Basic MSDP configuration

This is a short MSDP scenario designed to get familiar with the command to enable it and where you would use it. Below is the toplogy.


There are two domains, each with an RP. We seperate the domains by using the following commands on R3 and R4:

R3(config)#int s1/1
R3(config-if)#ip pim bsr-border

R4(config)#int s1/0
R4(config-if)#ip pim bsr-border

R2 and R4 have already been configured as the BSR and RP's for their respective domains. Let's verify on R1 and R5:

R1#sho ip pim rp mapping
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 2.2.2.2 (?), v2
Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150
Uptime: 18:21:34, expires: 00:02:13

R5#sho ip pim rp map
PIM Group-to-RP Mappings

Group(s) 224.0.0.0/4
RP 4.4.4.4 (?), v2
Info source: 4.4.4.4 (?), via bootstrap, priority 0, holdtime 150
Uptime: 18:19:56, expires: 00:01:52

R1 and R8 have already joined group 225.0.0.1. Let's see what happens when R6 sends a ping to this group:

R6#ping 225.0.0.1 re 10

Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 225.0.0.1, timeout is 2 seconds:

Reply to request 0 from 192.168.78.8, 192 ms
Reply to request 1 from 192.168.78.8, 192 ms
Reply to request 2 from 192.168.78.8, 100 ms
Reply to request 3 from 192.168.78.8, 84 ms
Reply to request 4 from 192.168.78.8, 112 ms
Reply to request 5 from 192.168.78.8, 104 ms

Only R8 responds. This is because the PIM joins from Domain 1 never get sent to the RP in Domain 2. Thus R4 never knows to forward to R3. Let's configure MSDP between R2 and R4:

R2(config)#ip msdp peer 4.4.4.4 connect-source loopback 0

R4(config)#ip msdp peer 2.2.2.2 connect-source loopback 0

It may take a moment but we will see this message:

*Mar 1 19:56:14.343: %MSDP-5-PEER_UPDOWN: Session to peer 2.2.2.2 going up

If we debug we would see this:

R4#debug ip msdp de
MSDP Detail debugging is on

*Mar 1 19:56:15.263: MSDP(0): Received 3-byte TCP segment from 2.2.2.2
*Mar 1 19:56:15.263: MSDP(0): Append 3 bytes to 0-byte msg 1170 from 2.2.2.2, qs 1
*Mar 1 19:56:15.643: MSDP(0): Sent entire mroute table, mroute_cache_index = 0, Qlen = 0
*Mar 1 19:56:15.647: MSDP(0): start_index = 0, sa_cache_index = 0, Qlen = 0
*Mar 1 19:56:15.651: MSDP(0): Sent entire sa-cache, sa_cache_index = 0, Qlen = 0
*Mar 1 19:56:16.275: MSDP(0): Received 3-byte TCP segment from 2.2.2.2
*Mar 1 19:56:16.275: MSDP(0): Append 3 bytes to 0-byte msg 1171 from 2.2.2.2, qs 1

Notice that R4 sent R2 its entire mroute table. Let's check the mroute table on R2:

R2#sho ip mroute 225.0.0.1 | be \(\*
(*, 225.0.0.1), 00:04:59/00:03:27, RP 2.2.2.2, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Serial1/0, Forward/Sparse, 00:04:59/00:03:27

(192.168.56.6, 225.0.0.1), 00:01:47/00:01:12, flags: M
Incoming interface: Serial1/1, RPF nbr 192.168.23.3
Outgoing interface list:
Serial1/0, Forward/Sparse, 00:01:47/00:03:27

R2 now knows about the source of R6 and has even populated its OIL. The M flag tells us this is an MSDP created entry. Let's ping from R6:

R6#ping 225.0.0.1 re 5

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 225.0.0.1, timeout is 2 seconds:

Reply to request 0 from 192.168.78.8, 188 ms
Reply to request 0 from 192.168.12.1, 284 ms
Reply to request 0 from 192.168.12.1, 268 ms
Reply to request 1 from 192.168.12.1, 132 ms
Reply to request 1 from 192.168.78.8, 184 ms
Reply to request 2 from 192.168.12.1, 132 ms
Reply to request 2 from 192.168.78.8, 132 ms
Reply to request 3 from 192.168.12.1, 100 ms
Reply to request 3 from 192.168.78.8, 100 ms
Reply to request 4 from 192.168.12.1, 96 ms
Reply to request 4 from 192.168.78.8, 100 ms

Well that's it for now. You can have more complex scenarios with multiple domains (DocCD says MBGP is required for that) but the basics are easy to get down.