User Tools

Site Tools


latex2wiki:user_manual:pim_sparse_mode

PIM Sparse-Mode

Terminology and Concepts

PIM stands for Protocol Independent Multicast, and denotes a class of multicast routing protocols. The term protocol independent comes from the fact that PIM does not have its own topology discovery protocol, but instead relies on routing information supplied by protocols such as RIP and BGP. What PIM does do is to build multicast trees from senders to receivers based on paths determined by this external topology information.

There are two PIM protocols: * PIM Sparse-Mode (PIM-SM) is the most commonly used multicast routing protocol, and explicitly builds distribution trees from the receivers back towards senders. * PIM Dense-Mode (PIM-DM) is less commonly used, and builds trees by flooding multicast traffic domain-wide, and then pruning off branches from the tree where there are no receivers.

At the present time, XORP only implements PIM Sparse Mode.

PIM-SM Protocol Overview

The following description is adapted from the PIM-SM specification.

PIM-SM relies on an underlying topology-gathering protocol to populate a routing table with routes. This routing table is called the MRIB or Multicast Routing Information Base. The routes in this table may be taken directly from the unicast routing table, or it may be different and provided by a separate routing protocol such as Multi-protocol BGP.

Regardless of how it is created, the primary role of the MRIB in the PIM-SM protocol is to provide the next-hop router along a multicast-capable path to each destination subnet. The MRIB is used to determine the next-hop neighbor to which any PIM Join/Prune message is sent. Data flows along the reverse path of the Join messages. Thus, in contrast to the unicast RIB which specifies the next-hop that a data packet would take to get to some subnet, the MRIB gives reverse-path information, and indicates the path that a multicast data packet would take from its origin subnet to the router that has the MRIB.

Like all multicast routing protocols that implement the ASM service model, PIM-SM must be able to route data packets from sources to receivers without either the sources or receivers knowing a-priori of the exis- tence of the others. This is essentially done in three phases, although as senders and receivers may come and go at any time, all three phases may be occur simultaneously.

Phase One: RP Tree

In phase one, a multicast receiver expresses its interest in receiving traffic destined for a multicast group. Typically it does this using IGMP or MLD. One of the receiver’s local PIM routers is elected as the Desig- nated Router (DR) for that subnet. On receiving the receiver’s expression of interest, the DR then sends a PIM Join message towards the Rendezvous Point (RP) for that multicast group. The RP is a PIM-SM router that has been configured to serve a bootstrapping role for certain multicast groups. This Join message is known as a (*,G) Join because it joins group G for all sources to that group. The (*,G) Join travels hop- by-hop towards the RP for the group, and in each router it passes through, multicast tree state for group G is instantiated. Eventually the (*,G) Join either reaches the RP, or reaches a router that already has (*,G) Join state for that group. When many receivers join the group, their Join messages converge on the RP, and form a distribution tree for group G that is rooted at the RP. This is known as the RP Tree (RPT), and is also known as the shared tree because it is shared by all sources sending to that group. Join messages are resent periodically so long as the receiver remains in the group. When all receivers on a leaf-network leave the group, the DR will send a PIM (*,G) Prune message towards the RP for that multicast group. However if the Prune message is not sent for any reason, the state will eventually time out.

A multicast data sender just starts sending data destined for a multicast group. The sender’s local router (DR) takes those data packets, unicast-encapsulates them, and sends them directly to the RP. The RP receives these encapsulated data packets, decapsulates them, and forwards them onto the shared tree. The packets then follow the (*,G) multicast tree state in the routers on the RP Tree, being replicated wherever the RP Tree branches, and eventually reaching all the receivers for that multicast group. The process of encapsulating data packets to the RP is called registering, and the encapsulation packets are known as PIM Register packets.

At the end of phase one, multicast traffic is flowing encapsulated to the RP, and then natively over the RP tree to the multicast receivers.

Phase Two: Register-Stop

Register-encapsulation of data packets is inefficient for two reasons: * Encapsulation and decapsulation may be relatively expensive operations for a router to perform, depending on whether or not the router has appropriate hardware for these tasks. * Travelling all the way to the RP, and then back down the shared tree may entail the packets travelling a relatively long distance to reach receivers that are close to the sender. For some applications, this increased latency is undesirable.

Although Register-encapsulation may continue indefinitely, for the reasons above, the RP will normally choose to switch to native forwarding. To do this, when the RP receives a register-encapsulated data packet from source S on group G, it will normally initiate an (S,G) source-specific Join towards S. This Join message travels hop-by-hop towards S, instantiating (S,G) multicast tree state in the routers along the path. (S,G) multicast tree state is used only to forward packets for group G if those packets come from source S. Eventually the Join message reaches S’s subnet or a router that already has (S,G) multicast tree state, and then packets from S start to flow following the (S,G) tree state towards the RP. These data packets may also reach routers with (*,G) state along the path towards the RP - if so, they can short-cut onto the RP tree at this point.

While the RP is in the process of joining the source-specific tree for S, the data packets will continue being encapsulated to the RP. When packets from S also start to arrive natively at the the RP, the RP will be receiving two copies of each of these packets. At this point, the RP starts to discard the encapsulated copy of these packets, and it sends a Register-Stop message back to S’s DR to prevent the DR unnecessarily encapsulating the packets.

At the end of phase 2, traffic will be flowing natively from S along a source-specific tree to the RP, and from there along the shared tree to the receivers. Where the two trees intersect, traffic may transfer from the source-specific tree to the RP tree, and so avoid taking a long detour via the RP. It should be noted that a sender may start sending before or after a receiver joins the group, and thus phase two may happen before the shared tree to the receiver is built.

Phase 3: Shortest-Path Tree

Although having the RP join back towards the source removes the encapsulation overhead, it does not completely optimize the forwarding paths. For many receivers the route via the RP may involve a significant detour when compared with the shortest path from the source to the receiver. To obtain lower latencies, a router on the receiver’s LAN, typically the DR, may optionally initiate a transfer from the shared tree to a source-specific shortest-path tree (SPT). To do this, it issues an (S,G) Join towards S. This instantiates state in the routers along the path to S. Eventually this join either reaches S’s subnet, or reaches a router that already has (S,G) state. When this happens, data packets from S start to flow following the (S,G) state until they reach the receiver.

