Overview

General information

The NFM-P supports the creation of VPRN services using the 7450 ESS in mixed mode, the 7750 SR, the 7705 SAR, and the 7950 XRS as a PE and provider core (P) router. VPRNs, also called IP VPNs or BGP/MPLS VPNs, are defined in RFC 2547bis. This standard describes a method of forwarding data and distributing routing information across an IP/MPLS service provider core network.

The NFM-P does not support the configuration of CE routers or devices.

The NFM-P supports end-to-end VPRN configuration using tabbed configuration forms with an embedded navigation tree.

The NFM-P supports the configuration in a VPRN of an L3 aggregation mechanism called routed CO. Routed CO uses DHCP relay to manage dynamic subscriber hosts; the network resources for static subscriber hosts are explicitly provisioned. Routed CO supports all residential subscriber management functions of the NFM-P. See Chapter 74, Residential subscriber management for more information about residential subscriber management and routed CO.

Routed CO uses a subscriber interface that defines up to 256 subnets. A subscriber interface has child objects called group interfaces. A group interface supports the configuration of multiple SAPs as child objects. A SAP in a group interface supports all residential subscriber management functions. A group interface does not allow the specification of IP subnets or addresses, but inherits the addressing scheme of the parent subscriber interface. The NFM-P service topology map displays VPRN subscriber interfaces, group interfaces, and the associated SAPs.

You can configure NAT for dynamic subscriber hosts in a routed CO deployment. NAT implementation in a VPRN service requires a NAT configuration on the VPRN routing instance and a NAT policy that is associated with a subscriber profile. See Chapter 30, NAT for information about configuring and deploying NAT, and about configuring a NAT policy. See To configure a subscriber profile for information about associating a NAT policy with a subscriber profile. See To configure NAT on a routing instance for information about how to configure NAT on a VPRN site.

A VPRN routed CO allows a service provider to resell wholesale carrier services while providing direct DSLAM connectivity. You can create a VPRN service for the retailer and also define subscriber access and configuration information for the retailer network. See To configure a group interface on a VPRN for more information on how to define a wholesale and retail VPRN configuration.

The General tab of the NFM-P service management form displays useful information about the operational state of the service and its sites through the Aggregated Operational State and State Cause indicators.

When you use the NFM-P to create or discover a service, the NFM-P assigns a default Service Tier value to the service. The Service Tier parameter value is relevant only in the context of composite service topology views. See Chapter 85, Composite service management for more information about the hierarchical organization of composite services.

Route advertisement

VPRN services use BGP to exchange the VPRN routes among the PE routers that participate in the VPRN. This is done in a way that ensures that routes from different VPRNs remain distinct and separate, even if two VPRNs have an overlapping address space. PE routers distribute routes to CE routers in the VPRN. Since the CE routers do not peer with each other, there is no overlay visible to the routing algorithm of the VPRN. The PE routers use BGP, RIP, OSPFv2, or OSPFv3 as the IGP to distribute internal routes to the CE routers.

Each route in a VPRN service is assigned an MPLS label. When BGP distributes a VPRN route, it also distributes an MPLS label for that route. Before a customer data packet travels across the backbone network, it is encapsulated with the MPLS label that corresponds, in the customer VPRN, to the route that best matches the destination address of the packet.

The MPLS packet is further encapsulated with either another MPLS label or with an IP or GRE tunnel header, so that it gets tunneled across the backbone to the proper PE router. Each route exchanged by the MP-BGP protocol includes an RD that identifies the VPRN association. Thus the backbone core routers do not need to know the VPRN routes.

In addition to exchanging routes using BGP, other types of routes can be leaked from the GRT to a VPRN instance so that they can be used for traffic forwarding or to redistribute those routes to other routers within the routing instance using either BGP or the VPRN IGP instance. Leaking of routes is administered using routing policies. A set of leak export routing policies is added to the NE routing interface. These policies determine the pool of GRT routes that can be imported by a VPRN instance. In the VPRN routing instance, the set of import policies determines which GRT routes from the pool will be added to the route table of the VPRN.

The following types of routes can be leaked from the GRT to a VPRN:

VPRN routing instances

VPRN routing instances are a representation of the objects assigned to a VPRN service such as the assigned interfaces, protocols, confederations, and spoke SDP bindings managed by the NFM-P. The supported objects are displayed in the service navigation tree as child objects to the VPRN routing instance.

You do not create VPRN routing instances; they are created automatically by the NFM-P when you create a VPRN service. You cannot view VPRN routing instances in the navigation tree routing view. You can view them using the Manage→Service→Services main menu, selecting a pre-configured VPRN service, then choose Properties. The VPRN routing instances are displayed under the Site icon in the service navigation tree.

