Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

RP Redundancy with PIM SM - Anycast RP

  • 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 :

Any-Prin1.jpg
  • There are 2 RPs for the same group, they use same IP address
  • MSDP is running between the 2 RPs
  • Receivers on the left have a shorter path towards RP1so they are connected to the shared tree (in red) of RP1
  • Receiver on the right is closer to RP2 so it's connected to the shared tree (in green) of RP2  

    When the source starts generating the stream :

    Any-Prin2.jpg

    1. First-hop router registers the stream to the closest RP, in this case RP1. The Register message contains the encapsulated multicast packet
    2. 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)
    3. 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
    4. RP2 forwards on its shared tree the multicast packet it receives in SA message
    5. 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 :

    Any-Prin3.jpg

    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.

    Any-Prin4.jpg

    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)

    More than 2 RPs: When there is a single MSDP peer configured, there is no RPF check against the SA message (we accept them all). On the other hand, when we have more than 2 MSDP peers, MSDP does by default an RPF check against the SA originator-ID. This RPF check mainly relies on BGP information (used in interAS multicast) which are not available in the case of Anycast RP so we should skip this RPF check. Way to avoid this check is to put all MSDP peers in a single mesh-groups. Idea of MSDP mesh-group is to have full meshed MSDP sessions between all members so all SA messages are received directly and they don't need to be propagated (same philosophy than iBGP). This way, mesh groups avoid potential looping problem and it's reason why MSDP RPF check is disabled for SA message coming from another member of the peer-group :

    (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
      ip address 192.168.2.100 255.255.255.255

    !

    interface Loopback1
      ip address 172.16.1.100 255.255.255.255
      ip pim sparse-mode
    !
    route-map CONNECTED permit 10
             match ip address ANYCAST-LOOP
    !
    ip access-list standard ANYCAST-LOOP
      permit 172.16.1.100
    !
    router ospf 1
      router-id  192.168.2.100
      redistribute connected subnets metric-type 1 route-map CONNECTED
    !
    ip msdp peer 192.168.2.101 connect-source Loopback0
    !
    ip pim rp-candidate Loopback1

    interface Loopback0

    ip address 192.168.2.101 255.255.255.255

    !

    interface Loopback1
      ip address 172.16.1.100 255.255.255.255
      ip pim sparse-mode
    !
    route-map CONNECTED permit 10
    match ip address ANYCAST-LOOP
    !
    ip access-list standard ANYCAST-LOOP
      permit 172.16.1.100
    !
    router ospf 1
      router-id  192.168.2.101
      redistribute connected subnets metric-type 1 route-map CONNECTED
    !
    ip msdp peer 192.168.2.100 connect-source Loopback0
    !
    ip pim rp-candidate Loopback1

    N.B. important to force IGP routerID when using Anycast RP to make sure common loopback is not picked up

      • with 4 RPs :

    RP1RP2

    interface Loopback0

      ip address 192.168.2.100 255.255.255.255
    !
    interface Loopback1
      ip address 172.16.1.100 255.255.255.255
      ip pim sparse-mode
    !
    route-map CONNECTED permit 10
      match ip address ANYCAST-LOOP
    !
    ip access-list standard ANYCAST-LOOP
      permit 172.16.1.100
    !
    router ospf 1
      router-id  192.168.2.100
      redistribute connected subnets metric-type 1 route-map CONNECTED
    !
    ip msdp peer 192.168.2.101 connect-source Loopback0
    ip msdp peer 192.168.2.102 connect-source Loopback0
    ip msdp peer 192.168.2.103 connect-source Loopback0

    ip msdp mesh-group ANYCAST-RP 192.168.2.101
    ip msdp mesh-group ANYCAST-RP 192.168.2.102
    ip msdp mesh-group ANYCAST-RP 192.168.2.103

    !
    ip pim rp-candidate Loopback1

    interface Loopback0

      ip address 192.168.2.101 255.255.255.255
    !
    interface Loopback1
      ip address 172.16.1.100 255.255.255.255
      ip pim sparse-mode
    !
    route-map CONNECTED permit 10
      match ip address ANYCAST-LOOP
    !
    ip access-list standard ANYCAST-LOOP
      permit 172.16.1.100
    !
    router ospf 1
      router-id  192.168.2.101
      redistribute connected subnets metric-type 1 route-map CONNECTED
    !
    ip msdp peer 192.168.2.100 connect-source Loopback0

    ip msdp peer 192.168.2.102 connect-source Loopback0
    ip msdp peer 192.168.2.103 connect-source Loopback0
    ip msdp mesh-group ANYCAST-RP 192.168.2.100
    ip msdp mesh-group ANYCAST-RP 192.168.2.102
    ip msdp mesh-group ANYCAST-RP 192.168.2.103
    !
    ip pim rp-candidate Loopback1

    RP3RP4

    interface Loopback0

      ip address 192.168.2.102 255.255.255.255
    !
    interface Loopback1
      ip address 172.16.1.100 255.255.255.255
      ip pim sparse-mode
    !
    route-map CONNECTED permit 10
      match ip address ANYCAST-LOOP
    !
    ip access-list standard ANYCAST-LOOP
      permit 172.16.1.100
    !
    router ospf 1
      router-id  192.168.2.102
      redistribute connected subnets metric-type 1 route-map CONNECTED
    !
    ip msdp peer 192.168.2.100 connect-source Loopback0

    ip msdp peer 192.168.2.101 connect-source Loopback0
    ip msdp peer 192.168.2.103 connect-source Loopback0
    ip msdp mesh-group ANYCAST-RP 192.168.2.100
    ip msdp mesh-group ANYCAST-RP 192.168.2.101
    ip msdp mesh-group ANYCAST-RP 192.168.2.103

    !
    ip pim rp-candidate Loopback1

    interface Loopback0
      ip address 192.168.2.103 255.255.255.255
    !
    interface Loopback1
      ip address 172.16.1.100 255.255.255.255
      ip pim sparse-mode
    !
    route-map CONNECTED permit 10
      match ip address ANYCAST-LOOP
    !
    ip access-list standard ANYCAST-LOOP
      permit 172.16.1.100
    !
    router ospf 1
      router-id  192.168.2.103
      redistribute connected subnets metric-type 1 route-map CONNECTED
    !
    ip msdp peer 192.168.2.100 connect-source Loopback0

    ip msdp peer 192.168.2.101 connect-source Loopback0
    ip msdp peer 192.168.2.102 connect-source Loopback0
    ip msdp mesh-group ANYCAST-RP 192.168.2.100
    ip msdp mesh-group ANYCAST-RP 192.168.2.101
    ip msdp mesh-group ANYCAST-RP 192.168.2.102

    !
    ip pim rp-candidate Loopback1

    • 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                           ........
    Comments
    New Member

    hi,

    the diagrams are not visible. please can you check.

    Regards,

    Shreeram

    Cisco Employee

    Which browser do you use ? Diagrams are properly displayed for me with IE and FireFox...

    New Member

    Hello Fabrice,

    I tried in all three IE, Firefox and crome. Unfortunately,I am not able to view the diagrams. Tried to download the file as pdf but still the same result

    Regards,

    Shreeram

    Cisco Employee

    Ok, you are the first one reporting this problem. Can you see the diagrams in other documents ? like

    https://supportforums.cisco.com/docs/DOC-14523

    Thx,


    Fabrice

    New Member

    Hello Fabrice,

    Yes, I am able to view the diagram in the link that you have provided. It seems to be an issue with only this document.

    Regards,

    Shreeram

    Cisco Employee

    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,

    FabriceAny-Prin1.jpg

    New Member

    Hello Fabrice,

    Yes, I can see the diagram.

    Regards,

    Shreeram

    Hello, I can't see the diagram's either. Mac OS X using Safari and firefox.

    New Member

    Hi Fabrice, I'm also having truble resolving the diagram.

    Could it be an issue with the location?

    http://wwwin-people.cisco.com/fducombl/MCAST/Any-Prin3.jpg

    regards

    Anton

    Cisco Employee

    Indeed, seems diagrams haven't been uploaded properly. I did it again, should be ok now ?

    Fabrice

    New Member

    All there now, thanks!

    Anton

    New Member

    I want to say a big thank you for a well written article. I have just been able to get an answer to a question I have been searching for a a very long time. Very easily understood and very clear. Thank you so much.

    13573
    Views
    15
    Helpful
    12
    Comments