[c-nsp] RP Migration option

Vitkovsky, Adam avitkovsky at emea.att.com
Fri Feb 24 07:58:20 EST 2012


Hi,
You mentioned you have a big m-cast network that's why I would recommend using several anycast RPs on routers with close proximity to receivers -this way each RP would serve only a subset of receivers (or two RPs in one locality can split the groups they serve)

In order to achieve this you'd configure the edge(ASBR) as pseudo msdp peer -no RP configured on ASBR (MSDP peers do not have to be an RP to forward SA msgs)
Than configure msdp peer sessions from the ASBR to all the anycast RPs in your domain 
If you only have receivers in your AS and all sources are in the partner AS -than you can configure your RPs with the default msdp peer to be the ASBR

If you also have sources in your AS you need to make sure the SA msgs get to all other RPs (in both domains) and RPF successfully 
So either use bgp in your AS between all the RPs and the ASBR (no need for msdp full mesh between RPs and ASBR)
Or you can put all RPs and ASBR into common mesh-group(but that would require a full mesh of msdp peering sessions)
Though you can avoid the full mesh requirement by putting each ASBR-to-RP session into a different mesh-group -than SA msgs would be passed between the peer-groups on the ASBR (RPF check would be ok)

Now to implement this seamlessly
By default dynamically learned RP takes precedence over static RP 
Though RP can be configured to take precedence over dynamic/auto RP this requires a lot of configuration on each last hop device

Also note:
That if you have all the interfaces configured only with: pim sparse mode
You would need to configure the nodes with: ip pim autorp listener
-this causes multicast traffic for the two Auto-RP groups(224.0.1.39 and 224.0.1.40) to be PIM dense mode flooded across interfaces operating in PIM sparse mode.

The more convenient migration approach would be to configure the anycast RPs first to support only a dummy m-cast group just to test the solution 
and than to add more and more groups to all anycast RPs to smoothly migrate the particular group to the new Anycast RPs -kind of group by group migration approach
Unfortunately this can't be scoped by location serviced by particular anycast RP -because as soon as one anycast RP starts acting as auto RP for particular group all the nodes in the network would start to use that RP for this group

Also I'd recommend BSR instead of Auto-RP as BSR can be very nicely scoped at the ASBRs on interfaces to the partner AS with: ip pim bsr border 


adam
-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of ?????? ???????
Sent: Friday, February 24, 2012 9:33 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] RP Migration option

Hi List,

Please advise me how can i use two independent RP at network for same 
groups to smoothly migrate backbone/aggregation devices and client 
equipment to new RP.

We have large network and even more large clients connected via PIM.
Now all network use static RP address from our partner AS.
We use PIM to connect to this partner.

Recently we start to use MSDP and MBGP at network edge device.
We received RP address and multicast source addresses via MBGP for RPF 
check and MSDP also works fine.

I plan to make Anycast RP on this edge device and change RP mapping on 
whole network.
Is there is any way to do this smoothly?
I can take window time and change RP at once on my device, but many 
clients cant do this.
So i need a way to migrate sequentially or partially over the long time.

One good news, Old RP address located beyond the edge router with 
MSDP/MBGP sessions so RPF is completely identical from view of whole 
network.

Backbone and edge run at 7600 - Sup720
Aggregation ran at 3560/3750

Any opinions and suggestions are welcome.

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/



More information about the cisco-nsp mailing list