VPRN service policies

Common to all device services, such as VPRN, are policies that are assigned to the service. Policies are defined at a global level and can then be applied to components of the service, such as interfaces or circuits, when the service is configured or modified. The following policies are common to all device services:

See Chapter 49, Policies overview for more information about policies.

VPRN service validation

The NFM-P provides OAM tools for service validation and for troubleshooting service and network transport issues. You can run an OAM Validation test suite for the service by clicking Validate, or by clicking More Actions and choosing Validate. Alternatively, you can also perform a One Time Validation. If a check mark appears beside the OAM Validation Failed state cause indicator, the test has failed. The Tested Entity Result tab on the Tests tab displays detailed information about the OAM test result. See Chapter 90, OAM diagnostic tests for general information about alarm management using OAM tools. See Chapter 89, Service Test Manager for more information about how to configure OAM validation test suites.

The Aggregated Operational State indicator has four possible values: Up, Down, Partially Down, and Unknown. The value is derived from the operational states of the sites that are part of the service, as follows:

When the Aggregated Service Site Operational State is Partially Down or Down, a check mark appears beside the appropriate State Cause indicator to identify the type of fault to the NFM-P operator. You can view alarms on the Faults page.

When the Aggregated Operational State is Partially Down or Down, a check mark appears beside the appropriate State Cause indicator to identify the type of fault to the NFM-P operator.

VPRN service routers

A VPRN service consists of CE routers or devices connected to PE routers. PE routers connected to P routers transport data across the IP/MPLS provider core network in service tunnels.

Packets that arrive at an edge 7450 ESS, 7705 SAR, 7750 SR, or 7950 XRS are associated with a VPRN service based on the access interface on which they arrive. An access interface is uniquely identified by the following parameters.

The following table describes the general functions performed by PE, P, and CE routers in a VPRN. See Figure 79-4, Sample VPRN Configuration in this chapter for a sample VPRN. See the appropriate hardware services guide for more detailed information about VPRN functionality on the supported managed devices.

Table 79-1: VPRN router functionality

Router type

Functionality

PE

  • Are directly connected to PE, CE, and P routers

  • Learn VPRN routes from CE devices using e-BGP, RIP, OSPFv2 or OSPFv3, or static routes

  • Maintain a separate routing table, called a VRF, for each service

  • Exchange multicast VPRN route information with PE routers in other autonomous systems using MP-BGP

  • Distribute MPLS inner labels using MP-BGP. Before data traverses the IP/MPLS backbone, it is encapsulated with the MPLS label that corresponds, within the VPRN, to the route that best matches the packet’s destination address.

  • Distribute MPLS outer labels using RSVP-TE or LDP. Before the MPLS packet traverses the IP/MPLS backbone, it is further encapsulated with either another MPLS label or with a GRE or MPLS LSP service tunnel header, so that it is tunneled across the backbone to the appropriate PE router.

  • Use RDs to identify the VPRN associations

  • Use RTs to determine when a received route is destined for a VPRN

  • Terminate RFC 2684-encapsulated IPv4 traffic from ATM access network on SAPs

P

  • Are directly connected to PE and P routers

  • Act as transit LSRs

  • Maintain routes to PE routers and are unaware of specific VPRN routing information

CE

  • Are directly connected to PE routers

  • Provide customer access to the VPRN

Inter-AS connections

You can connect VPRN service sites (or VRFs) on multiple ASs using EBGP. ASs set up mutual connections by exchanging routing information, such as routes and labels. Labeled VPN-IPv4 routes are distributed within an AS on a PE router using IGBP and between ASs using EGBP on an ASBR. The ASBR redistributes VPN-IPv4 routes to an ASBR in another AS, which in turn distributes the routes to PE routers in its own AS or to an ASBR.

When a VPRN inter-AS connection is between two service providers, the ASs must be on private peering points. For an LSP to operate between ASBRs on the AS borders, EBGP peering must be set up between the ASBRs and MPLS label exchange must be supported. Furthermore, an LSP must run from a packet’s ingress PE router to its egress PE router.

You can enable inter-AS connections from the BGP settings in To configure ISIS, L2TP, MLD, OSPFv2, OSPFv3, PIM, RIP, or WPP on a VPRN routing instance .

MP-BGP Multicast IPv4

