Virtual Private Routed Network service

VPRN service overview

RFC 2547b is an extension to the original RFC 2547, BGP/MPLS VPNs, which details a method of distributing routing information using BGP and MPLS forwarding data to provide a Layer 3 Virtual Private Network (VPN) service to end customers.

Each Virtual Private Routed Network (VPRN) consists of a set of customer sites connected to one or more PE routers. Each associated PE router maintains a separate IP forwarding table for each VPRN. Additionally, the PE routers exchange the routing information configured or learned from all customer sites via MP-BGP peering. Each route exchanged via the MP-BGP protocol includes a Route Distinguisher (RD), which identifies the VPRN association and handles the possibility of IP address overlap.

The service provider uses BGP to exchange the routes of a particular VPN among the PE routers that are attached to that VPN. This is done in a way which ensures that routes from different VPNs remain distinct and separate, even if two VPNs have an overlapping address space. The PE routers peer with locally connected CE routers and exchange routes with other PE routers to provide end-to-end connectivity between CEs belonging to a specific VPN. Because the CE routers do not peer with each other there is no overlay visible to the CEs.

When BGP distributes a VPN route it also distributes an MPLS label for that route. On an SR series router, the method of allocating a label to a VPN route depends on the VPRN label mode and the configuration of the VRF export policy. SR series routers support three label allocation methods: label per VRF, label per next hop, and label per prefix.

Before a customer data packet travels across the service provider's backbone, it is encapsulated with the MPLS label that corresponds, in the customer's VPN, to the route which best matches the packet's destination address. The MPLS packet is further encapsulated with one or additional MPLS labels or GRE tunnel header so that it gets tunneled across the backbone to the correct PE router. Each route exchanged by the MP-BGP protocol includes a route distinguisher (RD), which identifies the VPRN association. Thus the backbone core routers do not need to know the VPN routes. Virtual Private Routed Network displays a VPRN network diagram example.

Figure 1. Virtual Private Routed Network

Routing prerequisites

RFC 4364 requires the following features:

  • multi-protocol extensions to BGP

  • extended BGP community support

  • BGP capability negotiation

Tunneling protocol options are as follows:

  • Label Distribution Protocol (LDP)

  • MPLS RSVP-TE tunnels

  • Generic Router Encapsulation (GRE) tunnels

  • BGP route tunnel (RFC 8277)

Core MP-BGP support

BGP is used with BGP extensions mentioned in Routing prerequisites to distribute VPRN routing information across the service provider’s network.

BGP was initially designed to distribute IPv4 routing information. Therefore, multi-protocol extensions and the use of a VPN-IP address were created to extend BGP’s ability to carry overlapping routing information. A VPN-IPv4 address is a 12-byte value consisting of the 8-byte route distinguisher (RD) and the 4-byte IPv4 IP address prefix. A VPN-IPv6 address is a 24-byte value consisting of the 8-byte RD and 16-byte IPv6 address prefix. Service providers typically assign one or a small number of RDs per VPN service network-wide.

Route distinguishers

The route distinguisher (RD) is an 8-byte value consisting of two major fields, the Type field and Value field. The Type field determines how the Value field should be interpreted. The 7750 SR and 7950 XRS implementation supports the three (3) Type values as defined in the standard.

Figure 2. Route distinguisher

The three Type values are:

  • Type 0: Value Field — Administrator subfield (2 bytes)

    • Assigned number subfield (4 bytes)

    • The administrator field must contain an AS number (using private AS numbers is discouraged). The Assigned field contains a number assigned by the service provider.

  • Type 1: Value Field — Administrator subfield (4 bytes)

    • Assigned number subfield (2 bytes)

    • The administrator field must contain an IP address (using private IP address space is discouraged). The Assigned field contains a number assigned by the service provider.

  • Type 2: Value Field — Administrator subfield (4 bytes)

    • Assigned number subfield (2 bytes)

    • The administrator field must contain a 4-byte AS number (using private AS numbers is discouraged). The Assigned field contains a number assigned by the service provider.

eiBGP load balancing

eiBGP load balancing allows a route to have multiple next hops of different types, using both IPv4 next hops and MPLS LSPs simultaneously.

Basic eiBGP topology displays a basic topology that could use eiBGP load balancing. In this topology CE1 is dual homed and therefore reachable by two separate PE routers. CE 2 (a site in the same VPRN) is also attached to PE1. With eiBGP load balancing, PE1 uses its own local IPv4 nexthop as well as the route advertised by MP-BGP, by PE2.

Figure 3. Basic eiBGP topology

Another example displayed in Extranet load balancing shows an extra net VPRN (VRF). The traffic ingressing the PE that should be load balanced is part of a second VPRN and the route over which the load balancing is to occur is part of a separate VPRN instance and are leaked into the second VPRN by route policies.

Here, both routes can have a source protocol of VPN-IPv4 but one still has an IPv4 nexthop and the other can have a VPN-IPv4 nexthop pointing out a network interface. Traffic is still load balanced (if eiBGP is enabled) as if only a single VRF was involved.

Figure 4. Extranet load balancing

Traffic is load balanced across both the IPv4 and VPN-IPv4 next hops. This helps to use all available bandwidth to reach a dual-homed VPRN.

Route reflector

The use of Route Reflectors is supported in the service provider core. Multiple sets of route reflectors can be used for different types of BGP routes, including IPv4 and VPN-IPv4 as well as multicast and IPv6 (multicast and IPv6 apply to the 7750 SR only).

CE to PE route exchange

Routing information between the Customer Edge (CE) and Provider Edge (PE) can be exchanged by the following methods:

  • Static Routes

  • EBGP

  • RIP

  • OSPF

  • OSPF3

Each protocol provides controls to limit the number of routes learned from each CE router.

Route redistribution

Routing information learned from the CE-to-PE routing protocols and configured static routes should be injected in the associated local VPN routing/forwarding (VRF). In the case of dynamic routing protocols, there may be protocol specific route policies that modify or reject specific routes before they are injected into the local VRF.

Route redistribution from the local VRF to CE-to-PE routing protocols is to be controlled via the route policies in each routing protocol instance, in the same manner that is used by the base router instance.

The advertisement or redistribution of routing information from the local VRF to or from the MP-BGP instance is specified per VRF and is controlled by VRF route target associations or by VRF route policies.

VPN-IP routes imported into a VPRN, have the protocol type bgp-vpn to denote that it is an VPRN route. This can be used within the route policy match criteria.

CPE connectivity check

Static routes are used within many IES services and VPRN services. Unlike dynamic routing protocols, there is no way to change the state of routes based on availability information for the associated CPE. CPE connectivity check adds flexibility so that unavailable destinations are removed from the VPRN routing tables dynamically and minimize wasted bandwidth. Directly connected IP target shows a setup with a directly connected IP target and Multiple hops to IP target shows a setup with multiple hops to an IP target.

Figure 5. Directly connected IP target
Figure 6. Multiple hops to IP target

The availability of the far-end static route is monitored through periodic polling. The polling period is configured. If the poll fails a specified number of sequential polls, the static route is marked as inactive.

Either ICMP ping or unicast ARP mechanism can be used to test the connectivity. ICMP ping is preferred.

If the connectivity check fails and the static route is deactivated, the router continues to send polls and re-activate any routes that are restored.

RT Constraint

Constrained VPN Route Distribution based on route targets

Constrained Route Distribution (or RT Constraint) is a mechanism that allows a router to advertise Route Target membership information to its BGP peers to indicate interest in receiving only VPN routes tagged with specific Route Target extended communities. Upon receiving this information, peers restrict the advertised VPN routes to only those requested, minimizing control plane load in terms of protocol traffic and possibly also RIB memory.

The Route Target membership information is carried using MP-BGP, using an AFI value of 1 and SAFI value of 132. In order for two routers to exchange RT membership NLRI they must advertise the corresponding AFI/SAFI to each other during capability negotiation. The use of MP-BGP means RT membership NLRI are propagated, loop-free, within an AS and between ASes using well-known BGP route selection and advertisement rules.

ORF can also be used for RT-based route filtering, but ORF messages have a limited scope of distribution (to direct peers) and therefore do not automatically create pruned inter-cluster and inter-AS route distribution trees.

Configuring the route target address family

RT Constraint is supported only by the base router BGP instance. When the family command at the BGP router group or neighbor CLI context includes the route-target keyword, the RT Constraint capability is negotiated with the associated set of EBGP and IBGP peers.

ORF and RT Constraint are mutually exclusive on a particular BGP session. The CLI does not attempt to block this configuration, but if both capabilities are enabled on a session, the ORF capability is not included in the OPEN message sent to the peer.

Originating RT constraint routes

When the base router has one or more RTC peers (BGP peers with which the RT Constraint capability has been successfully negotiated), one RTC route is created for each RT extended community imported into a locally-configured L2 VPN or L3 VPN service. These imported route targets are configured in the following contexts:

  • config>service>vprn

  • config>service>vprn>mvpn

By default, these RTC routes are automatically advertised to all RTC peers, without the need for an export policy to explicitly ‟accept” them. Each RTC route has a prefix, a prefix length and path attributes. The prefix value is the concatenation of the origin AS (a 4-byte value representing the 2- or 4-octet AS of the originating router, as configured using the config>router>autonomous-system command) and 0 or 16-64 bits of a route target extended community encoded in one of the following formats: 2-octet AS specific extended community, IPv4 address specific extended community, or 4-octet AS specific extended community.

A router may be configured to send the default RTC route to any RTC peer. This is done using the new default-route-target group/neighbor CLI command. The default RTC route is a special type of RTC route that has zero prefix length. Sending the default RTC route to a peer conveys a request to receive all VPN routes (regardless of route target extended community) from that peer. The default RTC route is typically advertised by a route reflector to its clients. The advertisement of the default RTC route to a peer does not suppress other more specific RTC routes from being sent to that peer.

Receiving and re-advertising RT Constraint routes

All received RTC routes that are deemed valid are stored in the RIB-IN. An RTC route is considered invalid and treated as withdrawn, if any of the following applies:

  • The prefix length is 1-31.

  • The prefix length is 33-47.

  • The prefix length is 48-96 and the 16 most-significant bits are not 0x0002, 0x0102 or 0x0202.

If multiple RTC routes are received for the same prefix value then standard BGP best path selection procedures are used to determine the best of these routes.

The best RTC route per prefix is re-advertised to RTC peers based on the following rules:

  • The best path for a default RTC route (prefix-length 0, origin AS only with prefix-length 32, or origin AS plus 16 bits of an RT type with prefix-length 48) is never propagated to another peer.

  • A PE with only IBGP RTC peers that is neither a route reflector nor an ASBR does not re-advertise the best RTC route to any RTC peer because of standard IBGP split horizon rules.

  • A route reflector that receives its best RTC route for a prefix from a client peer re-advertises that route (subject to export policies) to all of its client and non-client IBGP peers (including the originator), per standard RR operation. When the route is re-advertised to client peers, the RR (i) sets the ORIGINATOR_ID to its own router ID and (ii) modifies the NEXT_HOP to be its local address for the sessions (for example, system IP).

  • A route reflector that receives its best RTC route for a prefix from a non-client peer re-advertises that route (subject to export policies) to all of its client peers, per standard RR operation. If the RR has a non-best path for the prefix from any of its clients, it advertises the best of the client-advertised paths to all non-client peers.

  • An ASBR that is neither a PE nor a route reflector that receives its best RTC route for a prefix from an IBGP peer re-advertises that route (subject to export policies) to its EBGP peers. It modifies the NEXT_HOP and AS_PATH of the re-advertised route per standard BGP rules. No aggregation of RTC routes is supported.

  • An ASBR that is neither a PE nor a route reflector that receives its best RTC route for a prefix from an External Border Gateway Protocol (EBGP) peer re-advertises that route (subject to export policies) to its EBGP and IBGP peers. When re-advertised routes are sent to EBGP peers, the ASBR modifies the NEXT_HOP and AS_PATH per standard BGP rules. No aggregation of RTC routes is supported.

Note:

These advertisement rules do not handle hierarchical RR topologies properly. This is a limitation of the current RT constraint standard.

Using RT Constraint routes

In general (ignoring IBGP-to-IBGP rules, Add-Path, Best-external, and so on), the best VPN route for every prefix/NLRI in the RIB is sent to every peer supporting the VPN address family, but export policies may be used to prevent some prefix/NLRI from being advertised to specific peers. These export policies may be configured statically or created dynamically based on use of ORF or RT constraint with a peer. ORF and RT Constraint are mutually exclusive on a session.

When RT Constraint is configured on a session that also supports VPN address families using route targets (that is: vpn-ipv4, vpn-ipv6, l2-vpn, mvpn-ipv4, mvpn-ipv6, mcast-vpn-ipv4 or evpn), the advertisement of the VPN routes is affected as follows:

  1. When the session comes up, the advertisement of the VPN routes is delayed for a short while to allow RTC routes to be received from the peer.

  2. After the initial delay, the received RTC routes are analyzed and acted upon. If S1 is the set of routes previously advertised to the peer and S2 is the set of routes that should be advertised based on the most recent received RTC routes, the following applies:

    • The set of routes in S1 but not in S2 should be withdrawn immediately (subject to MRAI).

    • The set of routes in S2 but not in S1 should be advertised immediately (subject to MRAI).

If a default RTC route is received from a peer P1, the VPN routes that are advertised to P1 is the set that meets all of the following requirements:

  • The set is eligible for advertisement to P1 per BGP route advertisement rules.

  • The set has not been rejected by manually configured export policies.

  • The set has not been advertised to the peer.

Note: This applies whether P1 advertised the best route for the default RTC prefix or not.

In this context, a default RTC route is any of the following:

  • a route with NLRI length = zero

  • a route with NLRI value = origin AS and NLRI length = 32

  • a route with NLRI value = {origin AS+0x0002 | origin AS+0x0102 | origin AS+0x0202} and NLRI length = 48

    • If an RTC route for prefix A (origin-AS = A1, RT = A2/n, n > 48) is received from an IBGP peer I1 in autonomous system A1, the VPN routes that are advertised to I1 is the set that meets all of the following requirements:

      • The set is eligible for advertisement to I1 per BGP route advertisement rules.

      • The set has not been rejected by manually configured export policies.

      • The set carries at least one route target extended community with value A2 in the n most significant bits.

      • The set has not been advertised to the peer.

      Note: This applies whether I1 advertised the best route for A or not.
    • If the best RTC route for a prefix A (origin-AS = A1, RT = A2/n, n > 48) is received from an IBGP peer I1 in autonomous system B, the VPN routes that are advertised to I1 is the set that meets all of the following requirements:

      • The set is eligible for advertisement to I1 per BGP route advertisement rules.

      • The set has not been rejected by manually configured export policies.

      • The set carries at least one route target extended community with value A2 in the n most significant bits.

      • The set has not been advertised to the peer.

      Note: This applies only if I1 advertised the best route for A.
    • If the best RTC route for a prefix A (origin-AS = A1, RT = A2/n, n > 48) is received from an EBGP peer E1, the VPN routes that are advertised to E1 is the set that meets all of the following requirements:

      • The set is eligible for advertisement to E1 per BGP route advertisement rules.

      • The set has not been rejected by manually configured export policies.

      • The set carries at least one route target extended community with value A2 in the n most significant bits.

      • The set has not been advertised to the peer.

      Note: This applies only if E1 advertised the best route for A.

BGP fast reroute in a VPRN

BGP fast reroute is a feature that brings together indirection techniques in the forwarding plane and pre-computation of BGP backup paths in the control plane to support fast reroute of BGP traffic around unreachable/failed next-hops. In a VPRN context BGP fast reroute is supported using unlabeled IPv4, unlabeled IPv6, VPN-IPv4, and VPN-IPv6 VPN routes. The supported VPRN scenarios are described in BGP fast reroute scenarios (VPRN context).

BGP fast reroute information specific to the base router BGP context is described in the BGP Fast Reroute section of the 7450 ESS, 7750 SR, 7950 XRS, and VSR Unicast Routing Protocols Guide.

Table 1. BGP fast reroute scenarios (VPRN context)
Ingress packet Primary route Backup route Prefix independent convergence

IPv4 (ingress PE)

IPv4 route with next-hop A resolved by an IPv4 route

IPv4 route with next-hop B resolved by an IPv4 route

Yes

IPv4 (ingress PE)

VPN-IPv4 route with next-hop A resolved by a GRE, LDP, RSVP or BGP tunnel

VPN-IPv4 route with next-hop A resolved by a GRE, LDP, RSVP or BGP tunnel

Yes

MPLS (egress PE)

IPv4 route with next-hop A resolved by an IPv4 route

IPv4 route with next-hop B resolved by an IPv4 route

Yes

MPLS (egress PE)

IPv4 route with next-hop A resolved by an IPv4 rout

VPN-IPv4 route* with next-hop B resolved by a GRE, LDP, RSVP or BGP tunnel

Yes

IPv6 (ingress PE)

IPv6 route with next-hop A resolved by an IPv6 route

IPv6 route with next-hop B resolved by an IPv6 route

Yes

IPv6 (ingress PE)

VPN-IPv6 route with next-hop A resolved by a GRE, LDP, RSVP or BGP tunnel

VPN-IPv6 route with next-hop B resolved by a GRE, LDP, RSVP or BGP tunnel

Yes

MPLS (egress)

IPv6 route with next-hop A resolved by an IPv6 route

IPv6 route with next-hop B resolved by an IPv6 route

Yes

MPLS (egress)

IPv6 route with next-hop A resolved by an IPv6 route

Yes

VPRN label mode must be VRF. VPRN must export its VPN-IP routes with RD ≠ y. For the best performance the backup next-hop must advertise the same VPRN label value with all routes (per VRF label).

BGP fast reroute in a VPRN configuration

In a VPRN context, BGP fast reroute is optional and must be enabled. Fast reroute can be applied to all IPv4 prefixes, all IPv6 prefixes, all IPv4 and IPv6 prefixes, or to a specific set of IPv4 and IPv6 prefixes.

If all IP prefixes require backup path protection, use a combination of the BGP instance-level backup-path and VPRN-level enable-bgp-vpn-backup commands. The VPRN BGP backup-path command enables BGP fast reroute for all IPv4 prefixes or all IPv6 prefixes, or both, that have a best path through a VPRN BGP peer. The VPRN-level enable-bgp-vpn-backup command enables BGP fast reroute for all IPv4 prefixes or all IPv6 prefixes, or both, that have a best path through a remote PE peer.

If only some IP prefixes require backup path protection, use route policies to apply the install-backup-path action to the best paths of the IP prefixes requiring protection. See the ‟BGP Fast Reroute” section of the 7450 ESS, 7750 SR, 7950 XRS, and VSR Unicast Routing Protocols Guide for more information.

BGP best-external in a VPRN context

If two or more PE routers connect to a multi-homed site and learn routes for a common set of IP prefixes from that site, then the failure of one of the PE routers or a PE-CE link can be handled by rerouting the traffic over the alternate paths. The traffic failover time in this situation can be reduced if all the PE routers have advance knowledge of the potential backup paths and do not have to wait for BGP route advertisements or withdrawals, or both, to reprogram their forwarding tables. This can be challenging with normal BGP procedures because a PE router is not allowed to advertise, to other PE routers, a BGP route that it has learned from a connected CE device if that route is not its active route for the destination in the route table. If the multi-homing scenario calls for all traffic destined for an IP prefix to be carried over a preferred primary path (passing through PE1-CE1 for example), then all other PE routers (PE2, PE3, and so on) have that VPN route as their active route for the destination, and they are not able to advertise their own routes for the same IP prefix.

The SR OS supports a VPRN feature, configured using the export-inactive-bgp command, that resolves the issue described above. When a VPRN is configured with this command, it is allowed to advertise (as a VPN-IP route toward other PEs) its best CE-BGP route for an IP prefix, even when that CE-BGP route is inactive in the route table because of the presence of a more-preferred VPN-IP route from another PE. In order for the CE-BGP route to be advertised, the CE-BGP route must be accepted by the VRF export policy. When a VPN-IP route is advertised because of the export-inactive-bgp command, the label carried in the route is a per-next-hop label corresponding to the next-hop IP address of the CE-BGP route, or a per-prefix label; this helps avoid packet looping issues because of unsynchronized IP FIBs.

When a PE router that advertised a backup path for an IP prefix receives a withdrawal for the VPN-IP route that it was using as the primary/active route, its backup path may be promoted to the primary path; that is, the CE-BGP route may become the active route for the destination. In this case, the PE router is required to re-advertise the VPN-IP route with a per-VRF label if that is the default allocation policy and there is no label-per-prefix policy override. It takes some time for the new VPN-IP route to reach all the ingress routers and for them to update their forwarding tables. In the meantime, traffic continues to be received with the old per-next-hop label. The egress PE drops this in-flight traffic unless label retention is configured using the bgp-labels-hold-timer command in the config>router>mpls-labels context. This command configures a delay (in seconds) between the withdrawal of a VPN-IP route with a per-next-hop label and the deletion of the corresponding label forwarding entry in the IOM. The value of bgp-labels-hold-timer should be large enough to account for the propagation delay of the route withdrawal to all the ingress routers.

VPRN features

This section describes various VPRN features and any special capabilities or considerations as they relate to VPRN services.

IP interfaces

VPRN customer IP interfaces can be configured with most of the same options found on the core IP interfaces. The advanced configuration options supported are as follows:

  • VRRP

  • Cflowd

  • secondary IP addresses

  • ICMP options

Note: NTP broadcast receipt is a configuration option found on core IP interfaces that is not supported on VPRN IP interfaces.

QoS Policy Propagation Using BGP

This section discusses QPPB as it applies to VPRN, IES, and router interfaces. See the QoS Policy Propagation Using BGP (QPPB) section and the IP Router Configuration section in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide.

The QoS Policy Propagation Using BGP (QPPB) feature applies only to the 7450 ESS and 7750 SR.

QoS policy propagation using BGP (QPPB) is a feature that allows a route to be installed in the routing table with a forwarding-class and priority so that packets matching the route can receive the associated QoS. The forwarding-class and priority associated with a BGP route are set using BGP import route policies. In the industry, this feature is called QPPB, and even though the feature name refers to BGP specifically. On SR OS, QPPB is supported for BGP (IPv4, IPv6, VPN-IPv4, VPN-IPv6), RIP and static routes.

While SAP ingress and network QoS policies can achieve the same end result as QPPB, the effort involved in creating the QoS policies, keeping them up-to-date, and applying them across many nodes is much greater than with QPPB. This is because of assigning a packet, arriving on a particular IP interface, to a specific forwarding-class and priority/profile, based on the source IP address or destination IP address of the packet. In a typical application of QPPB, a BGP route is advertised with a BGP community attribute that conveys a particular QoS. Routers that receive the advertisement accept the route into their routing table and set the forwarding-class and priority of the route from the community attribute.

QPPB applications

The typical applications of QPPB are as follows:

  • coordination of QoS policies between different administrative domains

  • traffic differentiation within a single domain, based on route characteristics

Inter-AS coordination of QoS policies

The operator of an administrative domain A can use QPPB to signal to a peer administrative domain B that traffic sent to specific prefixes advertised by domain A should receive a particular QoS treatment in domain B. More specifically, an ASBR of domain A can advertise a prefix XYZ to domain B and include a BGP community attribute with the route. The community value implies a particular QoS treatment, as agreed by the two domains (in their peering agreement or service level agreement, for example). When the ASBR and other routers in domain B accept and install the route for XYZ into their routing table, they apply a QoS policy on selected interfaces that classifies traffic toward network XYZ into the QoS class implied by the BGP community value.

QPPB may also be used to request that traffic sourced from specific networks receive appropriate QoS handling in downstream nodes that may span different administrative domains. This can be achieved by advertising the source prefix with a BGP community, as discussed above. However, in this case other approaches are equally valid, such as marking the DSCP or other CoS fields based on source IP address so that downstream domains can take action based on a common understanding of the QoS treatment implied by different DSCP values.

In the above examples, coordination of QoS policies using QPPB could be between a business customer and its IP VPN service provider, or between one service provider and another.

Traffic differentiation based on route characteristics

There may be times when a network operator wants to provide differentiated service to certain traffic flows within its network, and these traffic flows can be identified with known routes. For example, the operator of an ISP network may want to give priority to traffic originating in a particular ASN (the ASN of a content provider offering over-the-top services to the ISP’s customers), following a specific AS_PATH, or destined for a particular next-hop (remaining on-net vs. off-net).

Use of QPPB to differentiate traffic in an ISP network shows an example of an ISP that has an agreement with the content provider managing AS300 to provide traffic sourced and terminating within AS300 with differentiated service appropriate to the content being transported. In this example we presume that ASBR1 and ASBR2 mark the DSCP of packets terminating and sourced, respectively, in AS300 so that other nodes within the ISP’s network do not need to rely on QPPB to determine the correct forwarding-class to use for the traffic. The DSCP or other CoS markings could be left unchanged in the ISP’s network and QPPB used on every node.

Figure 7. Use of QPPB to differentiate traffic in an ISP network

QPPB

There are two main aspects of the QPPB feature on the 7450 ESS and 7750 SR:

  • the ability to associate a forwarding-class and priority with specific routes in the routing table

  • the ability to classify an IP packet arriving on a particular IP interface to the forwarding-class and priority associated with the route that best matches the packet

Associating an FC and priority with a route

This feature uses the fc command in the route-policy hierarchy to set the forwarding class and optionally the priority associated with routes accepted by a route-policy entry. The command has the following structure:

fc fc-name [priority {low | high}]

The use of this command is illustrated by the following example:

config>router>policy-options
begin
community gold members 300:100
policy-statement qppb_policy
entry 10
from
protocol bgp
community gold
exit
action accept
fc h1 priority high
exit
exit
exit
commit

The fc command is supported with all existing from and to match conditions in a route policy entry and with any action other than reject, it is supported with next-entry, next-policy and accept actions. If a next-entry or next-policy action results in multiple matching entries then the last entry with a QPPB action determines the forwarding class and priority.

A route policy that includes the fc command in one or more entries can be used in any import or export policy, but the fc command has no effect except in the following types of policies:

  • VRF import policies

    • config>service>vprn>vrf-import

  • BGP import policies

    • config>router>bgp>import

    • config>router>bgp>group>import

    • config>router>bgp>group>neighbor>import

    • config>service>vprn>bgp>import

    • config>service>vprn>bgp>group>import

    • config>service>vprn>bgp>group>neighbor>import

  • RIP import policies

    • config>router>rip>import

    • config>router>rip>group>import

    • config>router>rip>group>neighbor>import

    • config>service>vprn>rip>import

    • config>service>vprn>rip>group>import

    • config>service>vprn>rip>group>neighbor>import

As evident from above, QPPB route policies support routes learned from RIP and BGP neighbors of a VPRN as well as for routes learned from RIP and BGP neighbors of the base/global routing instance.

QPPB is supported for BGP routes belonging to any of the address families listed below:

  • IPv4 (AFI=1, SAFI=1)

  • IPv6 (AFI=2, SAFI=1)

  • VPN-IPv4 (AFI=1, SAFI=128)

  • VPN-IPv6 (AFI=2, SAFI=128)

A VPN-IP route may match both a VRF import policy entry and a BGP import policy entry (if vpn-apply-import is configured in the base router BGP instance). In this case the VRF import policy is applied first and then the BGP import policy, so the QPPB QoS is based on the BGP import policy entry.

This feature also introduces the ability to associate a forwarding-class and optionally priority with IPv4 and IPv6 static routes. This is achieved by specifying the forwarding-class within the static-route-entry next-hop or indirect context.

Priority is optional when specifying the forwarding class of a static route, but once configured it can only be deleted and returned to unspecified by deleting the entire static route.

Displaying QoS information associated with routes

The following commands are enhanced to show the forwarding-class and priority associated with the displayed routes:

  • show router route-table

  • show router fib

  • show router bgp routes

  • show router rip database

  • show router static-route

This feature uses a qos keyword to the show>router>route-table command. When this option is specified the output includes an additional line per route entry that displays the forwarding class and priority of the route. If a route has no fc and priority information, then the third line is blank. The following CLI shows an example:

show router route-table [family] [ip-prefix[/prefix-length]] [longer | exact] [protocol protocol-name] qos

An example output of this command is shown below:

A:Dut-A# show router route-table 10.1.5.0/24 qos
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix                                   Type    Proto    Age         Pref
       Next Hop[Interface Name]                                     Metric
       QoS
-------------------------------------------------------------------------------
10.1.5.0/24                                   Remote  BGP      15h32m52s   0
       PE1_to_PE2                                                   0
       h1, high
-------------------------------------------------------------------------------
No. of Routes: 1
===============================================================================
A:Dut-A#

Enabling QPPB on an IP interface

