Скачать или смотреть Packet Design's Route Explorer Managing Multicast: PIM Sparse Mode Sanity

PIM Sparse Mode multicast deployments for video and audio broadcasts can be complex. Where do you place Rendezvous Point Routers for shared multicast trees? Do you create multiple Rendezvous Points and allocate them for different multicast channels? What happens when there are network failures or instabilities near critical branches of the multicast tree? These and other questions are easily answered using the Packet Design Multicast Explorer product. In the following video see how the merging of route analytics with multicast tree visualization can help better optimize a customers PIM Sparse Mode Multicast network design.

For more resources, visit: http://packetdesign.com

Multicast has always been a tricky beast. So much so that even attempts to standardize on dynamic routing protocols to help propagate routing information have not had popular adoption. mOSPF and a few others have not really had widespread appeal especially in the enterprise market. As a consequence tools that help manage multicast in large networks have been lacking. If you're one of the lucky network professionals who has had to manage large multicast video and audio networks, this is painfully obvious. What if there was a way to visually track the dynamic nature of a multicast overlay network. How much quicker do you think you could isolate issues with poor video quality or choppy audio reception? In this video, I'll show how to use Packet Design’s multicast monitoring feature. For this scenario, let's assume we are preparing for an important simulcast of a live corporate event which will test by sending a stream from a broadcast location in New York. We have users in the Seattle office or region around there they keep getting periods of dropped audio and sometimes video, but it resolves itself in about 15 minutes. I'll log into the route Explorer Suite using the VNC engineering interface. To start the analysis, I'll now bring up the multicast routing status report. As you can see there's only a couple multicast video streams at the moment. I can see here that the rendezvous point for this network. Normally the multicast traffic flows through that router to reach the client viewers instead of the shared tree path and something is causing a shift from the source tree to the shared tree. I also see what looks like some disconnected tree branches - the gray links. So, something has definitely been causing flows to shift. I can use the mini map to see how some of the disconnected leaf nodes would have normally connected into the tree by using the pull down menu on the disconnected node and choosing to view the RPF IGP or tree path to connect the disconnected leaf back into the shared multicast stream. I can use the multicast path highlighting tool to show the current path of the source specific multicast traffic for the 224.255.14.6 video stream. When I enter the relevant address information for this path profile and press OK, the path is drawn through the Chicago-EE-122 router and then on to the Seattle PoP. I can now animate any path changes by clicking on the play button to see what happens to the path during the next hour or so. During the playback I notice a couple of key links are flapping along the multicast path. One of the links is the primary connection between the Chicago and Seattle office. I also see that the connection to the rendezvous point router the Chicago-PE-121 router, for this flow is unstable which would also adversely affect a shared path tree. This would definitely cause poor video quality. If I was managing this network, I'd consider converting the secondary rendezvous point router in the Dallas PoP to be the primary until the instabilities of the Chicago routers were resolved. There is also another way we could be monitoring the quality of the multicast Network rather than relying on user feedback. Route Explorer will generate alerts for various multicast PIM anomalies. So, a more efficient way of detecting this would have been to have an alert sent when the various PIM neighbors went down. We can also detect and alert the operators should a multicast source stop sending as well. Does this make sense? Can you see how this would be more efficient than using CLI commands and debug complex multicast issues?