The MP-BGP multicast extension allows for a network topology that supports both multicast and unicast routing. Routes from the unicast routing table can be imported into the multicast routing table, and routes from the multicast routing table can be imported into the unicast routing table. An ASBR can be configured to advertise VPRN routes to peers in other ASs, redistributing unicast routes learned by BGP into MP-BGP routes, and MP-BGP routes into unicast routes. This configuration enables the support of the two sets of routing information.

The MP-BGP multicast extension specifies that BGP can exchange routing information for the multicast IPv4 address family within and between BGP ASs. All configurations entered in a multicast IPv4 address family for a BGP instance affect multicast services and are applied to the multicast routing table. See Chapter 28, Routing protocol configuration for more information about the configuration of BGP and the MP-BGP multicast extension.

IPv6 support

To configure IPv6 in a VPRN, you must first enable VPN IPv6 for BGP on the base routing instance of each device that acts as a site in the VPRN.

A customer can use an SNMP utility to manage the IPv6 objects in a VPRN service. SNMP mediation of VPRN objects requires the configuration of a community string on each site in the VPRN, regardless of the IP or SNMP version. SNMPv3 mediation of VPRN IPv6 objects, however, requires the additional configuration of an SNMP context for the VPRN using a CLI. See Chapter 9, Device discovery for information about configuring an SNMPv3 context for a VPRN.

PIM for VPRN

The PIM protocol can be applied to a VPRN service to create a private multicast distribution network. PIM uses an MDT group address to identify multicast traffic for the VPRN instance to prevent flooding of multicast packets to PE devices in the VPRN. VRFs with the same MDT address are members of that group and receive multicast traffic from each other. The MDT address cannot be in the SSM range.

By default, the PIM protocol only uses the information in the unicast routing table to determine the RPF interface. PIM can be configured to use the separate multicast and unicast routing tables built by MP-BGP to perform RPF lookups for multicast-capable sources to build and maintain distribution trees for multicast traffic forwarding. See Chapter 28, Routing protocol configuration for more information about configuring PIM to use multicast or unicast routing tables in RPF lookups.

Data-MDT

A data-MDT is a tunnel for high-bandwidth source traffic through the P-network to interested PE routers. Data-MDTs do not broadcast customer multicast traffic to all PE routers in a multicast domain.

Note: Data-MDTs are only supported for VPRN services.

Multicast data transmission from a CE router is typically delivered to all CE routers in the same multicast group. Some CE routers do not require the delivery of a specific multicast stream because there no downstream receivers for the multicast group. You can prune a PE router from the MDT if the router does not deliver multicast traffic to the attached CE routers. This task is beneficial for high-traffic multicast applications.

A data-MDT allows you to configure a traffic threshold in Kb/s. The NFM-P signals the data-MDTs when the bandwidth for the SSM group exceeds the configured threshold. The PE router sends an MDT join TLV, at 60 s intervals, over the default MDT to all PE routers. The routers respond with the following actions:

The transmitting PE router switches the multicast stream to the data-MDT after allowing the PE routers to join the data MDT. You can configure the data-MDT delay interval using the NFM-P.

The PE router stops sending the MDT join TLV when the transmission bandwidth no longer exceeds the configured threshold. The PE routers using the data-MDT leave the group and transmission resumes over the default MDT.

OSPF sham link support

You can use the OSPF protocol to connect CE routers to PE routers over an MPLS VPN backbone. This can be useful for customers who subscribe to a VPN service and need to use OSPF as their intra-site routing protocol to exchange routing information between their sites. However, there is a potential configuration issue associated with this approach.

OSPF PE-CE connections assume that the only path between two client sites is across the MPLS VPN backbone. OSPF treats a link through a Layer 3 VPN as an inter-area link. However, other paths between VPN sites may also exist. For example, in the following figure, the link between CE-3 and CE-4 (two CE routers in the same OSPF area) might be a low-speed OC3/STM1 intra-area backup link. OSPF preferentially utilizes intra-area links over inter-area links, and since it establishes an intra-area route connection between CE-3 and CE-4, the potentially high-speed PE-1 to PE-2 primary connection is not utilized.

Figure 79-1: Sham link configuration example
Sham link configuration example

OSPF sham links can be created to resolve this problem. By creating and configuring a sham link as an intra-area link between PE-1 and PE-2, a normal OSPF adjacency is formed, and the link-state database is exchanged across the MPLS VPN. As a result, the desired intra-area connectivity is created between PE-1 and PE-2. In addition, the cost of the CE-3/CE-4 and PE-1/PE-2 links can be managed by the use of a numerical metric. You could then configure the service so that the CE-3/CE-4 link becomes a standby link only in event that the VPN fails.

