Routing Prerequisites

RFC 2547bis requires the following features:

Tunneling protocol requirements are as follows:

BGP Support

BGP is used with BGP extensions, as 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, multiprotocol extensions and the use of a VPN-IPv4 address were created to extend the ability of 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. In addition, 128-bit VPN-IPv6 addresses extend the capability to distribute VPRN routing information.

BGP route tunnels can be used to distribute label mapping information for a particular route, as defined in RFC 3107. For more information on BGP route tunnels, refer to the 7705 SAR OS Routing Protocols Guide, “BGP Route Tunnel”.

Note: The 7705 SAR supports 4-byte AS numbers, as defined in RFC 4893, BGP Support for Four-octet AS Number Space. This allows up to 4 294 967 295 unique AS numbers.

BGP is configured through the config>service>vprn>bgp context.

IPSec Support

The 7705 SAR supports IPSec and IPSec tunnels, where IES or VPRN is used as a public (untrusted) network-facing service and VPRN is used as a private (trusted) network-facing service. VPRN interfaces support provisioning of tunnel SAPs as part of IPSec provisioning. The sap-id for a VPRN tunnel SAP is tunnel-1.private:tag.

For more information, see the IPSec chapter in this guide.

Security Zones and VPRN

The 7705 SAR supports a number of mechanisms for node security, including Access Control Lists (ACLs), Network Address Translation (NAT), and stateful, zone-based firewalls. For information about ACLs, NAT, and firewalls, refer to the 7705 SAR OS Router Configuration Guide, “Configuring Security Parameters”.

NAT and firewall security configurations are both based on zones. Zones segment a network, making it easier to control and organize traffic. A zone consists of a group of Layer 3 interfaces with common criteria, bundled together. Security policies, which define a set of rules that determine how NAT or firewall should direct traffic, can be applied to the entire zone or to multiple zones. To enable NAT or firewall functionality, security policy, application group, host group, and profile parameters must be configured under the config>security context in the CLI, and a security zone must be configured under one or more of the following contexts:

A zone is created by adding at least one Layer 3 interface to the zone configuration. Multiple zones can be created within each service context or within the router context. Layer 3 interfaces from different services cannot be grouped into a single common zone. Table 101 lists the supported interfaces that can be added to zones in each CLI context for NAT or firewall.

A zone configured in the VPRN context could be used to create border security for Layer 3 service traffic traversing from the secure edge VPRN into the network core.

Figure 94 shows a firewall on a VPRN, where the core of the network is protected from access devices and from any traffic entering the VPRN through the transport tunnel. A VPRN configured with access security policies can also protect access networks or LANs from each other.

Figure 94:  Firewall Protection for the Network Core 

A security zone can also be created with spoke SDPs or auto-bind tunnels that have been configured for a VPRN service using MP-BGP. The auto-bind tunnels can be MPLS, LDP, or GRE. When a zone contains spoke SDPs or auto-bind MPLS tunnels, it cannot contain any other type of interface. A zone configured with spoke SDPs or auto-bind MPLS tunnels will firewall traffic arriving from the access side to this zone for any MP-BGP transport tunnel residing in that Layer 3 service. Once a security zone is created for MP-BGP transport tunnels, all MP-BGP transport tunnels going to far-end peers are part of this zone. Traffic entering or exiting the zone is firewalled; however, traffic traveling from one auto-bind tunnel to another within the same zone is not firewalled.

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 7705 SAR OS implementation supports the three (3) Type-Value combinations, as defined in RFC 2547bis. Figure 95 illustrates the RD structure.

Figure 95:  Route Distinguisher Structure 

The three Type-Value combinations supported are described in Table 102.

PE-to-CE Route Exchange

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

1. EBGP
2. OSPF
3. RIP
4. static routes

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

Route Redistribution

Routing information learned from the PE-to-CE routing protocols and configured static routes is injected into the associated local virtual routing and forwarding table (VRF). In the case of the 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 the PE-to-CE routing protocols is 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.

A route belonging to a VPRN must use the protocol owner, VPN-IPv4, to denote that it is a VPRN route. This can be used within the route policy match criteria.

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 are removed from the service provider’s routing tables dynamically, and wasted bandwidth is minimized.

Figure 96 and Figure 97 illustrate the use of CPE connectivity check in directly connected and multiple-hop connected routes.

