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=531000000s, 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 <jam...@nau.edu> 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 <jam...@nau.edu> 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
>> <jam...@nau.edu>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=710000000s, table_id=0,
>>> > priority=32768, n_packets=32, n_bytes=3136,
>>> >
>>> idle_timeout=5,hard_timeout=0,icmp,dl_vlan=0xffff,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
>>> > <jam...@nau.edu> 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 <nr...@bbn.com> 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
>>> > > > 306B Fluor Daniel
>>> > > > 843.425.9777
>>> > > >
>>> > > >
>>> > > >
>>> > > >
>>> >
>>> ------------------------------------------------------------------------
>>> > > >
>>> > > > _______________________________________________
>>> > > > nox-dev mailing list
>>> > > > nox-dev@noxrepo.org
>>> > > >
>>> > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>>> > > >
>>> > > >
>>> > > >
>>> > > > --
>>> > > > Aaron O. Rosen
>>> > > > Masters Student - Network Communication
>>> > > > 306B Fluor Daniel
>>> > > > 843.425.9777
>>> > > >
>>> > > >
>>> > > > _______________________________________________
>>> > > > nox-dev mailing list
>>> > > > nox-dev@noxrepo.org
>>> > > > http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
>>> > >
>>> >
>>> >
>>> >
>>> > --
>>> > Aaron O. Rosen
>>> > Masters Student - Network Communication
>>> > 306B Fluor Daniel
>>> > 843.425.9777
>>> >
>>>
>>>
>>>
>>
>>
>> --
>> Aaron O. Rosen
>> Masters Student - Network Communication
>> 306B Fluor Daniel
>> 843.425.9777
>>
>>
>>
>
>
> --
> Aaron O. Rosen
> Masters Student - Network Communication
> 306B Fluor Daniel
> 843.425.9777
>
> <tos.png>
>
>
>
--
Aaron O. Rosen
Masters Student - Network Communication
306B Fluor Daniel
843.425.9777
_______________________________________________
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
