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

770 Words. Plan about 5 minute(s) to read this.

The book mentions 2 sparse-mode multicast routing protocols: Protocol Independent Multicast Sparse Mode (PIM-SM) and Core-Based Tree (CBT). Looking ahead in the chapter, I don’t see any further mention of CBT…so off we go with PIM-SM.

PIM-SM is similar in core functionality to PIM-DM, with one major exception. Whereas PIM-DM assumes everyone wants to get multicast traffic, PIM-SM assumes no one wants to get multicast traffic. PIM-SM is targetted at an environment where only a small number of subnets are enrolling in multicast groups. PIM-DM and PIM-SM are similar in the following ways:

  • Use of Hellos.
  • Recalculating the RPF interface if a link goes down or the unicast route table otherwise changes.
  • Electing a designated router.
  • Using Prune Overrides on LANs or other multiaccess (not point to point) networks.
  • Using Assert messages to pick a forwarder when more than one router can forward multicast traffic onto a segment.

PIM-SM is significantly different from PIM-DM because of the use of a router that will act as a “rendezvous point” (RP). The RP is a router that’s been administratively defined to track whether there’s a need for a gateway router receiving multicast traffic from a source to forward that traffic anywhere. In a PIM-SM environment, a couple of things happen to get multicast traffic flowing:

  • The multicast source (server, whatever you’d like to call it) sends traffic to the RP.
  • The RP forwards the multicast traffic to everyone that has registered to receive traffic for that particular multicast group, using a logical shared tree.

Some key commands to get going PIM-SM multicast routing with a statically configured RP:

  • ip multicast-routing (global)
  • ip pim sparse-mode (interface command)
  • ip pim rp-address xx.xx.xx.xx (global, and usually a loopback address to better survive topology changes)

What happens when a source wants to send multicast traffic, but no hosts have registered to receive that traffic?

  • The multicast gateway router receives the traffic from the source/server.
  • The gateway router sends unicast PIM “Register” messages to the RP. This first register message will also encapsulate the multicast packet sent by the source.
  • The RP will respond with a unicast “Register-Stop” message, as the RP will know that there’s no one requesting that multicast traffic.
  • The gateway router will start a 60-second “Register-Suppression” timer when it gets the Register-Stop message.
  • With 5 seconds left on the Reigister-Suppression timer, the gateway router will send another Register message to the RP, but with the “Null-Register” bit set, and no encapsulated multicast packet, at which point a couple of things might happen:
    • If the RP doesn’t know of anyone who wants to receive traffic for that multicast group, the Register-Stop message is repeated. The gateway router will reset the “Register-Suppression” timer.
    • If the RP DOES know of someone who wants to receive the traffic, the RP will remain silent. Then the gateway router’s Register Suppression timer will expire, and a shiny new Register message with an encapsulated multicast from the source will be sent from the gateway router to the RP.

What happens when a host wants to join a multicast group in a PIM-SM routing environment?

  • The host sends a join to his local router for the group he wishes to receive multicast traffic for.
  • The host router sends a PIM join message for the requested multicast group towards the RP and places his host-facing port into a forwarding state for that group.
  • Any routers in between the host router and the RP will put their appropriate interfaces into forwarding states for that multicast group as they forward the join message to the RP.
  • The RP then receives the join message and places the interface he received the join message on into a forwarding state for that multicast group.

What happens when a source wants to send multicast traffic, and there are hosts that want to receive that traffic?

  • The multicast gateway router receives the traffic from the source/server.
  • The gateway router sends unicast PIM “Register” messages to the RP. This first register message will also encapsulate the multicast packet sent by the source.
  • The RP removes the encapsulation from the multicast packet and forwards it appropriately.
  • Now, we don’t want to do the encap/decap thing forever, so the RP takes some more steps. First, the RP will send a join towards the source.
  • The routers in between the RP and the source will put their interfaces into forwarding mode for that particular multicast group when they see the PIM-SM join message.
  • The RP will begin receiving the multicast traffic natively from the source. When this happens, the RP will send a “Register-Stop” to the gateway router.