To enable QoS classification of ingress IP packets on an interface based on the QoS information associated with the routes that best match the packets the qos-route-lookup command is necessary in the configuration of the IP interface. The qos-route-lookup command has parameters to indicate whether the QoS result is based on lookup of the source or destination IP address in every packet. There are separate qos-route-lookup commands for the IPv4 and IPv6 packets on an interface, which allows QPPB to enabled for IPv4 only, IPv6 only, or both IPv4 and IPv6. Current QPPB based on a source IP address is not supported for IPv6 packets nor is it supported for ingress subscriber management traffic on a group interface.

The qos-route-lookup command is supported on the following types of IP interfaces:

  • base router network interfaces (config>router>interface)

  • VPRN SAP and spoke SDP interfaces (config>service>vprn>interface)

  • VPRN group-interfaces (config>service>vprn>sub-if>grp-if)

  • IES SAP and spoke SDP interfaces (config>service>ies>interface)

  • IES group-interfaces (config>service>ies>sub-if>grp-if)

When the qos-route-lookup command with the destination parameter is applied to an IP interface and the destination address of an incoming IP packet matches a route with QoS information the packet is classified to the fc and priority associated with that route, overriding the fc and priority/profile determined from the SAP-Ingress or network qos policy associated with the IP interface. If the destination address of the incoming packet matches a route with no QoS information the fc and priority of the packet remain as determined by the SAP-Ingress or network qos policy.

Similarly, when the qos-route-lookup command with the source parameter is applied to an IP interface and the source address of an incoming IP packet matches a route with QoS information the packet is classified to the fc and priority associated with that route, overriding the fc and priority/profile determined from the SAP-Ingress or network qos policy associated with the IP interface. If the source address of the incoming packet matches a route with no QoS information the fc and priority of the packet remain as determined by the SAP-Ingress or network qos policy.

Currently, QPPB is not supported for ingress MPLS traffic on network interfaces or on CsC PE’-CE’ interfaces (config>service>vprn>nw-if).

QPPB when next hops are resolved by QPPB routes

In some circumstances (IP VPN inter-AS model C, Carrier Supporting Carrier, indirect static routes, and so on) an IPv4 or IPv6 packet may arrive on a QPPB-enabled interface and match a route A1 whose next-hop N1 is resolved by a route A2 with next-hop N2 and perhaps N2 is resolved by a route A3 with next-hop N3, and so on. The QPPB result is based only on the forwarding-class and priority of route A1. If A1 does not have a forwarding-class and priority association then the QoS classification is not based on QPPB, even if routes A2, A3, and so on have forwarding-class and priority associations.

QPPB and multiple paths to a destination

When ECMP is enabled some routes may have multiple equal-cost next-hops in the forwarding table. When an IP packet matches such a route the next-hop selection is typically based on a hash algorithm that tries to load balance traffic across all the next-hops while keeping all packets of a specific flow on the same path. The QPPB configuration model described in Associating an FC and priority with a route allows different QoS information to be associated with the different ECMP next hops of a route. The forwarding-class and priority of a packet matching an ECMP route is based on the particular next-hop used to forward the packet.

When BGP FRR is enabled some BGP routes may have a backup next-hop in the forwarding table in addition to the one or more primary next-hops representing the equal-cost best paths allowed by the ECMP/multipath configuration. When an IP packet matches such a route a reachable primary next-hop is selected (based on the hash result) but if all the primary next-hops are unreachable then the backup next-hop is used. The QPPB configuration model described in Associating an FC and priority with a route allows the forwarding-class and priority associated with the backup path to be different from the QoS characteristics of the equal-cost best paths. The forwarding class and priority of a packet forwarded on the backup path is based on the fc and priority of the backup route.

QPPB and policy-based routing

When an IPv4 or IPv6 packet with destination address X arrives on an interface with both QPPB and policy-based-routing enabled:

  • There is no QPPB classification if the IP filter action redirects the packet to a directly connected interface, even if X is matched by a route with a forwarding-class and priority

  • QPPB classification is based on the forwarding-class and priority of the route matching IP address Y if the IP filter action redirects the packet to the indirect next-hop IP address Y, even if X is matched by a route with a forwarding-class and priority.

QPPB and GRT lookup

Source-address based QPPB is not supported on any SAP or spoke SDP interface of a VPRN configured with the grt-lookup command.

QPPB interaction with SAP ingress QoS policy

When QPPB is enabled on a SAP IP interface the forwarding class of a packet may change from fc1, the original fc determined by the SAP ingress QoS policy to fc2, the new fc determined by QPPB. In the ingress datapath SAP ingress QoS policies are applied in the first P chip and route lookup/QPPB occurs in the second P chip. This has the implications listed below:

  • Ingress remarking (based on profile state) is always based on the original fc (fc1) and sub-class (if defined).

  • The profile state of a SAP ingress packet that matches a QPPB route depends on the configuration of fc2 only. If the de-1-out-profile flag is enabled in fc2 and fc2 is not mapped to a priority mode queue then the packet is marked out of profile if its DE bit = 1. If the profile state of fc2 is explicitly configured (in or out) and fc2 is not mapped to a priority mode queue, then the packet is assigned this profile state. In both cases there is no consideration of whether fc1 was mapped to a priority mode queue.

  • The priority of a SAP ingress packet that matches a QPPB route depends on several factors. If the de-1-out-profile flag is enabled in fc2 and the DE bit is set in the packet then priority is low regardless of the QPPB priority or fc2 mapping to profile mode queue, priority mode queue or policer. If fc2 is associated with a profile mode queue then the packet priority is based on the explicitly configured profile state of fc2 (in profile = high, out profile = low, undefined = high), regardless of the QPPB priority or fc1 configuration. If fc2 is associated with a priority mode queue or policer then the packet priority is based on QPPB (unless DE=1), but if no priority information is associated with the route then the packet priority is based on the configuration of fc1 (if fc1 mapped to a priority mode queue then it is based on DSCP/IP prec/802.1p and if fc1 mapped to a profile mode queue then it is based on the profile state of fc1).

QPPB interactions with SAP ingress QoS summarizes these interactions.

Table 2. QPPB interactions with SAP ingress QoS
Original FC object mapping New FC object mapping Profile Priority (drop preference) DE=1 override In/out of profile marking

Profile mode queue

Profile mode queue

From new base FC unless overridden by DE=1

From QPPB, unless packet is marked in or out of profile in which case follows profile. Default is high priority.

From new base FC

From original FC and sub-class

Priority mode queue

Priority mode queue

Ignored

If DE=1 override then low otherwise from QPPB. If no DEI or QPPB overrides then from original dot1p/exp/DSCP mapping or policy default.

From new base FC

From original FC and sub-class

Policer

Policer

From new base FC unless overridden by DE=1

If DE=1 override then low otherwise from QPPB. If no DEI or QPPB overrides then from original dot1p/exp/DSCP mapping or policy default.

From new base FC

From original FC and sub-class

Priority mode queue

Policer

From new base FC unless overridden by DE=1

If DE=1 override then low otherwise from QPPB. If no DEI or QPPB overrides then from original dot1p/exp/DSCP mapping or policy default.

From new base FC

From original FC and sub-class

Policer

Priority mode queue

Ignored

If DE=1 override then low otherwise from QPPB. If no DEI or QPPB overrides then from original dot1p/exp/DSCP mapping or policy default.

From new base FC

From original FC and sub-class

Profile mode queue

Priority mode queue

Ignored

If DE=1 override then low otherwise from QPPB. If no DEI or QPPB overrides then follows original FC’s profile mode rules.

From new base FC

From original FC and sub-class

Priority mode queue

Profile mode queue

From new base FC unless overridden by DE=1

From QPPB, unless packet is marked in or out of profile in which case follows profile. Default is high priority.

From new base FC

From original FC and sub-class

Profile mode queue

Policer

From new base FC unless overridden by DE=1

If DE=1 override then low otherwise from QPPB. If no DEI or QPPB overrides then follows original FC’s profile mode rules.

From new base FC

From original FC and sub-class

Policer

Profile mode queue

From new base FC unless overridden by DE=1

From QPPB, unless packet is marked in or out of profile in which case follows profile. Default is high priority.

From new base FC

From original FC and sub-class

Object grouping and state monitoring

This feature introduces a generic operational group object which associates different service endpoints (pseudowires and SAPs) located in the same or in different service instances. The operational group status is derived from the status of the individual components using specific rules specific to the application using the concept. A number of other service entities, the monitoring objects, can be configured to monitor the operational group status and to perform specific actions as a result of status transitions. For example, if the operational group goes down, the monitoring objects are brought down.

VPRN IP interface applicability

This concept is used by an IPv4 VPRN interface to affect the operational state of the IP interface monitoring the operational group. Individual SAP and spoke SDPs are supported as monitoring objects.

The following rules apply:

  • An object can only belong to one group at a time.

  • An object that is part of a group cannot monitor the status of a group.

  • An object that monitors the status of a group cannot be part of a group.

  • An operational group may contain any combination of member types: SAP or Spoke-SDPs.

  • An operational group may contain members from different VPLS service instances.

  • Objects from different services may monitor the oper-group.

  1. Identify a set of objects whose forwarding state should be considered as a whole group then group them under an operational group using the oper-group command.
  2. Associate the IP interface to the oper-group using the monitor-group command.

The status of the operational group (oper-group) is dictated by the status of one or more members according to the following rules:

  • The oper-group goes down if all the objects in the oper-group go down. The oper-group comes up if at least one of the components is up.

  • An object in the group is considered down if it is not forwarding traffic in at least one direction. That could be because the operational state is down or the direction is blocked through some validation mechanism.

  • If a group is configured but no members are specified yet then its status is considered up.

  • As soon as the first object is configured the status of the operational group is dictated by the status of the provisioned members.

The simple configuration below shows the oper-group g1, the VPLS SAP that is mapped to it and the IP interfaces in VPRN service 2001 monitoring the oper-group g1. This is example uses an R-VPLS context. The VPLS instance includes the allow-ip-int-bind and the name v1. The VPRN interface links to the VPLS using the vpls v1 option. All commands are under the configuration service hierarchy.

To further describe the configuration. Oper-group g1 has a single SAP (1/1/1:2001) mapped to it and the IP interfaces in the VPRN service 2001 derive its state from the state of oper-group g1.

oper-group g1 create

vpls 1 name "v1" customer 1 create
            allow-ip-int-bind
            stp
                shutdown
            exit
            sap 1/1/1:2001 create
                oper-group g1
                eth-cfm
                   mep domain 1 association 1 direction down 
 ccm-enable
       no shutdown
                exit
            exit
            sap 1/1/2:2001 create
            exit
            sap 1/1/3:2001 create
            exit
no shutdown


vprn 2001 customer 1 create
            interface "i2001"  create
                address 10.1.1.1/24
                monitor-oper-group "g1"
                vpls "v1"          
            exit
          no shutdown
          exit

Subscriber interfaces

Subscriber interfaces are composed of a combination of two key technologies, subscriber interfaces and group interfaces. While the subscriber interface defines the subscriber subnets, the group interfaces are responsible for aggregating the SAPs.

Subscriber interfaces apply only to the 7450 ESS and 7750 SR.

  • subscriber interface

    This is an interface that allows the sharing of a subnet among one or many group interfaces in the routed CO model.

  • group interface

    This interface aggregates multiple SAPs on the same port.

  • redundant interfaces

    This is a special spoke-terminated Layer 3 interface. It is used in a Layer 3 routed CO dual-homing configuration to shunt downstream (network to subscriber) to the active node for a specific subscriber.

SAPs

Encapsulations

The following SAP encapsulations are supported on the 7750 SR and 7950 XRS VPRN service:

  • Ethernet null

  • Ethernet dot1q

  • QinQ

  • LAG

  • Tunnel (IPsec or GRE)

Pseudowire SAPs

Pseudowire SAPs are supported on VPRN interfaces for the 7750 SR in the same way as on IES interfaces.

QoS policies

When applied to a VPRN SAP, service ingress QoS policies only create the unicast queues defined in the policy if PIM is not configured on the associated IP interface; if PIM is configured, the multipoint queues are applied as well.

With VPRN services, service egress QoS policies function as with other services where the class-based queues are created as defined in the policy.

Both Layer 2 and Layer 3 criteria can be used in the QoS policies for traffic classification in an VPRN.

Filter policies

Ingress and egress IPv4 and IPv6 filter policies can be applied to VPRN SAPs.

DSCP marking

Specific DSCP, forwarding class, and Dot1P parameters can be specified to be used by every protocol packet generated by the VPRN. This enables prioritization or de-prioritization of every protocol (as required). The markings effect a change in behavior on ingress when queuing. For example, if OSPF is not enabled, then traffic can be de-prioritized to best effort (be) DSCP. This change de-prioritizes OSPF traffic to the CPU complex.

DSCP marking for internally generated control and management traffic by marking the DSCP value should be used for the specific application. This can be configured per routing instance. For example, OSPF packets can carry a different DSCP marking for the base instance and then for a VPRN service. ISIS and ARP traffic is not an IP-generated traffic type and is not configurable. See DSCP/FC marking .

When an application is configured to use a specified DSCP value then the MPLS EXP, Dot1P bits are marked in accordance with the network or access egress policy as it applies to the logical interface the packet is egressing.

The DSCP value can be set per application. This setting is forwarded to the egress line card. The egress line card does not alter the coded DSCP value and marks the LSP-EXP and IEEE 802.1p (Dot1P) bits according to the appropriate network or access QoS policy.

Table 3. DSCP/FC marking
Protocol IPv4 IPv6 DSCP marking Dot1P marking Default FC

ARP

Yes

NC

BGP

Yes

Yes

Yes

Yes

NC

BFD

Yes

Yes

Yes

NC

RIP

Yes

Yes

Yes

Yes

NC

PIM (SSM)

Yes

Yes

Yes

Yes

NC

OSPF

Yes

Yes

Yes

Yes

NC

SMTP

Yes

AF

IGMP/MLD

Yes

Yes

Yes

Yes

AF

Telnet

Yes

Yes

Yes

Yes

AF

TFTP

Yes

Yes

Yes

AF

FTP

Yes

AF

SSH (SCP)

Yes

Yes

Yes

Yes

AF

SNMP (get, set, and so on)

Yes

Yes

Yes

Yes

AF

SNMP trap/log

Yes

Yes

Yes

Yes

AF

syslog

Yes

Yes

Yes

Yes

AF

OAM ping

Yes

Yes

Yes

Yes

AF

ICMP ping

Yes

Yes

Yes

Yes

AF

Traceroute

Yes

Yes

Yes

Yes

AF

TACPLUS

Yes

Yes

Yes

Yes

AF

DNS

Yes

Yes

Yes

Yes

AF

SNTP/NTP

Yes

AF

RADIUS

Yes

AF

Cflowd

Yes

AF

DHCP

7450 ESS and 7750 SR only

Yes

Yes

Yes

Yes

AF

Bootp

Yes

AF

IPv6 Neighbor Discovery

Yes

NC

Default DSCP mapping table


DSCP NameDSCP ValueDSCP ValueDSCP ValueLabel
Decimal Hexadecimal Binary
=============================================================
Default 00x00 0b000000be
nc1 48 0x30 0b110000h1
nc2 56 0x38 0b111000nc
ef 46 0x2e 0b101110ef
af11100x0a0b001010assured
af12120x0c0b001100assured
af13140x0e0b001110assured
af21 18 0x12 0b010010l1
af22 20 0x14 0b010100l1
af23220x160b010110l1
af31 26 0x1a 0b011010l1
af32 28 0x1c 0b011100l1
af33 30 0x1d 0b011110l1
af41 34 0x22 0b100010h2
af42 36 0x24 0b100100h2
af43 38 0x26 0b100110h2

default*0

*The default forwarding class mapping is used for all DSCP names or values for which there is no explicit forwarding class mapping.

Configuration of TTL propagation for VPRN routes

This feature allows the separate configuration of TTL propagation for in transit and CPM generated IP packets, at the ingress LER within a VPRN service context. The following commands are supported:

  • config router ttl-propagate vprn-local [none | vc-only | all]

  • config router ttl-propagate vprn-transit [none | vc-only | all]

You can enable TTL propagation behavior separately as follows:

  • for locally generated packets by CPM (vprn-local)

  • for user and control packets in transit at the node (vprn-transit)

The following parameters can be specified:

  • The all parameter enables TTL propagation from the IP header into all labels in the stack, for VPN-IPv4 and VPN-IPv6 packets forwarded in the context of all VPRN services in the system.

  • The vc-only parameter reverts to the default behavior by which the IP TTL is propagated into the VC label but not to the transport labels in the stack. You can explicitly set the default behavior by configuring the vc-only value.

  • The none parameter disables the propagation of the IP TTL to all labels in the stack, including the VC label. This is needed for a transparent operation of UDP traceroute in VPRN inter-AS Option B such that the ingress and egress ASBR nodes are not traced.

This command does not use a no version.

The user can override the global configuration within each VPRN instance using the following commands:

  • config service vprn ttl-propagate local [inherit | none | vc-only | all]

  • config service vprn ttl-propagate transit [inherit | none | vc-only | all]

The default behavior for a VPRN instance is to inherit the global configuration for the same command. You can explicitly set the default behavior by configuring the inherit value.

This command does not have a no version.

The commands do not apply when the VPRN packet is forwarded over GRE transport tunnel.

If a packet is received in a VPRN context and a lookup is done in the Global Routing Table (GRT), (when leaking to GRT is enabled for example), the behavior of the TTL propagation is governed by the LSP shortcut configuration as follows:

  • when the matching route is an RSVP LSP shortcut: configure router mpls shortcut-transit-ttl-propagate

  • when the matching route is an LDP LSP shortcut: configure router ldp shortcut-transit-ttl-propagate

When the matching route is a RFC 8277 label route or a 6PE route, It is governed by the BGP label route configuration

When a packet is received on one VPRN instance and is redirected using Policy Based Routing (PBR) to be forwarded in another VPRN instance, the TTL propagation is governed by the configuration of the outgoing VPRN instance.

Packets that are forwarded in different contexts can use different TTL propagation over the same BGP tunnel, depending on the TTL configuration of each context. An example of this may be VPRN using a BGP tunnel and an IPv4 packet forwarded over a BGP label route of the same prefix as the tunnel.

CE to PE routing protocols

The 7750 SR and 7950 XRS VPRN supports the following PE to CE routing protocols:

  • BGP

  • Static

  • RIP

  • OSPF

PE to PE tunneling mechanisms

The 7750 SR and 7950 XRS support multiple mechanisms to provide transport tunnels for the forwarding of traffic between PE routers within the 2547bis network.

The 7750 SR and 7950 XRS VPRN implementation supports the use of:

  • RSVP-TE protocol to create tunnel LSPs between PE routers

  • LDP protocol to create tunnel LSP's between PE routers

  • GRE tunnels between PE routers

These transport tunnel mechanisms provide the flexibility of using dynamically created LSPs where the service tunnels are automatically bound (the autobind feature) and the ability to provide specific VPN services with their own transport tunnels by explicitly binding SDPs if needed. When the autobind is used, all services traverse the same LSPs and do not allow alternate tunneling mechanisms (like GRE) or the ability to craft sets of LSPs with bandwidth reservations for specific customers as is available with explicit SDPs for the service.

Per VRF route limiting

The 7750 SR and 7950 XRS allow setting the maximum number of routes that can be accepted in the VRF for a VPRN service. There are options to specify a percentage threshold at which to generate an event that the VRF table is near full and an option to disable additional route learning when full or only generate an event.

Spoke SDPs

Distributed services use service distribution points (SDPs) to direct traffic to another router via service tunnels. SDPs are created on each participating router and then bound to a specific service. SDP can be created as either GRE or MPLS. See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Services Overview Guide for information about configuring SDPs.

This feature provides the ability to cross-connect traffic entering on a spoke SDP, used for Layer 2 services (VLLs or VPLS), on to an IES or VPRN service. From a logical point of view, the spoke SDP entering on a network port is cross-connected to the Layer 3 service as if it entered by a service SAP. The main exception to this is traffic entering the Layer 3 service by a spoke SDP is handled with network QoS policies and not access QoS policies.

SDP-ID and VC label service identifiers depicts traffic terminating on a specific IES or VPRN service that is identified by the sdp-id and VC label present in the service packet.

Figure 8. SDP-ID and VC label service identifiers

See ‟VCCV BFD support for VLL, Spoke SDP Termination on IES and VPRN, and VPLS Services” in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 2 Services and EVPN Guide for information about using VCCV BFD in spoke-SDP termination.

Note: Spoke-SDP termination of Ipipe VLLs on VPRN is not supported in System Profile B. To determine if Ipipes are currently bound to an VPRN interface, use the show router ldp bindings services command before configuring profile B.

T-LDP status signaling for spoke-SDPs terminating on IES/VPRN

T-LDP status signaling and PW active/standby signaling capabilities are supported on Ipipe and Epipe spoke SDPs.

Spoke SDP termination on an IES or VPRN provides the ability to cross-connect traffic entering on a spoke SDP, used for Layer 2 services (VLLs or VPLS), on to an IES or VPRN service. From a logical point of view the spoke SDP entering on a network port is cross-connected to the Layer 3 service as if it had entered using a service SAP. The main exception to this is traffic entering the Layer 3 service using a spoke SDP is handled with network QoS policies instead of access QoS policies.

When a SAP down or SDP binding down status message is received by the PE in which the Ipipe or Ethernet Spoke-SDP is terminated on an IES or VPRN interface, the interface is brought down and all associated routes are withdrawn in a similar way when the Spoke-SDP goes down locally. The same actions are taken when the standby T-LDP status message is received by the IES/VPRN PE.

This feature can be used to provide redundant connectivity to a VPRN or IES from a PE providing a VLL service, as shown in Active/standby VRF using resilient Layer 2 circuits.

Figure 9. Active/standby VRF using resilient Layer 2 circuits

Spoke SDP redundancy into IES/VPRN

This feature can be used to provide redundant connectivity to a VPRN or IES from a PE providing a VLL service, as shown in Active/standby VRF using resilient Layer 2 circuits, using either Epipe or Ipipe spoke-SDPs. This feature is supported on the 7450 ESS and 7750 SR only.

In Active/standby VRF using resilient Layer 2 circuits, PE1 terminates two spoke SDPs that are bound to one SAP connected to CE1. PE1 chooses to forward traffic on one of the spoke SDPs (the active spoke-SDP), while blocking traffic on the other spoke SDP (the standby spoke SDP) in the transmit direction. PE2 and PE3 take any spoke SDPs for which PW forwarding standby has been signaled by PE1 to an operationally down state.

The 7450 ESS, 7750 SR, and 7950 XRS routers are expected to fulfill both functions (VLL and VPRN/IES PE), while the 7705 SAR must be able to fulfill the VLL PE function. Spoke SDP redundancy model illustrates the model for spoke SDP redundancy into a VPRN or IES.

Figure 10. Spoke SDP redundancy model

Weighted ECMP for spoke-SDPs terminating on IES/VPRN and R-VPLS interfaces

ECMP and weighted ECMP into RSVP-TE and SR-TE LSPs is supported for Ipipe and Epipe spoke SDPs terminating on IP interfaces in an IES or VPRN, or for spoke SDP termination on a routed VPLS. It is also supported for SDPs using LDP over RSVP tunnels. Weighted ECMP is configured under the SDP used by the service, as follows:

config
   service
      sdp <sdp-id>
         [no] weighted-ecmp

Default: no weighted-ecmp

When a service uses a provisioned SDP on which weighted ECMP is configured, a path is selected based on the configured hash. Paths are then load balanced across LSPs used by an SDP according to normalized LSP load balancing weights. If one or more LSPs in the ECMP set to a specific next hop has no load-balancing-weight value configured, then regular ECMP spraying is used.

IP-VPNs

Using OSPF in IP-VPNs

Using OSPF as a CE to PE routing protocol allows OSPF that is currently running as the IGP routing protocol to migrate to an IP-VPN backbone without changing the IGP routing protocol, introducing BGP as the CE-PE or relying on static routes for the distribution of routes into the service providers IP-VPN. The following features are supported:

  • Advertisement/redistribution of BGP-VPN routes as summary (type 3) LSAs flooded to CE neighbors of the VPRN OSPF instance. This occurs if the OSPF route type (in the OSPF route type BGP extended community attribute carried with the VPN route) is not external (or NSSA) and the locally configured domain-id matches the domain-id carried in the OSPF domain ID BGP extended community attribute carried with the VPN route.

  • OSPF sham links; a sham link is a logical PE-to-PE unnumbered point-to-point interface that essentially rides over the PE-to-PE transport tunnel. A sham link can be associated with any area and can therefore appear as an intra-area link to CE routers attached to different PEs in the VPN.

IPCP subnet negotiation

This feature enables negotiation between Broadband Network Gateway (BNG) and customer premises equipment (CPE) so that CPE is allocated to both ip-address and associated subnet.

Some CPEs use the network up-link in PPPoE mode and perform dhcp-server function for all ports on the LAN side. Instead of wasting 1 subnet for p2p uplink, CPEs use allocated subnet for the LAN portion as shown in CPEs network up-link mode.

Figure 11. CPEs network up-link mode

From a BNG perspective, the specific PPPoE host is allocated a subnet (instead of /32) by RADIUS, external dhcp-server, or local-user-db. And locally, the host is associated with managed-route. This managed-route is subset of the subscriber-interface subnet (on a 7450 ESS or 7750 SR), and also, subscriber-host ip-address is from managed-route range. The negotiation between BNG and CPE allows CPE to be allocated both ip-address and associated subnet.

Cflowd for IP-VPNs

The cflowd feature allows service providers to collect IP flow data within the context of a VPRN. This data can used to monitor types and general proportion of traffic traversing an VPRN context. This data can also be shared with the VPN customer to see the types of traffic traversing the VPN and use it for traffic engineering.

This feature should not be used for billing purposes. Existing queue counters are designed for this purpose and provide very accurate per bit accounting records.

Inter-AS VPRNs

Inter-AS IP-VPN services have been driven by the popularity of IP services and service provider expansion beyond the borders of a single Autonomous System (AS) or the requirement for IP VPN services to cross the AS boundaries of multiple providers. Three options for supporting inter-AS IP-VPNs are described in RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs).

This feature applies to the 7450 ESS and 7750 SR only.

The first option, referred to as Option-A (Inter-AS Option-A: VRF-to-VRF model), is considered inherent in any implementation. This method uses a back-to-back connection between separate VPRN instances in each AS. As a result, each VPRN instance views the inter-AS connection as an external interface to a remote VPRN customer site. The back-to-back VRF connections between the ASBR nodes require individual sub-interfaces, one per VRF.

Figure 12. Inter-AS Option-A: VRF-to-VRF model

The second option, referred to as Option-B (Inter-AS Option-B), relies heavily on the AS Boundary Routers (ASBRs) as the interface between the autonomous systems. This approach enhances the scalability of the EBGP VRF-to-VRF solution by eliminating the need for per-VPRN configuration on the ASBRs. However it requires that the ASBRs provide a control plan and forwarding plane connection between the autonomous systems. The ASBRs are connected to the PE nodes in its local autonomous system using Interior Border Gateway Protocol (IBGP) either directly or through route reflectors. This means the ASBRs receive all the VPRN information and forward these VPRN updates, VPN-IPV4, to all its EBGP peers, ASBRs, using itself as the next-hop. It also changes the label associated with the route. This means the ASBRs must maintain an associate mapping of labels received and labels issued for those routes. The peer ASBRs in turn forward those updates to all local IBGP peers.

Figure 13. Inter-AS Option-B

This form of inter-AS VPRNs performs all necessary mapping functions and the PE routers do not need to perform any additional functions than in a non-Inter-AS VPRN.

On the 7750 SR, this form of inter-AS VPRNs does not require instances of the VPRN to be created on the ASBR, as in option-A, as a result there is less management overhead. This is also the most common form of Inter-AS VPRNs used between different service providers as all routes advertised between autonomous systems can be controlled by route policies on the ASBRs by the config>router>bgp>transport-tunnel CLI command. The third option, referred to as Option-C (Option C example), allows for a higher scale of VPRNs across AS boundaries but also expands the trust model between ASNs. As a result this model is typically used within a single company that may have multiple ASNs for various reasons. This model differs from Option-B, in that in Option-B all direct knowledge of the remote AS is contained and limited to the ASBR. As a result, in option-B the ASBR performs all necessary mapping functions and the PE routers do not need to perform any additional functions than in a non-Inter-AS VPRN.

Figure 14. Option C example

With Option-C, knowledge from the remote AS is distributed throughout the local AS. This distribution allows for higher scalability but also requires all PEs and ASBRs involved in the Inter-AS VPRNs to participate in the exchange of inter-AS routing information.

In Option-C, the ASBRs distribute reachability information for remote PE’s system IP addresses only. This is done between the ASBRs by exchanging MP-EBGP labeled routes, using RFC 8277, Using BGP to Bind MPLS Labels to Address Prefixes. Either RSVP-TE or LDP LSP can be selected to resolve next-hop for multi-hop EBGP peering by the config>router>bgp>transport-tunnel CLI command.