At this point the receiver (or a router upstream of the receiver) will be receiving two copies of the data - one from the SPT and one from the RPT. When the first traffic starts to arrive from the SPT, the DR or upstream router starts to drop the packets for G from S that arrive via the RP tree. In addition, it sends an (S,G) Prune message towards the RP. This is known as an (S,G,rpt) Prune. The Prune message travels hop- by-hop, instantiating state along the path towards the RP indicating that traffic from S for G should NOT be forwarded in this direction. The prune is propagated until it reaches the RP or a router that still needs the traffic from S for other receivers.

By now, the receiver will be receiving traffic from S along the shortest-path tree between the receiver and S. In addition, the RP is receiving the traffic from S, but this traffic is no longer reaching the receiver along the RP tree. As far as the receiver is concerned, this is the final distribution tree.

Multi-access Transit LANs

The overview so far has concerned itself with point-to-point links. However, using multi-access LANs such as Ethernet for transit is not uncommon. This can cause complications for three reasons:

* Two or more routers on the LAN may issue (*,G) Joins to different upstream routers on the LAN because they have inconsistent MRIB entries regarding how to reach the RP. Both paths on the RP tree will be set up, causing two copies of all the shared tree traffic to appear on the LAN. * Two or more routers on the LAN may issue (S,G) Joins to different upstream routers on the LAN because they have inconsistent MRIB entries regarding how to reach source S. Both paths on the source-specific tree will be set up, causing two copies of all the traffic from S to appear on the LAN. * A router on the LAN may issue a (*,G) Join to one upstream router on the LAN, and another router on the LAN may issue an (S,G) Join to a different upstream router on the same LAN. Traffic from S may reach the LAN over both the RPT and the SPT. If the receiver behind the downstream (*,G) router doesn’t issue an (S,G,rpt) prune, then this condition would persist.

All of these problems are caused by there being more than one upstream router with join state for the group or source-group pair. PIM-SM does not prevent such duplicate joins from occurring - instead when duplicate data packets appear on the LAN from different routers, these routers notice this, and then elect a single forwarder. This election is performed using PIM Assert messages, which resolve the problem in favor of the upstream router which has (S,G) state, or if neither or both router has (S,G) state, then in favor of the router with the best metric to the RP for RP trees, or the best metric to the source to source-specific trees.

These Assert messages are also received by the downstream routers on the LAN, and these cause subsequent Join messages to be sent to the upstream router that won the Assert.

RP Discovery

PIM-SM routers need to know the address of the RP for each group for which they have (*,G) state. This address is obtained either through a bootstrap mechanism or through static configuration.

One dynamic way to do this is to use the Bootstrap Router (BSR) mechanism. One router in each PIM-SM domain is elected the Bootstrap Router through a simple election process. All the routers in the domain that are configured to be candidates to be RPs periodically unicast their candidacy to the BSR. From the candidates, the BSR picks an RP-set, and periodically announces this set in a Bootstrap message. Bootstrap messages are flooded hop-by-hop throughout the domain until all routers in the domain know the RP-Set.

To map a group to an RP, a router hashes the group address into the RP-set using an order-preserving hash function (one that minimizes changes if the RP-Set changes). The resulting RP is the one that it uses as the RP for that group.

Standards

XORP is compliant with the following PIM-SM specification: * draft-ietf-pim-sm-v2-new-11. Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised). * draft-ietf-pim-sm-bsr-03. Bootstrap Router (BSR) Mechanism for PIM Sparse Mode.

Configuring PIM-SM

Configuring Multicast Routing on UNIX Systems

If XORP is to be run on a UNIX-based system, the following steps must be taken to enable the system for PIM-SM multicast routing before starting XORP: * Make sure that the underlying system supports multicast routing and has PIM-SM kernel support. Unfortunately, there is no trivial guideline how to check this, but the following OS-specific information can be useful:

  • DragonFlyBSD: DragonFlyBSD-1.0 and later.
  • FreeBSD: IPv4 (FreeBSD-4.9 and later, FreeBSD-5.2 and later), IPv6 (FreeBSD-4.x and later).
  • Linux: IPv4 (Linux-2.2.11 and later, Linux-2.3.6 and later), IPv6 (Linux 2.6.26 and later)
  • NetBSD: IPv4 (NetBSD-3.0 and later), IPv6 (NetBSD-1.5 and later).
  • OpenBSD: IPv4 (OpenBSD-3.7 and later), IPv6 (OpenBSD-2.7 and later).

* If necessary, configure the kernel to enable multicast routing and PIM-SM:

  • DragonFlyBSD:
            IPv4: enable the following options in the kernel:
            options                   MROUTING                             # Multicast routing
            options                   PIM                                  # PIM multicast routing
            IPv6: no kernel options are required.
  • FreeBSD:
            IPv4: enable the following option in the kernel:
            options                   MROUTING                             # Multicast routing
            For releases older than FreeBSD-7.0, the following option is needed as well:
            options                   PIM                                  # PIM multicast routing
            IPv6: no kernel options are required.
  • Linux:
            IPv4: enable the following options in the kernel:
            CONFIG_IP_MULTICAST=y
            CONFIG_IP_MROUTE=y
            CONFIG_IP_PIMSM_V2=y
            IPv6: Enable the following options in the kernel:
            CONFIG_IPV6_MROUTE=y
            CONFIG_IPV6_PIMSM_V2=y
  • NetBSD:
      IPv4: enable the following options in the kernel:
      options                  MROUTING                # IP multicast routing
      options                  PIM                     # Protocol Independent Multicast
      IPv6: no kernel options are required.
  • OpenBSD:
      IPv4: enable the following options in the kernel:
      option                   MROUTING                # Multicast router
      option                   PIM                     # Protocol Independent Multicast
      IPv6: no kernel options are required.

