VPRN service overview

RFC 2547bis requires the following features:

• multiprotocol extensions

• LDP support

• extended BGP community support

• BGP capability negotiation

• parameters defined in RFC 2918, BGP Route Refresh, and RFC 2796, Route Reflector

• a 4-byte autonomous system (AS) number

Tunneling protocol requirements are as follows:

• RFC 2547bis, BGP/MPLS VPNs, recommends implementing Label Distribution Protocol (LDP) to set up a full mesh of LSPs based on the IGP

• MPLS RSVP-TE tunnels can be used instead of LDP

• BGP route tunnels can be used as defined in RFC 3107

• alternatively, generic routing encapsulation (GRE) tunnels can be used

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. In addition, 128-bit VPN-IPv6 addresses extend the capability to distribute VPRN routing information.

BGP route tunnels can be used to distribute label mapping information for a particular route, as defined in RFC 3107. For more information about BGP route tunnels, see the 7705 SAR Routing Protocols Guide, ‟BGP route tunnel”.

VPRN BGP is configured through the config>service>vprn>bgp context. Global BGP is configured through the config>router>bgp context.

The 7705 SAR supports IPSec and IPSec tunnels, where VPRN or 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 public-side IPSec tunnel SAP is tunnel-1.public:tag. The sap-id for a private-side IPSec tunnel SAP is tunnel-1.private:tag

For more information, see the IPSec chapter in this guide.

The 7705 SAR supports a number of mechanisms for node security, including access control lists (ACLs), network address translation (NAT), and stateful, zone-based firewalls. For information about ACLs, NAT, and firewalls, see the 7705 SAR Router Configuration Guide, ‟Configuring security parameters”.

NAT and firewall security configurations are both based on zones. Zones segment a network, making it easier to control and organize traffic. A zone consists of a group of Layer 2 endpoints or Layer 3 interfaces with common criteria, bundled together. Security policies, which define a set of rules that determine how NAT or firewall should direct traffic, can be applied to the entire zone or to multiple zones. Layer 3 zones support both NAT and firewall security policies. Layer 2 zones support only firewalls. To enable NAT or firewall functionality, security policy and profile parameters must be configured under the config>security context in the CLI, and a security zone must be configured under one or more of the following contexts:

• config>router>zone

• config>service>epipe>zone

• config>service>vpls>zone

• config>service>vprn>zone

Layer 2 and Layer 3 firewalls share system resources; that is, they share the maximum number of policies, profiles, and session ID space supported by the system.

A zone is created by adding at least one Layer 2 endpoint or Layer 3 interface to the zone configuration. Multiple zones can be created within each Layer 3 service or within the router context. Layer 2 services support only one zone. Layer 2 endpoints or Layer 3 interfaces from different services cannot be grouped into a single common zone. The following table lists the supported interfaces and endpoints that can be added to zones in each CLI context for NAT or firewall.

A zone configured in the VPRN context could be used to create border security for Layer 3 service traffic traversing from the secure edge VPRN into the network core.

The following figure shows a firewall on a VPRN, where the core of the network is protected from access devices and from any traffic entering the VPRN through the transport tunnel. A VPRN configured with access security policies can also protect access networks or LANs from each other.

A security zone can also be created with spoke SDPs or autobind tunnels that have been configured for a VPRN service using MP-BGP. For autobind tunnels, the auto-bind-tunnel resolution-filter type can be set to gre, ldp, rsvp, sr-isis, sr-ospf, or sr-te. When a zone contains spoke SDPs or autobind MPLS tunnels, it cannot contain any other type of interface. A zone configured with spoke SDPs or autobind MPLS tunnels will firewall traffic arriving from the access side to this zone for any MP-BGP transport tunnel residing in that Layer 3 service. After a security zone is created for MP-BGP transport tunnels, all MP-BGP transport tunnels going to far-end peers are part of this zone. Traffic entering or exiting the zone is firewalled; however, traffic traveling from one autobind tunnel to another within the same zone is not firewalled.

With static one-to-one NAT, NAT is performed on packets traveling from an inside (private) interface to an outside (public) interface or from an outside interface to an inside interface. Static one to-one NAT can be applied to a single IP address or a subnet of IP addresses and is performed on the IP header of a packet, not on the UDP/TCP port.

