From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer

OECG – Chapter 20

915 Words. Plan about 6 minute(s) to read this.

In the previous post, it was mentioned that you can statically assign the RP, so that PIM-SM routers know where it is. And that’s about as exciting as doing a static route. Icky. Of course, you can dynamically discover RPs, as well as configure redundant RPs. (Side note – I’ve worked on a lot of enterprise networks, and I’ve had to set up multicasting exactly once, to support Ghost imaging from a server in a data center to a lab a few hops away. It’s hard to believe 100+ pages of the book are devoted to this topic. But I guess when you’re working on CCIE, you have to learn some things that might not be of frequent use. Anyway…)

Discovering Rendezvous Points

  • Static configuration – “ip pim rp-address <address>”
    • Does not scale well to enterprise environments with many multicast groups and different RPs.
    • Changing the RP becomes painful if routers have been configured statically with the RP address.
  • Cisco-proprietary Auto-RP protocol
    • The RP sends an RP-Announce to a reserved multicast destination of 224.0.1.39.
    • The RP-Announce message can include the multicast groups for which it is the RP.
    • The RP will send RP-Announce messages every 60 seconds.
    • When Auto-RP is in use, one router on the network is required to be the “mapping agent”.
      • Mapping agents enroll themselves in the 224.0.1.39 multicast group, so that they see all RP-Announce messages sent by the RPs.
      • The mapping agent’s job is to know all of the RPs and the groups that are supported by the RPs.
      • The mapping agent sends RP-Discovery messages to 224.0.1.40, telling all routers which RP they should use for which multicast group.
      • This allows for RP redundancy. The mapping agent determines which RP will handle traffic for a particular multicast group.
      • You can configure multiple mapping agents.
    • There is a notable challenge with Auto-RP. Routers need to join the 224.0.1.39 and/or 40 multicast groups to receive RP-Announce and RP-Discovery messages respectively. But if they don’t know the RP, they can’t do that – there’s no RP for them to send a join towards.
      • This is overcome by use of the Cisco “sparse-dense” mode, in which router will act as PIM-DM routers if the RP is unknown, and as PIM-SM if the RP is known.
      • Configured using “ip pim sparse-dense-mode” on an interface.
  • BootStrap Router (BSR) protocol
    • BSR showed up as a function of PIMv2, and is an alternate solution to the same problems solved by Cisco Auto-RP.
    • BSR is conceptually similar, but practically different from Auto-RP in these ways:
      • The BSR doesn’t choose the RP to advertise to the other routers.
      • The PIM routers figure out for themselves which RP is the best for a particular group by hashing on the bootstrap messages that are sent from the BSR router.
      • The BSR sends mapping messages to 224.0.0.13 (all-PIM-routers). This does not require dense mode support or a known RP, as PIMv2 requres that PIM routers flood BSR messages.
    • BSR supports multiple BSR routers.
      • Candidate BSRs sent bootstrap messages that have a priority and IP address of the BSR router.
      • Highest priority wins.
      • In a priority tie, highest BSR IP wins.
      • The winning BSR is known as the “preferred BSR”.
      • Candidate (losing) BSRs observe messages from the preferred BSR. If the preferred BSR goes dark, the candidate BSRs can attempt to become the preferred BSR again.
  • Anycast RP using Multicast Source Discovery Protocol (MSDP)
    • Anycast RP can be used in conjunction with static RP, Auto-RP or BSR. In that sense, it’s more of a feature enhancement to those existing discovery methods as opposed to a whole new way of doing things.
      • Without Anycast RP – only one RP can be the active RP for a given multicast group at a time. There’s no load-sharing among RPs for a group. You can do load-sharing by splitting different groups among different RPs, but you can’t share the SAME group among different RPs.
      • With Anycast RP – multiple RPs can be active as the RP for a specific multicast group.
    • Anycast RP accomplishes this by having RPs advertise the same /32 loopback IP. This makes it appear as if there’s only one RP for a particular multicast group, but in actuality, the end routers will determine which RP is closer via their unicast routing table.
      • This allows for multiple RPs to share the load for a specific multicast group.
      • If the RP fails, this scheme allows for a quick recovery time, dependent on convergence of the routing table to the remaining RP.
    • A challenge with this approach is that sources are only going to be sending through one RP. For the redundancy magic to work, the other RPs have to also receive the traffic from that source. To this end, MSDP steps in.
      • RPs send messages to each other using MSDP to tell one another the source IP address of each multicast group.
      • Once this information is known, the redundant RPs can join in the multicast.

Bidirectional PIM

  • Bidirectional PIM is intended to make PIM-SM more efficient in environments where there are a lot of multicast sources and enrolled hosts.
  • The efficiency gained, as best as I can tell (I admit that I’m a little fuzzy on exactly what’s going on here) is that the router receiving multicast packets from the source automatically forwards those packets to the RP, rather then sending a PIM-Register message. Then the RP forwards them along like normal via the shared tree.
  • Check out this PowerPoint stack from Cisco for a better explanation than my brief one here.