* Apply additional system configuration (if necessary):

  • DragonFlyBSD:
      IPv4: Enable IPv4 unicast forwarding:
      sysctl net.inet.ip.forwarding=1
      IPv6: Enable IPv6 unicast forwarding:
      sysctl net.inet6.ip6.forwarding=1
      See sysctl.conf(5) for information how to add the sysctl configuration permanently.
  • FreeBSD:
      IPv4: Enable IPv4 unicast forwarding:
      sysctl net.inet.ip.forwarding=1
      IPv6: Enable IPv6 unicast forwarding:
      sysctl net.inet6.ip6.forwarding=1
      See sysctl.conf(5) for information how to add the sysctl configuration permanently.
  • Linux:
      IPv4: Enable IPv4 unicast forwarding:
      echo 1 > /proc/sys/net/ipv4/ip_forward
      If the unicast Reverse Path Forwarding information is different from the multicast Reverse Path
      Forwarding information, the Return Path Filtering should be disabled:
      echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
      OR
      echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
      echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
      ...
      IPv6: Enable IPv4 forwarding
      echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
 
  • NetBSD: none.
  • OpenBSD:
             Enable multicast routing by adding the following lines to /etc/rc.conf.local and reboot:
             # Enable multicast routing (see netstart(8) for details).
             multicast_host=NO
             multicast_router=YES
             IPv4: Enable IPv4 multicast forwarding (for OpenBSD-3.9 and later):
             sysctl net.inet.ip.mforwarding=1
             IPv6: Enable IPv6 multicast forwarding (for OpenBSD-4.0 and later):
             sysctl net.inet6.ip6.mforwarding=1
             See sysctl.conf(5) for information how to add the sysctl configuration permanently.
             Note that XORP itself automatically enables the above sysctl multicast forwarding flags, hence
             it is not really necessary to set them manually. The flags are described for completeness and in
             case someone needs better control over multicast forwarding.

Configuring Multicast Tunnels on UNIX Systems

All PIM routers need to be directly connected so they can exchange control messages. Occasionally this might not be possible (e.g., if someone wants to forward multicast traffic to a remote host, and the routers in the middle are not running PIM).

In that case a tunnel between two remote routers can be used to create an artificial adjacency.

Creating a GRE tunnel

The GRE (Generic Routing Encapsulation) mechanism is described in RFC 1701 and RFC 1702. It is implemented on a variety of systems and is widely used for routing tunnels. Below is an example how to configure a GRE tunnel between two Linux systems.

       # GRE tunnel between two machines (host 11.11.11.11 and 33.33.33.33)
       #
       # Physical interfaces:                    [11.11.11.11]                  [33.33.33.33]
       # GRE tunnel:                              22.22.22.11<--------->22.22.22.33
       #
       # ==== host 11.11.11.11 (GRE interface 22.22.22.11)
       ip link set gre1 down
       ip tunnel del gre1
       ip tunnel add gre1 mode gre remote 33.33.33.33 local 11.11.11.11 ttl 127
       ip addr add 22.22.22.11/24 peer 22.22.22.33/24 dev gre1
       ip link set gre1 up multicast on
                                                      155
  # ==== host 33.33.33.33 (GRE interface 22.22.22.33)
  ip link set gre1 down
  ip tunnel del gre1
  ip tunnel add gre1 mode gre remote 11.11.11.11 local 33.33.33.33 ttl 127
  ip addr add 22.22.22.33/24 peer 22.22.22.11/24 dev gre1
  ip link set gre1 up multicast on

Creating an OpenVPN tunnel

OpenVPN (http://openvpn.net/) is free software to create a VPN tunnel. It is very popular and works on a variety of systems. One of the advantages of OpenVPN is that it is over TCP or UDP, hence unlike GRE it does not require special support from NAT devices that might be in the middle. Below is an example how to configure an OpenVPN tunnel.

  # OpenVPN tunnel between two machines (host 11.11.11.11 and 33.33.33.33)
  #
  # Physical interfaces:                     [11.11.11.11]                 [33.33.33.33]
  # OpenVPN tunnel:                           22.22.22.11<--------->22.22.22.33
  #
  # ==== host 11.11.11.11 (OpenVPN interface 22.22.22.11)
  openvpn --local 11.11.11.11 --remote 33.33.33.33 --ifconfig 22.22.22.11
         22.22.22.33 --dev tun0
  # ==== host 33.33.33.33 (OpenVPN interface 22.22.22.33)
  openvpn --local 33.33.33.33 --remote 11.11.11.11 --ifconfig 22.22.22.33
         22.22.22.11 --dev tun0

Reverse Path Forwarding (RPF) information setup.

It is important that the Reverse Path Forwarding (RPF) information is set to consider the tunnel for PIM-SM to operate properly. On Linux systems the following UNIX command needs to be used to disable the Return Path filtering:

  echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter 

In addition, the RPF information must be set appropriately for all systems that are suppose to be reached via the tunnel (e.g., RPs and remote sources). This can be achieved by adding MRIB-specific static routing entries in the XORP configuration. For example, if the IP address of the other side of the tunnel is 22.22.22.33, then the following XORP configuration can be used to specify that the tunnel is the default route for all destinations:

  protocols {
         static {
               mrib-route 0.0.0.0/0 {
                      next-hop 22.22.22.33
               }
         }
  }

Configuration Syntax

protocols {
    pimsm4 {
       targetname: text
       disable: bool
       interface text {
         vif text {
            disable: bool
            dr-priority: uint
            hello-period: uint(1..18724)
            hello-triggered-delay: uint(1..255)
            alternative-subnet IPv4/int(0..32)
         }
       }
       interface register vif {
         vif register vif {
            disable: bool
         }
       }
       static-rps {
         rp IPv4 {
            group-prefix IPv4Mcast/int(4..32) {
               rp-priority: uint(0..255)
               hash-mask-len: uint(4..32)
            }
         }
       }
       bootstrap {
         disable: bool
         cand-bsr {
            scope-zone IPv4Mcast/int(4..32) {
               is-scope-zone: bool
               cand-bsr-by-vif-name: text
               cand-bsr-by-vif-addr: IPv4
               bsr-priority: uint(0..255)
               hash-mask-len: uint(4..32)
            }
         }
         cand-rp {
            group-prefix IPv4Mcast/int(4..32) {
               is-scope-zone: bool
               cand-rp-by-vif-name: text
               cand-rp-by-vif-addr: IPv4
               rp-priority: uint(0..255)
               rp-holdtime: uint(0..65535)
            }
         }
       }
       switch-to-spt-threshold {
         disable: bool
         interval: uint(3..2147483647)
         bytes: uint
       }
    }

    traceoptions {
      flag all {
        disable: bool
      }
    }
  }
}

