[pox-dev] questions about l2_learning vs l2_pairs

[Murphy McCauley]

On May 27, 2015, at 2:24 PM, Kostas Chartsias <kchartsias at yahoo.gr> wrote:

> Hi all and thanks for the continuous support Murphy!!!
> I am trying to understand the differences between l2_learning and l2_pairs switch cause i am writing a report for a project.

The POX forwarding components are just examples, and they're not all at the same level of ... polish?  completeness?  So aside from taking slightly different approaches to learning, l2_learning is more "finished".

> 1)The l2_learning switch drops lldp packets and l2_pairs doesn't.Is there any side effect by not dropping lldp packets?

I think it's 802.1D that specifies a range of Ethernet addresses which are never supposed to be forwarded by switches.  This the the range usually used by LLDP.  l2_learning honors this; l2_pairs doesn't.  Thus, l2_pairs is less standards compliant.  If there are things trying to use LLDP on the network, this may be problematic.

> 2)The l2_learning switch handles multicast traffic and l2_pairs doesn't .I guess it's an extra feature and nothing else.

l2_pairs basically ends up doing the same thing, IIRC.  Since l2_pairs should, in practice, never learn a multicast address as the source, they both just end up flooding multicast packets from the controller, I think.  An alternate approach would be to actually install rules to forward multicast traffic without coming to the controller, but I don't think either of them actually do this.  (It's cleaner to do this using Nicira extended matches because you can match on the multicast bit in the destination address, but neither of these examples use any Nicira extensions.)

> 3)The more confusing feature in l2_learning is why drop packets if the output port is the same as input.How is it possible and why it hasnt been implemented in the l2_pairs.

There are multiple ways this can happen, but a quick example:
Imagine you have an OpenFlow switch connected to a plain old dumb hub.  Also connected to the hub are two hosts.  The OpenFlow switch sees both source an destination out the same port.

l2_pairs doesn't implement it because l2_pairs is a simpler example.

> Moreover i would like to describe in details their functionality.
> We have  pc1 and pc2 with arp cache empty and i ping pc1->pc2
> *l2_learning switch
> Pc1 arp broadcast.Switch sends packet to controller.Controller sends packet out flood and add to its decitionary mac and port of the incoming packet.Pc2 responds with its mac and controller adds to its dictionary mac and port of pc2.Installs one flow for the arp responce.After that the echo request and reply go to the controller and it installs new flows for each of them,cause l2_learning works with full match.
> *l2_pairs
> Pc1 arp broadcast.Switch sends packet to controller.Controller sends packet out flood and adds to its decitionary mac and port of the incoming packet.Pc2 responds with its mac and controller adds to its dictionary mac and port of pc2.Installs one flow for the arp responce.(Same thing as the previous one).But now after that with echo request it adds one more flow and that's the end of this,cause it works only in the data linke layer and doesnt care for the protocols above it.
> 
> To sum up.
> for two hosts
> l2_learning 1flow for arp reply,1flow for echo request and 1flow for echo reply and more flows for different ports etc...even though they are the same hosts
> l2_pairs 1 flow for arp reply,1 flow for echo request or whatever we send and that's the end of it
> (i assume we dont have timeouts and flows are permanent)

Yeah that sounds about right.  They're different approaches that represent different tradeoffs.  For example, the fact that l2_learning does fine grained entries means it's (sort of) easy to write arbitrary access control policies atop its flows, but this isn't the case for l2_pairs' broad entries.

> Any help or any correction would be very much appreciated!!!
> thanks in advance!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.noxrepo.org/pipermail/pox-dev-noxrepo.org/attachments/20150527/c9cc15ab/attachment.html>