6.1.1. Routing Prerequisites

RFC2547bis requires the following features:

Tunneling protocol options are as follows:

6.1.2. BGP Support

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

BGP was initially designed to distribute IPv4 routing information. Therefore, multi-protocol extensions and the use of a VPN-IPv4 address were created to extend ability of the BGP 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. The RD must be unique within the scope of the VPRN. This allows the IP address prefixes within different VRFs to overlap.

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.

6.1.3. Route Distinguishers

The route distinguisher (RD) is an 8-byte value consisting of 2 major fields, the Type field and Value field, as shown in Figure 54. The Type field determines how the Value field should be interpreted. The 7210 SAS implementation supports the three (3) Type values as defined in the Internet draft.

Figure 54:  Route Distinguisher 

The three Type values are:

6.1.3.2. CE to PE Route Exchange

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

1. Static Routes (with both IPv4 and IPv6)
2. E-BGP (with both IPv4 and IPv6 VPNs)

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

6.1.3.2.1. 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 certain 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.

6.1.3.2.2. CPE Connectivity Check

Static routes are used within many IES 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 will be removed from the VPRN routing tables dynamically and minimize wasted bandwidth.

Figure 55 and Figure 56 show static routes.

Figure 55:  Directly Connected IP Target 

Figure 56:  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 de-activated, the 7210 SAS router will continue to send polls and reactivate any routes that are restored.

6.1.4. BGP Fast Reroute in a VPRN

BGP fast reroute is a feature that brings together indirection techniques in the forwarding plane and precomputation 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 VPN-IPv4 and VPN-IPv6 VPN routes. The supported VPRN scenarios are described in Table 84.

6.1.4.1. BGP Fast Reroute in a VPRN Configuration

Configuring the enable-bgp-vpn-backup command under config>service>vprn causes only imported BGP-VPN routes to be considered when selecting the primary and backup paths.

This command is required to support fast failover of ingress traffic from one remote PE to another remote PE.

Note: 7210 SAS devices do not support BGP backup path command that is used to enable consideration of multiple paths learned from CE BGP peers when selecting primary and backup path to reach the CE.

6.2.1. 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:

Configuration options found on core IP interfaces not supported on VPRN IP interfaces are:

6.2.2. 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:

Configuration options found on core IP interfaces not supported on VPRN IP interfaces are:

6.2.3. SAPs

This section provides information about SAPs.

6.2.4. QoS Policies

When applied to a VPRN SAP, service ingress QoS policies only create the unicast queues defined in the policy (as multicast is not supported in VPRN service).

Multicast is not supported in VPRN service.

Both Layer 2 (dot1p only) or Layer 3 criteria can be used in the QoS policies for traffic classification in an VPRN.

6.2.5. Filter Policies

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

6.2.5.1. CPU QoS for VPRN Interfaces

Traffic bound to CPU received on VPRN access interfaces are policed/rate-limited and queued into CPU queues. The software allocates a policer per IP application or a set of IP applications, for rate-limiting CPU bound IP traffic from all VPRN access SAPs. The policers CIR/PIR values are set to appropriate values based on feature scaling and these values are not user configurable. The software allocates a set of queues for CPU bound IP traffic from all VPRN access SAPs. The queues are either shared by a set of IP applications or in some cases allocated to an IP application. The queues are shaped to appropriate rate based on feature scaling. The shaper rate is not user-configurable.

Note: The instance of queues and policers used for traffic received on network port IP interfaces is different for traffic received from access port IP interfaces. Additionally, the network CPU queues receive higher priority than the access CPU queues, which provides better security and mitigates the risk of access traffic affecting the network side. On the 7210 SAS-R6, the user can configure the IP DSCP value for self-generated traffic.

6.2.6. CE to PE Routing Protocols

The 7210 SAS VPRN supports the following PE to CE routing protocols:

6.2.7. Exporting MP-BGP VPN Routes

To reduce the number of MP-BGP VPN tunnels in a group of IP/MPLS PE routers that are part of the same L3 VPN instance, a hierarchy can be established by reexporting the VPN IP routes on a PE aggregation router (which can be an ABR node). In the case of VPRN service labels, reexporting VPN IP routes reduces the required MPLS FIB resources to the scale available on smaller access routers.

Use the config>service>vprn>allow-export-bgp-vpn command to configure the feature. This command enables the vrf-export and vrf-target export functions to include BGP-VPN routes that are installed in the VPRN route table.

