Multicast

Contents 1 Multicast Overview 1.1 Multicast Addresses 1.2 IGMP 1.3 PIM 1.3.1 PIM MODES 1.3.2 CONFIGURATION 1.3.3 Reverse Path Forwarding(RPF) 1.3.4 Bidirectional PIM 1.3.5 Stub multicast Routing 2 Rendezvous Points 2.1 Sparse Mode 2.1.1 Auto-RP 2.1.1.1 Auto-RP Problems 2.1.1.2 =Configuration 2.1.2 BSR 2.1.2.1 Configuration 2.1.3 Controlling Auto-RP/BSR messages 3 Detailed Working 3.1 Dense Mode 3.2 Sparse Mode 3.2.1 Source registration to the RP 3.2.2 Conversion of Shared tree to source tree in PIM-SM 3.2.3 Configuration

Multicast Overview

Multicast Addresses

• Class "D" Addresses
  • 224.0.0.0/4 ( 224.0.0.0 - 239.255.255.255 )
• Reserved Link Local Addresses
  • 224.0.0.0 - 224.0.0.255
  • TTL=1
• Administratively scoped addresses
  • 239.0.0.0/8

IGMP

• Communication between the client to a router
• Controls what multicast feeds are going to be fed into a segment
• When PIM mode is enabled on an interface, the router automatically starts listening for IGMP messages on that interface
• Testing commands available
  • ip igmp join-group
    • This simulates a client joining the multicast network.
  • ip igmp static-group
    • READ ABPOUT THIS

PIM

• Used between routers
• Protocol Independant
• PIM looks at the unicast routing table.

PIM MODES

• Sparse mode
  • Explicit joins
  • If a join message is not received, the multicast feed is not sent to the segment.
• Dense mode
  • Implicit join
  • Flood and prune behaviour
  • Everyone gets this and if they don't want it, they can prune the multicast traffic.
  • This is useful when the number of clients wanting the multicast feed are high.
• Sparse Dense mode
  • Sparse for groups with RP, dense mode for other groups

CONFIGURATION

• Enable multicast
  • ip multicast-routing
• Enable PIM
  • ip pim dense-mode
  • ip pim sparse-mode
  • ip pim sparse-dense mode
• If mode is sparse, then configure the RP addressed in 2 ways:
  • Statically
    • ip pim rp-address
  • Dynamically
    • Auto-RP
    • Bootstrap Router(BSR)

Reverse Path Forwarding(RPF)

• PIM looks at the unicast routing table and does the RPF check
• RPF checks if the incoming interface for the multicast feed is outgoing interface unicast route
• Static "mroute" overrides unicast information
  • This cheats the RPF check to consider the mroute configuration

Bidirectional PIM

• Uses shared tree, rooted at RP
• All devices need to support bidirPIM
  • ip pim bidir-enable

Stub multicast Routing

• Uses the IGMP helper-address command.
• Forwards the IGMP join-requests to the address configured as the helper address.

Rendezvous Points

Sparse Mode

• Can operate in either source based tree mode or shared tree mode, which is why this is the mode of choice in today's networks.
• RP can be configured either
  • Manually
    • ip pim rp-address
    • Advantage : High level of control
    • Disadvantage : Not scalable
  • Dynamically
    • Auto-RP
    • BSR(Bootstrap router) , vendor independant

Auto-RP

• Automatic RP advertisement
• Cisco proprietary
• Developed before BSR was developed.
• Auto-RP uses 2 dedicated multicast addresses 224.0.1.39 and 224.0.1.40 (instead of 224.0.0.13, like BSR)
• Here there is no election process for the Mapping agent ( unlike BSR ).
• 2 roles in AUTO-RP domain
  • Candidate RP
    • Advertises it's eligibility to be an RP in the form of a RP-Announce message.
    • Configuration -> ip pim send-rp-announce
    • 224.0.1.39 is uesd for the announcements
  • Mapping Agent
    • Takes the candidate RP advertisements and decides the RP
    • 224.0.1.40 is used to advertise RP information to other routers
    • The Group-to-RP mapping is advertised throught the PIM domain in the form of RP-Discovery messages.
    • configuration -> ip pim send-rp-discovery
• Auto-RP announcement subject to RPF check

Auto-RP Problems

• In sparse-mode, because the routers don't know the RP yet, they cannot listen to 224.0.1.40 and forward candidate RP announcements on 224.0.1.39 to the mapping agent
  • There are some workarounds
    • Default RP assignment
      • Assign a static RP for groups 224.0.1.39 and 224.0.1.40
      • Defeats the purpse of automatic assignment
    • Sparse-Dense
      • Dense for groups without RP ( 224.0.1.39/224.0.1.40), sparse for all others
    • Auto-RP listener
      • Treats the 224.0.1.39,.40 as dense mode.
      • All others still look like sparse-mode