Figure 96:  Directly Connected IP Target 

Figure 97:  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 7705 SAR router will continue to send polls and reactivate any routes that are restored.

In-Band Management using a VPRN

VPRN in-band management is supported on the 7705 SAR. In-band management of the 7705 SAR is performed using the global routing table (GRT) to perform a lookup on the system IP address of the 7705 SAR.

On network ingress, when a packet arrives from the transport tunnel to the VPRN, a lookup is performed within the VPRN on the inner customer packet IP header. If the destination IP address in the packet header matches that of the local 7705 SAR system IP address, and the command enable-grt-local-management-only is enabled under the VPRN instance, then the packet is extracted to the CSM for processing. If the enable-grt-local-management-only command is not enabled, the packet is routed using the corresponding 7705 SAR VRF FIB.

If the 7705 SAR system IP address is the same as any local IP address within the VPRN and the arriving packet destination IP matches this address, the packet is extracted to the CSM for processing only if the enable-grt-local-management-only command is enabled. Any ICMP packet destined for local interfaces will be processed by the system IP. If the local interface is operationally down, the system IP will still reply to ICMP packets successfully. Having a single IP address shared by the system IP and VPRN local interface is not recommended because some GRT-supported management protocols, such as Telnet and SSH, will not function with this configuration.

For MP-BGP VPRNs, the system IP address can be advertised to the far-end node using a static route whose next hop is configured as black-hole. If the command enable-grt-local-management-only is enabled under the VPRN instance, a packet arriving on a transport tunnel will be extracted to the CSM before hitting the black-hole route. In this case, the only effect of the black-hole route will be to advertise the system IP address to the far-end peer. If the command enable-grt-local-management-only is not enabled, packet forwarding will be the default forwarding mode; that is, all packets destined for the system IP address will be black-holed because of the static route configuration.

For MP-BGP VPRNs, when the command enable-grt-local-management-only is enabled, at least one interface (such as a loopback interface) must be configured on the VPRN and have an operational status of Up.

On network egress, the packets generated from the CSM with a source IP address that matches the 7705 SAR system IP address and destination IP address of either the far-end 5620 SAM or other management entity must perform a GRT route lookup in order to be resolved. A route policy can be configured with an IP address prefix of the far-end management entity and with the action to accept. This policy is configured for the GRT under the config>router>policy-options context and is installed in the GRT RIB (not the FIB) using the export-grt-rib-only command. The route installed in the GRT RIB will have a next hop of the corresponding VRF tunnel. This prevents any user data traffic in the GRT data path from leaking into the VPRN, and ensures that only the management traffic originating from the system IP address and the CSM gets transported through the VPRN. This forces the management packet to get routed by the corresponding VPRN transport tunnel, which means the VPRN route is leaked into the GRT so the GRT resolves the route using the corresponding VPRN.

Table 103 lists the management protocols supported by IPv4 and IPv6 GRT in the reverse and forward directions.

Figure 98 shows an example of IPv4 in-band management of the 7705 SAR and the switches behind it by the 5620 SAM and a TACACS+ server. In the example, an IPSec tunnel is being used as the VPRN in order to transport the management traffic via a secure and encrypted medium over the public internet.

Figure 98:  IPv4 In-Band Management Using a VPRN Configured with GRT Lookup  

In this example, the 7705 SAR system IP address is in the same subnet as the local interface; that is, subnet 192.168.0.x.

On network ingress in the above example, when enable-grt-local-management-only is configured for the VPRN, packets arriving on the 192.168.0 subnet are treated as follows.

On network egress in the above example, routing is as follows.

Figure 99 shows an example of IPv6 in-band management of the 7705 SAR and the switches behind it by the 5620 SAM and a TACACS+ server.

Figure 99:  IPv6 In-Band Management Using a VPRN Configured with GRT Lookup  

On network ingress in the above example, the 7705 SAR system IP address is in the same subnet as the local interface IPv6 VPRN address. When enable-grt-local-management-only is configured for the IPv6 VPRN, packets arriving on the fd00:1:1:1 subnet are treated as follows.

On network egress in the above example, routing is as follows.

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:

DHCP and DHCPv6

DHCP is a configuration protocol 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 added capability of allocating dynamic network addresses. DHCP-capable 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/BOOTP 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.

