Help! VLAN tagged and untagged routing

[rostfrei]

I'm using my linux system (Linux 2.6.31.12-1.0.2) as a IPTV media center (XBMC). My interface configuration is

eth0      Link encap:Ethernet  HWaddr 00:01:2e:2b:12:6e
          inet addr:192.168.1.6  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::201:2eff:fe2b:126e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:72695907 errors:0 dropped:0 overruns:0 frame:0
          TX packets:152520 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:64299304 (64.2 MB)  TX bytes:22220802 (22.2 MB)
          Interrupt:21

eth0.3999 Link encap:Ethernet  HWaddr 00:01:2e:2b:12:6e
          inet addr:10.39.0.75  Bcast:10.39.3.255  Mask:255.255.252.0
          inet6 addr: fe80::201:2eff:fe2b:126e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:839421 errors:0 dropped:0 overruns:0 frame:0
          TX packets:82 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1131088026 (1.1 GB)  TX bytes:5180 (5.1 KB)

eth0 network is for the "internet" traffic, eth0.3999 tagged interface is for IPTV multicast traffic. I had to manually add the following networks so the multicast works.

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     *               255.255.255.0   U     0      0        0 eth0
95.176.0.0      *               255.255.0.0     U     0      0        0 eth0.3999
224.0.0.0       *               240.0.0.0       U     0      0        0 eth0.3999

Wireshark gives me clearer picture





I can clearly see IGMP messages exchange and that source address for the given multicast address 232.4.1.1 (one of the IPTV channels) is 95.176.246.71.

Now here is the question. I always thought that routes are for the outbound traffic, so the kernel knows where to shift packets when it travels out of the box (packet generated by the application or packet received from another interface, but not meant for the current box). In VLAN it is a little bit different. I manually removed network

$ route del -net 95.176.0.0 netmask 255.255.0.0

and channel playing stopped working. When I manually add route

$ route add -net 95.176.0.0 netmask 255.255.0.0 dev eth0.3999

channel playing starts to work again. UDP packages are present on the physical interface all the time. That confuses me. My Linux box is not multicast traffic originator, yet it still needs route to the originator so the channel playing works. Why? Is it the case that when tagged traffic comes to the physical port, kernel does not know where to shift tagged multicast traffic (on tagged eth0.3999 or untagged eth0)? And when I add the route it knows it has to shift it to the tagged interface eth0.3999? Is this true also for the inbound traffic?

All the help or some link resources on the issue would much be appreciated.

Thank you!

[ripp3r]

hi rostfrei,

Yes, I think you're right. Vlan must have a TAG and if you remove the route some packets cannot be identified as VLAN.

I don't think it's the same thing for inbound traffic, because if they pass trough a router it should be able to route them to the right way... but I'm not sure.

[larrythethird`]

In networking parlance, usually tagging is allowing multiple vlans over a single interface.

And a route is a route. It is bidirectional. The way you are using the routes, per interface, sort of makes each interface a router, with specific addresses to deal with. So you are using your Linux system as a little router. Although this should not cause a problem, there are reasons for not doing it this way. Mostly, causing more overhead on each interface, which in turn will cause more CPU usage on the entire system.

I have a Linux box that is my server and my file storage. On my router, I redirect all protocols to the server. But I do have to put my server's local IP address into my Windows system's hosts file. Otherwise, it would route out to the internet and then back to get to the server. That's sound like what is happening to you. Since multicast IP addresses are predesignated, unless you specify them in your internal network, the route would try to go out to the internet to try to find them.