Mapping statements, or entries, can be configured to map an IP address range to a specific IP address. The direction of the NAT mapping entry dictates whether NAT is performed on a packet source IP address or subnet or on a packet destination IP address or subnet. The 7705 SAR supports inside mapping entries that map an inside IP address range to an outside IP address range sequentially.

With an inside mapping entry, the following points apply:

• Packets that originate from an inside interface and are destined for an inside interface are forwarded without any NAT being applied.

• If there is a matching one-to-one NAT mapping entry, packets that originate from an inside interface and are destined for an outside interface undergo static one-to-one NAT where NAT changes the source IP address of the packet IP header. The packet is forwarded whether or not a NAT mapping entry is found unless the drop-packets-without-nat-entry command is enabled. When a mapping entry is not found and the drop-packets-without-nat-entry command is enabled, the packet is not forwarded.

• If there is a matching one-to-one NAT mapping entry, packets that originate from an outside interface and are destined for an inside interface undergo static one-to-one NAT where NAT changes the destination IP address of the packet IP header. The packet is forwarded whether or not a NAT mapping entry is found unless the drop-packets-without-nat-entry command is enabled. When a mapping entry is not found and the drop-packets-without-nat-entry command is enabled, the packet is not forwarded.

• Packets that originate from an outside interface and are destined for an outside interface are forwarded without any NAT being applied.

Static one-to-one NAT is supported in the GRT and in VPRNs. For more information about static one-to-one NAT, see the 7705 SAR Router Configuration Guide, ‟Static one-to-one NAT”.

For VPRNs, one-to-one NAT can be configured between an inside interface and a outside MP-BGP MPLS transport tunnel interface. Policies should be used to not leak the inside interface/IP address via MP-BGP to the peer. Policies should be used to leak the NAT routes to the MP-BGP peer.

The following table lists the types of outside and inside interfaces that are supported in a VPRN for one-to-one NAT.

The 7705 SAR supports unicast-to-multicast address translation and multicast-to-multicast address translation.

For unicast-to-multicast translation, the 7705 SAR translates the destination IP address of the unicast flow to a multicast group. For multicast-to-multicast translation, the 7705 SAR acts as a host to upstream (S,G)s and performs address translation to the downstream (S,G).

Unicast and multicast address translation is supported on the following adapter cards and platforms:

• on the 7705 SAR-8 Shelf V2 and the 7705 SAR-18:

  • 2-port 10GigE (Ethernet) Adapter card

  • 6-port Ethernet 10Gbps Adapter card

  • 8-port Gigabit Ethernet Adapter card, version 3

  • 10-port 1GigE/1-port 10GigE X-Adapter card, version 2 (supported on the 7705 SAR-18 only)

• 7705 SAR-Ax

• 7705 SAR-H

• 7705 SAR-Hc

• 7705 SAR-Wx

• 7705 SAR-X

Unicast and multicast address translation is supported in the GRT and in VPRNs. For VPRNs, IPv4 addressing on SAP-to-SAP connections is supported.

For more information about unicast-to-multicast address translation and multicast-to-multicast address translation, see the 7705 SAR Routing Protocols Guide, ‟Unicast and multicast address translation”.

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 implementation supports the three (3) Type-Value combinations, as defined in RFC 2547bis. The following figure illustrates the RD structure.

The three Type-Value combinations supported are described in the following table.

Route target constraint (RTC) is a mechanism that 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. Upon receiving RTC route information, peers restrict the advertised VPN routes to only those requested, minimizing control plane load in terms of protocol traffic and potentially reducing RIB memory usage.

The route target membership information is carried using MP-BGP, using an AFI value of 1 and SAFI value of 132. The NLRI of an RTC route encodes an Origin AS and a route target extended community using prefix type encoding with host bits after the prefix-length set to zero.

In order for two routers to exchange route target membership NLRI, they must advertise the corresponding AFI and SAFI to each other during capability negotiation. The use of MP-BGP means route target membership NLRI are propagated, loop-free, within an autonomous system and between autonomous systems, using well-known BGP route selection and advertisement rules.