protocols {
  pimsm6 {
    disable: bool
    interface text {
      vif text {
        disable: bool
        dr-priority: uint
        hello-period: uint(1..18724)
        hello-triggered-delay: uint(1..255)
        alternative-subnet IPv6/int(0..128)
      }
    }
    interface register vif {
      vif register vif {
        disable: bool
      }
    }
    static-rps {
      rp IPv6 {
        group-prefix IPv6Mcast/int(8..128) {
           rp-priority: uint(0..255)
           hash-mask-len: uint(8..128)
        }
      }
    }
    bootstrap {
      disable: bool
      cand-bsr {
        scope-zone IPv6Mcast/int(8..128) {
           is-scope-zone: bool
           cand-bsr-by-vif-name: text
           cand-bsr-by-vif-addr: IPv6
           bsr-priority: uint(0..255)
           hash-mask-len: uint(8..128)
        }
      }
      cand-rp {
        group-prefix IPv6Mcast/int(8..128) {
           is-scope-zone: bool
           cand-rp-by-vif-name: text
           cand-rp-by-vif-addr: IPv6
           rp-priority: uint(0..255)
           rp-holdtime: uint(0..65535)
        }
      }
    }
    switch-to-spt-threshold {
      disable: bool
      interval: uint(3..2147483647)
      bytes: uint
    }
    traceoptions {
      flag all {
        disable: bool
      }
    }
  }
}
Option Description
protocols this delimits the configuration for all routing protocols in the XORP router configuration. It is mandatory that PIM-SM configuration is under the protocols node in the configuration.
pimsm4 this delimits the PIM-SM configuration part of the XORP router configuration related to IPv4 multicast.
targetname this is the name for this instance of PIM-SM for IPv4. It defaults to “PIMSM 4”, and it is not recommended that this default is overridden under normal usage scenarios.
disable this takes the value true or false, and indicates whether PIM-SM IPv4 multicast routing is currently disabled 1 . This allows multicast to be taken down temporarily without removing the configuration.
interface this directive specifies that this interface is to be used for PIM-SM IPv4 multicast routing. The parameter value must be the name of an interface that has been configured in the interfaces section of the router configuration.
vif this directive specifies that this vif on the specified interface is to be used for PIM-SM IPv4 multicast routing. The parameter value must be the name of a vif that has been configured in the interfaces section of the router configuration. A special logical interface called register vif with a special vif called register vif must be configured if a PIM-SM router is to be able to send Register messages to the RP. In general this should always be configured if the router is to support the ASM multicast service model. Each vif can take the following optional parameters:
       disable: this takes the value true or false, and indicates whether PIM-SM IPv4 multicast
         outing is currently disabled on this interface/vif 2.
       dr-priority: this directive takes a non-negative integer as its parameter giving this
         router’s Designated Router (DR) priority for this interface/vif. The default is 1.
         The PIM router on this subnet with the highest value of DR priority will become the
         DR for the subnet.
       hello-period: this directive specifies the PIM Hello period (in seconds) for this
         interface/vif 3 . It takes a non-negative integer in the interval [1..18724]. The
         default is 30. Every hello-period seconds the PIM router will transmit a PIM Hello
         message on the interface/vif. If the receivers of the PIM Hello message do not
         receive another Hello message for 3.5 * hello-period seconds, they will timeout
         the neighbor state for this router.
       hello-triggered-delay: this directive specifies the randomized triggered delay of
         the PIM Hello messages (in seconds) for this interface/vif 4 . It takes a
         non-negative integer in the interval [1..255]. The default is 5. When PIM is
         enabled on an interface or a router first starts, the Hello Timer of that
         interface is set to a random value between 0 and hello-triggered-delay.
         This prevents synchronization of Hello messages if multiple routers are
         powered on simultaneously.
       alternative-subnet: this directive is used to associate additional IP subnets
         with a network interface. The parameter value is an IPv4 subnet address in the
         address/prefix-length format.  One use of this directive is to make incoming
         traffic with a non-local source address appear as it is coming from a local
         subnet. Typically, this is needed as a work-around solution when uni-directional
         interfaces such as satellite links are used for receiving traffic. The
         alternative-subnet directive should be used with extreme care, because it is
         possible to create forwarding loops. 
static-rps this delimits the part of the PIM-SM configuration used to manually configure PIM RP router information. A PIM-SM router must either have some RPs configured as static RPs, or it must run the PIM-SM bootstrap mechanism (see the bootstrap directive). Under the static-rps part of the configuration, one or more RPs can be configured. It is important that all routers in a PIM domain make the same choice of RP for the same multicast group, so generally they should be configured with the same RP information.
       rp: this specifies the IPv4 address of a router to be a static RP.
             For each RP, the following parameters can be configured:
               group-prefix: this specifies the range of multicast addresses for which the specified router
                   is willing to be the RP. The value is in the form of an IP address and prefix-length in the
                   address/prefix-length format.
                     rp-priority: this specifies the priority of the specified RP router. It takes the form of
                        a non-negative integer in the interval [0, 255]. Smaller value means higher priority.
                        If multiple RP routers are known for a particular multicast group, then the one with the
                        most specific group-prefix will be used. If more than one router has the same most
                        specific group-prefix, then the one with the highest rp-priority is used. See also
                        hash-mask-len.
                        The default value is 192.
                     hash-mask-len: If multiple routers have the most specific group-prefix and the
                        same highest rp-priority, then to balance load, a hash function is used to choose
                        the RP. However, it is usually desirable for closely associated multicast groups to use
                        the same RP. Thus the hash function is only applied to the first n bits of the group IP
                        address, ensuring that if two groups have the same first n bits, they will hash to the
                        same RP address. The hash-mask-len parameter specifies the value of n. For IPv4 it
                        must be in the interval [4, 32], and defaults to 30 bits. Typically its value shouldn’t be
                        changed. If it is modified then all PIM-SM routers must be configured with the same
                        value.
