Sunday, October 10, 2010

Enterprise IPv4 Multicast - Rendezvous Points

Having established a scheme for assigning applications to multicast groups, we need to figure out what to do about RPs.

In a vanilla PIM deployment, every router knows the one router that serves as RP for any given multicast group.  You can have a single active RP (serving all groups), or many RPs, each one serving a different range of groups.

PIM routers can learn the RP address for a given group through one of several mechanisms:

MethodSyntaxProsCons
staticip pim rp-address rp-addressSimpleNot Robust
Auto-RPip pim autorp listener
ip pim send rp-announce scope
   ttl-value

ip pim send-rp-discovery scope
   ttl-value
AutomagicCisco proprietary.
Complicated when running multiple overlapping scopes
BSRip pim bsr-candidate
   interface-type interface-number
ip pim rp-candidate
   interface-type interface-number
Like Auto-RP, but standards basedNot widely used.
Complicated when running multiple overlapping scopes
Anycast PimN/AStandards based, scalable, awesome.Cisco only supports on NX-OS, not IOS
Anycast RP + MSDPip pim rp-address rp-address
Plus a mess of MSDP configuration
Scalable, awesome, interoperable.?

Anycast RP + MSDP
Anycast RP is far more simple than the election-based mechanisms, and lets us do lots of nifty scoping tricks fairly simply.  It also saves us from the pain of running multiple different RPs for different purposes. If you're not familiar with anycast, it's a simple concept: Run the same service on the same IP address on multiple different areas in a network, and advertise those IPs into your IGP. Routing protocols will deliver your packets to the closest implementation of that service (IP address). It works great for connectionless services (like PIM or DNS), where it doesn't matter if every packet you send hits exactly the same server.

In the case of anycast RP, we just spin up a loopback interface on every participating router, using the same IP address on each of them.  Be careful if the anycast address has the numerically highest address among loopback interfaces.  Then manually configure the anycast IP as the RP on all leaf routers in the network, just like you would for static RP configuration.

Leaf routers will now send PIM traffic to the closest RP.  But there's a missing bit here:



The missing piece is synchronization between RPs, and that's where Multicast Source Discovery Protocol (MSDP) fits in.  MSDP was designed to share information about active multicast sources between the (presumably single) RPs in different administrative domains.  You might use MSDP peering with your ISP to learn about active multicast flows out in the Internet, or with a business partner in order to attract flows from their network, because once your RP knows about an active source, it can send subscription requests (PIM joins) in the direction of the active source.

A clever use of MSDP is peering between your own Anycast RPs, so that each of the many simultaneously active RPs will know about all active flows in your network:



Anycast RP + MSDP is a great solution.  Anycast PIM (available on NX-OS) lacks rich filtering capability, which is key to the enterprise scoping scheme.  You can do interesting combinations of anycast RP with Auto-RP, but it gets complicated quickly, and I don't see a compelling use case for it.

Where do RPs belong?
So, having established that we're going to run lots of RPs, where do they belong exactly?  Lots of people spend lots of time thinking about exactly where RPs should go relative to sources and receivers.  Someplace between them is ideal, if you can manage it.  ...But it probably doesn't matter much.  With the default PIM sparse configuration, data won't flow through the RPs, except for a brief moment when subscribers initially come online.  If your packet rates are high enough, and your subscribers transient enough, then you should place RPs carefully.

So, where exactly do we need RPs?  Start with the smallest routable scope.  In our case, it's "building".  If there will be intra-building multicast flows, then by definition there must be an RP in each building.  And if you need one RP, then you probably need a second one for redundancy.  So, that settles it:  Two RPs in each building.  With wild, crazy and carefully planned MSDP peering to bring them all together.

2 comments:

  1. Hello,

    anycast_RP only within nexus 7000 its true within VRF; it doesn't work well.

    In the default vrf, it behave like stated in RFC:
    http://www.rfc-editor.org/rfc/rfc4610.txt
    See section mecanism.

    ReplyDelete
  2. Chris,
    These multicast posts are really helping me out. One minor point on RP placement that might be worth mentioning. With anycast (all RPs share a common IP address) and building local scope (building B's RPs have no knowledge of building A's local sources). You want to make sure that building A's RPs will always be topologically closer to all of building A's PIM routers than building B's RPs. Or you may find that you enable a new PIM router in building A and its local RPs are equidistant to, or one hop parther away than building B's RPs.
    Thanks again!

    ReplyDelete