[c-nsp] RP Migration option

Mon Feb 27 11:21:23 EST 2012

Hi,
Auto-RP and BSR is just a way how to dynamically disseminate the group to RP mapping information throughout the network -PIM protocol operation is parallel to these processes
So the only thing you need to worry about is how to get the information about active sources from RPs in the peer's domain to RPs in your domain and that's gonna be accomplished with MSDP
So you don't really need to worry about what your partner does in his network as long as it's PIM-SM and he is advertising active sources to you via MSDP and you can RPF the MSDP messages successfully
One of the primary design goals of MSDP was RP independence -so you can maintain your own RP infrastructure independently of your peer's infrastructure
What you need to pass between these two separate infrastructures is the information about active sources
So you don't need to mimic the peer's RP ip addressing or placement and you can build your own RP infrastructure

As you mentioned correctly all devices without override keyword will use dynamic Group to RP mappings
So once you have your RP and MSDP infrastructure in place
-you can either start using it for a given Group (configuring the particular group in the group-list acl on all RPs) -that's going to be used by all last hop nodes that are not configured with the override keyword
-or you can migrate node by node by configuring all nodes with the override keyword before configuring production Groups in the group-list acl than removing the override keyword node by node
-or combination of the two above

So I'd recommend building your own RP and MSDP infrastructure first than interconnecting your MSDP infrastructure with your peer's MSDP infrastructure than test it and afterwards proceed with the migration by enabling your RPs with production Groups or configuring end nodes to prefer dynamic RPs or combination of both
adam

________________________________
From: Андрей Андреев [mailto:a.andreev at teztour.com]
Sent: Monday, February 27, 2012 10:44 AM
To: Vitkovsky, Adam
Cc: cisco-nsp at puck.nether.net
Subject: Re: [c-nsp] RP Migration option

Thank you.
All your ideas are very helpful to me, I also think about multiple Anycast RP in domain.

After reading several materials i see the following migration steps

1) start to use BSR to announce partner RP, so all network devices without override keyword will use dynamic mapping.
2) then use bsr-border command at ASBR and start to use own network RP address.

One problem still exist, partner cant run BSR with us (only MSDP and MBGP), so i need to inject partner RP address via BSR in my domain.
If i can do this all PIM speakers in my domain will see BSR RP-Mapping without run BSR between domain.

Please review the following algorithm to spoof BSR announce:
1) Put current partner RP address on Loopback as /32 in stub router without multicast clients and transit multicast capability.
2) Activate PIM-SM on this interface and cBSR/cRP on this router.
3) Did not announce this address in IGP.

If i right, all my network will see dynamic mapping know by spoof BSR and will use external path to partner RP address known by MBGP.

Then i will careful migrate own network and clients to dynamic mappings use.
And finally turn ON own Anycast RPs and turn OFF spoof cBSR/cRP.

Is this right way?

24.02.2012 16:58, Vitkovsky, Adam пишет:

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> [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<mailto: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<mailto:cisco-nsp at puck.nether.net>

https://puck.nether.net/mailman/listinfo/cisco-nsp

archive at http://puck.nether.net/pipermail/cisco-nsp/