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: [email protected] [mailto:[email protected]] On Behalf Of ?????? ??????? Sent: Friday, February 24, 2012 9:33 AM To: [email protected] 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 [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