The 7705 SAR can act as a DHCP client, a DHCP or DHCPv6 Relay agent, or a local DHCP or DHCPv6 server.

Home computers in a residential high-speed Internet application typically use the DHCP protocol to have their IP address assigned by their Internet service provider.

Since IP routers do not forward broadcast or multicast packets, this would suggest that the DHCP client and server must reside on the same network segment. However, for various reasons, it is sometimes impractical to have the server and client reside in the same IP network.

When the 7705 SAR is acting as a DHCP Relay agent, it processes these DHCP broadcast or multicast packets and relays them to a preconfigured DHCP server. Therefore, DHCP clients and servers do not need to reside on the same network segment.

When the 7705 SAR is acting as a local DHCP server, it processes these DHCP broadcast or multicast packets and allocates IP addresses for the DHCP client as needed.

The 7705 SAR supports a maximum of 16 servers per node on the 7705 SAR-8 with a CSMv1, and on the 7705 SAR-A, 7705 SAR-F, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-M, 7705 SAR-W, 7705 SAR-Wx, and 7705 SAR-X. The 7705 SAR supports a maximum of 62 servers per node on the 7705 SAR-8 with a CSMv2 and on the 7705 SAR-18. Any Layer 3 interface configured using the global routing table or Layer 3 services supports up to 8 servers.

DHCP Relay and DHCPv6 Relay

The 7705 SAR provides DHCP/BOOTP 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.

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

In the stateful autoconfiguration model, hosts obtain interface addresses and/or configuration information and parameters from a server. The server maintains a database that keeps track of which addresses have been assigned to which hosts.

The 7705 SAR supports DHCP Relay on access IP interfaces associated with IES and VPRN and on network interfaces. Each DHCP instance supports up to eight DHCP servers.

The 7705 SAR supports DHCPv6 Relay on access IP interfaces associated with IES and VPRN. Each DHCPv6 instance supports up to eight DHCPv6 servers.

Note: The 7705 SAR acts as a Relay agent for DHCP and DHCPv6 requests and responses, and can also be configured to function as a DHCP or DHCPv6 server. DHCPv6 functionality is only supported on network interfaces and on access IP interfaces associated with VPRN. When used as a CPE, the 7705 SAR can act as a DHCP client to learn the IP address of the network interface. Dynamic IP address allocation is supported on both network and system interfaces. For more information on DHCP and DHCPv6, refer to the 7705 SAR OS Router Configuration Guide, “DHCP and DHCPv6”.

DHCP Relay

The 7705 SAR provides DHCP/BOOTP Relay agent services for DHCP clients. DHCP is a configuration protocol 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 added capability of allocating dynamic network addresses. DHCP-capable 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/BOOTP Relay agent is a host or router that passes DHCP messages between clients and servers.

Home computers in a residential high-speed Internet application typically use the DHCP protocol to have their IP address assigned by their Internet service provider.

The DHCP protocol requires the client to transmit a request packet with a destination broadcast address of 255.255.255.255 that is processed by the DHCP server. Since IP routers do not forward broadcast packets, this would suggest that the DHCP client and server must reside on the same network segment. However, for various reasons, it is sometimes impractical to have the server and client reside in the same IP network. When the 7705 SAR is acting as a DHCP Relay agent, it processes these DHCP broadcast packets and relays them to a preconfigured DHCP server. Therefore, DHCP clients and servers do not need to reside on the same network segment.

DHCP OFFER messages are not dropped if they contain a yiaddr that does not match the local configured subnets on the DHCP relay interface. This applies only to regular IES and VPRN interfaces with no lease-populate configured on the DHCP relay interface.

DHCP Options

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

The 7705 SAR supports the Relay Agent Information Option 82 as specified in RFC 3046. The following suboptions are supported:

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

DHCPv6 Relay

DHCPv6 Relay operation is similar to DHCP in that servers send configuration parameters such as IPv6 network addresses to IPv6 nodes, but DHCPv6 Relay is not based on the DHCP or BOOTP protocol. DHCPv6 can be used instead of stateless autoconfiguration (refer to the 7705 SAR OS Router Configuration Guide, “Neighbor Discovery”) or in conjunction with it.

