PIM

Protocol Independent Multicast

1.6.c Multicast scopes (not on blueprint)

General information on “PIM Multicast scopes”:

• IPv4 scopes:
  • 224.0.0.0/4 = Whole IPv4 multicast address space
  • 224.0.0.0/24 = Local subnetwork (eg. OSPF, EIGRP, …)
  • 232.0.0.0/8 = Source-specific multicast
  • 239.0.0.0/8 = Private multicast address space (like RFC 1918)
• IPv6 scopes:
  • FF0x::/8 = Whole IPv6 multicast address space
  • FF3x::/32 = Source-specific multicast
  • x = scope, which can be…
    • 2 = Link-local multicast (eg. OSPF, EIGRP, …)
    • 5 = Site-local multicast
    • 8 = Organization-local multicast
    • E = Global-scope multicast

1.6.c i Sparse Mode

General information on “PIM Sparse Mode”:

• Valid for all PIM modes:
  • Relies on the underlay unicast routing protocol (EIGRP, OSPF, IS-IS, …)
  • Used for routing multicast traffic
  • PIM uses ip/113 on 224.0.0.13 (IP4)/FF02::D (IPv6) for establishing and maintaining neighbor adjacencies
  • HELLO packets are exchanged by default every 30 seconds and will be sent out on every PIM interface
• PIM-SM specific differences:
  • Unlike Dense Mode, the multicast traffic is not flooded across the whole network
  • Instead, the multicast traffic is only sent to receivers explicitly requesting it (pull model)
  • For this to work, PIM-SM explicitly builds unidirectional shared trees rooted at a rendezvous point (RP)
  • Multicast routers forwarding the traffic must continuously send PIM Join messages to keep receiving the traffic (by default every 60 seconds)
  • When there’s no receiver for multicast traffic, the RP will tell the sender not to send him the traffic unless there’s a receiver (PIM Prune message)
• Designated Router (DR):
  • For each LAN segment a DR will be elected:
    • First tie: highest priority (default is 1)
    • Second tie: highest IP address
  • A DR forwards all PIM Join/Register messages towards the RP („upstream“)
  • This mitigates duplicate packets for LAN segments with several multicast routers
• A RP (rendezvous point) is like a “meeting point” for multicast traffic:
  • Every router that wants to send multicast traffic will initially forward it to the RP => (S,G) message
  • Every router that wants to receive multicast traffic will initially request it from the RP => (*,G) message
  • The RP can be defined statically or automatically
• OIL/IIL:
  • IIL: Incoming Interface List
  • IIL (*,G) entry: points towards the RP
  • IIL (S,G) entry: points towards the source
  • OIL: Outgoing Interface List
  • OIL entry: points towards the receiver
• PIM Join message:
  • (*,G) PIM Join messages are sent from the LHR towards the “all PIM routers” address 224.0.0.13
  • The (,G) PIM Join message includes an Upstream Neighbor address (= RPF neighbor address) which forwards the (,G) PIM Join message further towards the RP
  • The PIM Join message is forwarded out of each RP RPF interface to the “all PIM routers” address until it reaches the RP
  • Upon receiving the PIM Join message, the multicast routers in the path as well as the RP adds the interface where the PIM Join message was received to the OIL list for that specific (*,G) entry
  • The RPT remains active, even if there’s currently no active source generating traffic for that group
• PIM Register message:
  • The first packet from a multicast source will be encapsulated by the DR into a PIM Register message and sent unicast directly to the RP
  • Upon receiving and de-encapsulation the unicast packet, the RP has two options:
    • No active receivers:
      1. RP adds the (*,G) and (S,G) entry to the multicast routing table and sends a PIM Register-Stop message to the FHR.
      2. Upon receiving the PIM Register-Stop message the FHR prunes forwarding of the multicast traffic to the RP
      3. The DR will send a dataless PIM Register message 60 seconds before the (S,G) entry is about to timeout (by default every 120 seconds). This is repeated until the source stops sending traffic and/or receivers appear at the RP.
    • Active receivers:
      1. RP adds the (S,G) entry to the multicast routing table and the receiving interface to the (*,G) IIL.
      2. RP forwards the multicast stream towards the receiver on the RPT (on the (*,G)-path) which was built by the PIM Join message from LHR towards the RP.
      3. When the LHR receives the first multicast packet on the (*,G) path it sends a (S,G) PIM Join message directly towards the FHR. This builds the SPT. When the traffic starts to arrive over the (S,G) path the LHR will send a PIM Prune message to the RP and all traffic will now only flow over the (S,G) path.
      4. At the same time the RP sends a (S,G) PIM Join message towards the FHR to build the (S,G) tree towards it. The interface where the (S,G) PIM Join message was received along the path to the FHR is added to the OIL.
      5. When the (S,G) path from the RP to the FHR is built the FHR will continue to send encapsulated unicast PIM Register messages but also sends the traffic on the (S,G) multicast route (= duplicate traffic).
      6. When the RP receives the first native multicast packet on the (S,G) path it will send a PIM Register-Stop message to the FHR which ends the register process.
