L2VPN Use Cases

Among the many use cases for L2VPN, two of them are especially relevant.

Backhauling—L2VPN as a transport

Although L2VPN is definitely a popular commercial service offered to customers for many applications (e.g., DCI or WAN emulation), SPs also use internal L2VPNs as part of their own infrastructure: L2VPN as a transport in aggregation networks. This is a common approach to backhaul both mobile and wireline traffic.

Figure 6-2 represents a classic architecture. Note that the Customer and Service VLAN are optional: it is also possible to backhaul with one or zero VLAN tags. Using both tags is great for multiplexing, though.

Figure 6-2. Backhauling—L2VPN as a transport

The Metro Ethernet Forum (MEF) has defined some standards and mechanisms (such as OAM) necessary to achieve carrier-class behavior in a Carrier Ethernet network.

The last-mile access device is typically a translational L2 bridge whose customer-facing interfaces might or might not be pure Ethernet. On the left side of Figure 6-2, you can see the following:

• A corporate customer with a DSL connection that transports Ethernet over ATM

• A residential customer with a native Ethernet FTTH (Fiber to the Home) connection

• A 4G mobile user with a non-Ethernet microwave connection

These are just a few examples to illustrate the variety of access technologies. The last-mile access device hides all this complexity by translating CE→PE customer frames or cells into Ethernet frames and forwarding them up to the aggregation network. Likewise, PE→CE Ethernet frames are translated into the appropriate L2 format and sent down to the customer device. The manipulation of the original L2 headers can range from no action (such as in some FTTx implementations) to a significant translation logic. But it remains L2 bridging.

The Local Service PE may in turn provide an L3 service (Internet, IP VPN, etc.). In this case, the access L3 endpoints are the CE and the Local Service PE.

Or, the Local Service PE may provide an L2VPN Service; this is why in Figure 6-2 the right-side L3 Termination Point is labeled or beyond. In this case, the concepts of L2VPN as a Transport and L2VPN Service are totally orthogonal to each other. L2VPN as a Transport relates to how the SP transports L2 frames from CE to Local Service PE, and this should be transparent for the customer. On the other side, the L2VPN Service is what the customer purchases: L2 connectivity between its sites. In Figure 6-2, the Local Service PE sees the CE-PE interface as an L2 straight attachment circuit. How the L2 frames are actually transported inside the aggregation network is quite transparent to the Local Service PE. In that sense, the Infrastructure (Transport) L2VPN is just an overlay.

In more modern architectures, some of the functions depicted in Figure 6-2 are collapsed as follows:

• The same device can perform the last-mile access and Access L2VPN PE functions. This is just an internal implementation at the last-mile access device, which gets promoted from a L2 bridge to a L2VPN PE.

• The same device may perform the Aggregation L2VPN PE and Local Service PE functions. This interesting dimension (called PWHE) is explored later in this chapter.

Note

L2VPN—regardless of its application—is a bidirectional service that provides an overlay to transport L2 frames. The actual underlay is composed of unidirectional transport LSPs, a.k.a., PSN Tunnels.

L2VPN Topological Classification

L2VPNs can be Point-to-Point (P2P) or Multipoint-to-Multipoint (MP2MP). This concept is service-centric, not transport-centric, and it refers to the number of sites that a given L2VPN can have:

• P2P L2VPNs can have only two sites, which may be redundant or protected. These L2VPNs are commonly called Pseudowire Edge-to-Edge Emulation (PWE3), or Virtual Private Wire Service (VPWS), or E-Line, or Virtual Leased Line (VLL).

• MP2MP L2VPNs can have more than two sites. Depending on the topology, they are called E-Tree or E-LAN. Other popular terms such as Virtual Private LAN Service (VPLS) or Ethernet VPN (EVPN) are specific to certain flavors and do not represent the MP2MP L2VPN technology as a whole.

Another important concept is that of a pseudowire (PW). Paraphrasing RFC 6624, “the entity that connects two attachment circuits across the SP network is called a pseudowire.” In the context of the previous service classification, P2P L2VPNs rely on a single PW, and some flavors of MP2MP L2VPNs rely on a set of PWs.

Ethernet frames can be forwarded in the context of any of these two L2VPN topologies. Indeed, Ethernet is a multiaccess technology and it supports both. An MP2MP Ethernet L2VPN service behaves like a distributed switch with more than two ports, so it performs MAC learning. Conversely, P2P Ethernet L2VPNs do not require MAC learning because they are like a distributed hub with two ports (like a pipe): whatever the ingress PE receives on port #1, the egress PE simply sends it out of port #2, and vice versa.

Non-Ethernet L2 technologies are typically P2P in nature, so these can only be transported by using P2P L2VPNs.

L2VPN Signaling and Transport

Like L3VPNs, modern L2VPNs decouple the service from the transport by using MPLS label stacking: the outer label takes the tunneled packets to the egress PE, and the inner label identifies the VPN service.

Two protocols are capable of signaling the service labels: Multiprotocol BGP and Targeted LDP. In general, you can choose one or the other, after you’ve evaluated the pros and cons, with one exception: the latest L2VPN flavor (EVPN) is only supported in BGP.

As for the PSN Tunnels, they are simply MPLS LSPs so all of the options discussed in Chapter 2 apply here, too: LDP, RSVP-TE, BGP-LU, and SPRING.

P2P L2VPN—Varied Access Technologies

The mechanisms to signal a P2P L2VPN are quite agnostic of the L2 technology that needs to be transported. After you have chosen the signaling protocol (BGP or Targeted LDP), the message exchange required to establish an Ethernet or a non-Ethernet P2P L2VPN are practically identical. The only difference lies in a protocol attribute that encodes the L2 technology type for the VPN. This attribute is either an extended community (BGP) or a TLV (Targeted LDP).

As for the forwarding plane, L2 frames or cells are encapsulated in MPLS by using a collection of methods that are specific to each technology:

• Ethernet L2VPN forwarding is covered in RFC 4448 - Encapsulation Methods for Transport of Ethernet over MPLS Networks.

• There are equivalent RFCs for other L2 technologies: HDLC/PPP over MPLS (RFC 4618), Frame Relay over MPLS (RFC 4619), and ATM over MPLS (RFC 4717).

These forwarding plane RFCs belong to a collection of standards that are frequently referred to as Martini encapsulation, for Luca Martini. They explain how to encapsulate L2 frames or cells in MPLS. Actually, it is possible to go even one step further and simulate leased lines by encapsulating Time Division Multiplexing (TDM) data in packets over MPLS. This technology is commonly called Circuit Emulation Services (CES), and it has several flavors. For traditional Digital Signal (DS): Structure-Agnostic TDM over Packet (SAToP, RFC 4553) and Structure-Aware TDM Circuit Emulation Service over Packet Switched Network (CESoPSN, RFC 5086). These are implemented and widely deployed in a variety of physical interfaces such as E1/T1, OC3/STM1, and OC12/STM4. As for mapping native SONET/SDH frames into packets, the model is described in RFC 4842, but the authors are unaware of any production-ready implementation.

CES is very important in mobile backhaul legacy applications such as 2G and 3G requiring TDM transport. The TDM circuits begin at the base stations and are terminated on the BSC (Base Station Controller) or the RNC (Radio Network Controller). Timing and packet order requirements are typically quite strict for TDM, which motivates the usage of a control word. This concept is presented later in this chapter and can also be used in other L2VPNs services like Ethernet.

