6PE—backbone configuration at Junos PEs

Example 3-1 shows the relevant core-facing configuration at PE1.

1     protocols {
2         mpls {
3             ipv6-tunneling;
4         }
5         bgp {
6             group iBGP-RR {
7                 family inet6 {
8                     labeled-unicast;
9     }}}}

So it looks like IPv6 packets are to be tunneled in MPLS (line 3). The internal BGP (iBGP) sessions convey IPv6 Labeled Unicast (AFI=2, SAFI=4) prefixes, instead of unlabeled IPv6 Unicast (AFI=2, SAFI=1) ones. You’ll see more about this in the signaling section.

6PE—backbone configuration at IOS XR PEs

Here is the relevant core-facing configuration at PE2:

1     router bgp 65000
2      address-family ipv6 unicast
3       allocate-label all
4      !
5      neighbor-group RR
6       address-family ipv6 labeled-unicast
7     !

The principle is the same as in Junos. PE2 assigns MPLS labels to IPv6 prefixes, and this information is sent via iBGP to the RRs. In addition, PEs exchange unlabeled prefixes with CEs via eBGP. Later in the chapter, see Example 3-8, line 10.

6PE—access configuration at Junos PEs

Example 3-5 shows the access configuration at PE1. The only logical interface and eBGP session displayed correspond to the PE1-CE1 link.

1     interfaces {
2         ge-2/0/1 {
3             unit 1001 {
4                 vlan-id 1001;
5                 family inet address 10.1.0.1/31;
6                 family inet6 address fc00::10:1:0:1/127;
7     }}}
8     protocols {
9         bgp {
10            group eBGP-65001 {
11                family inet unicast;
12                family inet6 unicast;
13                peer-as 65001;
14                neighbor 10.1.0.0 export PL-eBGP-CE1-OUT;
15    }}}
16    policy-options {
17        policy-statement PL-eBGP-CE1-OUT {
18            term BGP {
19                from protocol bgp;
20                then metric 100; 
21            }
22            term IPv6 {
23                from family inet6;
24                then next-hop fc00::10:1:0:1; 
25    }}}

As you can see, the logical interface is dual-stacked (lines 5 and 6). Both IPv4 and IPv6 unicast (lines 11 and 12) prefixes can be exchanged on top of one single eBGP session (line 14).

The BGP next-hop rewrite in line 24 is essential. Without it, PE1 would advertise IPv6 routes to CE1 in the format shown in Example 3-6.

juniper@PE1> show route advertising-protocol bgp 10.1.0.0 detail
             table inet6.0

* fc00::10:2:34:0/112 (2 entries, 1 announced)
     [...]
     Nexthop: ::ffff:10.1.0.1

In classical IPv6 notation, ::ffff:10.1.0.1 is ::ffff:0a01:0001. This is an IPv4-mapped IPv6 address, automatically derived from 10.1.0.1. But, the PE1-CE1 link is configured with IPv6 network fc00::10:1:0:0, which is totally different—watch out for hex colon versus decimal dot. Hence, the need for a BGP next-hop rewrite: without it, CE1 would not be able to resolve the BGP next hop. The same technique must be applied for prefixes announced by CE1 to PE1. Following is the next hop after the policy is applied.

juniper@PE1> show route advertising-protocol bgp 10.1.0.0 detail table inet6.0

* fc00::10:2:34:0/112 (2 entries, 1 announced)
     [...]
     Nexthop: fc00::10:1:0:1

As a more complex alternative, you can install the ::ffff:10.1.0.1/128 route into inet6.3, which is the auxiliary table to resolve BGP next hops in IPv6 format. This technique is illustrated in Chapter 9.

6PE—access configuration at IOS XR PEs

Following is the access configuration at PE2. The only logical interface and eBGP session displayed correspond to the PE2-CE2 link.

1     interface GigabitEthernet0/0/0/0.1001
2      ipv4 address 10.1.0.3 255.255.255.254
3      ipv6 address fc00::10:1:0:3/127
4      encapsulation dot1q 1001
5     !
6     router bgp 65000
7      address-family ipv6 unicast
8      neighbor 10.1.0.2
9       remote-as 65001
10      address-family ipv6 unicast
11       route-policy PL-eBGP-65001-IN in
12       route-policy PL-eBGP-CE2-OUT out
13    !

The principle is very similar to Junos, except that IOS XR PE2 automatically performs the BGP next-hop rewrite (to fc00::10:1:0:3) on its IPv6 advertisements to CE2.

The eBGP route policies (lines 11 and 12) basically pass all the prefixes (see Chapter 1).

6PE—why is there a service label?

PE4 pops the service label and maps the packet to the Internet Global IPv6 Routing Table. Does PE4 really need the service label? Not really. If PE4 had received a native IPv6 packet on its core uplink Gi 0/0/0/0, it would still have mapped the packet to the global routing table. And it would know that it is an IPv6 packet due to the Layer 2 (L2) header’s Ethertype, not to mention that the first nibble (four bits) of the packet is 6.

