Configuring RSVP-TE P2MP Tunnels

RSVP-TE P2MP Tunnels adds support for Point-to-Multipoint (P2MP) tunnels to be used in Multicast Virtual Private Network (MVPN).

There are two major parts to the configuration for RSVP-TE P2MP tunnels: BGP and RSVP.

BGP Configuration

To enable MVPN using an RSVP P2MP tunnel, set the default encapsulation to mpls protocol rsvp p2mp. An RSVP P2MP tunnel profile can be configured for the VRF, as shown in the following example. It can also be configured for all VRFs under the address-family mvpn-ipv4 configuration mode within router bgp. If the tunnel profile is not configured, an implicit default profile is used, which does not contain any configuration options, as outlined in the Default Tree Specification section. 

switch# config 
switch(config)# router bgp 
switch(config-router-bgp)# show active 
router bgp 100 
 neighbor 4.4.4.4 remote-as 100 
 neighbor 4.4.4.4 update-source Loopback0 
 neighbor 4.4.4.4 send-community extended 
 neighbor 5.5.5.5 remote-as 100 
 neighbor 5.5.5.5 update-source Loopback0 
 neighbor 5.5.5.5 send-community extended 
 ! 
 address-family mvpn-ipv4 
  neighbor 4.4.4.4 activate 
  neighbor 5.5.5.5 activate 
  neighbor default encapsulation mpls protocol rsvp p2mp 
 ! 
 address-family vpn-ipv4 
  neighbor 4.4.4.4 activate 
  neighbor 5.5.5.5 activate 
 ! 
 vrf red 
  rd 1:1 
  route-target import vpn-ipv4 100:1 
  route-target export vpn-ipv4 100:1 
  network 11.0.0.0/24 
  ! 
  mvpn-ipv4 
   rsvp p2mp tunnel profile MyProfile

VRF-specific PMSI tunnels can be configured using the command pmsi-tunnel protocol rsvp p2mp. 

switch# config 
 switch(config)# router bgp 
 switch(config-router-bgp)# vrf red 
 switch(config-router-bgp-vrf-red)# mvpn-ipv4 
  aip1(config-mvpn-ipv4-vrf-red)# show active 
router bgp 1 
 vrf red 
 mvpn-ipv4 
 pmsi-tunnel protocol rsvp p2mp

Configuring RSVP

RSVP P2MP signaling functionality must be enabled by entering the p2mp submode of the mpls rsvp configuration mode. This is outlined in the Configuring RSVP-TE P2MP section.

The tunnel profile associated with the VRF in the BGP configuration must be defined in the rsvp submode of router traffic-engineering. The following example defines the profile MyProfile, referencing the ExpTree tree specification. 
switch(config)# router traffic-engineering 
switch(config-te)# rsvp 
switch(config-te-rsvp)# show active 
router traffic-engineering 
 rsvp 
  tree ExpTree explicit 
   leaf 4.4.4.4 
    hop 2.2.2.2 node 
    hop 4.4.4.4 node 
   ! 
   leaf 5.5.5.5 
    hop 10.0.12.2 
    hop 4.4.4.4 node 
    hop 5.5.5.5 node 
   ! 
  ! 
 tunnel profile MyProfile p2mp 
  tree ExpTree 
switch(config-te-rsvp)#

This profile will serve as a template for all tunnels requested by BGP for VRFs configured to use it.

Note: Only destinations requested by BGP will be signaled in the RSVP P2MP tunnel, regardless of whether they are listed in the tree specification. Further, for a leaf to come up, the egress node for that leaf must have BGP MVPN provisioned in the respective VRF.

Explicit Tree Specification

With an explicit tree specification, each configured leaf must specify all hops along the path from the root to the leaf. Any leaf that is not present in the explicit tree specification will not be part of the tunnel and will not be signaled.

Hops can either be configured as node or non-node hops. Without the node keyword, a configured hop will be a non-node hop and must be specified as the ingress IP interface of the hop. Alternatively, a node hop can be specified using the keyword node, allowing the path to traverse any link to that node. IPs specified with the keyword node can be ingress interface addresses or TE router IDs. Node and non-node hops can be mixed for the same leaf.

Dynamic Tree Specification