• PIM Prune message:
  • Used to signal a multicast router to prune the forwarding of multicast traffic for a specific group
  • This could be because there are no more receivers interested in the traffic or because of switching from the RPT to the SPT
• There are two trees within a multicast domain:
  • Root Path Tree (RPT):
    • The path from the receiving router to the sending router through the RP (rooted at the RP)
    • The RPT is used for initial traffic flow
  • Source Path Tree (SPT):
    • Used when there’s a better path from the receiving router to the sending router without going through the RP (rooted at the source/FHR)
    • The LHR will switch from the RPT to the SPT when the most optimal path from the sender to the receiver is calculated
    • This can result in multicast traffic not going through the RP router at all
    • SPT calculation can be modified/disabled, so that multicast traffic will always or until a threshold is reached (defined in kbps) use the path through the RP
• Multicast Troubleshooting:
  • Who’s the root?
  • Where’s the root?
  • What’s the PIM RPF neighbor for the root?
• PIMv6 specialties:
  • When pinging a multicast group from a loopback interface, the output interface must not be the physical interface but rather the tunnel interface used for PIM Registering
• Important: Sparse Mode is the only PIM mode supported in IPv6 multicast. Enabling IPv6 multicast-routing automatically enables PIMv6 (SM) on each interface!
• Good to know: In a dual-stack environment, an IPv4 RP can be used as RP for IPv6!

“PIM Sparse Mode” CLI configuration commands:

## ====
## IPv4
## ====

## Enabling multicast routing globally (IPv4)
Router(config)# ip multicast-routing

## Configuring PIM-SM on an interface (IPv4)
Router(config)# interface <if>
Router(config-if)# ip pim sparse-mode

## Modifying/Disabling the PIM SPT calculation behavior
Router(config)# ip pim spt-threshold [kbps | infinity] group-list [ACL]


## ====
## IPv6
## ====

## Enabling multicast routing globally (IPv6)
Router(config)# ipv6 multicast-routing

## Disabling PIMv6 on an interface (IPv6)
Router(config)# interface <if>
Router(config-if)# no ipv6 pim

“PIM Sparse Mode” CLI show commands:

## ====
## IPv4
## ====

## Showing IPv4 multicast routes
Router# show ip mroute

## Showing IPv4 PIM neighbors
Router# show ip pim neighbors

## Showing IPv4 PIM tunnel interfaces
Router# show ip pim tunnel


## ====
## IPv6
## ====

## Showing IPv6 multicast routes
Router# show ipv6 mroute

## Showing IPv6 PIM neighbors
Router# show ipv6 pim neighbors

## Showing IPv6 PIM tunnel interfaces
Router# show ipv6 pim tunnel

1.6.c ii Static RP, BSR, AutoRP

Rendezvous Point

Static RP

General information on “PIM Static RP”:

• For optimal placement of a RP in a multicast network, it can be defined manually
• Configuration needs to be applied on all multicast routers
• It’s possible to define multiple RPs for different multicast groups, but only when using access-lists

“PIM Static RP” CLI configuration commands:

## Configuring a static PIM RP (IPv4/v6)
Router(config)# [ip | ipv6] pim rp-address <ip>

“PIM Static RP” CLI show commands:

## ====
## IPv4
## ====

## Showing PIM RP-to-group mappings (IPv4)
Router# show ip pim rp mapping


## ====
## IPv6
## ====

## Showing PIMv6 RP-to-group mappings (IPv6)
Router# show ipv6 pim range-list

BSR

Bootstrap Router

General information on “PIM BSR”:

• Functionally similar to AutoRP, but open standard
• There are two roles within BSR:
  • Candidate RPs (C-RP): Routers willing to be the RP for a group mapping will announce themselves via unicast packets directly to the elected bootstrap router (BSR).
  • Bootstrap Router (BSR): Collects all C-RP announcements and informs other PIM routers about all C-RP candidates via 224.0.0.13 on a hop-by-hop basis.
