2013/11/30

WB1 8.31 Anycast RP

8.31 Anycast RP

• Instead of relying on the BSR protocol to distribute the load between the
RPs in AS 200, implement a solution that hides both RPs behind the same
RP IP address 150.1.100.100.
• Every RP should inform the other one of the active sources registered with them.

---------------------------------------------------

Anycast RP is a special RP redundancy scenario, which allows using
redundant RPs sharing the same IP address
. Here Anycast means that
groups of RPs use the same IP address used by all multicast routers in the
domain to build shared trees. However, the PIM Joins are being sent to the
closest RP, based on the unicast routing table. Thus, different routers might
join shared trees rooted at different RPs. At the same time, different DRs will
pick up different physical RPs based on the anycast address to register their
local sources.

In order to maintain consistent source information, MSDP sessions should be
configured between the RPs. This will ensure that all routers joining different
RPs will still have full information about all potential sources in the domain.
Thus, the following are the guidelines to configure Anycast RP:

1) Use the same IP address on all routers as the candidate RP IP address.
Propagate this information via BSR or Auto-RP.

2) Using different IP addresses on every router, source MSDP sessions and
link all candidate RPs in a mesh. Note that you might need to manually
specify the MSDP originator ID to be different on every RP, or the MSDP
sessions won’t come up.

Anycast RP is a purely intra-domain solution, and does not deal with inter-domain
multicast
. Thus, it is a good example of using the inter-domain
technology inside a single multicast region to achieve RP redundancy above
the scheme used by PIM BSR.

In our scenario, we mix intra-domain MSDP with inter-domain connections.
That is, a domain with Anycast RP peers in another domain with regular RPs.
This results in a looped MSDP topology, which will successfully work due to
MSDP RPF checks.

------------------------------------------------------------------------------------

R5:
interface Loopback100
ip address 150.1.100.100 255.255.255.255
ip pim sparse-mode
!
router eigrp 100
network 150.1.100.100 0.0.0.0
!
ip msdp originator-id Loopback 0
ip msdp peer 150.1.8.8 connect-source Loopback 0
no ip pim rp-candidate Loopback0
ip pim rp-candidate Loopback100


SW2:
interface Loopback100
ip address 150.1.100.100 255.255.255.255
ip pim sparse-mode
!
router eigrp 100
network 150.1.100.100 0.0.0.0
!
ip msdp originator-id Loopback 0
ip msdp peer 150.1.5.5 connect-source Loopback 0
no ip pim rp-candidate Loopback0
ip pim rp-candidate Loopback100


------------------------------------------------------------------------------------

First, join receivers on R4 and SW3 to the multicast group 239.1.1.1. Check that
R4 actually uses the Anycast RP IP address as its RP.

R4:
interface Loopback0
ip pim sparse-mode
ip igmp join-group 239.1.1.1


SW3:
interface Loopback0
ip pim sparse-mode
ip igmp join-group 239.1.1.1


Rack1R4#show ip mroute 239.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

(*, 239.1.1.1), 00:53:08/00:02:37, RP 150.1.100.100, flags: SJCL
  Incoming interface: Serial0/1, RPF nbr 155.1.45.5
  Outgoing interface list:
    Loopback0, Forward/Sparse, 00:53:08/00:02:37

Rack1R4#

----------------------------------

Next source multicast from SW4 and confirm that it actually reaches the receivers.

------------------------------------

Rack1SW4#ping 239.1.1.1 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 155.1.79.9, 42 ms
Reply to request 0 from 155.1.45.4, 151 ms
Reply to request 0 from 155.1.45.4, 142 ms
Reply to request 0 from 155.1.79.9, 134 ms
Reply to request 0 from 155.1.79.9, 126 ms
Reply to request 0 from 155.1.79.9, 109 ms
Reply to request 0 from 155.1.45.4, 100 ms
Reply to request 0 from 155.1.79.9, 59 ms
Reply to request 0 from 155.1.79.9, 50 ms


------------------------------------------

Look at the SA caches of R5 and SW1. Both of them should have been updated
by SW2, as SW2 is the closest RP to the source (SW4) and the source registers
with it.

---------------------------------------------

Rack1R5#show ip msdp sa-cache
MSDP Source-Active Cache - 3 entries
(150.1.10.10, 239.1.1.1), RP 150.1.8.8, MBGP/AS 200, 00:01:04/00:05:21, Peer 150.1.8.8
(155.1.10.10, 239.1.1.1), RP 150.1.8.8, MBGP/AS 200, 00:01:04/00:05:21, Peer 150.1.8.8
(155.1.108.10, 239.1.1.1), RP 150.1.8.8, MBGP/AS 200, 00:01:04/00:05:21, Peer 150.1.8.8
Rack1R5#


Rack1SW1#show ip msdp sa-cache
MSDP Source-Active Cache - 3 entries
(150.1.10.10, 239.1.1.1), RP 150.1.8.8, MBGP/AS 200, 00:01:32/00:05:31, Peer 150.1.8.8
Learned from peer 150.1.8.8, RPF peer 150.1.5.5,
SAs received: 4, Encapsulated data received: 0
(155.1.10.10, 239.1.1.1), RP 150.1.8.8, MBGP/AS 200, 00:01:32/00:05:31, Peer 150.1.8.8
Learned from peer 150.1.8.8, RPF peer 150.1.5.5,
SAs received: 6, Encapsulated data received: 2
(155.1.108.10, 239.1.1.1), RP 150.1.8.8, MBGP/AS 200, 00:01:32/00:05:31, Peer 150.1.8.8
Learned from peer 150.1.8.8, RPF peer 150.1.5.5,
SAs received: 6, Encapsulated data received: 2
Rack1SW1#


---------------------------------------------

Now source traffic from AS 100 and make sure both receivers are able to hear it.
Check the SA caches of SW2 and R5 after that, to confirm that SW1 has actually
updated them.

--------------------

Rack1R6#ping 239.1.1.1 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:

Reply to request 0 from 155.1.79.9, 32 ms
Reply to request 0 from 155.1.45.4, 52 ms
Reply to request 0 from 155.1.146.4, 32 ms
Reply to request 1 from 155.1.79.9, 28 ms
Reply to request 1 from 155.1.45.4, 60 ms
Reply to request 1 from 155.1.146.4, 48 ms


-----------------

MSDP Source-Active Cache - 4 entries
(150.1.10.10, 239.1.1.1), RP 150.1.8.8, MBGP/AS 200, 00:10:14/00:05:39, Peer 150.1.8.8
(155.1.10.10, 239.1.1.1), RP 150.1.8.8, MBGP/AS 200, 00:10:14/00:05:39, Peer 150.1.8.8
(155.1.67.6, 239.1.1.1), RP 150.1.7.7, MBGP/AS 100, 00:00:15/00:05:55, Peer 150.1.7.7
(155.1.108.10, 239.1.1.1), RP 150.1.8.8, MBGP/AS 200, 00:10:14/00:05:39, Peer 150.1.8.8
Rack1R5#


Rack1SW2#show ip msdp sa-cache
MSDP Source-Active Cache - 1 entries
(155.1.67.6, 239.1.1.1), RP 150.1.7.7, MBGP/AS 100, 00:01:13/00:05:34, Peer 150.1.5.5
Rack1SW2#

沒有留言:

張貼留言