Thursday, February 6, 2014

NTS: Multicast

Multicast



PIM-DM (Protocol Independent Multicast- Dense Mode) is defined in RFC 3973.
PIM-SM (PIM - Sparse Mode) is defined in RFC 4601.
PIM-SSM (PIM - Source Specific Multicast) is defined in RFC 4607.
BSR (BootStrap Router) for PIM is defined in RFC 5059.


Multicast Ranges

Multicast range:
  • 224.0.0.0/8
  • FF00::/8

Important ranges (IANA):
  • Link-local range (TTL=1)
    • 224.0.0.0/24 
    • FFx2::/16
  • SSM range:
    • 232.0.0.0/8
    • FF3x::/32 (FF3x::8000:0000  - FF3x::FFFF:FFFF)
  • GLOP range: 233.0.0.0/8
  • Admin-scope range: 239.0.0.0/8

Link-local addresses are not constrained by IGMP snooping. The same also applies to x.0.0.x or x.128.0.x (due to 32:1 mcast=>eth mapping).


GLOP range

GLOP addressing is defined in RFC 3180.

Every 16bit ASN has its own GLOP 233.X.Y.0/24 range.

i.e. for AS 12345, one hex=>dec and two dec=>hex conversions need to be made.

12345 => 0x3039
0x30 => 48 (X)
0x39 => 57 (Y)

 AS 12345 = > 233.48.57.0/24

Organizations with a 32-bit ASN may apply for space in AD-HOC Block III (233.252.0.0 - 233.255.255.255) also known as Extended GLOP (EGLOP), or consider using IPv6 multicast addresses.


Multicast Routing Protocols

Main functionalities
  • setup multicast forwarding state
  • exchange information about the multicast forwarding state

Protocols
  • DVMRP
  • PIM-DM
  • PIM-SM
Expect to see only PIM-SM being used in most networks.


IOS
ip multicast-routing

IOS-XR
multicast-routing


Enabling multicast-routing on an interface in IOS-XR will enable PIM and IGMP automatically. There is no need to configure the "router pim" command (unless something extra is required, like MDT or RP), since the PIM mode it's automatically determined by the group range.

IOS-XR
GSR#sh pim group-map
Fri Jun  9 06:11:08.463 UTC

IP PIM Group Mapping Table
(* indicates group mappings being used)
(+ indicates BSR group mappings active in MRIB)

Group Range         Proto Client   Groups RP address      Info

224.0.1.39/32*      DM    perm     0      0.0.0.0
224.0.1.40/32*      DM    perm     1      0.0.0.0
224.0.0.0/24*       NO    perm     0      0.0.0.0
232.0.0.0/8*        SSM   config   1      0.0.0.0
224.0.0.0/4*        SM    static   0      0.0.0.0         RPF: Null,0.0.0.0

Each multicast group can be one of sparse, dense, bidir, ssm. Each interface can be many modes, each one depending on the egress multicast group.

In IOS-XR, the router itself is also listed as a pim neighbor with a "*".


PIM-SM RP

For PIM-SM to work properly, all routers in a domain must know and agree on the active RP for each multicast group (Group-to-RP mappings).

Group-to-RP mappings can be created using:
  • Static group-to-RP mapping
  • Auto-RP
    • uses dense-mode (configure "sparse-dense-mode" or "sparse-mode" & "ip pim auto-rp listener")
    • uses 224.0.1.39 for RP announcements (from RP to MA)
    • uses 224.0.1.40 for MA announcements (from MA to all PIM routers)
    • the priority of each RP cannot be defined (the RP with the higher ip address wins)
    • the interval/scope of Auto-RP announcements can be defined
    • use "ip multicast boundary ACL in/out filter-autorp" to filter Auto-RP announcements entering/leaving your network
  • PIM BSR (bootstrap router)
    • uses sparse-mode (configure "no ip pim dm-fallback" in dense environments)
    • uses 224.0.0.13 for BSR announcements (from BSR to all PIM routers)
    • unicast for RP announcements (from RP to BSR router)
    • the priority of each RP can be defined
    • the interval/scope of BSR announcements cannot be defined
    • use "ip pim bsr-border" to filter BSR announcements from entering/leaving your network
