7.1.1. Routing Prerequisites

RFC2547bis requires the following features:

Tunneling protocol options are as follows:

7.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 BGP 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. 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.

7.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 73. 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 73:  Route Distinguisher 

The three Type values are:

7.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)
3. OSPF (v2 IPv4)

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

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

7.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 74 and Figure 75 show static routes.

Figure 74:  Directly Connected IP Target 

Figure 75:  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.

7.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 109.

7.1.4.1. BGP Fast Reroute in a VPRN Configuration

Configuring the config>service>vprn>enable-bgp-vpn-backup command 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 platforms do not support BGP backup path commands that are used to enable consideration of multiple paths learned from CE BGP peers when selecting primary and backup paths to reach the CE.

7.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 that are not supported on VPRN IP interfaces are:

7.2.1.1. DHCP and DHCPv6

Note: Unless otherwise stated, DHCP is equivalent to “DHCP for IPv4,” or DHCPv4.

The DHCP protocol is used to communicate network information and configuration parameters from a DHCP server to a DHCP-aware client. DHCP is based on the BOOTP protocol, with additional configuration options and the capability to allocate dynamic network addresses. DHCP devices are also capable of handling BOOTP messages.

A DHCP client is an IP-capable device (typically a computer or base station) that uses DHCP to obtain configuration parameters, such as a network address. A DHCP server is an Internet host or router that returns configuration parameters to DHCP clients. A DHCP relay agent is a host or router that passes DHCP messages between clients and servers.

DHCPv6 is not based on, and does not use, the BOOTP protocol.

Service providers use the DHCP protocol to assign IP addresses and provide other configuration parameters.

IP routers do not forward broadcast or multicast packets, which might suggest that the DHCP client and server must reside on the same IP network segment. However, this configuration is not required because when the 7210 SAS is acting as a DHCP relay agent, it processes these DHCP broadcast or multicast packets and relays them to a preconfigured DHCP server. As a result, DHCP clients and servers do not need to reside on the same IP network segment.

For DHCP relay, the 7210 SAS supports a maximum of eight DHCP servers for each VPRN or IES instance and eight DHCP servers for each node.

For DHCPv6 relay, the 7210 SAS supports a maximum of eight DHCPv6 servers for each VPRN instance and eight DHCPv6 servers for each node.

7.2.1.1.1. DHCP Relay and DHCPv6 Relay

The 7210 SAS provides DHCP relay agent services and DHCPv6 relay agent services for DHCP clients. DHCP is used for IPv4 network addresses and DHCPv6 is used for IPv6 network addresses. Both DHCP and DHCPv6 are known as stateful protocols because they use dedicated servers to maintain parameter information.

In the stateful autoconfiguration model, hosts obtain interface addresses and configuration information and parameters from a server. The server maintains a database that tracks which addresses are assigned to which hosts.

Note: The 7210 SAS acts as a relay agent for DHCP and DHCPv6 requests and responses. DHCPv6 functionality is only supported on VPRN access IP interfaces.

7.2.1.1.1.1. DHCP Relay

The 7210 SAS provides DHCP relay agent services for DHCP clients.

Service providers use the DHCP protocol to assign IP addresses and provide other configuration parameters. The DHCP protocol requires the client to transmit a request packet with a destination broadcast address of 255.255.255.255, which is processed by the DHCP server.

When the 7210 SAS is acting as a DHCP relay agent, it processes DHCP broadcast packets and relays them to a preconfigured DHCP server, ensuring that DHCP clients and servers do not need to reside on the same network segment.

DHCP offer messages are not dropped if they contain a giaddr that does not match the local configured subnets on the DHCP relay interface.

7.2.1.1.1.1.1. DHCP Options

DHCP options are codes that the 7210 SAS inserts in packets being forwarded from a DHCP client to a DHCP server. Some options have additional information stored in suboptions.

The 7210 SAS supports the Relay Agent Information Option 82, as described in RFC 3046. The following suboptions are supported:

1. circuit ID
2. remote ID
3. vendor-specific options

7.2.1.1.1.2. DHCPv6 Relay

Note: DHCPv6 relay is only supported on 7210 SAS-Mxp.

DHCPv6 relay operation is similar to DHCP in that servers send configuration parameters, such as IPv6 network addresses, to IPv6 nodes; however, DHCPv6 relay is not based on the DHCP or BOOTP protocol. DHCPv6 can be used instead of, or in conjunction with, stateless autoconfiguration.

DHCPv6 uses IPv6 methods of addressing, especially the use of reserved, link-local scoped multicast addresses. DHCPv6 clients transmit messages to these reserved addresses, allowing messages to be sent without the client knowing the address of any DHCP server. This transmission allows efficient communication even before a client is assigned an IP address. When a client has an address and knows the identity of a server, the client can communicate with the server directly using unicast addressing.

The DHCPv6 protocol requires the client to transmit a request packet with a destination multicast address of ff02::1:2 (which addresses all DHCP servers and relay agents on the local network segment) that is processed by the DHCP server.

Similar to DHCP address allocation, if a client needs to obtain an IPv6 address and other configuration parameters, it sends a Solicit message to locate a DHCPv6 server, then requests an address assignment and other configuration information from the server. Servers that meet the requirements of the client respond with an Advertise message. The client chooses one of the servers and sends a Request message; the server sends back a Reply message with the confirmed IPv6 address and configuration information.

If the client already has an IPv6 address, either assigned manually or obtained in another way, the client only needs to obtain configuration information. In this case, exchanges are done using a two-message process. The client sends a Request message for only configuration information. A DHCPv6 server that has configuration information for the client sends back a Reply message with the information.