So, why is there a service MPLS label? The main reason is PHP. The 6PE model was developed assuming that no LSR (including the penultimate one) supports IPv6 on its core uplinks. If PE1 had only pushed the transport MPLS label, this would be the Bottom of Stack (BoS) label. After popping it, P2 inspects the resulting packet and finds a first nibble with value 6. This is definitely not an IPv4 packet, whose first nibble would be 4. So far, no problem: P2 should be able to send the packet to the egress PE (PE4), as dictated by the LSP. But there is one snag: after all this popping, the packet has no L2 header.

In IPv4, the solution is easy: P2 builds an L2 header with Ethertype 0x0800 (IPv4) and a destination MAC address corresponding to PE4—and resolved via Address Resolution Protocol (ARP) by asking who has 10.0.0.11.

Now, in IPv6, P2 needs to push an L2 header with Ethertype 0x86DD (IPv6), but to which destination MAC address? ARP is an IPv4 thing! In IPv6 you need Neighbor Discovery (ND), an ICMPv6 mechanism that relies on IPv6 forwarding. And this is not possible if P2 does not support or is not configured for IPv6.

By using a service label, things are made easier for P2 because there is still an MPLS label after popping the transport label. P2 builds the L2 header with Ethertype 0x8847 (MPLS) and the destination MAC address is the one resolved via ARP for 10.0.0.11.

OK, this is why there is a service label. But how important is its value if the egress PE is going to pop it anyway? This is where it becomes more interesting.

6PE—service label allocation

There are three service label allocation modes at the egress PEs:

Per-prefix mode

This is the default mode in IOS XR for routes learned from (or pointing to) CEs. Every different service prefix (in this case, IPv6 route) has a different label. This mode is illustrated in Figure 3-2.

Per-CE

Also called per-NH (next hop) mode. This is the default mode in Junos. Let’s illustrate it with an example. Imagine PE3 has 1,000 IPv6 routes pointing to CE3, and 500 IPv6 routes pointing to CE4. PE3 assigns two labels: L1 to the first 1,000 routes, and L2 to the other 500 routes.

Per-table

Also called per-VRF (even if strictly speaking in the 6PE case there is no VRF). An egress PE assigns the same label to all the prefixes in the same table.

The most scalable model is per-table, followed by per-CE. Why? Because the lower the number of labels, the lower the number of forwarding next hops that the remote ingress PEs need to store and update.

However, using a high number of labels has an advantage if the backbone is composed of LSRs that do not have the capability of extracting fields from the IPv6 payload to compute the load-balancing hash. Most of the modern platforms are capable of doing it; hence, the trend is toward reducing the number of labels.

Following is the procedure to tune IOS XR in order to use per-CE or per-VRF mode.

RP/0/0/CPU0:PE4#configure
RP/0/0/CPU0:PE4(config)#router bgp 65000
RP/0/0/CPU0:PE4(config-bgp)#address-family ipv6 unicast
RP/0/0/CPU0:PE4(config-bgp-af)#label mode ?
  per-ce        Set per CE label mode
  per-vrf       Set per VRF label mode
  route-policy  Use a route policy to select prefixes ...

The per-vrf mode is very interesting. The assigned label to all the global IPv6 prefixes is number 2 or, in other words, the IPv6 Explicit Null label. For this reason, it is recommended to turn on this mode in Junos, as follows:

protocols {
    bgp {
        group iBGP-RR {
            family inet6 labeled-unicast explicit-null;
}}}

The choice of a label allocation mode has additional implications. The following statements hold true for Junos and might apply to IOS XR, too:

• With per-prefix and per-CE modes, the egress PE performs an MPLS lookup on the packet, and as a result, the forwarding next hop is already determined. The egress PE is actually performing packet switching, in MPLS terms.

• With per-table mode, the egress PE performs an IPv4 lookup on the packet after the MPLS label is popped. This results in a richer functionality set.

Now consider the PE-CE subnet fc00::10:2:0:0/112, which is local from the perspective of PE3. If PE3 is using per-CE mode for the 6PE service, what CE is actually linked to that prefix? Is it CE3 or CE4? Actually it’s neither. This is why, in per-CE mode, the local multipoint subnets are not advertised in Junos. You can still advertise CE3 (fc00::10:2:0:3/128) and CE4 (fc00::10:2:0:4/128) host routes if you locally configure a static route to the host.

6PE—traceroute

Here is a working traceroute from H1 (a host running IOS XR) to H3. You can compare the following example to Figure 3-2.

RP/0/0/CPU0:H#traceroute fc00::10:2:34:30

 1  fc00::10:1:12:1 0 msec 0 msec 0 msec                   # CE1
 2  fc00::10:1:0:1 59 msec 9 msec 0 msec                   # PE1
 3  fc00::10:0:0:3 [MPLS: Labels 299808/24020 Exp 0] ...   # P1
 4  ::ffff:172.16.0.2 [MPLS: Labels 24016/24020 Exp 0] ... # P2
 5  fc00::10:2:0:44 0 msec 0 msec 39 msec                  # PE4
 6  fc00::10:2:0:4 39 msec 0 msec 0 msec                   # CE4
 7  fc00::10:2:34:30 0 msec 0 msec 9 msec                  # H4

