multi-homed question

[rctor]

Hi, firstly thank you.

I have question about something that I'm having difficulty figuring out. A quick rundown on my setup:

pimd --version pimd version 3.0-beta1

Artful My network topology is: vlanguest 192.168.50.0/24 vlan33 192.168.33.0/24 vlan99 192.168.99.0/24 internal subnet 192.168.101.0/24

physical network:

the server / nat router / multicast video server box, has a 4 port bond using an Intel nic (350T), and a 20G bond (netxen nic) over sfp+ cables to my switch (a powerconnect 5524), tagged traffic from my guest network applicances are switched over the 4G bond to the server, and the 33 and 99 vlans go over the 20G bond. vlan99 is where I have my multicast video transmitters and receivers. (I use omxplayer run as a systemd service on raspberry pi's as receivers, both wired and wireless, they work.)

I have one h.264 type broadcaster transmitter (fbe200-h264-lan) pushing the hdmi from my playstation over to multicast group 239.255.42.43 as a test source that isnt' my "video server" as the source . it can be viewed within the same subnet, AND, it can be routed to the other subnets and vlans. it's ttl is 127 (I could likely use 2 or 3, but I'm not too sure if routed hops are always discounted by 1)

On the multi-homed "video server" firewall router computer box thing, I have several "vidstream" gstreamer stream pipelines wrapped in systemd services running, they work. I built a simple web interface to be able to start and stop my stream services, it's all working. I can play video to my receivers in the group when my default multicast interface is the video vlan99.

When I don't specify the default route for the multicast address (either by ip route add 239.255.42.4x, or by using multicast-iface in the udpsink of gstreamer), and it goes out over my internal subnet default, the stream can get routed where it needs to go. Amazing.

The problem is, and this is what I just can't seem to get, is that when I make vlan99's tagged interface the multicast interface using any of the methods described above, the stream does not get routed to the other subnets, I see the ip mroute show the connection from the interface to the group, but the stream does not forward to the port.

Basically I want the vlan99 to be the primary place my video streams go, and then route to the joins from vlan33 and internal but not guest

I have enabled snooping on my switch and can see that the ports are identifying group membership properly... all seems ok there... hosts are all reachable, I have ip forwarding enabled, and an ip tables script doing some nat and forwarding rules, I can drop my firewall and it' doesn't resolve the issues I describe above...

any thoughts? if you made it this far, thanks again!

[rctor]

I've tried various combinations of settings in my

phyint vlan33 enable igmpv3 altnet 192.168.33.0/24 2
phyint vlan199 enable igmpv3 altnet 192.168.99.0/24
phyint internal enable igmpv3 altnet 192.168.101.0/24 2
#phyint vlan2:1 disable
#phyint vlan2:2 disable

#default-route-distance   101      # smaller is better
#default-route-metric     1024     # smaller is better
#hello-interval           30       # Don't set lower than 30

#igmp-query-interval  12
#igmp-querier-timeout 42

# Bigger value means  "higher" priority
bsr-candidate priority 20
#bsr-candidate 192.168.99.1
#bsr-candidate 192.168.99.1
bsr-candidate vlan99
bsr-candidate vlan33
bsr-candidate internal 
# Smaller value means "higher" priority
rp-candidate time 20 priority 1
#rp-candidate 192.168.99.1 
#rp-candidate 192.168.50.3
#rp-candidate 192.168.100.2
# Candidate for being RP of complete IPv4 multicast range
#group-prefix 224.0.0.0 masklen 4
group-prefix 239.255.42.0 masklen 24
# Static rendez-vous point
#rp-address 192.168.101.2 224.0.0.0/4
rp-address 192.168.199.1 239.255.42.0/24
#rp-address 192.168.100.2 239.255.42.0/24
#rp-address 192.168.199.1 224.0.0.0/4
#rp-address 192.168.50.3 239.255.42.0/24
#rp-address 192.168.100.2 239.255.42.0/24

[troglobit]

Hi, I cannot wrap my head around your physical topology, so it's hard for me to suggest anything. You seem to have a good grasp of the basics, so that's a good start.

If you could add an ASCII picture of your desired setup, focusing on one stream and how you'd like that to be routed, that would be much appreciated.

[rctor]

[troglobit]

I think I'm starting to understand. The server is the source itself for the multicast streams you have problem routing, right?

If that's the case it may be that pimd never actually sees the multicast when you select vlan99 as the multicast interface. You can test this by running a ping in one terminal and a tcpdump in another, on the server:

terminal 1:

ping -I vlan99 225.1.23

terminal 2:

tcpdump -lni vlan99 -Q in ip dst 225.1.2.3

As you can see there is no multicast ingressing the interface. Try changing to -Q out and the ICMP packets will now show up.

All multicast routing daemons (pimd, mrouted, SMCRoute) take multicast coming in on an interface and route it to one or more interfaces. The former two rely on IGMP join messages to know where to route it and (statistical sampling of) inbound UDP multicast. Not really sure how you can fix this in your current setup. Maybe if you put vlan99 in a bridge with one end of a veth pair, then pimd would see your multicast video on the other end of that veth pair and be able route it elsewhere.

[rctor]

Yes, exactly, the server sources are the problem ones when I send the streams "into" vlan199 as their default interface. If I use the internal lan interface that isn't a vlan, then everyone gets routed. The trouble is that puts the streams on an interface that isn't the default for the majority of the receivers that will be joining. Thank you very much for your feedback, I've been trying to understand the various aspects of what all needs to happen to get things working as intended (if that's even possible)

I was pondering trying a virtual interface on the bond10g that isn't a vlan and isn't my internal network gatway lan.

[troglobit]

Yup, it's a pickle and you need to find some way to work around it in your topology. Thinking about it, a bridge is probably the way to go. Although I realize now you cannot put the VLAN interface in the bridge, but rather the bond as tagged VLAN member, along with one end of the veth pair ... then you can create the vlan199 interface on top of the bridge instead.

Either way, it's not a problem with pimd so I guess we can close this issue, right?

[rctor]

thanks for your feedback, yes go ahead and close the issue, I will investigate further to try and resolve the issues...

[rctor]

I thought I'd post the fix for my situation, as people often don't, even if it's not the right place for it.

in the end this command: ethtool -K vlan199 tx off rx off was the magic cookie to get routed streams to not have bad udp checksums and show me my video in the intended way.

i found this page: https://sokratisg.net/2012/04/01/udp-tcp-checksum-errors-from-tcpdump-nic-hardware-offloading/

and it magically resolved the problem with routing streams correctly... weird... thanks again bye

[troglobit]

@rctor Interesting! So without this I guess the frames are dropped due to bad checksum then. Good catch!