[pox-dev] packet.type doesn't work with VLAN-tagged packets

[Sam Russell]

That all makes sense, the VLAN vs non-VLAN stuff is going to be an ongoing
issue I think.

On a slightly related note, I've made a tun/tap module for POX that I'll
share next week, and the VLAN thing makes a mess of it given the packets
need to be straight Ethernet when going into tap0. On my Pronto 3780 I get
latency from 1-50ms and about 4Mb/s for extended transfers, but it does
mean we can plug a software router directly into the controller instead of
using virtual machines like in RouteFlow,

Nice interview for SDN Central btw

Sent from my iPhone

On Sep 7, 2012, at 4:56 PM, Murphy McCauley <murphy.mccauley at gmail.com>
wrote:

I agree with you in theory, though I think a design like that is liable to
either be somewhat more brittle or somewhat more complex (or both).  Issues
like making it work well when *building* a chain of packets from scratch
may complicate it, for example.  And then there's the question of what you
really mean... if you have a VLAN in an L2-in-L3 tunnel that's running on a
non-VLAN.   If you ask for the VLAN header from the "root" packet, what do
you get?  I argue that using find() or something that works like find()
gets you an answer that you may well not want.  Actually crawling the
structure yourself makes it much clearer, even though it's more of a pain,
but hopefully things like the effective_ethertype shortcut can take some of
the pain from the common cases.

There are other things about the packet library that could use improving
too... *I* certainly have not been worried enough about the efficiency of
this operation to try to optimize it.  I'm also not sure the performance
improvement is obvious in common cases.  Which is more expensive: searching
through four nested packet objects looking for a particular one twice, or
searching through once so that you can build a hashed map to each header
and then doing two hashed lookups?  I actually don't know, but I have my
suspicions.

The optimization I'm more interested in is parse-on-demand, but I've never
thought too hard about how to do it well.

-- Murphy

On Aug 31, 2012, at 10:08 PM, Sam Russell wrote:

Sorry for the spam

I think I'm trying to say that I want something more deterministic - we
should only have to recurse through the packet headers once when we parse
the packet, and any references afterwards should just be lookups instead of
having to recurse again.

Is this right, or am I going a bit overboard on trying to optimise things?

On Sat, Sep 1, 2012 at 4:58 PM, Sam Russell <sam.h.russell at gmail.com> wrote:

> The find() function does look good though, I'll try reimplementing using
> that
>
>
> On Sat, Sep 1, 2012 at 4:42 PM, Sam Russell <sam.h.russell at gmail.com>wrote:
>
>> Something like that. When the OpenFlow match is created, it recurses
>> through packet.next to find all the details, and checks the instance of
>> each one. Once it's done with this, could we cast (do you cast in Python?)
>> the packet in something else?
>>
>> For example, if it's a ping packet, then could you cast it as follows:
>>
>> EthernetPacket subclasses Packet
>> IPPacket subclasses EthernetPacket
>> ICMPPacket subclasses IPPacket
>> EchoPacket subclasses ICMPPacket
>>
>> You could then do tests, to check if it's an instance of IPPacket, then
>> of ICMPPacket, then EchoPacket, and if it's an EchoPacket then you could
>> reference anything from the echo packet, plus anything below (MAC
>> addresses, IP addresses etc)
>>
>> On Sat, Sep 1, 2012 at 4:14 PM, Murphy McCauley <
>> murphy.mccauley at gmail.com> wrote:
>>
>>> You can do pkt.find('icmp') for example to find a deeper header by name
>>> or type.  Something like that?
>>>
>>> (Excuse brevity; on phone)
>>> On Aug 31, 2012 7:52 PM, "Sam Russell" <sam.h.russell at gmail.com> wrote:
>>>
>>>> That looks useful, I think there could be a better way though - is
>>>> there any easy way to do a quick parse of a packet and create pointers to
>>>> useful parts? For example, if I know that a packet is ping (ICMP echo
>>>> request), is it useful to be able to check if packet.echo exists and then
>>>> reference that?
>>>>
>>>> On Fri, Aug 31, 2012 at 12:07 PM, Murphy McCauley <
>>>> murphy.mccauley at gmail.com> wrote:
>>>>
>>>>> I guess I mean effective_ethertype. :)  In particular, check
>>>>> out 42cec08c23 on MurphyMc/pox.  The commits after that show its usage a
>>>>> bit as they fix similar issues to the one you called out but in l2_multi
>>>>> and discovery.  I guess we should be doing this for l2_learning too (and
>>>>> possibly some other things?).
>>>>>
>>>>> -- Murphy
>>>>>
>>>>> On Aug 30, 2012, at 2:06 PM, Murphy McCauley wrote:
>>>>>
>>>>> Check out the "effective_type" attribute in my fork's packet class.
>>>>>
>>>>> (Excuse brevity -- on my phone)
>>>>> On Aug 30, 2012 1:12 PM, "Sam Russell" <sam.h.russell at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I've been trying to build some router functionality into POX, and I'm
>>>>>> coming across a similar problem to what ofp_match() used to have - here's a
>>>>>> snippet from l2_learning:
>>>>>>
>>>>>> # my code
>>>>>>     if packet.type == packet.ARP_TYPE:
>>>>>>         print "ARP packet"
>>>>>>     else:
>>>>>>     print "Packet type: " + str(packet.type)
>>>>>>
>>>>>> # next line, what I've based my code on
>>>>>>     if not self.transparent:
>>>>>>       if packet.type == packet.LLDP_TYPE or
>>>>>> packet.dst.isBridgeFiltered(): # 2
>>>>>>         drop()
>>>>>>         return
>>>>>>
>>>>>> The problem with the Pronto switches is that they pass all packets up
>>>>>> to the controller with VLAN headers, potentially also LLDP packets, meaning
>>>>>> the packet.type field is useless.
>>>>>>
>>>>>> What is the best plan of attack for this? I'm not sure of the best
>>>>>> style-wise for POX or Python, but I'm thinking either a macro/function that
>>>>>> checks if it's VLAN tagged and pulls out the inner type (eth_type) where
>>>>>> appropriate, or am I best to use the now-fixed ofp_match at the start of
>>>>>> _handle_PacketIn() and use the dl_type from there?
>>>>>>
>>>>>
>>>>>
>>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.noxrepo.org/pipermail/pox-dev-noxrepo.org/attachments/20120907/c0f7be1e/attachment-0002.htm>