The traceroute mechanism in an MPLS core is the same as the one described in Chapter 1 for IPv4 over MPLS packets. When an IPv6 packet’s Time-to-Live (TTL) expires at a transit LSR, such as P1 or P2, the LSR generates an ICMPv6 time exceeded toward the original source (H1). The resulting ICMPv6 message is then encapsulated on the original LSP (→PE4), so the egress PE (PE4) can IPv6-route it toward the source (H1) The egress PE (PE4) is configured in per-VRF label allocation mode, so it does not include the service label in the time exceeded message.

But how can a non-IPv6 LSR generate an ICMPv6 packet? IOS XR does it automatically by sourcing the packet from the IPv6 address that is mapped from its own loopback IPv4 address (line 4). As for Junos, it requires that you configure icmp-tunneling, and also some IPv6 addressing in place. The common practice is to configure IPv6 addresses on all the core links, and not to advertise them in the Interior Gateway Protocol (IGP)— in IS-IS, protocols isis no-ipv6-routing.

AC classification—per technology

One of the most common AC types is VLAN-tagged Ethernet. One VLAN/802.1q header contains a 12-bit VLAN ID field, so its maximum value is 4,095. It’s also possible to stack two VLAN/802.1q headers inside the original MAC header, overcoming the limit of 4,096 VLANs in one LAN. This is a popular technique that has different names: stacked VLAN, Q-in-Q, SVLAN/CVLAN (where S stands for Service and C for Customer), and so on. VXLAN is a different technology, and it is discussed in Chapter 8.

In addition to the classic AC types (native Ethernet, VLAN-tagged Ethernet, ATM, Frame Relay, etc.), there are many other flavors. For example, an AC can actually be totally virtual, such as a VLAN transported in a locally terminated MPLS Pseudowire (see PWHE at Chapter 6), or a PPPoE session, or an L2TP session, or a dynamic interface created upon the headers of incoming IP traffic (IP demux), and so forth. Even an IPsec tunnel coming from the Internet can be terminated at the PE, itself becoming an AC of a BGP/MPLS IP VPN. Not all these access flavors are covered here, but there is an important concept to keep in mind: any connection with an endpoint at the PE can be a valid attachment circuit.

Going back to the classic ACs (such as basic Ethernet with or without VLANs), in many real-life scenarios the connection between CE and PE is not direct. An L2 service provider is typically in the middle, transporting the frames between CE and PE in a transparent manner—via either a point-to-point or a multipoint mechanism. In that case, the L2 carrier provides an overlay: the CEs and PEs are the only IP endpoints of the circuit connection. So, if the AC is Ethernet-based and the service is a BGP/MPLS IPv4 VPN, CE1 and PE1 can resolve each other’s IPv4 addresses by using ARP.

Route Distinguisher

Route Distinguisher (RD) is a very accurate name. An RD does precisely what the term implies: it distinguishes routes. PE4 may have the route 10.2.34.0/24 in different VRFs. The host 10.2.34.30 may be a server in a multinational enterprise (VRF-A), and at the same time a mobile terminal in a university (VRF-B). VPNs provide independent addressing spaces, so prefixes from different VRFs can overlap with no collision.

The prefixes exchanged over PE-CE eBGP sessions are IP Unicast (SAFI=1) and they do not contain any RDs. Indeed, from the point of view of the PE, each eBGP session is bound to one single VRF, so there is no need to distinguish the prefixes. On the other hand, CEs have no VPN awareness: from the perspective of the CE, a PE is just an IPv4/IPv6 router.

Now, one single PE-RR (or PE-PE) iBGP session can signal prefixes from multiple VPNs. For example, PE4 may advertise the 10.2.34.0/24 route from VRF-A and VRF-B. The 10.2.34.0/24 prefix represents a different reality in each of the VRFs, and this is where an RD comes in handy. The actual prefixes that PE4 announces to the RRs are <RD1>:10.2.34.0/24 and <RD2>:10.2.34.0/24. These prefixes are different as long as <RD1> is different from <RD2>.

Back in Figure 3-3, the RD is 172.16.0.44:101. There are several ways to encode RDs, as regulated by IANA. This book discusses two types: 0 and 1. These formats are <AS>:<VPN_ID> and <ROUTER_ID>:<VPN_ID>, respectively.

In an Active-Backup redundancy scheme, CE3-A and CE4-A advertise the 10.2.34.0/24 prefix with a different MED: 200 to PE3 and 100 to PE4, respectively. This makes PE3 prefer the iBGP route over the eBGP route; as a result, PE4 does not advertise it to the RRs. In this model, the RD choice is not very important.

In an Active-Active redundancy scheme, CE3-A and CE4-A would advertise the 10.2.34.0/24 with the same MED, so both PE3 and PE4 would in turn advertise it to the RRs. In this case, the RD choice is critical. Let’s consider the case of VRF-A:

• If the RD format is <AS>:<VPN_ID>, unless each PE assigns a different <VPN_ID> to the VRF—which would result in a virtually unmanageable numbering scheme—both PE3 and PE4 advertise the 65000:101:10.2.34.0/24 prefix. The RR selects the best route (from its point of view) and reflects it. This results in information loss and suboptimal routing. Not only that, it also causes a delay in failure recovery. The RRs must detect that the primary route is not valid before they can advertise the backup route to the ingress PEs. Typically, RRs have many peers, so this process usually takes time, and RRs act as a control-plane bottleneck. In the Internet service, BGP Add-Path extensions were required to address this challenge, but not necessarily in IP VPN, where there is a native solution!

• If the RD format is <ROUTER_ID>:<VPN_ID>, PE3 and PE4 advertise two different prefixes: 172.16.0.33:101:10.2.34.0/24 and 172.16.0.44:101:10.2.34.0/24, respectively. These are two different NLRI prefixes, and RRs reflect both of them. This guarantees that all of the PEs have all the information, achieving optimal routing and improved convergence. This is the scheme we use in this book. Note that in this case the <VPN_ID> value is the same (101) on both PEs, but this is not mandatory.

It is possible to have iBGP multihoming with unequal-cost multipath—see Chapter 20 for more details. The ingress PE can load-balance traffic between several egress PEs, even if these are not at the same IGP distance.

VPN label

The VPN label is an MPLS label that is locally significant to the egress PE. It is a service label by which the egress PE can map the downstream (from the core) user packets to the appropriate VRF (or CE). Like in 6PE, there are different label allocation schemes, which we’ll discuss later.

Although the VPN label is encoded in the IP Unicast VPN (SAFI=128) NLRI, routers in general—and RRs in particular—consider it more like a route attribute rather than as part of the NLRI. In other words, two identical RD:route prefixes are considered to be the same even if the VPN label is different. Thus, the RRs only reflect one of them.

Route Target

The Route Target (RT) concept is probably the one that makes BGP/MPLS VPNs so powerful. RTs are one type of BGP extended community.

Every BGP VPN route carries at least one RT. RTs control the distribution of VPN routes. How? Locally at a PE, a VRF has the following export and import policies:

• An export policy influences the transition of (local and CE-pointing) VRF routes from IP Unicast to IP Unicast VPN, before these routes are advertised to the RRs or other PEs. The export policy can filter prefixes and change their attributes; its most important task is to add RTs to the IP Unicast VPN routes.

• An import policy influences the installation of remote IP Unicast VPN routes into the local VRFs. The import policy can filter prefixes and change their attributes; its most important task is to look at the incoming routes’ RTs and make a decision as to whether to install the route on the VRF where the import policy is applied.

You could view RTs as door keys. When a PE advertises a VPN route, it adds a key chain to the route. When the route arrives to other PEs, the route’s keys (RTs) can open one or more doors (import policies) at the target PE. These doors give access to rooms (VRFs) where the route is installed after stripping the RD.

For example, you can configure VRF-A on all PEs to export RT 65000:1001 and to also import RT 65000:1001. This symmetrical policy—with the same import and export RT—results in a full-mesh topology in which all the CEs are reachable from one another. In this sense, you can easily identify VPN A routes: they all carry RT 65000:1001.

But there are many other ways to configure RT policies (hub-and-spoke, service chaining, etc.). Indeed, RTs are a fundamental concept that will be discussed quite a few times in this book. Let’s move on.

L3VPN—why is there a service label?

The answer is quite straightforward: the VPN label is essential for the egress PE to know to which VRF the downstream (from the core) packet belongs. The service label allocation models are similar to those of 6PE, and they are further described later.

L3VPN—backbone configuration at Junos PEs

Example 3-24 shows the relevant core-facing configuration at PE1.

protocols {
    bgp {
        group iBGP-RR {
            family inet-vpn unicast; 
            family inet6-vpn unicast;
}}}

As expected, two new address families are added: IPv4 Unicast VPN (AFI=1, SAFI=128) and IPv6 Unicast VPN (AFI=2, SAFI=128).

L3VPN—backbone configuration at IOS XR PEs

Here is the relevant core-facing configuration at PE2:

router bgp 65000
 address-family vpnv4 unicast
 address-family vpnv6 unicast
 !
 neighbor-group iBGP-RR
  address-family vpnv4 unicast
  address-family vpnv6 unicast
!

L3VPN—VRF configuration at Junos PEs

Example 3-28 presents the access configuration at PE1. The only logical interface and eBGP session displayed correspond to the PE1-CE1 link.

1     interfaces {
2         ge-2/0/1 {
3             unit 1002 {
4                 vlan-id 1002;
5                 family inet address 10.1.0.1/31;
6                 family inet6 address fc00::10:1:0:1/127;
7     }}}
8     routing-instances {
9         VRF-A {
10            instance-type vrf;
11            interface ge-2/0/1.1002;
12            route-distinguisher 172.16.0.11:101;
13            vrf-export PL-VRF-A-EXP;
14            vrf-import PL-VRF-A-IMP;
15            protocols {
16                bgp {
17                    group eBGP-65001 {
18                        family inet unicast;
19                        family inet6 unicast; 
20                        peer-as 65001;
21                        as-override;
22                        neighbor 10.1.0.0 {
23                            export PL-VRF-A-eBGP-CE1A-OUT;
24                        }
25    }}}}}
26    policy-options {
27        policy-statement PL-VRF-A-eBGP-CE1A-OUT {
28            term BGP {
29                from protocol bgp;
30                then {
31                    metric 100;
32                    community delete RT-ALL;
33                }
34            }
35            term IPv6 {
36                from family inet6;
37                then {
38                    next-hop fc00::10:1:0:1;
39                }
40        }}
41        policy-statement PL-VRF-A-EXP {
42            term eBGP {
43                from protocol bgp;
44                then {
45                    community add RT-VPN-A;
46                    accept;
47                }
48        }}
49        policy-statement PL-VRF-A-IMP {
50            term VPN-A {
51                from community RT-VPN-A;
52                then accept;
53            }
54        }
55        community RT-ALL members target:*:*;
56        community RT-VPN-A members target:65000:1001;
57    }

The AC configuration (lines 1 through 6) has nothing special: just a dual-stack IFL.

The VRF export (lines 13, and 41 through 46) and VRF import (lines 14, and 49 through 52) are very simple, to the point that they would not need to be defined. You could replace lines 13 and 14 with vrf-target target:65000:1001. But this shortcut is compatible only with full-mesh VPN topologies, and it does not allow filtering or modifying prefixes. For this reason, it’s a good practice to use the syntax in Example 3-28.

The as-override configuration in line 21 is not specific to L3VPNs. In fact, it is required for any BGP-based design that requires connecting two islands with the same AS (65001 in this case). Otherwise, the AS-loop detection logic would drop the prefixes at some point. There are other techniques to achieve the same result, but this one is simple.

Unlike IOS XR, when Junos readvertises an IP Unicast VPN route—after converting it to IP Unicast format—it keeps all the communities, including the RTs. It is a good practice to strip the RTs before sending the route to a plain CE (line 32).

As for the IPv6 next-hop rewrite in line 38, it is due to the fact that there is a single eBGP session used for IPv4 and IPv6 prefixes. The rationale is the same as explained previously in the 6PE section. (See the full discussion with respect to Example 3-6.)

L3VPN—VRF configuration at IOS XR PEs

Example 3-29 contains the access configuration at PE4. The only logical interface and eBGP session displayed correspond to the PE4-CE4A link.

1     interface GigabitEthernet0/0/0/2.1002
2      vrf VRF-A
3      ipv4 address 10.2.0.44 255.255.255.0
4      ipv6 address fc00::10:2:0:44/112
5      encapsulation dot1q 1002
6     !
7     router bgp 65000
8      vrf VRF-A
9       rd 172.16.0.44:101
10      address-family ipv4 unicast
11      address-family ipv6 unicast
12      !
13      neighbor 10.2.0.4
14       remote-as 65001
15       address-family ipv4 unicast
16        route-policy PL-VRF-A-eBGP-CE4A-IN in
17        route-policy PL-VRF-A-eBGP-CE4A-OUT out
18        as-override
19       !
20       address-family ipv6 unicast
21        route-policy PL-VRF-A-eBGP-CE4A-IN in
22        route-policy PL-VRF-A-eBGP-CE4A-OUT out
23        as-override
24    !
25    vrf VRF-A
26     address-family ipv4 unicast
27      import route-target
28       65000:1001
29      export route-target
30       65000:1001
31     !
32     address-family ipv6 unicast
33      import route-target
34       65000:1001
35      export route-target
36       65000:1001
37    !
38    route-policy PL-VRF-A-eBGP-CE4A-IN
39      pass
40    end-policy
41    !
42    route-policy PL-VRF-A-eBGP-CE4A-OUT
43      pass
44    end-policy

As a side note, there is one significant configuration difference in the way non-BGP prefixes can be announced via BGP. In Junos, you need to modify the VRF export policy. Here is the syntax in IOS XR: router bgp <AS> vrf <VRF> address-family <AF> redistribute [...].

Virtual routers

The idea of having a private routing instance is very attractive, and not only in the context of an L3VPN service. For example, a physical CE can be turned into a set of virtual CEs, each with its own upstream circuits and routing table(s).

In Junos, this is called virtual router (VR, a.k.a., VRF Lite), and you can configure it as shown in Example 3-28, with the following differences:

• The instance-type in line 10 is virtual-router.

• Lines 12 through 14 must be removed, and line 32 is not necessary.

Graphically, if you disconnect VRF-A.inet.0 from bgp.l3vpn.0 in Figure 3-4, VRF-A becomes a VR.

The Cisco term for this same concept is VRF Lite. You can turn VRF-A into a VRF Lite by suppressing lines 27 through 30, and 33 through 36 from Example 3-29. Note that eBGP configuration in VRF Lite requires that you configure an RD, even if it is not actually signaled.

L3VPN—hub-and-spoke VPN

The lefthand scenario in Figure 3-5 shows a classic hub-and-spoke L3VPN. PE1 and PE2 are the hub PEs, connected to the corporate headquarters’ data center. PE3 and PE4 are spoke PEs, connected to small offices, home offices, or mobile users.

Figure 3-5. L3VPN Topology Samples

The remote sites do not need to communicate with one another.

With these connectivity requirements, hub-and-spoke PEs use complementary policies in the context of the same VPN:

• Spoke PEs export routes with route target RT-S, so hub PEs import them.

• Hub PEs export routes with route target RT-H, so spoke PEs import them.

• Spoke PEs do not import routes from other spoke PEs.

• Hub PEs may import routes from other hub PEs, if their import policies are configured to also accept routes with RT-H. This adds an extra level of redundancy.

The following example shows a typical asymmetrical RT configuration in Junos.

1     policy-options {
2         policy-statement PL-VRF-A-HUB-EXP {
3             term eBGP {
4                 from protocol bgp;
5                 then {
6                     community add RT-VPN-A-HUB;
7                     accept;
8                 }
9         }}
10        policy-statement PL-VRF-A-HUB-IMP {
11            term VPN-A {
12                from community [ RT-VPN-A-SPOKE RT-VPN-A-HUB ];
13                then accept;
14            }
15        }
16        community RT-VPN-A-HUB members target:65000:2001;
17        community RT-VPN-A-SPOKE members target:65000:3001;
18    }

Junos applies the following logical operators:

[OR]

This operator is applied if several communities are listed in a from community statement. It is enough for the route to contain any of the communities in order to match the term.

[AND]

This operator is applied if several communities are listed in members. The route must contain all the communities in order to match the community.

Following is an IOS XR sample.

1     vrf VRF-A-HUB
2      address-family ipv4 unicast
3       import route-target
4        65000:2001
5        65000:3001
6       !
7       export route-target
8        65000:2001
9     !

L3VPN—management VPN

The righthand scenario in Figure 3-5 is explained later. Let’s see a simpler example first. Very frequently, SPs manage all or a subset of the tenant CEs—just the first routing device, not necessarily the tenant network behind it.

Imagine 10 fully meshed customer VPNs called VPN-n (VPN-1 through VPN-10). These are instantiated on each PE as a VRF-n (VRF-1 through VRF-10), and each VPN has its own and different RT-n (RT-1 through RT-10).

In addition, the SP has a management VPN (VPN-M). This VPN is instantiated at PE1 and PE2 as VRF-M and the ACs are connected to the SP’s management network.

The SP’s management servers need to communicate to the customer VPN CEs, but not to the tenant’s end hosts. Here is how you can meet the connectivity requirement:

• PEs’ VRF-n export policies tag all the exported prefixes with at least RT-n.

• PEs’ VRF-M export policies tag the management server’s prefixes with RT-M.

• The SP assigns a globally unique loopback IP address to each CE in a VPN-n. PEs’ VRF-n export policies advertise these prefixes with RT-n and RT-CE-LO.

• PEs’ VRF-n import policies accept prefixes containing its RT-n and/or RT-M.

• PEs’ VRF-M import policies accept prefixes containing RT-CE-LO and/or RT-M.

• CEs must not advertise management prefixes to the tenants’ internal networks.

The same RT techniques used in Example 3-33 and Example 3-34 apply here, but this time it is necessary to do something more granular on the CE loopback prefixes.

Let’s assume that the CEs are advertising their own loopback to the PEs with standard community 65000:1234. In this way, PE3 can easily recognize CE3-A’s loopback. Then, PE3 adds RT-CE-LO to the prefix before announcing it via iBGP to the RRs.

1     policy-options {
2         policy-statement PL-VRF-A-EXP {
3             term CE-LO {
4                 from community CM-CE-LO;
5                 then community add RT-CE-LO;
6             }
7             term eBGP {
8                 from protocol bgp;
9                 then {
10                    community add RT-VPN-A;
11                    accept;
12                }
13            }
14        }
15        community CM-CE-LO members 65001:1234;
16        community RT-CE-LO members target:65000:1234;
17        community RT-VPN-A members target:65000:1001;
18    }

The resulting route 172.16.0.33:101:<CE-LO>/32 has the three communities in lines 15 through 17, because it is evaluated by both terms in the policy. The original community 65001:1234 is kept because the action in line 5 is community add. If it had been community set, the original community would have been stripped.

The following example illustrates how RTs can be granularly set in IOS XR:

vrf VRF-A
 address-family ipv4 unicast
  export route-policy PL-VRF-A-EXP
!
route-policy PL-VRF-A-EXP
  if community matches-any CM-LO-CE then
    set extcommunity rt (65000:1001, 65000:1234)
  endif
end-policy
!
community-set CM-LO-CE
  65000:1234
end-set
!

Again, the resulting IPv4 Unicast VPN prefix has three communities in total: one standard (65000:1234) and two extended (target:65000:1001 and target:65000:1234) communities. Hence, IOS XR differs from Junos in that the set keyword is additive.

As for the generic RT configuration in IOS XR Example 3-29 (lines 25 through 36), it still applies to prefixes that do not match the configured VRF export and import policies.

L3VPN—extranet

The previous example illustrated a generic technique known as extranet. In an extranet, a set of tenants is no longer isolated from one another and they can exchange prefixes. How much connectivity and which type of connectivity the VPNs have with each other is totally at the discretion of the configured routing policies.

There are two types of prefixes from the point of view of a VRF: remote and local. Remote prefixes are received from the RRs and/or from remote PEs. Conversely, local prefixes belong to the access side: these are typically routes learned from directly connected CEs, or they can also be static routes, directly connected ACs, local VRF loopbacks at the PE, and so on.

When a PE receives a remote IP Unicast VPN prefix, typically the RTs and other attributes determine the VRFs (it can be none, one or several) in which the prefix is imported. How about the local prefixes? The logic is the same. RT policies are evaluated, so two VRFs in a given PE may exchange local prefixes if their VRF policies match. This is known as route leaking.

A very common use case here is a tenant merger. Imagine VRF-A and VRF-B used to belong to different corporations but the two are merging into a bigger company. Provided that the IP addressing scheme is carefully analyzed and there is no overlap, the two VPNs can be merged into one by just importing each other’s RTs in their respective VRFs. As a final step after the extranet interim period, the two VRFs are then merged into one single VRF.

Route leaking is a very rich topic, and for further reading about this and other topics, we highly recommend the #TheRoutingChurn blog at http://forums.juniper.net/.

L3VPN—Service Chaining

Service Chaining or Service Function Chaining (SFC) is one of the most rapidly evolving solutions these days. As is detailed in Chapter 12, some network virtualization solutions go beyond the RT concept in order to achieve modern SFC.

In the late 1990s, well before the SDN era, the earliest flavor of SFC already existed in traditional L3VPN services. Let’s examine how SFC looked at that time, not only for historical reasons, but because it is still a common practice in carriers.

Imagine that an SP wants to provide added value services such as NAT, firewall, DDoS protection, deep-packet inspection, IDS/IDP, traffic big-data analytics, and so on to its high-touch customers. One expensive option is to implement all of these services at the CE—which can be particularly challenging for mobile users. In contrast, the most scalable and convenient option is to steer the traffic to service nodes that perform these added value tasks. These service nodes can be all in the same location or distributed in different sites.

RT policies can steer traffic through routing-aware appliances distributed in different data centers, each on a different VPN site. Indeed, this is possible even in classical BGP VPN setups, like the one on the righthand side of Figure 3-5. Each appliance performs an added-value function on top of the baseline Internet access service. The diagram shows the routes required to steer upstream traffic from the tenant’s host to the Internet, through the different (physical or virtual) appliances.

A similar routing scheme (not shown) would be required for downstream traffic, too. This is a bit more complex—but definitely feasible—when NAT is in the picture. Very often, the NAT function is performed directly on the PEs so the Left/Right VRFs are stitched locally at the PE through the NAT service interfaces.

Another challenge is redundancy, because many services (NAT, stateful firewalling, etc.) typically require symmetrical traffic. When there are several appliances in a redundancy pool, it is important that upstream and downstream packets from the same flow are all handled by the same appliance. Again, you can solve this challenge by carefully defining the policies.

It’s not theoretical: as mentioned, this approach has been used for decades in many SPs. This traditional SFC concept has evolved in the more recent years:

• Virtualizing the appliances

• Decoupling the PE’s control/signaling from the routing/forwarding functions into different entities

• Introducing flexible BGP next-hop manipulation and enhanced forwarding intelligence at the programmable PEs

• Natively implementing scalable security functions in the forwarding logic

• Automating the service provisioning, configuration, resiliency, and monitoring

Chapter 12 shows how the BGP VPN technology, which has always supported service chaining at some extent, recently evolved into a flexible, scalable, and modern SFC solution.

Plane A—RSVP-TE LSPs to the remote PE’s router ID

These are the two RSVP-TE LSPs signaled on plane A: PE1→PE4_PLANE-A and PE4→PE1_PLANE-A. They have as a destination the remote PE’s loopback address A.

By default, Junos only installs a route to the RSVP-TE LSP destination (to address) in the inet.3 routing table. This is exactly what we want in this case.

protocols {
    mpls {
        label-switched-path PE1--->PE4_PLANE-A {
            to 172.16.0.44;
}}}

As for IOS XR, by default there is no prefix bound to a RSVP-TE LSP. Indeed, autoroute is not turned on by default; you must configure it explicitly.

Now, the autoroute announce feature automatically uses the RSVP-TE LSPs as a next hop for all the destinations that are at or behind the tail end. So, PE4’s CEF sees the three PE1’s loopback IP addresses as reachable via the PE4→PE1_PLANE_A LSP. This is not what you want in this scenario, and the solution is not to use autoroute announce. There are several alternative methods for coupling prefixes to a LSP. One option is to use static routes, but it is much better to use a dynamic method that takes the IGP metric into account: this is the autoroute destination feature.

1     interface tunnel-te1101
2      ipv4 unnumbered Loopback 0
3      signalled-name PE4--->PE1_PLANE-A
4      autoroute destination 172.16.0.11
5      !
6      destination 172.16.0.11
7      record-route
8      path-option 1 dynamic
9     !

It is line 4, not line 6, that determines what is installed at PE4’s CEF. In this case, PE4 sees only one prefix as reachable via PE4→PE1_PLANE_A: 172.16.0.11.

Plane B—controlling LDP label bindings

The two vendors covered by this book have a different default behavior:

• Junos PE1 only advertises a label mapping for one local FEC: its primary loopback address (A). As for remote FECs, it uses the ordered label distribution control mode, which means that it only advertises label mappings for those remote FECs for which it has already received label mappings from the downstream LSR.

• IOS XR advertises a label mapping for all the local and remote (IGP) FECs in independent mode. This means that PE2, P2, and PE4 advertise a label mapping for all the loopback addresses (A, B, and C) of all the PEs, including PE1 and PE4.

Is the default implementation a valid one in this scenario? Let’s focus on plane A first.

In both Junos and IOS XR, if a remote FEC is reachable via a RSVP-TE LSP and via LDP label mappings, RSVP-TE is preferred. So RSVP-TE LSPs PE1→PE4_PLANE_A and PE4→PE1_PLANE_A take precedence over LDP. Only if the RSVP-TE LSPs cannot be signaled, for whatever reason, does LDP act as a fallback mechanism.

But this might not be your preferred option. Suppose that all the LSRs in the network are capable of IP routing Internet packets in the global instance. Although this scenario deviates from the first classical MPLS use case, it is a common practice in international carriers because it provides hop-by-hop control. In this case, you might prefer the fallback mechanism in plane A—dedicated in this example to the Internet service—not to be LDP, but hop-by-hop classical (unlabeled) IP routing. In this case, it is necessary to filter loopback address A out of LDP advertisements.

As for plane B, Junos P1 only advertises a label mapping for PE1’s loopback address B if it has previously received the corresponding label mapping from PE1.

Finally, let’s assume that LDP is a desirable fallback mechanism for plane C. Putting this all together, LDP must advertise label mappings for planes B and C, but not for plane A.

Following is the required configuration at Junos PE1:

1     protocols {
2         ldp egress-policy PL-LDP-EGRESS;
3     }
4     policy-options {
5         policy-statement PL-LDP-EGRESS {
6             term LOOPBACK-B-C {
7                 from {
8                     route-filter 172.16.1.11/32;
9                     route-filter 172.16.2.11/32;
10                }
11                then accept;
12            }
13            term REST {
14                then reject;
15    }}}

Junos PE3 needs a similar configuration—just by adapting lines 8 and 9 to its local addressing—and P1 does not require any additional changes.

The required configuration on all the IOS XR core routers (PE2, P2, and PE4) is shown in Example 3-50.

mpls ldp
 address-family ipv4
  label
   local
    allocate for ALL-LOCAL-PLANE-B-C
!
ipv4 access-list AL-LOCAL-PLANE-B-C
 10 permit ipv4 172.16.1.0 0.0.0.255 any
 20 permit ipv4 172.16.2.0 0.0.0.255 any
 30 deny ipv4 any any
!

Plane C—RSVP-TE LSPs to a secondary loopback address

These are the two RSVP-TE LSPs signaled on plane C: PE1→PE4_PLANE-C and PE4→PE1_PLANE-C. They are coupled to the remote PE’s loopback address C.

Taking into account this boundary condition, here is the configuration at PE1:

1     protocols {
2         mpls {
3             label-switched-path PE1--->PE4_PLANE-C {
4                 to 172.16.0.44;
5                 no-install-to-address;
6                 install 172.16.2.44;
7     }}}

With the previous configuration, the LSP is a next hop for the 172.16.2.44/32 route (line 6) at PE1’s inet.3 table. But it is not a next hop for 172.16.0.44/32 (line 5).

Here is the IOS XR configuration at PE4.

1     interface tunnel-te1103
2      ipv4 unnumbered Loopback 0
3      signalled-name PE4--->PE1_PLANE-C
4      autoroute destination 172.16.2.11
5      !
6      destination 172.16.0.11
7      record-route
8      path-option 1 dynamic
9     !

It is line 4, not line 6, that determines what is installed at PE4’s CEF. In this case, PE4 sees only one prefix as reachable via PE4→PE1_PLANE_C: 172.16.2.11.

There is an interesting implementation difference between Junos install and IOS XR autoroute destination. Junos calculates the 172.16.2.44/32 FEC metric as the shortest IGP path to the LSP’s tail end (172.16.0.44). IOS XR, on the other hand, calculates it as the shortest IGP path to the FEC itself (172.16.2.11, not 172.16.0.11).

In this example, there is no difference because the FEC is local to the LSP’s tail end. But there are other use cases of this technique—mainly Traffic Engineering—for which the LSP’s tail end may be en route to the FEC; however, the FEC is still one or more hops beyond. In this case, the previous implementation difference is relevant. There is a way to make Junos use the FEC metric—based on LDP tunneling and LDP policies—but it is beyond the scope of this book.