[c-nsp] RP Migration option

Андрей Андреев a.andreev at teztour.com
Mon Feb 27 12:26:37 EST 2012 

Maybe i cant clearly explain my issue.
I try to be more understandable...

I already have
1) MSDP session between domains ASBR;
2) MBGP session between domains ASBR.

I've receive SA via MSDP and correct source network announce for RPF via 
MBGP.

All my core and aggregation devices has static RP pointing to partner AS 
address.
All my client has static RP pointing to partner AS address.

I try to use my own RP address configured on ASBR.
When i change static RP mapping from partner address to own address some 
where in network i saw error message

%PIM-6-INVALID_RP_JOIN: Received (*, x.x.x.x) Join from y.y.y.y for 
invalid RP z.z.z.z

where
x.x.x.x - valid group address pointing to own RP
y.y.y.y - my client ip address
z.z.z.z - partner RP address.

Actually i can change RP at my manageable devices at once, but i have 
many different client, the client can not do so at the same time.
One way to accomplish this is to sequentially migrate my devices and 
clients to BSR without service break.
And then quickly change RP address over the network without client 
collaboration.

But my partner cant run BSR with us, so i need somehow to inject current 
partner RP to BSR without receiving this information from it.
Only way i can spoof or mimic partner BSR announce is algorithm written 
in my previous message.
Or there is another way to accomplish this?





27.02.2012 20:21, Vitkovsky, Adam пишет:
>
> 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 sourcesare 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 suggestionsare welcome.
>   
> _______________________________________________
> cisco-nsp mailing listcisco-nsp at puck.nether.net  <mailto:cisco-nsp at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive athttp://puck.nether.net/pipermail/cisco-nsp/
>

More information about the cisco-nsp mailing list