Multicast lab 1: Any-Source Multicast with static RP

After giving a two-days training to a customer on multicast technology, I take the opportunity to have my lab and the configurations ready to share with you a suite of five different multicast configurations examples. And, how to make some tests and troubleshooting. These examples are based on the labs I used to practice the CCIE R&S practical exam.

Any-source multicast (ASM) with static RP

Lab design and description

The network design is the same for every scenario:

I use four layer-3 Cisco 3650 catalyst switches running IOS-XE. With layer-3 ptp interfaces between them to create a small layer-3 network. OSPF is running between the switches to advertise all the networks: the ptp networks, the loopback0 interfaces and the VLAN10 of SW-1, where is the multicast source.

For the multicast source, I use a laptop running two VLC instances, sending video stream traffic to 233.1.2.3 and 234.1.2.3, both on port 30’001.

The receiver will be simulated by the loopback0 interface of SW-4.

(Click on the image to see a larger version)

This scenario is quite simple: the PIM configuration is done with PIMv1 and static-RP.

The loopback0 interface of SW-2 is the static RP. There is a faster bandwidth on the links SW1 – SW3 – SW4 comparing to SW1 – SW2 – SW4, to demonstrate later how the multicast traffic will switch from shared-tree to source-tree.

Configuration

First, we need to configure PIM on the interfaces between the four switches, on the interface where is source is located (VLAN10 of SW-1), the interface of the clients or receivers (in this case, the loopback0 of SW-4) and on the RP interface (loopback0 of SW-2). For this, we use PIM sparse-mode:

SW-1,2,3,4: on the ptp interfaces, VLAN10 of SW-1, lo0 of SW-2, and lo0 of SW-4:
ip pim sparse-mode

Now, we must configure multicast-routing and the static RP, on the four switches:

Here, we can see the source-tree (10.10.10.10, 234.1.2.3) have SW-1 (Gi1/0/1) as incoming interface. In this situation, the RP know the address of the multicast source (10.10.10.10) for the group 234.1.2.3, by maintaining a source-tree from the source to the RP.

For the shared-tree (*, 234.1.2.3), there is no incoming and outgoing interface. This is normal, because we have no receiver who has joined this group yet.

Note: at this moment, the multicast-routing table of SW-3 and SW-4 are empty.

IGMP join

Now, let’s make an IGMP join for the group 234.1.2.3 on the loopback0 of SW-4.

Shared tree to Source tree

Why the multicast traffic is coming through SW-3? Because the traffic already switched to source-tree (shortest path tree). And the shortest path from the receiver to the source is: SW4 – SW3 – SW1. Let’s control this with the command: show ip rpf <source> and show ip route <source>

The switch from shared to source tree happens upon the arrival of the first data packet at the last hop router. This switch occurs because the ippimspt-threshold command controls that timing, and its default setting is 0 kbps. So, in theory, just after the IGMP join, the multicast traffic was using the shared-tree from the RP to the receiver (SW2 to SW4). Then, it switched to source-tree (shortest path tree).

We can prevent this by using the command: ip pim spt-threshold infinity

Troubleshooting

RPF checks

The most common reasons for multicast problems are related to RPF. Because PIM is not enabled on all the needed interfaces, or PIM is not enabled on all the links running the IGP, or the PIM neighbor are not forming an adjacency because of an NBMA link or an ACL, for example. And this may create RPF failure.

RPF checks are used at the control and date planes of multicast routing; some PIM control-plane messages are subject to RPF checks and data-plane RPF checks are done every time a multicast data packet is received. The source IP address in the packet should be reachable via the receiving interface. It may be the real multicast source IP, like in shortest path tree, or the RP IP address, like in shared tree.

RP

If you use static-RP, add the “override” argument at the end of the RP configuration.

Be as specific as possible on the RP or SSM range definition: add an ACL to limit your groups/channels.

ICMP Ping to multicast group with static IGMP join

One very quick method to check your multicast configuration is to make a static IGMP join of the multicast group on the router close to your receivers, and then send an ICMP ping from the router close to the source, towards the IP of the multicast group. The “client” router must answer, also the clients who joined this group:

The Author

Jerome Tissieres is a multi-vendor certified network systems engineer with over 20 years of successful experience in building and operating enterprise, services providers and data-center IP networks.Jerome has also been chosen to be a 2019 Cisco Champion!

Pin It on Pinterest

Notice: This website or its third-party tools use cookies, which are necessary to its functioning and required to achieve the purposes illustrated in the privacy policy.
By closing this banner, clicking a link or continuing to browse otherwise, you agree to the use of cookies.Ok