On hub-n-spoke networks, when auto-rp announcements must pass between the spokes, you cannot use nbma-mode, because this works only in sparse mode (and announcements are in dense). You have to use BSR or create a pim-enabled tunnel between the spokes.

Static RP and BSR are the most common ways to configure a Group-to-RP mapping.


Static RP

IOS
interface Loopback0
 ip pim sparse-mode
!
ip pim rp-address 1.1.1.1

IOS-XR
router pim
 address-family ipv4
  rp-address 1.1.1.1
  interface Loopback0
   enable


Auto-RP

IOS
interface Loopback0
 ip pim sparse-mode
!
ip pim send-rp-announce Loopback0 scope 10
ip pim send-rp-discovery Loopback0 scope 10



IOS-XR
router pim
 address-family ipv4
  auto-rp mapping-agent Loopback0 scope 10 
  auto-rp candidate-rp Loopback0 scope 10
  interface Loopback0
   enable

In IOS-XR, Auto-RP is not supported for VRFs.

In IOS, you can use an ACL to filter the auto-rp groups.

Auto-RP requires either sparse-dense mode or sparse mode and auto-rp listener (by default enabled in IOS-XR).


BSR


IOS
interface Loopback0
 ip pim sparse-mode
!
ip pim bsr-candidate Loopback0
ip pim rp-candidate Loopback0

IOS-XR
router pim
 address-family ipv4
  interface Loopback0
   enable
  !
  bsr candidate-bsr 1.1.1.1
  bsr candidate-rp 1.1.1.1


When static RP is configured together with Auto-RP or BSR for the same PR mappings, Auto-RP/BSR created mappings take precedence, unless "override" is configured with the static rp-address.


PIM-SSM


PIM-SSM uses PIM-SM + IGMPv3/MLDv2.

Summary
  • Receivers report interest for a particular source using IGMv3
  • PIM routers do RPF lookups for the source and join upstream towards the source
  • An SPT is created between the source and the receivers
  • Multicast traffic starts to flow from source to the receivers on the SPT

Detailed analysis

  1. Receiver
    1. sends an IGMPv3 Report (S,G) to the LAN
  2. Receiver DR
    1. receives the IGMP Report (S,G) from the Receiver
    2. adds the incoming IGMP interface to OIL for (S,G)
    3. performs RPF lookup for source S
    4. sends a PIM Join (S,G) to the upstream router out of the RPF interface
  3. Upstream Routers (from Receiver DR towards the Source)
    1. add the incoming PIM interface to OIL for (S,G)
    2. perform RPF lookup for source S
    3. send a PIM Join (S,G) to the next upstream router out of the RPF interface (*)
    4. ...

(*) This propagation of PIM Join messages our of the RPF interface continues until the source DR is reached or an upstream router has already multicast forwarding state for this group.


IOS
ip pim ssm default
!
interface X
 ip pim sparse-mode


IOS-XR
multicast-routing
 address-family ipv4
  interface X
   enable


SSM is enabled by default on IOS-XR for 232.0.0.0/8.

In IOS-XR, interfaces enabled under multicast-routing run PIM sparse-mode by default.


PIM-SM


Summary
  • A receiver asks for multicast data and an RPT (*,G) is built from the receiver DR to the RP
  • When the source transmits the multicast data, first packets are sent encapsulated into PIM Register messages by the source DR to the RP and then an SPT (S,G) is built from the RP to the source
  • When the multicast data reaches the receiver, there is a new SPT (S,G) built from the receiver DR directly to the source
  • Receiver DR sends a prune message to the RP to stop the initial RPT

Detailed analysis

Phase #1 (Receiver asks for multicast data)
  1. Receiver
    1. sends an (*,G) IGMP Report to the LAN
  2. Receiver DR Router
    1. receives the (*,G) IGMP Report from the Receiver
    2. adds the incoming IGMP interface to OIL for (*,G)
    3. performs RPF lookup for RP
    4. sends a (*,G) PIM Join to the upstream router out of the RPF interface
  3. Upstream Routers (from Receiver DR towards the RP)
    1. receive the (*,G) PIM Join from the downstream router
    2. add the incoming PIM interface to OIL for (*,G)
    3. perform RPF lookup for RP
    4. send a (*,G) PIM Join to the next upstream router out of the RPF interface (*)
