TTL for Now
It’s always the little things that get you in technology. I’ve seen instances of stations taken off air by a simple fuse blowing. You also wouldn’t believe the level of embarrassment that can come from a bad jumper connection.
As you’ve probably guessed, it was a little thing that got me in my latest experiments. I’ve been playing with making multicast work across a couple of subnets on my home network.
To give you an idea of exactly what I was trying to do, here’s a quick diagram of the network I was experimenting with at the time:
For the bits we’re concerned with, there’s two subnets in action – Internal and Guest. The server and one client are on the internal network. The second client is on the guest network.
It’s also worth noting that our switch is managed and the router is really a multilayer device from Mikrotik.
So, let’s get cracking with a basic test – multicast streaming on a single subnet. We enable IGMP on the interface for each subnet by going to Routing –> PIM –> Interface in the menus.
As we’ve got a managed switch as part of our network, we’ll need to enable IGMP snooping and configure the trunk as the link to our multicast router.
As a test source, I’m using VLC relaying a web stream. We can start the multicasting using the following command:
vlc http://streaming.example.com:8000/stream –sout “udp{dst=239.0.0.1,network-caching=2000}”
We can now fire up the VLC client and pull the stream from rtp://@239.0.0.1:5004. Success – we’ve got audio playing out on our client.
With that going, we can now look at the more complicated case. Specifically, we’re wanting to stream across two subnets. To do this we’ll enable PIM across all of our interfaces.
I also configured a rendezvous point on a loopback interface on the router. Admittedly, it’s not really needed (it could be argued if we really need PIM as well) but would allow us to scale out if this works.
We can check the configuration by ensuring all the appropriate protocols are enabled on the router:
/routing pim> interface print
Flags: X – disabled, I – inactive, D – dynamic, R – designated-router,
v1 – IGMPv1, v2 – IGMPv2, v3 – IGMPv3
# INTERFACE PROTOCOLS
0 Rv2 internal-bridge pim
igmp
1 Rv2 visitors-bridge pim
igmp
2 Rv2 loopback0 pim
igmp
3 DR register pim
All good so far. It may also be worth checking the MRIB at this point. After all, you need unicast connectivity before multicast will work.
At this point I fired up the test server again. I can successfully pull the stream on the same subnet. As for the guest network, it’s a different story. The sound of silence.
A packet capture show the IGMP joins leaving the client. I can also confirm they’re getting successfully to the router:
/routing pim> igmp-group print
Flags: v1 – IGMPv1, v2 – IGMPv2, v3 – IGMPv3,
I – include, E – exclude, F – forward, D – don’t forward
INTERFACE GROUP SOURCE TIMEOUT
v2E visitors-bridge 239.0.0.1 0.0.0.0 4m
v2E internal-bridge 239.0.0.1 0.0.0.0 3m54s
The above shows that we’ve got joins from both the visitors and internal networks. They’re IGMP v2 joins and thus not source specific. The 0.0.0.0 confirms this.
Hmm… strange. Let’s take a look at the multicast routes:
/routing pim> join print
Flags: RP – (*,*,RP), WC – (*,G), SG – (S,G), SG_rpt – (S,G,rpt)
GROUP SOURCE RP
SG 239.0.0.1 0.0.0.0 172.16.5.254
SG_rpt 239.0.0.1 172.16.2.4 172.16.5.254
All looks good on both sides. So, why are we not seeing the multicast traffic, and therefore audio on the visitor subnet.
It’s a real head scratcher. At this point I created an allow all firewall rule for the 239.0.0.1 address. The firewall’s seeing nothing go past.
And that’s the point I got to for ages. I was stumped as to how the multicast traffic was simply refusing to work across subnets.
Eventually I asked on the Mikrotik forums for help. That’s when one bright spark pointed out one of the most simple things I can overlook – TTL.
At that point, I fire up the packet capture tool on the internal subnet and watch the multicast stream go by. The packets have a TTL of one by default when streamed from VLC.
That’ll explain why the firewall never saw them. The router had dropped the packets before getting to that stage of the processing.
As you can imagine, setting ttl=100 in the command line arguments for VLC made the stream work across subnets. I also learned yet again that it’s the simple things that will stump you.