L2VPN Flavors Covered in This Book

This book covers L2VPNs whose service and transport are decoupled. This means that regardless of the protocol used to signal the service (BGP or LDP), the transport LSP can be signaled with any of the available protocols: LDP, RSVP-TE, BGP-LU, or SPRING.

Although this L2VPN set fully supports the transport of Ethernet frames, the P2P flavors also support the transport of other data in a wide variety of formats: frames, cells, and CES. Looking forward, all of this chapter’s examples feature the transport of Ethernet frames. Not a hard constraint: the variety of solutions is still overwhelming! Table 6-1 lists the Ethernet L2VPN flavors addressed in this book.

All of these Ethernet L2VPN flavors rely on the same forwarding-plane encapsulation, as defined in RFC 4448 - Encapsulation Methods for Transport of Ethernet over MPLS Networks. The differences are in the signaling plane. When referring to Martini, it is important to differentiate between Martini encapsulation (RFC 4448 in the case of Ethernet) and Martini transport or signaling (RFC 4447, LDP VPWS). The latter is just one of the several L2VPN flavors that rely on the Martini encapsulation.

There are also L2VPN flavors based on a different encapsulation called Provider Backbone Bridging (PBB) or MAC-in-MAC on the AC side. This requires some extensions for VPLS (VPLS-PBB, RFC 7041) and for EVPN (EVPN-PBB, RFC 7623). The latter is briefly discussed in Chapter 8.

For the moment, let’s stick to the classic Martini encapsulation.

BGP L2VPN Address Family

BGP VPWS and BGP VPLS both use the same multiprotocol BGP address family: AFI=25, SAFI=65. Let’s call it the L2VPN address family.

Here is the additional configuration at a Junos PE:

protocols {
    bgp {
        group iBGP-RR {
            family l2vpn signaling;
}}}

Adding this configuration to all the BGP groups also does the trick on Junos RRs.

The additional configuration on IOS XR PEs is shown in Example 6-2.

router bgp 65000
 address-family l2vpn vpls-vpws
 !
 neighbor-group RR
  address-family l2vpn vpls-vpws
!

BGP VPWS Configuration at the PEs

Let’s begin with the simplest VPWS example, featuring a PW that interconnects these two ACs: PE1’s ge-2/0/1 and PE4’s GigabitEthernet0/0/0/3. All of the Ethernet frames entering one of these physical ports exits unchanged from the remote AC. As you can see, this PW is somehow stretching a physical wire between two CEs. Other, more flexible, models are described later.

The original frames can be untagged or VLAN-tagged. In the latter case, the VLAN tags are transported end to end because they are considered as part of the payload.

Example 6-3 the configuration of the PE1—PE4 PW at the Junos PE1 side.

1     interfaces {
2         ge-2/0/1 {
3             mtu 2000;
4             encapsulation ethernet-ccc;
5             unit 0;
6         }
7     }
8     routing-instances {
9         L2VPN-A {
10            instance-type l2vpn;
11            interface ge-2/0/1.0;
12            route-distinguisher 172.16.0.11:1010;
13            vrf-target target:65000:1010;
14            protocols {
15                l2vpn {
16                    encapsulation-type ethernet;
17                    interface ge-2/0/1.0;
18                    site CE1-A {
19                        site-identifier 1;
20                        ignore-mtu-mismatch;
21                        interface ge-2/0/1.0 {
22                            remote-site-id 4;
23    }}}}}}

As with any BGP-based VPN service, the Route Distinguisher (RD, line 12) format can be <IP>:<#> or <AS>:<#>. But we strongly recommend using the <IP>:<#> format for L2VPN prefixes, especially in CE multihoming topologies.

Note that the configuration does not include the remote PE address. BGP takes care of the autodiscovery!

The local and remote sites (lines 19 and 22, respectively) are L2VPN CE-IDs. They are numbered here according to the CE to which the attachment circuit is connected.

Let’s take care of the maximum transmission unit (MTU) now. One of the stickiest L2VPN interoperability challenges between Junos and IOS XR is setting and negotiating the PW MTU. When the negotiated MTU is not the same at both ends of a PW, typically the PW does not come up due to MTU mismatch.

There are two options to overcome this challenge:

Configuring the endpoints to ignore MTU mismatch

This is achieved both in Junos and IOS XR by using the knob ignore-mtu-mismatch. Actually, in IOS XR there are two knobs: ignore-mtu-mismatch for LDP-based L2VPNs, and ignore-mtu-mismatch-ad for BGP-based L2VPNs. The latter is hidden, so it does not autocomplete and does not show up in the running configuration even if it’s set.

Configuring a matching MTU on both ends

This has the advantage of providing more control, but both vendors have implementation gaps. Setting an explicit MTU is only available for some of the L2VPN flavors; and this flavor subset is different for each vendor.

A negotiated MTU is not really enforced on the traffic. The actual PW’s MTU is determined by the MTU of the local and remote ACs as well as the core links. L2 traffic cannot be fragmented, so it is very important to set the AC physical links’ MTU large enough to account for a standard IP packet (1,500 bytes), plus the Ethernet and VLAN headers. Furthermore, core links need to account for RFC 4448 encapsulation and for MPLS headers, too. In this book’s examples, it is assumed that all of the access interfaces are configured with a physical MTU of 2,000 bytes (line 3), and the core links with a MTU of at least 2,100 bytes.

In both Junos and IOS XR, sometimes a configuration change on the PW MTU does not have an immediate effect, and the PW needs to be deleted and added again or deactivated/activated in order for the change to take effect.

Example 6-4 the configuration for the PE1—PE4 PW at the IOS XR PE4 side.

1     interface GigabitEthernet0/0/0/3
2      mtu 2000
3      l2transport
4     !
5     l2vpn
6      ignore-mtu-mismatch-ad
7      xconnect group myL2VPN
8       mp2mp L2VPN-A
9        vpn-id 123456789
10       mtu 1986
11       l2-encapsulation vlan
12       autodiscovery bgp
13        rd 172.16.0.44:1010
14        route-target 65000:1010
15        signaling-protocol bgp
16         ce-id 4
17          interface GigabitEthernet0/0/0/3 remote-ce-id 1
18    !

The IOS XR configuration hierarchy in line 8 (mp2mp) supports a collection of BGP VPWS services, each with a different [local ce-id, remote ce-id] pair. VPWS is actually P2P, and it does not perform proper Ethernet bridging or MAC learning. So despite the mp2mp term, you can think point to point.

The vpn-id (line 9) is mandatory but its value is arbitrary because it is not signaled with BGP. Its value is only relevant when targeted LDP (and not BGP) is the protocol responsible for signaling the service.

How about the MTU? In some L2VPN flavors, IOS XR performs two MTU checks:

• The local PW’s MTU must match the MTU advertised by the remote end.

• The local AC’s MTU must match the locally configured PW’s MTU.

The ignore-mtu-mismatch-ad knob (line 6) helps to bypass the first check in BGP L2VPN, whereas the second check—if present—needs a little more work.