Phase #2 (Source sends multicast data and Receiver receives it through the RP)
  1. Source S
    1. starts sending native multicast data (S,G) to the LAN
  2. Source DR Router
    1. receives native multicast data from the source
    2. adds the incoming multicast data interface to IIF
    3. encapsulates multicast data in PIM Register messages
    4. sends the PIM Register messages to the RP as unicast packets
  3. RP (with active RPT)
    1. receives and decapsulates the PIM Register messages
    2. sends the decapsulated native multicast data to the receiver down the RPT
  4. Receiver
    1. receives the native multicast data through the RP
  5. RP (with active RPT)
    1. performs RPF lookup for source S
    2. sends a (S,G) PIM Join to the upstream router (towards source) out of the RPF interface
  6. Upstream Routers (from RP towards the Source)
    1. receive the (S,G) PIM Join
    2. add the incoming PIM interface to OIL for (S,G)
    3. perform RPF lookup for source S
    4. send a (S,G) PIM Join to the next upstream router (towards source) out of the RPF interface (*)
  7. Source DR Router
    1. receives the (S,G) PIM Join
    2. starts sending native multicast data to the RP
  8. RP (with active RPT)
    1. receives duplicate multicast data (encapsulated from Source DR and native from source/upstream)
    2. sends a PIM Register-Stop message to the Source DR
  9. Source DR Router
    1. receives the PIM Register-Stop message from the RP
    2. stops sending PIM Register messages with encapsulated multicast data to the RP
  10. RP (with active RPT)
    1. receives only native multicast data
    2. sends the native multicast data to the receivers down the RPT
  11. Receiver
    1. receives the native multicast data through the RP
Phase #3 (Receiver receives the multicast data directly from the Source)
  1. Receiver DR Router
    1. receives multicast data (S,G) from source S through the RP
    2. performs RPF lookup for source S
    3. sends a (S,G) PIM Join to the upstream router out of the RPF interface 
  2. Upstream Routers (from Receiver DR towards the Source DR)
    1. receive the (S,G) PIM Join from the downstream router
    2. add the incoming PIM interface to OIL for (S,G)
    3. perform RPF lookup for source S
    4. send a (S,G) PIM Join to the next upstream router out of the RPF interface (*)
  3. Source DR Router
    1. receives the (S,G) PIM Join from the downstream router
    2. starts sending native multicast data to the Receiver DR Router
  4. Receiver DR Router
    1. receives duplicate multicast data (from source DR through SPT and from RP through RPT)
    2. sends a PIM Prune (S,G,RPT) to the upstream router out of the RPF interface
  5. Upstream Routers (from Receiver DR towards the RP)
    1. receive the PIM Prune (S,G,RPT)
    2. remove the incoming PIM interface from OIL for (*,G)
    3. if OIL is null, send a PIM Prune (S,G) to the upstream router out of the RPF interface
  6. RP
    1. receives the PIM Prune (S,G)
    2. removes the incoming PIM interface from OIL for (*,G)
    3. if OIL is null, sends a PIM Prune (S,G) to the upstream router out of the RPF interface
  7. Source DR
    1. receives the PIM Prune (S,G)
    2. removes the incoming PIM interface from OIL for (S,G)

(*) This propagation of PIM Join messages our of the RPF interface continues until the RP or the Source DR is reached or an upstream router has already multicast forwarding state for this group.

PIM Prune messages might not be sent, if there is another active multicast state for the same group in the router.

The Source DR periodically sends a PIM Null-Register message (without any multicast data inside) to the RP, in order to inform it that the source is still active.



IOS
interface X
 ip pim sparse-mode


IOS-XR
multicast-routing
 address-family ipv4
  interface X
   enable


OIL = Outgoing Interface List
IIF = Incoming Interface

In the shortest path tree (SPT), the root of the tree is the source.
In the shared path tree (RPT), the root of the tree is the RP.

PIM Joins are sent to 224.0.0.13.

The threshold for switching from the RPT to SPT is 0 by default, which means once the Receiver DR receives the first multicast packet and learns the source, it sends a (S,G) PIM Join towards the source. When is starts receiving multicast data from the SPT, it sends a PIM Prune for traffic received via the RPT towards the RP.



PIM Bidir

PIM Bidir is significantly simpler in operation than PIM-SM.

