Layer 2 Vpn Architectures [Electronic resources] نسخه متنی

Figure 15-1. VPLS Network Reference Model

VPLS Configuration Case Studies" section later in this chapter examines the magnitude of such savings.

What makes VPLS particularly attractive to service providers is its plug-and-play nature. After you provision PE routers with multipoint connectivity for VPLS customers, you need to reconfigure only the directly attached PE router when adding, removing, or relocating a CE router within a Layer 2 VPN. In contrast, you must reconfigure every peering PE router if the Layer 2 VPN is based on a point-to-point architecture. With VPLS, packets are no longer forwarded based on the one-to-one mapping between an attachment circuit and a pseudowire on a PE router. Rather, a PE router uses a Layer 2 forwarding table to determine the outgoing paths based on the destination MAC addresses. A Layer 2 forwarding table is populated dynamically with MAC addresses and next-hop interfaces through the learning process. The next few sections explain the types of service that VPLS provides, protocol signaling, and packet forwarding behaviors.

Service Definitions

VPLS offers two types of service:

TLS

Ethernet Virtual Connection Service (EVCS)

The services are differentiated by the way that MAC addresses are learned and the way that bridging protocol data units (BPDU) are processed. TLS performs unqualified learning, in which all customer VLANs of a Layer 2 VPN are treated as if they were in the same broadcast domain.

Source MAC addresses are learned and forwarding entries are populated in the same Layer 2 forwarding table regardless of whether they are tagged or untagged. This means that MAC addresses have to be unique among all customer VLANs. Overlapping MAC addresses can cause confusion in the Layer 2 forwarding table and result in loss of customer packets.

Besides tagged and untagged Ethernet packets, a PE router that provides TLS also forwards BPDUs that it receives from the CE-facing interface to other interfaces or pseudowires without processing. Such transparency in BPDU forwarding makes the CE routers perceive that they are connected directly through an Ethernet hub instead of through a series of virtual switches, which you learn more about in the next section. Virtual switches, like real physical switches, terminate and process BPDUs by default.

Figure 15-2 illustrates an example of TLS.

For customers who want to keep a separate broadcast domain for each VLAN, EVCS is a more appropriate choice. In EVCS, the outer VLAN tag on the Ethernet packet differentiates one customer VLAN instance from another. Each VLAN has its own MAC address space, which allows qualified learning. In qualified learning, MAC addresses of different VLANs might overlap with one another, and each VLAN has a separate Layer 2 forwarding table.

EVCS keeps the broadcast domain on a per-VLAN basis and does not extend the spanning tree across the MPLS network. BPDU packets from CE routers are dropped or processed at PE routers. In such cases, CE routers do not see each other directly in the spanning tree. Figure 15-3 shows an example of EVCS. Suppose that a VPLS customer has four sites that form two separate broadcast domains. CE1 and CE2 connect to the same PE router but belong to different broadcast domains. IEEE 802.1q VLAN encapsulation is used between the CE routers and PE router to separate the traffic of different broadcast domains.

Note

If it is necessary to exchange Layer 3 traffic among different broadcast domains, PE routers can provide Layer 3 connectivity using the Integrated Routing and Bridging (IRB) capability. Layer 2 traffic cannot be forwarded from one broadcast domain to another.

Virtual Switch

Each service that is defined in the previous section is offered by a virtual switch inside a PE router. When provisioned to support multiple VPLS customers, the PE router effectively is partitioned into multiple virtual switches. A given PE router has at most one virtual switch for every VPLS domain.

A virtual switch consists of a bridge module, an emulated LAN interface, and a virtual forwarding instance (VFI), as shown in Figure 15-4. CE routers are connected to the bridge module through attachment circuits. Each bridge also has one emulated LAN interface that connects to the VFI.

The bridge module in a virtual switch has the equivalent role of that in a physical Ethernet switch. It makes no distinction between the emulated LAN interface and any physical LAN interface in terms of bridging functions, such as MAC address learning and aging, and packet flooding. Besides the bridge module maintaining a forwarding table that maps MAC addresses to attachment circuits, it can run spanning-tree protocols on them.

A VFI has similar functionality to a bridge but performs bridging operations on pseudowires instead of attachment circuits. It maintains a forwarding table that maps MAC addresses to pseudowires. The forwarding table is populated through the MAC address learning process based on packets it receives on pseudowires. It never learns the MAC addresses of the packets it receives on attachment circuits.

Note

In some literature, virtual switching instance (VSI) is used in place of VFI. They are inter-changeable terms.