Why is the PW’s MTU (line 10) different from the AC’s MTU (line 2)? If you take line 10 off Example 6-4, the PW goes down (see Example 6-5.

RP/0/0/CPU0:PE4#show l2vpn xconnect group myL2VPN detail | i MTU
        AC MTU Mismatch
    MTU 1986; XC ID 0x3881ef5; interworking none

The value in line 3 is dynamically computed from the physical MTU and must be configured explicitly on the PW (Example 6-4, line 10). This extra step is only required on a minority of the L2VPN flavors.

BGP VPWS Signaling

After they’re configured, PE1 and PE4 advertise one L2VPN BGP route each.

Example 6-6 the BGP L2VPN route advertised by Junos PE1.

1     juniper@PE1> show route advertising-protocol bgp 172.16.0.201
2                  table L2VPN-A.l2vpn.0 detail
3
4     L2VPN-A.l2vpn.0: 2 destinations, 3 routes (2 active, ...)
5     *  172.16.0.11:1010:1:3/96 (1 entry, 1 announced)
6      BGP group iBGP-RR type Internal
7         Route Distinguisher: 172.16.0.11:1010
8         Label-base: 800012, range: 2, offset: 3, status-vector: 0x0
9         Nexthop: Self
10        Flags: Nexthop Change
11        Localpref: 100
12        AS path: [65000] I
13        Communities: target:65000:1010
14                     Layer2-info: encaps: ETHERNET, control flags:[0x2]
15                                  Control-Word, mtu: 0
16                                  site preference: 100

The /96 mask is internal in Junos and not advertised via iBGP: you can safely ignore it.

The NLRI in line 5 contains the RD, the advertised local CE-ID (1) and the lowest numbered remote CE-ID (3) to which this advertisement applies. This value is equal to the offset in line 8.

Line 8 contains the MPLS label information. PE1 is allocating two labels (range: 2). The mathematical rule to calculate the label is as follows:

• Label = Label base + (Remote CE-ID – offset)

• Frames from remote CE-ID 3 (CE-ID = offset = 3) should arrive to PE1 with MPLS label 800012 (Label base + 0 = 800012).

• Frames from remote CE-ID 4 (CE-ID = offset + 1 = 4) should arrive to PE1 with MPLS label 800013 (Label base + 1 = 800013).

In this P2P L2VPN, there is just one remote CE from the perspective of PE1 and its CE-ID is 4. This is why you can see label 800013 in Figure 6-4, but not label 800012. Out of the two labels (800012 and 800013), only one is used in this P2P L2VPN. So what’s the point of advertising a label block?

Figure 6-4. BGP VPWS signaling with LDP-based PSN Tunnel

Not only can you define several sites inside the same L2VPN instance, you can also declare several interfaces under the same site. For example, imagine there are two logical interfaces connecting CE1 to PE1—which might be on the same or in different physical links. In this case, you can connect (CE-ID 1, interface A) to remote CE-ID 3, and also connect (CE-ID 1, interface B) to remote CE-ID 4. This is still a VPWS service that connects each link from CE1 to one and only one remote CE. One single label block would be enough to achieve the two parallel VPWS services.

On the other hand, the L2VPN NLRI is also used for MP2MP L2VPN, where more labels are required for MAC learning purposes—see Chapter 7. Instead of defining two different L2VPN NLRIs, one for P2P and one for MP2MP, there is just one NLRI for both purposes, and that is another reason why you see a label block here.

The Layer2 Info extended community (lines 14 and 15) contains all the information about the attachment circuit and the way frames must be encapsulated in the MPLS core. This community must be consistent on both ends for the PW to come up.

Example 6-7 shows the L2VPN route advertised by IOS XR PE4, as seen from Junos RR1.

1     juniper@RR1> show route receive-protocol bgp 172.16.0.44
2                  table bgp.l2vpn.0 detail
3
4     bgp.l2vpn.0: 2 destinations, 4 routes (...)
5        172.16.0.44:1010:4:1/96 (2 entries, 1 announced)
6          Accepted
7          Route Distinguisher: 172.16.0.44:1010
8          Label-base: 24045, range: 16, offset: 1, status-vector: 0x7F 0xFF
9          Nexthop: 172.16.0.44
10         Localpref: 100
11         AS path: I
12         Communities: target:65000:1010
13                      Layer2-info: encaps: ETHERNET, control flags:[0x2]
14                                   Control-Word, mtu: 1986

Line 8 contains the MPLS label information. PE4 is allocating 16 labels (range: 16). Following is what the lowest and highest numbered labels are for:

• Frames from remote CE-ID 1 (CE-ID = offset = 1) should arrive to PE4 with MPLS label 24045 (Label base + 0 = 24045).

• Frames from remote CE-ID 16 (CE-ID = offset + 15 = 16) should arrive to PE1 with MPLS label 24060 (Label base + 15 = 24060).

In this P2P L2VPN, there is just one remote CE from the perspective of PE4 and it is CE-ID is 1. This is why you can see label 24045 in Figure 6-4, but not the other labels in the block (24046 up to 24060).

At this point, the PW is correctly established:

juniper@PE1> show l2vpn connections instance L2VPN-A
[...]
Instance: L2VPN-A
Edge protection: Not-Primary
  Local site: CE1-A (1)
    connection-site           Type  St     [...] # Up trans
    4                         rmt   Up     [...] 1
      Remote PE: 172.16.0.44, Negotiated control-word: Yes
      Incoming label: 800013, Outgoing label: 24045
      Local interface: ge-2/0/1.0
      Status: Up, Encapsulation: ETHERNET

RP/0/0/CPU0:PE4#show l2vpn xconnect group myL2VPN detail

Group myL2VPN, XC L2VPN-A.4:1, state is up; Interworking none
  Local CE ID: 4, Remote CE ID: 1, Discovery State: Advertised
  AC: GigabitEthernet0/0/0/3, state is up
    Type VLAN; Num Ranges: 1
    Outer Tag: 1010
    VLAN ranges: [123, 123]
    MTU 1994; XC ID 0x1; interworking none
[...]
  PW: neighbor 172.16.0.11, PW ID 262145, state is up (established)
      MPLS         Local             Remote
      ------------ ----------------- ----------------
      Label        24045             800013
      MTU          1986              unknown
      Control word enabled           enabled
      PW type      Ethernet          Ethernet
      CE-ID        4                 1
      ------------ ----------------- ----------------
[...]

L2VPN Forwarding Plane

Junos computes L2VPN forwarding entries by using a new set of RIBs. Let’s review the Junos routing tables used by all the MPLS services described so far in this book.

juniper@PE1> show route table mpls.0 protocol l2vpn

mpls.0: 15 destinations, 15 routes (15 active, ...)
+ = Active Route, - = Last Active, * = Both

800013         *[L2VPN/7] 1d 11:58:41
                > via ge-2/0/1.0, Pop [...]
ge-2/0/1.0     *[L2VPN/7] 1d 09:11:58, metric2 4
                > to 10.0.0.3 via ge-2/0/4.0,
                  Push 24045, Push 299808(top) [...]

Ethernet II, Src: MAC_PE1_ge-2/0/4, Dst: MAC P1_ge-2/0/3
MPLS Header, Label: 299808, Exp: 0, S: 0, TTL: 255
MPLS Header, Label: 24045, Exp: 0, S: 1, TTL: 255
PW Ethernet Control Word, Sequence Number: 0
Ethernet II, Src: MAC H1_Gi0/0/0/0, Dst: MAC H2_Gi0/0/0/2
    Type: 802.1Q Virtual LAN (0x8100)
# Outer VLAN header #
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 1010
    Type: 802.1Q Virtual LAN (0x8100)
# Inner VLAN header #
802.1Q Virtual LAN, PRI: 0, CFI: 0, ID: 123
    Type: IP (0x0800)
Internet Protocol Version 4, Src: 10.1.1.1, Dst: 10.1.1.4
Internet Control Message Protocol
    Type: 8 (Echo (ping) request) [...]

BGP VPWS—CE Multihoming to Several PEs

Imagine an L2 frame circulating in the following manner (see Figure 6-3): H3→CE3→PE3→PE1→CE1→PE2→PE1→CE1, and so on, looping in a triangle with vertices CE1, PE1 and PE2. In general, L2 frames do not have a Time-to-Live (TTL) field in the L2 header, so a frame can be looping forever. Such an L2 loop scenario typically causes broadcast storms and connectivity loss, thus it is extremely undesirable. This is why redundancy is one of the touchiest aspects of L2 services in general.

Strictly speaking, there is one only clean solution to this problem: moving to L3! In L3, every time a packet traverses a device, the TTL field is decremented and when it expires the packet is dropped, which limits the impact of forwarding loops. This is not always an option for applications and services, so let’s see what alternatives are available to prevent, detect, and mitigate L2 loops.

In traditional LANs, L2 loops are prevented with Spanning Tree protocols (STP, RSTP, MSTP, etc.). If a loop takes place, it can be handled with a series of techniques: MAC move detection, broadcast storm control and mitigation, policing, automatic port disabling, and so on. Still, L2 loops do sometimes happen in L2 bridging networks, no matter how many protection measures are in place.

Now moving to L2VPN, it is possible to keep these measures in place, but just for the sake of extra protection. The L2VPN design (assuming that there are no backdoor links) should guarantee a loop-free protection even without Spanning Tree. You may add Spanning Tree on top only as an extra protection layer.

There are several multihoming options in L2VPN, and the most robust are based on Link Aggregation Group (LAG). LAGs with Link Aggregation Control Protocol (LACP) are stateful, and a CE does not switch frames between two members of a LAG, which is a great built-in way to avoid L2 loops. Here are some common approaches:

• The CE may control the multihomed AC redundancy. For example, CE1 may group its two uplinks in a standard LAG. PE1 and PE2 both have a standard one-link LAG toward CE1, and their local System ID is different. Due to this System ID discrepancy, CE1 only activates one of the LAG’s links. If the chosen link is CE1-PE1, CE1 changes the flags of its LACP packets to PE2 to inform it that the link is not active in the LAG. The result is that PE1 flags its AC up, whereas PE2 flags its AC down. Although this solution relies on a LAG that goes to different chassis (PE1 and PE2), it is not what the industry calls a Multichassis LAG (MC-LAG).

• The solution may be implemented on the SP, and this is a preferred option for the SP because it can take control over the critical L2 redundancy decisions. CE1 groups its two uplinks in a standard LAG, and this time PE1 and PE2 are configured with the same System ID, so CE1 sees both links as if they were connected to the same chassis. PE1 and PE2 communicate to each other over the SP core by using Inter-Chassis Communication Protocol (ICCP) and decide on whether to keep both links active or only one of them. In the all-active case—only supported in EVPN—CE1 sees both links as part of the LAG and load-balances the frames between both uplinks. In the single-active case, then if PE2 assumes the standby role—according to the ICCP negotiation—it changes the flags of its LACP packets to CE1 in order to inform it that the link is not active in the LAG. As a result, CE1 only activates its link toward PE1. This is MC-LAG. A downgraded MC-LAG without ICCP is also possible and operational (it works), but this latter model does not benefit from the possibility of having a decision point at the multi-PE side.

If either PE1 or PE2 has its local AC down—or not active in the LAG—it must signal this state accordingly to the remote PEs. Otherwise, the remote PEs might send traffic to a PE that is not able to forward the traffic to the AC, which results in traffic blackholing. Let’s see how the AC status is signaled in BGP VPWS.

juniper@PE1> show l2vpn connections
[...]
Instance: L2VPN-A
Edge protection: Not-Primary
  Local site: CE1-A (1)
    connection-site           Type  St     Time last up
    4                         rmt   VC-Dn  -----
[...]

RP/0/0/CPU0:PE4#show l2vpn xconnect
XConnect               Segment 1              Segment 2
Group Name        ST   Description       ST   Description    ST
--------------------   --------------------   -----------------
L2VPN-A.4:1       DN   Gi0/0/0/3         UP   172.16.0.11    DN

juniper@PE1> show route advertising-protocol bgp 172.16.0.201
             table L2VPN-A.l2vpn.0 detail

L2VPN-A.l2vpn.0: 2 destinations, 3 routes (3 active, ...)
*  172.16.0.11:1010:1:3/96 (1 entry, 1 announced)
 BGP group iBGP-RR type Internal
    Route Distinguisher: 172.16.0.11:1010
    Label-base: 800004, range: 2, status-vector: 0x40, offset: 3
[..]Communities: target:65000:1010
                 Layer2-info: encaps: ETHERNET, control flags:[0x82]
                              Control-Word Site-Down, mtu: 0
                              site preference: 100

BGP VPWS multihoming at work

After understanding how the AC status is signaled with BGP, it’s time to see BGP VPWS multihoming in action. Junos supports draft-ietf-bess-vpls-multihoming, which describes BGP L2VPN active-backup multihoming scenarios such as in Figure 6-5. As of this writing, IOS XR does not support multihoming with BGP VPWS; however, it supports multihoming with LDP VPWS, as you will see later in this chapter.

Figure 6-5. BGP VPWS—CE Multihoming

The dashed line in Figure 6-5 means that PE2 is not forwarding traffic from/to the AC. This is typically the case if the LAG is in single-active mode (the AC is logically down on PE2). But, before uplink LAGs became popular, the CE uplinks were often not aggregated, and then the standby PE (PE2) saw the AC up but did not forward traffic. BGP VPWS multihoming takes care of both scenarios, but remember that LAG uplink is a good practice whenever possible.

With BGP VPWS multihoming, one, and only one, PE is chosen as a Designated Forwarder (DF) for CE1. How? PE1 and PE2 have a CE-ID (or Site ID) assigned to their CE1-facing attachment circuits. The key is that you must configure the same CE-ID value on both PEs. Why? Because they are connected to the same CE!

The site-identifier assignment is therefore critical:

• PE1 and PE2 both have local CE ID = 1 and remote CE ID = 4. The same local CE ID ensures that either PE1 or PE2—only one of them—is a DF.

• PE3 and PE4 both have local CE ID = 4 and remote CE ID = 1. The same local CE ID ensures that either PE3 or PE4—only one of them—is a DF.

The election of the DF for each L2VPN site is deterministic: every PE in the network chooses the same DF for each L2VPN site. The preferred way to control the outcome of this election is to configure a site preference:

Example 6-14. BGP VPWS—site preference—PE1 (Junos)

routing-instances {
    L2VPN-A {
        protocols {
            l2vpn {
                site CE1-A {
                    site-identifier 1;
                    site-preference primary;
}}}}}

Alternatively, you can configure site-preference backup. Junos automatically sets the preference numerical values accordingly (65,535 for primary and 1 for backup).

Looking back at Figure 6-5, PE1 has a higher site preference, so it becomes the DF for CE1. Junos automatically copies the site preference—which is a numeric field in the Layer2 Info extended community—to the well-known BGP Local Preference attribute. This ensures that all of the PEs in the network—those that support draft-ietf-bess-vpls-multihoming—choose PE1 as the Designated Forwarder for CE1.

What happens if the PE1-CE1 attachment circuit goes down? PE1 advertises its L2VPN route with a modified status vector in the NLRI and, more important, with the Down “D” bit in the Layer2 Info extended community flags. Thanks to this “D” bit, all the other PEs learn that PE1 can no longer be a DF for CE1. At this point, PE2 becomes the DF for CE1, and all the PEs agree on that. Last but not least, PE1 sets the Local Preference of its L2VPN route to zero.

Note that PE1 does not withdraw its route upon PE1-CE1 failure, it only changes its attributes.

Note

It is recommended to use a <ROUTER_ID>:<VPN_ID> RD scheme in BGP VPWS scenarios with CEs multihomed to several PEs.

What if CE1 and CE4 are also connected via a direct backdoor link without the intervention of the MPLS/IP backbone? In that case, which is strongly undesirable, they would need to run a loop prevention mechanism such as Spanning Tree, both on the L2VPN and on the backdoor link. This is only an option for P2P L2VPN.

Ethernet OAM (802.3ah, 802.1ag)

Looking back at Figure 6-2, there are many reasons why the CE might lose connectivity to the Service PE, and many of them do not involve a physical link failure on the Service PE side.

If the attachment circuit on the Service PE side is L3-capable, it can run a routing or a keepalive end-to-end protocol (such as BFD) and keep track of the PE1-CE’s connection health. However, this is not always possible, especially if the Service PE provides an L2VPN service to the end customer, in which case the attachment circuit is not L3-capable.

The CE and the PE can also run LACP, even in non-multihomed scenarios (one-link LAG). Although this approach works and is gaining traction in real deployments, this is not what LACP was designed for in the first instance.

Ethernet OAM was designed for this purpose and it comes to the rescue with the following L2 tools:

Link Fault Management (IEEE 802.3ah)

This provides, among other things, a link-local keepalive that is exchanged between L2-capable adjacent devices.

Connectivity Fault Management (IEEE 802.1ag)

This provides, among other things, a hierarchical end-to-end keepalive between two remote endpoints that are not necessarily adjacent to each other.

This book does not cover Ethernet OAM interoperability but here are some notes based on the authors’ deployment experience, particulary on Junos.

You can couple an Ethernet OAM action-profile to an interface. These profiles monitor events such as [link-]adjacency-loss (no longer receiving Ethernet OAM PDUs) or [interface|port]-status-tlv (receiving a down status TLV in an incoming Ethernet OAM PDU). As a result of one of these events, the attachment circuit can be considered to be logically down even if the physical interface is up. If that happens, the local PE updates the L2VPN status vector and notifies the remote PE.

However, the remote PE does not notify its CE by changing the [interface|port]-status-tlv of its Ethernet OAM PDUs. Why? This is intentional and the goal is to avoid a deadlock where CEs prevent one another from coming up.

On a side note, an Ethernet OAM action-profile that checks for [link-]adjacency-loss is event-driven. To bring an attachment circuit logically down, the PE must stop receiving keepalives. But if keepalives have never been received on the interface, the action-profile is not executed.

BGP VPWS—VLAN Tag Multiplexing

The basic PW configured in Example 6-3 and Example 6-4 can transport native Ethernet as well as VLAN-tagged frames. There is no restriction about the number of VLAN tags, or about the outer VLAN tag’s value. However, this approach has a big drawback: the entire AC physical interface is dedicated to a single PW; or, in other words, it is dedicated to a single remote PE. The model does not allow mapping different frames to different PWs in a per-VLAN basis; and it does not allow associating certain VLANs to other services such as L3VPN. Let’s consider a more flexible model!

If you look back to Figure 6-2, the last-mile access device inserts two VLAN tags in the user frame. What are these? It is very common to refer to the outer and inner tags as Service VLAN (S-VLAN) and Customer VLAN (C-VLAN), respectively.

Typically, the S-VLAN identifies one last-mile access device. Being the outer tag, this is the only VLAN that the aggregation network cares about. The mapping is not always 1:1, and there may be several S-VLANs handled by the same last-mile access device.

The C-VLAN typically identifies one customer circuit. Imagine that the last-mile access device receives—from the upstream aggregation network—a frame whose outer VLAN tag matches one of the S-VLANs for which it is responsible. The last-mile access device (which is a bridge, not a PE) determines, according to the combination of S-VLAN and C-VLAN, the actual end customer interface to which the frame must be forwarded. In that sense, C-VLANs act as pure multiplexers.

What if you want to map one S-VLAN to one PW? Example 6-15 shows how you can do it in Junos.

1     interfaces {
2         ge-2/0/1 {
3             mtu 2000;
4             flexible-vlan-tagging;
5             encapsulation flexible-ethernet-services;
6             unit 1010 {
7                 encapsulation vlan-ccc;
8                 vlan-id 1010;
9     }}}
10    routing-instances {
11        L2VPN-A {
12            instance-type l2vpn;
13            interface ge-2/0/1.1010;
14            route-distinguisher 172.16.0.11:1010;
15            vrf-target target:65000:1010;
16            protocols {
17                l2vpn {
18                    encapsulation-type ethernet-vlan;
19                    interface ge-2/0/1.1010;
20                    site CE1-A {
21                        site-identifier 1;
22                        ignore-mtu-mismatch;
23                        interface ge-2/0/1.1010 {
24                            remote-site-id 4;
25    }}}}}}

VLAN tags are just a multiplexing field in the VPWS world. They do not identify a bridge domain, because there is simply no intelligent bridging in VPWS. Indeed, a VPWS service is just a cross-connect between an AC and a PW.

A single VLAN tag is specified on line 8. As a result, all the following frames are transported by the VPWS service:

• Frames with single VLAN tag 1010.

• Frames with double VLAN tag, being 1010 the outer (SVLAN) tag. In this case, the CVLAN header is considered as part of the payload and it is preserved.

If you want to be more selective, you can use the syntax vlan-tags outer 1010 inner[-list] <CVLAN(s)>, specifying the CVLAN(s) that are mapped to the PW.

Example 6-16 shows the configuration to map one S-VLAN to one PW in IOS XR.

1     interface GigabitEthernet0/0/0/3
2      mtu 2000
3     !
4     interface GigabitEthernet0/0/0/3.1010 l2transport
5      encapsulation dot1q 1010
6     !
7     l2vpn
8      xconnect group myL2VPN
9       mp2mp L2VPN-A
10       vpn-id 123456789
11       l2-encapsulation vlan
12       autodiscovery bgp
13        rd 172.16.0.44:1010
14        route-target 65000:1010
15        signaling-protocol bgp
16         ce-id 4
17          interface GigabitEthernet0/0/0/3.1010 remote-ce-id 1
18    !

The handling of additional VLAN tags is the same as in Junos. If you want to be more selective, you can use the syntax encapsulation dot1q 1010 second-dot1q <CVLAN>, specifying the CVLAN that is mapped to the PW.

The two previous examples are interoperable between both vendors.

Finally, it is also possible to specify a list of S-VLANs that are mapped to a PW. Here are the changes that you would need to apply:

• In Junos, let’s use Example 6-15 as a reference. First, replace vlan-id (line 8) with, for example, vlan-id-list [1001-1019 2001-2009]. Then, set the encapsulation-type (line 18) to ethernet.

• In IOS XR, simply configure the list on the AC itself. In Example 6-16, line 5, use the syntax encapsulation dot1q 1010-1019.

This S-VLAN list scenario works fine in single-vendor scenarios, but, as of this writing, it does not interoperate between Junos and IOS XR. This is because Junos and IOS XR signal Ethernet and VLAN encapsulation, respectively. Neither Junos nor IOS XR allows changing the encapsulation successfully in this case, and the ignore-encapsulation-mismatch knob is only available in Junos.

There is one way to achieve interoperability, though. If the entire physical interface is reserved in the IOS XR device (Example 6-4), it interoperates successfully with Junos vlan-id-list.

BGP VPWS—VLAN Tag Translation and Manipulation

Now, put a mirror on Figure 6-2. Place it in the middle of the right-side cloud (labeled Central IP/MPLS Core) and look from the left so that you can see the same picture twice in a nice symmetrical manner. Imagine that two end customers—one on the far left and one on the far right—need to communicate to each other. The Service PEs can provide an L3 Service or an L2 Service to achieve that:

• If they provide an L3 Service, the ingress PE strips the Ethernet header—including the VLAN tags—from the user frame, as you can see at the top of Figure 6-1.

• In the L2 Service case, the Ethernet header—including its VLAN tags—is preserved. Now, the VLAN tags must match on the left and on the right. That is a tough provisioning challenge, and its workaround is VLAN tag translation.

In the following example, a frame with (SVLAN, CVLAN) = (1010, 123) in the PE-CE interface would have (SVLAN, CVLAN) = (2020, 123) in the PW. And if the frame has only one VLAN tag equal to 1010 on the AC, the tag would be 2020 on the PW.

# PE1 (Junos)

interfaces {
    ge-2/0/1 {
        unit 1010 {
            encapsulation vlan-ccc;
            vlan-id 1010;
            input-vlan-map {
                swap;
                vlan-id 2020;
            }
            output-vlan-map swap;
}}}

juniper@PE1> show interfaces ge-2/0/1.1010 | match vlan
    VLAN-Tag [ 0x8100.1010 ]
        In(swap-swap .2020) Out(swap-swap .1010)
    Encapsulation: VLAN-CCC

# PE4 (IOS XR)

interface GigabitEthernet0/0/0/3.1010 l2transport
 encapsulation dot1q 1010
 rewrite ingress tag translate 1-to-1 dot1q 2020 symmetric
!

This technique resolves mismatched SVLAN/CVLAN values at the PW’s endpoints. Indeed, Example 6-17 interoperates fine, regardless of the AC’s VLANs.

Finally, in Example 6-18, a frame with (SVLAN, CVLAN) = (1010, 123) in the AC would have single VLAN = 123 in the PW. And if the frame has only one VLAN tag equal to 1010 on the AC, it travels with no VLAN tag through the PW.

1     # PE1 (Junos)
2
3     interfaces {
4         ge-2/0/1 {
5             unit 1010 {
6                 encapsulation vlan-ccc;
7                 vlan-id 1010;
8                 input-vlan-map pop;
9                 output-vlan-map push;
10    }}}
11    routing-instances {
12        L2VPN-A {
13            protocols {
14                l2vpn {
15                    encapsulation-type ethernet;
16    }}}}
17
18    # PE4 (IOS XR)
19
20    interface GigabitEthernet0/0/0/3.1010 l2transport
21     encapsulation dot1q 1010
22     rewrite ingress tag pop 1 symmetric
23    !

Several combinations of the pop, push, and swap actions are available and the flexibility is so nice that there is often more than one solution to each challenge.

Just note that the SVLAN-pop scenario in Example 6-18 works fine in single-vendor scenarios, but as of this writing, it does not interoperate between Junos and IOS XR. The reason is the encapsulation mismatch discussed in the context of vlan-id-list, and it is specific to the current BGP VPWS multivendor implementation.

What if the AC is configured with two VLAN tags? In that case, you can apply the pop/push actions as in Example 6-18 (lines 8 and 9) and keep encapsulation ethernet-vlan on the PW. With these settings, interoperability is successful. However, the encapsulation mismatch issue is hit if there is a double pop/push instead of a single one, for exactly the same reasons discussed earlier.

BGP VPWS—PW Head-End (PWHE)

The traditional L2VPN as a transport architecture depicted back in Figure 6-2 offers a pair of possibilities to optimize provisioning and service delivery:

• Merging the functions of the last-mile access device and the Access L2VPN PE into a converged Access Node. This is a local implementation matter.

• Merging the functions of the Aggregation L2VPN PE and the Local Service PE in one single Service Node device, as in Figure 6-6.

Figure 6-6. Aggregation L2VPN and Local Service PE in one device

The second evolution brings the possibility of having one unified IP/MPLS backbone. The core can be flat from the IGP perspective or, for better scaling, it can be partitioned if the Local Service PE acts as an Area Border Router (ABR) or Autonomous System Border Router (ASBR), and you can find further details in Chapter 16.

This Local Service PE may be offering different services:

L3 Services (Internet or L3VPN)

In this case, the Local Service PE is an L3 Endpoint: you can ignore the mention or beyond in Figure 6-6. Each VLAN or SVLAN/CVLAN transported in the PW gets mapped to a different L3 logical interface. In turn, each such L3 interface can belong to the master routing table (Internet service) or to a L3VPN.

P2P L2VPN

The Infrastructure PW is stitched to the Service PW. PW stitching is not discussed in detail in this book.

MP2MP L2VPN

There is more about this option in Chapter 7.

Let’s discuss the first use case. It is called Pseudowire Head-End (PWHE or PWH), also known as Pseudowire Head-End Termination (PWHT or PHT). Among all the acronyms, this book picks PWHE.

We are in VLAN (de)multiplexing mode: the traffic from all the customers that share the same pair (last-mile access device, Local Service PE) are grouped into one single PW. Let’s focus on just one such PW.

Back in Figure 6-2, the Aggregation L2VPN PE has one AC pointing to the right, toward the Local Service PE. Similarly, the Local Service PE has one AC per VLAN(s) pointing to the left, toward the Aggregation L2VPN PE.

Now, in Figure 6-6 both functions are collapsed into the same device, labeled as Local Service PE: let’s call it Head-End PE from now on.

Conceptually, PWHE is simply VLAN (de)multiplexing on the same PW. The only difference is that the Head-End PE—converged Aggregation L2VPN PE + Local Service PE—terminates the L2 emulated circuit, instead of switching traffic between PW and external L2 ACs.

As of this writing, both IOS XR and Junos support PWHE with LDP VPWS, but only Junos supports PWHE with BGP VPWS. The following example uses BGP VPWS, but because the Head-End role (PWHE function) is implemented on a Junos PE, the end result is interoperable. The Access L2VPN PE, which runs IOS XR, simply sees a regular L2VPN, but it has no L3 visibility of the PWHE.

The IOS XR configuration is exactly the same as in Example 6-4. The only difference is on the Head-End PE side, running Junos (see Example 6-19).

1     chassis {
2         pseudowire-service device-count 10;
3         fpc 0 pic 0 tunnel-services bandwidth 10g;
4     }
5     interfaces {
6         ps1 {
7             anchor-point lt-0/0/0;
8             flexible-vlan-tagging;
9             mtu 9192;
10            unit 0 {
11                encapsulation ethernet-ccc;
12            }
13            unit 1010 {
14                vlan-tags outer 1010 inner 123;
15                family inet address 10.1.1.100/24;
16    }}}
17    routing-instances {
18        L2VPN-A {
19            instance-type l2vpn;
20            interface ps1.0;
21            route-distinguisher 172.16.0.1:111;
22            vrf-target target:65000:111;
23            protocols {
24                l2vpn {
25                    encapsulation-type ethernet;
26                    interface ps1.0;
27                    site CE1-A {
28                        site-identifier 1;
29                        mtu 2000;
30                        interface ps1.0 remote-site-id 4;
31    }}}}}}