DHCPv6 is also oriented around 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 has been assigned an IP address. When a client has an address and knows the identity of a server, it 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 (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. Any server that can meet the client’s requirements responds with an Advertise message. The client chooses one of the servers and sends a Request message, and 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 some other way, it only needs to obtain configuration information. In this case, exchanges are done using a two-message process. The client sends an Information Request message, requesting only configuration information. A DHCPv6 server that has configuration information for the client sends back a Reply message with the information.

The 7705 SAR supports the DHCPv6 Relay Agent option in the same way that it supports the DHCP Relay Agent option. This means that when the 7705 SAR is acting as a DHCPv6 Relay Agent, it relays messages between clients and servers that are not connected to the same link.

DHCPv6 Options

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

Local DHCP and DHCPv6 Server

The 7705 SAR supports local DHCP server functionality on the base router and on access IP interfaces associated with VPRN, by dynamically assigning IPv4 or IPv6 addresses to access devices that request them. This standards-based, full DHCP server implementation allows a service provider the option to decentralize IP address management into the network. The 7705 SAR can support public and private addressing in the same router, including overlapped private addressing in the form of VPRNs in the same router.

The 7705 SAR can act as a DHCP server or a DHCPv6 server.

An administrator creates pools of addresses that are available for assigned hosts. Locally attached hosts can obtain an address directly from the server. Routed hosts receive addresses through a relay point in the customer’s network.

When a DHCP server receives a DHCP message from a DHCP Relay agent, the server looks for a subnet to use for assigning an IP address. If configured with the use-pool-from-client command, the server searches Option 82 information for a pool name. If a pool name is found, an available address from any subnet of the pool is offered to the client. If configured with the use-gi-address command, the server uses the gateway IP address (GIADDR) supplied by the Relay agent to find a matching subnet. If a subnet is found, an address from the subnet is offered to the client. If no pool or subnet is found, then no IP address is offered to the client.

When a DHCPv6 server receives a DHCP message from a DHCPv6 Relay agent, the server looks for a subnet to use for assigning an IP address. If configured with the use-pool-from-client command, the server searches Option 17 information for a pool name. If a pool name is found, an available address from any subnet of the pool is offered to the client. If configured with the use-link-address command, the server uses the address supplied by the Relay agent to find a matching subnet prefix. If a prefix is found, an address from the subnet is offered to the client. If no pool or prefix is found, then no IP address is offered to the client.

IPv4 and IPv6 address assignments are temporary and expire when the configured lease time is up. The server can reassign addresses after the lease expires.

If both the no use-pool-from-client command and the no use-gi-address command or no use-link-address command are specified, the server does not act.

DHCP and DHCPv6 Server Options

Options and identification strings can be configured on several levels.

DHCPv4 servers support the following options, as defined in RFC 2132:

1. Option 1—Subnet Mask
2. Option 3—Default Routers
3. Option 6—DNS Name Servers
4. Option 12—Host Name
5. Option 15—Domain Name
6. Option 44—Netbios Name Server
7. Option 46—Netbios Node Type Option
8. Option 50—IP Address
9. Option 51—IP Address Lease Time
10. Option 53—DHCP Message Type
11. Option 54—DHCP Server IP Address
12. Option 55—Parameter Request List
13. Option 58—Renew (T1) Timer
14. Option 59—Renew (T2) Timer

DHCPv4 servers also support Suboption 13 Relay Agent Information Option 82 as specified in RFC 3046, to enable the use of a pool indicated by the DHCP client.

DHCPv6 servers support the following options, as defined in RFC 3315:

1. Option 1—OPTION_CLIENTID
2. Option 2—OPTION_SERVERID
3. Option 3—OPTION_IA_NA
4. Option 4—OPTION_IA_TA
5. Option 5—OPTION_IAADDR
6. Option 6—OPTION_ORO
7. Option 7—OPTION_PREFERENCE
8. Option 8—OPTION_ELAPSED_TIME
9. Option 9—OPTION_RELAY_MSG
10. Option 11—OPTION_AUTH
11. Option 12—OPTION_UNICAST
12. Option 13—OPTION_STATUS_CODE
13. Option 14—OPTION_RAPID_COMMIT
14. Option 15—OPTION_USER_CLASS
15. Option 16—OPTION_VENDOR_CLASS
16. Option 17—OPTION_VENDOR_OPTS
17. Option 18—OPTION_INTERFACE_ID
18. Option 19—OPTION_RECONF_MSG
19. Option 20—OPTION_RECONF_ACCEPT

These options are copied into the DHCP reply message, but if the same option is defined several times, the following order of priority is used:

1. subnet options
2. pool options
3. options from the DHCP client request

A local DHCP server must be bound to a specified interface by referencing the server from that interface. The DHCP server will then be addressable by the IP address of that interface. A normal interface or a loopback interface can be used.

A DHCP client is defined by the MAC address and the circuit identifier. This implies that for a certain combination of MAC and circuit identifier, only one IP address can be returned; if more than one request is made, the same address will be returned.

Troubleshooting and Fault Detection Services

Bidirectional forwarding detection (BFD) can be configured on the VPRN interface. BFD is a simple protocol for detecting failures in a network. BFD uses a “hello” mechanism that sends control messages periodically to the far end and expects to receive periodic control messages from the far end. On the 7705 SAR, BFD is implemented for static routes in asynchronous mode only, meaning that neither end responds to control messages; rather, the messages are sent periodically from each end.

To support redundancy with fast switchover, BFD must be enabled to trigger the handoff to the other route in case of failure.

Due to the lightweight nature of BFD, it can detect failures faster than other detection protocols, making it ideal for use in applications such as mobile transport.

If BFD packets are not received in the configured amount of time, the associated static route is declared “not active”, causing a reroute to an alternative path, if any.

Note: Link failures detected by BFD will disable the IP interface.

The 7705 SAR also supports Internet Control Message Protocol (ICMP). ICMP is a message control and error reporting protocol that also provides information relevant to IP packet processing.

Configurable ARP Retry Timer

A timer is available to configure a shorter retry interval when an ARP request fails. An ARP request may fail for a number of reasons, such as network connectivity issues. By default, the 7705 SAR waits 5000 ms before retrying an ARP request. The configurable retry timer makes it possible to shorten the retry interval to between 100 and 30 000 ms.

Note: The ARP retry default value of 5000 ms is intended to protect CPU cycles on the 7705 SAR, especially when it has a large number of interfaces. Configuring the ARP retry timer to a value shorter than the default should be done only on mission-critical links, such as uplinks or aggregate spoke SDPs transporting mobile traffic; otherwise, the retry interval should be left at the default value.

The configurable ARP retry timer is supported on VPRN and IES service interfaces, as well on the router interface.

SAPs

Topics in this section include:

VPRN service also supports SAPs for IPSec tunnels (see IPSec Support).

PE-to-CE Routing Protocols

The 7705 SAR supports the following PE-to-CE routing protocols for VPRN service:

EBGP is supported within both the router context and VPRN service context. OSPF is supported within the router context as well as within the VPRN service context, with some minor differences in the command set depending on the context.

PE-to-PE Tunneling Mechanisms

The 7705 SAR supports multiple mechanisms to provide transport tunnels for the forwarding of traffic between PE routers within the RFC 2547bis network.

The 7705 SAR VPRN implementation supports the use of:

These transport tunnel mechanisms provide the flexibility of using dynamically created LSPs, where the service tunnels are automatically bound (the “auto-bind” feature) and there is the ability to provide certain VPN services with their own transport tunnels by explicitly binding SDPs, if desired. When the auto-bind command 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 7705 SAR allows 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 is nearly full and an option to disable additional route learning when the VRF is full or only generate an event.

RIP Metric Propagation in VPRNs

When RIP is used as the PE-CE protocol for VPRNs (IP-VPNs), the RIP metric is used only by the local node running RIP with the Customer Equipment (CE). The metric is not used with the MP-BGP path attributes that are exchanged between PE routers. Figure 100 shows an example of RIP metric propagation in a VPRN across two autonomous systems.

Figure 100:  RIP Metric Propagation in VPRNs 

The RIP metric can also be used to exchange routing information between PE routers 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. The RIP metric sets the BGP MED attribute, which allows remote PEs to choose the lowest MED and the PE with the lowest advertised RIP metric as the preferred egress point for the VPRN.

Spoke SDPs

For VPRN service, spoke SDPs can be used only for providing network connectivity between the PE routers.

Spoke SDP Termination to VPRN

This feature enables a customer to exchange traffic between a VLL or VPLS (Layer 2) service and an IES or VPRN (Layer 3) service. Customer premises traffic coming in from a VLL or VPLS service (SAP to spoke SDP) is forwarded over the IP/MPLS network to the IES or VPRN service, and vice versa. Network QoS policies can be applied to the spoke SDP to control traffic forwarding to the Layer 3 service.

In a Layer 3 spoke SDP termination to an IES or VPRN service, where the destination IP address resides within the IES or VPRN network, CE device-generated ARP frames must be processed by the Layer 3 interface. When an ARP frame is received over the spoke SDP at the Layer 3 interface endpoint, the 7705 SAR responds to the ARP frame with its own MAC address. When an ARP request is received from the routed network and the ARP entry for the CE device that is connected to the spoke SDP is not known, the 7705 SAR initiates an ARP frame to resolve the MAC address of the next hop or CE device.

Figure 101 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 101:  SDP ID and VC Label Service Identifiers (Conceptual View of the Service) 

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

Figure 102:  VPRN Spoke SDP Termination 

Ethernet spoke SDP termination for VPRN service is supported over the following network uplinks:

Spoke SDP termination for VPRN supports the following:

A spoke SDP on a VPRN interface service can be connected to the following entities:

There are three scenarios to backhaul traffic from a given site that uses PWs and VPRN on a 7705 SAR.

Figure 103:  Pseudowire-Based Backhaul (Spoke SDP Termination at 7750 SR) 

Figure 104:  VPRN in Mobile Backhaul Application 

Figure 105:  Spoke-SDP Termination to VPRN 

IPv6 on Virtual Private Edge Router

The IPv6 on Virtual Private Edge Router (6VPE) feature allows customers that are migrating from an IPv4 to an IPv6 environment to use their existing IPv4 core infrastructure for transporting IPv6 traffic. Customers can migrate their access network to IPv6, including the eNodeBs, and keep the IPv4 core. The IPv4 core can be used for transporting eNodeB IPv6 traffic over MPLS or GRE tunnels. See IPv6 over IPv4 LAN-to-LAN IPSec tunnels for a description of how the 6VPE functionality is achieved.

Note: The 6VPE feature is not supported on the 16-port T1/E1 ASAP Adapter card or the 32-port T1/E1 ASAP Adapter card. This applies to both the access side (VPRN interfaces) and network side (MPLS/GRE tunnels). On the network side, 6VPE is not supported on DS3/OC3 network interfaces, but is supported on SAR-A, SAR-M, SAR-H, and SAR-X T1/E1 ASAP network interfaces. On the access side, 6VPE (VPRN SAP interfaces) is not supported on any T1/E1 ASAP adapter cards/blocks. VPRN spoke-SDP interfaces (spoke-SDP termination) are supported on SAR-A, SAR-M, SAR-H, and SAR-X T1/E1 ASAP blocks but not on T1/E1 adapter cards.

The classification of packets on a 6VPE access network is based on a customer packet Transaction Code (TC) field. The TC field is one byte long, but only the first six bits are used for the classification process. The use of six bits offers 64 different classes. The marking of the network outer tunnel DSCP/EXP bits is based on this access classification.

The supported protocols for 6VPE are listed in Table 103. The Access Control Lists for 6VPE are provided by Table 104, Table 105, and Table 106.

IPv6 over IPv4 LAN-to-LAN IPSec tunnels

In order to support the 6VPE functionality described in IPv6 on Virtual Private Edge Router, access (customer) IPv6 traffic is aggregated using a service VPRN and encrypted via an IPSec IPv4 static LAN-to-LAN tunnel, as shown in Figure 106. BGPv4 or BGPv6 can be configured over the IPSec IPv4 static LAN-to-LAN tunnel with an IPv6 address family to advertise the IPv6 VPRN routes to the peer VPRN.

The management IP addresses of all customer switches are migrated to IPv6. The system IP address of the 7705 SAR is configured as an IPv6 address and also migrated to IPv6. The OAM customer traffic is aggregated via an r-VPLS (IPv6 r-VPLS) into a 6VPE OAM VPRN. An IPv6 static route carries the IPv6 OAM traffic to an IPv4 static LAN-to-LAN tunnel, where the traffic is encrypted and encapsulated in an IPSec IPv4 transport tunnel. The IPSec IPv4 transport tunnel uses a NAT-to-single public IP address method, that is, NAT-T.

Figure 106:  Access IPv6 Traffic Aggregation and Encryption