bootstrap this delimits the part of the PIM-SM configuration used to configure the automatic bootstrap of PIM RP router information using the PIM BootStrap Router mechanism. A PIM-SM router must either run the PIM-SM bootstrap mechanism, or have some RPs configured as static RPs (see the static-rps directive). Under the bootstrap directive, the following additional information can be configured.
       disable: this takes the value true or false, and determines whether or not the router will run
             the bootstrap mechanism 5 . The default is false.

       cand-bsr: this directive specifies that this router is to be a candidate to be the BootStrap Router
             (BSR) for this PIM-SM domain. It will become the BSR only if it wins the BSR election process.
             One or more scope-zones must be specified for a candidate BSR router:
               scope-zone: this directive specifies one multicast group prefix for which this router is will-
                  ing to be BSR.
                  For each scope zone, the following information can be specified:
                   is-scope-zone: this directive takes the value true or false. When the value is
                       true, this indicates that this multicast group prefix defines a multicast scope zone.
                       When the value is false, this indicates that the group prefix in the scope-zone di-
                       rective merely represents a range of multicast groups for which this router is willing to
                       be BSR. The default is false.
                   cand-bsr-by-vif-name: this specifies the name of the vif whose IP address will
                       be used in the PIM bootstrap messages. It is a mandatory parameter.
                   cand-bsr-by-vif-addr: this specifies the address that will be used in the PIM boot-
                       strap messages. This address must belong to the vif specified by cand-bsr-by-vif-name.
                       If it is omitted, a domain-wide address (if exists) that belongs to that interface is chosen
                       by the router itself 6 .
                   bsr-priority: this specifies the BSR priority for this router. It takes a positive integer
                       value in the interval [0, 255], which is used in the PIM-SM BSR election process.
                       Larger value means higher priority. For each scope-zone, the candidate bootstrap
                       router with the highest BSR priority will be chosen to be BSR. Its default value is 1.
                   hash-mask-len: The BSR mechanism announces a list of candidate RPs (C-RPs) for
                       each scope zone to the other routers in the scope zone. To balance load, those routers
                       then use a hash function to choose the RP for each multicast group from amongst the
                       C-RPs. However, it is usually desirable for closely associated multicast groups to use
                       the same RP. Thus the hash function is only applied to the first n bits of the group
                       IP address, ensuring that if two groups have the same first n bits, they will hash to
                       the same RP address. Should this router become the BSR for this scope-zone, the
                       hash-mask-len parameter gives the value of n that this router will inform other
                       routers they must use. For IPv4 it must be in the interval [4, 32], and defaults to 30
                       bits. Typically its value shouldn’t be changed. If it is modified then all PIM-SM routers
                       must be configured with the same value.
cand-rp this directive specifies that this router is to be a candidate to be an RP for this PIM-SM domain. It will become an RP only if the BSR chooses it to be. One or more group-prefixes must be specified for this router to function as an RP:
       group-prefix: this specifies the range of multicast addresses for which the specified router
             is willing to be the RP. The value is in the form of an IP address and prefix length in the
             address/prefix-length format.
             For each group-prefix, the following parameters can be specified:
               is-scope-zone: this directive takes the value true or false. When the value is true, this
                  indicates that this multicast group prefix defines a multicast scope zone. When the value is
                  false, this indicates that the group prefix in the scope-zone directive merely represents
                  a range of multicast groups for which this router is willing to be RP. The default is false.

                cand-rp-by-vif-name: this specifies the name of the vif whose IP address will be used
                    as the RP address if this router becomes an RP. It is a mandatory parameter.
                cand-rp-by-vif-addr: this specifies the address that will be used as the RP address if
                    this router becomes an RP. This address must belong to the vif specified by cand-rp-by-vif-name.
                    If it is omitted, a domain-wide address (if exists) that belongs to that interface is chosen by
                    the router itself 7 .
                rp-priority: this specifies the RP priority of this router for this group-prefix. It takes
                    the form of a non-negative integer in the interval [0, 255].
                    If multiple RP routers are known for a particular multicast group, then the one with the
                    most specific group-prefix will be used. If more than one router has the same most
                    specific group-prefix, then the one with the highest rp-priority is used. See also
                    hash-mask-len.
                    The default value for rp-priority is 1.
                rp-holdtime: this specifies the holdtime that this router will advertise when talking to
                    the BSR. If the BSR has not heard a Candidate RP Advertisement from this router for
                    rp-holdtime seconds, then the BSR will conclude it is dead, and will remove it from the
                    set of possible RPs. It takes the form of a non-negative integer in the interval [0, 65535]
                    and its default value is 150 seconds.
      Note that a PIM-SM router that participates in the Bootstrap mechanism, but is not a Candidate BSR
      or a Candidate RP must have an explicit bootstrap block to enable the Bootstrap mechanism (this
      block could be empty).
switch-to-spt-threshold this directive permits the specification of a bitrate threshold at a last-hop router or RP for switching from the RP Tree to the Shortest-Path Tree. The following parameters can be specified:
        disable: this takes the value true or false, and determines whether bitrate-based switching to
              the shortest path tree is disabled 8 . The default is false.
        interval: this specifies the measurement interval in seconds for measuring the bitrate of traffic
              from a multicast sender 9 . The measurement interval should normally not be set too small -
              values greater than ten seconds are recommended. It takes the form of a non-negative integer in
              the interval [3, 2147483647] and its default value is 100 seconds.
        bytes: this specifies the maximum number of bytes from a multicast sender that can be received
              in interval seconds. If this threshold is exceeded, the router will attempt to switch to the
              shortest-path tree from that multicast sender. If the shortest-path switch should happen right
              after the first packet is forwarded, then bytes should be set to 0.