You can view each ps interface as the local termination of a PW coming from one single last-mile access device. With the previous configuration (line 2), you can define up to 10 psX interfaces (ps0 through ps9), each mapped to/from one PW. These interfaces are anchored (line 7) to an lt interface (line 3). Anchoring instantiates the psX interface in a Packet Forwarding Engine (PFE) inside the router. This makes the service actually work by associating bandwidth resources and also enabling Quality of Service (QoS).

Now, the psX.0 logical interface (lines 10 through 12) is special in that it represents the PW’s AC inside the Head-End PE (lines 20, 26, and 30). VLANs are then used as (de)multiplexers and many non-zero units (lines 13 through 15) can be created: these are the service endpoints. In this case, the service is L3 but it could be in theory L2 (not implemented yet), as well.

The L3 endpoint units such as ps1.1010 can have single or dual VLAN tags. They can be kept in the master routing table or declared in a VRF. Although as of this writing the latter is not officially supported yet, the authors’ lab testing was successful.

The logical interface ps1.1010 is static. But it is also possible to create dynamic interfaces by using VLAN autosensing, which opens the door to a very flexible broadband access and subscriber management model. The classical BNG (Broadband Network Gateway) is replaced with a Service PE that can be anywhere in the MPLS core.

BGP VPWS—Load Balancing

As you saw before, the CW is required to ensure that all the L2VPN frames of the same flow are forwarded on the same path so that they do not arrive to the destination out of order. The downside of the CW is that all the packets of the same PW may follow the same path. For some applications, this is a poor load-balancing scheme that can easily lead to traffic polarization in the core network. There are two solutions to this challenge:

RFC 6790 - The Use of Entropy Labels in MPLS Forwarding

It is applicable to MPLS in general (not only L2VPN) and it relies on inserting two MPLS labels just below the transport label: the Entropy Label Indicator (ELI), which is a reserved fixed label with value 7, and the entropy label itself. The full MPLS label stack from top to bottom would be: the transport label, the ELI, the entropy label, and the VPN label (if any).

RFC 6391 - Flow-Aware Transport (FAT) of Pseudowires over a MPLS Packet Switched Network

This is only available for L2VPN and it relies on inserting an MPLS label—a so-called flow label—at the bottom of the stack. This label lies between the L2VPN label and the Control Word.

The principle of both approaches is quite simple: entropy (or flow) labels have pseudo-random values and are not interpreted by any routers. By inserting such label(s), the ingress PE is actually adding a variable seed for load-balancing hash computation when the packet arrives to transit LSRs. The ingress PE assigns the same entropy (or flow) label value to every packet of a given flow, so packet order is guaranteed. As a result of the entropy (or flow) label, different flows in the same PW can be mapped to different equal-cost paths.

Here is what happens when the packet reaches the egress PE:

• In the entropy label case, due to PHP the ELI is exposed (although the penultimate LSR may decide to also pop the ELI and entropy label). If needed, the egress PE removes the ELI and the entropy label, exposing the service label (if any). The packet is then mapped to the appropriate service—for example, to an L2VPN AC.

• In the FAT scenario, due to PHP the L2VPN label is exposed. The egress PE maps the packet to the appropriate L2VPN AC, and then it pops all the remaining labels (VPN and flow label) without any further processing.

As of this writing, entropy labels were supported by Junos, but not by IOS XR. On the other hand, this book’s tests provided interoperable PW with FAT and LDP VPWS.

As for BGP VPWS, flow labels can be enabled in IOS XR but not in Junos. The result is interoperable, in the sense that PE4 pushes the flow label and PE1 is able to pop it and forward the frame successfully. In the other direction, PE1 does not push the flow label, but that is fine for PE4, too.

Example 6-20 shows the IOS XR configuration.

l2vpn
 xconnect group myL2VPN
  mp2mp L2VPN-A
   autodiscovery bgp
    signaling-protocol bgp
     load-balancing flow-label both static
!

LDP VPWS Configuration at the PEs

Let’s begin with a scenario in which a physical AC is mapped to a PW. The AC configuration is skipped because it is similar to BGP VPWS (see Example 6-3, lines 1 through 7 and Example 6-4, lines 1 through 4).

Example 6-21 shows the PE1—PE4 PW configuration at Junos PE1.

1     protocols {
2         ldp {
3             interface lo0.0;
4         }
5         l2circuit {
6             neighbor 172.16.0.44 {
7                 interface ge-2/0/1.0 {
8                     virtual-circuit-id 13579;
9                     encapsulation-type ethernet;
10                    ignore-mtu-mismatch;
11                    pseudowire-status-tlv;
12    }}}}

One key aspect of LDP VPWS is its lack of a native autodiscovery mechanism. You must configure neighbors (line 6) explicitly. Later you will see how this limitation is overcome by using BGP AD.

The service is identified by a VC ID (line 8) that must match on both ends of the PW.

The pseudowire-status-tlv usage is explained later.

Following is the PE1—PE4 PW configuration at PE4, which runs IOS XR:

l2vpn
 ignore-mtu-mismatch
 pw-class PW-L2CKT-UNTAGGED
  encapsulation mpls
   protocol ldp
   control-word
   transport-mode ethernet
 !
 xconnect group myL2CKT
  p2p L2CKT-A
   interface GigabitEthernet0/0/0/3
   neighbor ipv4 172.16.0.11 pw-id 13579
    pw-class PW-L2CKT-UNTAGGED
!

LDP VPWS Signaling and Forwarding Planes

With the previous configuration, the PW comes up. Let’s verify that.

# PE1 (Junos)

juniper@PE1> show l2circuit connections interface ge-2/0/1.0
[...]
Neighbor: 172.16.0.44
 Interface                 Type  St     # Up trans
 ge-2/0/1.0(vc 13579)    rmt   Up     1
   Remote PE: 172.16.0.44, Negotiated control-word: No
   Incoming label: 299776, Outgoing label: 16080
   Negotiated PW status TLV: Yes
   Local PW status code: 0x0000, Neighbor PW status code: 0x0000
   Local interface: ge-2/0/1.0, Status: Up, Encapsulation: ETHERNET
   Flow Label Transmit: No, Flow Label Receive: No

# PE4 (IOS XR)

RP/0/0/CPU0:PE4#show l2vpn xconnect group myL2CKT
XConnect               Segment 1          Segment 2
Group    Name     ST   Description     ST  Description         ST
--------------------   ------------------  ----------------------
myL2CKT  L2CKT-A  UP   Gi0/0/0/3       UP  172.16.0.11  13579  UP
-----------------------------------------------------------------

In IOS XR, you can use the show l2vpn xconnect detail option in order to see the local and remote PW status TLV values. The following couple of tips can help you to interpret the output of both Junos and IOS XR commands:

• Local PW Status in Junos means the same as Outgoing PW Status in IOS XR: the advertised PW Status TLV value.

• Neighbor PW Status in Junos means the same as Incoming Status in IOS XR: the received PW Status TLV.

Figure 6-7 shows an example in which the transport LSP is signaled by using LDP. This is just one option and all the other transport protocols are also available. Indeed, LDP-based L2VPNs can also be transported with RSVP-TE, BGP-LU, and SPRING-signaled LSPs, as well as with IP (e.g., GRE) tunnels.

Figure 6-7. LDP VPWS signaling with LDP-based PSN Tunnel

The forwarding plane is the same as in BGP VPWS. Just one note about the CW: by default, an LDP VPWS whose endpoints run Junos negotiate to use the CW, whereas two IOS XR PEs negotiate not to use it. As a result, in a multivendor PW with one PE running Junos and the other running IOS XR, there is no CW unless the IOS XR PE is explicitly instructed to use it (Example 6-22).

LDP VPWS—CE Multihoming and PW Redundancy

The concepts were already discussed in the context of BGP VPWS. With the FEC 129 model, discussed in Chapter 7, it is possible to deploy the same multihoming mechanisms as in BGP VPWS, but let’s see what can be done with plain FEC 128.

protocols {
    l2circuit {
        neighbor 172.16.0.44 {
            interface ge-2/0/1.0 {
                virtual-circuit-id 13579;
                pseudowire-status-tlv;
                backup-neighbor 172.16.0.33 {
                    virtual-circuit-id 13579;
                    [hot-]standby;
}}}}}

l2vpn
 xconnect group myL2CKT
  p2p L2CKT-A
   interface GigabitEthernet0/0/0/3
   neighbor ipv4 172.16.0.11 pw-id 13579
    pw-class PW-L2CKT-UNTAGGED
    backup neighbor 172.16.0.22 pw-id 13579
     pw-class PW-L2CKT-UNTAGGED
!

LDP VPWS—VLAN Tag Multiplexing

As with BGP VPWS, you can map one or more S-VLANs to a PW in LDP VPWS. Example 6-26 builds on top of the AC configuration in Example 6-15 (lines 1 through 9), except that the unit and VLAN IDs are 1020 instead of 1010 now.

protocols {
    l2circuit {
        neighbor 172.16.0.44 {
            interface ge-2/0/1.1020 {
                virtual-circuit-id 13579;
                ignore-mtu-mismatch;
                pseudowire-status-tlv;
}}}}

Likewise, the following example builds on top of the AC configuration in Example 6-16 (line 1 through 6), after replacing 1010 with 1020:

l2vpn
 ignore-mtu-mismatch
 pw-class PW-L2CKT-TAGGED
  encapsulation mpls
   protocol ldp
   control-word
   transport-mode vlan passthrough
!
 xconnect group myL2CKT
  p2p L2CKT-A
   interface GigabitEthernet0/0/0/3.1020
   neighbor ipv4 172.16.0.11 pw-id 13579
    pw-class PW-L2CKT-TAGGED
!

To transport all the frame’s VLAN tags on the PW, IOS XR needs the vlan passthrough knob. This is the default in Junos.

The strategy to map an SVLAN and one or more CVLAN(s) to a PW is the same as in BGP VPWS, and the AC configuration is identical, so it is skipped here.

As for the possibility to map a list of SVLANs to a PW, the AC configuration remains the same as in BGP VPWS (vlan-id-list, etc.), and you can achieve interoperability by using the following Junos configuration:

protocols {
    l2circuit {
        neighbor 172.16.0.44 {
            interface ge-2/0/1.1020 {
                encapsulation-type ethernet-vlan;
}}}}

So, multiplexing several SVLANs in the same PW fully interoperates without having to reserve a physical interface on any PE. This is an advantage of LDP VPWS over BGP VPWS that has nothing to do with the protocols; it has to do with the current implementation in both vendors.

LDP VPWS—VLAN Tag Translation and Manipulation

Again, the concepts are the same as in BGP VPWS. The techniques are already illustrated in Example 6-17 and Example 6-18 (just ignore lines 11 through 16 in the latter). And the good news with the current LDP VPWS implementation is that all of the scenarios—not just a subset—are fully interoperable.

The BGP VPWS interoperability issue happens if all the VLAN tags (one or two) configured on the AC are popped at the PW’s ingress—and pushed at egress. Junos and IOS XR considered the resulting encapsulation to be Ethernet and VLAN, respectively. Now, in LDP VPWS it is possible to tune the encapsulation on the Junos side, achieving interoperability. As of this writing, the difference is due exclusively to the implementation in both vendors; it has nothing to do with the protocols.

The adjustment required on the Junos PE side in order to achieve full interoperability with IOS XR is already shown in Example 6-28.

LDP VPWS—PWHE

Once again, the concepts are the same as in BGP VPWS. And for the same implementation reasons just discussed, in LDP VPWS it is not necessary to dedicate a physical interface on any PE to achieve interoperability between IOS XR and Junos.

Following is an interoperable PWHE configuration in Junos:

1     protocols {
2         ldp {
3             interface lo0.0;
4         }
5         l2circuit {
6             neighbor 172.16.0.44 {
7                 interface ps2.0 {
8                     virtual-circuit-id 13579;
9                     ignore-mtu-mismatch;
10                    control-word;
11                    encapsulation-type ethernet-vlan;
12                    pseudowire-status-tlv;
13    }}}}

The configuration of the ps2 interface follows the same principle as Example 6-19, lines 1 through 16: ps2.0 binds to the PW, and ps2.<X> are the L3 multiplexed interfaces.

In Example 6-29, PE1 is acting as the PWHE, and PE4 as a plain L2VPN PE.

In Example 6-30, we’ll reverse the roles, and make IOS XR PE4 the PWHE.

1     generic-interface-list GIL-CORE
2      interface GigabitEthernet0/0/0/0
3      interface GigabitEthernet0/0/0/1
4     !
5     interface PW-Ether100
6      attach generic-interface-list GIL-CORE
7     !
8     interface PW-Ether100.1020
9      ipv4 address 10.2.2.200 255.255.255.0
10     encapsulation dot1q 1020 second-dot1q 123
11    !
12    l2vpn
13     ignore-mtu-mismatch
14     xconnect group myL2CKT
15      p2p L2CKT-A
16       interface PW-Ether1020
17       neighbor ipv4 172.16.0.11 pw-id 13579
18        pw-class PW-L2CKT-TAGGED
19    !

PW-Ether interfaces in IOS XR are anchored on physical interfaces. The best practice is to include all the core-facing links in the generic-interface-list (lines 1 through 3). The pw-class PW-L2CKT-TAGGED configuration is the same as in Example 6-27.

LDP VPWS—FAT

The concept is already discussed in “BGP VPWS Signaling”. This book’s tests provided interoperable LDP VPWS with FAT by using the configuration shown in Example 6-31.

# PE1 (Junos)

protocols {
    l2circuit {
        neighbor 172.16.0.44 {
            interface ge-2/0/1.1020 {
                flow-label-transmit-static;
                flow-label-receive-static;
}}}}

# PE4 (IOS XR)

l2vpn
 pw-class PW-L2CKT    ! This pw-class is applied to the PW
  encapsulation mpls
   load-balancing
    flow-label both static
!

The usage of flow labels can also be negotiated during LDP VPWS establishment, but it did not provide successfully interoperable results in this book’s tests. On the other hand, when FAT was statically configured as in Example 6-31, interoperability was successful.