- Overview :
Anycast RP is a mechanism to provide fast RP failover (primary goal) and RP load-sharing. Idea is to get (at least) 2 routers playing the role of RP simultaneously...
- Principles :
To achieve fast failover, we should use the same IP address on all RPs. This way, we don't have the slowness of Auto-RP or BSR to advertise a new RP address. All RPs are then configured with the same IP address (classically on a loopback) and this address is advertised in the IGP (typically as external route to be able to play easily with metric). Each multicast router uses the closest RP, i.e. lower IGP cost. There are then several shared trees per group, one per RP. We should get a way to 'interconnect' these shared trees to ensure all receivers could receive all streams. This is exactly same situation when running multicast between different Autonomous Systems, i.e. each AS gets its own RP/shared tree. It's reason why AnyCast RP uses same mechanism as interAS multicast, namely MSDP (Multicast Source Discovery Protocol). This protocol is run between RPs and advertises some SA (Source Active) messages when a source is active. That way, all RPs are aware of the active sources and can join the SPT to receive directly the stream.
- Example :
example below the different steps when using Anycast RP :
 |
|
When the source starts generating the stream :
- First-hop router registers the stream to the closest RP, in this case RP1. The Register message contains the encapsulated multicast packet
- RP1 advertises to RP2 via an MSDP SA message that there is an active source 'S' for the group 'G'. The first SA message contains the encapsulated multicast packet (subsequent SA messages don't)
- If RP2 has a receiver for group 'G' (as it's the case here), it joins SPT of the source 'S' by sending an (S,G) join towards the source
- RP2 forwards on its shared tree the multicast packet it receives in SA message
- when last-hop router receives the multicast packet, it joins the SPT (assuming it uses default SPT threshold)
N.B. MSDP SA messages are generated periodically (evrery 1 min) as long as source is active.
Of course, we end up with the same multicast topology as if there was a single RP :
With Anycast RP, RP failover depends only on IGP convergence 
RP convergence = IGP convergence
In our example, if RP1 fails, there is only one route left for the RP address pointing to RP2 and so all routers use RP2 as RP. There is only one shared tree (green) and all multicast operations are fully restored as soon as IGP has converged.
N.B. SPT are not impacted by RP failover so multicast streams already flowing through SPT are NOT impacted !
- Configuration :
| (config)#ip msdp peer <peer-IP-addr> [connect-source] [remote-as] |
- peer-IP-addr : address of other RP(s). Need one command per other RP(s)
- connect-source : interface used as source IP for MSDP packets. Typically a loopback.
- remote-as : AS number of MSDP peer. Not used for Anycast RP (all peers are in same AS)
| (config)#ip msdp mesh-group <group-name> <peer-IP-addr> |
- group-name : name of MSDP peer group
- peer-IP-addr : address of a member of the MSDP peer group. We need one command per mesh-group member.
- Configuration examples :
- with 2 RPs :
| RP1 | RP2 |
|---|---|
interface Loopback0 ! interface Loopback1 | interface Loopback0 ip address 192.168.2.101 255.255.255.255 ! interface Loopback1 |
N.B. important to force IGP routerID when using Anycast RP to make sure common loopback is not picked up
- with 4 RPs :
| RP1 | RP2 |
|---|---|
interface Loopback0 ip address 192.168.2.100 255.255.255.255 ip msdp mesh-group ANYCAST-RP 192.168.2.101 ! | interface Loopback0 ip address 192.168.2.101 255.255.255.255 ip msdp peer 192.168.2.102 connect-source Loopback0 |
| RP3 | RP4 |
|---|---|
interface Loopback0 ip address 192.168.2.102 255.255.255.255 ip msdp peer 192.168.2.101 connect-source Loopback0 ! | interface Loopback0 ip msdp peer 192.168.2.101 connect-source Loopback0 ! |
- Outputs examples :
- On RP which receives the PIM Register (SA Originator) :
RP1#sh ip mroute 225.1.1.1
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
(*, 225.1.1.1), 00:00:31/stopped, RP 172.16.1.100, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(10.1.1.100, 225.1.1.1), 00:00:31/00:02:31, flags: PA
Incoming interface: Serial2/0, RPF nbr 192.168.1.5
Outgoing interface list: Null
RP1#
- On RP receiving the SA message :
RP2#sh ip mroute 225.1.1.1
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
(*, 225.1.1.1), 06:05:30/00:03:15, RP 172.16.1.100, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/0, Forward/Sparse-Dense, 06:05:30/00:03:15
(10.1.1.100, 225.1.1.1), 00:00:19/00:02:53, flags: PMT
Incoming interface: Ethernet1/0, RPF nbr 192.168.1.14
Outgoing interface list: Null
RP2#
- Packet capture of an MSDP SA message :
| MSDP SA message |
|---|
| Ethernet II, Src: aa:bb:cc:00:68:00, Dst: aa:bb:cc:00:69:00 Destination: aa:bb:cc:00:69:00 (aa:bb:cc:00:69:00) Source: aa:bb:cc:00:68:00 (aa:bb:cc:00:68:00) Type: IP (0x0800) Internet Protocol, Src Addr: 192.168.2.100 (192.168.2.100), Dst Addr: 192.168.2.5 (192.168.2.5) Version: 4 Header length: 20 bytes Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00) 1100 00.. = Differentiated Services Codepoint: Class Selector 6 (0x30) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 160 Identification: 0x478c (18316) Flags: 0x00 .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 255 Protocol: TCP (0x06) Header checksum: 0xed51 (correct) Source: 192.168.2.100 (192.168.2.100) Destination: 192.168.2.5 (192.168.2.5) Transmission Control Protocol, Src Port: 639 (639), Dst Port: 13998 (13998), Seq: 3451840662, Ack: 3280286093, Len: 120 Source port: 639 (639) Destination port: 13998 (13998) Sequence number: 3451840662 Next sequence number: 3451840782 Acknowledgement number: 3280286093 Header length: 20 bytes Flags: 0x0018 (PSH, ACK) 0... .... = Congestion Window Reduced (CWR): Not set .0.. .... = ECN-Echo: Not set ..0. .... = Urgent: Not set ...1 .... = Acknowledgment: Set .... 1... = Push: Set .... .0.. = Reset: Not set .... ..0. = Syn: Not set .... ...0 = Fin: Not set Window size: 15910 Checksum: 0xd2e0 (correct) Multicast Source Discovery Protocol Type: IPv4 Source-Active (1) Length: 120 Entry Count: 1 RP Address: 172.16.1.100 (172.16.1.100) (S,G) block: 10.1.1.100/32 -> 225.1.1.1 Reserved: 0x000020 Sprefix len: 32 Group Address: 225.1.1.1 (225.1.1.1) Source Address: 10.1.1.100 (10.1.1.100) Encapsulated IPv4 packet: 100 bytes Internet Protocol, Src Addr: 10.1.1.100 (10.1.1.100), Dst Addr: 225.1.1.1 (225.1.1.1) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 0000 00.. = Differentiated Services Codepoint: Default (0x00) .... ..0. = ECN-Capable Transport (ECT): 0 .... ...0 = ECN-CE: 0 Total Length: 100 Identification: 0x0028 (40) Flags: 0x00 .0.. = Don't fragment: Not set ..0. = More fragments: Not set Fragment offset: 0 Time to live: 254 Protocol: ICMP (0x01) Header checksum: 0xcf09 (correct) Source: 10.1.1.100 (10.1.1.100) Destination: 225.1.1.1 (225.1.1.1) Internet Control Message Protocol Type: 8 (Echo (ping) request) Code: 0 Checksum: 0x3e41 (correct) Identifier: 0x0004 Sequence number: 0x0000 Data (72 bytes) 0000 00 00 00 00 04 f9 3b 0c ab cd ab cd ab cd ab cd ......;......... 0010 ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd ................ 0020 ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd ................ 0030 ab cd ab cd ab cd ab cd ab cd ab cd ab cd ab cd ................ 0040 ab cd ab cd ab cd ab cd ........ |
ok, I don't know what could be the issue, diagrams in both docs are light jpeg files.
I'm adding the first diagram below, do you see it ?
Thx,
Fabrice