• BSR election:
  1. In case of multiple BSR candidate, each C-BSR sends out BSR messages including its priority.
  2. The C-BSR with the highest priority (255 = highest), or on tie, highest IP address, wins and will continue to send out BSR messages.
  3. All other C-BSRs will continue monitoring the BSR messages so that in case of a BSR failure they can try to take over (same procedure as above).
• BSR message flow:
  1. BSR sends out BSR messages on all non-RPF interfaces using the „All PIM routers“ address of 224.0.0.13 and a TTL of 1.
  2. When a multicast router receives a BSR messages it will perform an RPF check on the source address.
  3. If the RPF check fails, the BSR message will be discarded.
  4. If the RPF check is successful, it will forward the BSR message out of all non-RPF interfaces with the same parameters.
• RP election:
  • Unlike AutoRP, the election of the RP is up to the receiving multicast router.
  • Tie-breaker order for C-RPs with the same group mapping:
    1. Longest multicast group match
    2. Highest priority (0 = highest)
    3. Highest hash value (if group and priority are the same)
    4. Highest IP address
• C-RP message flow:
  • C-RP announcements are sent as unicast packets directly to the BSR, including the RP address and the group mappings.

Configuration information:

• When verifying with show ip pim rp mapping, the first entry (top) represents the current RP

“PIM BSR” CLI configuration commands:

## ====
## IPv4
## ====

## Configuring a PIM BSR candidate-RP (IPv4)
Router(config)# ip pim rp-candidate <if> interval <sec>

## Configuring a PIM BSR candidate-BSR (IPv4)
Router(config)# ip pim bsr-candidate <if>


## ====
## IPv6
## ====

## Configuring a PIMv6 BSR candidate-RP (IPv6)
Router(config)# ipv6 pim bsr candidate rp <ipv6-addr>

## Configuring a PIMv6 BSR candidate-BSR (IPv6)
Router(config)# ipv6 pim bsr candidate bsr <ipv6-addr>

“PIM BSR” CLI show commands:

## ====
## IPv4
## ====

## Showing the PIM BSR router (IPv4)
Router# show ip pim bsr-router

## Showing PIM RP-to-group mappings (IPv4)
Router# show ip pim rp mapping


## ====
## IPv6
## ====

## Showing the PIMv6 BSR state, election and timers (IPv6)
Router# show ipv6 pim bsr election

## Showing the PIMv6 BSR candidate-RPs states (IPv6)
Router# show ipv6 pim bsr candidate-rp

## Showing PIMv6 RP-to-group mappings (IPv6)
Router# show ipv6 pim range-list

AutoRP

General information on “PIM AutoRP”:

• AutoRP is a Cisco proprietary feature which was developed/implemented before the BSR feature existed
• AutoRP requires the multicast groups 224.0.1.39/.40 to be dense flooded
• There are two roles within BSR:
  • Candidate RPs (C-RP): Routers willing to be the RP for a group mapping will announce themselves via 224.0.1.39.
  • Mapping Agent (MA): Elects the “final” RP for a group mapping out of all C-RPs. Informs the network about the elected RP via 224.0.1.40.
• MA election:
  • Since C-RP/MA announcements are dense-flooded throughout the network, there is no MA election process
  • Therefor a multicast router can receive different MA announcements from multiple MAs
  • If badly/weird configured (with RP filters), this can result in a multicast router receiving different RPs for the same group mapping
  • In this case, the multicast router goes through the same RP election process as the MA
• RP election:
  • Unlike BSR, the election of the RP is done by the MA.
  • Tie-breaker order for C-RPs with the same group mapping:
    1. Longest multicast group match
    2. Highest IP address
• MA/C-RP message flow:
  • Two options to dense flood the C-RP/MA announcements:
    1. The ip pim autorp listener command forces the multicast groups 224.0.1.39 and 224.0.1.40 to be dense flooded
    2. Enable PIM Sparse-Dense mode throughout the network which causes unknown multicast group to be dense flooded
  • This also results in no PIM Prune messages for these groups
  • C-RP announcements are sent to the multicast group 239.0.1.39
  • MA announcements are sent to the multicast group 239.0.1.40
• Important: AutoRP supports IPv4 only!

“PIM AutoRP” CLI configuration commands:

## Enabling PIM AutoRP listener mode
Router(config)# ip pim autorp listener

