This chapter provides information about the Virtual Private Routed Network (VPRN) service and implementation notes.
Topics in this chapter include:
Topics in this section include:
RFC 2547bis, an extension of RFC 2547, details a method of distributing routing information and forwarding data to provide a Layer 3 Virtual Private Network (VPN) service to end customers.
Each Virtual Private Routed Network (VPRN) consists of a set of customer sites connected to one or more PE routers. Each associated PE router maintains a separate IP forwarding table for each VPRN. Additionally, the PE routers exchange the routing information configured or learned from all customer sites via MP-BGP peering. Each route exchanged via the MP-BGP protocol includes a route distinguisher (RD), which identifies the VPRN association.
The service provider uses BGP to exchange the routes of a particular VPN among the PE routers that are attached to that VPN. This is done in a way that ensures that routes from different VPNs remain distinct and separate, even if two VPNs have an overlapping address space. Within a particular VPN, the PE routers distribute route information from and to the CE routers. Since the CE routers do not peer with each other, there is no overlay visible to the VPN routing algorithm.
When BGP distributes a VPN route, it also distributes an MPLS label for that route. On an individual 7705 SAR, a single label is assigned to (advertised for) all routes in a VPN. A VRF lookup is used to determine the egress interface for a packet.
Before a customer data packet travels across the service provider’s backbone network, it is encapsulated with the MPLS label that corresponds, in the customer’s VPN, to the route that best matches the packet’s destination address. That label (called the inner label) is the label that was advertised from the destination 7705 SAR, as described in the previous paragraph. The MPLS packet is further encapsulated with either another MPLS label 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 a route distinguisher (RD), which identifies its VPRN association. Thus, the backbone core routers do not need to know the VPN routes.
Figure 87 shows an example of a VPRN network diagram, showing two VPNs (labeled “Red” and “Green”) attached to PEs. The core routers are labeled “P”.
RFC 2547bis requires the following features:
Tunneling protocol requirements are as follows:
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.
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.
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. |
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.
The three Type-Value combinations supported are described in Table 91.
Type Field | Value Field | Notes |
Type 0 | Administrator subfield (2 bytes) | The Administrator field must contain an AS number (using private AS numbers is discouraged) |
Assigned number subfield (4 bytes) | The Assigned field contains a number assigned by the service provider | |
Type 1 | Administrator subfield (4 bytes) | The Administrator field must contain an IP address (using private IP address space is discouraged) |
Assigned number subfield (2 bytes) | The Assigned field contains a number assigned by the service provider | |
Type 2 | Administrator subfield (4 bytes) | The Administrator field must contain a 4-byte AS number (using private AS numbers is discouraged) |
Assigned number subfield (2 bytes) | The Assigned field contains a number assigned by the service provider |
Routing information between the Provider Edge (PE) and Customer Edge (CE) can be exchanged by the following methods:
Each protocol provides controls to limit the number of routes learned from each CE router.
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.
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.
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.
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.
Protocol | Reverse Direction (Towards the 7705 SAR) | Forward Direction (From the 7705 SAR) |
FTP Passive and Active | Yes 1 | Yes 2 |
NTP | — | Yes 3 |
Radius | Yes | — |
SCP | Yes 1 | Yes 3 |
SNMP | Yes | — |
SNMP Trap | — | Yes |
SSH | Yes 1 | Yes 3 |
TACACS+ | Yes | — |
Telnet | Yes 1 | Yes 3 |
TWAMP | Yes 4 | Yes 5 |
Notes:
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.
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.
This section describes the 7705 SAR service features and any special capabilities or considerations as they relate to VPRN services:
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 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. |
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 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:
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.
Options and identification strings can be configured on several levels. DHCP servers support the following options, as defined in RFC 2132:
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:
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.
Similar to DHCP over Ethernet interfaces, Internet Protocol Control Protocol (IPCP) extensions to push IP information over PPP/MLPPP VPRN (and IES) SAPs are supported. Within this protocol, extensions can be configured to define the remote IP address and DNS IP address to be signaled via IPCP on the associated PPP interface. The IPCP-based IP and DNS assignment process is similar to DHCP behavior; IPCP-based IP/DNS assignment is a natural use of PPP/MLPPP IP layer protocol handshake procedures. PPP/MLPPP connected devices hooked up to VPRN (and IES) can benefit from this feature for the assignment of IP and DNS to the associated interface.
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.
IP ECMP allows the configuration of load balancing across all IP interfaces at the system level or interface level on the network side. You can include Layer 4 port attributes and/or the TEID attribute in the hashing algorithm with the l4-load-balancing and teid-load-balancing commands in the config>service>vprn>interface context. Configuration at the interface level overrides the system-level settings for the specific interface.
For more information on IP ECMP, refer to the 7705 SAR OS Router Configuration Guide, “Static Routes, Dynamic Routes, and ECMP”.
Proxy ARP is supported on VPRN interfaces.
Proxy ARP is a technique by which a router on one network responds to ARP requests intended for another node that is physically located on another network. The router effectively pretends to be the destination node by sending an ARP response to the originating node that associates the router’s MAC address with the destination node’s IP address (acts as a proxy for the destination node). The router then takes responsibility for routing traffic to the real destination.
For more information on proxy ARP, refer to the 7705 SAR OS Router Configuration Guide, “Proxy ARP”.
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.
Topics in this section include:
VPRN service also supports SAPs for IPSec tunnels (see IPSec Support).
The following SAP encapsulations are supported on the 7705 SAR VPRN service:
For each instance of VPRN service, QoS policies can be applied to the ingress and egress VPRN interface SAPs.
VPRN service ingress QoS policies only create the unicast queues defined in the policy. VPRN service egress QoS policies function in the same way as they do for other services, where the class-based queues are created as defined in the policy. Both the Layer 2 and Layer 3 criteria can be used in the QoS policies for traffic classification in a VPRN.
For VPRN services, the fabric mode needs to be set to aggregate mode as opposed to per-destination mode. VPRN services are only supported with aggregate-mode fabric profiles. When the fabric mode is set to per-destination mode, creation of VPRN service is blocked through the CLI. The user must change the fabric mode to aggregate mode before being able to configure VPRN services. As well, when a VPRN service is configured, changing from aggregate mode is blocked. The fabric mode is configured under the config>qos>fabric-profile context. For more information, refer to the 7705 SAR OS Quality of Service Guide.
For each instance of VPRN service, DSCP marking and dot1p marking for self-generated traffic QoS can be configured for the applications supported by the 7705 SAR.
For VPRN service, DSCP marking is configured in the vprn>sgt-qos>application context. For more information about DSCP marking and self-generated QoS traffic, see “CoS Marking for Self-generated Traffic” in the 7705 SAR OS Quality of Service Guide.
VPRN supports QinQ functionality. For details, see QinQ Support.
IPv4 filter policies can be applied to ingress and egress VPRN SAPs.
Configuration and assignment of IP filter policies is similar for network interfaces, IES management SAPs, Ethernet and IP pseudowire SAPs, VPRN and IES SAPs and spoke SDPs, and VPLS SAPs and SDPs (spoke and mesh). Refer to the 7705 SAR OS Router Configuration Guide, “Filter Policies”, for information on configuring IP filters.
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.
Using OSPF as a PE-to-CE routing protocol allows OSPF that is currently running as the IGP routing protocol to migrate to an IP-VPN backbone without changing the IGP routing protocol, introducing BGP as the PE-CE, or relying on static routes for the distribution of routes into the service provider’s IP-VPN.
The following features are supported:
TTL security provides protection for EBGP peering sessions against CPU utilization-based attacks such as denial of service (DoS) attacks. This feature is supported for directly connected peering sessions and for multihop EBGP peering sessions. The BGP session can be over spoke-SDP terminated VPRN interfaces, SAP interfaces, and loopback interfaces, as well as over router interfaces and IPSec interface tunnels.
TTL security is most important for EBGP PE-CE sessions because CE devices can be multiple hops away, which adds a higher level of risk. TTL security provides a mechanism to better ensure the validity of BGP sessions from the CE device.
For more information on TTL security, refer to the 7705 SAR OS Routing Protocols Guide, “TTL Security”.
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.
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.
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.
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.
For VPRN service, spoke SDPs can be used only for providing network connectivity between the PE routers.
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 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.
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.