Chapter 2

BGP/MPLS IP-VPN

The framework for building BGP/Multi-Protocol Label Switching (BGP/MPLS) based IP Virtual Private Networks (IP-VPNs) relies on Multi-Protocol BGP (RFC 4760) and the optional-transitive BGP Extended Communities (RFC 4360) attribute “Route Target.”

Multi-Protocol BGP is used for advertising of VPN-IPv4/VPN-IPv6 prefixes, and, because both are labeled prefixes, they follow the encoding of labeled BGP (RFC 3107), where the prefix is constructed of an 8-byte Route-Distinguisher followed by a 4-byte IPv4 prefix or 16-byte IPv6 prefix. The purpose of the RD is to allow the concatenation of RD and IPv4/IPv6 prefixes to create a unique VPN-IPv4/VPN-IPv6 prefix.

For VPN-IPv4 the AFI is 1 (IPv4), and for VPN-IPv6 the AFI is 2 (IPv6). Both VPN-IPv4 and VPN-IPv6 use a SAFI of 128 (MPLS-labeled VPN address).

Figure 2-1 VPN-IPv4/IPv6 NLRI Encoding

When a route is redistributed into VPN-IPv4, a Route Target Extended Community is appended to the prefix. The Route Target Extended Community is a transitive attribute (RFC 4360) used to define the set of sites belonging to a given VPN. When a VPN-IPv4 prefix is received at a Provider Edge (PE) router, it parses the Route Target value and checks whether any locally configured VRFs have an import policy that matches that value. If it does, the route is imported into that VPRN. If it doesn't, the route is not imported into any VPRNs. In short, associating a particular Route Target attribute with a prefix allows that route to be placed into VRFs serving that VPN. If ten sites in a VPN all have a common export and import Route Target value, the result is an “any-to-any” VPN.

Basic Configuration

Output 2-1 shows the base level of configuration required in order to configure a VPRN. The route-distinguisher (RD) is a required parameter when configuring a VPRN, and the VPRN will not become operational until it is configured. When a VPRN is configured with a Route-Distinguisher but without any Route Target parameters, the VPRN does not rely on any BGP/MPLS IP-VPN control plane for learning prefixes but simply creates a separate routing context frequently referred to as “VRF-lite.” The route-distinguisher command is followed by a value that can take three formats but typically uses the type 0 format of a 2-byte ASN subfield followed by a 4-byte assigned number subfield (the remaining 2 bytes are used to define the actual type).

To participate in the BGP/MPLS IP-VPN control plane, the definition of Route Target values is required for import and export of VPN-IPv4 prefixes. The simplest method is using the vrf-target command followed by a Route Target value that has the same format as the Route Distinguisher. The vrf-target command allows for definition of a single value applicable to import and export Route Targets as shown in Output 2-1, or it allows for definition of different import and export Route Target values using the export and import keywords after the vrf-target command, followed by the relevant Route Target values. An alternative to the vrf-target approach for defining Route Target values is to use the vrf-import and vrf-export commands to reference policies constructed within the policy framework.

When prefixes are learned in VPN-IPv4, the receiving PE router must resolve the BGP Next-Hop to a GRE or MPLS tunnel before the prefix is considered valid. The auto-bind command tells the system to automatically bind the Next-Hop to an LSP in the LSP tunnel-table, and the keyword mpls means to use any form of LSP, with a preference for RSVP over LDP, and LDP over BGP.

Output 2-1: VPRN Base Configuration

One last optional parameter is the definition of an autonomous-system number in the VPRN. This parameter is required only if BGP is used as a PE-CE routing protocol. This parameter is used as the source ASN in the OPEN exchange unless the local-as parameter is also configured, in which case the ASN defined as the local-as is used in the OPEN exchange. (This also applies to the use of local-as in the global BGP context.)

At face value, both the VPRN autonomous-system ASN and local-as ASN appear to serve the same purpose of mimicking an ASN that differs from the global ASN defined in the router context. In fact, they can have different impacts on the AS_PATH of UPDATE messages propagated to connected CE routers depending on two things:

• Their co-existence in configuration
• Whether the no-prepend-global-as argument is specified as part of the local-as definition

If configured on their own (they do not co-exist) the VPRN-level ASN or local-as ASN is appended to the AS_PATH advertised to the CE and overrides the global ASN. If they are configured to co-exist, the behavior differs depending on the setting of the local-as no-prepend-global-as parameter. If the no-prepend-global-as parameter is disabled, the local-as AS number is appended to the AS_PATH along with the VPRN-level AS number if it differs from the VPRN-level ASN. If the no-prepend-global-as parameter is enabled, the local-as AS number overrides the VPRN-level AS number.

The local-as parameter can be considered useful if a VPRN context needs to appear to be more than one ASN to its peers. If not, the VPRN-level ASN is sufficient. To consolidate the various options, consider the topology in Figure 2-2 where CE1 is in AS 64509 and advertises IPv4 prefix 172.31.100.0/24 to PE1, which in turn propagates the prefix to PE2, which in turn propagates the prefix to CE2. The AS_PATH as seen at CE2 with different configurations is shown in Table 2.1.

Figure 2-2 AS_PATH Encoding

Table 2.1 AS_PATH Encoding with VRF ASN and Local-AS

Prefix Dissemination

When a PE router belongs to a particular VPN, it learns some of that VPN's routes from attached CE routers using static or dynamic routing. These routes are installed in the VRF associated with that CE router and are converted to VPN-IPv4/IPv6 routes for export into BGP so that other PEs belonging to that VPN can learn those routes. These routes can be disseminated to other PE routers of the same VPN through a number of methods; some use an implicit flood model while others use an explicit send-only-if-required model. This section discusses the varying approaches that can be adopted for both prefix dissemination and route-table updates following a local policy change.

Automatic Route Filtering

To help scale BGP/MPLS based IP-VPNs, PE routers do not by default retain in the RIB-IN prefixes that are not associated with any configured VRFs. When a PE router receives a VPN-IPv4/IPv6 prefix with a Route Target value that is not associated with any VRFs on that PE, the prefix is simply discarded (unless, of course, the PE is a Route-Reflector). This approach is known as Automatic Route Filtering (ARF) and ensures that PE routers hold routes only for VRFs that are actually configured on that PE. It is enabled by default and requires no configuration. In the example illustrated in Debug 2-1, the PE router receives VPN-IPv4 prefix 64496:30:172.16.100.0/24 with Extended Community Route Target 64496:30 but has no configured VRFs with that Route Target value. The PE router therefore silently discards the prefix as shown in Output 2-2.

Debug 2-1: Automatic Route Filtering

Output 2-2: ARF and RIB-IN

Route Refresh

ARF is useful for optimizing memory consumption, but what...