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.
Content of the posts
- Any-source multicast (ASM) with static RP
- Any-source multicast (ASM) with auto-RP
- Any-source multicast (ASM) with anycast RP
- Any-source multicast (ASM) with bootstrap router (aka PIMv2)
- Source-specific multicast (SSM)
Including, for each topic:
- A network drawing
- The configuration details.
- The tests and debug outputs.
- When possible, a failover test and debug outputs.
- Some basic troubleshooting.
Any-source multicast (ASM) with bootstrap router (BSR)
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 22.214.171.124 and 126.96.36.199, 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)
On this scenario, we will use the loopback0 of SW-2 as PIMv2 RP and bootstrap router (BSR).
BSR is like AutoRP, but does not use any dense-mode group. Candidates RPs (cRP) propose themselves as RP which is then flooded (RP-Set) to all PIM neighbors inside a bootstrap message (BSM). RP election is based on the higher priority (default = 0) or highest IP address. cRP learn the BSR IP address from the BSM and only 1 RP will be selected per group or group-range.
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 the loopback0 of SW-2. For this, we use the ip pim spare-mode command.
Do not forget to also configure ip multicast-routing, like below:
SW-1,2,3,4: SW-X(config)#ip multicast-routing SW-1,2,3,4: on the ptp interfaces, VLAN10 of SW-1, lo0 of SW-2 and SW-4: SW-X(config-if)#ip pim sparse-mode
Then, we configure the rp-candidate and the bsr-candidate. For the RP, I specify the group 188.8.131.52 with the access-list 11 and the priority to 255:
SW-2#config t Enter configuration commands, one per line. End with CNTL/Z. SW-2(config)#ip pim bsr-candidate lo0 ! SW-2(config)#access-list 11 permit 184.108.40.206 ! SW-2(config)#ip pim rp-candidate lo0 group-list 11 priority 255
Tests and debugging
Before any IGMP join
First, let’s check the RP mapping on the four switches:
SW-X#show ip pim rp mapping PIM Group-to-RP Mappings Group(s) 220.127.116.11/32 RP 18.104.22.168 (?), v2 Info source: 22.214.171.124 (?), via bootstrap, priority 255, holdtime 150 Uptime: 00:03:29, expires: 00:01:43
Now, let’s make an IGMP join for the group 126.96.36.199 on the loopback0 of SW-4.
SW-4#config t SW-4(config)#int lo SW-4(config-if)#ip igmp join-group 188.8.131.52
At this point, exactly as we seen on lab-1, we can see on the multicast routing table of SW-4 that the multicast traffic is coming through SW-3, because it uses shortest-path tree (T flag):
SW-4#show ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group, V - RD & Vector, v - Vector Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 184.108.40.206), 00:01:44/stopped, RP 220.127.116.11, flags: SJCL Incoming interface: GigabitEthernet1/0/2, RPF nbr 10.10.24.2 Outgoing interface list: Loopback0, Forward/Sparse, 00:01:44/00:02:46 (10.10.10.10, 18.104.22.168), 00:01:44/00:01:15, flags: LJT Incoming interface: GigabitEthernet1/0/3, RPF nbr 10.10.34.3 Outgoing interface list: Loopback0, Forward/Sparse, 00:01:44/00:02:46
We can also see traffic statistics with the command: show ip mroute count:
SW-4#show ip mroute count Use "show ip mfib count" to get better response time for a large number of mroutes. IP Multicast Statistics 3 routes using 1544 bytes of memory 2 groups, 0.50 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 22.214.171.124, Source count: 1, Packets forwarded: 34605, Packets received: 34608 RP-tree: Forwarding: 2/0/0/0, Other: 2/0/0 Source: 10.10.10.10/32, Forwarding: 34603/142/355/393, Other: 34606/1/2
Let’s test the following: configure another BSR and RP-candidate on SW-3, with a lowest priority. Then, shutdown the RP on SW-2:
- Configuration of the new BSR and RP candidates on SW-3:
SW-3(config)#ip pim bsr-candidate Loopback0 SW-3(config)#ip pim rp-candidate Loopback0 group-list 11 priority 100
- Check the RP mappings:
SW-4#show ip pim rp map PIM Group-to-RP Mappings Group(s) 126.96.36.199/32 RP 188.8.131.52 (?), v2 Info source: 184.108.40.206 (?), via bootstrap, priority 100, holdtime 150 Uptime: 00:00:34, expires: 00:01:53 RP 220.127.116.11 (?), v2 Info source: 18.104.22.168 (?), via bootstrap, priority 255, holdtime 150 Uptime: 00:13:18, expires: 00:01:53
Now, we have two RP for 22.214.171.124: 126.96.36.199 with a priority of 255 and 188.8.131.52 with a priority of 100.
- Check the BSR-router:
SW-4#show ip pim bsr-router PIMv2 Bootstrap information BSR address: 184.108.40.206 (?) Uptime: 00:01:38, BSR Priority: 0, Hash mask length: 0 Expires: 00:01:31
And now, the BSR is SW-3 instead of SW-2, because of the highest IP address.
- After a shutdown of the Loopback0 of SW-2, to simulate a problem on the RP, we can see on SW-4 we still receive the multicast stream and the RP is now: 220.127.116.11:
SW-4#show ip pim rp mapping PIM Group-to-RP Mappings Group(s) 18.104.22.168/32 RP 22.214.171.124 (?), v2 Info source: 126.96.36.199 (?), via bootstrap, priority 100, holdtime 150 Uptime: 00:12:37, expires: 00:01:42 ! SW-4#show ip pim rp Group: 188.8.131.52, RP: 184.108.40.206, v2, uptime 00:12:39, expires 00:01:40 ! SW-4#show ip mroute count Use "show ip mfib count" to get better response time for a large number of mroutes. IP Multicast Statistics 3 routes using 1544 bytes of memory 2 groups, 0.50 average sources per group Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc) Group: 220.127.116.11, Source count: 1, Packets forwarded: 189159, Packets received: 189162 RP-tree: Forwarding: 2/0/0/0, Other: 2/0/0 Source: 10.10.10.10/32, Forwarding: 189157/143/345/393, Other: 189160/1/2
As we can see, we can create RP redundancy with BSR.
Most of the troubleshooting and debugging methods are similar as the multicast lab-1. Please refer to the multicast lab-1.