Distribution of VPRN routing information is handled by either direct MP-BGP peering between PEs in the different ASNs or more likely by one or more route reflectors in ASN.

VPRN label security at inter-AS boundary

This feature allows the user to enforce security at an inter-AS boundary and to configure a router, acting in a PE role or in an ASBR role, or both, to accept packets of VPRN prefixes only from direct EBGP neighbors to which it advertised a VPRN label.

Feature configuration

To use this feature, network IP interfaces that can have the feature enabled must first be identified. Participating interfaces are identified as having the untrusted state. The router supports a maximum of 15 network interfaces that can participate in this feature.

The following command is used to enable or disable this feature.

config>router>interface>untrusted [default-forwarding {forward | drop}]

Normally, the user applies the untrusted command to an inter-AS interface and PIP keeps track of the untrusted status of each interface. In the data path, an inter-AS interface that is flagged by PIP causes the default forwarding to be set to the value of the default-forwarding keyword (forward or drop).

For backward compatibility, default-forwarding on the interface is set to the forward value. This means that labeled packets are checked in the normal way against the table of programmed ILMs to decide if it should be dropped or forwarded in a GRT, a VRF, or a Layer 2 service context.

If the user sets the default-forwarding argument to the drop value, all labeled packets received on that interface are dropped. For details, see Data path forwarding behavior.

This feature sets the default behavior for an untrusted interface in the data path and for all ILMs. To allow the data path to provide an exception to the normal way of forwarding handling away from the default for VPRN ILMs, BGP must flag those ILMs to the data path.

The user enables exceptional ILM forwarding behavior, on a per-VPN-family basis, by using the following command:

configure>router>bgp>neighbor-trust [vpn-ipv4] [vpn-ipv6]

At a high level, BGP tracks each direct EBGP neighbor over an untrusted interface and to which it sent a VPRN prefix label. For each of those VPRN prefixes, BGP programs a bit map in the ILM that indicates, on a per-untrusted interface basis, whether the matching packets must be forwarded or dropped. For details, see CPM behavior.

CPM behavior

This feature affects PIP behavior for management of network IP interfaces and in BGP for the resolution of BGP VPN-IPv4 and VPN-IPv6 prefixes.

The following are characteristics of CPM behavior related to PIP and the VPRN label security at inter-AS boundary feature:

  • PIP manages the status of an untrusted interface based on the user configuration on the interface, as described in Feature configuration. It programs the interface record in the data path using a 4-bit untrusted interface identification number. A trusted interface has no untrusted record.

  • BGP determines the status of trusted or untrusted of an EBGP neighbor by checking the untrusted record provided by PIP for the index of the interface used by the EBGP session to the neighbor.

  • BGP only tracks the status of trusted or untrusted for directly connected EBGP neighbors. The neighbor address and the local address must be on the same local subnet.

  • BGP includes the neighbor status of trusted or untrusted in the tribe criteria. For example, if a group consists of two untrusted EBGP neighbors and one trusted EBGP neighbor and all three neighbors have the same local-AS, neighbor-AS, and export policy, then the result is two different tribes.

    As a result, if the interface status changes from trusted to untrusted or untrusted to trusted, the EBGP neighbors on that interface bounce.

  • When the feature is enabled for a specified VPN family and BGP advertises a label for one or more resolved VPN prefixes to a group of trusted and untrusted EBGP neighbors, it creates a 16-bit map in the ILM record in which it sets the bit position corresponding to the identification number of each untrusted interface used by a EBGP session to a neighbor to which it sent the label.

    A bit in the ILM record bit-map is referred to as the untrusted interface forwarding bit. The bit position corresponding to the identification number of any other untrusted interface is left clear.

    For details on the data path of the ILM bit-map record, see Data path forwarding behavior.

  • Because the same label value is advertised for prefixes in the same VRF (label per-VRF mode) and for prefixes with the same next hop (label per-next-hop mode), BGP programs the forwarding bit position in the ILM bit map for both VPN IPv4 and VPN IPv6 prefixes sharing the same label, as long as the feature is enabled for at least one of the two VPN families.

  • BGP tracks, on a per-untrusted interface basis, the number of RIB-Out entries to EBGP neighbors that reference a specific VPN label. When that reference transitions from zero to a positive value or from a positive value to zero, the label for the ILM of the VPN prefix is re-downloaded to the IOM with the forwarding bit position in the ILM bit map record updated accordingly (set or unset, respectively).

This feature supports label per-VRF and label per-next-hop modes for the PE role. The feature supports label per-next-hop mode for the ASBR role.

The feature is not supported with label per-prefix mode in a PE role and is not supported in a Carrier Supporting Carrier (CSC) PE role.

Data path forwarding behavior

ILM forwarding on a trusted interface behaves as in prior releases and is not changed. The ILM forwarding bit map is ignored and packets are forwarded normally.

ILM forwarding on an untrusted interface follows these rules:

  • Only the top-most label in the label stack in a received packet is checked against the next set of rules. The top label can correspond to any one of the following applications:

    • a transport label with a pop or swap operation of static, RSVP-TE, SR-TE, LDP, SR-ISIS, SR-OSPF, or BGP-LU

    • a BGP VPRN inter-AS option B label with a swap operation when the router acts in the ASBR role for VPN routes

    • a service delimiting label for a local VRF when the router acts as a PE in a VPRN service

  • The data path checks the bit position in the bit map in the ILM record, when present, that corresponds to the untrusted interface identification number in the interface record and then makes a forwarding decision to drop or forward.

    A decision to forward means that a labeled packet proceeds to the regular ILM processing and its label stack is checked against the table of programmed ILMs to decide if the packet should be:

    • dropped

    • forwarded to CPM

    • forwarded as an MPLS packet

    • forwarded as an IP packet in a GRT or a VRF context

    • forwarded as a packet in a Layer 2 service context

  • The following are the processing rules of the ILM:

    • interface default-forwarding=forward and ILM bit-map not present ⇒ forward packet

    • interface default-forwarding=forward and interface forwarding bit position in the ILM bit-map 1 ⇒ forward packet

    • interface default-forwarding=forward and interface forwarding bit position in the ILM bit-map zero ⇒ drop packet

    • interface default-forwarding=drop and ILM bit-map not present ⇒ drop packet

    • interface default-forwarding=drop and interface forwarding bit position in the ILM bit-map zero ⇒ drop packet

    • interface default-forwarding=drop and interface forwarding bit position in the ILM bit-map 1 ⇒ forward packet

  • When the EBGP neighbor is not directly connected, BGP does not track that neighbor (see CPM behavior). In this case, the VPRN packet is received with a transport label or without a transport label if implicit-null is enabled in LDP or RSVP-TE for the transport label. Either way, the forwarding decision for the packet is solely dictated by the configuration of the default-forwarding value on the incoming interface.

  • If the direct EBGP neighbor sends a VPRN packet using the MPLS-over-GRE encapsulation, the data path does not check the interface forwarding bit position in the ILM bit map. In this case, the forwarding decision of the packet is solely dictated by the configuration of the default-forwarding value on the incoming interface.

    SR OS EBGP neighbors never use the MPLS-over-GRE encapsulation over an inter-AS link, but third party implementations may do this.

CSC

Carrier Supporting Carrier (CSC) is a solution for the 7750 SR and 7950 XRS that allows one service provider (the Customer Carrier) to use the IP VPN service of another service provider (the Super Carrier) for some or all of its backbone transport. RFC 4364 defines a Carrier Supporting Carrier solution for BGP/MPLS IP VPNs that uses MPLS on the interconnections between the two service providers to provide a scalable and secure solution.

CSC support in SR OS allows a 7750 SR or 7950 XRS to be deployed as any of the following devices shown in Carrier Supporting Carrier reference diagram:

  • PE1 (service provider PE)

  • CSC-CE1, CSC-CE2 and CSC-CE3 (CE device from the point of view of the backbone service provider)

  • CSC-PE1, CSC-PE2 and CSC-PE3 (PE device of the backbone service provider)

  • ASBR1 and ASBR2 (ASBR of the backbone service provider)

    Figure 15. Carrier Supporting Carrier reference diagram

Terminology

CE
customer premises equipment dedicated to one particular business/enterprise
PE
service provider router that connects to a CE to provide a business VPN service to the associated business/enterprise
CSC-CE
an ASBR/peering router that is connected to the CSC-PE of another service provider for purposes of using the associated CsC IP VPN service for backbone transport
CSC-PE
a PE router belonging to the backbone service provider that supports one or more CSC IP VPN services

CSC connectivity models

A PE router deployed by a customer service provider to provide Internet access, IP VPNs, or L2 VPNs may connect directly to a CSC-PE device, or it may back haul traffic within its local ‟site” to the CSC-CE that provides this direct connection. Here, ‟site” means a set of routers owned and managed by the customer service provider that can exchange traffic through means other than the CSC service. The function of the CSC service is to provide IP/MPLS reachability between isolated sites.

The CSC-CE is a ‟CE” from the perspective of the backbone service provider. There may be multiple CSC-CEs at a specific customer service provider site and each one may connect to multiple CSC-PE devices for resiliency/multi-homing purposes.

The CSC-PE is owned and managed by the backbone service provider and provides CSC IP VPN service to connected CSC-CE devices. In many cases, the CSC-PE also supports other services, including regular business IP VPN services. A single CSC-PE may support multiple CSC IP VPN services. Each customer service provider is allocated its own VRF within the CSC-PE; VRFs maintain routing and forwarding separation and allow the use of overlapping IP addresses by different customer service providers.

A backbone service provider may not have the geographic span to connect, with reasonable cost, to every site of a customer service provider. In this case, multiple backbone service providers may coordinate to provide an inter-AS CSC service. Different inter-AS connectivity options are possible, depending on the trust relationships between the different backbone service providers.

The CSC Connectivity Models apply to the 7750 SR and 7950 XRS only.

CSC interface

From the point of view of the CSC-PE, the IP/MPLS interface between the CSC-PE and a CSC-CE has these characteristics:

  1. The CSC interface is associated with one (and only one) VPRN service. Routes with the CSC interface as next-hop are installed only in the routing table of the associated VPRN.

  2. The CSC interface supports EBGP or IBGP for exchanging labeled IPv4 routes (RFC 8277). The BGP session may be established between the interface addresses of the two routers or else between a loopback address of the CSC-PE VRF and a loopback address of the CSC-CE. In the latter case, the BGP next-hop is resolved by either a static or OSPFv2 route.

  3. An MPLS packet received on a CSC interface is dropped if the top-most label was not advertised over a BGP (RFC 8277) session associated with one of the VPRN’s CSC interfaces.

  4. The CSC interface supports ingress QoS classification based on 802.1p or MPLS EXP. It is possible to configure a default FC and default profile for the CSC interface.

  5. The CSC interface supports QoS (re)marking for egress traffic. Policies to remark 802.1p or MPLS EXP based on forwarding-class and profile are configurable per CSC interface.

  6. By associating a port-based egress queue group instance with a CSC interface, the egress traffic can be scheduled/shaped with per-interface, per-forwarding-class granularity.

  7. By associating a forwarding-plane based ingress queue group instance with a CSC interface, the ingress traffic can be policed to per-interface, per-forwarding-class granularity.

  8. Ingress and egress statistics and accounting are available per CSC interface. The exact set of collected statistics depends on whether a queue-group is associated with the CSC interface, the traffic direction (ingress vs. egress), and the stats mode of the queue-group policers.

An Ethernet port or LAG with a CSC interface can be configured in hybrid mode or network mode. The port or LAG supports null, dot1q or qinq encapsulation. To create a CSC interface on a port or LAG in null mode, the following commands are used:

config>service>vprn>nw-if>port port-id config>service>vprn>nw-if>lag lag-id

To create a CSC interface on a port or LAG in dot1q mode, the following commands are used:

config>service>vprn>nw-if>port port-id:qtag1 config>service>vprn>nw-if>lag port-id:qtag1

To create a CSC interface on a port or LAG in qinq mode, the following commands are used:

config>service>vprn>nw-if>port port-id:qtag1.qtag2 config>service>vprn>nw-if>port port-id:qtag1.* config>service>vprn>nw-if>lag port-id:qtag1.qtag2 config>service>vprn>nw-if>lag port-id:qtag1.*

A CSC interface supports the same capabilities (and supports the same commands) as a base router network interface, except it does not support:

  • IPv6

  • LDP

  • RSVP

  • Proxy ARP (local/remote)

  • Network domain configuration

  • DHCP

  • Ethernet CFM

  • Unnumbered interfaces

QoS

Egress

Egress traffic on a CSC interface can be shaped and scheduled by associating a port-based egress queue-group instance with the CSC interface. The steps for doing this are summarized below:

  1. Create an egress queue-group-template.
  2. Define one or more queues in the egress queue-group. For each one specify scheduling parameters such as CIR, PIR, CBS and MBS and, if using H-QoS, the parent scheduler.
  3. Apply an instance of the egress queue-group template to the network egress context of the Ethernet port with the CSC interface. When doing so, and if applicable, associate an accounting policy or a scheduler policy, or both, with this instance.
  4. Create a network QoS policy.
  5. In the egress part of the network QoS policy define EXP remarking rules, if necessary.
  6. In the egress part of the network QoS policy map a forwarding-class to a queue-id using the port-redirect-group command.
    For example:

    config>qos>network>egress>fc$ port-redirect-group queue 5

  7. Apply the network QoS policy created in step 4 to the CSC interface and specify the name of the egress queue-group created in step 1 and the specific instance defined in step 3.
Ingress
Ingress traffic on a CSC interface can be policed by associating a forwarding-plane based ingress queue-group instance with the CSC interface. The steps for doing this are summarized below:
  1. Create an ingress queue-group-template.
  2. Define one or more policers in the ingress queue-group. For each one specify parameters such as CIR, PIR, CBS and MBS and, if using H-Pol, the parent arbiter.
  3. Apply an instance of the ingress queue-group template to the network ingress context of the forwarding plane with the CSC interface.
    When doing so, and if applicable, associate an accounting policy or a policer-control-policy, or both, with this instance.
  4. Create a network QoS policy.
  5. In the ingress part of the network QoS policy define EXP classification rules, if necessary.
  6. In the ingress part of the network QoS policy map a forwarding-class to a policer-id using the fp-redirect-group policer command.
    For example:

    config>qos>network>ingress>fc$ fp-redirect-group policer 5

  7. Apply the network QoS policy created in step 4 to the CSC interface and specify the name of the ingress queue-group created in step 1 and the specific instance defined in step 3.

MPLS

BGP-8277 is used as the label distribution protocol on the CSC interface. When BGP in a CSC VPRN needs to distribute a label corresponding to a received VPN-IPv4 route, it takes the label from the global label space. The allocated label is not re-used for any other FEC regardless of the routing instance (base router or VPRN). If a label L is advertised to the BGP peers of CSC VPRN A then a received packet with label L as the top most label is only valid if received on an interface of VPRN A, otherwise the packet is discarded.

To use BGP-8277 as the label distribution protocol on the CSC interface, add the family label-ipv4 command to the family configuration at the instance, group, or neighbor level. This causes the capability to send and receive labeled-IPv4 routes {AFI=1, SAFI=4} to be negotiated with the CSC-CE peers.

CSC VPRN service configuration

To configure a VPRN to support CSC service, the carrier-carrier-vpn command must be enabled. The command fails if the VPRN service has any existing SAP or spoke SDP interfaces. A CSC interface can be added to a VPRN (using the network-interface command) only if the carrier-carrier-vpn command is enabled.

A VPRN service with the carrier-carrier-vpn command may be provisioned to use auto-bind-tunnel, configured spoke SDPs, or some combination. All SDP types are supported except for:

  • GRE SDPs
  • LDP over RSVP-TE tunnel SDPs

Other aspects of VPRN configuration are the same in a CSC model as in a non-CSC model.

Node management using VPRN

There are two basic approaches that can be used to manage a node using a VPRN. In both cases, management traffic is received and sent in the VPRN router instance:

  • Management traffic can target the IP address of a VPRN interface
  • Management traffic can target the system address in the base router instance (using grt-leaking)

In the first approach, node management can be enabled using the local interface of any VPRN service. A management VPRN is separated from other traffic using an MPLS transport tunnel. This provides IP domain separation and security for the management domain. The management domain supports IPv4 and IPv6 address families and the AAA server is connected to the same VPRN for authentication, authorization, and accounting. The SR OS allows management using a VPRN as long the management packet is destined for a local interface of the VPRN, in addition it allows configuration of the AAA servers within a VPRN; see VRF network example.

In the second approach, node management is achieved using GRT leaking. In this case the management traffic uses an IP address in the Base routing context. See Management via VPRN using GRT leaking for details on this method.

The remainder of this section describes node management using the local VPRN interfaces (non grt-leaking).

Figure 16. VRF network example

VPRN management

VPRN management can be enabled by configuring the appropriate management protocol within the VPRN from the vprn>management context. The following protocols can be enabled in this context:

  • FTP

  • gRPC

  • NETCONF

  • SSH

  • Telnet

  • Telnetv6

SNMP access is not controlled in the vprn>management context. See section SNMP management.

NTP and PTP access are not controlled in the vprn>management context. See NTP within a VPRN service and PTP within a VPRN service.

By default, all protocols are disabled. When one of these protocols is enabled, that VRF becomes a management VRF.

Note: An SSH server can only be enabled or disabled in VPRN. All other SSH configurations such as key re-exchange, SSH client/server HMAC/cipher list, and so on, are configured under the system and used globally.

All other gRPC configurations remain global under the config>system>grpc context.

All other NETCONF configurations remain global under the config>system>management-interface>netconf context.

The TLS profiles needed for gRPC can be configured under the config>system>security>tls context.

AAA management

To configure the authentication, authorization, and accounting order for the system, including VPRNs, use the following CLI contexts:
  • Classic CLI

    config>system>security>password>authentication-order

  • MD-CLI

    configure system security user-params authentication-order order

To configure the system local user profile configuration for local user authentication and authorization, including VPRNs, use the following CLI contexts:

  • Classic CLI

    config>system>security>profile

  • MD-CLI

    configure system security aaa local-profiles profile

To configure AAA servers, use the following CLI contexts:

  • Classic CLI

    config>system>security for system AAA servers

    config>service>vprn>aaa>remote-servers for AAA remote servers under the VPRN

  • MD-CLI

    configure system security aaa for system AAA servers

    configure service vprn aaa remote-servers for AAA remote servers under the VPRN

When AAA servers are configured using the preceding commands, they are used as follows:

  • If servers are configured under the VPRN AAA, only the VPRN AAA servers are used.

    For example, the authentication-order command lists the order as local, TACACS+, and RADIUS, while the VPRN only has a RADIUS server configured, and under the system AAA servers both TACACS+ and RADIUS are configured. In this case, if a management session connects to the VPRN and the destination IP matches a local interface in the VPRN, the SR OS tries the local AAA first, and then RADIUS as configured in the VPRN. The SR OS does not try the system AAA servers because there is a AAA server configured in the VPRN.

  • If servers are configured under VPRN AAA and the VPRN AAA parameters are configured for in-band, out-of-band, or VPRN, the servers can be used for the VPRN and the system.
  • If no AAA servers are configured under VPRN AAA, the system AAA servers are used.

SNMP management

The SR OS SNMP agent can be reached via a VPRN interface address when configure>service>vprn>snmp>access is enabled.

Using an SNMP community defined inside the VPRN context (configure>service>vprn>snmp>community) or a user associated with an SNMPv3 USM access group defined in the system context (configure>system>snmp>access) allows access to a subset of the full SNMP data model. This subset can be seen in the output of show system security view "vprn-view".

Using an SNMP community defined in the system context (configure>system> security>snmp>community) allows access to the full SNMP data model (unless otherwise restricted used SNMP views).

Alternatively, grt leaking and a Base routing IP address can be used (along with an SNMP community defined at the system context) to get access to the entire SNMP data model (see the allow-local-management command).

A network manager using SNMP, cannot discover or fully manage an SR OS router using an SNMP community defined inside the VPRN context. Full SNMP access requires using one of the approaches described above.

SNMP communities configured under a VPRN are associated with the SNMP context "vprn". For example, walking the ifTable (IF-MIB) using the community configured for VPRN 5 returns counters and status for interfaces in VPRN 5 only.

Note: To access Base router ifTable entries in a VPRN, use the community string that is defined in the system context (config>system>security>snmp>community).

To access VPRN ifTable entries, use the community string that is defined inside that VPRN context (config>service>vprn>snmp>community).

Events and notifications

Syslog, SNMP traps and Netconf notifications are generated via the Event Logging System.

VPRN syslog destinations are defined under the config>service>vprn>log>syslog context.

SNMP trap destination in a VPRN are defined using the config>service>vprn>log>snmp-trap-group context.

Events for the whole system can be directed to a destination within the management VPRN by using the config>log>services-all-events command. See the 7450 ESS, 7750 SR, 7950 XRS, and VSR System Management Guide for details of this command.

DNS resolution

DNS default domain name and DNS servers for domain name resolution can be defined within a VPRN in the config>service>vprn>dns context.

Traffic leaking to GRT

Traffic leaking to Global Route Table (GRT) for the 7750 SR and 7950 XRS allows service providers to offer VPRN and Internet services to their customers over a single VRF interface. This supports IPv4 and, for the 7750 SR, requires the customer VPRN interfaces to terminate on a minimum of IOM3-XP and IMM hardware.

Packets entering a local VRF interface can have route processing results derived from the VPRN forwarding table or the GRT. The leaking and preferred lookup results are configured on a per VPRN basis. Configuration options can be general (for example, any lookup miss in the VPRN forwarding table can be resolved in the GRT), or specific (for example, specific routes should only be looked up in the GRT and ignored in the VPRN). To provide operational simplicity and improve streamlining, the CLI configuration is contained within the context of the VPRN service.

This feature is enabled within the VPRN service context under config>service>vprn>grt-lookup. This is an administrative context and provides the container under which the user can enter all specific commands, except policy definition. Policy definitions remain unchanged but are referenced from this context.

The enable-grt command establishes the basic functionality. When it is configured, any lookup miss in the VRF table is resolved in the GRT, if available. By itself, this only provides part of the solution. Packet forwarding within GRT must route packets back to the correct node and to the specific VPRN from which the destination exists. Destination prefixes must be leaked from the VPRN to the GRT through the use of policy. Policies are created under the config>router>policy-options hierarchy. By default, the number of prefixes leaked from the VPRN to the GRT is limited to five. The export-limit command under the grt-lookup hierarchy allows a service provider to override the default, or remove the limit.

When a VPRN forwarding table consists of a default route or an aggregate route, the customer may require the service provider to poke holes in those, or provide more specific route resolution in the GRT. In this case, the service provider may configure a static-route-entry and specify the GRT as the nexthop type.

The lookup result prefers any successful lookup in the GRT that is equal to or more specific than the static route, bypassing any successful lookup in the local VPRN.

This feature and Unicast Reverse Path Forwarding (uRPF) are mutually exclusive. When a VPRN service is configured with either of these functions, the other cannot be enabled. Also, prefixes leaked from any VPRN should never conflict with prefixes leaked from any other VPRN or existing prefixes in the GRT. Prefixes should be globally unique within the service provider network and if these are propagated outside a single provider network, they must be from the public IP space and globally unique. Network Address Translation (NAT) is not supported as part of this feature. The following type of routes are not leaked from VPRN into the Global Routing Table (GRT):

  • Aggregate routes

  • Blackhole routes

  • BGP VPN extranet routes

Management via VPRN using GRT leaking

In addition to node management using the IP addresses of VPRN interfaces, see Node management using VPRN, management via a VPRN can also be achieved using IP addresses in the Base routing instance and GRT leaking.

When a management packet arrives on a VPRN, there is a lookup for the destination IP address of the packet. If the destination IP is resolved using VPRN and the corresponding protocol is enabled under VPRN management, then the packet is extracted to CPM.

If the destination IP address is not a VRF IP and GRT leaking is enabled, a second lookup is done in the GRT FIB. If the IP belongs to a local interface in GRT and allow-local-management is enabled under enable-grt, then the packet is extracted using GRT leaking to the CPM.

Traffic leaking from VPRN to GRT for IPv6

This feature allows IPv6 destination lookups in two distinct routing tables and applies only to the 7750 SR and 7950 XRS. IPv6 packets within a Virtual Private Routed Network (VPRN) service is able to perform a lookup for IPv6 destination against the Global Route Table (GRT) as well as within the local VPRN.

Currently, VPRN to VPRN routing exchange is accomplished through the use of import and export policies based on Route Targets (RTs), the creation of extranets. This new feature allows the use of a single VPRN interface for both corporate VPRN routing and other services (for example, Internet) that are reachable outside the local routing context. This feature takes advantage of the dual lookup capabilities in two separate routing tables in parallel.

This feature enables IPv6 capability in addition to the existing IPv4 VPRN-to-GRT Route Leaking feature.

RIP metric propagation in VPRNs

When RIP is used as the PE-CE protocol for VPRNs (IP-VPNs), the RIP metric is only used by the local node running RIP with the Customer Equipment (CE). The metric is not used to or encoded into and MP-BGP path attributes exchanged between PE routers.

The RIP metric can also be used to be exchanged between PE routers so if a customer network is dual homed to separate PEs the RIP metric learned from the CE router can be used to choose the best route to the destination subnet. By using the learned RIP metric to set the BGP MED attribute, remote PEs can choose the lowest MED and in turn the PE with the lowest advertised RIP metric as the preferred egress point for the VPRN. RIP metric propagation in VPRNs shows RIP metric propagation in VPRNs.

Figure 17. RIP metric propagation in VPRNs

NTP within a VPRN service

Communication to external NTP clocks through VPRNs is supported in two ways: communication with external servers and peers, and communication with external clients.

Communication with external servers and peers are controlled using the same commands as used for access via base routing (see Network Time Protocol (NTP) in the 7450 ESS, 7750 SR, 7950 XRS, and VSR Basic System Configuration Guide). Communication with external clients is controlled via the VPRN routing configuration. The support for the external clients can be as unicast or broadcast service. In addition, authentication keys for external clients are configurable on a per-VPRN basis.

Only a single instance of NTP remains in the node that is time sourced to as many as five NTP servers attached to the base or management network.

The NTP show command displays NTP servers and all known clients. Because NTP is UDP-based only, no state is maintained. As a result, the show command output only displays when the last message from the client was received.

PTP within a VPRN service

The PTP within a VPRN service provides access to the PTP clock within the 7750 SR through one or more VPRN services. Only one VPRN or the base routing instance may have configured peers, but all may have discovered peers. If needed, a limit on the maximum number of dynamic peers allowed may be configured on a per routing instance basis.

For more detail on PTP see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Basic System Configuration Guide.

VPN route label allocation

The method used for allocating a label value to an originated VPN-IP route (exported from a VPRN) depends on the configuration of the VPRN service and its VRF export policies. SR OS supports three 3 label modes:

  • label per VRF

  • label per next hop (LPN)

  • label per prefix (LPP)

Label per VRF is the label allocation default. It is used when the label mode is configured as VRF (or not configured) and the VRF export policies do not apply an advertise-label per-prefix action. All routes exported from the VPRN with the per-VRF label have the same label value. When the PE receives a terminating MPLS packet with a per-VRF label, the label value selects the VRF context in which to perform a forwarding table lookup and this lookup determines the outgoing interface (or set of interfaces if ECMP applies).

Label per next hop is used when the exported route is not a local or aggregate route, the label mode is configured as next-hop, and the VRF export policies do not apply an advertise-label per-prefix override. It is also used when an inactive (backup path) BGP route is exported by effect of the export-inactive-bgp command if there is no advertise-label per-prefix override. All LPN-exported routes with the same primary next hop have the same per-next-hop label value. When the PE receives a terminating MPLS packet with a per-next-hop label, the label lookup selects the outgoing interface for forwarding, without any FIB lookup that may cause problems with overlapping prefixes. LPN does not support ECMP, BGP fast reroute, QPPB, or policy accounting features that may otherwise apply.

Label per-prefix is used when a qualifying IP route is exported by matching a VRF export policy action with advertise-label per-prefix. Any IPv4 or IPv6 route that is not a local route, aggregate route, BGP-VPN route, or GRT lookup static route qualifies. With LPP, every prefix is associated with its own unique label value that does not change while the route is present in the route table. When the PE receives a terminating MPLS packet with a per-prefix label value, the packet is forwarded as if the FIB lookup found only the matching prefix route and not any of the more specific prefix routes that would normally be selected. LPP supports ECMP, QPPB, and policy accounting as part of the egress forwarding decision. It does not support BGP fast reroute or BGP sticky ECMP.

