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

647 Words. Plan about 4 minute(s) to read this.

Multicast routing is fundamentally different from unicast routing in that multicast destinations are not stored in the routing table. The router doesn’t keep a list of all hosts that have enrolled in a multicast group. So when a router receives a packet destined for a multicast address, how does the router make its forwarding decision?

Routers make these forwarding decisions implementing either dense- or sparse-mode multicast routing protocols.

  • Multicast Forwarding with Dense Mode
    • Dense-mode protocols assume that every subnet contains at least one recipient of any multicast group for which it might see a packet. “Flooding” is the operative word here. Build an ark, people – dense-mode routing protocol in full-effect.
    • Dense-mode protocols tell the router to forward multicast traffic out every interface, except when this could cause a loop. Multicast packets aren’t forwarded out the interface they came in on, for instance.
    • Dense-mode protocols allow the router to opt-out of certain multicast groups via a “prune” message. The router may want to do this if the following is true:
      • There are no downstream routers who need those multicast packets.
      • There are no hosts on connected subnets who need those multicast packets.
    • DVMRP, PIM-DM and MOSPF are dense-mode routing protocols.
  • Reverse-Path-Forwarding Check (a multicast loop-prevention mechanism)
    • Logic: Check the multicast packet source IP (which is a routable unicast address, remember). If my routing table indicates that the source IP lives on the same interface where I received the multicast packet, life is good. RPF is satisfied. If not, then don’t forward or make copies of the packet.
    • Distance Vector Multicast Routing Protocol (DVMRP) uses a separate multicast routing table it uses for RPF.
    • Protocol Independent Multicast (PIM) and Core-Based Tree (CBT) generally use the regular unicast routing table, but they can also use the DVMRP routing table, the Multiprotocol Border Gateway Protocol (MBGP), or static multicast routes for RPF.
    • Multicast OSPF doesn’t use RPF. This is because MOSPF uses the Dijkstra algorithm to determine forward and reverse shortest-path source-rooted trees.
  • Multicast Forwarding with Sparse Mode
    • If you didn’t figure it out from the overview above, dense-mode multicast routing can be pretty wasteful. It floods multicast traffic out essentially every routing interface, whether there’s anyone that needs to hear it somewhere down the line or not. Sparse-mode steps in to prevent this sort of wastefulness.
    • Sparse-mode, by default, only forwards a multicast packet out a particular interface if it has received a request to do so. This can happen because:
      • A downstream router requested the traffic.
      • A host on a connected segment issued an IGMP Join message.
    • Sparse mode routers tell special routers called “rendezvous points” that they want to receive traffic for a specific multicast group. The RP is the router the multicast source uses as a gateway. The RP is generally reachable by all other sparse-mode multicast routers via an advertised loopback address.
  • Multicast Scoping limits how many routers away multicast traffic will be forwarded.
    • TTL Scoping
      • A multicast router will only forward a multicast packet out an interface if the TTL on the interface is less than or equal to the TTL of the packet.
      • By default the TTL is 0 – but you can tweak this higher, in effect reducing how far away a multicast packet can get before a router drops it because TTL has expired.
      • TTL scoping isn’t great for large networks, because it becomes the administrator’s responsibility to figure out on every router what the appropriate TTL should be for every interface. Also, that TTL value you set on an interface is global for all multicast traffic. So if you want different TTL behavior per application, then you have to tweak the application itself – the routing infrastructure doesn’t give you the flexibility with TTL scoping alone.
    • Administrative Scoping
      • You can set routers to not forward traffic through a router if destined for the private range of 239.0.0.0 to 239.255.255.255.
      • This is manually configured.