The 7210 SAS supports the DHCPv6 relay agent option in the same way that it supports the DHCP relay agent option: when the 7210 SAS is acting as a DHCPv6 relay agent, it relays messages between clients and servers that are not connected to the same link.

The DHCP relay agent uses one of its interfaces as an IP source address in the DHCP relay-forward message. The DHCPv6 server uses the same source IP address as the destination IP address in the DHCP relay-reply message. There are restrictions for the source IP address used by the DHCP relay agent, which depend on whether the relay agent is a few hops away or is directly connected.

In the case where the relay agent is a few hops away from the DHCPv6 server, the source address used by the relay agent must not fall under the subnet or prefix range configured on the IP interface on which the client is connected. For example, the loopback interface address of the DHCP relay agent can be used instead. To forward the DHCPv6 relay-reply message back to the relay agent, add a static route for the relay agent source IP address.

In the case where the relay agent is directly connected, there are two options. In the first option, the relay agent use the address of the directly connected interface as the relay-forward source address, and no additional configuration is required for the DHCP server to forward the relay-reply message back to the relay-agent. The other option is to use an interface address on the relay agent that does not fall under the subnet or prefix range configured on the IP interface on which the client is connected. Similar to the scenario where the relay-agent is a few hops away, a static route is required to forward the DHCP relay-reply message back to the relay agent.

7.2.1.1.1.2.1. DHCPv6 Options

DHCPv6 options are codes that the 7210 SAS inserts in packets being forwarded from a DHCPv6 client to a DHCPv6 server. DHCPv6 supports interface ID and remote ID options, as described in RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPV6) and RFC 4649, DHCPv6 Relay Agent Remote-ID Option.

7.2.2. SAPs

7.2.2.1. IPv6 Support for VPRN IP Interfaces

Note: IPv6 VPRN IP interfaces are supported on all 7210 SAS platforms as described in this document, except those operating in access-uplink mode.

VPRN IPv6 access interfaces are allowed to be configured to provide IPv6 VPN connectivity to customers.

IPv4 and IPv6 route table lookup entries are shared. Before adding routes for IPv6 destinations, route entries in the routed lookup table needs to be allocated for IPv6 addresses. This can be done using the CLI config system resource-profile router max-ipv6-routes command. This command allocates route entries for /64 IPv6 prefix route lookups. The system does not allocate any IPv6 route entries by default and user needs to allocate some resources before using IPv6. For the command to take effect the node must be rebooted after making the change. For more information, see the following example and refer to the 7210 SAS-M, T, R6, R12, Mxp, Sx, S Basic System Configuration Guide.

A separate route table (or a block in the route table) is used for IPv6 /128-bit prefix route lookup. A limited amount of IPv6 /128 prefixes route lookup entries is supported. The software enables lookups in this table by default (that is no user configuration is required to enable Ipv6 /128-bit route lookup).

In addition, the number IP subnets can be configured by the user using the configure system resource-profile router max-ip-subnets command. Suitable defaults are assigned to this parameter. Users can increase the number of subnets if they plan to add more IPv6 addresses for eachIPv6 interface.

Following features and restrictions is applicable for IPv6 VPRN IP interfaces:

1. PE-CE routing - static routing and EBGP is supported.
2. A limited amount of IPv6 /128 prefixes route lookup entries is supported on 7210 SAS platforms.
3. VRRP for VPRN IPv6 interfaces is not supported.

7.2.3. QoS Policies

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

For 7210 SAS-Sx/S 1/10GE, 7210 SAS-Sx 10/100GE, 7210 SAS-M (network mode), and 7210 SAS-T (network mode) (with VPRN services), access egress policies are available for use on access ports. On 7210 SAS-Mxp Service egress QoS policies are supported.

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

7.2.4. Filter Policies

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

7.2.4.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 are accorded higher priority than the access CPU queues. This is done to provide better security and mitigate the risk of access traffic affecting network traffic. The 7210 SAS-Mxp allows the user to configure the IP differentiated services code point (DSCP) value for self-generated traffic. On the 7210 SAS-M, 7210 SAS-T, 7210 SAS-Sx/S 1/10GE, and 7210 SAS-Sx 10/100GE, IP DSCP marking of self-generated traffic is not user-configurable and is assigned by software.

7.2.5. CE to PE Routing Protocols

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

Note: OSPFv2 used as a PE-CE protocol is supported on all 7210 SAS platforms as described in this document, except the 7210 SAS-M.

7.2.6. 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.

7.2.7. Spoke-SDPs

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

7.2.8. Using OSPF in IP-VPNs

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

7.2.9. 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.

7.2.10. Multicast in IP-VPN Applications

Note: Multicast in IP-VPN services using NG-MVPN mechanisms is supported on the 7210 SAS-T, 7210 SAS-Mxp, 7210 SAS-Sx 1/10GE operating in the standalone mode, and 7210 SAS-S 1/10GE operating in the standalone-VC mode.

Applications for this feature include enterprise customers 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 76 shows 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 76:  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 router for a specific customer multicast domain becomes adjacent to the CE routers attached to that PE and to all other PE routers that participate in the IP-VPN (or customer) multicast domain. This is achieved by the PE router, which encapsulates the customer multicast control data and multicast streams inside the provider multicast packets. These encapsulated packets are forwarded only to the PE routers 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 PE routers that do not participate in the customer multicast domain.

7.2.11. 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. Option-B is not supported and is included in this description only for completeness.

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

The second option, referred to as Option-B (Figure 78), 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 78:  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 79), 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 79:  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.