The following points summarize the logic that determines the label allocation method for an exported route:

  • If the IP route is LOCAL, AGGREGATE, or BGP-VPN always use the VRF label.

  • If the IP route is accepted by a VRF export policy with the advertise-label per-prefix action, use LPP.

  • If the IP (BGP) route is exported by the export-inactive-bgp command (VPRN best external), use LPN.

  • If the IP route is exported by a VPRN configured for label-mode next-hop, use LPN.

  • Else, use the per-VRF label.

Configuring the service label mode

To change the service label mode of the VPRN for the 7750 SR, the config>service>vprn>label-mode {vrf | next-hop} command is used:

The default mode (if the command is not present in the VPRN configuration) is vrf meaning distribution of one service label for all routes of the VPRN. When a VPRN X is configured with the label-mode next-hop command the service label that it distributes with an IPv4 or IPv6 route that it exports depends on the type of route as summarized in Service labels distributed in service label per next hop mode.

Table 4. Service labels distributed in service label per next hop mode
Route type Distributed service label

remote route with IP A (associated with a SAP) as resolved next-hop

platform-wide unique label allocated to next-hop A

remote route with IP B (associated with a spoke SDP) as resolved next-hop

platform-wide unique label allocated to next-hop B

local route

platform-wide unique label allocated to VPRN X

aggregate route

platform-wide unique label allocated to VPRN X

ECMP route

platform-wide unique label allocated to next-hop A (the lowest next-hop address in the ECMP set)

BGP route with a backup next-hop (BGP FRR)

platform-wide unique label allocated to next-hop A (the lowest next-hop address of the primary next-hops)

A change to the label-mode of a VPRN requires the VPRN to first be shutdown.

Restrictions and usage notes

The service label per next-hop mode has the following restrictions (applies only to the 7750 SR):

  • ECMP

    The VPRN label mode should be set to VRF if distribution of traffic across the multiple PE-CE next-hop interfaces of an ECMP route is needed.

  • hub and spoke VPN

    The VPRN label mode should not be set to next-hop if the operator does not want the hub-connected CE to be involved in the forwarding of spoke-to-spoke traffic.

  • BGP next-hop indirection

    BGP next-hop indirection has no benefit in service label per next-hop mode. When the resolved next-hop interface of a BGP next-hop changes all of the affected BGP routes must be re-advertised to VPRN peers with the new service label corresponding to the new resolved next-hop.

  • BGP anycast

    When a PE failure results in redirection of MPLS packets to the other PE in a dual-homed pair, the service label mode is forced to VRF, for example, FIB lookup determines the next-hop even if the label mode of the VPRN is configured as next-hop.

  • U-turn routing

    U-turn routing is effectively disabled by service-label per next-hop.

  • Carrier Supporting Carrier

    The label-mode configuration of a VPRN with CSC interfaces is ignored for BGP-8277 routes learned from connected CSC-CE devices.

VPRN Support for BGP FlowSpec

When a VPRN BGP instance receives an IPv4 or IPv6 flow route, and that route is valid/best, the system attempts to construct an IPv4 or IPv6 filter entry from the NLRI contents and the actions encoded in the UPDATE message. If the attempt is successful, the filter entry is added to the system-created ‟fSpec-n” IPv4 or IPv6 embedded filter, where n is the service-id of the VPRN. These embedded filters may be inserted into configured IPv4 and IPv6 filter policies that are applied to ingress traffic on a selected set of the VPRN’s IP interfaces. These interfaces can include SAP and spoke SDP interfaces, but not CsC network interfaces.

When FlowSpec rules are embedded into a user-defined filter policy, the insertion point of the rules is configurable through the offset parameter of the embed-filter command. The sum of the ip-filter-max-size and offset must not exceed the maximum filter entry-id range.

MPLS entropy label and hash label

The router supports both the MPLS entropy label (RFC 6790) and the Flow Aware Transport label, known as the hash label (RFC 6391). LSR nodes in a network can load-balance labeled packets in a more granular way than by hashing on the standard label stack. See the 7450 ESS, 7750 SR, 7950 XRS, and VSR MPLS Guide for more information.

The entropy label is supported for VPRN services, as well as Epipe and Ipipe spoke-SDP termination on VPRN interfaces. To configure insertion of the entropy label, use the entropy-label command in the vprn context or spoke-sdp context of an interface.

The hash label is also supported for Epipe and Ipipe spoke-SDP termination on VPRN and VPRN services bound to any MPLS-type encapsulated SDP, as well as to a VPRN service using auto-bind-tunnel with the resolution-filter configured as any MPLS tunnel type. Configure it using the hash-label command in the vprn, vprn>spoke-sdp, and vprn>if>spoke-sdp contexts.

Either the hash label or the entropy label can be configured on one object, but not both.

LSP tagging for BGP next hops or prefixes and BGP-LU

It is possible to constrain the tunnels used by the system for resolution of BGP next-hops or prefixes and BGP labeled unicast routes using LSP administrative tags. See ‟LSP Tagging and Auto-Bind Using Tag Information‟ section of the 7450 ESS, 7750 SR, 7950 XRS, and VSR MPLS Guide for more information.

Route leaking from the global route table to VPRN instances

The Global Route Table (GRT) to VPRN route leaking feature allows actual routes from the global route table to be exported into specific VPRN instances allowing those routes to be used for forwarding as well as being re-advertised within the VPRN context.

There are two stages for route leaking. The first stage requires the configuration of a set of leak-export route policies that identifies which GRT routes are subject to being exported into VPRN services. The leak-export command in the configure>router context is used to configure between one and four route policies. The GRT routes must match the policy entries configured with action accept. In addition, the leak-export-limit command is used to specify the maximum number of GRT routes that can be included in the GRT leak pool.

The second stage requires the configuration of an import-grt policy that specifies which routes within the GRT leak pool that are leaked into the associated VPRN instances route table. The import-grt command in the config>service>vprn>grt-lookup context is used and accepts one route policy. In order for the GRT route to be leaked into the local VPRN, the route must match a policy entry with action accept.

If a GRT route passes both stages, it is added into the VPRN route table which it to be used for IP forwarding as well as re-advertisement within other routing protocols within the VPRN context.

Both IPv4 and IPv6 routes can be leaked using this process from the GRT into one or more VPRN instances. The GRT route types that can be leaked using this process are:

  • RIP, OSPF, and IS-IS routes

  • Direct routes

  • Static routes

Class-based forwarding of VPN-v4/v6 prefixes over RSVP-TE or SR-TE LSPs

This feature enables class-based forwarding (CBF) with ECMP of BGP VPN-v4/v6 prefixes that are resolved using RSVP-TE or SR-TE as auto-bind-tunnel.

Feature configuration

To configure this feature:

  • Enable resolution to RSVP-TE or SR-TE tunnels in the auto-bind-tunnel context.

  • Enable ECMP in the auto-bind-tunnel context.

  • Enable class-forwarding in the vprn context.

  • Define at least one class forwarding policy in the mpls context, the FC to sets associations and the LSP to (policy, set) associations.

The SR OS CBF implementation supports spraying of packets over a maximum of six forwarding sets of ECMP LSPs only when the system profile is profile-b that is supported on an FP4 or later-based CPM. In any other case, the maximum number of forwarding sets of ECMP LSPs is four.

config
      router
            [no] mpls
                  class-forwarding-policy policy-name create
                  fc be forwarding-set set-id <1..6>
                  fc l2 forwarding-set set-id <1..6>
                  fc af forwarding-set set-id <1..6>
                  fc l1 forwarding-set set-id <1..6>
                  fc h2 forwarding-set set-id <1..6>
                  fc ef forwarding-set set-id <1..6>
                  fc h1 forwarding-set set-id <1..6>
                  fc nc forwarding-set set-id <1..6>
                  [no] default-set set-id <1..6>

All FCs are mapped to set 1 as soon as the policy is created. The user can make changes to the mapping of FCs as required. An FC that is not added to the class-forwarding policy, is always mapped to set 1. At most, an FC can be mapped to a single forwarding set. One or more FCs can be mapped to the same set. The user can indicate the initial default set by including the default-set option.

The default forwarding set is used to forward packets of any FC in cases where all LSPs of the forwarding set the FC maps to become operationally DOWN. The router uses the user-configured default set as the initial default set. Otherwise, the router selects the lowest numbered set as the default forwarding set in a class-forwarding policy. When the last LSP in a default forwarding set goes into an operationally DOWN state, the router designates the next lowest-numbered set as the new default forwarding set.

A mapping to a class-forwarding policy and set is added to the existing CBF configuration of an RSVP-TE or SR-TE LSP or to an LSP template. The following commands perform this function:

config>router>mpls>lsp>class-forwarding forward-set policy policy-name set set-id

config>router>mpls>lsp-template>class-forwarding forwarding-set policy policy-name set set-id

An MPLS LSP only maps to a single class-forwarding policy and forwarding set. Multiple LSPs can map to the same policy and set. If they form an ECMP set, from the IGP shortcut perspective, packets of the FCs mapped to this set are sprayed over these LSPs based on a modulo operation of the output of the hash routine on the headers of the packet and the number of LSPs in the set.

Feature behavior

When a VPN-v4/v6 prefix is resolved, the default behavior of the data path is to spray the packets over the entire ECMP set using a modulo operation of the number of resolved next hops in the ECMP set and the output of the hash on the packet header fields. With class-based forwarding enabled, the FC of the packet, is used to look up the forwarding set ID. Then, a modulo operation is performed on the tunnel next hops of this set ID only, to spray packets of this FC. The data path concurrently implements ECMP within the tunnels of each set ID.

The CBF information of the LSPs forming the ECMP set is checked for consistency before programming. If more than a single class-forwarding policy exists, the set is considered inconsistent from a CBF perspective and no CBF information is programmed in the data-path and regular ECMP occurs.

Also, regardless of the CBF consistency check, the system programs the data-path with the full ECMP set.

The following describes the fall-back behavior in data path of the CBF feature.

An FC, for which all LSPs in the forwarding set are operationally DOWN, has its packets forwarded over the default forwarding set. The default forwarding set is either the initial default forwarding set configured by the user or the lowest numbered set in the class-forwarding policy that has one or more LSPs in the operationally UP state. If the initial or subsequently elected default forwarding set has all its LSPs operationally DOWN, the next lower numbered forwarding set, which has at least one LSP in the operationally UP state, is elected as the default forwarding set.

If all LSPs of all forwarding sets become operationally DOWN, the router resumes regular ECMP spraying on the remaining LSPs in the full ECMP set.

Whenever the first LSP in a forwarding set becomes operationally UP, the router triggers the re-election of the default set and selects this set as the new default set, if it is the initial default set, otherwise, it selects the lowest numbered set.

SR OS implements a hierarchical ECMP architecture for BGP prefixes. The first level is the ECMP at the VPRN Level between different BGP next hop, and the second level is ECMP at the auto-bind-tunnel level, having the same next hop. This CBF feature is applied at the auto-bind-tunnel level. Weighted ECMP and the CBF feature are mutually exclusive on a per-BGP next-hop basis. When both are configured, Weighted ECMP takes the preference. CPM-originated packets on the router, including control plane and OAM packets, are forwarded over a single LSP from the set of LSPs that the packet's FC is mapped to, as per the CBF configuration.

QoS on ingress bindings

Traffic is tunneled between VPRN service instances on different PEs over service tunnels bound to MPLS LSPs or GRE tunnels. The binding of the service tunnels to the underlying transport is achieved either automatically (using the auto-bind-tunnel command) or statically (using the spoke-sdp command; not that under the VPRN IP interface). QoS control can be applied to the service tunnels for traffic ingressing into a VPRN service; see Ingress QoS control on VPRN bindings.

Figure 18. Ingress QoS control on VPRN bindings

An ingress queue group must be configured and applied to the ingress network FP where the traffic is received for the VPRN. All traffic received on that FP for any binding in the VPRN (either automatically or statically configured) which is redirected to a policer in the FP queue group (using fp-redirect-group in the network QoS policy) is controlled by that policer. As a result, the traffic from all such bindings is treated as a single entity (per forwarding class) with regard to ingress QoS control. Any fp-redirect-group mcast-policer, broadcast-policer or unknown-policer commands in the network QoS policy are ignored for this traffic (IP multicast traffic would use the ingress network queues or queue group related to the network interface).

Ingress classification is based on the configuration of the ingress section of the specified network QoS policy, noting that the dot1p and exp classification is based on the outer Ethernet header and MPLS label whereas the DSCP applies to the outer IP header if the tunnel encapsulation is GRE, or the DSCP in the first IP header in the payload if ler-use-dscp is enabled in the ingress section of the referenced network QoS policy.

Ingress bandwidth control does not take into account the outer Ethernet header, the MPLS labels/control word or GRE headers, or the FCS of the incoming frame.

The following command configures the association of the network QoS policy and the FP queue group and instance within the network ingress of a VPRN:

configure
    vprn
        network
            ingress
                qos <network-policy-id> fp-redirect-group <queue-group-name>
                                        instance <instance-id>

When this command is configured, it overrides the QoS applied to the related network interfaces for unicast traffic arriving on bindings in that VPRN. The IP and IPv6 criteria statements are not supported in the applied network QoS policy.

This is supported for all available transport tunnel types and is independent of the label mode (vrf or next-hop) used within the VPRN. It is also supported for Carrier-Supporting-Carrier VPRNs.

The ingress network interfaces on which the traffic is received must be on FP2- and higher-based hardware.

Multicast in IP-VPN applications

This section and its subsections focuses on Multicast in IP VPN functionality. See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Multicast Routing Protocols Guide for information about multicast protocols.

Applications for this feature include enterprise customer implementing a VPRN solution for their WAN networking needs, customer applications including stock-ticker information, financial institutions for stock and other types of trading data and video delivery systems.

Implementation of multicast in IP VPNs entails the support and separation of the providers core multicast domain from the various customer multicast domains and the various customer multicast domains from each other.

Figure 19. Multicast in IP-VPN applications

Multicast in IP-VPN applications depicts an example of multicast in an IP-VPN application. The provider’s domain encompasses the core routers (1 through 4) and the edge routers (5 through 10). The various IP-VPN customers each have their own multicast domain, VPN-1 (CE routers 12, 13 and 16) and VPN-2 (CE Routers 11, 14, 15, 17 and 18). Multicast in this VPRN example, the VPN-1 data generated by the customer behind router 16 is multicast only by PE 9 to PE routers 6 and 7 for delivery to CE routers 12 and 13 respectively. Data generated for VPN-2 generated by the customer behind router 15 is forwarded by PE 8 to PE routers 5, 7 and 10 for delivery to CE routers 18, 11, 14 and 17 respectively.

The demarcation of these domains is in the PE’s (routers 5 through 10). The PE router participates in both the customer multicast domain and the provider’s multicast domain. The customer’s CEs are limited to a multicast adjacency with the multicast instance on the PE specifically created to support that specific customer’s IP-VPN. This way, customers are isolated from the provider’s core multicast domain and other customer multicast domains while the provider’s core routers only participate in the provider’s multicast domain and are isolated from all customers’ multicast domains.

The PE for a specific customer’s multicast domain becomes adjacent to the CE routers attached to that PE and to all other PE’s that participate in the IP-VPN (or customer) multicast domain. This is achieved by the PE who encapsulates the customer multicast control data and multicast streams inside the provider’s multicast packets. These encapsulated packets are forwarded only to the PE nodes that are attached to the same customer’s edge routers as the originating stream and are part of the same customer VPRN. This prunes the distribution of the multicast control and data traffic to the PEs that participate in the customer’s multicast domain. The Rosen draft refers to this as the default multicast domain for this multicast domain; the multicast domain is associated with a unique multicast group address within the provider’s network.

Use of data MDTs

Using the above method, all multicast data offered by a specific CE is always delivered to all other CEs that are part of the same multicast. It is possible that a number of CEs do not require the delivery of a particular multicast stream because they have no downstream receivers for a specific multicast group. At low traffic volumes, the impact of this is limited. However, at high data rates this could be optimized by devising a mechanism to prune PEs from the distribution tree that although forming part of the customer multicast have no need to deliver a specific multicast stream to the CE attached to them. To facilitate this optimization, the Rosen draft specifies the use of data MDTs. These data MDTs are signaled after the bandwidth for a specific SG exceeds the configurable threshold.

When a PE detects it is transmitting data for the SG in excess of this threshold, it sends an MDT join TLV (at 60 second intervals) over the default MDT to all PEs. All PEs that require the SG specified in the MDT join TLV join the data MDT that is used by the transmitting PE to send the specific SG. PEs that do not require the SG do not join the data MDT, therefore pruning the multicast distribution tree to just the PEs requiring the SG. After providing sufficient time for all PEs to join the data MDT, the transmitting PE switches the specific multicast stream to the data MDT.

PEs that do not require the SG to be delivered, keep state to allow them to join the data MDT as required.

When the bandwidth requirement no longer exceeds the threshold, the PE stops announcing the MDT join TLV. At this point the PEs using the data MDT leave this group and transmission resumes over the default MDT.

Sampling to check if an s,g has exceeded the threshold occurs every ten seconds. If the rate has exceeded the configured rate in that sample period then the data MDT is created. If during that period the transmission rate has not exceeded the configured threshold then the data MDT is not created. If the data MDT is active and the transmission rate in the last sample period has not exceeded the configured rate then the data MDT is torn down and the multicast stream resumes transmission over the default MDT.

Multicast protocols supported in the provider network

When MVPN auto-discovery is disabled, PIM-SM can be used for I-PMSI, and PIM-SSM or PIM-SM (Draft-Rosen Data MDT) can be used for S-PMSI; When MVPN S-PMSI auto-discovery is enabled, both PIM-SM and PIM SSM can be used for I-PMSI, and PIM-SSM can be used for S-PMSI. In the customer network, both PIM-SM and PIM-SSM are supported.

An MVPN is defined by two sets of sites: sender sites set and receiver sites set, with the following properties:

  • Hosts within the sender sites set could originate multicast traffic for receivers in the receiver sites set.

  • Receivers not in the receiver sites set should not be able to receive this traffic.

  • Hosts within the receiver sites set could receive multicast traffic originated by any host in the sender sites set.

  • Hosts within the receiver sites set should not be able to receive multicast traffic originated by any host that is not in the sender sites set.

A site could be both in the sender sites set and receiver sites set, which implies that hosts within such a site could both originate and receive multicast traffic. An extreme case is when the sender sites set is the same as the receiver sites set, in which case all sites could originate and receive multicast traffic from each other.

Sites within a specific MVPN may be either within the same, or in different organizations, which implies that an MVPN can be either an intranet or an extranet. A site may be in more than one MVPN, which implies that MVPNs may overlap. Not all sites of a specific MVPN have to be connected to the same service provider, which implies that an MVPN can span multiple service providers.

Another way to look at MVPN is to say that an MVPN is defined by a set of administrative policies. Such policies determine both sender sites set and receiver site set. Such policies are established by MVPN customers, but implemented by MVPN service providers using the existing BGP/MPLS VPN mechanisms, such as route targets, with extensions, as necessary.

MVPN membership auto-discovery using BGP

BGP-based auto-discovery is performed by a multicast VPN address family. Any PE that attaches to an MVPN must issue a BGP update message containing an NLRI in this address family, along with a specific set of attributes.

The PE router uses route targets to specify MVPN route import and export. The route target may be the same as the one used for the corresponding unicast VPN, or it may be different. The PE router can specify separate import route targets for sender sites and receiver sites for a specific MVPN.

The route distinguisher (RD) that is used for the corresponding unicast VPN can also be used for the MVPN.

When BGP auto-discovery is enabled, PIM peering on the I-PMSI is disabled, so no PIM hellos are sent on the I-PMSI. C-trees to P-tunnels bindings are also discovered using BGP S-PMSI AD routes, instead of PIM join TLVs. Configure PIM join TLVs when c-mcast-signaling is set to pim in the config>service>vprn>mvpn>provider-tunnel>selective>auto-discovery-disable context.

Supported configuration combinations and Supported configuration combinations describe the supported configuration combinations. If the CLI combination is not allowed, the system returns an error message. If the CLI command is marked as ‟ignored” in the table, the configuration is not blocked, but its value is ignored by the software.

Table 5. Supported configuration combinations
Auto-discovery Inclusive PIM SSM Action

Yes

Yes

Allowed

MDT-SAFI

Yes

Allowed

No

Yes

Not Allowed

Yes or No

No

Allowed

MDT-SAFI

No

Ignored

MDT-SAFI

No (RSVP and MLDP)

Not Allowed

Table 6. Supported configuration combinations
Auto-discovery C-mcast-signaling s-PMSI auto-discovery Action

Yes

BGP

Ignored

Allowed

Yes

PIM

Yes

Allowed

Yes

PIM

No

Allowed

No

BGP

Ignored

Not Allowed

No

PIM

Ignored

Allowed

MDT-SAFI

Ignored (PIM behavior)

Ignored (‟No” behavior)

Allowed

For example, if auto-discovery is disabled, the c-mcast-signaling bgp command fails with an error message stating:

C-multicast signaling in BGP requires auto-discovery to be enabled

If c-mcast-signaling is set to bgp then no auto-discovery fails with an error message stating

C-multicast signaling in BGP requires auto-discovery to be enabled

When c-mcast-signaling is set to bgp, S-PMSI A-D is always enabled (its configuration is ignored);

When auto-discovery is disabled, S-PMSI A-D is always disabled (its configuration is ignored).

When auto-discovery is enabled and c-multicast-signaling is set to pim, the S-PMSI A-D configuration value is used.

mdt-safi uses pim c-mcast-signaling and s-pmsi-signaling regardless of what is configured. A c-mcast-signaling or s-pmsi-signaling configuration is ignored, but both pim and bgp values are allowed.

mdt-safi is only applicable to PIM-SSM I-PMSI. PIM-SM (ASM) I-PMSI is configurable but is ignored. RSVP and MLDP I-PMSI are not allowed.

MVPN implementation based on RFC 6037, Cisco Systems’ Solution for Multicast in MPLS/BGP IP VPNs can support membership auto-discovery using BGP MDT-SAFI. A CLI option is provided per MVPN instance to enable auto-discovery either using BGP MDT-SAFI or NG-MVPN. Only PIM-MDT is supported with BGP MDT-SAFI method.

PE-PE transmission of C-multicast routing using BGP

MVPN c-multicast routing information is exchanged between PEs by using c-multicast routes that are carried using MCAST-VPN NLRI.

VRF route import extended community

VRF route import is an IP address-specific extended community, of an extended type, and is transitive across AS boundaries (RFC 4360, BGP Extended Communities Attribute).

To support MVPN, in addition to the import/export route target extended communities used by the unicast routing, each VRF on a PE must have an import route target extended community that controls imports of C-multicast routes into a particular VRF.

The c-multicast import RT uniquely identifies a VRF, and is constructed as follows:

  • The Global Administrator field of the c-multicast import RT must be set to an IP address of the PE. This address should be common for all the VRFs on the PE (this address may be the PE’s loopback address).

  • The Local Administrator field of the c-multicast import RT associated with a specific VRF contains a 2 octets long number that uniquely identifies that VRF within the PE that contains the VRF.

A PE that has sites of a specific MVPN connected to it communicates the value of the c-multicast import RT associated with the VRF of that MVPN on the PE to all other PEs that have sites of that MVPN. To accomplish this, a PE that originates a (unicast) route to VPN-IP addresses includes in the BGP updates message that carries this route the VRF route import extended community that has the value of the c-multicast import RT of the VRF associated with the route, except if it is known a priori that none of these addresses act as multicast sources or RP, or both, in which case the (unicast) route need not carry the VRF Route Import extended community.

All c-multicast routes with the c-multicast import RT specific to the VRF must be accepted. In this release, vrf-import and vrf-target policies do not apply to C-multicast routes.

The decision flow path is shown below.

 if (route-type == c-mcast-route)

  if (route_target_list includes C-multicast_Import_RT){

   else

    drop;

  else

  Run vrf_import or vrf-target, or both;

Provider tunnel support

Point-to-Multipoint Inclusive (I-PMSI) and Selective (S-PMSI) Provider Multicast Service Interface

BGP C-multicast signaling must be enabled for an MVPN instance to use P2MP RSVP-TE or LDP as I-PMSI (equivalent to ‛Default MDT’, as defined in draft Rosen MVPN) and S-PMSI (equivalent to ‛Data MDT’, as defined in draft Rosen MVPN).

By default, all PE nodes participating in an MVPN receive data traffic over I-PMSI. Optionally, (C-*, C-*) wildcard S-PMSI can be used instead of I-PMSI. See section Wildcard (C-*, C-*) P2MP LSP S-PMSI for more information. For efficient data traffic distribution, one or more S-PMSIs can be used, in addition to the default PMSI, to send traffic to PE nodes that have at least one active receiver connected to them. For more information, see P2MP LSP S-PMSI.

Only one unique multicast flow is supported over each P2MP RSVP-TE or P2MP LDP LSP S-PMSI. Number of S-PMSI that can be initiated per MVPN instance is restricted by CLI command maximum-p2mp-spmsi. P2MP LSP S-PMSI cannot be used for more than one (S,G) stream (that is, multiple multicast flow) as number of S-PMSI per MVPN limit is reached. Multicast flows that cannot switch to S-PMSI remain on I-PMSI.

P2MP RSVP-TE I-PMSI and S-PMSI

Point-to-Multipoint RSVP-TE LSP as inclusive or selective provider tunnel is available with BGP NG-MVPN only. P2MP RSVP-TE LSP is dynamically setup from root node on auto discovery of leaf PE nodes that are participating in multicast VPN. Each RSVP-TE I-PMSI or S-PMSI LSP can be used with a single MVPN instance only.

RSVP-TE LSP template must be defined (see 7450 ESS, 7750 SR, 7950 XRS, and VSR MPLS Guide) and bound to MVPN as inclusive or selective (S-PMSI is for efficient data distribution and is optional) provider tunnel to dynamically initiate P2MP LSP to the leaf PE nodes learned via NG-MVPN auto-discovery signaling. Each P2MP LSP S2L is signaled based on parameters defined in LSP template.

P2MP LDP I-PMSI and S-PMSI

Point-to-Multipoint LDP LSP as inclusive or selective provider tunnel is available with BGP NG-MVPN only. P2MP LDP LSP is dynamically setup from leaf nodes on auto discovery of leaf node PE nodes that are participating in multicast VPN. Each LDP I-PMSI or S-PMSI LSP can be used with a single MVPN instance only.

The multicast-traffic CLI command must be configured per LDP interface to enable P2MP LDP setup. P2MP LDP must also be configured as inclusive or selective (S-PMSI is for efficient data distribution and is optional) provider tunnel per MVPN to dynamically initiate P2MP LSP to leaf PE nodes learned via NG-MVPN auto-discovery signaling.

Wildcard (C-*, C-*) P2MP LSP S-PMSI

Wildcard S-PMSI allows usage of selective tunnel as a default tunnel for a specific MVPN. By using wildcard S-PMSI, operators can avoid full mesh of LSPs between MVPN PEs, reducing related signaling, state, and BW consumption for multicast distribution (no traffic is sent to PEs without any receivers active on the default PMSI).

The SR OS allows an operator to configure wildcard S-PMSI for ng-MVPN (config>service>vprn>mvpn>pt>inclusive>wildcard-spmsi), using LDP and RSVP-TE in P-instance. Support includes:

  • IPv4 and IPv6

  • PIM ASM and SSM

  • directly attached receivers

The SR OS (C-*, C-*) wildcard implementation uses wildcard S-PMSI instead of I-PMSI for a specific MVPN. To switch MVPN from I-PMSI to (C-*, C-*) S-PMSI a VPRN shutdown is required. ISSU and Upstream Multicast Hop (UMH) redundancy can be used to minimize the impact.

To minimize outage, the following upgrade order is recommended:

  1. Route Reflector

  2. Receiver PEs

  3. backup UMH

  4. active UMH

RSVP-TE/mLDP configuration under inclusive provider tunnel (config>service>vprn>mvpn>pt>inclusive) apply to wildcard S-PMSI when enabled.

Wildcard C-S and C-G values are encoded as defined in RFC6625: using zero for Multicast Source Length and Multicast Group Length and omitting Multicast Source and Multicast Group values respectively in MCAST_VPN_NLRI. For example, a (C-*, C-*) is advertised as: RD, 0x00, 0x00, and originating router's IP address.

Note: All SR OSs with BGP peering session to the PE with RFC6625 support enabled must be upgraded to SR OS Release 13.0 before the feature is enabled. Failure to do so results in the following processing on a router with BGP peering session to an RFC6625-enabled PE:
  • BGP peer running Release 12.0 version R4 or newer accepts 0-length address and it keeps encoding length 4 with all zeros for the address

  • BGP peer running Release 12 version R3 or older does not accept 0-length address and keeps restarting BGP session

The procedures implemented by SR OS are compliant to section 3 and 4 of RFC, 6625. Wildcards encoded as described above are carried in NLRI field of MP_REACH_NLRF_ATTRIBUTE. Both IPv4 and IPv6 are supported: (AFI) of 1 or 2 and a Subsequent AFI (SAFI) of MCAST-VPN.

The (C-*, C-*) S-PMSI is established as follows:

  • UMH PEs advertise I-PMSI A-D routes without tunnel information present (empty PTA) - encoded as per RFC6513/6514 before advertising wildcard S-PMSI. I-PMSI needs to be signaled and installed on receiver PEs, because (C-*, C-*) S-PMSI is only installed when a first receiver is added. However, no LSP is established for I-PMSI).

  • UMH PEs advertise S-PMSI A-D route whose NLRI contains (C-*, C-*) with tunnel information encoded as per RFC 6625.

  • Receiver PEs join wildcard S-PMSI if there are any receivers present.

Note: If UMH PE does not encode I-PMSI/S-PMSI A-D routes as per the above, or advertises both I-PMSI and wildcard S-PMSI with the tunnel information present, no interoperability can be achieved.

To ensure correct operation of BSR between PEs with (C-*, C-*) S-PMSI signaling, SR OS implements two modes of operations for BSR.

By default (bsr unicast):

  • BSR PDUs are sent/forwarded as unicast PDUs to neighbor PEs when I-PMSI with Pseudo-tunnel interface is installed.

  • At every BSR interval timer BSR Unicast PDU are sent to all I-PMSI interfaces when this is an elected BSR.

  • BSMs received as multicast from C-instance interfaces are flooded as unicast in the P-instance.

  • All PEs process BSR PDU's received on I-PMSI Pseudo-tunnel interface as unicast packets.

  • BSR PDU's are not forwarded to PE's management control interface.

  • BSR unicast PDU's use PE's System IP address as destination IP and sender PE's System address as Source IP.

  • The BSR unicast functionality ensures that no special state needs to be created for BSR when (C-*, C-*) S-PMSI is enabled, which is beneficiary considering low volume of BSR traffic.

Note:
  • For bsr unicast, the base IPv4 system address (IPv4) or the mapped version of the base IPv4 system address (IPv6) must be configured under the VPRN to ensure bsr unicast messages can reach the VPRN.

  • For bsr spmsi, the base IPv4/IPv6 system address must be configured under the VPRN to ensure B-SR S-PMSI's are established.

BSR S-PMSI mode can be enabled to allow interoperability with other vendors. In that mode full mesh S-PMSI is required and created between all PEs in MVPN to exchange BSR PDUs between all PEs in MVPN. To operate as expected, the BSR S-PMSI mode requires a selective P-tunnel configuration. For IPv6 support (including dual-stack) of BSR S-PMSI mode, the IPv6 default system interface address must be configured as a loopback interface address under the VPRN and VPRN PIM contexts. Changing BSR signaling requires a VPRN shutdown.

Other key feature interactions and restrictions for (C-*, C-*) include the following:

  • Extranet is fully supported with wildcard S-PMSI trees.

  • (C-S, C-G) S-PMSIs are supported when (C-*, C-*) S-PMSI is configured (including both BW and receiver PE driven thresholds).

  • Geo-redundancy is supported (deploying with geo-redundancy eliminates traffic duplication when geo-redundant source has no active receivers at a cost of slightly increased outage upon a switch because wildcard S-PMSI may need to be re-establish).

  • PIM in P-instance is not supported.

  • SR OS implementation requires wildcard encoding as per RFC6625 and I-PMSI/S-PMSI signaling as defined above (I-PMSI signaled with empty PTA then S-PMSI signaled with P-tunnel PTA) for interoperability. Implementations that do not adhere to RFC6625 encoding, or signal both I-PMSI and S-PMSI with P-tunnel PTA do not inter-operate with SR OS implementation).

P2MP LSP S-PMSI

NG-MVPN support P2MP RSVP-TE and P2MP LDP LSPs as selective provider multicast service interface (S-PMSI). S-PMSI is used to avoid sending traffic to PEs that participate in multicast VPN, but do not have any receivers for a specific C-multicast flow. This allows more-BW efficient distribution of multicast traffic over the provider network, especially for high bandwidth multicast flows. S-PMSI is spawned dynamically based on configured triggers as described in S-PMSI trigger thresholds section.

In MVPN, the head-end PE firstly discovers all the leaf PEs via I-PMSI A-D routes. It then signals the P2MP LSP to all the leaf PEs using RSVP-TE. In the scenario of S-PMSI:

  1. The head-end PE sends an S-PMSI A-D route for a specific C-flow with the Leaf Information Required bit set.

  2. The PEs who are interested in the C-flow respond with Leaf A-D routes.

  3. The head-end PE then signals the P2MP LSP to all the leaf PEs using RSVP-TE.

Also, because the receivers may come and go, the implementation supports dynamically adding and pruning leaf nodes to and from the P2MP LSP.

When the tunnel type in the PMSI attribute is set to RSVP-TE P2MP LSP, the tunnel identifier is <Extended Tunnel ID, Reserved, Tunnel ID, P2MP ID>, as carried in the RSVP-TE P2MP LSP SESSION Object.

The PE can also learn via an A-D route that it needs to receive traffic on a particular RSVP-TE P2MP LSP before the LSP is actually setup. In this case, the PE needs to wait until the LSP is operational before it can modify its forwarding tables as directed by the A-D route.

Because of the way that LDP normally works, mLDP P2MP LSPs are setup without solicitation from the leaf PEs toward the head-end PE. The leaf PE discovers the head-end PE via I-PMSI or S-PMSI A-D routes. The tunnel identifier carried in the PMSI attribute is used as the P2MP FEC element. The tunnel identifier consists of the head-end PE’s address, along with a Generic LSP identifier value. The Generic LSP identifier value is automatically generated by the head-end PE.

Dynamic multicast signaling over P2MP LDP in VRF

This feature provides a multicast signaling solution for IP-VPNs, allowing the connection of IP multicast sources and receivers in C-instances, which are running PIM multicast protocol using Rosen MVPN with BGP SAFI and P2MP mLDP in P-instance. The solution dynamically maps each PIM multicast flow to a P2MP LDP LSP on the source and receiver PEs.

The feature uses procedures defined in RFC 7246: Multipoint Label Distribution Protocol In-Band Signaling in Virtual Routing and Forwarding (VRF) Table Context. On the receiver PE, PIM signaling is dynamically mapped to the P2MP LDP tree setup. On the source PE, signaling is handed back from the P2MP mLDP to the PIM. Because of dynamic mapping of multicast IP flow to P2MP LSP, provisioning and maintenance overhead is eliminated as multicast distribution services are added and removed from the VRF. Per (C-S, C-G) IP multicast state is also removed from the network, because P2MP LSPs are used to transport multicast flows.

Dynamic mLDP signaling for IP multicast in VPRN illustrates dynamic mLDP signaling for IP multicast in VPRN.

Figure 20. Dynamic mLDP signaling for IP multicast in VPRN

As illustrated in Dynamic mLDP signaling for IP multicast in VPRN, P2MP LDP LSP signaling is initiated from the receiver PE that receives PIM JOIN from a downstream router (Router A). To enable dynamic multicast signaling, the p2mp-ldp-tree-join must be configured on PIM customer-facing interfaces for the specific VPRN of Router A. This enables handover of multicast tree signaling from the PIM to the P2MP LDP LSP. Being a leaf node of the P2MP LDP LSP, Router A selects the upstream-hop as the root node of P2MP LDP FEC, based on a routing table lookup. If an ECMP path is available for a specific route, then the number of trees are equally balanced toward multiple root nodes. The PIM joins are carried in the Transit Source PE (Router B), and multicast tree signaling is handed back to the PIM and propagated upstream as native-IP PIM JOIN toward C-instance multicast source.

The feature is supported with IPv4 and IPv6 PIM SSM and IPv4 mLDP. Directly connected IGMP/MLD receivers are also supported, with PIM enabled on outgoing interfaces and SSM mapping configured, if required.

The following are feature restrictions:

  • Dynamic mLDP signaling in a VPRN instance and Rosen or NG-MVPN are mutually exclusive.

  • A single instance of P2MP LDP LSP is supported between the receiver PE and Source PE per multicast flow; there is no stitching of dynamic trees.

  • Extranet functionality is not supported.

  • The router LSA link ID or the advertising router ID must be a routable IPv4 address (including IPv6 into IPv4 mLDP use cases).

  • IPv6 PIM with dynamic IPv4 mLDP signaling is not supported with EBGP or IBGP with IPv6 next-hop.

  • Inter-AS and IGP inter-area scenarios where the originating router is altered at the ASBR and ABR respectively, (therefore PIM has no way to create the LDP LSP toward the source), are not supported.

  • When dynamic mLDP signaling is deployed, a change in Route Distinguisher (RD) on the Source PE is not acted upon for any (C-S, C-G)s until the receiver PEs learn about the new RD (via BGP) and send explicit delete and create with the new RD.

  • Procedures of Section 2 of RFC 7246 for a case where UMH and the upstream PE do not have the same IP address are not supported.

MVPN sender-only/receiver-only

In multicast MVPN, by default, if multiple PE nodes form a peering with a common MVPN instance then each PE node originates a multicast tree locally toward the remaining PE nodes that are member of this MVPN instance. This behavior creates a mesh of I-PMSI across all PE nodes in the MVPN. It is often a case, that a specific VPN has many sites that host multicast receivers, but only few sites that either host both receivers and sources or sources only.

MVPN Sender-only/Receiver-only allows optimization of control and data plane resources by preventing unnecessary I-PMSI mesh when a specific PE hosts multicast sources only or multicast receivers only for a specific MVPN.

For PE nodes that host only multicast sources for a specific VPN, operators can now block those PEs, through configuration, from joining I-PMSIs from other PEs in this MVPN. For PE nodes that host only multicast receivers for a specific VPN, operators can now block those PEs, through configuration, to set-up a local I-PMSI to other PEs in this MVPN.

MVPN Sender-only/Receiver-only is supported with ng-MVPN using IPv4 RSVP-TE or IPv4 LDP provider tunnels for both IPv4 and IPv6 customer multicast. MVPN sender-only/receiver-only example depicts 4-site MVPN with sender-only, receiver-only and sender-receiver (default) sites.

Figure 21. MVPN sender-only/receiver-only example

Extra attention needs to be paid to BSR/RP placement when Sender-only/Receiver-only is enabled. Source DR sends unicast encapsulated traffic toward RP, therefore, RP shall be at sender-receiver or sender-only site, so that *G traffic can be sent over the tunnel. BSR shall be deployed at the sender-receiver site. BSR can be at sender-only site if the RPs are at the same site. BSR needs to receive packets from other candidate-BSR and candidate-RPs and also needs to send BSM packets to everyone.

S-PMSI trigger thresholds

The mLDP and RSVP-TE S-PMSIs support two types of data thresholds: bandwidth-driven and receiver-PE-driven. The threshold evaluation and bandwidth driven threshold functionality are described in Use of data MDTs.

In addition to the bandwidth threshold functionality, an operator can enable receiver-PE-driven threshold behavior. Receiver PE thresholds ensure that S-PMSI is only created when BW savings in P-instance justify extra signaling required to establish a new S-PMSI. For example, the number of receiver PEs interested in a specific C-multicast flow is meaningfully smaller than the number of receiver PEs for default PMSI (I-PMSI or wildcard S-PMSI). To ensure that S-PMSI is not constantly created/deleted, two thresholds need to be specified: receiver PE add threshold and receiver PE delete threshold (expected to be significantly higher).

When a (C-S, C-G) crosses a data threshold to create S-PMSI, instead of regular S-PMSI signaling, sender PE originates S-PMSI explicit tracking procedures to detect how many receiver PEs are interested in a specific (C-S, C-G). When receiver PEs receive an explicit tracking request, each receiver PE responds, indicating whether there are multicast receivers present for that (C-S, C-G) on the specific PE (PE is interested in a specific (C-S, C-G)). If the geo-redundancy feature is enabled, receiver PEs do not respond to explicit tracking requests for suppressed sources and therefore only Receiver PEs with an active join are counted against the configured thresholds on Source PEs.

Upon regular sampling and check interval, if the previous check interval had a non-zero receiver PE count (one interval delay to not trigger S-PMSI prematurely) and current count of receiver PEs interested in the specific (C-S, C-G) is non-zero and is less than the configured receiver PE add threshold, Source PE sets up S-PMSI for this (C-S, C-G) following standard ng-MVPN procedures augmented with explicit tracking for S-PMSI being established.

Data threshold timer should be set to ensure enough time is given for explicit tracking to complete (for example, setting the timer to value that is too low may create S-PMSI prematurely).

Upon regular data-delay-interval expiry processing, when BW threshold validity is being checked, a current receiver PE count is also checked (for example, explicit tracking continues on the established S-PMSI). If BW threshold no longer applies or the receiver PEs exceed receiver PE delete threshold, the S-PMSI is torn down and (C-S, C-G) joins back the default PMSI.

Changing of thresholds (including enabling disabling the thresholds) is allowed in service. The configuration change is evaluated at the next periodic threshold evaluation.

The explicit tracking procedures follow RFC 6513/6514 with clarification and wildcard S-PMSI explicit tracking extensions as described in IETF Draft: draft-dolganow-l3vpn-expl-track-00.

Migration from existing Rosen implementation

The existing Rosen implementation is compatible to provide an easy migration path.

The following migration procedures are supported:

  • Upgrade all the PE nodes that need to support MVPN to the newer release.

  • The old configuration is converted automatically to the new style.

  • Node by node, MCAST-VPN address-family for BGP is enabled. Enable auto-discovery using BGP.

  • Change PE-to-PE signaling to BGP.

Policy-based S-PMSI

SR OS creates a single Selective P-Multicast Service Interface (S-PMSI) per multicast stream: (S,G) or (*,G). To better manage bandwidth allocation in the network, multiple multicast streams are often bundled starting from the same root node into a single, multi-stream S-PMSI. Network bandwidth is usually managed per package or group of packages, instead of per channel.

Multi-stream S-PMSI supports a single S-PMSI for one or more IPv4 (C-S, C-G) or IPv6 (C-S, C-G) streams. Multiple multicast streams starting from the same VPRN going to the same set of leafs can use a single S-PMSI. Multi-stream S-PMSIs can:

  • carry exclusively IPv4 or exclusively IPv6, or a mix of channels

  • coexist with a single group S-PMSI

To create a multi-stream S-PMSI, an S-PMSI policy needs to be configured in the VPN context on the source node. This policy maps multiple (C-S, C-G) streams to a single S-PMSI. Because this configuration is done per MVPN, multiple VPNs can have identical policies, each configured for its own VPN context.

When mapping a multicast stream to a multi-stream S-PMSI policy, the data traverses the S-PMSI without first using the I-PMSI. (Before this feature, when a multicast stream was sourced, the data used the I-PMSI first until a configured threshold was met. After this, if the multicast data exceeded the threshold, it would signal the S-PMSI tunnel and switch from I-PMSI to S-PMSI.)

For multi-stream S-PMSI, if the policy is configured and the multicast data matches the policy rules, the multi-stream S-PMSI is used from the start without using the default I-PMSI.

Multiple multi-stream S-PMSI policies could be assigned to a specific S-PMSI configuration. In this case, the policy acts as a link list. The first (lowest index) that matches the multi-stream S-PMSI policy is used for that specific stream.

The rules for matching a multi-stream S-PMSI on the source node are listed here.

S-PMSI to (C-S, C-G) mapping on Source-PE, in sequence:

  1. The multi-stream S-PMSI policy is evaluated, starting from the lowest numerical policy index. This allows the feature to be enabled in the service when per-(C-S, C-G) stream configuration is present. Only entries that are not shut down are evaluated. First, the multi-stream S-PMSI (the lowest policy index) that the (C-S, C-G) stream maps to is selected.

  2. If (C-S, C-G) does not map to any of multi-stream S-PMSIs, per-(C-S, C-G) S-PMSIs are used for transmission if a (C-S, C-G) maps to an existing S-PMSI (based on data-thresholds).

  3. If S-PMSI cannot be used, the default PMSI is used.

To address multi-stream S-PMSI P-tunnel failure, if an S-PMSI P-tunnel is not available, a default PMSI tunnel is used. When an S-PMSI tunnel fails, all (C-S, C-G) streams using this multi-stream S-PMSI move to the default PMSI. The groups move back to S-PMSI after the S-PMSI tunnel is restored.

Supported MPLS tunnels

Multi-stream S-PMSI is configured in the context of an auto-discovery default (that is, NG-MVPN). It supports all existing per-mLDP/RSVP-TE P2MP S-PMSI tunnel functionality for multi-stream S-PMSI LSP templates (RSVP-TE P-instance).

Note:
  • Per-multicast group statistics are not available for multi-stream S-PMSIs on S-PMSI level.

  • GRE tunnels are not supported for multi-stream S-PMSI.

Supported multicast features

S-PMSI is supported with PIM ASM and PIM SSM in C-instances.

Note:
  • The multi-stream S-PMSI model uses BSR RP co-located with the source PE or an RP between the source PE and multicast source, that is, upstream of receivers. Both bsr unicast and bsr spmsi can be deployed as applicable.

  • The model also supports other RP types.

In-service changes to multi-stream S-PMSI

The operator can change the mapping in service; that is, the operator can move active streams (C-S, C-G) from one S-PMSI to another using the configuration, or from the default PMSI to the S-PMSI, without having to stop data transmission or having to disable a PMSI.

The change is performed by moving a (C-S, C-G) stream from a per-group S-PMSI to a multi-stream S-PMSI and the other way around, and moving a (C-S, C-G) stream from one multi-stream S-PMSI to another multi-stream S-PMSI.

Note:
  • During re-mapping, a changed (C-S, C-G) stream is first moved to the default PMSI before it is moved to a new S-PMSI, regardless of the type of move. Unchanged (C-S, C-G) streams must remain on an existing PMSIs.

  • Any change to a multi-stream S-PMSI policy or to a preferred multi-stream S-PMSI policy (for example, an index change equivalent to less than or equal to the current policy) should be performed during a maintenance window. Failure to perform these types of changes in a maintenance window could potentially cause a traffic outage.

Configuration example

In this example, two policies are created on the source node: multi-stream S-PMSI 1 and multi-stream-S-PMSI 10.

A multicast stream with group 224.0.0.x and source 192.0.2.0/24 maps to the first multi-stream policy. The group in the range of 224.0.0.0/24 and source 192.0.2.1/24 maps to policy 10.

*A:SwSim14>config>service>vprn# info 
mvpn
                auto-discovery default
                c-mcast-signaling bgp
                provider-tunnel
                    inclusive
                        mldp
                            no shutdown
                        exit
                    exit
                    selective
                        mldp
                            no shutdown
                        exit          
                        no auto-discovery-disable
                        data-threshold 239.70.1.0/24 1
                        data-threshold 239.0.0.0/8 1
                        multistream-spmsi 1 create
                            group 224.0.0.0/24
                                source 192.0.2.0/24
                            exit
                        exit
                        multistream-spmsi 10 create
                            group 224.0.0.0/24
                                source 192.0.2.1/24
                            exit
                        exit
                    exit
                exit

Policy-based data MDT

A single data MDT can transport one or more IPv4 (C-S, C-G) streams. This allows multiple multicast streams starting from the same VPRN going to the same set of leafs to use a single data MDT. Characteristics of an MDT include:

  • a multi-stream data MDT can carry IPv4 only

  • a multi-stream data MDT can coexist with a single-group data MDT

  • a default MDT must be configured

To create a multi-stream MDT data, an MDA data policy must be configured in the context of MVPN on the source node. This policy maps multiple (C-S, C-G) streams to a single data MDT. Because this configuration is per MVPN, multiple VPNs can have identical policies configured, each for its own VPN context.

When a multicast stream is mapped to a multi-stream data MDT policy, the data traverses the default MDT first. The data delay timer is used to switch the data from the default MDT to the multi-stream data MDT.

When the multi-stream data MDT is deleted, the traffic switches back to the default MDT.

In some cases when a new multi-stream data MDT is configured which is better suited, some streams may prefer this new multi-stream data MDT. To switch, the traffic switches to the default MDT and then to the new multi-stream data MDT.

MDT data can be configured as SSM or ASM.

There can be multiple multi-stream policies assigned to a single data MDT configuration. In this case, the policy acts as a link list, the first (lowest index) matched multi-stream policy is used for that specific stream. The following are the rules of matching a multi-stream data MDT to (C-S, C-G) mapping on a source PE (in order):

  1. The multi-stream policy is evaluated to enable the feature in service when per-(C-S, C-G) configuration is present, starting from the lowest numerical policy index (only entries that are not shutdown are evaluated). The first multi-stream data MDT (the lowest policy index) the (C-S, C-G) maps to is selected.

  2. If (C-S, C-G) does not map to any of the multi-stream data MDTs, per-(C-S, C-G) single data MDTs are used if a (C-S, C-G) maps to an existing MDT based on data-thresholds.

  3. The default MDT is used if no policy matches to a data MDT.

  4. When a (C-S, C-G) arrives, it start on the default MDT but can switch to a data MDT when the data delay interval expires. It does not check the data-threshold before switching.

  5. When going from one multi-stream data MDT to a more suitable one, the traffic first switches to the default MDT and then switch to the new multi-stream data MDT based on the data-delay-interval.

When a data MDT tunnel fails, all (C-S, C-G)s using this multi-stream data MDT move to the default MDT, and the groups move back to the data MDT when it is restored.

MVPN (NG-MVPN) upstream multicast hop fast failover

MVPN upstream PE or P node fast failover detection method is supported with RSVP P2MP I-PMSI only. A receiver PE achieves fast upstream failover based on the capability to subscribe multicast flow from multiple UMH nodes and the capability to monitor the health of the upstream PE and intermediate P nodes using an unidirectional multi-point BFD session running over the provider tunnel.

A receiver PE subscribes multicast flow from multiple upstream PE nodes to have active redundant multicast flow available during failure of primary flow. Active redundant multicast flow from standby upstream PE allows instant switchover of multicast flow during failure of primary multicast flow.

Faster detection of multicast flow failure is achieved by keeping track of unidirectional multi-point BFD sessions enabled on the provider tunnel. Multi-point BFD sessions must be configured with 10 ms transmit interval on sender (root) PE to achieve sub-50ms fast failover on receiver (leaf) PE.

UMH tunnel-status selection option must be enabled on the receiver PE for upstream fast failover. Primary and standby upstream PE pairs must be configured on the receiver PE to enable active redundant multicast flow to be received from the standby upstream PE.

Multicast VPN extranet

Multicast VPN extranet distribution allows multicast traffic to flow across different routing instances. A routing instance that received a PIM/IGMP JOIN but cannot reach source of multicast source directly within its own instance is selected as receiver routing instance (receiver C-instance). A routing instance that has source of multicast stream and accepts PIM/IGMP JOIN from other routing instances is selected as source routing instance (source C-instance). A routing instance that does not have either source or receivers but is used in the core is selected as a transit instance (transit P-instance). The following subsections detail supported functionality.

Multicast extranet for Rosen MVPN for PIM SSM

Multicast extranet is supported for Rosen MVPN with MDT SAFI. Extranet is supported for IPv4 multicast stream for default and data MDTs (PIM and IGMP).

The following extranet cases are supported:

  • local replication into a receiver VRF from a source VRF on a source PE

  • transit replication from a source VRF onto a tunnel of a transit core VRF on a source PE. A source VRF can replicate its streams into multiple core VRFs as long as any specific stream from source VRF uses a single core VRF (the first tunnel in any core VRF on which a join for the stream arrives). Streams with overlapping group addresses (same group address, different source address) are supported in the same core VRF.

  • remote replication from source or transit VRF into one or more receiver VRFs on receiver PEs

  • multiple replications from multiple source or transit VRFs into a receiver VRF on receiver PEs

Rosen MVPN extranet requires routing information exchange between the source VRF and the receiver VRF based on route export or import policies:

  • Routing information for multicast sources must be exported using an RT export policy from the source VRF instance.

  • Routing information must be imported into the receiver or transit VRF instance using an RT import policy.

The following are restrictions:

  • The source VRF instance and receiver VRF instance of extranet must exist on a common PE node (to allow local extranet mapping).

  • SSM translation is required for IGMP (C-*, C-G).

  • An I-PMSI route cannot be imported into multiple VPRNs, and NG-MVPN routes do not need to be imported into multiple VPRNs.

In Multicast VPN traffic flow, VPRN-1 is the source VPRN instance and VPRN-2 and VPRN-3 are receiver VPRN instances. The PIM/IGMP JOIN received on VPRN-2 or VPRN-3 is for (S1, G1) multicast flow. Source S1 belongs to VPRN-1. Because of the route export policy in VPRN-1 and the import policy in VPRN-2 and VPRN-3, the receiver host in VPRN-2 or VPRN-3 can subscribe to the stream (S1, G1).

Figure 22. Multicast VPN traffic flow

Multicast extranet for NG-MVPN for PIM SSM

Multicast extranet is supported for ng-MVPN with IPv4 RSVP-TE and mLDP I-PMSIs and S-PMSIs including (C-*, C-*) S-PMSI support where applicable. Extranet is supported for IPv4 C-multicast traffic (PIM/IGMP joins).

The following extranet cases are supported:

  • local replication into a receiver C-instance MVPNs on a source PE from a source P-instance MVPN

  • remote replication from P-instance MVPN into one or more receiver C-instance MVPNs on receiver PEs

  • multiple replications from multiple source/transit P-instance MVPNs into a receiver C-instance MVPN on receiver PEs

Note: Transit replication on Source PE is not supported.

Multicast extranet for ng-MVPN, similarly to extranet for Rosen MVPN, requires routing information exchange between source ng-MVPN and receiver ng-MVPN based on route export and import policies. Routing information for multicast sources is exported using an RT export policy from a source ng-MVPN instance and imported into a receiver ng-MVPN instance using an RT import policy. S-PMSI/I-PMSI establishment and C-multicast route exchange occurs in a source ng-MVPN P-instance only (import and export policies are not used for MVPN route exchange). Sender-only functionality must not be enabled for the source/transit ng-MVPN on the receiver PE. It is recommended to enable receiver-only functionality on a receiver ng-MVPN instance.

The following are restrictions:

  • Source P-instance MVPN and receiver C-instance MVPN must reside on the receiver PE (to allow local extranet mapping).

  • SSM translation is required for IGMP (C-*, C-G).

Multicast extranet with per-group mapping for PIM SSM

In some deployments, such as IPTV or wholesale multicast services, it may be desirable to create one or more transit MVPNs to optimize delivery of multicast streams in the provider core. Source PE transit replication and receiver PE per-group SSM extranet mapping represents an example deployment model.

Figure 23. Source PE transit replication and receiver PE per-group SSM extranet mapping

The architecture displayed in Source PE transit replication and receiver PE per-group SSM extranet mapping requires a source routing instance MVPN to place its multicast streams into one or more transit core routing instance MVPNs (each stream mapping to a single transit core instance only). It also requires receivers within each receiver routing instance MVPN to know which transit core routing instance MVPN they need to join for each of the multicast streams. To achieve this functionality, transit replication from a source routing instance MVPN onto a tunnel of a transit core routing instance MVPN on a source PE (see earlier sub-sections for MVPN topologies supporting transit replication on source PEs) and per-group mapping of multicast groups from receiver routing instance MVPNs to transit core routing instance MVPNs (as defined below) are required.

For per-group mapping on a receiver PE, the operator must configure a receiver routing instance MVPN per-group mapping to one or more source/transit core routing instance MVPNs. The mapping allows propagation of PIM joins received in the receiver routing instance MVPN into the core routing MVPN instance defined by the map. All multicast streams sourced from a single multicast source address are always mapped to a single core routing instance MVPN for a specific receiver routing instance MVPN (multiple receiver MVPNs can use different core MVPNs for groups from the same multicast source address). If per-group map in receiver MVPN maps multicast streams sourced from the same multicast source address to multiple core routing instance MVPNs, then the first PIM join processed for those streams selects the core routing instance MVPN to be used for all multicast streams from a specific source address for this receiver MVPN. PIM joins for streams sourced from the source address not carried by the selected core VRF MVPN instance remains unresolved. When a PIM join or prune is received in a receiver routing instance MVPN with per-group mapping configured, if no mapping is defined for the PIM join’s group address, non-extranet processing applies when resolving how to forward the PIM join/prune.

The main attributes for per-group SSM extranet mapping on receiver PE include support for:

  • Rosen MVPN with MDT SAFI. RFC6513/6514 NG-MVPN with IPv4 RSVP-TE/mLDP in P-instance (a P-instance tunnel must be in the same VPRN service as multicast source)

  • IPv4 PIM SSM

  • IGMP (C-S, C-G), and for IGMP (C-*, C-G) using SSM translation

  • a receiver routing instance MVPN to map groups to multiple core routing instance MVPNs

  • in-service changes of the map to a different transit/source core routing instance (this is service affecting)

The following are restrictions:

  • When a receiver routing instance MVPN is on the same PE as a source routing instance MVPN, basic extranet functionality and not per-group (C-S, C-G) mapping must be configured (extranet from receiver routing instance to core routing instance to source routing instance on a single PE is not supported).

  • Local receivers in the core routing instance MVPN are not supported when per-group mapping is deployed.

  • Receiver routing instance MVPN that has per-group mapping enabled cannot have tunnels in its OIF lists.

  • Per-group mapping is blocked if GRT/VRF extranet is configured.

Multicast GRT-source/VRF-receiver extranet with per group mapping for PIM SSM

Multicast GRT-source/VRF-receiver (GRT/VRF) extranet with per-group mapping allows multicast traffic to flow from GRT into VRF MVPN instances. A VRF routing instance that received a PIM/IGMP join but cannot reach the source multicast stream directly within its own instance is selected as receiver routing instance. A GRT instance that has sources of multicast streams and accepts PIM joins from other VRF MVPN instances is selected as source routing instance.

GRT/VRF extranet shows an example deployment.

Figure 24. GRT/VRF extranet

Routing information is exchanged between GRT and VRF receiver MVPN instances of extranet by enabling grt-extranet under a receiver MVPN PIM configuration for all or a subset of multicast groups. When enabled, multicast receivers in a receiver routing instances can subscribe to streams from any multicast source node reachable in GRT source instance.

The main feature attributes are:

  • GRT/VRF extranet can be performed on all streams or on a configured group of prefixes within a receiver routing instance.

  • GRT instance requires Classic Rosen multicast.

  • IPv4 PIM joins are supported in receiver VRF instances.

  • Local receivers using IGMP: (C-S, C-G) and (C-*, C-G) using SSM translation are supported.

  • The feature is blocked if a per-group mapping extranet is configured in receiver VRF.

Multicast extranet with per-group mapping for PIM ASM

Multicast extranet with per-group mapping for PIM ASM allows multicast traffic to flow from a source routing instance to a receiver routing instance when a PIM ASM join is received in the receiver routing instance.

Multicast extranet with per group PIM ASM mapping depicts PIM ASM extranet map support.

Figure 25. Multicast extranet with per group PIM ASM mapping

PIM ASM extranet is achieved by local mapping from the receiver to source routing instances on a receiver PE. The mapping allows propagation of anycast RP PIM register messages between the source and receiver routing instances over an auto-created internal extranet interface. This PIM register propagation allows the receiver routing instance to resolve PIM ASM joins to multicast sources and to propagate PIM SSM joins over an auto-created extranet interface to the source routing instance. PIM SSM joins are then propagated toward the multicast source within the source routing instance.

The following MVPN topologies are supported:

  • Rosen MVPN with MDT SAFI: a local replication on a source PE and multiple-source/multiple-receiver replication on a receiver PE

  • RFC 6513/6514 NG-MVPN (including RFC 6625 (C-*, C-*) wildcard S-PMSI): a local replication on a source PE and a multiple source/multiple receiver replication on a receiver PE

  • Extranet for GRT-source/VRF receiver with a local replication on a source PE and a multiple-receiver replication on a receiver PE

  • Locally attached receivers are supported without SSM mapping.

To achieve the extranet replication, the operator must configure:

  • local PIM ASM mapping on a receiver PE from a receiver routing instance to a source routing instance (config>service>vprn>mvpn>rpf-select>core-mvpn or config>service>vprn>pim>grt-extranet as applicable)

  • an anycast RP mesh between source and receiver PEs in the source routing instance

The following are restrictions:

  • This feature is supported for IPv4 multicast.

  • The multicast source must reside in the source routing instance the ASM map points to on a receiver PE (the deployment of transit replication extranet from source instance to core instance on Source PE with ASM map extranet from receiver instance to core instance on a receiver PE is not supported).

  • A specific multicast group can be mapped in a receiver routing instance using either PIM SSM mapping or PIM ASM mapping but not both.

  • A specific multicast group cannot map to multiple source routing instances.

Non-congruent unicast and multicast topologies for multicast VPN

Operators that prefer to keep unicast and multicast traffic on separate links in a network have the option to maintain two separate instances of the route table (unicast and multicast) per VPRN.

Multicast BGP can be used to advertise separate multicast routes using Multicast NLRI (SAFI 2) on PE-CE link within VPRN instance. Multicast routes maintained per VPRN instance can be propagated between PE-PE using BGP Multicast-VPN NLRI (SAFI 129).

Figure 26. Incongruent multicast and unicast topology for non-overlapping traffic links

SR OS supports option to perform RPF check per VPRN instance using multicast route table, unicast route table or both.

Non-congruent unicast and multicast topology is supported with NG-MVPN. Draft Rosen is not supported.

Automatic discovery of Group-to-RP mappings (auto-RP)

Auto-RP is a proprietary group discovery and mapping mechanism for IPv4 PIM that is described in cisco-ipmulticast/pim-autorp-spec, Auto-RP: Automatic discovery of Group-to-RP mappings for IP multicast. The functionality is similar to the IETF standard bootstrap router (BSR) mechanism that is described in RFC 5059, Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM), to dynamically learn about the availability of Rendezvous Points (RPs) in a network. When a router is configured as an RP-mapping agent with the pim>rp>auto-rp-discovery command, it listens to the CISCO-RP-ANNOUNCE (224.0.1.39) group and caches the announced mappings. The RP-mapping agent then periodically sends out RP-mapping packets to the CISCO-RP-DISCOVERY (224.0.1.40) group. SR OS supports version 1 of the auto-RP specification, so the ability to deny RP-mappings by advertising negative group prefixes is not supported.

PIM dense-mode (PIM-DM) as described in RFC 3973, Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised), is used for the auto-RP groups to support multihoming and redundancy. The RP-mapping agent supports announcing, mapping, and discovery functions; candidate RP functionality is not supported.

Auto-RP is supported for IPv4 in multicast VPNs and in the global routing instance. Either BSR or auto-RP for IPv4 can be configured; the two mechanisms cannot be enabled together. BSR for IPv6 and auto-RP for IPv4 can be enabled together. In a multicast VPN, auto-RP cannot be enabled together with sender-only or receiver-only multicast distribution trees (MDTs), or wildcard S-PMSI configurations that could block flooding.

IPv6 MVPN support

IPv6 multicast support in SR OS allows operators to offer customers IPv6 multicast MVPN service. An operator uses IPv4 mLDP or RSVP-TE core to carry IPv6 c-multicast traffic inside IPv4 mLDP or RSVP-TE provider tunnels (p-tunnels). The IPv6 customer multicast on a specific MVPN can be blocked, enabled on its own or in addition to IPv4 multicast per PE or per interface. When both IPv4 and IPv6 multicast is enabled for a specific MVPN, a single tree is used to carry both IPv6 and IPv4 traffic. IPv6 MVPN example shows an example of an operator with IPv4 MPLS backbone providing IPv6 MVPN service to Customer 1 and Customer 2.

Figure 27. IPv6 MVPN example

SR OS IPv6 MVPN multicast implementation provides the following functionality:

  • IPv6 C-PIM-SM (ASM and SSM)

  • MLDv1 and MLDv2

  • SSM mapping for MLDv1

  • I-PMSI and S-PMSI using IPv4 P2MP mLDP p-tunnels

  • I-PMSI and S-PMSI using IPv4 P2MP RSVP p-tunnels

  • BGP auto-discovery

  • PE-PE transmission of C-multicast routing using BGP mvpn-ipv6 address family

  • IPv6 BSR/RP functions on functional par with IPv4 (auto-RP using IPv4 only)

  • Embedded RP

  • Inter-AS Option A

The following known restrictions exist for IPv6 MVPN support:

  • Non-congruent topologies are not supported.

  • IPv6 is not supported in MCAC.

  • If IPv4 and IPv6 multicast is enabled, per-MVPN multicast limits apply to entire IPv4 and IPv6 multicast traffic as it is carried in a single PMSI. For example IPv4 AND IPv6 S-PMSIs are counted against a single S-PMSI maximum per MVPN.

  • IPv6 Auto-RP is not supported.

Multicast core diversity for Rosen MDT_SAFI MVPNs

Multicast core diversity depicts Rosen MVPN core diversity deployment:

Figure 28. Multicast core diversity

Core diversity allows operator to optionally deploy multicast MVPN in either default IGP instance or one of two non-default IGP instances to provide, for example, topology isolation or different level of services. The following describes main feature attributes:

  • Rosen MVPN IPv4 multicast with MDT SAFI is supported with default and data MDTs.

  • Rosen MVPN can use a non-default OSPF or ISIS instance (using their loopback addresses instead of a system address).

  • Up to 3 distinct core instances are supported: system + 2 non-default OSPF instances – referred as ‟red” and ‟blue” below.

  • The BGP Connector also uses non-default OSPF loopback as NH, allowing Inter-AS Option B/C functionality to work with Core diversity as well.

  • The feature is supported with CSC-VPRN.

On source PEs (PE1: UMH, PE2: UMH in Multicast core diversity), an MVPN is assigned to a non-default IGP core instance as follows:

  1. MVPN is statically pointed to use one of the non-default ‟red”/‟blue” IGP instances loopback addresses as source address instead of system loopback IP.

  2. MVPN export policy is used to change unicast route next-hop VPN address (no longer required as of SR OS Release 12.0.R4 - BGP Connector support for non-default instances).

The above configuration ensures that MDT SAFI and IP-VPN routes for the non-default core instance use non-default IGP loopback instead of system IP. This ensures PIM advertisement/joins run in the correct core instance and GRE tunnels for multicast can be set-up using and terminated on non-system IP.

If BGP export policy is used to change unicast route next-hop VPN address, unicast traffic must be forwarded in non-default ‟red” or ‟blue” core instance LDP or RSVP (terminating on non-system IP) must be used. GRE unicast traffic termination on non-system IP is not supported, and any GRE traffic arriving at the PE in ‟blue”, ‟red” instances destined for non-default IGP loopback IP is forwarded to CPM (ACL or CPM filters can be used to prevent the traffic from reaching the CPM). This limitation does not apply if BGP connector attribute is used to resolve the multicast route.

No configuration is required on non-source PEs.

The following are feature restrictions:

  • VPRN instance must be shutdown to change the mdt-safi source-address. The CLI rollback that includes change of the auto-discovery is therefore service impacting.

  • To reset mdt-safi source-address to system IP, operator must first execute no auto-discovery (or auto-discovery default) then auto-discovery mdt-safi

  • Configuring system IP as a source-address consumes one of the 2 IP addresses allowed, therefore it should not be done.

  • Operators must configure correct IGP instance loopback IP addresses within Rosen MVPN context and must configure correct BGP policies (Before Release 12.0.R4) for the feature to operate as expected. There is no verification that the address entered for MVPN provider tunnel source-address is such an address or is not a system IP address.

NG-MVPN core diversity

See Logical networks using multi-instance IGP for an operational example of logical networks using Multi-Instance IGP.

Figure 29. Logical networks using multi-instance IGP

SR OS is being positioned in multi-instance IGP as a virtualization or migration strategy in numerous cases. One specific application is as a virtual LSR core whereby various topologies are created using separate IGP instances. Specifically, the migration to SR solutions requires the deployment of multi-instance IGP with service migrations. The objective is to more cleanly segregate protocols and service bindings to specific routing instances. NG-MVPN does not currently allow non-system loopbacks to be used for PMSI (for example, MVPN address family).

The ability to support binding MVPN with mLDP tunnels to different loopback interfaces is one of the main requirements. In addition, assigning these loopback interfaces to different IGP instances creates parallel NG-MVPN services, each running over a separate IGP instance.

This feature has two main components to it:

  • The ability of advertising a MVPN route, via a loopback interface, and generating an mLDP FEC with that loopback interface.

  • The ability of creating multiple IGP instances and assigning a loopback to each IGP instance. This, combined with the component above, creates parallel NG-MVPN services on different IGP instances.

NG-MVPN to loopback interface

Figure 30. NG-MVPN setup via loopback interface

SystemIP is usually used for management purposes and, therefore, it may be needed to create services to a separate loopback interface. Because of security concerns, many operators do not want to create services to the systemIP address. See NG-MVPN setup via loopback interface and Intra-AS basic opaque FEC to loopback interface.

The first portion of this feature allows MVPN routes be advertised with a nexthop specific loopback.

This can be achieved via two methods:

  • Having IBGP session to the loopback interface of the peer, and using the corresponding local loopback for local-address.

  • Having IBGP session to the systemIP but using policies to change the nexthop of the AD route to the corresponding loopback interface.

After the AD routes are advertised via the loopback interface as nexthop, PIM generates an mLDP FEC for the loopback interface.

The preceding configuration allows an NG-MVPN to be established via a specific loopback.

Figure 31. Intra-AS basic opaque FEC to loopback interface

It should be noted that this setup works in a single area or multi-area through an ABR.

NG-MVPN core diversity

Figure 32. Core diversity with parallel NG-MVPN services on parallel IGP instances

In Core diversity with parallel NG-MVPN services on parallel IGP instances, Red and Blue networks correspond to separate IGP instances tied to separate loopback interfaces. In core diversity, MVPN services on the LER are bound to a domain by advertising MP-BGP routes, with next hop set to the appropriate loopback address, and having the receiving LERs resolve those BGP next hops, based on the corresponding IGP instance. All subsequent MVPN BGP routing exchanges must set and resolve the BGP next hop with the configured non-system loopback.

With this feature, an MP-BGP next hop would resolve to a link LDP label which is indirectly associated with a specific IGP instance. Services which advertise BGP routes with next hop Red loopback would result in traffic flowing over the Red network using LDP and Blue loopback would result in traffic flowing over Blue network. See Core diversity with parallel NG-MVPN services on parallel IGP instances.

Most importantly, the common routes in each IGP instance must have a unique and active label. This is required to ensure that the same route advertised in two different IGP domains do not resolve to the same label. LDP local-lsr-id can be used to ensure FECs and label mapping be advertised via the right instance of IGP.

Core diversity allows an operator to optionally deploy multicast NG-MVPN in either default IGP instance or one of the non-default IGP instances to provide, for example, topology isolation or different level of services. The following describes the main feature attributes:

  • NG- MVPN can use IPv4/IPv6 multicast.

  • NG-MVPN can use a non-default OSPF or ISIS instance.

    Note: This is accomplished by using their loopback addresses instead of a system address.
  • The BGP Connector also uses non-default OSPF loopback as NH, via two methods:

    • Setting the BGP local-address to a loopback interface IP address

    • Creating a routing policy to set the NH of a MVPN AD route to the corresponding loopback IP

  • RSVP-TE/LDP transport tunnels also use non-systemIP loopback for session creation. As an example, RSVP-TE p2mp LSPs would be created to non systemIP loopbacks and mLDP creates a session via local-lsr-id.

  • Need to add the source-address for mvpn auto-discover default.

On the source PEs, a NG-MVPN is assigned to a non-default IGP core instance as follows:

  1. NG-MVPN is statically pointed to use one of the non-default red/blue IGP instances loopback addresses as source address instead of system loopback IP.

  2. MVPN export policy is used to change unicast route next-hop VPN address (BGP Connector support for non-default instances).

  3. Alternatively, the BGP local-address can be set to the correct loopback interface assigned for that specific instance.

The preceding configuration ensures that MVPN-IPv4/v6 and IP-VPN routes for the non-default core instance use non-default IGP loopback instead of system IP. This ensures MVPN-IPv4/v6 advertisement/joins run in the correct core instance and mLDP and P2MP RSVP tunnels (I-PMSI and S-PMSI) for multicast can be set-up using and terminating on non-system IP.

If BGP export policy is used to change unicast route next-hop VPN address, then unicast traffic must be forwarded in non-default red or blue core instance LDP or RSVP (terminating on non-system IP) must be used.

P2MP RSVP-TE core diversity with UFD for UMH redundancy

Figure 33. P2MP RSVP-TE core diversity with UFD for UMH redundancy

Each NG-MVPN can be established over a separate IGP instance for core diversity support. In P2MP RSVP-TE core diversity with UFD for UMH redundancy, there are two IGP instances, Blue and Red, each having its own dedicated NG-MVPN service. The Blue plane is identified with the system IP address, and Red plane is identified with a loopback IP address. MVPN Autodiscovery (AD) routes are advertised and installed accordingly based on their NLRI in each instance. To advertise these MVPN AD routes in the corresponding planes, route policies are used to change the next hops of the AD routes. For example, for the Blue plane the AD routes are advertised by default with the system IP address as their next hop, so no route policy is necessary. In the Red plane, a route policy can change the next hop of the corresponding NG-MVPN AD routes to use the loopback IP address.

Core diversity also supports UMH redundancy solutions. In the case of P2MP RSVP-TE, which uses UFD for source UMH failure, the UFD packets are generated for each IGP instance (Blue, Red) accordingly, with the correct source and destination IP address that is part of that IGP instance.

UFD packet generation

SR OS generates the UFD packets with the correct source and destination IP addresses for each IGP instance used in the core diversity configuration. SR OS uses the NLRI next-hop information of the AD route for the destination IP address and derives the source IP address from the MVPN autodiscovery default source-address loopback for the UFD packets. This ensures the UFD packets are traversing the appropriate core corresponding to their UMH reachability.

For example, in P2MP RSVP-TE core diversity with UFD for UMH redundancy, the Blue plane UFD packets are generated from the root PE to the leaf PE with the source IP address as the local system IP on the root and the destination IP address as the system IP of the leaf. The Red plane generates the UFD packet with the loopback IP address to which it is corresponding to as its source and destination IP address.

Configuration example

Figure 34. Core diversity with parallel NG-MVPN services on parallel IGP instances

In Core diversity with parallel NG-MVPN services on parallel IGP instances, there are three IGP instances, the default Instance 0, Instance 1, and Instance 2. Each instance binds to its own loopback interface. For Instance 0, it is the systemIP system Interface used as loopback. LDP, RSVP and MP-BGP need to run between the corresponding loopback associated with each instance.

For example, for the blue Instance 2, both MP-BGP and LDP need to be configured to its corresponding loopback loopback2 and the next-hop for BGP MVPN-IP4/IPv6 and the VPN-IPv4/IPv6 need to be loopback2.

From a configuration point of view, the following steps need to be performed:

  1. For MLDP, configure LDP with local-lsr-id with loopback interface of instance 2 loopback2:

    *A:SwSim14>config>router>ldp# info 
    
          interface-parameters
             interface ‟2ROOT” dual-stack
               ipv4
                 local-lsr-id interface-name ‟loopback2”
                  no shutdown
               exit
               no shutdown
             exit
    
  2. Enable the source-address for default auto discover as follows:

    *A:Dut-A>config>service>vprn 2
          mvpn auto-discovery default source-address LOOPBack1
          vrf-export ‟vprnexp100”
    *A:Dut-A>config>service>vprn 3
          mvpn auto-discovery default source-address LOOPBack2
          vrf-export ‟vprnexp101”
    
  3. Define community vprnXXXX for each VPRN using non-default core-instance and define a policy to tag each VPRN with either a blue or red standard community attribute:

    *A:Dut-A>config>router>policy-options# info
            community "vprn2" members "target:70:70"
            community "vprn3" members "target:80:80"
            policy-statement "vprnexp2"
                entry 10
                    from
                       protocol direct
                    exit
                    action accept
                       community add "vprn2" "red"
                    exit
                exit
            policy-statement "vprnexp3"
                entry 10
                    from
                       protocol direct
                    exit
                    action accept
                       community add "vprn3" "blue"
                    exit
                exit
            exit
    
  4. Define a single global BGP policy to change next hop for red/blue MVPNs:

    *A:Dut-A>config>router>policy-options# info
            policy-statement "MVPN_CoreDiversity_Exp"
                entry 10
                    from
                       community "red"
                    exit
                    to
                       protocol bgp-vpn
                    exit
                    action accept
                         next-hop loopback1
                    exit
                exit
                entry 20
                    from
                       community "blue"
                    exit
                    to
                       protocol bgp-vpn
                    exit
                    action accept
                         next-hop loopback2
                    exit
                exit
            exit
    
  5. Configure BGP default MVPN export in the group as required:

    configure router bgp group "mvpn" export "MVPN_CoreDiveristy_Exp"
    
  6. Configure each VPRN to use correct IGP source address and correct VRF export policy:

    *A:Dut-A>config>service>vprn 2
          mvpn auto-discovery default source-address loopback1
          vrf-export "vprnexp2"
    *A:Dut-A>config>service>vprn 3
          mvpn auto-discovery default source-address loopback2
          vrf-export "vprnexp3"
    

NG-MVPN multicast source geo-redundancy

Multicast source geo-redundancy is targeted primarily for MVPN deployments for multicast delivery services like IPTV. The solutions allows operators to configure a list of geographically dispersed redundant multicast sources (with different source IPs) and then, using configured BGP policies, ensure that each Receiver PE (a PE with receivers in its C-instance) selects only a single, most-preferred multicast source for a specific group from the list. Although the data may still be replicated in P-instance (each multicast source sends (C-S, C-G) traffic onto its I-PMSI tree or S-PMSI tree), each Receiver PE only forwards data to its receivers from the preferred multicast source. This allows operators to support multicast source geo-redundancy without the replication of traffic for each (C-S, C-G) in the C-instance while allowing fast recovery of service when an active multicast source fails.

Preferred source selection for multicast source geo-redundancy shows an operational example of multicast source geo-redundancy:

Figure 35. Preferred source selection for multicast source geo-redundancy

Operators can configure a list of prefixes for multicast source redundancy per MVPN on Receiver PEs:

  • Up to 8 multicast source prefixes per VPRN are supported.

  • Any multicast source that is not part of the source prefix list is treated as a unique source and automatically joined in addition to joining the most preferred source from the redundant multicast source list.

A Receiver PE selects a single, most-preferred multicast source from the list of pre-configured sources for a specific MVPN during (C-*, C-G) processing as follows:

  • A single join for the group is sent to the most preferred multicast source from the operator-configured multicast source list. Joins to other multicast sources for a specific group are suppressed. Operator can see active and suppressed joins on a Receiver PE. Although a join is sent to a single multicast source only, (C-S, C-G) state is created for every source advertising Type-5 S-A route on the Receiver PE.

  • The most preferred multicast source is a reachable source with the highest local preference for Type-5 SA route based on the BGP policy, as described later in this section.

  • On a failure of the preferred multicast source or when a new multicast source with a better local preference is discovered, Receiver PE joins the new most-preferred multicast source. The outage experienced depends on how quickly Receiver PE receives Type-5 S-A route withdrawal or loses unicast route to multicast source, and how quickly the network can process joins to the newly selected preferred multicast sources.

  • Local multicast sources on a Receiver PE are not subject to the most-preferred source selection, regardless of whether they are part of redundant source list or not.

BGP policy on Type-5 SA advertisements is used to determine the most preferred multicast source based on the best local preference as following:

  • Each Source PE (a PE with multicast sources in its C-instance) tags Type-5 SA routes with a unique standard community attribute using global BGP policy or MVPN vrf-export policy. Depending on multicast topology, the policy may require source-aware tagging in the policy. Either all MVPN routes or Type 5 SA routes only can be tagged in the policy (new attribute mvpn-type 5).

  • Each receiver PE has a BGP VRF import policy that sets local preference using match on Type-5 SA routes (new attribute mvpn-type 5) and standard community attribute value (as tagged by the Source PEs). Using policy statements that also include group address match, allows receiver PEs to select the best multicast source per group. The BGP VRF import policy must be applied as vrf-import under config>service>vprn>mvpn context. It must have default-action accept specified, or all MVPN routes other than those matched by specified entries are rejected. In addition, it must have vrf-target as a community match condition, because vrf-target mvpn configuration is ignored when vrf-import policy is defined.

Operators can change redundant source list or BGP policy affecting source selection in service. If such a change of the list/policy results in a new preferred multicast source election, make-before-break is used to join the new source and prune the previously best source.

For the correct operations, MVPN multicast source geo-redundancy requires the router:

  • To maintain the list of eligible multicast sources on Receiver PEs, Source PE routers must generate Type-5 S-A route even if the Source PE sees no active joins from any receiver for a specific group.

  • To trigger a switch from a currently active multicast source on a Receiver PE, Source PE routers must withdraw Type-5 S-A route when the multicast source fails or alternatively unicast route to multicast source must be withdrawn or go down on a Receiver PE.

MVPN multicast source redundancy solutions is supported for the following configurations only. Enabling the feature in unsupported configuration must be avoided.

  • NG-MVPN with RSVP-TE or mLDP or PIM with BGP c-multicast signaling in P-instance. Both I-PMSI and S-PMSI trees are supported.

  • IPv4 and IPv6 (C-*, C-G) PIM ASM joins in the C-instance.

  • Both intersite-shared enabled and disabled are supported. For intersite-shared enabled, operators must enable generation of Type-5 S-A routes even in the absence of receivers seen on Source PEs (intersite-shared persistent-type5-adv must be enabled).

  • The Source PEs must be configured as a sender-receiver, the Receiver PEs can be configured as a sender-receiver or a receiver-only.

  • The RPs must be on the Source PEs side. Static RP, anycast-RP, embedded-RP types are supported.

  • UMH redundancy can be deployed to protect Source PE to any multicast source. When deployed, UMH selection is executed independently of source selection after the most preferred multicast source had been chosen. Supported umh-selection options include: highest-ip, hash-based, tunnel-status (not supported for IPv6), and unicast-rt-pref.

Multicast core diversity for Rosen MDT SAFI MVPNs

Multicast core diversity shows a Rosen MVPN core diversity deployment.

Figure 36. Multicast core diversity

Core diversity allows operators to optionally deploy multicast MVPN in either default IGP instance. or one of two non-default IGP instances to provide; for example, topology isolation or different level of services. The following describes the main feature attributes:

  • Rosen MVPN IPv4 multicast with MDT SAFI is supported with default and data MDTs.

  • Rosen MVPN can use a non-default OSPF or ISIS instance (using their loopback addresses instead of a system address).

  • Up to 3 distinct core instances are supported: system + 2 non-default OSPF instances shown in Multicast core diversity.

  • The BGP Connector also uses non-default OSPF loopback as NH, allowing Inter-AS Option B/C functionality to work with Core diversity as well.

  • The feature is supported with CSC-VPRN.

On source PEs (PE1: UMH, PE2: UMH in the above picture), an MVPN is assigned to a non-default IGP core instance as follows:

  • MVPN is statically pointed to use one of the non-default IGP instances loopback addresses as source address instead of system loopback IP.

  • MVPN export policy is used to change unicast route next-hop VPN address.

  • BGP Connector support for non-default instances.

The configuration shown above ensures that MDT SAFI and IP-VPN routes for the non-default core instance use non-default IGP loopback instead of system IP. This ensures PIM advertisement/joins run in the correct core instance and GRE tunnels for multicast can be set-up using and terminated on non-system IP. If BGP export policy is used to change unicast route next-hop VPN address instead of BGP Connector attribute-based processing and unicast traffic must be forwarded in non-default core instances 1 or 2, LDP or RSVP (terminating on non-system IP) must be used. GRE unicast traffic termination on non-system IP is not supported and any GRE traffic arriving at the PE in instances 1 or 2, destined for non-default IGP loopback IP is forwarded to CPM (ACL or CPM filters can be used to prevent the traffic from reaching the CPM).

No configuration is required on non-source PEs.

Known feature restrictions include:

  • VPRN instance must be shutdown to change the mdt-safi source-address. The CLI rollback that includes change of the auto-discovery is therefore service impacting.

  • To reset mdt-safi source-address to system IP, operator must first execute no auto-discovery (or auto-discovery default) then auto-discovery mdt-safi

  • Configuring system IP as a source-address consumes one of the 2 IP addresses allowed, therefore it should not be done.

  • Operators must configure correct IGP instance loopback IP addresses within Rosen MVPN context and must configure correct BGP policies (before Release 12.0R4) for the feature to operate as expected. There is no verification that the address entered for MVPN provider tunnel source-address is such an address or is not a system IP address.

Inter-AS MVPN

The Inter-AS MVPN feature allows set-up of Multicast Distribution Trees (MDTs) that span multiple Autonomous Systems (ASes).This section focuses on multicast aspects of the Inter-AS MVPN solution.

To support Inter-AS option for MVPNs, a mechanism is required that allows setup of Inter-AS multicast tree across multiple ASes. Because of limited routing information across AS domains, it is not possible to setup the tree directly to the source PE. Inter-AS VPN Option A does not require anything specific to inter-AS support as customer instances terminate on ASBR and each customer instance is handed over to the other AS domain via a unique instance. This approach allows operators to provide full isolation of ASes, but the solution is the least scalable case, as customer instances across the network have to exist on ASBR.

Inter-AS MVPN Option B allows operators to improve upon the Option A scalability while still maintaining AS isolation, while Inter-AS MVPN Option C further improves Inter-AS scale solution but requires exchange of Inter-AS routing information and therefore is typically deployed when a common management exists across all ASes involved in the Inter-AS MVPN. The following sub-sections provide further details on Inter-AS Option B and Option C functionality.

BGP connector attribute

BGP connector attribute is a transitive attribute (unchanged by intermediate BGP speaker node) that is carried with VPNv4 advertisements. It specifies the address of source PE node that originated the VPNv4 advertisement.

With Inter-AS MVPN Option B, BGP next-hop is modified by local and remote ASBR during re-advertisement of VPNv4 routes. On BGP next-hop change, information about the originator of prefix is lost as the advertisement reaches the receiver PE node.

BGP connector attribute allows source PE address information to be available to receiver PE, so that a receiver PE is able to associate VPNv4 advertisement to the corresponding source PE.

PIM RPF vector

In case of Inter-AS MVPN Option B, routing information toward the source PE is not available in a remote AS domain, because IGP routes are not exchanged between ASes. Routers in an AS other than that of a source PE, have no routes available to reach the source PE and therefore PIM JOINs would never be sent upstream. To enable setup of MDT toward a source PE, BGP next-hop (ASBR) information from that PE's MDT-SAFI advertisement is used to fake a route to the PE. If the BGP next-hop is a PIM neighbor, the PIM JOINs would be sent upstream. Otherwise, the PIM JOINs would be sent to the immediate IGP next-hop (P) to reach the BGP next-hop. Because the IGP next-hop does not have a route to source PE, the PIM JOIN would not be propagated forward unless it carried extra information contained in RPF Vector.

In case of Inter-AS MVPN Option C, unicast routing information toward the source PE is available in a remote AS PEs/ASBRs as BGP 8277 tunnels, but unavailable at remote P routers. If the tunneled next-hop (ASBR) is a PIM neighbor, the PIM JOINs would be sent upstream. Otherwise, the PIM JOINs would be sent to the immediate IGP next-hop (P) to reach the tunneled next-hop. Because the IGP next-hop does not have a route to source PE, the PIM JOIN would not be propagated forward unless it carried extra information contained in RPF Vector.

To enable setup of MDT toward a source PE, PIM JOIN therefore carries BGP next hop information in addition to source PE IP address and RD for this MVPN. For option-B, both these pieces of information are derived from MDT-SAFI advertisement from the source PE. For option-C, both these pieces of information are obtained from the BGP tunneled route.

The RPF vector is added to a PIM join at a PE router when configure router pim rpfv option is enabled. P routers and ASBR routers must also have the option enabled to allow RPF Vector processing. If the option is not enabled, the RPF Vector is dropped and the PIM JOIN is processed as if the PIM Vector were not present.

For further details about RPF Vector processing please see [RFCs 5496, 5384 and 6513]

Inter-AS MVPN Option B

Inter-AS Option B is supported for Rosen MVPN PIM SSM using BGP MDT SAFI, PIM RPF Vector and BGP Connector attribute. The Inter-AS Option B default MDT setup depict set-up of a default MDT:

Figure 37. Inter-AS Option B default MDT setup

SR OS inter-AS Option B is designed to be standard compliant based on the following RFCs:

RFC 5384
The Protocol Independent Multicast (PIM) Join Attribute Format
RFC 5496
The Reverse Path Forwarding (RPF) Vector TLV
RFC 6513
Multicast in MPLS/BGP IP VPNs

The SR OS implementation was designed also to interoperate with older routers Inter-AS implementations that do not comply with the RFC 5384 and RFC 5496.

Inter-AS MVPN Option C

Inter-AS Option C is supported for Rosen MVPN PIM SSM using BGP MDT SAFI and PIM RPF Vector. Inter-AS Option C default MDT setup depicts a default MDT setup:

Figure 38. Inter-AS Option C default MDT setup

Additional restrictions for Inter-AS MVPN Option B and C support are the following:

  • Inter-AS MVPN Option B is not supported with duplicate PE addresses.

  • For Inter-AS Option C, BGP 8277 routes are installed into unicast rtm (rtable-u), unless routes are installed by some other means into multicast rtm (rtable-m), and Option C does not build core MDTs, therefore, rpf-table is configured to rtable-u or both.

Additional Cisco interoperability notes are the following:

RFC 5384
The Protocol Independent Multicast (PIM) Join Attribute Format
RFC 5496
The Reverse Path Forwarding (RPF) Vector TLV
RFC 6513
Multicast in MPLS/BGP IP VPNs

The SR OS implementation was designed to inter-operate with Cisco routers Inter-AS implementations that do not comply with the RFC5384 and RFC5496.

When configure router pim rpfv mvpn option is enabled, Cisco routers need to be configured to include RD in an RPF vector using the following command: ip multicast vrf vrf-name rpf proxy rd vector for interoperability. When Cisco routers are not configured to include RD in an RPF vector, operator should configure SR OS router (if supported) using configure router pim rpfv core mvpn: PIM joins received can be a mix of core and mvpn RPF vectors.

NG-MVPN non-segmented inter-AS solution

This feature allows multicast services to use segmented protocols and span them over multiple autonomous systems (ASs), as done in unicast services. As IP VPN or GRT services span multiple IGP areas or multiple ASs, either because of a network designed to deal with scale or as result of commercial acquisitions, operators may require Inter-AS VPN (unicast) connectivity. For example, an Inter-AS VPN can break the IGP, MPLS and BGP protocols into access segments and core segments, allowing higher scaling of protocols by segmenting them into their own islands. SR OS also allows for similar provision of multicast services and for spanning these services over multiple IGP areas or multiple ASs.

For multicast VPN (MVPN), SR OS previously supported Inter-AS Model A/B/C for Rosen MVPN; however, when MPLS was used, only Model A was supported for Next Generation Multicast VPN (NG-MVPN) and d-mLDP signaling.

For unicast VPRNs, the Inter-AS or Intra-AS Option B and C breaks the IGP, BGP and MPLS protocols at ABR routers (in case of multiple IGP areas) and ASBR routers (in case of multiple ASs). At ABR and ASBR routers, a stitching mechanism of MPLS transport is required to allow transition from one segment to next, as shown in Unicast VPN Option B with segmented MPLS and Unicast VPN Option C with segmented MPLS.

In Unicast VPN Option B with segmented MPLS, the Service Label (S) is stitched at the ASBR routers.

Figure 39. Unicast VPN Option B with segmented MPLS

In Unicast VPN Option C with segmented MPLS, the 8277 BGP Label Route (LR) is stitched at ASBR1 and ASBR3. At ASBR1, the LR1 is stitched with LR2, and at ASBR3, the LR2 is stitched with TL2.

Figure 40. Unicast VPN Option C with segmented MPLS

Previously, in case of NG-MVPN, segmenting an LDP MPLS tunnel at ASBRs or ABRs was not possible. As such, RFC 6512 and 6513 used a non-segmented mechanism to transport the multicast data over P-tunnels end-to-end through ABR and ASBR routers. The signaling of LDP needed to be present and possible between two ABR routers or two ASBR routers in different ASs.

Note: For unicast VPNs, it was usually preferred to only have EBGP between ASBR routers. The non-segmented behavior of d-mLDP would have broken this by requiring LDP signaling between ASBR routers.

SR OS now has d-mLDP non-segmented intra-AS and inter-AS signaling for NG-MVPN and GRT multicast. The non-segmented solution for d-mLDP is possible for inter-ASs as Option B and C.

Non-segmented d-mLDP and inter-AS VPN

There are three types of VPN Inter-AS solutions:

Options B and C use recursive opaque types 8 and 7 respectively, from Recursive opaque types .

Table 7. Recursive opaque types
Opaque type Opaque name RFC SR OS use

1

Basic Type

RFC 6388

VPRN Local AS

3

Transit IPv4

RFC 6826

IPv4 multicast over mLDP in GRT

4

Transit IPv6

RFC 6826

IPv6 multicast over mLDP in GRT

7

Recursive Opaque (Basic Type)

RFC 6512

Inter-AS Option C MVPN over mLDP

8

Recursive Opaque (VPN Type)

RFC 6512

Inter-AS Option B MVPN over mLDP

Inter-AS Option A

In Inter-AS Option A, ASBRs communicate using VPN access interfaces, which need to be configured under PIM for the two ASBRs to exchange multicast information.

Inter-AS Option B

The recursive opaque type used for Inter-AS Option B is the Recursive Opaque (VPN Type), shown as opaque type 8 in Recursive opaque types .

Inter-AS Option B Support for NG-MVPN

Inter-AS Option B requires additional processing on ASBR routers and recursive FEC encoding than that of Inter-AS Option A. Because BGP adjacency is not e2e, ASBRs must cache and use a PMSI route to build the tree. For that, mLDP recursive FEC must carry RD information—therefore, VPN recursive FEC is required (opaque type 8).

In Inter-AS Option B, the PEs in two different ASs do not have their system IP address in the RTM. As such, for NG-MVPN, a recursive opaque value in mLDP FEC is required to signal the LSP to the first ASBR in the local AS path.

Because the system IPs of the peer PEs (Root-1 and Root-2) are not installed on the local PE (leaf), it is possible to have two PEs in different ASs with same system IP address, as shown in Identical system IP on multiple PEs (Option B). However, SR OS does not support this topology. The system IP address of all nodes (root or leaf) in different ASs must be unique.

Figure 41. Identical system IP on multiple PEs (Option B)

For inter-AS Option B and NG-MVPN, SR OS as a leaf does not support multiple roots in multiple ASs with the same system IP and different RDs; however, the first root that is advertised to an SR OS leaf is used by PIM to generate an MLDP tunnel to this actual root. Any dynamic behavior after this point, such as removal of the root and its replacement by a second root in a different AS, is not supported and the SR OS behavior is nondeterministic.

I-PMSI and S-PMSI Establishment

I-PMSI and S-PMSI functionality follows RFC 6513 section 8.1.1 and RFC 6512 sections 3.1 and 3.2.1. For routing, the same rules as for GRT d-mLDP use case apply, but the VRR Route Import External community now encodes the VRF instance in the local administrator field.

Option B uses an outer opaque of type 8 and inter opaque of type 1 (see Recursive opaque types ).

Non-segmented mLDP PMSI establishment (Option B) depicts the processing required for I-PMSI and S-PMSI Inter-AS establishment.

Figure 42. Non-segmented mLDP PMSI establishment (Option B)

For non-segmented mLDP trees, A-D procedures follow those of the Intra-AS model, with the exception that NO EXPORT community must be excluded; LSP FEC includes mLDP VPN-recursive FEC.

For I-PMSI on Inter-AS Option B:

  • A-D routes must be installed by ASBRs and next-hop information is changed as the routes are propagated, as shown in Non-segmented mLDP PMSI establishment (Option B).

  • PMSI A-D routes are used to provide inter-domain connectivity on remote ASBRs.

On a receipt of an Intra-AS PMSI A-D route, PE2 resolves PE1’s address (next-hop in PMSI route) to a labeled BGP route with a next-hop of ASBR3, because PE1 (Root-1) is not known via IGP. Because ASBR3 is not the originator of the PMSI route, PE2 sources an mLDP VPN recursive FEC with a root node of ASBR3, and an opaque value containing the information advertised by Root-1 (PE-1) in the PMSI A-D route, shown below, and forwards the FEC to ASBR 3 using IGP.

PE-2 LEAF FEC: (Root ASBR3, Opaque value {Root: ROOT-1, RD 60:60, Opaque Value: P2MPLSP-ID xx}}

When the mLDP VPN-recursive FEC arrives at ASBR3, it notes that it is the identified root node, and that the opaque value is a VPN-recursive opaque value. Because Root-1 PE1 Is not known via IGP, ASBR3 resolves the root node of the VPN-Recursive FEC using PMSI A-D (I or S) matching the information in the VPN-recursive FEC (the originator being PE1 (Root-1), RD being 60:60, and P2MP LSP ID xx). This yields ASBR1 as next hop. ASBR3 creates a new mLDP FEC element with a root node of ASBR1, and an opaque value being the received recursive opaque value, as shown below. ASBR then forwards the FEC using IGP.

ASBR-3 FEC: {Root ASBR 1, Opaque Value {Root: ROOT-1, RD 60:60, Opaque Value: P2MPLSP-ID xx}}

When the mLDP FEC arrives at ASBR1, it notes that it is the root node and that the opaque value is a VPN-recursive opaque value. As PE1’s ROOT-1 address is known to ASBR1 through the IGP, no further recursion is required. Regular processing begins, using received Opaque mLDP FEC information.

ASBR-1 FEC: {Root: ROOT-1, Opaque Value: P2MP LSP-ID xx

Note: VPN-Recursive FEC carries P2MPLSP ID. The P2MPLSP ID is used in addition to PE RD and Root to select a route to the mLDP root using the correct I-PMSI or S-PMSI route.

The functionality as described above for I-PMSI applies also to S-PMSI and (C-*, C-*) S-PMSI.

C-multicast Route Processing

C-multicast route processing functionality follows RFC 6513 section 8.1.2 (BGP used for route exchange). The processing is analogous to BGP Unicast VPN route exchange described in Unicast VPN Option B with segmented MPLS and Unicast VPN Option C with segmented MPLS. Non-segmented mLDP C-multicast exchange (Option B) shows C-multicast route processing with non-segmented mLDP PMSI details.

Figure 43. Non-segmented mLDP C-multicast exchange (Option B)
Inter-AS Option C

In Inter-AS Option C, the PEs in two different ASs have their system IP address in the RTM, but the intermediate nodes in the remote AS do not have the system IP of the PEs in their RTM. As such, for NG-MVPN, a recursive opaque value in mLDP FEC is needed to signal the LSP to the first ASBR in the local AS path.

The recursive opaque type used for Inter-AS Option B is the Recursive Opaque (Basic Type), shown as opaque type 7 in Recursive opaque types .

Inter-AS Option C support for NG-MVPN

For Inter-AS Option C, on a leaf PE, a route exists to reach root PE’s system IP and, as ASBRs can use BGP unicast routes, recursive FEC processing using BGP unicast routes, and not VPN recursive FEC processing using PMSI routes, is required.

I-PMSI and S-PMSI establishment

I-PMSI and S-PMSI functionality follows RFC 6513 section 8.1.1 and RFC 6512 Section 2. The same rules as per the GRT d-mLDP use case apply, but the VRR Route Import External community now encodes the VRF instance in the local administrator field.

Option C uses an outer opaque of type 7 and inter opaque of type 1.

Non-segmented mLDP PMSI establishment (Option C) shows the processing required for I-PMSI and S-PMSI Inter-AS establishment.

Figure 44. Non-segmented mLDP PMSI establishment (Option C)

For non-segmented mLDP trees, A-D procedures follow those of the Intra-AS model, with the exception that NO EXPORT Community must be excluded; LSP FEC includes mLDP recursive FEC (and not VPN recursive FEC).

For I-PMSI on Inter-AS Option C:

  • A-D routes are not installed by ASBRs and next-hop information is not changed in MVPN A-D routes.

  • BGP-labeled routes are used to provide inter-domain connectivity on remote ASBRs.

On a receipt of an Intra-AS I-PMSI A-D route, PE2 resolves PE1’s address (N-H in PMSI route) to a labeled BGP route with a next-hop of ASBR3, because PE1 is not known via IGP. PE2 sources an mLDP FEC with a root node of ASBR3, and an opaque value, shown below, containing the information advertised by PE1 in the I-PMSI A-D route.

PE-2 LEAF FEC: {root = ASBR3, opaque value: {Root: ROOT-1, opaque value: P2MP-ID xx}}

When the mLDP FEC arrives at ASBR3, it notes that it is the identified root node, and that the opaque value is a recursive opaque value. ASBR3 resolves the root node of the Recursive FEC (ROOT-1) to a labeled BGP route with the next-hop of ASBR1, because PE-1 is not known via IGP. ASBR3 creates a new mLDP FEC element with a root node of ASBR1, and an opaque value being the received recursive opaque value.

ASBR3 FEC: {root: ASBR1, opaque value: {root: ROOT-1, opaque value: P2MP-ID xx}}

When the mLDP FEC arrives at ASBR1, it notes that it is the root node and that the opaque value is a recursive opaque value. As PE-1’s address is known to ASBR1 through the IGP, no further recursion is required. Regular processing begins, using the received Opaque mLDP FEC information.

The functionality as described above for I-PMSI applies to S-PMSI and (C-*, C-*) S-PMSI.

C-multicast route processing

C-multicast route processing functionality follows RFC 6513 section 8.1.2 (BGP used for route exchange). The processing is analogous to BGP Unicast VPN route exchange. Non-segmented mLDP C-multicast exchange (Option C) shows C-multicast route processing with non-segmented mLDP PMSI details.

Figure 45. Non-segmented mLDP C-multicast exchange (Option C)
LEAF node cavities
Caution: The SR OS ASBR does not currently support receiving a non-recursive opaque FEC (opaque type 1).

The LEAF (PE-2) has to have the ROOT-1 system IP installed in RTM via BGP. If the ROOT-1 is installed in RTM via IGP, the LEAF does not generate the recursive opaque FEC. As such, the ASBR 3 does not process the LDP FEC correctly.

Configuration example

No configuration is required for Option B or Option C on ASBRs, although for Option B, config>router>bgp>enable-inter-as-vpn is required to enable inter-as-non-segmented MLDP through the ASBR router.

Policy is required for a root or leaf PE for removing the NO_EXPORT community from MVPN routes, which can be configured using an export policy on the PE.

The following is an example for configuring a policy on PEs to remove the no-export:

*A:Dut-A>config>router>policy-options# info 
----------------------------------------------
            community "no-export" members "no-export"
            policy-statement "remNoExport"
                default-action accept
                    community remove "no-export"
                exit
            exit
----------------------------------------------
*A:Dut-A>config>router>policy-options#

The following is an example for configuring in BGP the policy in a global, group, or peer context:

*A:Dut-A>config>router>bgp# info 
----------------------------------------------
            vpn-apply-export
            export "remNoExport"
Inter-AS non-segmented MLDP

See the ‟Inter-AS Non-segmented MLDP” section of the 7450 ESS, 7750 SR, 7950 XRS, and VSR MPLS Guide for more information.

ECMP

See the ‟ECMP” section of the 7450 ESS, 7750 SR, 7950 XRS, and VSR MPLS Guide for more information about ECMP.

mLDP non-Segmented intra-AS (inter-area) MVPN solution

SR OS now supports intra-AS (Inter-Area) option B and C. The following interaction between inter and intra is as follows:

  • Intra-AS option B with inter-AS option B

  • Intra-AS option C with inter-AS option C

Intra-AS and inter-AS Option B

For intra/inter-as option B, the root is not visible on the leaf. LDP is responsible for building the recursive FEC and signaling the FEC to ABR/ASBR on the leaf. ABR/ASBR must have the PMSI AD router to re-build the FEC (recursive or basic) depending on whether they are connected to another ABR/ASBR or root node. As such, LDP must import the MVPN PMSI AD routes. To save resources, importing MVPN PMSI AD routes are performed manually by the operator using configuration commands. When mvpn-no-export-community command is enabled, LDP requests BGP to provide the LDP task with all the MVPN PMSI AD routes and LDP internally caches these routes. If this knob is disabled and to save resources, MVPN discards the catch routes.

In a scenario where a node running an older image that does not support the mvpn-no-export-community command and that node upgrades to a new image that does support the mvpn-no-export-community command, and if the older image had an inter-as MVPN configuration, then after the upgrade to the newer image, the mvpn-no-export-community command is enabled by default, to ensure a smooth upgrade. This is to verify that all the routes are imported to mLDP so the inter-as functionality works after the upgrade.

In addition, SR OS supports two major upgrades to enable the MVPN command if an upgrade to a load supporting this knob.

MVPN next hop self on ABRs

For option B, the ABR routers must change the next-hop of MVPN AD routes to be the ABR systemIP or the loopback IP for core diversity. Currently, the next-hop-self BGP command does not change the next hop of the MVPN AD routes. This functionality will be available in a future release.

In the meantime, a BGP policy can be used to change the MVPN AD routes next hop at the ABR.

MVPN next-hop-self policy example

MVPN Type 1 route (intra-AS IPMSI AD route) and MVPN Type 3 (S-PMSI AD route) must have a policy to set their next hop to be the ABR systemIP. In the following example, the ABR systemIP is 10.20.1.4 with the same token as the unicast vpn-ipv4 family and can be configured within the policy to have the next hop changed to the ABR systemIP.

Configure three policies on all ABRs:

  • a policy to change mvpn-ipv4 IntraAD Route Type 1 next hop to next-hop-self

  • a policy to change vpn-ipv4 next hop to next-hop-self

  • a policy to change mvpn-ipv4 IntraAD Route Type 3 to next-hop-self


*A:Dut-D>config>router>policy-options# info
----------------------------------------------
            policy-statement "mod_nh_10.20.1.4"
                entry 1
                    from
                        mvpn-type 1
                    exit
                    action accept
                        next-hop 10.20.1.4
                    exit
                exit
                default-action next-policy
                exit
            exit
            policy-statement "mod_nh_vpn_10.20.1.4"
                entry 1
                    from
                        family vpn-ipv4
                    exit
                    action accept
                        next-hop 10.20.1.4
                    exit
                exit
                default-action next-policy
                exit
            exit
            policy-statement "mod_nh_spmsi_10.20.1.4"
                entry 1
                    from
                        mvpn-type 3
                    exit
                    action accept
                        next-hop 10.20.1.4
                    exit
                exit
                default-action next-policy
                exit
            exit
----------------------------------------------
LDP configuration example

Under the LDP configuration, all ABR and non-ABR routers must enable import- pmsi-routes mvpn and mvpn-no-export-community to import all inter-AS and intra-AS (inter-area) routes.

A:Dut-B>config>router>ldp# info 
----------------------------------------------
            fast-reroute
            mp-mbb-time 10
            generate-basic-fec-only
            import-pmsi-routes
                mvpn
                mvpn-no-export-community
            exit
BGP configuration example

The MVPN AD next-hop-self policies and the vpn-ipv4 policy must be imported under BGP on ABR routers.

In addition, for unicast vpn-ipv4 connectivity, the enable-inter-as-vpn command must be configured under BGP.

A:Dut-B>config>router>bgp# info 
----------------------------------------------
            family ipv4 ipv6 vpn-ipv4 vpn-ipv6 mvpn-ipv4 mcast-vpn-ipv4 mvpn-ipv6 mcast-vpn-ipv6
            vpn-apply-import
            vpn-apply-export
            connect-retry 10
            keepalive 10
            hold-time 30
            enable-inter-as-vpn
            rapid-update vpn-ipv4 vpn-ipv6 mvpn-ipv4 mcast-vpn-ipv4 mvpn-ipv6 mcast-vpn-ipv6
            group "ibgp_A"
                next-hop-self
                cluster 10.20.1.2
                export "mod_nh_10.20.1.2" "mod_nh_spmsi_10.20.1.2" "mod_nh_vpn_10.20.1.2"
                neighbor 10.20.1.1
                    local-address 10.20.1.2
                    med-out 100
                    peer-as 100
                exit
            exit
            group "ibgp_D"
                next-hop-self
                cluster 10.180.4.2
                export "mod_nh_10.20.1.2" "mod_nh_spmsi_10.20.1.2" "mod_nh_vpn_10.20.1.2"

Weighted ECMP and ECMP for VPRN IPv4 and IPv6 over MPLS LSPs

ECMP over MPLS LSPs for VPRN services refers to spraying packets across multiple named RSVP and SR-TE LSPs within the same ECMP set.

The ECMP-like spraying consists of hashing the relevant fields in the header of a labeled packet and selecting the next-hop tunnel based on the modulo operation of the output of the hash and the number of ECMP tunnels. The maximum number of ECMP tunnels selected from the TTM matches the value of the user-configured ecmp option. Only LSPs with the same lowest LSP metric can be part of the ECMP set. If the number of these LSPs is higher than the value configured in the ecmp option, the LSPs with the lowest tunnel IDs are selected first.

In weighted ECMP, the load-balancing weight of the LSP is normalized by the system and then used to bias the amount of traffic forwarded over each LSP. The weight of the LSP is configured using the config>router>mpls>lsp>load-balancing-weight weight and config>router>mpls>lsp-template>load-balancing-weight weight commands.

If one or more LSPs in the ECMP set have no load-balancing-weight configured, and the ECMP is set to a specific next hop, regular ECMP spraying is used.

Weighted ECMP is configured for VPRN services with SDP auto-bind by using the config>service>vprn>auto-bind-tunnel>ecmp max-ecmp-routes and config>service>vprn>auto-bind-tunnel>weighted-ecmp commands. Weighted ECMP is disabled by default.

The ecmp max-ecmp-routes command allows explicit configuration of the number of tunnels that auto-bind-tunnel can use to resolve for a VPRN. The max-ecmp-routes parameter range is 1 to 32.

If weighted ECMP is enabled, then a path is selected based on the output of the hashing algorithm. Packet paths are then mapped to LSPs in the SDP in proportion to the configured load-balancing weight of the LSP. The hash is based on the system load-balancing configuration.

UMH redundancy using bandwidth monitoring

Bandwidth monitoring is used in MVPN for NG-MVPN and mLDP transport. It is used for multicast source redundancy, where both sources have the same IP address but are connected to two different root nodes. Bandwidth monitoring can be used with basic or recursive mLDP FEC. Upstream Multicast Hop (UMH) redundancy for bandwidth monitoring is supported for mLDP basic FEC and recursive FEC type 7 and 8 only.

Figure 46. Bandwidth monitoring

With bandwidth monitoring, the leaf node sends a single (S1,G1) join to both root nodes. PIM SSM and ASM can be used between the receiver and the leaf, or between the UMH and the source. For ASM, bandwidth monitoring works only when traffic is switched from <*,G> to <S,G>.

After the source starts the multicast flow toward the root PEs, both root nodes transport the traffic to the leaf node on the PMSI (I-PMSI or S-PMSI).

The leaf listens to the active PMSI, blocks the other PMSI, and monitors the traffic rate on both the active and inactive PMSI. For faster than 50 ms switchover, both the active and the inactive PMSIs must arrive on the same IOM, because a single IOM must make the decision about which PMSI the leaf listens to and which PMSI to block.

The threshold for the rate of traffic lost between the active PMSI and the inactive PMSI is configured on the leaf PE. If the rate exceeds the configured value, the traffic switches from the active PMSI to the inactive PMSI. Rate monitoring is per PMSI, and not per (C-S,C-G).

After the active PMSI traffic rate is stored, there is a revertive behavior, which has a configurable timer. The revertive timer starts after the active PMSI traffic is recovered. When the timer expires and the primary PMSI traffic is stable, the traffic is switched back to the primary path. If the traffic goes below the threshold while the timer is decrementing, the timer is reset. This feature supports 1K of PMSI switchovers within 50 ms.

Fault recovery mitigation at PMSI switchover time

<S,G> switching between I-PMSI and S-PMSI is not symmetrical (synchronized in time) on the active and the inactive UMH. While the active UMH attempts to switch an <S,G> between I-PMSI and S-PMSI, the active PMSI traffic rate arriving from the active UMH may be different from that arriving from the inactive UMH. This asymmetrical behavior can generate a premature switch from the active PMSI to the inactive PMSI.

The traffic rate delta can be set to account for this behavior. For example, if a 1080P channel uses 5 Mb/s, the traffic rate delta can be set to 15 Mb/s to avoid the switchover from the primary to the secondary PMSI if one or two 1080 <S,G>s are switched between I-PMSI and S-PMSI. This provides a 10 Mb/s tolerance of asymmetric traffic.

S-PMSI behavior

If the network FDV is large or the sources are not synchronized, switching from I-PMSI to S-PMSI can happen at a different time on the primary and backup UMHs. This can cause asymmetric traffic on the I-PMSI and S-PMSI, resulting in a switch from the active UMH. The <S,G> traffic can arrive for the I-PMSI from the backup UMH and for S-PMSI from the active UMH, which causes temporary duplicate traffic until both UMHs switch to S-PMSI.

Multistream S-PMSI provides a solution for this case by mapping an <S,G> to an S-PMSI. The <S,G> is locked to the multistream S-PMSI, which is always configured and never torn down, even if the traffic goes down to 0, so the multistream S-PMSI is not susceptible to S-PMSI traffic drops.

The number of <S,G>s must be less than, or equal to, the maximum-p2mp-spmsi value configured under the MVPN selective provider tunnel. Otherwise, different <S,G>s can switch to the S-PMSI and when the S-PMSI limit is exhausted, the 2 UMHs become out of sync.

Bandwidth monitoring on single IOMs

Bandwidth monitoring is supported on single IOMs, that is, both the active and the backup PMSI terminate on the same IOM. The IOM monitors the statistics of both PMSIs and makes the switchover decision. The IOM does not include the CPM in any of the bandwidth monitoring decisions, which ensures fast detection times and switchover times under 50 ms.

All leaf and bud nodes must be configured with the same UMH PEs, I-PMSI and S-PMSI, and bandwidth threshold configuration to avoid traffic drops.

All LAG members must be in the same IOM that is performing the bandwidth monitoring function. The LAG interfaces spanning between multiple port members that belong to different IOMs have an unpredictable behavior, including traffic duplication.

ASM behavior

Bandwidth monitoring is supported with ASM only after the traffic is switched from <*,G> to <S,G>. Traffic arriving on separate IOMs from the active UMH and the inactive UMH results in traffic duplication because the pairing of the active and inactive UMH is per IOM, and the IOMs do not have a view of the pair. If the active traffic and the backup traffic arrive on different IOMs, each IOM treats the flow as the active flow and processes the traffic accordingly.

Low traffic rate

At low traffic rates, the packet on the active PMSI and the packet on the inactive PMSI can arrive at different times. If the packets arrive at the point that the statistics are read, there can be an inconsistency, resulting in a switchover. To avoid a switchover, UMH redundancy using bandwidth monitoring should be used only when the traffic rate is higher than 2 or 3 packets per second.

Revertive timer

If the active PMSI traffic goes below the threshold while the revertive timer (configure service vprn mvpn provider-tunnel inclusive umh-rate-monitoring revertive-timer and configure service vprn mvpn provider-tunnel selective umh-rate-monitoring group source revertive-timer) is running, the timer is reset.

MVPN upstream PE fast failover

MVPN upstream UMH fast failover is supported for P2MP SR PMSI, as illustrated in Example of MVPN upstream PE fast failover. The upstream PE failure detection uses the Unidirectional Forwarding Detection (UFD) method. A downstream PE (receiver PE) supports fast upstream failover using the capability:
  • to select two UMH nodes
  • to monitor the upstream PE health using UFD
The tunnel status is monitored using the UFD session status received over the P-tunnel; the C-flow source is declared to be active based on this monitoring information. If multiple nodes are sourcing C-flows, the receiver PE node can choose to receive traffic from a primary and a standby source, but forwards only the multicast stream received from the primary source. If the detected P-tunnel status is down, the multicast receiver PE forwards the traffic received over the standby P-tunnel.
Figure 47. Example of MVPN upstream PE fast failover
MVPN upstream PE fast failover for tree SID

MVPN upstream PE fast failover for tree SID is supported as follows:

  • Only inclusive PMSIs are supported.
  • SM and SSM modes are supported. For SM, only fast switchover is supported on SPT. Fast protection is not supported on a shared tree.
  • UFD sessions with 10-millisecond interval are supported on the CPM.
  • Traffic duplication for restoration of the primary stream from the standby can occur for up to a second or more, depending on the CPU load during switchover.
  • The P2MP policy tunnel ID is used as the UFD discriminator. Consequently, the solution is not interoperable with other vendors.

Multicast-only Fast Reroute

Multicast-only Fast Reroute (MoFRR) is not supported when UMH redundancy with bandwidth monitoring is enabled.

FIB prioritization

The RIB processing of specific routes can be prioritized through the use of the rib-priority command. This command allows specific routes to be prioritized through the protocol processing so that updates are propagated to the FIB as quickly as possible.

The rib-priority command can be configured within the VPRN instance of the OSPF or IS-IS routing protocols. For OSPF, a prefix list can be specified that identifies which route prefixes should be considered high priority. If the rib-priority high command is configured under an VPRN>OSPF>area>interface context then all routes learned through that interface is considered high priority. For the IS-IS routing protocol, RIB prioritization can be either specified though a prefix-list or an IS-IS tag value. If a prefix list is specified than route prefixes matching any of the prefix list criteria is considered high priority. If instead an IS-IS tag value is specified then any IS-IS route with that tag value is considered high priority.

The routes that have been designated as high priority are the first routes processed and then passed to the FIB update process so that the forwarding engine can be updated. All known high priority routes should be processed before the routing protocol moves on to other standard priority routes. This feature has the most impact when there are a large number of routes being learned through the routing protocols.

Configuring a VPRN service with CLI

This section provides information to configure Virtual Private Routed Network (VPRN) services using the command line interface.

Basic configuration

The following fields require specific input (there are no defaults) to configure a basic VPRN service:

  • customer ID (see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Services Overview Guide)

  • interface parameters

  • spoke SDP parameters

The following example displays a configuration of a VPRN service.

*A:ALA-1>config>service>vprn# info
----------------------------------------------
            vrf-import "vrfImpPolCust1"
            vrf-export "vrfExpPolCust1"
            ecmp 8
            autonomous-system 10000
            route-distinguisher 10001:1
            auto-bind-tunnel
                resolution filter
                resolution-filter ldp
            vrf-target target:10001:1
            interface "to-ce1" create
                address 10.1.0.1/24
                proxy-arp
                exit
                sap 1/1/10:1 create
                    ingress
                        qos 100
                    exit
                    egress
                        qos 1010
                        filter ip 10
                    exit
                exit
                dhcp
                    description "DHCP test"
                exit
                vrrp 1
                exit
            exit
            static-route-entry 10.5.0.0/24 
                next-hop 10.1.1.2
            bgp
                router-id 10.0.0.1
                group "to-cel"
                    export "vprnBgpExpPolCust1"
                    peer-as 65101
                    neighbor 10.1.1.2
                    exit
                exit
            exit
            pim
                apply-to all
                rp
                    static
                    exit
                    bsr-candidate
                        shutdown
                    exit
                    rp-candidate
                        shutdown
                    exit
                exit
            exit
            rip
                export "vprnRipExpPolCust1"
                group "cel"
                    neighbor "to-ce1"
                    exit
                exit
            exit
            no shutdown
----------------------------------------------
*A:ALA-1>config>service>vprn#

Common configuration tasks

This section provides a brief overview of the tasks that must be performed to configure a VPRN service and provides the CLI commands.

  1. Associate a VPRN service with a customer ID.
  2. Optionally define an autonomous system.
  3. Define a route distinguisher (mandatory).
  4. Define VRF route-target associations or VRF import/export policies.
  5. Optionally define PIM parameters.
  6. Create a subscriber interface (applies to the 7750 SR only and is optional).
  7. Create an interface.
  8. Define SAP parameters on the interface.
    • Select nodes and ports.

    • Optionally select QoS policies other than the default (configured in config>qos context).

    • Optionally select filter policies (configured in config>filter context).

    • Optionally select accounting policy (configured in config>log context).

    • Optionally configure DHCP features. (applies to the 7450 ESS and 7750 SR)

  9. Optionally define BGP parameters.
    BGP must be enabled in the config>router>bgp context.
  10. Optionally define RIP parameters.
  11. Optionally spoke SDP parameters.
  12. Optionally create confederation autonomous systems within an AS.
  13. Enable the service.

Configuring VPRN components

This section provides VPRN configuration examples.

Creating a VPRN service

Use the following CLI syntax to create a VPRN service. A route distinguisher must be defined and the VPRN service must be administratively up in order for VPRN to be operationally active.

config>service# vprn service-id [customer customer-id]
    — route-distinguisher [ip-address:number1 | asn:number2]
    — description description-string
    — no shutdown

The following example displays a VPRN service configuration.

*A:ALA-1>config>service# info
----------------------------------------------
...
        vprn 1 customer 1 create
            route-distinguisher 10001:0
            no shutdown
        exit
...
----------------------------------------------
*A:ALA-1>config>service>vprn# 

Configuring global VPRN parameters

The following example displays a VPRN service with configured parameters.

*A:ALA-1>config>service# info
----------------------------------------------
...
        vprn 1 customer 1 create
            vrf-import "vrfImpPolCust1"
            vrf-export "vrfExpPolCust1"
            autonomous-system 10000
            route-distinguisher 10001:1
            spoke-sdp 2 create
            exit
            no shutdown
        exit
...
----------------------------------------------
*A:ALA-1>config>service# 

Configuring VPRN log parameters

The following output displays a VPRN log configuration example.

B:Dut-C>config>service>vprn# info 
----------------------------------------------
            dhcp
                local-dhcp-server "vprn_1" create
                    use-pool-from-client
                    force-renews
                    no shutdown
                exit
            exit
            snmp
                 community "YsMv96H2KZVKQeakNAq.38gvyr.MH9vA" hash2 r version both
                 community "gkYL94l90FFgu91PiRNvn3Rnl0edkMU1" hash2 rw version v2c
                 access
            log
                filter 1 
                    default-action forward
                    entry 1 
                        action forward
                    exit 
                exit 
                syslog 1
                    address 3ffe::e01:403
                    log-prefix "vprn1"
                exit 
                snmp-trap-group 32001
                    trap-target "3" address 3ffe::e01:403 port 9000 snmpv2c notify-
community "vprn1"
                exit 
                log-id 1 
                    filter 1 
                    from main change 
                    to syslog 1
                exit 
                log-id 3 
                    filter 1 
                    from main change 
                    to snmp
                exit 
            exit
...
----------------------------------------------
B:Dut-C>config>service>vprn# 
Configuring a spoke-SDP

Use the following CLI syntax to configure spoke SDP parameters:

config>service# vprn service-id [customer customer-id]
    — spoke-sdp sdp-id 
        — no shutdown
    — interface ip-int-name
        — spoke-sdp sdp-id:vc-id [vc-type {ether | vlan}]
            — egress
                — filter {ip ip-filter-id}
                — vc-label egress-vc-label
            — ingress
                — filter {ip ip-filter-id}
                — vc-label ingress-vc-label
            — tos-marking-state {trusted | untrusted}
            — no shutdown 

Use the following CLI syntax to configure spoke SDP parameters for the 7750 SR:


    — config>service# vprn service-id [customer customer-id]
    — spoke-sdp sdp-id 
        — no shutdown
    — interface ip-int-name
        — spoke-sdp sdp-id:vc-id [vc-type {ether | vlan | vpls}]
            — egress
                — filter {ip ip-filter-id}
                — vc-label egress-vc-label
            — ingress
                — filter {ip ip-filter-id}
                — vc-label ingress-vc-label
            — tos-marking-state {trusted | untrusted}
            — no shutdown 

The following output displays a spoke SDP configuration.

A:ALA-48>config>service>vprn# info
----------------------------------------------
...
            interface "SpokeSDP" create
                spoke-sdp 3:4 create
                    ingress
                        vc-label 3000
                        filter ip 10
                    exit
                    egress
                        vc-label 2000
                        filter ip 10
                    exit
                exit
            exit
...
            spoke-sdp 3 create
            exit
            no shutdown
----------------------------------------------
A:ALA-48>config>service>vprn#

Configuring VPRN protocols - PIM

The following example displays a VPRN PIM configuration for the 7750 SR:

config>service# info
#------------------------------------------
...
        vprn 1 customer 2 create
            route-distinguisher 1:11
            interface "if1" create
                address 10.13.14.15/32
                loopback
            exit
            interface "if2" create
                address 10.13.14.1/24
                sap 1/1/2:0 create
                exit
            exit
            pim
                interface "if1"
                exit
                interface "if2"
                exit
                rp
                    static
                    exit
                    bsr-candidate
                        shutdown
                    exit
                    rp-candidate
                        shutdown
                    exit
                exit
            exit
            no shutdown
        exit
    exit
#------------------------------------------
config>service#

Configuring router interfaces

See the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide for command descriptions and syntax information to configure router interfaces.

The following example displays a router interface configurations:

ALA48>config>router# info
#------------------------------------------
echo "IP Configuration"
#------------------------------------------
...
        interface "if1"
            address 10.2.2.1/24
            port 1/1/33
        exit
        interface "if2"
            address 10.49.1.46/24
            port 1/1/34
        exit
        interface "if3"
            address 10.11.11.1/24
            port 1/1/35
        exit
...
#------------------------------------------
ALA48>config>router# 
Configuring VPRN protocols - BGP

The autonomous system number and router ID configured in the VPRN context only applies to that particular service.

The minimal parameters that should be configured for a VPRN BGP instance are:

  • Specify an autonomous system number for the router. See Configuring global VPRN parameters.

  • Specify a router ID. If a new or different router ID value is entered in the BGP context, then the new values takes precedence and overwrites the VPRN-level router ID. See Configuring global VPRN parameters.

  • Specify a VPRN BGP peer group.

  • Specify a VPRN BGP neighbor with which to peer.

  • Specify a VPRN BGP peer-AS that is associated with the above peer.

VPRN BGP is administratively enabled upon creation. Minimally, to enable VPRN BGP in a VPRN instance, you must associate an autonomous system number and router ID for the VPRN service, create a peer group, neighbor, and associate a peer AS number. There are no default VPRN BGP groups or neighbors. Each VPRN BGP group and neighbor must be explicitly configured.

All parameters configured for VPRN BGP are applied to the group and are inherited by each peer, but a group parameter can be overridden on a specific basis. VPRN BGP command hierarchy consists of three levels:

  • the global level

  • the group level

  • the neighbor level

For example:

config>service>vprn>bgp#		(global level)
        — group 	(group level)
    — neighbor 					(neighbor level)

The local-address must be explicitly configured if two systems have multiple BGP peer sessions between them for the session to be established.

For more information about the BGP protocol, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide.

Configuring VPRN BGP group and neighbor parameters

A group is a collection of related VPRN BGP peers. The group name should be a descriptive name for the group. Follow your group, name, and ID naming conventions for consistency and to help when troubleshooting faults.

All parameters configured for a peer group are applied to the group and are inherited by each peer (neighbor), but a group parameter can be overridden on a specific neighbor-level basis.

After a group name is created and options are configured, neighbors can be added within the same autonomous system to create IBGP connections or neighbors in different autonomous systems to create EBGP peers. All parameters configured for the peer group level are applied to each neighbor, but a group parameter can be overridden on a specific neighbor basis.

Configuring route reflection

Route reflection can be implemented in autonomous systems with a large internal BGP mesh to reduce the number of IBGP sessions required. One or more routers can be selected to act as focal points, for internal BGP sessions. Several BGP-speaking routers can peer with a route reflector. A route reflector forms peer connections to other route reflectors. A router assumes the role as a route reflector by configuring the cluster cluster-id command. No other command is required unless you want to disable reflection to specific peers.

If you configure the cluster command at the global level, then all subordinate groups and neighbors are members of the cluster. The route reflector cluster ID is expressed in dotted-decimal notation. The ID should be a significant topology-specific value. No other command is required unless you want to disable reflection to specific peers.

If a route reflector client is fully meshed, the disable-client-reflect command can be enabled to stop the route reflector from reflecting redundant route updates to a client.

Configuring BGP confederations

A VPRN can be configured to belong to a BGP confederation. BGP confederations are one technique for reducing the degree of IBGP meshing within an AS. When the confederation command is in the configuration of a VPRN the type of BGP session formed with a VPRN BGP neighbor is determined as follows:

  • The session is of type IBGP if the peer AS is the same as the local AS.

  • The session is of type confed-EBGP if the peer AS is different than the local AS AND the peer AS is listed as one of the members in the confederation command.

  • The session is of type EBGP if the peer AS is different than the local AS AND the peer AS is not listed as one of the members in the confederation command.

VPRN BGP CLI syntax

Use the CLI syntax to configure VPRN BGP parameters.

The following example displays a VPRN BGP configuration:

*A:ALA-1>config>service# info 
----------------------------------------------
...
        vprn 1 customer 1 create
            vrf-import "vrfImpPolCust1"
            vrf-export "vrfExpPolCust1"
            ecmp 8
            autonomous-system 10000
            route-distinguisher 10001:1
            auto-bind-tunnel
                resolution filter
                resolution-filter ldp
            vrf-target target:10001:1
            interface "to-ce1" create
                address 10.1.0.1/24
                sap 1/1/10:1 create
                    ingress
                        scheduler-policy "SLA2"
                        qos 100
                    exit
                    egress
                        scheduler-policy "SLA1"
                        qos 1010
                        filter ip 6
                    exit
                exit
            exit
            static-route-entry 10.5.0.0/24   
                next-hop 10.1.1.2
            bgp
                router-id 10.0.0.1
                group "to-cel"
                    export "vprnBgpExpPolCust1"
                    peer-as 65101
                    neighbor 10.1.1.2
                    exit
                exit
            exit
            spoke-sdp 2 create
            exit
            no shutdown
        exit
...
----------------------------------------------
*A:ALA-1>config>service#
Configuring VPRN protocols - RIP

PE routers attached to a specific VPN must learn the set of addresses for each site in that VPN. There are several ways for a PE router to obtain this information, one of which is the Routing Information Protocol (RIP). RIP sends routing update messages that include entry changes to the routing table, which is updated with the new information.

RIP can be used as a PE/CE distribution technique. PE and CE routers can be configured as RIP peers, and the CE router can transmit RIP updates to inform the PE router about the set of address prefixes which are reachable at the CE router's site. When RIP is configured in the CE router, care must be taken to ensure that address prefixes from other sites (address prefixes learned by the CE router from the PE router) are never advertised to the PE router. Specifically, if a PE router receives a VPN-IPv4 route and, as a result, distributes an IPv4 route to a CE router, then that route must not be distributed back from that CE's site to a PE router (either the same router or different routers).

To enable a VPRN RIP instance, enable the RIP protocol in the config>service> >vprn>rip context of the VPRN. VPRN RIP is administratively enabled upon creation. Configuring other RIP commands and parameters is optional.

Caution: Careful planning is essential to implement commands that can affect the behavior of VPRN RIP global, group, and neighbor levels. Because the RIP commands are hierarchical, analyze the values that can disable features on a particular level.

The parameters configured at the VPRN RIP global level are inherited by the group and neighbor levels. Several hierarchical VPRN RIP commands can be modified on different levels; the most specific value is used. That is, a VPRN RIP group-specific command takes precedence over a global VPRN RIP command. A neighbor-specific command takes precedence over a global VPRN RIP and group-specific command. For example, if you modify a VPRN RIP neighbor-level command default, the new value takes precedence over VPRN RIP group- and global-level settings. VPRN RIP groups and neighbors are not created by default. Each VPRN RIP group and neighbor must be explicitly configured.

The minimal parameters that should be configured for a VPRN instance are:

  • Specify a VPRN RIP peer group.

  • Specify a VPRN RIP neighbor with which to peer.

  • Specify a VPRN RIP peer-AS that is associated with the above peer.

The VPRN RIP command hierarchy consists of three levels:

  • the global level

  • the group level

  • the neighbor level

For example:

config>service>vprn>rip#		(global level)
    — group	(group level)
        — neighbor 	(neighbor level)
VPRN RIP CLI syntax

The following example displays a VPRN RIP configuration:

*A:ALA-1>config>service# info 
----------------------------------------------
...
        vprn 1 customer 1 create
            vrf-import "vrfImpPolCust1"
            vrf-export "vrfExpPolCust1"
            ecmp 8
            autonomous-system 10000
            route-distinguisher 10001:1
            auto-bind-tunnel
                resolution filter
                resolution-filter ldp
            vrf-target target:10001:1
            interface "to-ce1" create
                address 10.1.0.1/24
                sap 1/1/10:1 create
                    ingress
                        scheduler-policy "SLA2"
                        qos 100
                    exit
                    egress
                        scheduler-policy "SLA1"
                        qos 1010
                        filter ip 6
                    exit
                exit
            exit
            static-route-entry 10.5.0.0/24 
                       next-hop 10.1.1.2
            bgp
                router-id 10.0.0.1
                group "to-cel"
                    export "vprnBgpExpPolCust1"
                    peer-as 65101
                    neighbor 10.1.1.2
                    exit
                exit
            exit
            rip
                export "vprnRipExpPolCust1"
                group "cel"
                    neighbor "to-ce1"
                    exit
                exit
            exit
            spoke-sdp 2 create
            exit
            no shutdown
        exit
...
----------------------------------------------
*A:ALA-1>config>service# info 

For more information about the RIP protocol, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide.

Configuring VPRN protocols - OSPF

Each VPN routing instance is isolated from any other VPN routing instance, and from the routing used across the backbone. OSPF can be run with any VPRN, independently of the routing protocols used in other VPRNs, or in the backbone itself. For more information about the OSPF protocol, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide.

The OSPF backbone area, area 0.0.0.0, must be contiguous and all other areas must be connected to the backbone area. The backbone distributes routing information between areas. If it is not practical to connect an area to the backbone (see Area 0.0.0.5 in OSPF areas), the area border routers (such as routers Y and Z) must be connected via a virtual link. The two area border routers form a point-to-point-like adjacency across the transit area (see Area 0.0.0.4). A virtual link can only be configured while in the area 0.0.0.0 context.

Figure 48. OSPF areas
config>service>vprn>ospf#	
VPRN OSPF CLI syntax

The following example displays the VPRN OSPF configuration shown above:

*A:ALA-48>config>service# info
----------------------------------------------
 vprn 2 customer 1 create
            interface "test" create
            exit
            no shutdown
        exit
            area 0.0.0.0
                virtual-link 1.2.3.4 transit-area 1.2.3.4
                    hello-interval 9
                    dead-interval 40
                exit
    exit
----------------------------------------------
*A:ALA-48>config>service#

For more information about the OSPF protocol, see the 7450 ESS, 7750 SR, 7950 XRS, and VSR Router Configuration Guide.

Configuring a VPRN interface

Interface names associate an IP address to the interface, and then associate the IP interface with a physical port. The logical interface can associate attributes like an IP address, port, Link Aggregation Group (LAG) or the system.

There are no default interfaces.

You can configure a VPRN interface as a loopback interface by issuing the loopback command instead of the sap sap-id command. The loopback flag cannot be set on an interface where a SAP is already defined and a SAP cannot be defined on a loopback interface.

When using mtrace or mstat in a Layer 3 VPN context then the configuration for the VPRN should have a loopback address configured which has the same address as the core instance's system address (BGP next-hop).

The following example displays a VPRN interface configuration:

*A:ALA-1>config>service>vprn# info
----------------------------------------------
...
        vprn 1 customer 1 create
            vrf-import "vrfImpPolCust1"
            vrf-export "vrfExpPolCust1"
            ecmp 8
            autonomous-system 10000
            route-distinguisher 10001:1
            auto-bind-tunnel
                resolution filter
                resolution-filter ldp
            vrf-target target:10001:1
            interface "to-ce1" create
                address 10.1.0.1/24
                exit
            exit
            static-route-entry 10.5.0.0/24 
                next-hop 10.1.1.2
            spoke-sdp 2 create
            exit
            no shutdown
        exit
...
----------------------------------------------
*A:ALA-1>config>service#
Configuring overload state on a single SFM

When a router has fewer than the full set of SFMs functioning, the forwarding capacity can be reduced. Some scenarios include:

  • fewer than the maximum number of SFMs installed in the system

  • one or more SFMs have failed

  • the system is in the ISSU process and the SFM is co-located on the CPM

An overload condition can be set for IS-IS and OSPF to enable the router to still participate in exchanging routing information, but route all traffic away from it when insufficient SFMs are active. This is achieved using the following CLI commands:

config>router>single-sfm-overload [holdoff-time hold-off-time]
    config>service>vprn>single-sfm-overload [holdoff-time hold-off-time]
    tools>perform>redundancy>forced-single-sfm-overload

These cause an overload state in the IGP to trigger the traffic reroute by setting the overload bit in IS-IS or setting the metric to maximum in OSPF. When PIM uses IS-IS or OSPF to find out the upstream router, a next-hop change in the IS-IS or OSPF causes PIM to join the new path and prune the old path, which effectively also reroutes the multicast traffic downstream as well as the unicast traffic.

When the problem is resolved, and the required compliment of SFMs become active in the router, the overload condition is cleared, which causes the traffic to be routed back to the router.

The conditions to set overload are:

  • For 7950 XRS-20, 7750 SR-12/SR-7 and 7450 ESS-12/ESS-7 platforms, if an SF/CPM fails, the protocol sets the overload.

  • For 7950-40 XRS and 7750 SR-12e platforms, if two SFMs fail (a connected pair on the XRS-40) the protocol sets the overload.

Configuring a VPRN interface SAP

A SAP is a combination of a port and encapsulation parameters which identifies the service access point on the interface and within the SR. Each SAP must be unique within a router. A SAP cannot be defined if the interface loopback command is enabled.

When configuring VPRN interface SAP parameters, a default QoS policy is applied to each ingress and egress SAP. Additional QoS policies and scheduler policies must be configured in the config>qos context. Filter policies are configured in the config>filter context and must be explicitly applied to a SAP. There are no default filter policies.

The following example displays a VPRN interface SAP configuration:

*A:ALA-1>config>service# info
----------------------------------------------
...
        vprn 1 customer 1 create
            vrf-import "vrfImpPolCust1"
            vrf-export "vrfExpPolCust1"
            ecmp 8
            autonomous-system 10000
            route-distinguisher 10001:1
            auto-bind-tunnel
                resolution filter
                resolution-filter ldp
            vrf-target target:10001:1
            interface "to-ce1" create
                address 10.1.0.1/24
                sap 1/1/10:1 create
                    ingress
                        scheduler-policy "SLA2"
                        qos 100
                    exit
                    egress
                        scheduler-policy "SLA1"
                        qos 1010
                        filter ip 6
                    exit
                exit
            exit
            static-route-entry 10.5.0.0/24 
                next-hop 10.1.1.2
            spoke-sdp 2 create
            exit
            no shutdown
        exit
...
----------------------------------------------
*A:ALA-1>config>service#

Service management tasks

This section discusses VPRN service management tasks.

Modifying VPRN service parameters

Use the CLI syntax to modify VPRN parameters. The following example displays the VPRN service creation output.

*A:ALA-1>config>service# info
----------------------------------------------
...
vprn 1 customer 1 create
            shutdown
            vrf-import "vrfImpPolCust1"
            vrf-export "vrfExpPolCust1"
            ecmp 8
            maximum-routes 2000
            autonomous-system 10000
            route-distinguisher 10001:1
            interface "to-ce1" create
                address 10.1.1.1/24
                sap 1/1/10:1 create
                exit
            exit
            static-route-entry 10.5.0.0/24 
                next-hop 10.1.1.2
            bgp
                router-id 10.0.0.1
                group "to-ce1"
                    export "vprnBgpExpPolCust1"
                    peer-as 65101
                    neighbor 10.1.1.2
                    exit
                exit
            exit
            spoke-sdp 2 create
            exit
        exit
...
----------------------------------------------
*A:ALA-1>config>service>vprn#

Deleting a VPRN service

A VPRN service cannot be deleted until SAPs and interfaces are shut down and deleted. If protocols or a spoke-SDP, or both are defined, they must be shut down and removed from the configuration as well.

Use the following CLI syntax to delete a VPRN service:

config>service#
    — [no] vprn service-id [customer customer-id]
        — shutdown
        — [no] interface ip-int-name
            — shutdown
            — [no] sap sap-id]
        — [no] bgp
            — shutdown
        — [no] rip
            — shutdown
        — [no] spoke-sdp sdp-id 
            — [no] shutdown

Disabling a VPRN service

A VPRN service can be shut down without deleting any service parameters.

config>service#
    — vprn service-id [customer customer-id]
        — shutdown
config>service# vprn 1
    — config>service>vprn# shutdown
    — config>service>vprn# exit
*A:ALA-1>config>service# info
----------------------------------------------
...
        vprn 1 customer 1 create
            shutdown
            vrf-import "vrfImpPolCust1"
            vrf-export "vrfExpPolCust1"
            ecmp 8
            autonomous-system 10000
            route-distinguisher 10001:1
            auto-bind-tunnel
                resolution filter
                resolution-filter ldp
            vrf-target target:10001:1
            interface "to-ce1" create
                address 10.1.0.1/24
                sap 1/1/10:1 create
                    ingress
                        scheduler-policy "SLA2"
                        qos 100
                    exit
                    egress
                        scheduler-policy "SLA1"
                        qos 1010
                        filter ip 6
                    exit
                exit
            exit
            static-route-entry 10.5.0.0/24 
                next-hop 10.1.1.2
            bgp
                router-id 10.0.0.1
                group "to-cel"
                    export "vprnBgpExpPolCust1"
                    peer-as 65101
                    neighbor 10.1.1.2
                    exit
                exit
            exit
            rip
                export "vprnRipExpPolCust1"
                group "cel"
                    neighbor "to-ce1"
                    exit
                exit
            exit
            spoke-sdp 2 create
            exit
        exit
...
----------------------------------------------
*A:ALA-1>config>service#

Re-enabling a VPRN service

To re-enable a VPRN service that was shut down.

config>service#
    — vprn service-id [customer customer-id]
        — no shutdown
        —