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

463 Words. Plan about 3 minute(s) to read this.

The last post on Protocol Independent Multicast Sparse Mode would have been way too long if I’d kept it going…so it continues here.

Various PIM-SM Behaviors

  • PIM-SM routes are in the context of returning to the rendezvous point, not the source. This forms a shared distribution tree, or root-path tree, with the tree root at the RP.
  • A PIM-SM multicast route will expire in 3 minutes if no matching packet is forwarded during that time.
  • When looking at a “show ip mroute”, the following are notable from this section of the chapter (other sections have other notable things, but I wanted to capture these salient facts):
    • The notation of *, G instead of S, G indicates a root-path tree environment – the * indicates all potential sources.
    • The “incoming” interface indicates the source-facing interface. If the incoming interface is “Null”, that implies that the router you’re looking at is the RP.
    • The “outgoing” interface indicates the host-facing interface.
      • The first time indicates how long the interface has been forwarding traffic for that group.
      • The second time is the prune timers – if there’s no IGMP join before this expires, the interface will no longer forward traffic for that multicast group.
    • An S flag indicate sparse mode.
    • A C flag indicates a host receiving traffic for that group is on a locally attached segment.
  • A PIM-SM router will be “steady state” forwarding for a multicast group in the following circumstances:
    • A downstream router keeps sending PIM join messages for that multicast group.
    • A host on a locally attached segment responds to IGMP queries with IGMP reports.

Receiving Multicast Traffic From the Source Directly Instead of via the RP

  • It is possible that receiving multicast traffic via the RP isn’t the most efficient way to receive the traffic. The RP is necessary because a host doesn’t know the source of the multicast until it receives the first multicast packet. But once the source is known, it may be desirable to put alternate interfaces into a forwarding state so that the multicast traffic is received via the most efficient route possible.
  • This process is called a “switchover” to shortest-path tree (SPT) instead of root-path tree (RPT).
  • You can manipulate when this happens via the “ip pim spt-threshold <rate>” where rate is in kbps, although the default behavior is for the router to attempt to switch to SPT as soon as the multicast traffic starts arriving from the source.
  • The router attempting to switch to SPT will:
    • Examine the source IP of the incoming multicast packet.
    • Look at the unicast routing table for that source.
    • Send a PIM-SM Join out the more efficient interface towards the source, with normal join behavior following.
  • Once the router has switched to SPT, it will prune the interface facing the RPT.