INE R&S ATC119 ~ ATC128 - Multicast

Multicast Section Objectives
• Understand the components of…
– Multicast Addressing
– Multicast Control Plane
– Multicast Data Plane
• Understand the Verification & Troubleshooting
– Configuration syntax is simple
– What should I see during each step of CP vs DP?
– Where do I go if I don’t see that?

IPv4 Multicast Addressing
• IPv4 multicast uses Class “D” Addresses
– 224.0.0.0/4 (224.0.0.0–239.255.255.255)
• Includes reserved ranges
– Link-local Addresses
• 224.0.0.0/24 (224.0.0.0 -224.0.0.255)
– Source Specific Multicast
• 232.0.0.0/8 (232.0.0.0 -232.255.255.255)
– Administratively Scoped
• 239.0.0.0/8 (239.0.0.0 -239.255.255.255)

Multicast Control Plane
• Multicast control plane used to determine
– Who is sending traffic and to what group(s)
– Who is receiving traffic and for what group(s)
– How traffic should be forwarded when it is received
• The Multicast “Tree”
• Control plane is built with a combination of
– Host to Router communication (IGMP)
– Router to Router communication (PIM and MSDP)

Multicast Data Plane
• Once the tree from sender to receiver(s) is built, traffic begins to flow
• Beforeforwarding, Data Plane checks occur
– Reverse Path Forwarding (RPF) check
• Was traffic received on the correct interface?
– Multicast Routing Table
• What interface(s) should I forward the packets out?

Control Plane - IGMP
• Internet Group Management Protocol
– Used for receiver to signal routers on the LAN that it wants traffic for a specific group
• Enabled when PIM is enabled
– ip pim[dense-mode | sparse-mode | sparse-dense-mode | passive]
• IOS runs IGMPv2 by default
– ip igmpversion [1 | 2 | 3]