## Configuring a PIM AutoRP candidate
Router(config)# ip pim send-rp-announce <if> scope <ttl> interval <sec>

## Configuring a PIM AutoRP mapping agent
Router(config)# ip pim send-rp-discovery <if> scope <ttl> interval <sec>

“PIM Static RP” CLI show commands:

## Showing PIM RP-to-group mappings (IPv4)
Router# show ip pim rp mapping

1.6.c iii Group to RP Mapping

General information on “Group to RP Mapping”:

• Group mappings are based on the longest match (like the routing table)
• With access-lists it’s possible to map specific multicast groups to different RPs
• This can be used for load-balancing
• The configuration needs to be done on the RP routers (AutoRP and BSR) or all routers (static RP)

“PIM Group to RP Mapping” CLI configuration commands:

## ====
## IPv4
## ====

## Configuring a group-to-RP mapping for a static RP (IPv4)
Router(config)# ip pim rp-address <ip> [ACL]

## Configuring a group-to-RP mapping for a BSR RP (IPv4)
Router(config)# ip pim rp-candidate <if> group-list [ACL]

## Configuring a group-to-RP mapping for an AutoRP (IPv4)
Router(config)# ip pim send-rp-announce <if> scope <ttl> group-list [ACL]


## ====
## IPv6
## ====

## Configuring a group-to-RP mapping for a static RP (IPv6)
Router(config)# ipv6 pim rp-address <ip> [ACL]

## Configuring a group-to-RP mapping for a BSR RP (IPv6)
Router(config)# ipv6 pim bsr candidate rp <ipv6-addr> group-list [ACL]

“PIM Group to RP Mapping” CLI show commands:

## ====
## IPv4
## ====

## Showing PIM RP-to-group mappings (IPv4)
Router# show ip pim rp mapping


## ====
## IPv6
## ====

## Showing PIMv6 RP-to-group mappings (IPv6)
Router# show ipv6 pim range-list

1.6.c iv Bidirectional PIM

General information on “Bidirectional PIM”:

• Used/Recommended when there are many senders which are also receivers (many-to-many applications like video conferencing, …)
• RP is essential in a bidirectional multicast network because there are only (*,G) multicast routing entries
• Since there are only (*,G) routing entries, all multicast traffic will always run over the RP
• RPs within BiDir PIM can be seen as more like a vector since they don’t connect (S,G) with (*,G) pairs, but rather forward the traffic received from the source downstream towards LHR
• At the same time this means there are only RPTs but never SPTs
• In contrast to “normal” PIM, BiDir allows traffic for (*,G) entries to flow upstream towards the RP as well as downstream towards the source/receiver (= bidirectional)
• There are also no PIM Register(-Stop) messages in BiDir, but a concept of DFs (= Designated Forwarder) is used
• This means the all multicast routers to the RP from, and including, the FHR won’t create an (S,G) or (*,G) entry
• DF (Designated Forwarder) election:
  • For each LAN segment, except the LAN segment of the RP, a DF (Designated Forwarder) will be elected
  • The main responsibility of a DF is to send traffic from a source upstream towards the RP
  • This is especially necessary in case of multiple multicast routers on a LAN segment, so that no duplicate traffic gets generated
  • The election is based on the PIM Assert mechanism:
    1. Router with lowest AD to the source
    2. Router with lowest unicast metric to the source
    3. Router with highest IP address
• BiDir in conjunction with Anycast RP is not possible, since Anycast RP relies on sharing (S,G) pairs
• Load-sharing can be achieved by using multiple RPs and assigning them to different multicast groups
• High availability can be achieved using the “Phantom RP” feature
• Important: Enabling Bidirectional PIM disables SPTs and SSM!

// Graphic missing - Coming soon //

High availability for BiDir PIM using Phantom RPs:

• Phantom RPs are the only approach for high availability when using BiDir PIM
• This concept works by creating a virtual RP with an IP address not defined on any multicast router
• This is possible because in BiDir PIM no packet is unicasted to the RP address but instead the RP is used more like a vector
• Failover time relies on the convergence time of the underlying IGP

Configuration steps for Phantom RPs:

1. Create the same loopback interface on different routers with the same IP address but different subnet mask (eg. Starting with /30, then /29, …)
2. Advertise the created loopback interfaces into the IGP
3. Announce/set the RP address to an IP address in the range of the loopback interface but NOT the actual loopback IP address itself (eg. if the loopback is 10.0.0.1/30 then the Phantom RP is 10.0.0.2)