ATM SAP terminations for VPRN

CE routers that have access to an ATM network can connect with a VPRN using ATM SAP terminations on a 7750 SR. The interconnection between ATM point-to-point and L3 services uses RFC 2684-encapsulated IPv4 traffic over an ATM PVC that terminates on a specially configured SAP. All RFC 2684- encapsulated traffic can be routed over ATM networks, frame relay, or directly through ATM connections.

The following figure shows how CPE Router A in an ATM network can access L3 IP services, such as a VPRN, using a statically configured ATM PVC on a 7750 SR (SR#1). A SAP is configured on SR #1 to serve a specific VPRN as identified by the VRF. Destination CPE router D can receive RFC 2684-encapsulated traffic over an IP network through a frame relay over 7750 SR 2.

Figure 79-2: ATM SAP network connection to a VPRN
ATM SAP network connection to a VPRN

The two connection methods used between ATM and VPRN, which appear in NFM-P as AAL5 Encapsulation parameters. LLC/SNAP encapsulation and VC-multiplexing.

Epipe SDP spoke termination on VPRN services

A VLL Epipe service can terminate directly on a VPRN service using an SDP spoke on the 7750 SR, 7450 ESS, or 7950 XRS. Traffic that terminates on a VPRN service is identified by the interface ID of the SDP on the L2 access router and the VC ID label in the service packet. All routing protocols supported by VPRN are also supported for spoke SDP termination.

The following figure shows a spoke SDP terminating directly on a VPRN. The spoke SDP could be tied to an Epipe or VPLS. No configuration is required for the CE-to-PE connection on the SAP.

Figure 79-3: SDP spoke termination on an L2 service
SDP spoke termination on an L2 service
Routed CO dual homing using SRRP

Subscriber Router Redundancy Protocol (SRRP) allows two separate connections to an access NE such as DSLAM to operate in an active/standby configuration similar to the way in which VRRP interfaces operate. SRRP is a collection of functions and messaging protocols that allows a system to create a set of redundant gateway IP addresses that are shared by a local and remote NE.

Each SRRP instance is created within the context of a subscriber group IP interface and is identified by a unique SRRP instance ID, which must be unique within the NE. This SRRP instance controls the redundant routing for all subscriber subnets configured or associated with the group interface. One SRRP instance is supported for each group interface and the SRRP ID must be the same as the SRRP instance ID on the group IP interface on the redundant NE.

A subscriber subnet redundant gateway IP host address is assigned at the subscriber IP interface level and is used for each SRRP instance associated with the subscriber subnet. The redundant IP host address must be configured for a subscriber subnet before it can be associated with an SRRP instance.

When SRRP is active on a group interface, the SRRP instance advertises to a remote NE using in-band messaging on the group-interface SAPs and out-of-band messaging on the group-interface redundant interface. If the remote NE uses the same SRRP instance ID, one NE enters a master state, while the other NE enters a backup state. Since the NEs share a common SRRP gateway MAC address (used for the SRRP gateway IP address and for proxy ARP functions), either NE can act as the default gateway for the attached subscriber hosts. This functionality helps to preserve subscriber QoS enforcement. The master state allows routing to and from the subscriber hosts associated with the group IP interface. The backup state stops ingress forwarding for packets destined to the SRRP gateway MAC and causes all packets destined to subscriber hosts on the group IP interface to be forwarded to a redundant IP interface associated with the group IP interface.

Normally, when anti-spoofing is enabled on a group-interface SAP, the SAP drops SRRP packets because they do not contain a subscriber MAC or IP address. However, you can use a configuration option to enable anti-spoofing for subscriber hosts on a group-interface SAP that participates in SRRP advertisements.

The underlying mechanism that controls state transitions is based on a dynamic priority level that an SRRP instance maintains. The SRRP instance with the highest priority level assumes the master operating state. An SRRP instance with a higher current priority level always preempts an SRRP instance with a lower priority level. If the priority levels are equal, the SRRP instance with the lowest source SRRP host IP address assumes the master state. The local SRRP instance priority may also be controlled by associating the instance with an existing VRRP policy.

To prevent a flood of AccessInterfaceDown alarms that an SRRP fault or link failure may generate for LAG-based MSAPs, the NFM-P performs alarm suppression. See Chapter 74, Residential subscriber management for more information.

The redundant IP interface is a special interface that connects two systems with one or more common SRRP instances. The interface is configured with a /31 address and a spoke SDP binding, creating an Ethernet pseudowire shortcut between the redundant NEs. When the SRRP instance is in backup state, the group interface associated with this instance is not allowed to forward or route traffic downstream towards the subscriber. As a result of this, the packets are shunted across the redundant interface so that the active group interface does the forwarding or routing.

If the redundant IP interface goes down, the system allows the group IP interfaces associated with the down interface to forward locally downstream, when they are in the backup SRRP state. While forwarding downstream in the backup state, the system uses the MAC address associated with the group IP interface, not the SRRP redundant gateway MAC address.

SRRP is supported on the 7450 ESS in mixed mode and 7750 SR.

DoS protection

To protect a VPRN from a high incoming packet rate that characterizes a DoS attack, you can use the NFM-P to create DoS protection policies for the VPRN L3 access interfaces. A DoS protection policy limits the number of control-plane packets that an interface receives each second, and optionally logs a violation notification if a policy limit is exceeded. You can use the NE System Security form to view the violations for a specific NE.

You can configure a DoS protection policy to control the following on a VPRN L3 access interface:

Each VPRN L3 access interface on an NE that supports DoS protection is automatically assigned a default DoS protection policy. This default policy limits only the overall packet arrival rate for the interface, and cannot be deleted or modified. See the procedure to configure an NE DoS protection policy in the NSP System Administrator Guide for information about creating a DoS protection policy.

DDoS protection

To protect a VPRN from a high incoming packet rate that characterizes a DDoS attack, you can use the NFM-P to configure TMS interfaces to route malicious traffic through the ISA-TMS MDA where the malicious traffic is cleaned before being released to the network.

The TMS interface on a VPRN consists of three VPRNs as follows:

See To add a TMS interface to a VPRN for information about creating a TMS interface.

You can configure a DDoS protection policy on a VPRN group interface SAP, network interface, or L3 access interface. See the procedure to configure an NE DDoS protection policy in the NSP System Administrator Guide for more information.

Local DHCP servers

A local DHCP server can be associated with an L3 access interface on a VPRN service. See Residential subscriber components .

Local user database

A local user database can be associated with a local DHCP server and PPPoE configurations on group interfaces. See Residential subscriber components .

PPPoE protocol on VPRN services

A VPRN service can be configured to run PPPoE protocol. PPPoE is used in subscriber networks to encapsulate PPP frames inside Ethernet frames. PPPoE combines the point-to-point protocol used with DSL sessions with the Ethernet protocol used to support multiple subscribers in a local area network. From the group interface configuration form you can assign a PPPoE policy and a local user database to authenticate PPPoE subscribers.

PPPoE termination in a business VPRN environment is also supported. This ability targets applications such as PPPoE VPRN with IP overlap, where there are two participants in the service:

In this configuration, the PPPoE subscriber host terminates in a Retail VPRN and provides a routed path to the customer site. The VPRN service-id that carries it is determined by the service configuration, specifically:

The PPPoE session is negotiated with the parameters defined by the Wholesale VPRN interface. Since the IP address space of the subscriber management host may overlap between VPRN services, the node anti-spoofs the packets at access ingress with the session-id.

L2TP on VPRN services

The NFM-P supports the configuration of L2TP on a 7750 SR or 7950 XRS, and on the 7450 ESS in mixed mode. L2TP is a session-layer protocol that extends the PPP model by allowing L2 and PPP endpoints to reside on different devices that are interconnected by a PSN. L2TP extends the PPP sessions between the CPE and PPP/L2TP termination points on the L2TP network server (LNS), via an intermediate L2TP access concentrator (LAC). The LAC is the initiator of session-generated L2TP tunnels; the LNS is the server that waits for new tunnels. Manually configured and initiated L2TP tunnels can be initiated or stopped from either the LNS or LAC.

At least one ISA-LNS group must be configured for the LNS NE.

On an LNS NE, L2TP destinations configured for L2TP tunnel profiles can include the following:

See Chapter 13, Logical group object configuration for more information about ISA-LNS groups. See To configure an ISA-LNS group for information about how to create and configure an ISA-LNS group. See Chapter 28, Routing protocol configuration for more information about L2TP.

See To configure ISIS, L2TP, MLD, OSPFv2, OSPFv3, PIM, RIP, or WPP on a VPRN routing instance for information about enabling L2TP on a VPRN router instance site. See To configure a group interface on a VPRN for information about configuring a VPRN group interface to terminate LNS PPP sessions.

IPsec

You can configure a VPRN with a tunnel interface for secure and encrypted tunneling between sites. An IPsec VPRN allows you to share secure and encrypted VPN traffic among multiple sites.

IPsec VPRN services include:

See Chapter 34, IPsec for more information about IPsec configuration.