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:[email protected]]
*Sent:* Monday, February 27, 2012 10:44 AM
*To:* Vitkovsky, Adam
*Cc:* [email protected]
*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:[email protected]
<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of ?????? ???????
Sent: Friday, February 24, 2012 9:33 AM
To:[email protected] <mailto:[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 suggestionsare welcome.
_______________________________________________
cisco-nsp mailing [email protected]
<mailto:[email protected]>
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive athttp://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/