traceoptions this directive delimits the configuration of debugging and tracing options for PIM-SM.
        flag: this directive is used to specify which tracing options are enabled. Possible parameters are:
                all: this directive specifies that all tracing options should be enabled. Possible parameters
                    are:
                      disable: this takes the value true or false, and disables or enables tracing 10 . The
                          default is false.

Note that in case of PIM-SM for IPv4 each enabled interface must have a valid IPv4 address. The configuration for PIM-SM for IPv6 is identical to PIM-SM for IPv4, except for the following:

  • The pimsm6 directive is used in place of the pimsm4 directive.
  • The default value of targetname is ‘‘PIMSM 6’’ instead of ‘‘PIMSM 4’’.
  • All IP addresses used in the configuration are IPv6 addresses instead of IPv4 addresses.
  • The hash-mask-len value must be in the interval [8, 128], and defaults to 126.
  • Each enabled interface must have a valid link-local and a valid domain-wide IPv6 addresses.

Example Configurations

protocols {
   pimsm4 {
      disable: false
      interface dc0 {
        vif dc0 {
           disable: false
           /* dr-priority: 1 */
           /* hello-period: 30 */
           /* alternative-subnet 10.40.0.0/16 */
        }
      }
      interface register vif {
        vif register vif {
           /* Note: this vif should be always enabled */
           disable: false
        }
      }
      static-rps {
        rp 10.60.0.1 {
           group-prefix 224.0.0.0/4 {
              /* rp-priority: 192 */
              /* hash-mask-len: 30 */
           }
        }
      }
      bootstrap {
        disable: false
        cand-bsr {
           scope-zone 224.0.0.0/4 {
              /* is-scope-zone: false */
              cand-bsr-by-vif-name: "dc0"
              /* cand-bsr-by-vif-addr: 10.10.10.10 */
              /* bsr-priority: 1 */
              /* hash-mask-len: 30 */
           }
        }
        cand-rp {
           group-prefix 224.0.0.0/4 {
              /* is-scope-zone: false */
              cand-rp-by-vif-name: "dc0"
              /* cand-rp-by-vif-addr: 10.10.10.10 */
              /* rp-priority: 192 */
              /* rp-holdtime: 150 */
           }
        }
      }
      switch-to-spt-threshold {
        /* approx. 1K bytes/s (10Kbps) threshold */
        disable: false
        interval: 100
        bytes: 102400
      }
    }
    traceoptions {
      flag all {
        disable: false
      }
    }
  }
}
protocols {
  pimsm6 {
    disable: false
    interface dc0 {
      vif dc0 {
        disable: false
        /* dr-priority: 1 */
        /* hello-period: 30 */
        /* alternative-subnet 2001:DB8:40:40::/64 */
      }
    }
    interface register vif {
      vif register vif {
        /* Note: this vif should be always enabled */
        disable: false
      }
    }
    static-rps {
      rp 2001:DB8:50:50:50:50:50:50 {
        group-prefix ff00::/8 {
           /* rp-priority: 192 */
           /* hash-mask-len: 126 */
        }
      }
    }
    bootstrap {
      disable: false
      cand-bsr {
        scope-zone ff00::/8 {
           /* is-scope-zone: false */
           cand-bsr-by-vif-name: "dc0"
           /* cand-bsr-by-vif-addr: 2001:DB8:10:10:10:10:10:10 */
           /* bsr-priority: 1 */
           /* hash-mask-len: 126 */
        }
      }
      cand-rp {
        group-prefix ff00::/8 {
           /* is-scope-zone: false */
           cand-rp-by-vif-name: "dc0"
           /* cand-rp-by-vif-addr: 2001:DB8:10:10:10:10:10:10 */
           /* rp-priority: 192 */
           /* rp-holdtime: 150 */
        }
      }
    }
    switch-to-spt-threshold {
      /* approx. 1K bytes/s (10Kbps) threshold */
      disable: false
      interval: 100
      bytes: 102400
    }
    traceoptions {
      flag all {
        disable: false
      }
    }
  }
}

Monitoring PIM-SM

All operational commands for monitoring PIM-SM for IPv4 begin with show pim. This section describes those commands in details. All operational commands for monitoring PIM-SM for IPv6 are similar except that they begin with show pim6.

Monitoring PIM-SM Bootstrap Information

The show pim bootstrap command can be used to display information about PIM bootstrap routers:

 user@hostname> show pim bootstrap
 Active zones:
 BSR              Pri LocalAddress         Pri State        Timeout SZTimeout
 10.4.0.1           1 10.2.0.2               1 Candidate         75           -1
 Expiring zones:
 BSR              Pri LocalAddress         Pri State        Timeout SZTimeout
 Configured zones:
 BSR              Pri LocalAddress         Pri State        Timeout SZTimeout
 10.2.0.2           1 10.2.0.2               1 Init              -1           -1

The bootstrap information is separated in three sections:

  • Active zones: This section contains the bootstrap zones that are currently in use.
  • Expiring zones: If new bootstrap information is received and it replaces the old bootstrap information, the old information is deleted. However, if some of the old bootstrap information was not replaced, that information is moved to the Expiring zones section until it times out.
  • Configured zones: This section contains the bootstrap zones that are configured on the router.

The fields for each entry (in order of appearance) are:

  • BSR: The address of the Bootstrap router for the zone.
  • Pri: The priority of the Bootstrap router.
  • LocalAddress: The local Candidate-BSR address for the zone (if the router is configured as a Candidate-BSR).
  • Pri: The local Candidate-BSR priority for the zone (if the router is configured as a Candidate-BSR).
  • State: The state of the per-scope-zone state machine. In the above example, the router is configured as a Candidate-BSR, but it is not the elected BSR, hence its state is Candidate.
  • Timeout: The number of seconds until the BSR times-out. If it is -1, it will never timeout.
  • SZTimeout: The number of seconds until the scoped zone times-out. If it is -1, it will never timeout.