=Configuration

• Define mapping agent
• Define candidate RP

BSR

• Similar to Auto-RP
• Open standard
• Referred to as PIMv2
• Just like Auto-RP , we have
  • RP Candidates (c-RP)
    • ip pim rp-candidate
    • Advertises itself to the BSR for candidacy
  • Bootstrap Router candidates (c-BSRs)
    • Advertises RP information to other routers
    • ip pim bsr-candidate
• The first step is for the BSR to be elected from the candidate-BSRs.
  • Bootstrap messages advertise the originator's priority and the BSR IP address.
  • Bootstrap messages are sent to the all PIM address (224.0.0.13) with a TTL of 1.
• The next step is for the RP to be selected from the candidate-RPs.
  • A C-RP is configured with a RP-address and a priority value ( 0 - 255 )
  • After the BSR is elected( i.e the only BSR sending out broadcasts ), the c-RPs send unicasts(Candidate-RP-Advertisements) to this BSR.
  • These messages contain
    • Originator's IP
    • Priority
    • Group for which the c-RPs are bidding for
• BSR compiles the c-RP received info and creates an RP-SET and broadcasts through the PIM domain.
• If a router has to now join a shared tree as a result of receiving either an IGMP message or a PIM join message,it examines the RP-set received from the BSR and finds the RP . The selection algorithm is something i do not want to go into.

Configuration

• Configure BSR(s)
• Configure RP Candidates

Controlling Auto-RP/BSR messages

• We can stop messages at a certain point
• BSR
  • interface fa 0/0, ip pim bsr-border
• Auto-RP
  • interface fa 0/0,ip multicast boundary 1
  • access-list 1 deny 224.0.1.39
  • access-list 1 deny 224.0.1.40
  • access-list 1 permit 224.0.0.0 15.255.255.255
• This is usually done at the edge of the networks.

Detailed Working

Dense Mode

• Flood and Prune model
• Simple to configure
  • ip multicast-routing -> Global command to turn on multicast on the router
  • ip pim dense-mode -> Interface level to turn on PIM Dense mode on an interface
  • show ip pim neighbor -> Good command to verify
  • show ip mroute -> Shows the multicast routing table.
    • Even though we folow dense mode, we will see the (*,G) in the multicast table. This is normal.
• Use the ip igmp join-group command on an interface to simulate a client wanting the multicast feed.
• Dense mode follows (S,G) model.

Sparse Mode

• The servers send their multicast traffic to a Rendezvous point.
• Clients pull the multicast traffic from the RP.

Source registration to the RP

• When a PIM-SM router receives a multicast packet from a directly connected source, it looks at its group-to-RP mapping to find the correct RP for the destination group.
• After the RP is determined, the router encapsulates the Multicast message in a unicast PIM Register message and sends it to the RP.
• When the RP receives this message, it decapsulates it and looks at the multicast message
  • If the multicast routing table already has an entry for the group,copies of the multicast packet are forwarded out all interfaces of the outgoing interface list.
• Now the RP creates an (S,G) entry for the multicast table and initiates an SPT to the source DR by multicasting a Join/Prune message.
• Once the RP is receiving the group traffic from the dense-mode tree from the DR of the multicast source, it unicasts a PIM Register Stop message to the multicast source's DR to stop sending the Register messages.
• If there are no members, then the RP doesn't establish an SPT with the source's DR. It just sends the register-stop message and creates an (*,G) entry in it's mroute table. If some client joins, then it goes ahead and establishes the dense-mode tree with the source's DR.
• In order to detect dead RPs, after 60 seconds of receiving the register-stop message, the Source's DR again sends the register message to the RP. This register message is called a null-register message(no encapsulated data) and this triggers the RP to send a Register-stop message to the DR.

Conversion of Shared tree to source tree in PIM-SM

• This is done because sometimes, the Source tree path is way more efficient than routing through the RP.
• When a router get's an IGMP join message from a client, it sends a PIM-JOIN message to the RP and joins the Shared tree (usual PIM-SM operation)
• however, now when the multicast packets are being received by this router, it checks the shortest path the source of the multicast packets.
• if this route is not through the RP, what this router does is, it sends a PIM-JOIN message to the source directly and after the shortest path tree has been established, it cuts-off it's association with the RP , by sending a PRUNE message to the RP.
• the show "ip mroute" command will still show both the *,G and S,G routes. But the router will prefer the S,G route.
• On cisco routers, the routers automatically join the shortest path tree after receiving the first packet on the shared tree for a given (S,G).
  • This can be changed using ip pim spt-threshold
  • If the threshold falls below the configured threshold, unless we have the infinity command configured, the router falls back to the sparse-mode.

Configuration

• ip pim sparse-mode -> on the interface
• ip pim rp-address -> global command to configure the RP address. This should be pasted into all routers (including the RP)