NFD

Junxiao Shi wrote:

I generally agree with this feature.

I wonder the implication on receive path:

Does EthernetTransport need to construct a libpcap filter string so that it only receives Ethernet frames with a specific VLAN tag or no VLAN tag?

Note that their might be multiple such tags (VLAN hierarchy). NFD should be able receive a packet, check if VLAN tag(s) exist and decode properly.

Does EthernetTransport need to unwrap received frames by deleting the 802.11Q header?

I think so, but not sure about the implications. Some Intel drivers strip vlan tags.

What are the advantages of adding VLAN handling in NFD?

I might have misunderstood your scenario/application/use case, but I think VLAN encap/decap should not be done by NFD. This is something that should be handled at the kernel level or even below. The obvious advantage is that the kernel is able to exploit the hardware VLAN acceleration provided by most Ethernet controllers.

Davide Pesavento wrote:
What are the advantages of adding VLAN handling in NFD?

I might have misunderstood your scenario/application/use case,

This is the use case I am interested in:

Let's say, I have two machines.

I bring up a VLAN interface on the first machine as eth0.801 (VLAN ID=801). The Ethernet address is a0:36:9g:36:23:7c.

On the other end of the VLAN, I add an interface on the second machine as eth0.801 (VLAN ID=801). The Ethernet address is a0:36:9f:23:df:56.

I want to exchange NDN packets between these two machines without needing to configure IP tunnels.

but I think VLAN encap/decap should not be done by NFD. This is something that should be handled at the kernel level or even below. The obvious advantage is that the kernel is able to exploit the hardware VLAN acceleration provided by most Ethernet controllers.

Maybe.

susmit shannigrahi wrote:

I bring up a VLAN interface on the first machine as eth0.801 (VLAN ID=801). The Ethernet address is a0:36:9g:36:23:7c.
On the other end of the VLAN, I add an interface on the second machine as eth0.801 (VLAN ID=801). The Ethernet address is a0:36:9f:23:df:56.
I want to exchange NDN packets between these two machines without needing to configure IP tunnels.

Right. So, if NFD is configured to use eth0.801 on the two machines, isn't the kernel automatically adding/removing the VLAN tags from packets sent/received through those (pseudo-)interfaces?

Right. So, if NFD is configured to use eth0.801 on the two machines, isn't the kernel automatically adding/removing the VLAN tags from packets sent/received through those (pseudo-)interfaces?

Ah, I didn't realize NFD treats vlan interfaces as separate faces. So this might work already. Thanks for pointing that out.

I did a quick test on a VLAN and it's crashing NFD, so I take that as a good sign. :)

Bug here: http://redmine.named-data.net/issues/3348

susmit shannigrahi wrote:

Ah, I didn't realize NFD treats vlan interfaces as separate faces. So this might work already. Thanks for pointing that out.

I haven't tried with Linux VLAN pseudo-interfaces, but they should look like normal interfaces to userspace programs, so I'm expecting NFD will create a multicast face for each one of them... which might not be desirable in this case, because it means we'd receive the same packets twice (untagged from eth0.801 and tagged from eth0), see #1712 for a to-be-implemented solution to this problem.

Right. So, if NFD is configured to use eth0.801 on the two machines, isn't the kernel automatically adding/removing the VLAN tags from packets sent/received through those (pseudo-)interfaces?

The kernel doesn't seem to be removing the tags, hence the crash in 3348. Kernel delivers the VLAN packet with the tag to NFD.

That's surprising. Are you sure the packets are coming from the vlan interface?

Anyway, after we fix #3348, is there anything else we need to do in order to "support" VLANs? I'm expecting that untagged packets sent to a vlan pseudo-interface (e.g. eth0.42) are tagged by the kernel with the vlan id assigned to that interface.

Davide Pesavento wrote:
That's surprising. Are you sure the packets are coming from the vlan interface?

Anyway, after we fix #3348, is there anything else we need to do in order to "support" VLANs? I'm expecting that untagged packets sent to a vlan pseudo-interface (e.g. eth0.42) are tagged by the kernel with the vlan id assigned to that interface.

So I added this to the Ethernet face's processIncomingPacket.

NFD_LOG_FACE_DEBUG("Ethenet type" << ntohs(eh->ether_type));

It gives me the number 33024, which is "Customer VLAN Tag Type" according to this .

Do you still have the whole log line generated by the statement you added? In particular I care about the part between brackets with the Face URIs.

Davide Pesavento wrote:
Do you still have the whole log line generated by the statement you added? In particular I care about the part between brackets with the Face URIs.

Sorry, should've included that. It's coming from the actual interface.

1449116144.465650 DEBUG: [EthernetFace] [id=260,local=dev://p2p2,remote=ether://[01:00:5e:00:17:aa]] Ethenet type 33024

Ticket status should be "rejected".