IGMP Membership
• IGMP host signals membership to router via Report
– IGMPv1/v2 supports only group specific joins
• (*,G) Report
– IGMPv3 supports group and source specific joins
• (S,G) Report
• Router can initiate join with…
– ip igmp join-group group-address[source source-address]
– ip igmp static-group {* | group-address[source {source-address| ssm-map}]

IGMP Convergence
• How often to check for active membership
– ip igmp query-interval
• How long to wait for query response before implicit leave is assumed
– ip igmp query-max-response-time
• How long before detecting that querier is gone
– ip igmp querier-timeout

IGMP Convergence
• How many queries after explicit leave is heard
– ip igmp last-member-query-count
• How often query is sent after explicit leave
– ip igmp last-member-query-interval
• If explicit leave, prune without sending query
– ip igmp immediate-leave
• Track each SSM receivernot just (S,G)
– ip igmp explicit-tracking

Miscellaneous IGMP Features
• Filtering
– Control what groups can be joined
• ip igmp access-group
– Control how many groups can be joined
• ip igmp limit
• Stub Multicast Routing
• Send all reports and leaves upstream
• ip igmp helper-address

Control Plane -PIM• Protocol Independent Multicast
– Used for routers to signal each other how to build the Multicast Tree
• “Protocol Independent” because it does not advertise its own topology information
– Implies IGP already runs in the network to build a loop-free topology
• IOS runs PIMv2 by default
– ip pim version[1|2]

PIM Modes
• PIM modes control how the tree is built and who receives what traffic
• Dense Mode
– Considered implicit join
– All traffic unless you say you don’twant it
– Uses Flood & Prune behavior
• Sparse Mode
– Considered explicit join
– No traffic unless you ask for it
– Uses Rendezvous Point (RP) to process join requests
• Sparse Dense Mode
– Sparse for groups with an RP assigned
– Dense for all others

Control Plane -MSDP
• Multicast Source Discovery Protocol
– Used forRPs to signal each other about Multicast Senders
• Originally designed for Inter-ASMulticast
• Can be used for Intra-AS Anycast RP
– More on these later…

Data Plane -RPF Check
• PIM does not exchange topology information
– How do we know the network is loop free?
• RPF check prevents loops in the DataPlane
• When packet is received…
– Check source IP address and incoming interface
– If incoming multicast interface == outgoing unicast interface back to source, RPF check passes
– If incoming multicast interface != outgoing unicast interface, RPF check fails and packet is dropped

Data Plane -Multicast Routing Table
• Using PIM, routers learn where sources and receivers exist
– Interface facing upstream towards source is the “incoming interface”
– Interface(s) facing downstream towards receivers make up the “outgoing interface list” or OIL
– Split-horizon like behavior stops an interface from being in OIL if it is already an incoming interface
• If RPF check passes…
– Prefer (S,G) over (*,G) in routing table
– Switch packets from incoming interface to all interfaces in the OIL

PIM Dense Mode
• RFC 3973 “Protocol Independent Multicast -Dense Mode (PIM-DM)”
• Uses “push” model or “implicit join”
– Called flood and prune
– All traffic flooded throughout entire network
– Routers that have no receivers prune (unjoin) unused links
• Only suitable for small multicast implementations
– Doesn’t scale because of flooding and (S,G) state creation

PIM Dense Mode Operation
• Discover PIM neighbors
– 224.0.0.13 (PIM) to find neighbors on attached links
• Flood all multicast traffic
• Prune unwanted traffic
• Multicast table maintenance
– Graft
– Assert
– State Refresh

PIM Dense Mode Flooding
• Router attached to LAN listens for senders
– Sender does not communicate multicast control plane
• Once traffic is received…
– Insert (*,G) and (S,G) into routing table
• Incoming interface is attached to sender
• OIL is all other PIM interfaces
– Flood traffic to OIL
• Next downstream router(s) continue the process
– Flooding results in a Shortest Path Tree (SPT)
 
PIM Dense Mode Pruning
• Prune used to tell upstream neighbor to stop sending traffic for (S,G)
• Prune occurs if
– Multicast feed fails RPF check
– No downstream neighbors or receivers
– Downstream neighbors have already sent prune
– LAN Prune Override exception
• Once prune occurs, traffic flow stops but (S,G) remains in table
– Even after prune, traffic is periodically re-flooded at a set interval

PIM Dense Mode Graft
• What happens if I have pruned an (S,G), but then I receive an IGMP join from receiver?
• Graft message used as dense mode “join” to un-prune (S,G) from upstream neighbor
– Graft continues up reverse path back towards Source until tree is rebuilt
– Used to speed up convergence and not wait for periodic flooding

PIM Dense Mode Assert
• Used to prune duplicate multicast feed transmissions
– Typically needed when multiple routers attach to the same multicast enabled LAN
• Triggered when (S,G) feed is receive in an interface already in the OIL
• Assert winner determined by
– Lowest metric to source
– Highest IP address if metric is equal

PIM Dense Mode State Refresh
• Normally once an (S,G) is pruned, traffic is reflooded about every 3 minutes
– Limits scalability of dense mode
• State refresh is a keepalive for prune state
– Originated by root of the SPT
– If downstream routers agree, traffic is not reflooded
– Still doesn’t fix (S,G) state information in the routing table

PIM Sparse Mode
• RFC 4601 “Protocol Independent Multicast -Sparse Mode (PIM-SM)”
• Uses “pull” model or “explicit join”
– Traffic is not flooded unless you ask for it
• Uses both Shared Trees (RPT) and Source Based Trees (SPT)
– Dense mode uses only source trees
– More scalable than dense mode and usually the better design choice
 
Shared vs. Source Trees
• Multicast tree determines how traffic is routed from sender to receivers
• Source based trees
– Uses shortest path from sender to receiver
– Dense mode or sparse mode
• Shared trees
– Uses shortest path from sender to Rendezvous Point (RP), then shortest path from RP to receiver
– Sparse mode only
– Used to eliminate flooding and pruning and make routing table more scalable

PIM Sparse Mode Operation
• Discover PIM neighbors & elect DR
• Discover RP
• Tell RP about sources
• Tell RP about receivers
• Build shared tree from sender to receivers through RP
• Join shortest path tree
• Leave shared tree
• Multicast table maintenance

RP Overview
• RP is used as a reference point for the root of the shared tree
• RP learns about sources through unicast PIM Register messages
– Register tells the RP about an (S,G)
• RP learns about receivers through PIM Join messages
– Tells the RP to add an interface to the OIL for (*,G)
• RP is used to merge the two trees together

PIM Register Message
• As the root of all shared trees, the RP must know about all sources
• When the first-hop router connected to sender hears traffic, a unicast Register message is sent to the RP
– If multiple first-hop routers, only the DR registers
• If RP accepts this message, it acknowledges with Register Stop and inserts (S,G) into the table
• At this point only DR and RP know (S,G)

PIM Join Message
• As the root of all shared trees, the RP must also know about all receivers
• When a last-hop router receives an IGMP Report, a PIM Join is generated up the reverse path tree towards the RP
• All routers in the reverse path install (*,G) and forward the Join hop-by-hop to the RP
• At this point the RP and all downstream devices towards the receiver know (*,G)

Merging the Trees
• Once the RP knows about both sender and receiver…
– RP sends a PIM Join message up reverse path to source
• All routers in the reverse path from the RP to the source install (*,G) with OIL pointing towards RP
• Once (S,G) begins to flow, the tree is built end-to-end through the RP

Joining the SPT
• The shared tree is made up of two Shortest Path Trees
– SPT from receiver to RP
– SPT from RP to sender
• SPT from receiver to sender may not be the same as the shared tree
– Result is that Shared Tree is not optimal forwarding
• To fix this, last-hop router…
– Joins SPT to source with (S,G) Join
– Leaves the RPT by sending (*,G) Prune to RP
• Can be modified with ip pim spt-threshold {kbps| infinity} [group-list access-list]

Routing Table Maintenance
• Like PIM Dense Mode, PIM Sparse Mode uses State Refresh to ensure that feeds do not timeout
– (*,G) join sent to RP or up SPT to refresh the OIL
• Sparse Prune message can be used to speed up state information timeout if IGMP Leave is heard from end host
RPF Check and Sparse Mode
• RPF check is different in Sparse vs. Dense
• RP performs RPF on…
– Control Plane PIM Register from DR
– Data Plane packets from Source
• Receivers perform RPF check on…
–  RP for (*,G) Shared Tree
– Source for (S,G) SPT

Changing the RPF
• RPF is based on unicast routing table
– Implies changing unicast routing affects multicastrouting
• RPF can be modified
– Manuallywith ip mroute
– Dynamically with Multicast BGP
• RPF controls how tree mustbe built, not how it can be built
• RPF can be verified with…
– show ip rpf
– show ip mroute count
– debug ip mpacket

Learning the RP’s Address
• Without the RP…
– Sources can’t register
– Joins can’t be processed
• All routers must agree on the same RP address on a per-group basis
– Registers and joins are rejected for invalid RPs
• RP address can be assigned
– Statically
– Dynamically
• Auto-RP
• BSR

Auto-RP
• Legacy Cisco proprietary method
• Uses two functional roles
– Candidate RP(s)
• Device(s) willing to be the RP
• Sends advertisement to MA via 224.0.1.39
– Mapping Agent
• Chooses the RP among candidates and relays this information to the rest of the PIM domain
• Sends advertisement to all routers via 224.0.1.40

Auto-RP Caveats
• Dynamically learned RP mappings are preferred over statically configured ones
• Auto-RP control plane messages are subject to RPF check
• To successfully advertise Auto-RP information
– Mapping Agent must listen for 224.0.1.39
– Everyone must listen for 224.0.1.40
• In PIM Sparse Mode
– Cannot join the Auto-RP groups without knowing where the RP is
– Cannot know where the RP is without joining the Auto-RP groups
– Recursive logic

Auto-RP Solutions
• Default RP assignment
– Assign a static RP for groups 224.0.1.39 and 224.0.1.40
– Defeats the purpose of automatic assignment
• PIM Sparse-Dense Mode
– Dense for groups without an RP
– Sparse for all others
• Auto-RP Listener feature
– Dense for 224.0.1.39/224.0.1.40 only
– Sparse for others

Bootstrap Router
• Standard per PIMv2
– Functionally similar to Auto-RP
• Defines two roles in BSR domain
– RP Candidate
• Analogous to Candidate RP in Auto-RP
• Uses unicast PIM to advertise itself to the Bootstrap Router
– Bootstrap Router (BSR)
• Analogous to Mapping Agent in Auto-RP
• Advertises RP information to other routers with multicast PIM on a hop-by-hop basis

Bidirectional PIM
• Traditional Sparse Mode forms two trees
– Unidirectional SPT from source to RP
– Unidirectional Shared tree from RP to receivers
• Results in (*,G) and (S,G) entries in control plane
– For many-to-many multicast applications, doesn’t scale well
• Bidirectional PIM solves this by only allowing the Shared Tree (*,G) and never a SPT (S,G)

Source Specific Multicast
• IGMPv2 and PIM Sparse mode use (*,G) Joins to discover sources
– This is why the RP is needed
• IGMPv3 and SSM change these rules
– Clients generate (S,G) IGMPv3 Joins
– Routers build SPT directly to S for G
• Removes the need for RP
– Since no RP, no Register messages
– Source discovery is out of band
• Typically uses address range 232.0.0.0/8

MSDP
• RFC 3618 -Multicast Source Discovery Protocol
• Allows Service Provider to use their own internal RPs
– Don’t rely on internal routing of another AS
• MSDP used to communicate between RPs
– Who are the active multicast sources?
• Does not eliminate the need for PIM

How MSDP Works
• RPs in different ASes peer via MSDP
– TCP transport required
• When RP receives PIM Register for (S,G), it informs MSDP peers using Source Active (SA) message
– Allows other ASes to know what senders there are
• If another RP receives (*,G) Join for G, (S,G) Join sent to S
– MSDP peers are used just for control, not necessarily data plane

Anycast RP
• Uses anycast load balancing to decentralize the placement of RPs
– PIM Register and Join messages go to the closest RP in the topology
– If one RP goes down, convergence is up to IGP
– As long as one anycast RP is up, network is functional
• Anycast RP Design Issues
– For anycast to work, all RPs must share the same information about senders and receivers
– What if PIM Register is sent to one anycast RP, and PIM Join is sent to another?
• Solution: MSDP

How Anycast RP Works
• Anycast RPs assign a duplicate Loopback address and advertise into IGP
• All routers point to anycast RP address
– Could be static or dynamic assignment
• Anycast RPs are MSDP peers using a unique address
– If three of more RPs, usually a mesh group
• When PIMRegister is received, MSDP SA is sent to MSDP peers
– Results in synchronization of (S,G) information

IPv6 Multicast Routing
• Similar to IPv4 Multicast Components
– IPv6Multicast Addressing
– Host to Router communication (MLD)
– Router to Router communication (PIM)
 
IPv6 Multicast Addressing
• Uses reserved range FF00::/8
• First two bytes: FFXYwhere
– X = flags
– Y = scope
• Both X and Y are 4-bit fields
• 128-16=112 bits left for multicast groups Flags
• Only two bits in flags standardized
– X=00PT
• P=1 Embedded Unicast Address
– More in Embedded RP section
• T=1 Temporary address
– Normally T=0 in applications

Scope
• Scope values Y in FFXY:
– 1 = node
– 2 = link (e.g. FF02::2, FF02::5)
– 5 = site
– 8 = organization
– E = global
• Scopes are not automatically enforced
– Up to administrator to use filtering
 
CommonIPv6 Multicast Addresses
• Link-Local Scope
– FF02::1 All Nodes Address
– FF02::2 All Routers Address
– FF02::5 All OSPF Routers
– FF02::6 OSPF Designated Routers
– FF02::9 RIP Routers
– FF02::A EIGRP Routers
– FF02::D All PIM Routers
– FF02::1:FFXX:XXXX Solicited-Node Address
• Site-Local Scope
– FF05::2 All Routers Address
– FF05::1:3 All-dhcp-servers
– FF05::1:4 All-dhcp-relays

IPv6 PIM
• PIMv2 for IPv6
– Same basic behavior as PIMv2 for IPv4
• Sparse Mode Only
• Enabled using command
– ipv6 multicast-routing
• Disabled per-interface using
– no ipv6 pim

IPv6 MLD
• Multicast Listener Discovery
– Part of the ICMPv6 stack
– Replaces IGMP
• Enabled everywhere PIM is
– show ipv6 mldinterface
• MLDv1 copies IGMPv2 functions
– Query, Report, Done message
– Uses same timers as IGMPv2
• MLDv2 supports SSM
– Equivalent to IGMPv3

MLD Commands
• Limit states
– ipv6 mldlimit
• Query interval
– ipv6 mldquery-interval
• QuerierTimeout
– ipv6 mldquery-timeout
• Max Response Time
– ipv6 mldquery-max-response-time
• Access Group
– ipv6 mldaccess-group

IPv6 PIM Differences
• RP Tunnel Interface
• Every Router creates a tunnel to the RP address
– show ipv6 pimtunnel
• The tunnel is used to unicast PIM Register messages
– Allows for unified forwarding semantics
– Not really a “tunnel” in terms of GRE or IPv6IP

IPv6 PIM RP Discovery
• Static configuration
– ipv6 pimrp-address
• Dynamic learning
– Only BSR is supported, no Auto-RP
– Like IPv4, uses BSR and Candidate RPs
• Embedded RP
– RP address encoded in multicast group

IPv6 BSR
• Candidate RP
– ipv6 pimbsrcandidate rp<IPv6>
• Candidate BSR
– ipv6 pimbsrcandidate bsr<IPv6>
• Statically program BSR with RPs
– ipv6 pimbsrannounced RP <IPv6>
• Check for learned RPs
– show ipv6 pimrange-list

Embedded RP
• RP address is encoded in the IPv6 multicast group address itself
• Does not require any RP protocol
• Makes Inter-AS multicast easier
• Number of groups limited to 232
• RP must assign it’s own address as the RP

Embedded RP Format
FF7Y:0iLL:<64 bit RP prefix>:<32-bit Group ID>
– Y = scope for multicast group
– LL = 8 bit RP address prefix length
– “i” = 4-bit RP interface ID
• RP address = <64 bit RP prefix>::i/LL
– Concatenate address and interface ID
– Mask with the prefix length
• Note that group ID is shrunk to 32 bits

Embedded RP Example
• Embedded RP Format
– FF7Y:0iLL:<64 bit RP prefix>:<32-bit Group ID>
• Example RP Address
– 2001:1234:5678:ABCD::1/64
• Y = E (global scope)
• i= 1 (RP interface ID)
• LL = 40 (prefix length /64 in hex)
• RP Prefix = 2001:1234:5678:ABCD
• Group ID = 1
• Example Group Address
– FF7E:0140:2001:1234:5678:ABCD::1

Static IPv6 Multicast Routes
• No ipv6 mroute command
• Replaced with ipv6 route…multicast
• Like ipv4 mroute, used to fix RPF failures