From: Scott Morris (swm@emanon.com)
Date: Thu Nov 10 2005 - 21:39:54 GMT-3
Just not my style. Picks up the wrong kind of people at bars. ;)
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Andrew Lissitz (alissitz)
Sent: Thursday, November 10, 2005 5:34 PM
To: swm@emanon.com; jon; ccielab@groupstudy.com; comserv@groupstudy.com
Subject: RE: Auto-RP with MSDP and Anycast
What's wrong with tights or festive boots? I was thinking the cape was
perhaps a bit too much ;-)
Thanks for the clarification!!!
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Thursday, November 10, 2005 5:31 PM
To: Andrew Lissitz (alissitz); 'jon'; ccielab@groupstudy.com;
comserv@groupstudy.com
Subject: RE: Auto-RP with MSDP and Anycast
Do I get a cape? (No tights or festive boots though)
If the received direction of multicast traffic differs from the unicast
reverse path, and you don't feel like doing a bunch of "ip mroute"
commands, then yes MBGP is your friend.
I would think that it would be a fair topic for SP exam, but a bit beyond
the scope of the R&S exam.
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Andrew Lissitz (alissitz)
Sent: Thursday, November 10, 2005 5:28 PM
To: swm@emanon.com; jon; ccielab@groupstudy.com; comserv@groupstudy.com
Subject: RE: Auto-RP with MSDP and Anycast
So super Scott, if we are asked to configure this between two routers
without an IGP between them ... (this statement also assumes different
AS#s), is MPBGP our only way to propagate RPF info?
Something like this could easily be done on the SP lab...
-----Original Message-----
From: Scott Morris [mailto:swm@emanon.com]
Sent: Thursday, November 10, 2005 5:23 PM
To: 'jon'; ccielab@groupstudy.com
Cc: Andrew Lissitz (alissitz); comserv@groupstudy.com
Subject: RE: Auto-RP with MSDP and Anycast
So we want to explore the possibility of Anycast gone bad? :)
In the lab environment, there's really not a lot that can go bad. As long
as you have reachability and configure your different addresses correctly,
things will work fairly nicely.
In larger scale environments, the failures can occur based on difficulties
with the RPF checking versus the received paths for the multicast traffic.
And in larger scale environments we use MBGP carrrying the multicast address
family to assist in solving this problem for passing RPF information. (Note
to SP CCIE list, this MAY pertain to you!)
You can make things (manually) more complex by adding different filtering
techniques into the MSDP setup for which things will go where, but unlikely
to really run into this with the lab environment. If you're running it with
AutoRP or BSR, you'll have other difficulties with the default behavior of a
BSR or MA listing one RP per group max.
Typically I've seen this implemented with static RP assignments, but I guess
as long as everyone knows the "shared IP" it really doesn't matter "which
one" wins. *shrug*
But other than that, it's really just a cool way of distributing the load
and giving yourself some redundancy and resiliency along the way as
well!
HTH,
Scott
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of jon
Sent: Thursday, November 10, 2005 4:54 PM
To: ccielab@groupstudy.com
Subject: Auto-RP with MSDP and Anycast
I was messing around today with the following....
Two routers in a network of about 7 or 8.
All routers running pim sparse-dense.
I setup each of the two as both Auto-RP announcers and mapping agents, using
an Anycast loopback (advertised into OSPF).
I setup MSDP between them and messed with costs in the network to ensure
that my source registered with one RP, and the two client listeners
registered with one RP each.
Apart from some oddities around caching, it all worked lovely - however, I
having trouble following through the possibilities of it all.
I didn't limit the scope of the AutoRP, but due to the anycast IP both
ignore the other (except through the MSDP which uses different IPs on the
routers).
I guess what I'm interested in exploring is how this could go wrong, as it
seems a nice neat way to deal with variable multicast situations - with
source and listeners always registering with the nearest RP. The
infrastructure seemed to deal very well with RP failure, but went horribly
wrong when MSDP was disrupted.
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:06 GMT-3