It eliminates the maintenance of  (S,G) entries (only  (*,G) are kept) and there's no data driven events hence packets never need to be signaled and preserved (much more scalable for many-to-many applications).

Bidir PIM uses the Designated Forwarder (DF) election mechanism (based on routing protocol cost to the RP) to elect a single router on each link, which becomes responsible for the following tasks:
  • picking up packets from the link and forwarding them upstream towards the RP
  • forwarding downstream multicast packets from the RP onto the link

When configuring both sparse and bidir groups, you need to explicitly define them, because everything excluded from bidir is dense by default.

IOS
ip pim bidir-enable
ip pim rp-address 1.1.1.1 bidir

IOS-XR
router pim
 address-family ipv4
  rp-address 1.1.1.1 bidir


In some IOS-XR releases you might need to define the mcast bidir range of group addresses.

IOS
R2#sh ip pim rp map
PIM Group-to-RP Mappings

Group(s): 224.0.0.0/4, Static, Bidir Mode
    RP: 1.1.1.1 (?)

IOS-XR
GSR#sh pim group-map
Tue Feb  4 13:57:55.368 UTC

IP PIM Group Mapping Table
(* indicates group mappings being used)
(+ indicates BSR group mappings active in MRIB)

Group Range         Proto Client   Groups RP address      Info

224.0.1.39/32*      DM    perm     0      0.0.0.0
224.0.1.40/32*      DM    perm     1      0.0.0.0
224.0.0.0/24*       NO    perm     0      0.0.0.0
232.0.0.0/8*        SSM   config   0      0.0.0.0
224.0.0.0/4*        BD    config   1      1.1.1.1         RPF: Gi0/2/1/2.28,2.2.28.2
224.0.0.0/4         SM    static   0      0.0.0.0         RPF: Null,0.0.0.0


You will see only (*,G) entries for the bidir groups, no (S,G) entries.


PIM Register Tunnels

In latest software releases, PIM uses tunnel interfaces for RP Register communication. You can use "sh ip pim tunnel" in order to verify the PIM connectivity, either inside or outside a vrf. If no tunnel exists but should exist, then there is probably something wrong.

IOS
R1#sh ip pim tunnel
Tunnel0
  Type  : PIM Encap
  RP    : 10.0.0.1*
  Source: 10.0.0.1
Tunnel1*
  Type  : PIM Decap
  RP    : 10.0.0.1*
  Source: -
 
R1#sh ip pim vrf VPN tunnel
Tunnel1
  Type  : PIM Encap
  RP    : 10.0.0.1
  Source: 10.1.7.1

R1#sh int tun1 | i protocol/transport
  Tunnel protocol/transport PIM/IPv4


IOS-XR
GSR#sh pim tunnel info all
Fri Jun  9 06:04:51.319 UTC

Interface           RP Address      Source Address

Encapstunnel0       10.0.0.1        10.0.0.1
Decapstunnel0       0.0.0.0          -

The router acting as RP should have at least two PIM tunnels: one for Encapsulation (usually src=RP) and another one for Decapsulation. All other PIM routers should have only one for Encapsulation (src=local PIM address, dst=RP).


IGMP

You can use the following as multicast receiver.

IOS
interface X
 ip igmp join-group 224.1.1.1

IOS-XR
router igmp
 interface X
  join-group 232.1.1.1 192.168.1.1

PIM (sparse) is also required on the interface where IGMP is enabled.

"ip igmp static-group x.x.x.x" can also be used, if we want to avoid having the multicast traffic being processed by the router.

IGMP (v3) for SSM requires to also define the source of multicast traffic.

In IOS, when using multicast ping to test connectivity, the multicast packets go out through all multicast enabled interfaces by default (regardless of the source ip/interface chosen in CLI). If you want to send it out through a specific interface then you need to use extended ping and choose a specific interface in the "Interface" option.

IOS
R1#ping
Protocol [ip]:
Target IP address: 232.1.1.1
Repeat count [1]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Interface [All]: FastEthernet0/0
Time to live [255]:
Source address: 1.1.1.1


Posted by at
Labels: , , , , , , , , , , , , , , ,

2 comments:

  1. Unknown29 September, 2015 08:30

    Thank You. Good job.
    But ..... multicast range 224.0.0.0/4

    ReplyDelete

Subscribe to: Post Comments (Atom)