Important for Phantom RPs:

• The IP address of the Phantom RP is a virtual one, therefor NEVER the actual IP address of the loopback itself
• When using OSPF, the network type must be set to point-to-point because OSPF advertises loopbacks by default as /32
• RID of the IGP should be hardcoded to avoid problems in case of that the loopback interface for the phantom RP has the highest IP address of all loopbacks
• BSR doesn’t support Phantom RPs yet, therefor either AutoRP or static settings must be used

“Bidirectional PIM” CLI configuration commands:

## ====
## IPv4
## ====

## Enabling bidirectional PIM on every multicast router (IPv4)
Router(config)# ip pim bidir-enable

## Configuring a static RP with bidirectional PIM enabled (IPv4)
Router(config)# ip pim rp-address <ip> bidir

## Configuring a BSR RP with bidirectional PIM enabled (IPv4)
Router(config)# ip pim rp-candidate <if> bidir

## Configuring a AutoRP with bidirectional PIM enabled (IPv4)
Router(config)# ip pim send-rp-announce <if> scope <ttl> bidir


## ====
## IPv6
## ====

## Configuring a static RP with bidirectional PIMv6 enabled (IPv6)
Router(config)# ipv6 pim rp-address <ipv6-addr> bidir

## Configuring a BSR RP with bidirectional PIM enabled (IPv6)
Router(config)# ipv6 pim bsr candidate rp <ipv6-addr> bidir

1.6.c v Source-Specific Multicast

General information on “PIM Source-Specific Multicast”:

• With SSM, the receiver signals an (S,G) instead of a (*,G) join
• The LHR sends (S,G) PIM Join directly towards the source out of the RPF interface
• This means SSM must only be configured on the edge router nearest to the receiver
• This results in no need for a RP since the application already knows the source
• Therefor each tree is a SPT and never a RPT
• Only routers within the SPT know about the (S,G) pair
• SSM has a specific pre-defined range of 232.0.0.0/8 but can be changed, if needed
• SSM only works together with IGMPv3 (IPv4)/MLDv2 (IPv6) because IGMPv1/v2 and MLDv1 don’t support source specification
• Important: SSM is automatically enabled in PIMv6 (IPv6)!

“PIM Source-Specific Multicast” CLI configuration commands:

## Enabling PIM SSM globally
Router(config)# ip pim ssm [default | range]

## Configuring IGMPv3 on a specific interface
Router(config)# interface <if>
Router(config-if)# ip igmp version 3

1.6.c vi Multicast boundary, RP announcement filter

Multicast boundary

General information on “Multicast boundary”:

• Configured on interfaces to limit the scope of a multicast domain
• This allows the same multicast group addresses to be reused in a different administrative domain

Configuration considerations:

• IPv4 configuration:
  • Configuration is done per interface with an ACL and can be inbound, outbound or both ways.
  • The permitted IP addresses within the ACL are the multicast groups and not the multicast source addresses.
• IPv6 configuration:
  • Configuration is done per interfaces with different options:
    • With the block source keyword all incoming multicast traffic on an interface will be blocked. The implementation is most commonly implemented at the first-hop router.
    • With the scope keyword the behavior depends on the interface:
      • RPF interface: Packets are not accepted that belong to scopes less or equal the configured one
      • Outgoing interface: Packets are not forwarded that belong to scopes less or equal the configured one
  • Additionally PIM Register/BSR messages are also not accepted for multicast group addresses that belong to scopes less or equal the configured one.

“PIM Multicast boundary” CLI configuration commands:

## ====
## IPv4
## ====

## Configuring PIM multicast boundary on an interface (IPv4)
Router(config)# interface <if>
Router(config-if)# ip multicast boundary [ACL] [in | out]


## ====
## IPv6
## ====

## Configuring PIMv6 multicast boundary with block source option on an interface (IPv6)
Router(config)# interface <if>
Router(config-if)# ipv6 multicast boundary block source

## Configuring PIMv6 multicast boundary with scope option on an interface (IPv6)
Router(config)# interface <if>
Router(config-if)# ipv6 multicast boundary scope <type>

RP announcement filter

General information on “RP announcement filter”:

• Configured on the AutoRP mapping agent or BSR to allow/deny specific RP candidates
• Can be used to mitigate rouge/accidentally/… configured RPs
• Important: If the local router is an AutoRP mapping agent + RP candidate or BSR candidate + BSR RP candidate at the same time, it must be included in the ACL!