Alternatively, a Dynamic Tree Specification can be configured. A dynamic tree specification delegates the discovery of the tree to a CSPF run, allowing CSPF to find paths from the root to all leaves. A dynamic tree specification does not need to contain all leaves that are part of the tree. Tree-level constraints can be in the form of administrative group constraints.

The following example directs CSPF only to consider links that do not contain the administrative group associated with name red and administrative group 10. As with P2P tunnels, administrative group constraints with exclude, include all, and include any are supported and can be mixed freely. 
switch(config)# router traffic-engineering 
switch(config-te)# rsvp 
switch(config-te-rsvp)# show active 
router traffic-engineering 
 rsvp 
   tree DynTree dynamic 
  administrative-group exclude red,10 
 ! 
 tunnel profile MyProfile p2mp 
 tree DynTree 
switch(config-te-rsvp)#

Default Tree Specification

If a tunnel profile does not specify the name of a tree specification, then a default dynamic tree specification is applied. This is equivalent to configuring an empty dynamic tree specification, meaning the specification has no constraints. In this case, CSPF is used to find paths to all leaves and can use any link, since there are no constraints.

Static Tunnels

As an alternative to the MVPN/BGP configuration, for testing purposes not involving BGP/MVPN, a static tunnel can be configured by providing an explicit tunnel configuration instead of a tunnel profile configuration. In addition to configuring the name of a tree specification, a tunnel must also specify all destinations for this IP and be enabled with no shutdown. This will start signaling the tunnel right away upon leaving tunnel config mode, independent of any BGP configuration. 

switch# config
switch(config)# router traffic-engineering
switch(config-te)# rsvp
switch(config-te-rsvp)# show active
router traffic-engineering
   rsvp
      tree MyTree explicit
         leaf 4.4.4.4
            hop 2.2.2.2 node
            hop 4.4.4.4 node
         !
         leaf 5.5.5.5
            hop 2.2.2.2 node
            hop 4.4.4.4 node
            hop 5.5.5.5 node
        !
        !
        tunnel MyTunnel p2mp
          destination ip 4.4.4.4
          destination ip 5.5.5.5
          tree MyTree
          no shutdown

switch(config-te-rsvp)#
  !

For a leaf to come up with static tunnels, a static PMSI must be configured on egress and bud nodes under the router multicast mode, and multicast IPv4 routing must be enabled. 

switch# config
switch(config)#
switch(config)# router multicast 
switch(config-router-multicast)#  mvpn ipv4 static pmsi
!
switch(config-router-multicast)# ipv4 
switch(config-router-multicast-ipv4)#routing

Interoperability

Routers from other vendors may not support signaling of multiple sub-LSPs per sub-group. A compatibility configuration option is available to limit sub-group size. That setting may need to be set to 1 for interoperability with routers from some other vendors. The size of sub-groups can also be reduced if the number of sub-LSPs causes packet sizes of PATH and/or RESV messages to exceed the MTU.

Note: Signaling and processing are less efficient with a smaller subgroup size. The default is 20. 
switch# config 
switch(config)# mpls rsvp 
switch(config-mpls-rsvp)# p2mp 
switch(config-mpls-rsvp-p2mp)# sub-group limit 1 sub-lsps 
switch(config-mpls-rsvp-p2mp)# exit 
switch(config-mpls-rsvp)#

RSVP-TE P2MP Tunnels Limitations

  • No FRR node protection support.
  • No path protection support.
  • No bandwidth reservation support.
  • No tunnel counters.
  • The only supported constraints for dynamic tree specifications are administrative-group constraints. When using dynamic trees with IS-IS multi-instance enabled, only the default ISIS instance (i.e., instance-id 0) is supported.
  • No Graceful Restart for P2MP tunnels is supported.
  • Maximum branching degree (next hops per headend) is 64.
  • Forwarding plane agent restart (SandMcast) is hitful.
  • When Fast Re-Route (FRR) is enabled, multicast traffic is replicated for both primary and backup paths in the packet processing pipeline, but traffic on the inactive path is blocked at the outgoing interface. As a result, inactive paths can still restrict the available bandwidth on their outgoing interfaces, leading to cases where the full bandwidth along the active paths cannot be achieved when primary and backup paths share the same outgoing interfaces.
  • Anycast Loopbacks are not supported as leaves or include-hops.
  • Secondary Loopbacks as tunnel endpoints are not supported in OSPF.