VPRN Features

Unnumbered interfaces are supported on VPRN and IES services for IPv4. Unnumbered interfaces are point-to-point interfaces that are not explicitly configured with a dedicated IP address and subnet; instead, they borrow (or link to) an IP address from another interface on the system (the system IP address, another loopback interface, or any other numbered interface) and use it as the source IP address for packets originating from the interface.

This feature is supported via both dynamic and static ARP for unnumbered interfaces to allow interworking with unnumbered interfaces that may not support dynamic ARP.

The use of unnumbered interfaces has no effect on IPv6 routes; however, the unnumbered command must only be used in cases where IPv4 is active (IPv4 only and mixed IPv4/IPv6 environments). When using an unnumbered interface for IPv4, the loopback address used for the unnumbered interface must have an IPv4 address. The interface type for the unnumbered interface is automatically point-to-point.

DHCP is a configuration protocol used to communicate network information and configuration parameters from a DHCP server to a DHCP-aware client. DHCP is based on the BOOTP protocol, with additional configuration options and the added capability of allocating dynamic network addresses. DHCP-capable devices are also capable of handling BOOTP messages.

A DHCP client is an IP-capable device (typically a computer or base station) that uses DHCP to obtain configuration parameters such as a network address. A DHCP server is an Internet host or router that returns configuration parameters to DHCP clients. A DHCP/BOOTP Relay agent is a host or router that passes DHCP messages between clients and servers.

DHCPv6 is not based on, and does not use, the BOOTP protocol.

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

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

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

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

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

The 7705 SAR supports a maximum of 16 servers per node on the 7705 SAR-A, 7705 SAR-Ax, 7705 SAR-H, 7705 SAR-Hc, 7705 SAR-M, 7705 SAR-Wx, and 7705 SAR-X. The 7705 SAR supports a maximum of 62 servers per node on the 7705 SAR-8 Shelf V2 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.

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 IGP and BGP protocols, including 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 route is declared ‟not active”, causing a reroute to an alternative path, if any.

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.

VRRP can be implemented on VPRN service interfaces to participate as part of a virtual router instance. This implementation prevents a single point of failure by ensuring access to the gateway address, which is configured on all VPRN service interfaces in the VRRP. VRRPv3 can also be implemented on VPRN service interfaces, including r-VPLS interfaces for VPRN.

The 7705 SAR supports VRRPv3 for IPv4 and IPv6 as described in RFC 5798. Within a VRRP router, the virtual routers in each of the IPv4 and IPv6 address families are a domain unto themselves and do not overlap.

For information on VRRP and VRRP VPRN service interface parameters, as well as the configuration parameters of VRRP policies, see the ‟VRRP” section in the 7705 SAR Router Configuration Guide. CLI command descriptions for VRRP policies are also given in the 7705 SAR Router Configuration Guide.

For CLI command descriptions related to VPRN service interfaces, see VPRN Services Command Reference.

IP ECMP allows the configuration of load balancing across all IP interfaces at the system level or interface level on the network side. Layer 4 port attributes and the TEID attribute in the hashing algorithm can be configured with the l4-load-balancing and teid-load-balancing commands in the config>service>vprn> interface context. Configuration of the l4-load-balancing command at the interface level overrides the system-level settings for the specific interface. The teid-load-balancing command can only be configured at the interface level.

The system IP address can be included in or excluded from the hashing algorithm with the system-level system-ip-load-balancing command.

For more information about IP ECMP, see the 7705 SAR 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 about proxy ARP, see the 7705 SAR 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.

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

The 7705 SAR allows timers to be configured on a VPRN or IES IPv4 or IPv6 interface or on the base router to keep the IP interface in an operationally up or down state for a specified time beyond when it should be declared operationally up or down. The timers are configured at the VPRN service level using the config>service>vprn>interface>hold-time>up/down commands.

An init-only option enables the down delay to be applied only when the IP interface is first configured or after a system reboot. See Internet Enhanced Service for information about how to configure the hold-time command on IES interfaces. See the 7705 SAR Router Configuration Guide for information about how to configure the hold-time command at the router level.

The configuration causes the system to delay sending notifications of any state change associated with the IP interface until the timer has expired.

The following SAP encapsulations are supported on the 7705 SAR VPRN service:

• Ethernet null

• Ethernet dot1q

• Ethernet qinq

• PPP

• MLPPP

• MC-MLPPP

• LAG

For each instance of VPRN service, QoS policies can be applied to the ingress and egress VPRN interface SAPs.

At VPRN access ingress, traffic can be classified as unicast or multicast traffic types. In a VPRN access ingress QoS policy, users can create queues that map to forwarding classes. For each forwarding class, traffic can be assigned to a queue that is configured to support unicast, multicast, or both. As shown in the following example, for fc ‟af”, both unicast and multicast traffic use queue 2, and for fc ‟l2”, only multicast traffic uses queue 3.

