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.

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

NAT and VPRN

Network Address Translation (NAT) is used by mobile backhaul, enterprise, and SI (Strategic Industries) providers to provide expandability and security for private networks. Tier 1 providers can potentially run out of private IPv4 addresses, making it difficult to expand their existing networks. To address this issue, NAT can be used. NAT can hide multiple private IP addresses behind a single public IP address and therefore makes it possible to scale IP solutions in mobile backhaul, enterprise, and SI networks.

Besides conserving available IPv4 addresses, NAT can also be used as a security feature to hide the real IP addresses of hosts, securely providing private LAN users access to public addresses.

NAT configuration is 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. NAT policies, which define a set of rules that determine how NAT should direct traffic, can be applied to the entire zone.

A zone can be configured within the router context or under the base router and/or within the IES or VPRN service context. A zone is configured by adding at least one Layer 3 interface to the zone configuration. Multiple zones can be created within each service or within the router context. Layer 3 interfaces from different services cannot be grouped into a single common zone.

An example of NAT within VPRN is shown in Figure 88. All traffic between zone 1 and zone 2 has NAT applied to it.

Note: NAT on VPRN does not support MP-BGP, spoke SDP termination, or IPSec private interface.

Figure 88:  NAT Within VPRN 

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 89 illustrates the RD structure.

Figure 89:  Route Distinguisher Structure 

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

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 90 and Figure 91 illustrate the use of CPE connectivity check in directly connected and multiple-hop connected routes.

Figure 90:  Directly Connected IP Target 

Figure 91:  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 CPM 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 92 lists the management protocols supported by GRT in the reverse and forward directions.

Figure 92 shows an example of 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 92:  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.

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

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.

The 7705 SAR can act as a DHCP Relay agent or a local DHCP 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.

The DHCP protocol requires the client to transmit a request packet with a destination address of 255.255.255.255 (broadcast) 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.

When the 7705 SAR is acting as a local DHCP server, it processes these DHCP broadcast 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, and 7705 SAR-Wx. 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.

Note: 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 network interfaces only. Refer to the 7705 SAR OS Router Configuration Guide, “DHCP”, for more information.

DHCP Relay

The 7705 SAR provides DHCP/BOOTP Relay agent services for DHCP clients. DHCP is known as a stateful protocol because it uses dedicated servers to maintain parameter information.

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 the base router, and on access IP interfaces associated with IES and VPRN.

DHCP Relay Agent 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

Local DHCP 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 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 acts as a DHCP server only; it does not currently function as 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.

IPv4 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 are specified, the server does not act.

DHCP Server Options

Options and identification strings can be configured on several levels. DHCP 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

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

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 93 shows an example of RIP metric propagation in a VPRN across two autonomous systems.

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

Figure 95 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 95:  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 96:  Pseudowire-Based Backhaul (Spoke SDP Termination at 7750 SR) 

Figure 97:  VPRN in Mobile Backhaul Application 

Figure 98:  Spoke-SDP Termination to VPRN