When a route is installed in the VPRN route table, the route is exported as a new VPN-IP route to an MP-IBGP peer only; that is, the route is accepted by the VRF export policy but may be rejected by a BGP export policy. Assuming that the export policies have simple accept and reject actions, the new VPN-IP route is the same as the original VPN-IP route, except in the following cases.

6.2.8. Spoke SDPs

Spoke-SDP termination into a Layer 3 service is not supported on 7210 SAS platforms.

Distributed services use service distribution points (SDPs) to direct traffic to another SR-Series router via service tunnels. SDPs are created on each participating SR-Series and then bound to a specific service. SDP can be created as either GRE or MPLS. Refer to SDPs 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 not access QoS policies.

Figure 57 shows 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 57:  SDP-ID and VC Label Service Identifiers 

Figure 58 shows a spoke-SDP terminating directly into an IES. In this case, a spoke-SDP could be tied to an Epipe or H-VPLS service. There is no configuration required on the PE connected to the CE.

Figure 58:  Spoke-SDP Termination 

Note that all the routing protocols, including multicast, that are supported by VPRN are supported for spoke-sdp termination.

6.2.8.1. 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 Figure 59.

Figure 59:  Active/Standby VRF Using Resilient L2 Circuits 

6.2.8.3. 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 Figure 59, using either epipe or ipipe spoke-SDPs.

In Figure 59, 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.

Note that 7210 routers are expected to fulfill both functions (VLL and VPRN/IES PE). Figure 60 shows the model for spoke-SDP redundancy into a VPRN or IES.

Figure 60:  Spoke-SDP Redundancy Model  

6.2.9. Using OSPF in IP-VPNs

Note: OSPF as a PE-CE routing protocol is only supported for IPv4 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:

6.2.10. Service Label Mode of a VPRN

The 7210 SAS allocates one unique (platform-wide) service label per VRF. All VPN-IP routes exported by the PE from a particular VPRN service with that configuration have the same service label. When the PE receives a terminating MPLS packet, the service label value determines the VRF to which the packet belongs. A lookup of the IP packet DA in the forwarding table of the selected VRF determines the next-hop interface.

6.2.11. Multicast in IP-VPN Applications

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.

Figure 61 depicts an example of multicast in an IP-VPN application. The provider 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). In this VPRN example, the VPN-1 data generated by the customer behind router 16 is multicast only by PE router 9 to PE routers 6 and 7 for delivery to CE routers 12 and 13 respectively. Data for VPN-2 generated by the customer behind router 15 is forwarded by PE router 8 to PE routers 5, 7 and 10 for delivery to CE routers 18, 11, 14 and 17 respectively.

Figure 61:  Multicast in IP-VPN Applications 

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

The PE for a specific customer multicast domain becomes adjacent to the CE routers attached to that PE and to all other PE that participate in the IP-VPN (or customer) multicast domain. This is achieved by the PE, which encapsulates the customer multicast control data and multicast streams inside the provider multicast packets. These encapsulated packets are forwarded only to the PE nodes that are participating in the same MVPN domain and are part of the same customer VPRN. This prunes the distribution of the multicast control and data traffic to the PEs that do not participate in the customer multicast domain.

Note: To enable ingress FC classification for packets received on a P2MP LSP on a network port IP interface and that needs to be replicated to IP receivers, use the loopback-no-svc-port>p2mpbud>p2mpbud-port-id>p2mp-bud-classification command. This command is required only on the 7210 SAS-R6 and 7210 SAS-R12 for ingress FC classification; for other platforms, this is not required.This command allows users to prioritize multicast traffic to IP receivers in the service. In addition, this command marks the packet with IP DSCP values while sending the multicast stream out of the IP interface. Before using the command, users must ensure that sufficient resources are available in the network ingress CAM resource pool and MPLS EXP ingress profile map resource pool. Use the tools>dump>system-resources command to check resource availability.

6.2.12. 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).

NOTE: 7210 SAS platforms support only option-A and option-C. It does not support option-B. It described as follows only for the sake of completeness.

The first option, referred to as Option-A (Figure 62), 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 62:  Inter-AS Option-A: VRF-to-VRF Model 

The second option, referred to as Option-B (Figure 63), 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 iBGP either directly or through route reflectors.

This means the ASBRs receive all the VPRN information and will 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 will in turn forward those updates to all local IBGP peers.

Figure 63:  Inter-AS Option-B 

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.

The third option, referred to as Option-C (Figure 64), 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 perform any additional functions then in a non-Inter-AS VPRN.

Figure 64:  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 system IP addresses only. This is done between the ASBRs by exchanging MP-eBGP labeled routes, using RFC 3107, Carrying Label Information in BGP-4.

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.