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:

Multicast Network Structure

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.

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *