Re: [nox-dev] Setting ToS bits (mod_flow)
Hmm,
If I replace flow = extract_flow(packet) with
#flow = extract_flow(packet)
flow = {}
flow[core.DL_DST] = packet.dst;
I don't seem to encounter this issue. Any idea why? Sorry if I side tracked
this a little thread. I'm still having the ToS problem when my action is
this,
actions = [[openflow.OFPAT_SET_NW_TOS,
22],[openflow.OFPAT_SET_DL_DST,
"00:17:df:2b:08:00"],[openflow.OFPAT_SET_NW_DST, "130.127.39.173"],
[openflow.OFPAT_OUTPUT, [0, openflow.OFPP_IN_PORT]]]
Thanks,
Aaron
On Wed, Nov 17, 2010 at 9:53 PM, Aaron Rosen wrote:
> Hi Murphy,
>
> Ok so now I'm just pinging 130.127.39.206 from 130.127.48.212 and it does
> seem to set the correct ToS bit value in this case. Though not in the case
> before when [openflow.OFPAT_OUTPUT, [0, openflow.OFPP_IN_PORT] is in the
> action list.
>
> Also, I just noticed that for some reason my controller doesn't seem to be
> handling arp correctly. For example, if i do arp -d (the gateways ip
> address). My computer will start arping for the gw and the following rule
> will be installed to the switch
>
>
> idle_timeout=5,hard_timeout=0,arp,dl_vlan=0x,dl_vlan_pcp=0x00,dl_src=00:17:df:2b:08:
>
> 00,dl_dst=00:22:fa:62:4a:de,nw_src=0.0.0.0,nw_dst=0.0.0.0,nw_tos=0x00,nw_proto=2,tp_src=0,tp_dst=0,actions=mod_nw_tos:0x10,output:2
>
> Though for some reason the arp response never gets back to it (note: all
> the entries in the flow seem to be correct).
>
> I've also seen the following errors from nox when this happens ( Though I
> only get one of these errors at a time,)
>
> (openflow typemap) py argument to Buffer must be of type str, instead
> received
>
>
>
> (openflow typemap) py argument to Buffer must be of type str, instead
> received
>
> Perhaps this is a bug in my controller? This does not seem to happen in
> mininet when I follow the same steps to reproduce this here.
>
> Is there any chance you could at this controller? Its a basic L2 learning
> switch that handles multiple dpids, I stripped out all the extra stuff I
> had.
>
> http://pastebin.com/SfgmzaqU
>
> Thanks,
>
> Aaron
>
>
> On Wed, Nov 17, 2010 at 9:01 PM, James "Murphy" McCauley
> wrote:
>
>> As an experiment, why don't you try setting the ToS bits to 0x10 and see
>> if that actually comes out like you'd expect it to.
>>
>> -- Murphy
>>
>> On Wed, 2010-11-17 at 20:49 -0500, Aaron Rosen wrote:
>> > Hi Murphy,
>> >
>> > So here is the topology: I am pinging 130.127.39.206 (<- connected via
>> > pc-engine which is running the openflow switch )from 130.127.48.212
>> > (Non-Openflow). Then I install the following action for that flow.
>> >
>> >actions = [[openflow.OFPAT_SET_NW_TOS,
>> > 22],[openflow.OFPAT_SET_DL_DST,
>> > "00:17:df:2b:08:00"],[openflow.OFPAT_SET_NW_DST, "130.127.39.173"],
>> > [openflow.OFPAT_OUTPUT, [0, openflow.OFPP_IN_PORT]]]
>> >
>> > This basically takes these icmp packets and forward them to
>> > 130.127.39.173 (Non, openflow) The DL_DST you see there is the gateway
>> > of 130.127.39.173.
>> >
>> > On 130.127.39.173, I see the ICMP request after the entry is
>> > installed. But the ToS bits are 0x00 and not (0x16 aka 22) as I they
>> > should be.
>> >
>> > Here is the information from dpctl for that flow (as you can see
>> > packets are being matched).
>> >
>> > cookie=0, duration_sec=484s, duration_nsec=53100s, table_id=1,
>> > priority=32768, n_packets=484, n_bytes=47432,
>> >
>> idle_timeout=15,hard_timeout=0,dl_dst=00:22:fa:62:4a:de,actions=mod_nw_tos:0x16,
>> > mod_dl_dst:00:17:df:2b:08:00,mod_nw_dst:130.127.39.173,IN_PORT
>> >
>> >
>> > Also, 130.127.39.173 and 130.127.39.206 are on different subnets (the
>> > mask is 255.255.255.128) (just pointing that out so it makes sense
>> > why i'm doing OFPP_IN_PORT).
>> >
>> > Thanks,
>> >
>> > Aaron
>> >
>> >
>> > On Wed, Nov 17, 2010 at 5:55 PM, Murphy McCauley
>> > wrote:
>> > Where are you sniffing with Wireshark? On the machine running
>> > the switch? Which interface are you sniffing? It needs to be
>> > an interface the packet *goes out on after having gone through
>> > the switch* or you won't see any difference since the switch
>> > hasn't actually gotten a chance to modify it yet. In
>> > particular, this means that if you're changing the TOS in both
>> > directions for the same connection, one interface will only
>> > show the altered TOS in one direction and *another* interface
>> > will show the altered TOS in the other direction.
>> >
>> >
>> > Also note that I've only tested with Open vSwitch and not with
>> > the reference switch.
>> >
>> >
>> > -- Murphy
>> >
>> >
>> > On Nov 16, 2010, at 1:03 PM, Aaron Rosen wrote:
>> >
>> >
>> > >
>> > > Yes,
>> > >
>> > >
>> > > See screenshot. In the terminal you can see the dump-flows
>> > > rule and the packets getting forwarded in wireshark. The
>> > > n_packets increment for
Re: [nox-dev] Setting ToS bits (mod_flow)
Hi Murphy, Ok so now I'm just pinging 130.127.39.206 from 130.127.48.212 and it does seem to set the correct ToS bit value in this case. Though not in the case before when [openflow.OFPAT_OUTPUT, [0, openflow.OFPP_IN_PORT] is in the action list. Also, I just noticed that for some reason my controller doesn't seem to be handling arp correctly. For example, if i do arp -d (the gateways ip address). My computer will start arping for the gw and the following rule will be installed to the switch idle_timeout=5,hard_timeout=0,arp,dl_vlan=0x,dl_vlan_pcp=0x00,dl_src=00:17:df:2b:08: 00,dl_dst=00:22:fa:62:4a:de,nw_src=0.0.0.0,nw_dst=0.0.0.0,nw_tos=0x00,nw_proto=2,tp_src=0,tp_dst=0,actions=mod_nw_tos:0x10,output:2 Though for some reason the arp response never gets back to it (note: all the entries in the flow seem to be correct). I've also seen the following errors from nox when this happens ( Though I only get one of these errors at a time,) (openflow typemap) py argument to Buffer must be of type str, instead received (openflow typemap) py argument to Buffer must be of type str, instead received Perhaps this is a bug in my controller? This does not seem to happen in mininet when I follow the same steps to reproduce this here. Is there any chance you could at this controller? Its a basic L2 learning switch that handles multiple dpids, I stripped out all the extra stuff I had. http://pastebin.com/SfgmzaqU Thanks, Aaron On Wed, Nov 17, 2010 at 9:01 PM, James "Murphy" McCauley wrote: > As an experiment, why don't you try setting the ToS bits to 0x10 and see > if that actually comes out like you'd expect it to. > > -- Murphy > > On Wed, 2010-11-17 at 20:49 -0500, Aaron Rosen wrote: > > Hi Murphy, > > > > So here is the topology: I am pinging 130.127.39.206 (<- connected via > > pc-engine which is running the openflow switch )from 130.127.48.212 > > (Non-Openflow). Then I install the following action for that flow. > > > >actions = [[openflow.OFPAT_SET_NW_TOS, > > 22],[openflow.OFPAT_SET_DL_DST, > > "00:17:df:2b:08:00"],[openflow.OFPAT_SET_NW_DST, "130.127.39.173"], > > [openflow.OFPAT_OUTPUT, [0, openflow.OFPP_IN_PORT]]] > > > > This basically takes these icmp packets and forward them to > > 130.127.39.173 (Non, openflow) The DL_DST you see there is the gateway > > of 130.127.39.173. > > > > On 130.127.39.173, I see the ICMP request after the entry is > > installed. But the ToS bits are 0x00 and not (0x16 aka 22) as I they > > should be. > > > > Here is the information from dpctl for that flow (as you can see > > packets are being matched). > > > > cookie=0, duration_sec=484s, duration_nsec=53100s, table_id=1, > > priority=32768, n_packets=484, n_bytes=47432, > > > idle_timeout=15,hard_timeout=0,dl_dst=00:22:fa:62:4a:de,actions=mod_nw_tos:0x16, > > mod_dl_dst:00:17:df:2b:08:00,mod_nw_dst:130.127.39.173,IN_PORT > > > > > > Also, 130.127.39.173 and 130.127.39.206 are on different subnets (the > > mask is 255.255.255.128) (just pointing that out so it makes sense > > why i'm doing OFPP_IN_PORT). > > > > Thanks, > > > > Aaron > > > > > > On Wed, Nov 17, 2010 at 5:55 PM, Murphy McCauley > > wrote: > > Where are you sniffing with Wireshark? On the machine running > > the switch? Which interface are you sniffing? It needs to be > > an interface the packet *goes out on after having gone through > > the switch* or you won't see any difference since the switch > > hasn't actually gotten a chance to modify it yet. In > > particular, this means that if you're changing the TOS in both > > directions for the same connection, one interface will only > > show the altered TOS in one direction and *another* interface > > will show the altered TOS in the other direction. > > > > > > Also note that I've only tested with Open vSwitch and not with > > the reference switch. > > > > > > -- Murphy > > > > > > On Nov 16, 2010, at 1:03 PM, Aaron Rosen wrote: > > > > > > > > > > Yes, > > > > > > > > > See screenshot. In the terminal you can see the dump-flows > > > rule and the packets getting forwarded in wireshark. The > > > n_packets increment for each icmp packet received so it is > > > matching this flow. (Wireshark shows the tos bits being > > > 0x00). > > > > > > > > > Thanks, > > > > > > Aaron > > > > > > On Tue, Nov 16, 2010 at 3:39 PM, Murphy McCauley > > > wrote: > > > So you are seeing that the switch receives the > > > action correctly (that is, with the ToS modify > > > action and the correct new ToS bits), but the > > > packets aren't being modified as you expect? Are > > > you sure the packets you want modified are matching? > > > > > > > > > --
Re: [nox-dev] Setting ToS bits (mod_flow)
As an experiment, why don't you try setting the ToS bits to 0x10 and see if that actually comes out like you'd expect it to. -- Murphy On Wed, 2010-11-17 at 20:49 -0500, Aaron Rosen wrote: > Hi Murphy, > > So here is the topology: I am pinging 130.127.39.206 (<- connected via > pc-engine which is running the openflow switch )from 130.127.48.212 > (Non-Openflow). Then I install the following action for that flow. > >actions = [[openflow.OFPAT_SET_NW_TOS, > 22],[openflow.OFPAT_SET_DL_DST, > "00:17:df:2b:08:00"],[openflow.OFPAT_SET_NW_DST, "130.127.39.173"], > [openflow.OFPAT_OUTPUT, [0, openflow.OFPP_IN_PORT]]] > > This basically takes these icmp packets and forward them to > 130.127.39.173 (Non, openflow) The DL_DST you see there is the gateway > of 130.127.39.173. > > On 130.127.39.173, I see the ICMP request after the entry is > installed. But the ToS bits are 0x00 and not (0x16 aka 22) as I they > should be. > > Here is the information from dpctl for that flow (as you can see > packets are being matched). > > cookie=0, duration_sec=484s, duration_nsec=53100s, table_id=1, > priority=32768, n_packets=484, n_bytes=47432, > idle_timeout=15,hard_timeout=0,dl_dst=00:22:fa:62:4a:de,actions=mod_nw_tos:0x16, > mod_dl_dst:00:17:df:2b:08:00,mod_nw_dst:130.127.39.173,IN_PORT > > > Also, 130.127.39.173 and 130.127.39.206 are on different subnets (the > mask is 255.255.255.128) (just pointing that out so it makes sense > why i'm doing OFPP_IN_PORT). > > Thanks, > > Aaron > > > On Wed, Nov 17, 2010 at 5:55 PM, Murphy McCauley > wrote: > Where are you sniffing with Wireshark? On the machine running > the switch? Which interface are you sniffing? It needs to be > an interface the packet *goes out on after having gone through > the switch* or you won't see any difference since the switch > hasn't actually gotten a chance to modify it yet. In > particular, this means that if you're changing the TOS in both > directions for the same connection, one interface will only > show the altered TOS in one direction and *another* interface > will show the altered TOS in the other direction. > > > Also note that I've only tested with Open vSwitch and not with > the reference switch. > > > -- Murphy > > > On Nov 16, 2010, at 1:03 PM, Aaron Rosen wrote: > > > > > > Yes, > > > > > > See screenshot. In the terminal you can see the dump-flows > > rule and the packets getting forwarded in wireshark. The > > n_packets increment for each icmp packet received so it is > > matching this flow. (Wireshark shows the tos bits being > > 0x00). > > > > > > Thanks, > > > > Aaron > > > > On Tue, Nov 16, 2010 at 3:39 PM, Murphy McCauley > > wrote: > > So you are seeing that the switch receives the > > action correctly (that is, with the ToS modify > > action and the correct new ToS bits), but the > > packets aren't being modified as you expect? Are > > you sure the packets you want modified are matching? > > > > > > -- Murphy > > > > > > On Nov 16, 2010, at 12:09 PM, Aaron Rosen wrote: > > > > > Murphy, > > > > > > Unfortunately this patch does not actually change > > > the ToS bits in the ip packet. Sorry I should have > > > confirmed that before I told you it worked. I just > > > checkout a fresh copy of nox destiny and confirmed > > > this with wireshark. > > > > > > (I assumed it worked before, because of this "68, > > > n_packets=37, n_bytes=3626, > > > > idle_timeout=15,hard_timeout=0,dl_dst=00:22:fa:62:4a:de,actions=mod_nw_tos:0x16,mod_dl_dst:00:17:df:2b:08:00,mod_nw_dst:130.127.39.173,IN_PORT" > action being installed) > > > > > > Sorry, > > > > > > Aaron > > > > > > > > > On Mon, Nov 15, 2010 at 8:19 PM, James "Murphy" > > > McCauley wrote: > > > Great. Pushed to destiny. > > > > > > -- Murphy > > > > > > > > > On Mon, 2010-11-15 at 20:11 -0500, Aaron > > > Rosen wrote: > > > > Awesome Murphy that seemed to work :D > > > > > > > > cookie=0, dura
Re: [nox-dev] Setting ToS bits (mod_flow)
Hi Murphy,
So here is the topology: I am pinging 130.127.39.206 (<- connected via
pc-engine which is running the openflow switch )from 130.127.48.212
(Non-Openflow). Then I install the following action for that flow.
actions = [[openflow.OFPAT_SET_NW_TOS, 22],[openflow.OFPAT_SET_DL_DST,
"00:17:df:2b:08:00"],[openflow.OFPAT_SET_NW_DST, "130.127.39.173"],
[openflow.OFPAT_OUTPUT, [0, openflow.OFPP_IN_PORT]]]
This basically takes these icmp packets and forward them to 130.127.39.173
(Non, openflow) The DL_DST you see there is the gateway of 130.127.39.173.
On 130.127.39.173, I see the ICMP request after the entry is installed. But
the ToS bits are 0x00 and not (0x16 aka 22) as I they should be.
Here is the information from dpctl for that flow (as you can see packets are
being matched).
cookie=0, duration_sec=484s, duration_nsec=53100s, table_id=1,
priority=32768, n_packets=484, n_bytes=47432,
idle_timeout=15,hard_timeout=0,dl_dst=00:22:fa:62:4a:de,actions=mod_nw_tos:0x16,
mod_dl_dst:00:17:df:2b:08:00,mod_nw_dst:130.127.39.173,IN_PORT
Also, 130.127.39.173 and 130.127.39.206 are on different subnets (the mask
is 255.255.255.128) (just pointing that out so it makes sense why i'm doing
OFPP_IN_PORT).
Thanks,
Aaron
On Wed, Nov 17, 2010 at 5:55 PM, Murphy McCauley wrote:
> Where are you sniffing with Wireshark? On the machine running the switch?
> Which interface are you sniffing? It needs to be an interface the packet
> *goes out on after having gone through the switch* or you won't see any
> difference since the switch hasn't actually gotten a chance to modify it
> yet. In particular, this means that if you're changing the TOS in both
> directions for the same connection, one interface will only show the altered
> TOS in one direction and *another* interface will show the altered TOS in
> the other direction.
>
> Also note that I've only tested with Open vSwitch and not with the
> reference switch.
>
> -- Murphy
>
> On Nov 16, 2010, at 1:03 PM, Aaron Rosen wrote:
>
> Yes,
>
> See screenshot. In the terminal you can see the dump-flows rule and the
> packets getting forwarded in wireshark. The n_packets increment for each
> icmp packet received so it is matching this flow. (Wireshark shows the tos
> bits being 0x00).
>
> Thanks,
>
> Aaron
>
> On Tue, Nov 16, 2010 at 3:39 PM, Murphy McCauley wrote:
>
>> So you are seeing that the switch receives the action correctly (that is,
>> with the ToS modify action and the correct new ToS bits), but the packets
>> aren't being modified as you expect? Are you sure the packets you want
>> modified are matching?
>>
>> -- Murphy
>>
>> On Nov 16, 2010, at 12:09 PM, Aaron Rosen wrote:
>>
>> Murphy,
>>
>> Unfortunately this patch does not actually change the ToS bits in the ip
>> packet. Sorry I should have confirmed that before I told you it worked. I
>> just checkout a fresh copy of nox destiny and confirmed this with wireshark.
>>
>>
>> (I assumed it worked before, because of this "68, n_packets=37,
>> n_bytes=3626,
>> idle_timeout=15,hard_timeout=0,dl_dst=00:22:fa:62:4a:de,actions=*
>> mod_nw_tos:*0x16,mod_dl_dst:00:17:df:2b:08:00,mod_nw_dst:130.127.39.173,IN_PORT"
>> action being installed)
>>
>> Sorry,
>>
>> Aaron
>>
>>
>> On Mon, Nov 15, 2010 at 8:19 PM, James "Murphy" McCauley
>> wrote:
>>
>>> Great. Pushed to destiny.
>>>
>>> -- Murphy
>>>
>>> On Mon, 2010-11-15 at 20:11 -0500, Aaron Rosen wrote:
>>> > Awesome Murphy that seemed to work :D
>>> >
>>> > cookie=0, duration_sec=31s, duration_nsec=71000s, table_id=0,
>>> > priority=32768, n_packets=32, n_bytes=3136,
>>> >
>>> idle_timeout=5,hard_timeout=0,icmp,dl_vlan=0x,dl_vlan_pcp=0x00,dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:04,nw_src=10.0.0.2,nw_dst=10.0.0.4,icmp_type=8,icmp_code=0,actions=mod_nw_tos:0x28,output:3
>>> >
>>> > Thanks,
>>> >
>>> > Aaron
>>> >
>>> >
>>> > On Mon, Nov 15, 2010 at 7:51 PM, James "Murphy" McCauley
>>> > wrote:
>>> > >
>>> > > Try this patch.
>>> > >
>>> > > Also, your parameter for OFPAT_SET_NW_TOS ("44") should probably be
>>> > an
>>> > > integer (44).
>>> > >
>>> > > -- Murphy
>>> > >
>>> > > On Mon, 2010-11-15 at 15:30 -0500, Aaron Rosen wrote:
>>> > > > Thanks Niky,
>>> > > >
>>> > > >
>>> > > > Does anyone know how I would modify those ToS bits then? Or what
>>> > all I
>>> > > > would have to add to make, make_action_array be able to modify the
>>> > ToS
>>> > > > in the manor that I'm attempting?
>>> > > >
>>> > > >
>>> > > > Thanks,
>>> > > >
>>> > > > Aaron
>>> > > >
>>> > > > On Mon, Nov 15, 2010 at 3:20 PM, Niky Riga wrote:
>>> > > > I am not 100% but I think the problem is that the
>>> > > > OFPAT_SET_NW_TOS action is not currently handled by the
>>> > > > function that creates the actions
>>> > > > for the python modules.
>>> > > >
>>> > > > If you look at the core.py (src/nox/lib/core.py) there is
>>> > a
>>> > > > function
>>> > > > make_action_array() that creates the actions st
Re: [nox-dev] Setting ToS bits (mod_flow)
Where are you sniffing with Wireshark? On the machine running the switch?
Which interface are you sniffing? It needs to be an interface the packet *goes
out on after having gone through the switch* or you won't see any difference
since the switch hasn't actually gotten a chance to modify it yet. In
particular, this means that if you're changing the TOS in both directions for
the same connection, one interface will only show the altered TOS in one
direction and *another* interface will show the altered TOS in the other
direction.
Also note that I've only tested with Open vSwitch and not with the reference
switch.
-- Murphy
On Nov 16, 2010, at 1:03 PM, Aaron Rosen wrote:
> Yes,
>
> See screenshot. In the terminal you can see the dump-flows rule and the
> packets getting forwarded in wireshark. The n_packets increment for each icmp
> packet received so it is matching this flow. (Wireshark shows the tos bits
> being 0x00).
>
> Thanks,
>
> Aaron
>
> On Tue, Nov 16, 2010 at 3:39 PM, Murphy McCauley wrote:
> So you are seeing that the switch receives the action correctly (that is,
> with the ToS modify action and the correct new ToS bits), but the packets
> aren't being modified as you expect? Are you sure the packets you want
> modified are matching?
>
> -- Murphy
>
> On Nov 16, 2010, at 12:09 PM, Aaron Rosen wrote:
>
>> Murphy,
>>
>> Unfortunately this patch does not actually change the ToS bits in the ip
>> packet. Sorry I should have confirmed that before I told you it worked. I
>> just checkout a fresh copy of nox destiny and confirmed this with wireshark.
>>
>> (I assumed it worked before, because of this "68, n_packets=37,
>> n_bytes=3626,
>> idle_timeout=15,hard_timeout=0,dl_dst=00:22:fa:62:4a:de,actions=mod_nw_tos:0x16,mod_dl_dst:00:17:df:2b:08:00,mod_nw_dst:130.127.39.173,IN_PORT"
>> action being installed)
>>
>> Sorry,
>>
>> Aaron
>>
>>
>> On Mon, Nov 15, 2010 at 8:19 PM, James "Murphy" McCauley
>> wrote:
>> Great. Pushed to destiny.
>>
>> -- Murphy
>>
>> On Mon, 2010-11-15 at 20:11 -0500, Aaron Rosen wrote:
>> > Awesome Murphy that seemed to work :D
>> >
>> > cookie=0, duration_sec=31s, duration_nsec=71000s, table_id=0,
>> > priority=32768, n_packets=32, n_bytes=3136,
>> > idle_timeout=5,hard_timeout=0,icmp,dl_vlan=0x,dl_vlan_pcp=0x00,dl_src=00:00:00:00:00:02,dl_dst=00:00:00:00:00:04,nw_src=10.0.0.2,nw_dst=10.0.0.4,icmp_type=8,icmp_code=0,actions=mod_nw_tos:0x28,output:3
>> >
>> > Thanks,
>> >
>> > Aaron
>> >
>> >
>> > On Mon, Nov 15, 2010 at 7:51 PM, James "Murphy" McCauley
>> > wrote:
>> > >
>> > > Try this patch.
>> > >
>> > > Also, your parameter for OFPAT_SET_NW_TOS ("44") should probably be
>> > an
>> > > integer (44).
>> > >
>> > > -- Murphy
>> > >
>> > > On Mon, 2010-11-15 at 15:30 -0500, Aaron Rosen wrote:
>> > > > Thanks Niky,
>> > > >
>> > > >
>> > > > Does anyone know how I would modify those ToS bits then? Or what
>> > all I
>> > > > would have to add to make, make_action_array be able to modify the
>> > ToS
>> > > > in the manor that I'm attempting?
>> > > >
>> > > >
>> > > > Thanks,
>> > > >
>> > > > Aaron
>> > > >
>> > > > On Mon, Nov 15, 2010 at 3:20 PM, Niky Riga wrote:
>> > > > I am not 100% but I think the problem is that the
>> > > > OFPAT_SET_NW_TOS action is not currently handled by the
>> > > > function that creates the actions
>> > > > for the python modules.
>> > > >
>> > > > If you look at the core.py (src/nox/lib/core.py) there is
>> > a
>> > > > function
>> > > > make_action_array() that creates the actions string that
>> > is
>> > > > sent.
>> > > >
>> > > > This function covers all the cases but the
>> > OFPAT_SET_NW_TOS
>> > > > action.
>> > > >
>> > > > Hope this is helpful.
>> > > >
>> > > > --niky
>> > > >
>> > > > Aaron Rosen wrote:
>> > > >
>> > > > Hello,
>> > > >
>> > > > I'm trying to change the ToS bits in IP packets
>> > but
>> > > > nox is telling me invalid action type 8.
>> > > >
>> > > > Here is the blurb of code that I'm trying:
>> > > >
>> > > > attrs = extract_flow(packet)
>> > > > outport = self.data[dpid, mac_to_str(packet.dst)]
>> > > > actions = [[openflow.OFPAT_SET_NW_TOS, "44"],
>> > > > [ openflow.OFPAT_OUTPUT, [0, outport]]]
>> > > > self.install_datapath_flow( dpid , attrs, 5, 0,
>> > > > actions, bufid, openflow.OFP_DEFAULT_PRIORITY,
>> > inport,
>> > > > packet)
>> > > >
>> > > > Could anyone point out where I'm going wrong?
>> > > >
>> > > > Thanks,
>> > > >
>> > > > Aaron
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Aaron O. Rosen
>> > > > Masters Student - Network Communication
>> > > >
Re: [nox-dev] Hosts with Same IP
HI Rohit I'm not sure if this is a question appropriate to the nox-dev list. I believe the list is intended for questions regarding developing over NOX. You may want to lookup a previous work called Plug-n-serve, followed by an improved system called Aster*x, that builds a server farm with all hosts having same alias IP address, while having different MAC address. To achieve what you are suggesting, you might have to rewrite MAC addresses at the gateway point instead of trying to use ARP revocation to change the MAC address for each request. Srini. On Wed, Nov 17, 2010 at 10:37 AM, Rohit Manohar wrote: > I am trying to simulate Server-Load Distribution. I have a farm of > host behind a switch who should be addressable by a single IP because > they are part of the same server service advertised to the outside > world. The switch will decide which flow to assign to which host > depending upon the link utilization of the hosts. So, during the > topology setup, can I assign the same IP address to the farm of hosts? > > Regards, > -- > Rohit Manohar > Graduate Student > North Carolina State University > Raleigh, US. > > ___ > nox-dev mailing list > nox-dev@noxrepo.org > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org > ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] Multiple Actions Format
Is the action to change destination IP address of a flow 'openflow.OFPAT_SET_NW_DST'? If yes then is this the right format to specify multiple actions? actions = [[openflow.OFPAT_OUTPUT, [0, prt[0]]],[openflow.OFPAT_SET_NW_DST,[0, ip[0 Regards, -- Rohit Manohar Graduate Student North Carolina State University Raleigh, US. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
[nox-dev] Hosts with Same IP
I am trying to simulate Server-Load Distribution. I have a farm of host behind a switch who should be addressable by a single IP because they are part of the same server service advertised to the outside world. The switch will decide which flow to assign to which host depending upon the link utilization of the hosts. So, during the topology setup, can I assign the same IP address to the farm of hosts? Regards, -- Rohit Manohar Graduate Student North Carolina State University Raleigh, US. ___ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
