Thursday, November 22, 2012

MSDP & Anycast RP

Anycast RP is a pretty "easy" topic, but it has a gotcha I'd forgotten about.

Anycast RP allows RP load balancing inside a single AS by advertising the same IP in multiple spots in the domain, and then announcing that IP as the RP.  Those wishing to receive their respective multicast feeds just need to join the closest RP determined by the IGP's metric.

Of course the multicast sources don't know about all this extra-RP craziness we're doing.  So we need to tie all the RPs together in full-mesh with MSDP.  MSDP will share information on the sources with each other RP.

The config for this is simple enough that I'm not going to bother with a diagram.

Let's say R1 and R2 are our RPs.  They're both in the same IGP and AS.  All IP addresses are advertised by the IGP.

R1:
Interface Loopback0
 ip address 1.1.1.1 255.255.255.255

Interface Loopback1
 ip address 100.100.100.100 255.255.255.255

ip pim bsr-candidate Lo0
ip pim rp-candidate Lo1

ip msdp peer 2.2.2.2 connect-source Loopback0

R2:
Interface Loopback0
ip address 2.2.2.2 255.255.255.255

Interface Loopback1
ip address 100.100.100.100 255.255.255.255

ip pim rp-candidate Lo1

ip msdp peer 1.1.1.1 connect-source Loopback0

This config looks great, but it's potentially got a fatal flaw.  Unfortunately you have to turn on a  debug to find it.

R1:
debug ip msdp peer

R3 (connected closer to R2 than R1):
ping 239.1.1.17

R2:
R2#show ip mroute 239.1.1.17
<output omitted>
(*, 239.1.1.17), 00:00:16/stopped, RP 100.100.100.100, flags: SP
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list: Null

(192.168.23.3, 239.1.1.17), 00:00:16/00:02:50, flags: PTA
  Incoming interface: Serial0/1/0, RPF nbr 192.168.23.3
  Outgoing interface list: Null
OK, so R2 heard R3's ping and created an (S,G) entry.  So now R1 should insert that same (S,G).
Back to that debug on R1:

*Mar  2 00:06:44.902: MSDP(0): 2.2.2.2: Received 56-byte msg 133 from peer
*Mar  2 00:06:44.902: MSDP(0): 2.2.2.2: SA TLV, len: 56, ec: 4, RP: 100.100.100.100
*Mar  2 00:06:44.902: MSDP(0): 2.2.2.2: Peer RPF check failed for 100.100.100.100, we are RP
We have an RPF failure.  Why?  Because the MSDP originator ID is used as a loop prevention mechanism, and it's taken from the highest IP on the router - which in our case, is Lo1, and Lo1 is the same on both devices because we're attempting to run Anycast RP.

R1 & R2:
ip msdp originator-id Loopback 0

Now we have a unique originator ID.  The same process again:

*Mar  2 00:14:27.533: MSDP(0): 2.2.2.2: Received 120-byte msg 151 from peer
*Mar  2 00:14:27.533: MSDP(0): 2.2.2.2: SA TLV, len: 120, ec: 1, RP: 100.100.100.100, with data
*Mar  2 00:14:27.533: MSDP(0): 2.2.2.2: Peer RPF check passed for 100.100.100.100, peer is RP
It's something of a bummer that this issue isn't at a higher warning level and logged to console by default.  It's not like most of us are in the habit of building Anycast RP configs every day, and remembering this obscure detail can be challenging. 

Jeff Kronlage

1 comment:

  1. Good Pointer there! It is quite hidden and many overlook this small detail!! Well Done Jeff

    ReplyDelete