configure qos sap-ingress qos 2 create
            queue 1 create
            exit
            queue 2 create
            exit
            queue 3 create
            exit
            fc "af" create
                queue 2 
                multicast-queue 2
            exit
            fc "l2" create
                multicast-queue 3
            exit

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 must 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, see the 7705 SAR Quality of Service Guide.

VPRN supports QinQ functionality. For details, see QinQ Support.

IPv4 and IPv6 filter policies can be applied to ingress and egress VPRN SAPs.

See the 7705 SAR Router Configuration Guide, ‟Filter Policies”, for information about configuring IP filters.

Using OSPF or OSPFv3 as a PE-to-CE routing protocol allows the version of 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:

• transportation of OSPF/OSPFv3 learned routes as OSPF/OSPFv3 externals

  This feature uses OSPF or OSPFv3 as the protocol between the PE and CE routers; however, instead of transporting the OSPF/OSPFv3 LSA information across the IP-VPN, the OSPF/OSPFv3 routes are ‟imported” into MP-BGP as AS externals. As a result, other OSPF- or OSPFv3-attached VPRN sites on remote PEs receive these via type 5 LSAs.

• advertisement/redistribution of BGP-VPN routes as summary (type 3) LSAs flooded to CE neighbors of the VPRN OSPF/OSPFv3 instance

  This occurs if the OSPF or OSPFv3 route type (in the OSPF/OSPFv3 route type BGP extended community attribute carried with the VPN route) is not external (or NSSA) and the locally configured domain ID matches the domain ID carried in the OSPF/OSPFv3 domain ID BGP extended community attribute carried with the VPN route.

• sham links

  A sham link is a logical PE-to-PE unnumbered point-to-point interface that rides over the PE-to-PE transport tunnel. A sham link can be associated with any area and can appear as an intra-area link to CE routers attached to different PEs in a VPN.

  Sham links are not supported on OSPFv3.

• import policies

  By default, OSPF imports all the routes advertised via LSAs. Import policies allow routes that match a certain criteria, such as neighbor IP addresses, to be rejected. Users must use caution when applying import policies, since not using certain routes may result in network stability issues.

  Import policies are supported within the VPRN context and the base router context. Import policies are not supported on OSPFv3.

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 about TTL security, see the 7705 SAR Routing Protocols Guide, ‟TTL Security”.

This section focuses on IP-VPN multicast functionality. As a prerequisite for MVPN, readers should be familiar with the ‟IP Multicast” material in the 7705 SAR Routing Protocols Guide, where multicast protocols (PIM, IGMP, and MLD) are described.

Applications for this feature include enterprise customers implementing a VPRN solution for their WAN networking needs, video delivery systems, and customer applications that include stock-ticker information as well as financial institutions for stock and other types of trading data.

Implementation of next-generation VPRN (NG-VPRN) requires the separation of the provider’s core multicast domain from customer multicast domains, and the customer multicast domains from each other.

Multicast in an IP-VPN Application shows an example of multicast in an IP-VPN application and shows the following domains:

• provider's domain

  • core routers (1 through 4)

  • edge routers (5 through 10)

• customers’ IP-VPNs, each having their own multicast domain

  • VPN-1 (CE routers 12, 13, and 16)

  • VPN-2 (CE routers 11, 14, 15, 17, and 18)

In this VPRN multicast example, VPN-1 data generated by the customer behind router 16 is multicast by PE router 9 to PE routers 6 and 7 for delivery to CE routers 12 and 13, respectively. VPN-2 data generated by the customer behind router 15 is forwarded by PE router 8 to PE routers 5, 7, and 10 for delivery to CE routers 11 and 18, 14, and 17, respectively.

The demarcation points for these domains are in the PEs (routers 5 through 10). The PE routers participate in both the customer multicast domain and the provider multicast domain. The customer CEs are limited to a multicast adjacency with the multicast instance on the PE, where the PE multicast instance is specifically created to support that specific customer IP-VPN. As a result, customers are isolated from the provider core multicast domain and other customer multicast domains, while the provider core routers only participate in the provider multicast domain and are isolated from all customer multicast domains.

The PE for a customer's multicast domain becomes adjacent to the CE routers attached to that PE and to all other PEs that participate in the IP-VPN (customer) multicast domain. The adjacencies are set up by the PE that encapsulates the customer multicast control data and the multicast streams inside the provider's multicast packets. The encapsulated packets are forwarded only to the PE nodes that are attached to the same customer's edge routers as the originating stream and are part of the same customer VPRN. This process prunes the distribution of the multicast control and data traffic to the PEs that participate in the customer's multicast domain.

This section includes information about the following topics:

• PMSI

