Multicast is by no means a new technology, but it’s amazing how long we’ve managed to resist implementing it - or at least implementing it properly - on our networks.

If all you need is local multicast within a VLAN, then you don’t need to do anything -the switches will get the traffic to where it needs to go. Of course, they may do it by treating the packets as if they were broadcasts and just flooding them everywhere, but hey, your LAN bandwidth is cheap, isn’t it?

If you want a bit more control, or want to pass multicasts between subnets and across your WAN, then you will need to do a bit more config work. And with the amount and variety of multicast traffic you’re likely to be faced with these days, just configuring up dense-mode PIM isn’t going to be good enough.

So where is all this multicast traffic coming from? Software distributions, applications such as TIBCO Rendezvous, now fairly extensively used in finance houses, and video streaming all have different requirements in terms of criticality, bandwidth and response times, and all need to be catered for appropriately. And while it’s vital that the traffic gets to the receivers that need it, it’s also important that it doesn’t go to parts of the network that have no business receiving it.

Multicast Mechanisms
What are the options for configuring multicast on your LANs and WANs, which is best for you, and what does the future hold in terms of performance improvements?

We’re just going to talk about PIM (Protocol Independent Multicast) here, because to be honest, it’s the only one that really scales, unlike MOSPF or DVMRP, so nearly every multicast network you see will—or should be—running a version of PIM. That said, there are still a few options to choose from.

As soon as you need to start verifying and troubleshooting a multicast setup, turn everything you know about normal IP routing on its head and think backwards.

PIM uses the router’s unicast routing tables to build its multicast forwarding paths, so the first thing to make sure of when you’re checking your multicast traffic flows is that all your unicast traffic is flowing exactly as you’d expect, and all routes are present and correct. Don’t even bother looking at multicast until you can be sure of that, because if your unicast traffic isn’t right, there is no hope for the multicast.

Once you are happy that the unicast side of things is fine, you can start to look at multicast.

RPF
In unicast forwarding, the routers figure out the best path from themselves to the destination, without caring too much about the source address. But in multicast, the routers are sending to a group rather than a specific destination. A multicast router has to determine which direction is upstream, towards the source, and which directions are downstream, away from the source, and towards all possible destinations. Rather than sending data towards a receiver, it actually sends it away from the source—a mechanism known as Reverse Path Forwarding, and which is fundamental to the operation of multicast.

The router uses the unicast routing table to identify the upstream interface---i.e. the route back to the source—and will forward traffic out of the other interfaces. To make sure that there no loops formed, it will only forward a packet if it received it on the correct upstream interface—in other words, if it receives a multicast packet from a source 192.168.251.17/24, then it will only forward it on if the interface it received that packet on was the one with the best route back to (reverse path back to) network 192.168.251.0/24. Otherwise it will figure out that the packet has looped round someplace to be coming from the wrong direction and discard it. This check that the router does is known as the RPF check.

So in order to confirm that traffic is doing what it should be, work backwards. Rather than starting at a source router and looking at routes through the network to see if they are heading in the expected direction, start at the receiver. Make sure that it is receiving state information on the correct group from the direction you expect and follow that path back through the network to make sure you get back to the source you want. RPF check failure is probably the biggest cause of multicast problems.

As we’ve said, the use of Auto-RP requires a form of dense mode to be configured on the interfaces pointing towards the parts of the network where the candidate RPs reside. If for any reason a router cannot locate an RP, the default behaviour is for the router to revert to dense mode for the multicast group traffic also, to ensure that its receivers will continue to receive data. To avoid this, the first action is obviously to have redundant RPs. However, as a back up it is recommended that a dummy RP address be configured into the router as a final option—an RP of last resort. This won’t affect the Auto-RP operation, as static RPs take a lower precedence that those found via Auto-RP. The RP address should just be a fictitious IP address as it will never actually be used, but it will stop dense-mode flooding should the RPs be lost, or, more likely, a strange multicast source appearing on the network for a group that your real RPs aren’t catering for.

Other issues
If your multicast stream isn’t appearing where it should be, check that all your PIM neighbourships have formed between adjacent routers as expected. If this looks okay, then have a look at active flows on the source router, and then follow those flows through the routers in the path to find out where it stops—could the TTL of the flow be too low coming out of the source application, so that it doesn’t make it through the network?

If you want to run multicast over a Service Providers WAN, you may have another raft of potential problems. If the provider hasn’t multicast-enabled its service, then the multicast traffic will have to be tunnelled. This adds overhead and management complexity for them—and hence cost for you.

MPLS is an ideal example. The technology to support multicast VPNs over MPLS is very new, so only a couple of vendors support it. The rest rely on tunnelling, and unless you have a pretty small hub and spoke site setup, they won’t want to know. So if you’re looking at doing this sort of thing, quiz your suppliers very carefully to find out just what they can and can’t offer—and at what extra price.

Multicast is a mainstream application now, and you will be expected to be able to provide a network to support it. Plan carefully, know how it should all work when everything’s in its ideal state, and you’ll find it’s not too much of a nightmare to troubleshoot when you need to.