166 The show pim bootstrap rps command can be used to display information about Candidate RP information received by the Bootstrap mechanism:

 user@hostname> show   pim bootstrap rps
 Active RPs:
 RP                Pri Timeout GroupPrefix BSR           CandRpAdvTimeout
 10.4.0.1          192     148 224.0.0.0/4 10.4.0.1                    -1
 10.2.0.2          192     148 224.0.0.0/4 10.4.0.1                    -1
 Expiring RPs:
 RP                Pri Timeout GroupPrefix BSR           CandRpAdvTimeout
 Configured RPs:
 RP                Pri Timeout GroupPrefix BSR           CandRpAdvTimeout
 10.2.0.2          192      -1 224.0.0.0/4 10.2.0.2                    58

The Candidate RPs information is separated in three sections:

  • Active RPs: This section contains the Candidate RPs that are currently in use.
  • Expiring RPs: If new bootstrap information is received and it replaces the old bootstrap information, the old information is deleted. However, if some of the old bootstrap information was not replaced, the Candidate RPs contained in that information are moved to the Expiring RPs section until they time-out.
  • Configured RPs: This section contains the Candidate RP information that is configured on the router.

The fields for each entry (in order of appearance) are:

  • RP: The address of the Candidate RP for the entry.
  • Pri: The priority of the Candidate RP.
  • Timeout: The number of seconds until the Candidate RP times-out. If it is -1, it will never timeout.
  • GroupPrefix: The multicast group prefix address the Candidate RP is advertising.
  • BSR: The address of the BSR that advertised this Candidate RP.
  • CandRpAdvTimeout: The number of seconds until the Candidate RP is advertised to the BSR. This applies only for the Candidate-RPs configured in this router. If it is -1, the Candidate RP is not advertised to the BSR.

Monitoring PIM-SM Interface Information

The show pim interface command can be used to display information about PIM network interfaces:

 user@hostname> show pim interface
 Interface     State     Mode    V PIMstate Priority DRaddr           Neighbors
 dc1           UP        Sparse 2 NotDR             1 10.3.0.2                  1
 dc2           UP        Sparse 2 DR                1 10.2.0.2                  0
 register vif UP         Sparse 2 DR                1 10.3.0.1                  0

The fields for each entry (in order of appearance) are:

  • Interface: The name of the interface.
  • State: The state of the interface. E.g. UP, DOWN, DISABLED, etc.
  • Mode: The PIM mode of the interface. E.g. Sparse means PIM-SM.
  • V: The protocol version.
  • PIMstate: The protocol state on that interface. E.g., DR means the router is the Designated Router on that interface.
  • Priority: The configured Designated Router priority on that interface.
  • DRaddr: The address of the elected Designated Router on the subnet connected to that interface.
  • Neighbors: The number of PIM neighbor routers on that interface.

The show pim interface address command can be used to display address information about PIM network interfaces:

 user@hostname> show pim interface address
 Interface     PrimaryAddr       DomainWideAddr   SecondaryAddr
 dc1           10.3.0.1          10.3.0.1
 dc2           10.2.0.2          10.2.0.2
 register vif 10.3.0.1           10.3.0.1

The fields for each entry (in order of appearance) are:

  • Interface: The name of the interface.
  • PrimaryAddr: The primary address on the interface.
  • DomainWideAddr: The domain-wide address on the interface.
  • SecondaryAddr: The first secondary address on the interface (if any). If there is more than one secondary address on the interface, they are printed one per new line (in the same column).

Monitoring PIM-SM Multicast Routing State Information

The show pim join command can be used to display information about PIM multicast routing state:

 user@hostname> show pim join
 Group             Source           RP              Flags
 224.0.1.20        0.0.0.0          10.2.0.2        WC
      Upstream interface (RP):     register vif
      Upstream MRIB next hop (RP): UNKNOWN
      Upstream RPF’(*,G):          UNKNOWN
      Upstream state:              Joined
      Join timer:                  21
      Local receiver include WC: .O.
      Joins RP:                    ...
      Joins WC:                    ...
      Join state:                  ...
      Prune state:                 ...
      Prune pending state:         ...
      I am assert winner state: ...
      I am assert loser state:     ...
      Assert winner WC:            ...
      Assert lost WC:              ...
      Assert tracking WC:          .OO
      Could assert WC:             .O.
      I am DR:                     .OO
      Immediate olist RP:          ...
      Immediate olist WC:          .O.
      Inherited olist SG:          .O.
      Inherited olist SG RPT:      .O.
      PIM include WC:              .O.

The fields for each entry (in order of appearance) are:

  • Group: The group address.
  • Source: The source address.
  • RP: The address of the RP for this entry.
  • Flags: The set of flags for this entry. For example:
    • RP: (*,*,RP) routing entry.
    • WC: (*,G) routing entry.
    • SG: (S,G) routing entry.
    • SG RPT: (S,G,rpt) routing entry.
    • SPT: The routing entry has the Shortest-Path Tree flag set.
    • DirectlyConnectedS: The routing entry is for a directly-connected source.

