The Lab of the Real World
I don’t know if it is coincidence or not, but it seems to happen often enough that I’m beginning to wonder. It seems like I will get ready to study something for an exam and then all of a sudden there is a need for me to practice this skill in the real world, often before I even get a chance to study it or practice it in the lab. Real life can be funny like that…it often just doesn’t respect training schedules enough to wait until I am on the right chapter! Today, I ended up spending most of the afternoon helping TAC and another engineer troubleshoot issues he was having with a multicast configuration. Sometimes just having a fresh pair of eyes on a problem can help. It also helped a ton that we got one of those great TAC engineers that not only is great at troubleshooting but also enjoys teaching. Needless to say, I learned a lot about multicast today that I might not have picked up so well from just reading a book or a nice clean lab environment…let me try to sum it up.
1. Make sure your RP is reachable from all the parts of the network that the multicast group will need to reach. In our case, the loopback interface being used for the RP was not being advertised in OSPF. This is a pretty quick showstopper!
2. Make sure ALL layer 3 interfaces that the multicast traffic might need to pass are configured for your PIM mode. This includes vlan interfaces as well.
3. Watch out for static mroute entries on switches. These can be just as insidious as regular static routes and can be just as tough to weed out of the network. If your RP is advertised correctly by your routing protocol, then you should not need a static mroute statement and should avoid them like the plague.
4. Static RP statements are a different story. I can’t remember if we had these on our ASR’s, but we did find it necessary to update them on the other switches for the group to appear in a “show ip pim mroute.”
I got some good links from the TAC engineer and a glowing recommendation for the “Developing IP Multicast Networks Vol. 1″ book from Cisco Press. He says at RTP they pretty much regard it as the multicast bible. Add another one to my Amazon wish list. I’ll add those links to this post tomorrow as well as add them to the CCNP section. The best thing I got out of this, though, was some good practice time making something work and a chance to help out a teammate. Now, time to sleep…
oooo Yummy Mcast!
In labs I usually make a habit of just throwing the PIM mode on well, everything lol. Usually you can just get away with it unless it states otherwise. Probably not best in real world, but those are two different things.
A lo interface is pretty common for an RP, for a few reasons. I personally think its good practice for the entire network to reach loopbacks anyway (for management purposes), so its something that you can forget to do if thats not already present on a network.
Hmmm…if multicast always works the way it should, shouldn’t it prune traffic only to those links that have subscribers to the group downstream? This would seem to mean that it would be fine to put the PIM mode on any interface unless you specifically don’t want multicast traffic going down it, even if it is a path to a subscriber…
There you go again, Rob…making me think!
Yup, that is essentially what PIM does, and why I usually just throw it everywhere. The reason I say it probably isn’t best to do that in the real world, as large networks would be a hassle if you only need Mcast in certain parts of it. Also, its probably a security risk (like everything seems to be lol) to have it where you won’t need it/want it.