I just discovered a quirk worth being aware of: The two LLDP daemons
out there work in a subtly different way.
'lldpd' uses PF_PACKET with ETH_P_ALL as the prtotocol, meaning
it captures all layer 2 frames. Same thing with the packet
capture interface tcpdump uses.
'open-lldp' uses PF_PACKET with the ETH_P_LLDP protocol specifically,
meaning it only gets LLDP layer 2 frames.
The kernel handles these two cases differently. All the protocol-
specific handlers are run *after* the hook we use. All the
ETH_P_ALL handlers are run *before*.
Meaning: LLDP works for lldpd without any changes to OVS, but doesn't
work for Open LLDP (though my tweaks do allow it).
However, here's a twist: The ETH_P_ALL case specifically skips
PACKET_LOOPBACK frames, the protocol specific case does not.
This inadverently means that when I add a flow allowing LLDP
it does not get double-delivered to lldpd and it does get
counted in the flow stats.
I think I would be inclined to argue that lldpd is doing it the
wrong way, that ETH_P_ALL packet sockets are meant as monitoring
taps, not protocol handlers.
Chris.
Chris Luke wrote (on Fri 03 Jan, 2014 at 01:33 GMT):
Jesse Gross wrote (on Fri 03 Jan, 2014 at 00:27 GMT):
On Thu, Jan 2, 2014 at 6:01 PM, Chris Luke <chr...@flirble.org> wrote:
On Jan 2, 2014, at 16:51, Jesse Gross <je...@nicira.com> wrote:
On Mon, Dec 23, 2013 at 11:46 PM, Chris Luke <chr...@flirble.org> wrote:
Jesse Gross wrote (on Tue 24 Dec, 2013 at 03:05 GMT):
* This type of concept has come up before and its usually in the
context of allowing an existing daemon like lldpad to be run on an OVS
port. At a minimum, we would need to make sure that whatever we do
here is compatible with that and ideally we would be able to
essentially solve both problems at the same time. If you are planning
on running routing protocol daemons then maybe it is already pretty
similar.
Exactly. I have lldpd running on my test setup and it appears to work
fine, but I'll dig into it to be sure.
Do the packets sent from the daemon go through OVS? It doesn't seem
like they would and while this would likely work in many cases, it is
odd.
No, from the daemon they go directly out the port. The case that needs OVS
involvement is incoming packets.
I believe that it works correctly in most cases but it seems somewhat
weird and asymmetric. Is there anything that we can do about it?
I think it's just the nature of it - the datapath only hooks into the
receive path of ports. If you wanted DP involvement in the other direction
we'd need some hook into host-originated traffic. That would certainly
make it feel more symmetric from a user perspective. I can take that on if
it's interesting for OVS.
If you feel the switch mode idea is a non-starter then I'll abandon it.
Yeah, I'm pretty strongly opposed to hanging more things onto the
normal action. In OVS there's a history of breaking things out of
normal because they tend to not interact very well with the OpenFlow
pipeline so I'm not eager to mix more things in.
Done. That code had ugly stuff in it anyway. But it was a good learning
exercise to get to know the code base.
As for potential upstream kernel stuff, really what we want is to
be able to resume the chain of network "stuff" from the point after
our module. It has been a very long time since i submitted anything
to the Linux kernel - like, since before it had SMP support. :)
Cheers,
Chris.
--
== chr...@flirble.org
--
== chr...@flirble.org
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
