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

[Murphy McCauley]

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/private.cgi/pox-dev-noxrepo.org/attachments/20120906/a5d93f0e/attachment.htm>