• MVPN Using BGP Control Plane

• Auto-Discovery

• PE-CE Multicast Protocols and Services

• PE-PE Transmission of C-Multicast Routing Using BGP

• PE-PE Multicast Protocols

• PE-PE Multicast Data Transmission

The following provider tunnel features are supported:

• I-PMSI

• S-PMSI

Topics in this section include:

• Point-to-Multipoint I-PMSI and S-PMSI

• Point-to-Multipoint LDP I-PMSI and S-PMSI

• Point-to-Multipoint LSP S-PMSI

• MVPN Sender-only and Receiver-only

An MVPN service that spans more than one AS is called an inter-AS MVPN. As is the case with unicast-only IP VPN services, there are different approaches for supporting inter-AS MVPNs. Generally, the approaches belong to one of two categories:

• all P-tunnels and P-multicast trees start and end on PEs and ASBRs in the same AS

• P-tunnels and P-multicast trees extend across multiple ASs

In the first category, the P-tunnels and P-multicast trees start on PEs and ASBRs of an AS, and end on PEs and ASBRs in that same AS (extending no further). In this scenario, C-multicast traffic that must cross an AS boundary is handed off natively between the ASBRs on each side of the AS boundary.

From the perspective of each ASBR, the other ASBR is simply a collection of CEs, each reachable through separate logical connections (for example, VPRN SAPs). In this type of deployment, no auto-discovery signaling is required between the different ASs, and the exchange of C-multicast routes and C-multicast signaling uses the same protocols and procedures as described in PE-CE Multicast Protocols and Services for PE-CE interfaces.

In the second category, P-tunnels and P-multicast trees extend across the boundaries between different ASs. In this scenario, the PMSI extends end-to-end between the PEs of the MVPN, even when those PEs are in different ASs. ASBRs need to exchange auto-discovery information in order to determine whether, for a given MVPN:

• the neighbor AS has PEs with sites in the MVPN

• the neighbor AS is a transit node on the best path to a remote AS that has sites of the MVPN

If a P-multicast tree is used to transport the PMSI, there are two options for extending the P-tree across multiple ASs:

• non-segmented inter-AS MDT

  The end-to-end P-tree is end-to-end between all the PEs supporting the MVPN, passing through ASBRs as necessary.

• segmented inter-AS MDT (see Inter-AS Option B: Non-Segmented Solution)

  The end-to-end P-tree is formed by stitching together a sub-tree from each AS. A sub-tree of an AS connects only the PEs and ASBRs of that AS. A point-to-point tunnel between ASBRs on each side of an AS boundary is typically used to stitch the sub-trees together.

Constructing and using a non-segmented inter-AS MDT is similar to constructing and using an intra-AS MDT, except that BGP auto-discovery messages are propagated by ASBRs across AS boundaries, where the BGP auto-discovery messages are I-PMSI intra-AS auto-discovery routes, despite the reference to intra-AS.

When segmented inter-AS tunnels are used for an NG-MVPN, the ASBRs configured to support that MVPN will originate inter-AS I-PMSI auto-discovery routes for that MVPN toward their external peers after having received intra-AS I-PMSI auto-discovery routes for the MVPN from one or more PEs in their own AS. The inter-AS I-PMSI auto-discovery messages are propagated through all ASs that support the MVPN (that is, through all ASs that have PEs or ASBRs for the MVPN).

When an ASBR receives an inter-AS I-PMSI auto-discovery route, and it is the best route for the NLRI, the ASBR sends a leaf auto-discovery route to the exterior Border Gateway Protocol (EBGP) peer that advertised the route. The leaf auto-discovery route is used to set up a point-to-point, one-hop MPLS LSP that stitches together the P-multicast trees of each AS.

The 7705 SAR supports inter-AS and intra-AS option A.

The 7705 SAR supports non-segmented inter-AS and intra-AS Option C as an ABR or ASBR router or as a leaf router. The 7705 SAR can be part of non-segmented inter-AS and intra-AS with Option B as a root node.

This feature allows multicast services to use segmented protocols and span them over multiple autonomous systems (ASs) in the same way as unicast services. Because IP VPN or GRT services span multiple IGP areas or multiple ASs, either for a network designed to deal with scale or as result of commercial acquisitions, operators may require inter-AS VPN (unicast) connectivity. For example, an inter-AS VPN can break the IGP, MPLS and BGP protocols into access segments and core segments, allowing higher scaling of protocols by segmenting them into their own islands. The 7705 SAR allows for a similar provisioning of multicast services and for spanning these services over multiple IGP areas or multiple ASs.

For unicast VPRNs, inter-AS or intra-AS Option C breaks the IGP, BGP and MPLS protocols at ABR routers (for multiple IGP areas) and ASBR routers (for multiple ASs). At ABR and ASBR routers, a stitching mechanism of MPLS transport is required to allow transition from one segment to the next, as shown in Unicast VPN Option C with Segmented MPLS.