Route target constrained route distribution and outbound route filtering (ORF) both allow routers to advertise which route target extended communities they want to receive in VPN routes from peers. RTC, however, is more widely supported, is simpler to configure, and its distribution scope is not limited to a direct peer.

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 a destination IP address in the packet header matches any system IP address configured under grt-lookup with a GRT static-route-entry set to the system IP address specified under vprn>static-route-entry>grt, the packet is extracted to the CSM for processing. If the vprn>grt-lookup>enable-grt>allow-local-management command is not enabled, the packet is routed using the 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 allow-local-management 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 configured under vprn>static-route-entry>grt. If the command allow-local-management is enabled under the VPRN instance, a packet arriving on a transport tunnel will be extracted to the CSM before hitting the blackhole route. In this case, the only effect of the blackhole route will be to advertise the system IP address to the far-end peer. If the command allow-local-management is not enabled, packet forwarding will be the default forwarding mode; that is, all packets destined for the system IP address will be blackholed because of the static route configuration.

For MP-BGP VPRNs, when the command allow-local-management 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 local IP address and destination IP address of either the far-end NSP NFM-P 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 FIB using the export-grt command. The route installed in the GRT FIB 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.

The following table lists the management protocols supported by IPv4 and IPv6 GRT in the reverse and forward directions.

Notes:

1. Supported, if the 7705 SAR is acting as a server

2. Supported, if the 7705 SAR is acting as an active client

3. Supported, if the 7705 SAR is acting as a client

4. Supported on IPv4 only

5. Supported, if the 7705 SAR is acting as a server (control packets)

6. Supported, if the 7705 SAR is acting as a session reflector (test packets)

The following figure shows an example of IPv4 in-band management of the 7705 SAR and the switches behind it by the NSP NFM-P and a TACACS+ server. In the example, an IPSec tunnel is being used as the VPRN 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 allow-local-management is configured for the VPRN, packets arriving on the 192.168.0 subnet are treated as follows:

• If the packet destination IP address is 192.168.0.2, the packet is extracted to the CSM to be processed as management traffic.

• If the packet is destined for subnet 192.168.0.x/29, it is forwarded out of interface 192.168.0.1.

On network egress in the above example, routing is as follows:

• A static route can be installed in the 7705 SAR VPRN for subnet 192.168.1.0/24 with a next hop to IPSecTunnel_1.

• A route policy can be created with an IP address prefix of 192.168.1.0/24 and an action to accept. This route policy is configured under the config>router>policy-options context, and can be exported to the GRT FIB using the export-grt command.

• The above configuration will add route 192.168.1.0/24 to the GRT FIB with the next hop being the corresponding VPRN IPSec tunnel. This entry will force the CSM-generated packets destined for the 192.168.1.x subnet to be resolved by the VPRN IPSec tunnel.

The following figure shows an example of IPv6 in-band management of the 7705 SAR and the switches behind it by the NSP NFM-P and a TACACS+ server.

On network ingress in the above example, the 7705 SAR system IP address is in the same subnet as the local interface IPv6 VPRN address. When allow-local-management is configured for the IPv6 VPRN, packets arriving on the fd00:1:1:1 subnet are treated as follows:

• If the packet destination IP address is fd00:1:1:1::2, the packet is extracted to the CSM to be processed as management traffic.

• If the packet is destined for subnet fd00:1:1:1::/64, it is forwarded out of interface fd00:1:1:1::1.

On network egress in the above example, routing is as follows:

• A static route can be installed at the 7705 SAR VPRN for subnet fd00:1:129:1::/64 with a next hop to IPSecTunnel_1.

• A route policy can be created with an IP address prefix of fd00:1:129:1::/64 and an action to accept. This route policy is configured under the config>router>policy-options context, and can be exported to the GRT FIB using the export-grt command.

  The above configuration adds route fd00:1:129:1::/64 to the GRT FIB with the next hop being the corresponding VPRN IPSec tunnel. This entry forces the CSM-generated packets destined for the fd00:1:129:1::x subnet to be resolved by the VPRN IPSec tunnel.