8.1.3.1. Route reflector

Per RFC2547bis the use of Route Reflectors is supported in the service provider core. Multiple sets of route reflectors can be used for different types of BGP routes, including IPv4 and VPN-IPv6. 7210 can only be used a route reflector client. It cannot be used as a route reflector ("server").

8.1.3.2. Customer Edge to Provider Edge route exchange

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

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

8.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 84 and Figure 85 show static routes.

Figure 84:  Directly connected IP target 

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

8.1.4.1. Constrained VPN route distribution based on route targets

The RTC is a mechanism allows a router to advertise route target membership information to its BGP peers to indicate interest in receiving only VPN routes tagged with specific route target extended communities. After receiving this information, peers restrict the advertised VPN routes to only those requested, which minimizes the control plane load in terms of protocol traffic and possibly routing information base (RIB) memory.

MP-BGP carries the route target membership information, using an address family identifier (AFI) value of 1 and subsequent address family identifier (SAFI) value of 132. For two routers to exchange RT membership network layer reachability information (NLRI), they must advertise the corresponding AFI/SAFI to each other during capability negotiation. MP-BGP allows RT membership NLRI to be propagated, loop-free, within an AS and between ASs using well-known BGP route selection and advertisement rules.

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

8.1.4.2. Configuring the route target address family

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

ORF is mutually exclusive with RTC on a specific BGP session. The CLI will not attempt to block this configuration, but if both capabilities are enabled on a session, the ORF capability is not included in the OPEN message sent to the peer.

8.1.4.3. Originating RT constraint routes

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

Note: Refer to the 7210 SAS-Mxp, R6, R12, S, Sx, T Routing Protocols Guide for more information about BGP address families that support RTC.

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

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

8.1.4.4. Receiving and re-advertising RT constraint routes

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

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

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

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

8.1.4.5. Using RT constraint routes

In general (ignoring iBGP-to-iBGP rules, add-path, best-external, and so on), the best VPN route for every prefix/NLRI in the RIB is sent to every peer supporting the VPN address family, but export policies may be used to prevent the advertisement of some prefix/NLRIs to specific peers. These export policies may be configured statically or created dynamically based on use of ORF or RTC with a peer. ORF and RTC are mutually exclusive on a session.

When RTC is configured on a session that also supports VPN address families using route targets (vpn-ipv4, vpn-ipv6, and so on), the advertisement of the VPN routes is affected as follows:

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

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

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

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

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

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

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

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

8.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-Mxp, R6, R12, S, Sx, T 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:

8.2.2.2. Encapsulations

The following SAP encapsulations are supported on the 7210 SAS VPRN service:

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

8.2.5.1. PE to PE tunneling mechanisms

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

The 7210 SAS VPRN implementation supports the use of:

These transport tunnel mechanisms provide the flexibility to use dynamically created LSPs, where the “autobind” feature is used to automatically bind service tunnels, and there is the ability to provide specific VPN services with their own transport tunnels by explicitly binding SDPs, if required. When the auto-bind-tunnel command is used, all services traverse the same LSPs and do not allow alternate tunneling mechanisms or the ability to configure sets of LSPs with bandwidth reservations for specific customers, as is available with explicit SDPs for the service.

8.2.5.2. Per-VRF route limiting

The 7210 SAS 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 to indicate that the VRF table is nearly full, and an option to disable additional route learning when the VRF is full or only generate an event.

8.2.6.1. Configuration guidelines

The following configuration guidelines apply to this feature:

8.2.10.1. Multicast protocols supported in the provider network

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

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

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

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

8.2.10.2. Provider tunnel support

The following provider tunnels are supported: