I'm working with an application that sends multicast traffic between a client and server. This traffic is sent via multicast. The client and server are both using VLAN interfaces, and need to communicate on a specific VLAN in order to properly talk to one another. The client and server are on the same subnet (so there are no network hops) and their IP's are in the same subnet (so the only routing going on is a route for the multicast to go out the proper VLAN interface).

Using tcpdump I can see the traffic on the untagged interface from both hosts, but if I look at the tagged interface, I only see the local machine's traffic. I confirmed that the traffic coming in the untagged interface has the proper vlan tag as well.

To help illustrate this, let's say:

VLAN: 10

What I'm seeing is:

[root@client]# tcpdump -ei ens192 host
.... vlan 10 ... client.[port] >[port]
.... vlan 10 ... server.[port] >[port]
.... vlan 10 ... client.[port] >[port]
.... vlan 10 ... server.[port] >[port]

and the same idea from the other side:

[root@server]# tcpdump -ei ens192 host
.... vlan 10 ... server.[port] >[port]
.... vlan 10 ... client.[port] >[port]
.... vlan 10 ... server.[port] >[port]
.... vlan 10 ... client.[port] >[port]

But when I tcpdump the tagged interface:

[root@client]# tcpdump -ei ens192.10 host
.... client.[port] >[port]
.... client.[port] >[port]

Same idea from the server.

I've tried sysctl net.ipv4.conf.all.rp_filter=0 with no change.

I also ran strace -fe trace=network -p [PID of software] 2>&1 | grep on both client and server, and there were only send_to calls being made, nothing received (which I expected after not seeing incoming on the tagged interface).

I also confirmed with ip maddr that ens192.10 is subscribed to, though all of the other VLAN interfaces are also subscribed which I found a bit suspicious. I confirmed with tcpdump that the traffic isn't coming in on any of the other VLAN interfaces. I'll admit I don't know how this software is performing the subscriptions since I have no access to the internals/source code.

Operating system is RHEL 7.5.

Is there any reason why properly tagged VLAN traffic wouldn't appear on the appropriate VLAN interface?

EDIT: Also, there is other mutlicast traffic working just fine on this VLAN interface, the problem seems specific to this software.

  • Stupid question, just in case: The vlan interface has the correct tag, address etc. (ip -d addr show dev ens192.10)? – dirkt Oct 3 '18 at 16:51
  • What sits between the client and server? One switch or more than one switch? – Mark Plotnick Oct 3 '18 at 17:04
  • @dirkt Yes, the vlan is tagged correctly and there's lots of other traffic flowing properly on the vlan. BTW, interfaces named [int].XX have to be tagged with the XX as the vlan: access.redhat.com/documentation/en-us/red_hat_enterprise_linux/… (scroll down to the interfacename= option. – Centimane Oct 3 '18 at 17:42
  • @MarkPlotnick A Cisco nexus switch. Only a single switch* (technically 2 nexus switches using virtual port channels, but that essentially acts as a single switch). Though I will say that there is other multicast working fine on this VLAN. – Centimane Oct 3 '18 at 17:44
  • How does the working-fine multicast traffic and its endpoints differ from the non-working multicast traffic? – Mark Plotnick Oct 3 '18 at 18:07

I don't think you can user tcpdump on a subinterface (i.e. ens192.10) like this on Linux.

The usual way to dump a specific (or all) vlan traffic is

tcpdump -i ens192 -e vlan 10 and host # just vlan tag 10
tcpdump -i ens192 -e vlan and host # all tagged vlans

or, if your tcpdump version does not support the vlan X syntax, you can match raw headers with

tcpdump -i ens192 -e 'ether[12:2] = 0x8100 and ether[15] = 10' and host
  • 1
    you definitely can use tcpdump on a virtual (sub) interface like this. I can tcpdump without a filter and see lots of working traffic and use it regularly. – Centimane Oct 3 '18 at 16:18
  • @Centimane it might depend on the tcpdump version, then. On my servers (admittedy, they have a quite old Ubuntu version) it misses lots of traffic while using the vlan X syntax shows a lot more going on. – Mr Shunz Oct 3 '18 at 16:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.