In Unicast VPN Option C with Segmented MPLS, the 3107 BGP Label Route (LR) is stitched at ASBR1 and ASBR3. At ASBR1, the LR1 is stitched with LR2, and at ASBR3, the LR2 is stitched with TL2.

Previously, segmenting an LDP MPLS tunnel at ASBRs or ABRs was not possible with NG-MVPN. Therefore, RFC 6512 and 6513 used a non-segmented mechanism to transport the multicast data over P-tunnels end-to-end through ABR and ASBR routers. The signaling of LDP needed to be present and possible between two ABR routers or two ASBR routers in different ASs.

For unicast VPNs, it was usually preferred to only have EBGP between ASBR routers.

The 7705 SAR now has non-segmented intra-AS and inter-AS signaling for NG-MVPN. The non-segmented solution is possible for inter-ASs as Option C.

When using mrinfo and mtrace in a Layer 3 VPN context, the configuration for the VPRN should have a loopback address configured that has the same address as the core VPRN instance's system address (that is, the BGP next hop).

For more information, see the ‟IP Multicast Debugging Tools” section in the 7705 SAR OAM and Diagnostics Guide.

The 7705 SAR supports MoFRR in the context of GRT for mLDP. The multicast traffic is duplicated on a primary mLDP multicast tree and a secondary mLDP multicast tree.

For more information, see the ‟Multicast-only Fast Reroute (MoFRR)” section in the 7705 SAR Routing Protocols Guide.

The 7705 SAR supports mLDP point-to-multipoint traffic.

For more information, see the ‟LDP Point-to-Multipoint Support” section in the 7705 SAR MPLS Guide.

This feature allows a downstream LSR of an mLDP FEC to perform a fast switchover in order to source the traffic from another upstream LSR while IGP and LDP are converging due to a failure of the upstream LSR, where the upstream LSR is the primary next hop of the root LSR for the point-to-multipoint FEC.

For more information, see the ‟Multicast LDP Fast Upstream Switchover” section in the 7705 SAR MPLS Guide.

7705 SAR supports Multicast Source Discovery Protocol (MSDP) for MVPNs.

MSDP is a mechanism that allows rendezvous points (RPs) to share information about active sources. When RPs in remote domains hear about the active sources, they can pass on that information to the local receivers and multicast data can be forwarded between the domains. MSDP allows each domain to maintain an independent RP that does not rely on other domains, but it also enables RPs to forward traffic between domains. PIM-SM is used to forward the traffic between the multicast domains.

In addition to supporting MSDP on MVPNs in the VPRN service context, the 7705 SAR supports MSDP in the base router context. For information about MSDP, see the 7705 SAR Routing Protocols Guide.

In an MVPN, a PE node can act as an RP and run the MSDP functionality.

To interconnect multicast domains and to learn about source in other domains, MSDP peering is maintained between RP nodes. MSDP peering occurs over a TCP connection and control information is exchanged between peers to learn about multicast sources in other domains and to distribute information about multicast sources in the local domain.

When MSDP is configured in a service provider MVPN for a given IP VPN customer, at least one of the PEs that are part of that MVPN becomes an MSDP peer to customer-instance RPs. MSDP groups are configured on PEs to limit source-active (SA) advertisements to routers within a group. As the PE RP learns about multicast sources within its domain via PIM-SM, it encapsulates the first data packet in an MSDP SA message and distributes it to all of its peer RP nodes. Based on the RPF check, each peer node sends the control message to other peers to distribute information about the active source. If there is an existing entry for the multicast group, the RP node joins the shortest path tree towards the source.

OAM tests require a minimum network port MTU in order to run; this value depends on the test. If the port MTU is set to a value lower than the minimum requirement, the test will fail.

If the port MTU is set to a value that meets the minimum requirement, the packet size parameter can be configured for the test (for example, oam sdp-ping 1 size 102).

If the size parameter is not specified, the system builds the packet based on the default payload size. If the size parameter is configured and is greater than the default payload size, padding bytes are added to equal the configured value.

The packet size is dependent on the port MTU value; that is, if the minimum port MTU value is used, there are restrictions on the packet size. If the configured size is greater than the maximum value supported with the minimum port MTU, the test will fail.

Port MTU Requirements for OAM Diagnostics (GRE Tunnels) and Port MTU Requirements for OAM Diagnostics (LDP Tunnels) list the minimum port MTU required for each OAM test and the maximum size of the OAM packet that can be configured when the minimum port MTU is used, based on SDP tunnel type.

Note:

1. Size is not configurable

Note:

1. Size is not configurable

For information about OAM diagnostics, see the 7705 SAR OAM and Diagnostics Guide.