One of the technologies that I never really mastered was Multicast. I knew the basics but didn’t really know how to troubleshoot it. This is one of the holes in my knowledge that contributed to my last failure of the CCIE Lab Exam.
So in order for that to not happen again I have decided to do a real deep dive into Multicast for CCIE candidates. I am going to be starting with the basics and building on the knowledge ensuring that I cover every detail of the technology.
Now Multicast is not really that difficult to configure, there are only a handful of commands. The problem most people suffer with is that they don’t know how to properly troubleshoot it and when it doesn’t work, they have nowhere to go.
So for this tutorial on the Static RP or Rendezvous Point I will be using the topology below. This is a very simple setup with all routers running OSPF area 0. Each router has a loopback of x.x.x.x where x=router number. The IP addressing is very simple, between router 1 and 2 the addressing is 10.0.12.x and between 2 and 4 it is 10.0.24.x where x=router number.
To test any Multicast topology you are going to need a Server and a Client. Within the scope of the CCIE Lab Exam you will not have a multicast server or client so we have to simulate these. We do this in the following way:
The multicast server will be a dedicated device who will send a ping to the multicast group address. This will simulate a stream of multicast traffic. In our topology R1 is going to be the Multicast server. You do not have to run PIM on R1 as it does not partake in Multicast Routing. R2 will be the RP or Rendezvouz Point and will hear the multicast traffic and register R1 as a source.
Normally a multicast client will be a PC who wants to receive the multicast traffic. Within the CCIE Lab Exam to simulate a multicast client we will use the ip igmp group command. The config on R6 (Client) is below. I have configured the loopback address as the interface to configure the ip igmp group command on.
R6-CLIENT#sh run int lo0 interface Loopback0 ip address 184.108.40.206 255.255.255.255 ip pim sparse-mode ip igmp join-group 220.127.116.11 ip ospf 1 area 0 end
To verify this you can use the sh ip igmp group command
R6-CLIENT#sh ip igmp group IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 18.104.22.168 Loopback0 15:35:47 00:02:36 22.214.171.124 126.96.36.199 Loopback0 15:35:47 00:02:38 188.8.131.52 R6-CLIENT#
Here you can see that the group 184.108.40.206 is joined on lo0 interface.
As a troubleshooting step if I remove the pim configuration from lo0 we can see there is a problem by running the sh ip igmp group command again
R6-CLIENT(config)#int lo0 R6-CLIENT(config-if)#no ip pim sparse-mode R6-CLIENT#sh ip igmp group IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter Group Accounted 220.127.116.11 Loopback0 15:37:00 stopped 18.104.22.168 22.214.171.124 FastEthernet0/0 00:00:06 00:02:53 10.0.65.6 126.96.36.199 Loopback0 15:37:00 00:02:21 188.8.131.52
You can see that under the Expires column that it says stopped. Let put it back and carry on.
I have configured ip pim sparse-mode on every interface of R1,R2,R4,R5 & R6 (R3 will play its part in the next tutorial)
Example interface configuration on R4
R4#sh run int f0/0 interface FastEthernet0/0 ip address 10.0.24.4 255.255.255.0 ip pim sparse-mode ip ospf 1 area 0 duplex auto speed auto end
To verify if the multicast traffic is going to flow we need to verify the patch, you can do this with an mtrace
R6-CLIENT#mtrace 10.0.12.1 Type escape sequence to abort. Mtrace from 10.0.12.1 to 10.0.65.6 via RPF From source (?) to destination (?) Querying full reverse path... 0 10.0.65.6 -1 10.0.65.6 PIM [10.0.12.0/24] -2 10.0.65.5 PIM [10.0.12.0/24] -3 10.0.45.4 PIM [10.0.12.0/24] -4 10.0.24.2 PIM [10.0.12.0/24] -5 10.0.12.1 R6-CLIENT#ping 10.0.12.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.0.12.1, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 84/200/456 ms R6-CLIENT#trace 10.0.12.1 Type escape sequence to abort. Tracing the route to 10.0.12.1 1 10.0.65.5 140 msec 196 msec 32 msec 2 10.0.45.4 164 msec 64 msec 80 msec 3 10.0.24.2 144 msec 96 msec 64 msec 4 10.0.12.1 232 msec * 144 msec R6-CLIENT#
Here you can see that there is a full path all the way up to R1 and the standard trace proves connectivity.
If in the mtrace output there were any failures this would indicate that PIM is not enabled on that particular interface.
So we know we have a multicast path from client to server. The next step is to configure a RP there are three ways of doing this and all routers in the topology must agree on who the RP is.
The three was to configure an RP are:
- Static RP – using the ip pim rp-address command – this has to be configured on every device and can be overridden with a dynamic method.
- Auto-RP – this will be dealt with in a later post
- BSR – this will be dealt with in a later post
To configure a static RP simply add the command ip pim rp-address 184.108.40.206 onto every device inluding the RP itself. The Rendezvouz Point needs to know it is the RP!
The next step is to verify that all routers have this configuration and that everyone agrees on who the RP is.
R2#sh ip pim rp mapping PIM Group-to-RP Mappings Group(s): 220.127.116.11/4, Static RP: 18.104.22.168 (?)
This tells us that R2 is the RP and that is been configured with the ip pim rp-mapping command.
The question mark by RP: 22.214.171.124 (?) just indicates that there is not a DNS entry for 126.96.36.199
You would normally decide on the router closest to the Server to be the RP.
So now that everyone in the topology agrees on the RP and there is a successful mtrace both ways from client to server and server to client we should be able to ping the multicast group address 188.8.131.52 from the server and get a reply from R6
R1-SERVER#ping 184.108.40.206 re 5 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 220.127.116.11, timeout is 2 seconds: Reply to request 0 from 10.0.65.6, 92 ms Reply to request 1 from 10.0.65.6, 76 ms Reply to request 2 from 10.0.65.6, 88 ms Reply to request 3 from 10.0.65.6, 64 ms Reply to request 4 from 10.0.65.6, 112 ms
Success! we have end to end connectivity and can ping the multicast group address 18.104.22.168
If we look on R5 and do a sh ip mroute you can see the (*,G) and (S,G) entries showing the incoming and outgoing interfaces for the multicast group
R5#sh 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, 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 Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 22.214.171.124), 02:26:29/00:02:40, RP 126.96.36.199, flags: S Incoming interface: FastEthernet0/0, RPF nbr 10.0.45.4 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 02:26:29/00:02:40 (10.0.12.1, 188.8.131.52), 00:02:10/00:02:26, flags: T Incoming interface: FastEthernet0/0, RPF nbr 10.0.45.4 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 00:02:10/00:03:18 (*, 184.108.40.206), 02:29:03/00:02:31, RP 220.127.116.11, flags: SJCL Incoming interface: FastEthernet0/0, RPF nbr 10.0.45.4 Outgoing interface list: FastEthernet0/1, Forward/Sparse, 02:26:30/00:02:35
One final thing to look at as the options on the end of the ip pim rp-address command
Going back to R2 our Rendezvouz Point lets look at the options you have for configuration on the RP
R2(config)#ip pim rp-address ? A.B.C.D IP address of Rendezvous-point for group R2(config)#ip pim rp-address 18.104.22.168 ? Access-list reference for group Access-list reference for group (expanded range) WORD IP Named Standard Access list override Overrides dynamically learnt RP mappings
Lets start with override – by default if you have a static RP configured and some dynamic information is learnt via Auto-RP or BSR the dynamic information will override the static configuration. The opposite to unicast routing. If you want your statically configured RP to remain even on receipt of dynamic information just add the override keyword at the end of the configuration e.g
R2(config)#ip pim rp-address 22.214.171.124 override
You also have the option to add an access list to the end of the configuration e.g
R2(config)#ip pim rp-address 126.96.36.199 10
Where 10 references an access list to set a static RP for specific groups.
Static RP for all groups
ip pim rp-address 188.8.131.52
Static RP for specific groups
access-l 10 permit 184.108.40.206 0.255.255.255 ip pim rp-address 220.127.116.11 10
This configures the RP to only be the RP for 18.104.22.168
If you want to force a particular RP for one group but use dynamic methods for others
access-l 10 permit 22.214.171.124 0.255.255.255 ip pim rp-address 126.96.36.199 10 override
In this configuration the RP will be set to 188.8.131.52 for the group 184.108.40.206 and will accept dynamic methods for others.
In the next post we will explore Auto-RP and how to dynamically assign the Rendezvouz Point.