Conceptually, the forwarding table of a bridge module and that of a VFI are different entities. In practice, VPLS implementations can choose either to create separate tables for each or combine them into a single table. Because the actual form of the data structures does not affect VPLS operations, this chapter assumes a single Layer 2 forwarding table for every VPLS domain for the sake of simplicity.

VPLS Forwarding and Flooding

In a point-to-point Layer 2 VPN architecture, an attachment circuit and a pseudowire have a one-to-one mapping. Packets that are received from a CE router are forwarded to only one pseudowire based on the attachment circuit that packets arrive on.

In VPLS, attachment circuits and pseudowires are connected through a virtual switch. Because more than one attachment circuit and pseudowire can attach to the same virtual switch, the correlation between attachment circuits and pseudowires becomes many-to-many.

The forwarding decision is made in two stages in VPLS, as follows:

A packet is mapped to a virtual switch and its corresponding Layer 2 forwarding table based on the attachment circuit or pseudowire that the packet arrives on.

The virtual switch looks up the forwarding table using the destination MAC address and determines the proper forwarding action. Unless a policy is in place to block this particular packet, the forwarding action can be either broadcast or unicast.

Initially, the Layer 2 forwarding table does not include dynamically learned entries.

When packets arrive on attachment circuits or pseudowires, MAC address learning takes place as part of the forwarding process. If the source MAC address is not present in the forwarding table, it is added to the table with the arriving attachment circuit or pseudowire as the outgoing interface. Also, an aging timer is started for the new forwarding entry. If the source MAC address is already in the forwarding table, no new entry is created, and the aging timer is refreshed so that an active MAC address is not flushed out prematurely.

Unlike Layer 3 forwarding, in which packets are dropped if no forwarding entry matches the Layer 3 destination address, VPLS employs a flooding process when the virtual switch receives a packet that has an unknown destination MAC address. The flooding process also applies to multicast and broadcast packets. Resembling that of a real bridge, VPLS flooding also has its distinct nuances that pertain to pseudowires. Depending on whether the packet receives on an attachment circuit or a pseudowire and whether Layer 2 split horizon is enabled, flooding can take different courses of action.

When a packet with an unknown destination MAC address arrives on an attachment circuit, it is flooded to all other attachment circuits and all pseudowires that are bound to the virtual switch. When Layer 2 split horizon is enabled on a pseudowire, packets that arrive on this pseudowire are flooded to all attachment circuits, but not a pseudowire. When Layer 2 split VPLS Deployment Models" section later in this chapter examines the correlations between split horizon and different deployment models.

VPLS Signaling

Chapter 2, "Pseudowire Emulation Framework and Standards," explained two MPLS pseudowire emulation frameworks, known as draft-martini and draft-kompella, in the context of point-to-point Layer 2 VPN architectures. Each architecture defines a signaling protocol to establish and manage pseudowires. Just as the networking community debates which signal protocol is superior in the point-to-point Layer 2 VPN architectures, a similar debate arose when VPLS debuted as a multipoint Layer 2 VPN architecture. The two competing proposals that were made to the networking community are based on the same ideas as in draft-martini and draft-kompella, where one is based on Label Distribution Protocol (LDP) and the other is based on Border Gateway Protocol (BGP). Despite being applied to a new architecture like VPLS, the fundamental property of each protocol still remains.

The LDP-based VPLS solution, like its point-to-point counterpart, receives much wider acceptance in terms of vendor implementation and network deployment. The VPLS solution that Cisco IOS offered is an LDP-based solution.

To comprehend the details of the BGP-based VPLS solution, refer to the relevant documents of the Layer 2 VPN working group at the IETF web site (Chapter 6, "Understanding Any Transport over MPLS." The Pseudowire Type field in the Pseudowire ID FEC element is Ethernet for VPLS, which is the same as for the point-to-point EoMPLS.

The Pseudowire ID field in the Pseudowire ID FEC element serves the binding of two remotely located entities, such as attachment circuits or VFIs. For point-to-point Layer 2 VPNs, the Pseudowire ID only needs to be unique between a pair of PE routers. For VPLS Layer 2 VPNs, each VPLS domain is identified by a globally unique VPN ID, which means that you have to provision VFIs of the same VPLS domain with the same VPN ID on all participating PE routers. When you are setting up pseudowires for a VPLS domain, instead of VC IDs or Pseudowire IDs of individual point-to-point pseudowires, you have the VPN ID in the Pseudowire ID field. Because point-to-point and VPLS Layer 2 VPNs share the same Pseudowire ID space, you need to ensure that VPN IDs that are used in VPLS do not overlap with Pseudowire IDs that are used in point-to-point Layer 2 VPNs.