The remaining lines per entry display various additional information for that entry. Some of the information below contains a set of network interfaces: there is either “.” or “O” per interface (starting with the first interface according to the show pim interface command), and if an interface is included, it is marked with “O”.

  • Upstream interface (RP): The name of the upstream interface toward the RP.
  • Upstream MRIB next hop (RP): The address of the next-hop router (according to the MRIB) toward the RP. In the above example the router itself is the RP, hence there is no next-hop router.
  • Upstream RPF’(*,G): The address of the next-hop router (according to PIM) toward the RP. Note that this address may be different, because it may be affected by PIM-specific events such as PIM Assert messages on the upstream interface. In the above example the router itself is the RP, hence there is no next-hop router.
  • Upstream state: The upstream state of this entry.
  • Join timer: The number of seconds until the upstream Join timer timeout.
  • Local receiver include WC: The set of interfaces that have local (*,G) receivers according to the MLD/IGMP module.
  • Joins RP: The set of interfaces that have received (*,*,RP) Join.
  • Joins WC: The set of interfaces that have received (*,G) Join.
  • Join state: The set of interfaces that are in Join state.
  • Prune state: The set of interfaces that are in Prune state.
  • Prune pending state: The set of interfaces that are in Prune-Pending state.
  • I am assert winner state: The set of interfaces that are in Assert Winner state.
  • I am assert loser state: The set of interfaces that are in Assert Loser state.
  • Assert winner WC: The set of interfaces for which the corresponding (*,G) entry is in Assert Winner state.
  • Assert lost WC: The set of interfaces for which the corresponding (*,G) entry has lost the PIM Assert.
  • Assert tracking WC: The set of interfaces for which the corresponding (*,G) entry desires to track the PIM Asserts.
  • Could assert WC: The set of interfaces for which the corresponding (*,G) entry could trigger a PIM Assert.
  • I am DR: The set of interfaces for which this is the Designated Router.
  • Immediate olist RP: The set of interfaces that are included in the immediate outgoing interfaces for the corresponding (*,*,RP) entry.
  • Immediate olist WC: The set of interfaces that are included in the immediate outgoing interfaces for the corresponding (*,RP) entry.
  • Inherited olist SG: The set of interfaces that are included in the outgoing interface list for packets forwarded on (S,G) state taking into account (*,*,RP) state, (*,G) state, asserts, etc.
  • Inherited olist SG RPT: The set of interfaces that are included in the outgoing interface list for packets forwarded on (*,*,RP) or (*,G) state taking into account (S,G,rpt) prune state, and asserts, etc.
  • PIM include WC: The set of interfaces to which traffic might be forwarded because of hosts that are local members on that interface.

The show pim join all command can be used to display information about all PIM multicast routing entries including those that may be created internally by the PIM implementation. Typically, those are the (*,*,RP) entries that are created per RP for implementation-specific reasons even though there is no requirement to do so. Currently, this command is used only for debugging purpose.

Monitoring PIM-SM Multicast Routing State Information

The show pim mfc command can be used to display information about PIM multicast forwarding entries that are installed in the multicast forwarding engine:

 user@hostname> show pim mfc
 Group              Source             RP
 224.0.1.20         10.4.0.2           10.2.0.2
      Incoming interface :            register vif
      Outgoing interfaces:            .O.

The fields for each entry (in order of appearance) are:

  • Group: The group address.
  • Source: The source address.
  • RP: The address of the RP for this entry.

The remaining lines per entry display various additional information for that entry. Some of the information below contains a set of network interfaces: there is either “.” or “O” per interface (starting with the first interface according to the show pim interface command), and if an interface is included, it is marked with “O”.

  • Incoming interface: The name of the incoming interface.
  • Outgoing interfaces: The set of outgoing interfaces.

Monitoring PIM-SM Multicast Routing Information Base

The show pim mrib command can be used to display information about the Multicast Routing Information Base (MRIB) that is used by PIM:

 user@hostname> show pim mrib
 DestPrefix             NextHopRouter     VifName VifIndex MetricPref Metric
 10.2.0.0/24            10.2.0.2          dc2     1                 0      0
 10.3.0.0/24            10.3.0.1          dc1     0                 0      0
 10.4.0.0/24            10.3.0.2          dc1     0               254 65535
 10.5.0.0/24            10.2.0.4          dc2     1               254 65535
 10.6.0.0/24            10.2.0.1          dc2     1               254 65535

The fields for each entry (in order of appearance) are:

  • DestPrefix: The destination prefix address.
  • NextHopRouter: The address of the next-hop router toward the destination.
  • VifName: The name of the virtual interface toward the destination.
  • VifIndex: The virtual interface index of the virtual interface toward the destination.
  • MetricPref: The metric preference of the entry.
  • Metric: The routing metric of the entry.

Monitoring PIM-SM Multicast Routing Information Base

The show pim neighbors command can be used to display information about the PIM neighbor routers:

 user@hostname> show pim neighbors
 Interface     DRpriority NeighborAddr       V Mode    Holdtime Timeout
 dc1                     1 10.3.0.2          2 Sparse       105      97

The fields for each entry (in order of appearance) are:

  • Interface: The name of the interface toward the neighbor:
  • DRpriority: The DR priority of the neighbor.
  • NeighborAddr: The primary address of the neighbor.
  • V: The PIM protocol version used by the neighbor.
  • Mode: The PIM mode of the neighbor. E.g. Sparse means PIM-SM.
  • Holdtime: The PIM Hello holdtime of the neighbor (in seconds).
  • Timeout: The number of seconds until the neighbor timeout (in case no more PIM Hello messages are received from it).

Monitoring PIM-SM Candidate RP Set Information

The show pim rps command can be used to display information about the Candidate RP Set:

 user@hostname> show pim rps
 RP               Type        Pri Holdtime Timeout ActiveGroups GroupPrefix
 10.4.0.1         bootstrap 192         150     134             0 224.0.0.0/4
 10.2.0.2         bootstrap 192         150     134             1 224.0.0.0/4

The fields for each entry (in order of appearance) are:

  • RP: The address of the Candidate RP.
  • Type: The type of the mechanism that provided the Candidate RP.
  • Pri: The priority of the Candidate RP.
  • Holdtime: The holdtime (in number of seconds) of the Candidate RP.
  • Timeout: The number of seconds until the Candidate RP timeout. If it is -1, the Candidate RP will never timeout.
  • ActiveGroups: The number of groups that use this Candidate RP.
  • GroupPrefix: The multicast group prefix address for this Candidate RP.

Monitoring PIM-SM Scope Zone Information

The show pim scope command can be used to display information about the PIM scope zones:

 user@hostname> show pim scope
 GroupPrefix                                     Interface
 225.1.2.0/24                                    dc1

The fields for each entry (in order of appearance) are:

  • GroupPrefix: The multicast group prefix address of the scoped zone.
  • Interface: The name of the interface that is the boundary of the scoped zone. Note that currently (July 2008), configuring multicast scoped zones is not supported. This feature should be added in the future.
latex2wiki/user_manual/pim_sparse_mode.txt · Last modified: 2011/03/11 02:09 by Ben Greear