“PIM RP announcement filter” CLI configuration commands:

## ====
## IPv4
## ====

## Configuring a PIM AutoRP announcement filter (IPv4)
Router(config)# ip pim rp-announce-filter rp-list [ACL] group-list [ACL]

## Configuring a PIM BSR RP announcement filter (IPv4)
Router(config)# ip pim bsr-candidate <if> <hash> <priority> accept-rp-candidate [ACL]


## ====
## IPv6
## ====

## Configuring a PIMv6 BSR RP announcement filter (IPv6)
Router(config)# ipv6 pim bsr candidate bsr <ipv6-addr> accept-rp-candidate [ACL]

BSR border (not on blueprint)

General information on “BSR border (not on blueprint)":

• Configured on interfaces towards other routers to disallow BSR advertisement
• Requires more configuration than the AutoRP scope feature but is also much more granular

“PIM BSR border” CLI configuration commands:

## Configuring the PIM BSR border feature
Router(config-if)# [ip | ipv6] pim bsr border

1.6.c vii PIMv6 Anycast RP

General information on “PIMv6 Anycast RP”:

• Provides anycast RP services for PIM-SM within IPv6 networks
• Doesn’t rely on MSDP (unlike IPv4 Anycast RP which requires MSDP)
• Feature to provide load-sharing, redundancy and high availability within intra-area multicast domains
• Application data is mirrored to multiple devices (RPs) in the topology
• PIM Register/Join messages go to the nearest RP
• Packets from a multicast source need to get to all RPs to find joined receivers
• Each RP within an Anycast RP group has the same IP address
• Each sender/receiver use the nearest RP based on their unicast metric

Configuration steps:

1. Configure a loopback interface with the same IP address on multiple routers
2. Configure Anycast RP Peerings
3. Important: Own loopback must also be set as Anycast RP peer!

“PIMv6 Anycast RP” CLI configuration commands:

## Configuring PIMv6 Anycast RP peers
Router(config)# ipv6 pim anycast-rp <rp-address> <rp-peer-address>

“PIMv6 Anycast RP” CLI show commands:

## Showing PIMv6 Anycast RP peers
Router# show ipv6 pim anycast-rp

1.6.c viii IPv4 Anycast RP using MSDP

Multicast Source Discovery Protocol

General information on “IPv4 Anycast RP using MSDP”:

• Provides anycast RP services for PIM-SM in IPv4
• Feature to provide load-sharing, redundancy and high availability within intra-area multicast domains
• Application data is mirrored to multiple devices (RPs) in the topology
• PIM Register/Join messages go to the nearest RP
• MSDP is used to advertise (S,G) pairs between different RPs
• MSDP establishes a TCP connection on tcp/639 between different RPs to exchange (S,G) pairs
• Important: When configuring Anycast RP with more than 2 MSDP peers, a MSDP mesh group must be configured!

Configuration steps:

1. Configure a loopback interface with the same IP address on multiple routers
2. Advertise the loopback interfaces via the IGP
3. Configure MSDP peerings
4. Important: The MSDP peering address must be different to the Anycast RP address! The originator-id is comparable to the router-id of EIGRP/OSPF/BGP and should be unique (= not the RP address)!

“PIM IPv4 Anycast RP using MSDP” CLI configuration commands:

## Configuring the MSDP peers
Router(config)# ip msdp peer <ip> connect-source <if>

## Configuring the MSDP originator ID
Router(config)# ip msdp originator-id <if>

“PIM IPv4 Anycast RP using MSDP” CLI show commands:

## Showing MSDP peers
Router# show ip msdp peer

1.6.c ix Multicast multipath

General information on “Multicast multipath”:

• Normally multicast only utilizes one path even if there are multiple ECMP links available
• This is because multicast relies on RPF which allows by default only one best neighbor (based on the lowest AD, on tie based on the lowest metric)
• With multicast multipath it’s possible to load-split the multicast traffic
• Multicast multipath is based on ECMP links
• The [ip | ipv6] multicast multipath command without additional arguments is prone to polarization because the load splitting is based on the source address only
• Therefor it’s recommended to use the additional commands so that the source, group and next-hop is taken into account

“PIM Multicast multipath” CLI configuration commands:

## Configuring multicast multipath globally with hashing (IPv4)
Router(config)# ip multicast multipath s-g-hash next-hop-based

## Configuring multicast multipath globally (IPv6)
Router(config)# ipv6 multicast multipath