Presentation is loading. Please wait.

Presentation is loading. Please wait.

An Introduction to VPLS

Similar presentations


Presentation on theme: "An Introduction to VPLS"— Presentation transcript:

1 An Introduction to VPLS
Jeff Apcar, Distinguished Services Engineer APAC Technical Practices, Advanced Services

2 Agenda VPLS Introduction Pseudo Wire Refresher VPLS Architecture
VPLS Configuration Example VPLS Deployment Summary VPLS is like having Paris Hilton as your girlfriend The concept is fantastic, but in reality the experience might not be that great But you are still willing to take her out, as long as you can handle her behaviour

3 Do you want to date VPLS? “VPLS is like having Paris Hilton as your girlfriend. The concept is fantastic, but in reality the experience might not be what you expected. But… we’re still willing to give it a go as long as we can understand/handle her behaviour” VPLS is like having Paris Hilton as your girlfriend The concept is fantastic, but in reality the experience might not be that great But you are still willing to take her out, as long as you can handle her behaviour Me, Just Then

4 VPLS Introduction

5 Virtual Private LAN Service (VPLS)
VPLS defines an architecture allows MPLS networks offer Layer 2 multipoint Ethernet Services SP emulates an IEEE Ethernet bridge network (virtual) Virtual Bridges linked with MPLS Pseudo Wires Data Plane used is same as EoMPLS (point-to-point) VPLS is an Architecture PE PE CE CE CE

6 Virtual Private LAN Service
End-to-end architecture that allows MPLS networks to provide Multipoint Ethernet services It is “Virtual” because multiple instances of this service share the same physical infrastructure It is “Private” because each instance of the service is independent and isolated from one another It is “LAN Service” because it emulates Layer 2 multipoint connectivity between subscribers

7 Why Provide A Layer 2 Service?
Customer have full operational control over their routing neighbours Privacy of addressing space - they do not have to be shared with the carrier network Customer has a choice of using any routing protocol including non IP based (IPX, AppleTalk) Customers could use an Ethernet switch instead of a router as the CPE A single connection could reach all other edge points emulating an Ethernet LAN (VPLS)

8 VPLS is defined in IETF VPWS, VPLS, IPLS Application ISOC General
L2VPN Formerly PPVPN workgroup IAB L3VPN Internet BGP/MPLS VPNs (RFC 4364 was 2547bis) IP VPNs using Virtual Routers (RFC 2764) CE based VPNs using IPsec PWE3 IETF Ops and Mgmt VPLS is defined under the auspices of the IETF (which is part of Internet Society/Internet Architecture Board). IETF is broken into 9 categories each which is addressing a certain technical ara consisting of working groups. VPLS is under the L2VPN working group (once part of PPVPN – which was broken into two working groups L2VPN and L3VPN as things got more complicated). Another important working group which directly affects the operation of VPLS is the PWE3 working group who is tasked with defining the process and procedures for the create of Pseudo Wires over and IP/MPLS backbone. Routing MPLS Pseudo Wire Emulation edge-to-edge Forms the backbone transport for VPLS Security Transport As of 2-Nov-2006

9 Classification of VPNs
Network Based CPE Based Layer 2 Layer 3 Layer 3 Ethernet P2P VPWS VPLS IPLS MPLS VPN Virtual Router IPSec GRE Frame Relay ATM Frame Relay PPP/HDLC ATM/Cell Relay Ethernet (P2P) Ethernet (P2MP) Ethernet (MP2MP)

10 Like-to-Like Any-to-Any
L2VPN Models L2VPN MPLS IP Like-to-Like Any-to-Any Like-to-Like VPWS Point-to-Point VPLS/IPLS Multipoint L2TPv3 Point-to-Point PPP HDLC PPP HDLC ATM AAL5/Cell ATM AAL5/Cell Ethernet FR Ethernet Ethernet FR

11 IP LAN-Like Service (IPLS)
An IPLS is very similar to a VPLS except The CE devices must be hosts or routers not switches The service will only carry IPv4 or IPv6 packets IP Control packets are also supported – ARP, ICMP Layer 2 packets that do not contain IP are not supported IPLS is a functional subset of the VPLS service MAC address learning and aging not required Simpler mechanism to match MAC to CE can be used Bridging operations removed from the PE Simplifies hardware capabilities and operation Defined in draft-ietf-l2vpn-ipls

12 VPLS Components N-PE N-PE MPLS Core N-PE CE router CE router CE router
Pseudo Wires within LSP Virtual Switch Interface (VSI) terminates PW and provides Ethernet bridge function Attachment circuits Port or VLAN mode Mesh of LSP between N-PEs N-PE N-PE CE router CE router CE router CE router CE switch CE switch MPLS Core Targeted LDP between PEs to exchange VC labels for Pseudo Wires CE router Attachment CE can be a switch or router CE switch N-PE

13 Virtual Switch Interface
Flooding / Forwarding MAC table instances per customer (port/vlan) for each PE VFI will participate in learning and forwarding process Associate ports to MAC, flood unknowns to all other ports Address Learning / Aging LDP enhanced with additional MAC List TLV (label withdrawal) MAC timers refreshed with incoming frames Loop Prevention Create full-mesh of Pseudo Wire VCs (EoMPLS) Unidirectional LSP carries VCs between pair of N-PE Per A VPLS use “split horizon” concepts to prevent loops

14 Pseudo Wire Refresher

15 Pseudo Wires in VPLS IETF working group PWE3
‘Pseudo Wire Emulation Edge to Edge’; Requirements detailed in RFC3916 Architecture details in RFC3985 Develop standards for the encapsulation & service emulation of “Pseudo Wires” Across a packet switched backbone A VPLS is based on a full mesh of Pseudo Wires

16 Pseudo Wire Reference Model (RFC 3916)
Emulated Service Pseudo Wire PSN Tunnel (LSP in MPLS) Customer Site Customer Site CE CE IP/MPLS PW1 Attachment Circuit PW2 CE PE1 PE2 Customer Site CE Customer Site Pseudo Wire PDUs A PWES is either: - an Ethernet link or a VLAN link between two ports, or - an ATM VC or VP, or - a Frame Relay VC, or - a TDM circuit, or - an MPLS LSP Note that the PSN tunnel may be MPLS, L2TP, GRE and so on .. UTI is another mechanism to transport the PDUs between ingress and egress PE – in this case the PW is created using a UTI tunnel. Packet Switched Network (PSN) IP or MPLS A Pseudo Wire (PW) is a connection between two provider edge devices connecting two attachment circuits (ACs) In an MPLS core a Pseudo Wire uses two MPLS labels Tunnel Label (LSP) identifying remote PE router VC Label identifying Pseudo Wire circuit within tunnel

17 Pseudo Wire Standards (Care for a Martini?)
RFC 4446 – Numeric values for PW types RFC 4447 – Distribution mechanism for VC labels Previously called draft-martini-l2circuit-trans-mpls RFC 4448 – Encapsulation for Ethernet using MPLS Previously called draft-martini-l2circuit-encap-mpls Other drafts are addressing different encapsulations draft-ietf-pwe3-frame-relay/draft-ietf-pwe3-atm-encap draft-ietf-pwe3-ppp-hdlc-encap-mpls Originally part of draft-martini-l2circuit-encap-mpls

18 MPLS PW Types (RFC 4446) 0x0001 Frame Relay DLCI ( Martini Mode )
0x0002 ATM AAL5 SDU VCC transport 0x0003 ATM transparent cell transport 0x0004 Ethernet Tagged Mode (VLAN) 0x0005 Ethernet (Port) 0x0006 HDLC 0x0007 PPP 0x0008 SONET/SDH Circuit Emulation 0x0009 ATM n-to-one VCC cell transport 0x000A ATM n-to-one VPC cell transport 0x000B IP Layer2 Transport 0x000C ATM one-to-one VCC Cell Mode 0x000D ATM one-to-one VPC Cell Mode 0x000E ATM AAL5 PDU VCC transport 0x000F Frame-Relay Port mode 0x0010 SONET/SDH Circ. Emu. over Packet 0x0011 Structure-agnostic E1 over Packet 0x0012 Structure-agnostic T1 over Packet 0x0013 Structure-agnostic E3 over Packet 0x0014 Structure-agnostic T3 over Packet 0x0015 CESoPSN basic mode 0x0016 TDMoIP AAL1 Mode 0x0017 CESoPSN TDM with CAS 0x0018 TDMoIP AAL2 Mode 0x0019 Frame Relay DLCI This slides shows different available Pseudo Wire types used to different attachment circuits. The highlided types are then one we going to cover today. During the session you will see how these PW Type are applied during your troubleshooting we will go in to detail further in this session.

19 VC Information Distribution (RFC 4447)
VC labels are exchanged across a targeted LDP session between PE routers Generic Label TLV within LDP Label Mapping Message LDP FEC element defined to carry VC information Such PW Type (RFC 4446) and VCID VC information exchanged using Downstream Unsolicited label distribution procedures Separate “MAC List” TLV for VPLS Defined in draft-ietf-l2vpn-vpls-ldp Use to withdraw labels associated with MAC addresses LDP label mapping message described in RFC 3036

20 VC Distribution Mechanism using LDP
Directed LDP Session between PE1 and PE2 Tunnel Label(s) gets to PE router Label Switch Path Customer Site Customer Site CE CE IP/MPLS CE PE1 PE2 Customer Site Customer Site CE LSP created using IGP+LDP or RSVP-TE A PWES is either: - an Ethernet link or a VLAN link between two ports, or - an ATM VC or VP, or - a Frame Relay VC, or - a TDM circuit, or - an MPLS LSP Note that the PSN tunnel may be MPLS, L2TP, GRE and so on .. UTI is another mechanism to transport the PDUs between ingress and egress PE – in this case the PW is created using a UTI tunnel. VC Label identifies interface Unidirectional Tunnel LSP between PE routers to transport PW PDU from PE to PE using tunnel label(s) Both LSPs combined to form single bi-directional Pseudo Wire Directed LDP session between PE routers to exchange VC information, such as VC label and control information

21 PW Encapsulation over MPLS (RFC 4448)
Ethernet Pseudo Wires use 3 layers of encapsulation Tunnel Encapsulation (zero, one or more MPLS Labels) To get PDU from ingress to egress PE; Could be an MPLS label (LDP, TE), GRE tunnel, L2TP tunnel Pseudo Wire Demultiplexer (PW Label) To identify individual circuits within a tunnel; Obtained from Directed LDP session Control Word (Optional) The following is supported when carrying Ethernet Provides the ability to sequence individual frames Avoidance of equal-cost multiple-path load-balancing Operations and Management (OAM) mechanisms Control word format varies depending on transported PDU Cisco implementation allows only 1 key per GRE tunnel – GRE code would need to be enhanced to provide multiple keys per GRE tunnel to allow for demultiplexer field implementation. Layer 2 PDU Control Word PW Label Tunnel Label

22 Ethernet PW Tunnel Encapsulation
Tunnel Encaps Tunnel Label (LDP,RSVP,BGP) EXP TTL PW Demux VC Label (VC) EXP 1 TTL (set to 2) Control Word Reserved Sequence Number Layer-2 PDU Tunnel Encapsulation One or more MPLS labels associated with the tunnel Defines the LSP from ingress to egress PE router Can be derived from LDP+IGP, RSVP-TE, BGP IPv4+Label

23 Ethernet PW Demultiplexer
Tunnel Encaps Tunnel Label (LDP,RSVP,BGP) EXP TTL PW Demux VC Label (VC) EXP 1 TTL (set to 2) Control Word Reserved Sequence Number Layer-2 PDU VC Label Inner label used by receiving PE to determine the following Egress interface for L2PDU forwarding (Port based) Egress VLAN used on the CE facing interface (VLAN Based) EXP can be set to the values received in the L2 frame If using LDP, liberal retention mode should be used but conservative label retention must be implemented

24 Ethernet PW Control Word
Tunnel Encaps Tunnel Label (LDP,RSVP,BGP) EXP TTL PW Demux VC Label (VC) EXP 1 TTL (set to 2) Control Word Reserved Sequence Number Layer-2 PDU Control Word is Optional (as per RFC) First nibble is 0x0 to prevent aliasing with IP Packets over MPLS (MAC addresses that start with 0x4 or 0x6) Reserved Should be all zeros, ignored on receive Seq number provides sequencing capability to detect out of order packets - currently not in Cisco’s implementation – processing is optional

25 PW Operation and Encapsulation
Label 72 for PW1 Directed LDP Session between PE1 and PE2 LSP Lo0: IP/MPLS “PW1” 24 72 L2 PDU 38 72 L2 PDU 72 L2 PDU P1 P2 CE PE1 Label Pop for Lo0: Label 38 for Lo0: Label 24 for Lo0: PE2 Customer Site Customer Site CE A PWES is either: - an Ethernet link or a VLAN link between two ports, or - an ATM VC or VP, or - a Frame Relay VC, or - a TDM circuit, or - an MPLS LSP Note that the PSN tunnel may be MPLS, L2TP, GRE and so on .. UTI is another mechanism to transport the PDUs between ingress and egress PE – in this case the PW is created using a UTI tunnel. LDP Session LDP Session LDP Session This process happens in both directions (Example shows process for PE2  PE1 traffic)

26 VPLS Architecture

27 VPLS Standards Architecture allows IEEE bridge behaviour in SP plus: Autodiscovery of other N-PE in same VPLS instance Signaling of PWs to interconnect VPLS instances Loop avoidance & MAC Address withdrawal Two drafts have been approved by IETF L2VPN Working Group draft-ietf-l2vpn-vpls-ldp Uses LDP for signalling, agnostic on PE discovery method Predominant support from carriers and vendors Cisco supports this draft draft-ietf-l2vpn-vpls-bgp Uses BGP for signalling and autodiscovery

28 Cisco VPLS Building Blocks
NMS/OSS Point-to-Point Layer 2 VPN Layer 2 VPN Multipoint Layer 2 VPN Layer 3 VPN Forwarding Mechanism Interface-Based/ Sub-Interface Ethernet Switching (VFI) IP Routing L2VPN Discovery Centralised DNS Radius Directory Services Distributed BGP Label Distribution Protocol Signaling Tunnel Protocol MPLS IP Hardware Cisco 7600 Catalyst 6500 Cisco 12000

29 VPLS Auto-discovery & Signaling
VPN Discovery Centralised DNS Radius Directory Services Distributed BGP Signaling Label Distribution Protocol Draft-ietf-l2vpn-vpls-ldp Does not mandate an auto-discovery protocol Can be BGP, Radius, DNS, or Directory based Uses Directed LDP for label exchange (VC) and PW signaling PWs signal control information as well (for example, circuit state) Cisco IOS supports Directed LDP for all VC signaling Point-to-point – Cisco IOS Any Transport over MPLS (AToM) Multipoint – Cisco IOS MPLS Virtual Private LAN Services

30 VPLS Flooding & Forwarding
Unknown DA? Pseudo Wire in LSP Data SA DA? Flooding (Broadcast, Multicast, Unknown Unicast) Dynamic learning of MAC addresses on PHY and VCs Forwarding Physical Port Virtual Circuit Frame Forwarding Requirements -         MAC address to VC-LSP association is required -         Dynamically learn MAC addresses on PHY ports and VCs -         Forward

31 MAC Address Learning and Forwarding
Send me frames using Label 102 Send me frames using Label 170 Directed LDP MAC1 MAC2 PE1 PE2 CE Use VC Label 102 CE E0/0 Use VC Label 170 E0/1 MAC Address Adj MAC Address Adj MAC MAC 2 E0/1 PE2 102 MAC1 MAC2 Data MAC 1 E0/0 MAC PE2 170 MAC2 MAC1 Data Broadcast, Multicast, and Unknown Unicast are learned via the received label associations Two LSPs associated with a VC (Tx & Rx) If inbound or outbound LSP is down Then the entire Pseudo Wire is considered down Assume a packet from A1 is bound for A2. When it leaves CE1, say it has a source MAC address of M1 and a destination MAC of M2. If PE1 does not know where M2 is, it will multicast the packet to PE2 and PE3. When PE2 receives the packet, it will have an inner label of 201. PE2 can conclude that the source MAC address M1 is behind PE1, since it distributed the label 201 to PE1. It can therefore associate MAC address M1 with VC Label 102.

32 MAC Address Withdrawal Message
Directed LDP MAC Withdrawal MPLS X MAC Withdrawal Message speeds up convergence process Otherwise PE relies on MAC Address Aging Timer Upon failure PE removes locally learned MAC addresses Send LDP Address Withdraw (RFC3036) to remote PEs in VPLS (using the Directed LDP session) New MAC List TLV is used to withdraw addresses The processing for MAC TLVs received in an Address Withdraw Message is: For each MAC address in the TLV: - Relearn the association between the MAC address and the interface/Pseudo Wire over which this message is received - Send the same message to all other PEs over the corresponding directed LDP sessions. For an Address Withdraw message with empty list: - Remove all the MAC addresses associated with the VPLS instance (specified by the FEC TLV) except the MAC addresses learned

33 VPLS Topology – PE View CEs MPLS PEs Full Mesh LDP Ethernet PW to each peer PE view Each PE has a P2MP view of all other PEs it sees it self as a root bridge with split horizon loop protection Full mesh topology obviates STP in the SP network Customer STP is transparent to the SP / Customer BPDUs are forwarded transparently

34 VPLS Topology – CE View CE routers/switches see a logical Bridge/LAN
MPLS VPLS Core MPLS CEs MPLS PEs CEs PE view Full Mesh LDP Ethernet PW to each peer CE routers/switches see a logical Bridge/LAN VPLS emulates a LAN – but not exactly… This raises a few issues which are discussed later

35 VPLS Architectures VPLS defines two Architectures
Direct Attachment (Flat) Described in section 4 of Draft-ietf-l2vpn-vpls-ldp Hierarchical or H-VPLS comprising of two access methods Ethernet Edge (EE-H-VPLS) – QinQ tunnels MPLS Edge (ME-H-VPLS) - PWE3 Pseudo Wires (EoMPLS) Described in section 10 of Draft-ietf-l2vpn-vpls-ldp Each architecture has different scaling characteristics

36 VPLS Functional Components
Customer MxUs Customer MxUs SP PoPs CE U-PE N-PE MPLS Core N-PE U-PE CE N-PE provides VPLS termination/L3 services U-PE provides customer UNI CE is the custome device

37 Directed attachment (Flat) Characteristics
Suitable for simple/small implementations Full mesh of directed LDP sessions required N*(N-1)/2 Pseudo Wires required Scalability issue a number of PE routers grows No hierarchical scalability VLAN and Port level support (no QinQ) Potential signaling and packet replication overhead Large amount of multicast replication over same physical CPU overhead for replication

38 Direct Attachment VPLS (Flat Architecture)
CE N-PE MPLS Core N-PE CE Ethernet (VLAN/Port Ethernet (VLAN Port) Full Mesh PWs + LDP MAC2 MAC1 Data 802.1q Customer MAC2 MAC1 Data PE VC MAC2 MAC1 Data Pseudo Wire SP Core

39 Hierarchical VPLS (H-VPLS)
Best for larger scale deployment Reduction in packet replication and signaling overhead Consists of two levels in a Hub and Spoke topology Hub consists of full mesh VPLS Pseudo Wires in MPLS core Spokes consist of L2/L3 tunnels connecting to VPLS (Hub) PEs Q-in-Q (L2), MPLS (L3), L2TPv3 (L3) Some additional H-VPLS terms MTU-s Multi-Tenant Unit Switch capable of bridging (U-PE) PE-r Non bridging PE router PE-rs Bridging and Routing capable PE

40 Why H-VPLS? VPLS H-VPLS Potential signaling overhead
PE CE CE CE PE-rs MTU-s PE PE CE CE CE PE PE PE-rs PE-rs CE CE PE PE PE-rs PE-r PE-rs PE-rs CE CE CE PE CE Potential signaling overhead Full PW mesh from the Edge Packet replication done at the Edge Node Discovery and Provisioning extends end to end Minimizes signaling overhead Full PW mesh among Core devices Packet replication done the Core Partitions Node Discovery process

41 Ethernet Edge H-VPLS (EE-H-VPLS)
U-PE MTU-s N-PE PE-rs N-PE PE-rs U-PE MTU-s CE MPLS Core CE 1 2 3 802.1q Access QinQ Tunnel QinQ Tunnel 802.1q Access Full Mesh PWs + LDP 1 MAC2 MAC1 Data Vlan CE 802.1q Customer QinQ SP Edge 2 MAC2 MAC1 Data Vlan CE Vlan SP 3 Data Vlan CE MAC1 MAC2 VC PE Pseudo Wire SP Core

42 Bridge Capability in EE-H-VPLS
U-PE MTU-s N-PE PE-rs CE Local edge traffic does not have to traverse N-PE MTU-s can switch traffic locally Saves bandwidth capacity on circuits to N-PE

43 Ethernet Edge Topologies
Full Service CPE Efficient Access U-PE Large Scale Aggregation PE-AGG Intelligent Edge N-PE Multiservice Core P Intelligent Edge N-PE Efficient Access U-PE Full Service CPE User Facing Provider Edge (U-PE) Metro C Metro A U-PE PE-AGG Hub and Spoke 10/100/ 1000 Mbps 10/100/ 1000 Mbps GE Ring P P U-PE N-PE Note that in many cases, any given Metro Ethernet solution may not contain all of these layers. In fact, in some cases the architectural functions can be merged into a single layer. For example, various combinations of network technologies and topologies can be formed to deliver Ethernet services without passing through a core network. In this context, these network technology and topology combinations can be viewed as separate from the inter-connecting core network, and are hence referred to as Metro Ethernet islands (or simply islands). MPLS VPLS Metro B 10/100/ 1000 Mbps N-PE P P DWDM/ CDWM RPR N-PE U-PE 10/100/ 1000 Mbps Network Facing Provider Edge (N-PE) U-PE Metro D

44 Same VCID used in Edge and core (Labels may differ)
MPLS Edge H-VPLS U-PE PE-rs N-PE PE-rs N-PE PE-rs U-PE PE-rs CE MPLS Core CE MPLS Core MPLS Access MPLS Access 1 2 MPLS Pseudo Wire 3 802.1q Access MPLS Pseudo Wire 802.1q Access Full Mesh PWs + LDP Same VCID used in Edge and core (Labels may differ) 1 MAC2 MAC1 Data Vlan CE 802.1q Customer 2 Data Vlan CE MAC1 MAC2 VC PE MPLS PW SP Edge 3 Data Vlan CE MAC1 MAC2 VC PE Pseudo Wire SP Core

45 VFI and Split Horizon (VPLS, EE-H-VPLS)
This traffic will not be replicated out PW #2 and visa versa Pseudo Wire #1 CE 1 1 N-PE2 VFI 3 Pseudo Wire #2 1 2 3 CE 2 3 2 3 N-PE3 Broadcast /Multicast 3 N-PE1 Virtual Forwarding Interface Bridging Function (.1Q or QinQ) Pseudo Wires Local Switching Split Horizon Active Virtual Forwarding Interface is the VSI representation in IOS Single interface terminates all PWs for that VPLS instance This model applicable in direct attach and H-VPLS with Ethernet Edge

46 VFI and NO Split Horizon (ME-H-VPLS)
Pseudo Wire #1 Pseudo Wire #3 CE N-PE1 Split Horizon disabled 1 VFI Pseudo Wire #2 N-PE2 U-PE 1 2 3 CE 3 2 Unicast N-PE3 Virtual Forwarding Interface Pseudo Wire MPLS Based Pseudo Wires NO Split Horizon Split Horizon Active This model applicable H-VPLS with MPLS Edge PW #1, PW #2 will forward traffic to PW #3 (non split horizon port)

47 VPLS Logical Topology Comparison
Direct Attach H-VPLS – QinQ tunnel H-VPLS - MPLS PW Pros Simple access via Ethernet Hierarchical support via QinQ at access Scalable customer VLANs (4K x 4K) 4K customers supported per Ethernet Access Domain Fast L3 IGP convergence MPLS TE FRR <50msec Hierarchical support via MPLS PW at access Cons No hierarchical scalability Customer VLAN cannot over lap 4K customer VLAN limit in Ethernet access domain High STP reconvergence time High STP re-convergence time MAC is not scalable as customer MAC still seen on SP network Supported on SIP-600 only as of 12.2(33)SRA More complicated provisioning Requires MPLS to u-PE OSM/SIP-400/600 as U-PE facing card on N-PE (for 7600)

48 Configuration Examples

49 Configuration Examples
Direct Attachment Using a Router as a CE (VLAN Based) Using a Switch as a CE (Port Based) H-VPLS Ethernet QinQ EoMPLS Pseudo Wire (VLAN Based) EoMPLS Pseudo Wire (Port Based) Sample Output

50 Direct Attachment Configuration (C7600)
MPLS Core PE1 PE2 CE1 CE2 pos4/1 pos4/3 gi3/0 gi4/4 VLAN100 pos3/0 pos3/1 VLAN100 PE3 gi4/2 CE2 VLAN100 CEs are all part of same VPLS instance (VCID = 56) CE router connects using VLAN 100 over sub-interface

51 Direct Attachment CE router Configuration
interface GigabitEthernet 2/ encapsulation dot1q ip address interface GigabitEthernet 1/ encapsulation dot1q ip address CE1 CE2 Subnet /24 VLAN100 VLAN100 interface GigabitEthernet 2/ encapsulation dot1q ip address CE2 VLAN100 CE routers sub-interface on same VLAN Can also be just port based (NO VLAN)

52 Direct Attachment VSI Configuration
l2 vfi VPLS-A manual vpn id 56 neighbor encapsulation mpls neighbor encapsulation mpls l2 vfi VPLS-A manual vpn id 56 neighbor encapsulation mpls neighbor encapsulation mpls MPLS Core PE1 PE2 CE1 CE2 pos4/1 pos4/3 gi3/0 gi4/4 VLAN100 pos3/0 pos3/1 VLAN100 PE3 gi4/2 CE2 VLAN100 l2 vfi VPLS-A manual vpn id 56 neighbor encapsulation mpls neighbor encapsulation mpls Create the Pseudo Wires between N-PE routers

53 Direct Attachment CE Router (VLAN Based)
Same set of commands on each PE Configured on the CE facing interface MPLS Core PE1 PE2 CE1 CE2 pos4/1 pos4/3 gi3/0 gi4/4 VLAN100 Interface GigabitEthernet3/0 switchport switchport mode trunk switchport trunk encapsulation dot1q switchport trunk allowed vlan 100 ! Interface vlan no ip address xconnect vfi VPLS-A ! vlan state active pos3/0 pos3/1 VLAN100 PE3 gi4/2 CE2 VLAN100 This command associates the VLAN with the VPLS instance VLAN100 = VCID 56

54 Configuration Examples
Direct Attachment Using a Router as a CE (VLAN Based) Using a Switch as a CE (Port Based) H-VPLS Ethernet QinQ EoMPLS Pseudo Wire (VLAN Based) EoMPLS Pseudo Wire (Port Based) Sample Output

55 Direct Attachment CE switch (Port Based)
If CE was a switch instead of a router then we can use QinQ QinQ places all traffic (tagged/untagged) from switch into a VPLS MPLS Core PE1 PE2 CE1 CE2 pos4/1 pos4/3 gi3/0 gi4/4 All VLANs Interface GigabitEthernet3/0 switchport switchport mode dot1qtunnel switchport access vlan l2protocol-tunnel stp ! Interface vlan no ip address xconnect vfi VPLS-A ! vlan state active pos3/0 pos3/1 All VLANs PE3 gi4/2 CE2 All VLANs This command associates the VLAN with the VPLS instance VLAN100 = VCID 56

56 Configuration Examples
Direct Attachment Using a Router as a CE (VLAN Based) Using a Switch as a CE (Port Based) H-VPLS Ethernet QinQ EoMPLS Pseudo Wire (VLAN Based) EoMPLS Pseudo Wire (Port Based) Sample Output

57 H-VPLS Configuration (C7600/3750ME)
U-PE1 Cisco 3750ME U-PE2 Cisco 3750ME MPLS Core pos4/1 pos4/3 fa1/0/1 gi3/0 gi4/4 gi1/1/1 N-PE1 pos3/0 pos3/1 N-PE2 CE1 N-PE3 CE1 CE2 CE2 gi4/2 CE2 U-PE3 Cisco 3750ME CE1 U-PEs provide services to customer edge device CE traffic then carried in QinQ or EoMPLS PW to N-PE PW VSI mesh configuration is same as previous examples

58 Configuration Examples
Direct Attachment Using a Router as a CE (VLAN Based) Using a Switch as a CE (Port Based) H-VPLS Ethernet QinQ EoMPLS Pseudo Wire (VLAN Based) EoMPLS Pseudo Wire (Port Based) Sample Output

59 H-VPLS QinQ Tunnel (Ethernet Edge)
U-PE carries all traffic from CE using QinQ Outer tag is VLAN100, inner tags are customer’s U-PE1 Cisco 3750ME U-PE2 Cisco 3750ME MPLS Core pos4/1 pos4/3 fa1/0/1 gi3/0 gi4/4 gi1/1/1 Interface GigabitEthernet4/4 switchport switchport mode trunk switchport trunk encapsulation dot1q switchport trunk allowed vlan 100 ! Interface vlan no ip address xconnect vfi VPLS-A ! vlan state active N-PE1 pos3/0 pos3/1 N-PE2 CE1 N-PE3 CE1 CE2 CE2 interface FastEthernet1/0/1 switchport switchport access vlan 100 switchport mode dot1q-tunnel switchport trunk allow vlan ! interface GigabitEthernet 1/1/1 switchport switchport mode trunk switchport allow vlan HVPLS with L2 Handoff (QinQ) H-VPLS with QinQ attachment circuit is the simplest of all configurations. This handoff does not require MPLS to the edge. It only requires a physical link that is configured as a 802.1Q trunk or a QinQ access port. gi4/2 CE2 U-PE3 Cisco 3750ME CE1

60 Configuration Examples
Direct Attachment Using a Router as a CE (VLAN Based) Using a Switch as a CE (Port Based) H-VPLS Ethernet QinQ EoMPLS Pseudo Wire (VLAN Based) EoMPLS Pseudo Wire (Port Based) Sample Output

61 H-VPLS EoMPLS PW Edge (VLAN Based)
CE interface on U-PE can be access or trunk port xconnect per VLAN is required U-PE1 Cisco 3750ME U-PE2 Cisco 3750ME MPLS Core pos4/1 pos4/3 fa1/0/1 gi3/0 gi4/4 gi1/1/1 Interface GigabitEthernet4/4 no switchport ip address mpls ip ! l2 vfi VPLS-A manual vpn id 56 neighbor encapsulation mpls neighbor encapsulation mpls neighbor encaps mpls no-split N-PE1 pos3/0 pos3/1 N-PE2 CE1 N-PE3 CE1 CE2 interface FastEthernet1/0/1 switchport switchport access vlan 500 ! interface vlan500 xconnect encapsulation mpls ! interface GigabitEthernet1/1/1 no switchport ip address mpls ip CE2 HVPLS with MPLS edge VC type 4 When configuring HVPLS with MPLS edge the U-PE is simply a Vlan-Based EoMPLS Tunnel (VC Type 4). The Tunnel xconnect is configured on the VLAN interface which allows all traffic from that VLAN to pass into the VPLS Core. If the UNI is configured as a trunk port, a xconnect per VLAN allowed on the trunk will be required to pass the customer traffic. gi4/2 CE2 U-PE3 Cisco 3750ME CE1 Ensures CE traffic passed on PW to/from U-PE

62 Configuration Examples
Direct Attachment Using a Router as a CE (VLAN Based) Using a Switch as a CE (Port Based) H-VPLS Ethernet QinQ EoMPLS Pseudo Wire (VLAN Based) EoMPLS Pseudo Wire (Port Based) Sample Output

63 H-VPLS EoMPLS PW Edge (Port Based)
CE interface on U-PE can be access or trunk port xconnect for entire PORT is required U-PE1 Cisco 3750ME U-PE2 Cisco 3750ME MPLS Core pos4/1 pos4/3 fa1/0/1 gi3/0 gi4/4 gi1/1/1 Interface GigabitEthernet4/4 no switchport ip address mpls ip ! l2 vfi PE1-VPLS-A manual vpn id 56 neighbor encapsulation mpls neighbor encapsulation mpls neighbor encaps mpls no-split N-PE1 pos3/0 pos3/1 N-PE2 CE1 N-PE3 CE1 CE2 interface FastEthernet1/0/1 no switchport xconnect encapsulation mpls ! interface GigabitEthernet1/1/1 no switchport ip address mpls ip CE2 HVPLS with MPLS edge VC type 4 When configuring HVPLS with MPLS edge the U-PE is simply a Vlan-Based EoMPLS Tunnel (VC Type 4). The Tunnel xconnect is configured on the VLAN interface which allows all traffic from that VLAN to pass into the VPLS Core. If the UNI is configured as a trunk port, a xconnect per VLAN allowed on the trunk will be required to pass the customer traffic. gi4/2 CE2 U-PE3 Cisco 3750ME CE1 Ensures CE traffic passed on PW to/from U-PE

64 Configuration Examples
Direct Attachment Using a Router as a CE (VLAN Based) Using a Switch as a CE (Port Based) H-VPLS Ethernet QinQ EoMPLS Pseudo Wire (VLAN Based) EoMPLS Pseudo Wire (Port Based) Sample Output

65 show mpls l2 vc U-PE1 Cisco 3750ME U-PE2 Cisco 3750ME MPLS Core N-PE1
MPLS Core pos4/1 pos4/3 fa1/0/1 gi3/0 gi4/4 gi1/1/1 N-PE1 pos3/0 pos3/1 N-PE2 CE1 N-PE3 CE1 CE2 CE2 HVPLS with MPLS edge VC type 4 When configuring HVPLS with MPLS edge the U-PE is simply a Vlan-Based EoMPLS Tunnel (VC Type 4). The Tunnel xconnect is configured on the VLAN interface which allows all traffic from that VLAN to pass into the VPLS Core. If the UNI is configured as a trunk port, a xconnect per VLAN allowed on the trunk will be required to pass the customer traffic. gi4/2 CE2 U-PE3 Cisco 3750ME NPE-A#show mpls l2 vc Local intf Local circuit Dest address VC ID Status VFI VPLS-A VFI UP VFI VPLS-A VFI UP CE1

66 show mpls l2 vc detail U-PE1 Cisco 3750ME U-PE2 Cisco 3750ME MPLS Core
MPLS Core Use VC Label 19 Use VC Label 23 pos4/1 pos4/3 fa1/0/1 gi3/0 gi4/4 gi1/1/1 N-PE1 pos3/0 pos3/1 N-PE2 CE1 N-PE3 CE1 CE2 NPE-2#show mpls l2 vc detail Local interface: VFI VPLS-A up Destination address: , VC ID: 10, VC status: up Tunnel label: imp-null, next hop Output interface: POS4/3, imposed label stack {19} Create time: 1d01h, last status change time: 00:40:16 Signaling protocol: LDP, peer :0 up MPLS VC labels: local 23, remote 19 CE2 HVPLS with MPLS edge VC type 4 When configuring HVPLS with MPLS edge the U-PE is simply a Vlan-Based EoMPLS Tunnel (VC Type 4). The Tunnel xconnect is configured on the VLAN interface which allows all traffic from that VLAN to pass into the VPLS Core. If the UNI is configured as a trunk port, a xconnect per VLAN allowed on the trunk will be required to pass the customer traffic. gi4/2 CE2 U-PE3 Cisco 3750ME CE1

67 Deployment Issues

68 Deployment Issues MTU Size Broadcast Handling Router or a Switch CPE?
Ramblings of an Engineer A Sample Problem

69 Pseudo Wire Data Plane Overhead
At imposition, N-PE encapsulates CE Ethernet or VLAN packet to route across MPLS cloud These are the associated overheads Transport Header is 6 bytes DA + 6 bytes SA + 2 bytes Etype + OPTIONAL 4 Bytes of VLAN Tag (carried in Port based service) At least 2 levels of MPLS header (Tunnel + VC) of 4 bytes each There is an optional 4-Byte control word Here is example basic Ethernet over MPLS Data plane overhead PE Encapsulate CE ethernet or vlan before it ships to MPLS core This is very important to understand overhead of EoMPLS before you provision your core to support EoMPLS. Transport header is 6 bytes Distanation address + 6 bytes for source address + 2 bytes for ethertype + optional 4 bytes for VLAN tag which gives up 18 bytes if we use dot1q tag. This if you core base of Ethernet and Gigabit recommended to modify your core to lest 1518 There least 2 level of MPLS header Tunnel label and VC lablel each of them 4 bytes which add another 8 bytes In next slide we going to show more detail brake down regards mtu calculation L2 Header Tunnel Header VC Header Original Ethernet Frame Outer Label (32-bits) Inner Label (32-bits)

70 Calculating Core MTU Requirements
Core MTU ≥ Edge MTU + Transport Header + AToM Header + (MPLS Label Stack * MPLS Header Size) Edge MTU is the MTU configured in the CE-facing PE interface Examples (all in Bytes): 1530 [1526] 1526 [1522] Total 4 3 1500 EoMPLS Port w/ TE FRR 2 EoMPLS VLAN Mode EoMPLS Port Mode MPLS Header MPLS Stack Edge 14 18 Transport 4 [0] AToM EoMPLS port mode default 1500 and transport is 14 which include DA and SA 12 bytes + 2 bytes for etype Control Word for 2 labels And everything else is kind explainable, once again make sure you know how to calculate your mtu before provision your core. Specially when you provision your core to support Interworking

71 Beware the MTU – It Can Get Real Big
Carrier Pseudowire Encapsulation Enterprise MPLS Frame 7 1 6 6 2 4 4 4 4 6 6 2 2 2 > 1500 4 Pre SFD DA SA Type TE Tu Vc Cntrl DA SA TPID TCI Type Data FCS Preamble Carrier Dest MAC Cust Type Start of Frame Delimter Carrier Source MAC Control Word VLAN ID Info Cust Packet Ether type = 8847 EoMPLS VC Label Cust Source MAC Traffic Engineer label EoMPLS Tunnel Label Cust Destination MAC VLAN Protocol ID = 8100 Frame Check Sequence MTU Sizing Packet size can get very large in backhaul due to multiple tags and labels Ensure core and access Ethernet interfaces are configured with appropriate MTU size Assume you are running MPLS VPN with Backbone Ethernet links with TE and FRR – 4 labels. Now your SP providing pseudowire over metro ethernet…. using ERS. That means there is a vlan tag on your traffic that is carried into their network… another 4 bytes. Then they may be using FRR and TE and Q-in-Q another 12 bytes… Data portion may be > 1500 if carrying MPLS labels

72 Broadcast/Multicast/Unknown Unicast Handling
VPLS relies on ingress replication Ingress PE replicates the multicast packet to each egress Pseudo Wire (PE neighbour) Ethernet switches replicate broadcast/multicast flows once per output interface VPLS may duplicate packets over the same physical egress interface – for each PW that interface carriers Unnecessary replication brings the risk of resource exhaustion when the number of PWs increases Some discussion on maybe using multicast for PWs Rather than full mesh of P2P Pseudo Wires

73 Switch or Router as CE device
Ethernet Switch as CE device If directly attached SP allocates VLAN could be an issue in customer network SP UNI exposed to L2 network of customer L2 PDUs must be tunnelled such as STP BPDUs No visibility of network behind CE switch Many MAC address can exists on UNI High exposure to broadcast storms Router as CE device Single MAC Address exists (for interface of router) No SPT interactions Router controls broadcast issues (multicast still happens)

74 VPLS Caveats (Ramblings of an Engineer)
VPLS may introduce non-deterministic behaviour in SP Core Case in point – learning of VPN routes An MPLS-VPN provides ordered manner to learn VPNv4 routers using MP-BGP – unknown addresses are dropped In VPLS, learning is achieved through flooding MAC address Excessive number of Unknown, Broadcast and Multicast frames could behave as a series of “packet bombs” Solution: Ingress Threshold Filters (on U-PE or N-PE) How to selectively choose which Ethernet Frames to discard? How to avoid dropping Routing and Keepalives (control) May cause more problems in customer network… How many MAC addresses allowed? Does SP really want to take this responsibility? As simple as a LAN appears to be in that it is essentially plug and play, from a Service Providers view it introduces an element of non-deterministic behaviour into the MPLS core. For example, in an MPLS VPN environment, Multi-Protocol BGP (MP-BGP) is used to advertise VPNv4 prefixes between PE routers. These prefixes have been learnt in an ordered manner by static or dynamic routing protocols from the CE routers. Therefore it is reasonable to assume that when an IP packet arrives on an ingress PE router interface, the IP destination of that packet will be known the to PE router as it was previously learnt from MP-BGP. The packet will then be forwarded to the correct egress PE router on the MPLS network. If the IP destination is not known to the PE router (that is, it does not exists in the VRF), then the packet will be dropped. In a VPLS service, forwarding based on MAC addresses. All PE routers participating in the VPLS service must have a full mesh of label switch paths (LSP) between them (basically a series of pipes). The reachability of a particular destination is determined by the presence of MAC address in the MAC cache. There is a correlation between the MAC address and the LSP that address is reached on. With VPLS, if an Ethernet frame arrives on an ingress PE router with an unknown MAC destination address (it is not present in the cache), then than frame must be flooded out every LSP to the other PE routers. This is also the mandatory behaviour for all broadcast and multicast Ethernet frames. Therefore an excessive number of Unknown, Broadcast and Multicast frames could behave as a series of “packet bombs” in the MPLS core which could affect other VPNs. The assumption is made here that the customer is using a switch as the CPE (how do you control what type of device they connect) To combat this, threshold filters could be placed on the ingress PE interfaces, to limit the numbers of these types of packets entering the MPLS core. If frames were indiscriminately dropped, it could have an affect on customer traffic, particular control plane traffic such as routing updates or keepalives. This in turn could introduce further problems up the protocol stack. Therefore, it may be necessary to selectively discard traffic so as to avoid dropping bonafide multicast and broadcast traffic. How is this decision made? What thresholds are reasonable? Deep packet inspection would most likely be necessary. This increases the operational complexity of such a service. A Denial of Service attack, whether it is intentional or by customer misconfiguration, would have a higher probability of manifesting itself. Since traffic is carried at layer 2, there is a lot of chatter that could be traversing the MPLS core unnecessarily. This could include many unknown protocols, such as status requests for printers or NETBEUI type traffic that would normally be stopped at the router. The number of MAC address introduced into the PE router would have to be monitored and controlled. How is CoS applied across an MPLS core for a VPLS service? Many protocols make use of the 802.1p bits to propagate CoS from the IP Precedence into the Ethernet frame. How do those protocols that for some reason, possibly legacy applications, do not use 802.1p? How should they be treated in the MPLS core? Should all frames on a VPLS interface be afforded the same class of service? The provision of redundant access circuits for VPLS is an added complexity from an operational perspective. Good network design states that a layer 2 domain should be as small as possible. The IP MAN has reasonably large domains, but the issues are well known and steps are being taken to reduce the layer 2 domain size. VPLS increases the domain size to possibly a national network by allowing a customer to join all its layer 2 domains. To combat these issues and the reduce the operational complexities, if a VPLS service was to be offered, then part of the service description would be that the CPE must be a router. This would address the broadcast and MAC address type problems. However, although VPLS could be viewed as an Ethernet switch network, it does not necessarily behave like one.

75 VPLS Caveats (Ramblings of an Engineer)
DoS attack has a higher probability of manifesting Whether intentional or by mis-configuration Since traffic is carried at layer 2, a lot of chatter could be traversing the MPLS core unnecessarily. For example, status requests for printers How is CoS applied across for a VPLS service? Should all frames on a VPLS interface be afforded the same class of service? Should there be some sort of differentiation? As simple as a LAN appears to be in that it is essentially plug and play, from a Service Providers view it introduces an element of non-deterministic behaviour into the MPLS core. For example, in an MPLS VPN environment, Multi-Protocol BGP (MP-BGP) is used to advertise VPNv4 prefixes between PE routers. These prefixes have been learnt in an ordered manner by static or dynamic routing protocols from the CE routers. Therefore it is reasonable to assume that when an IP packet arrives on an ingress PE router interface, the IP destination of that packet will be known the to PE router as it was previously learnt from MP-BGP. The packet will then be forwarded to the correct egress PE router on the MPLS network. If the IP destination is not known to the PE router (that is, it does not exists in the VRF), then the packet will be dropped. In a VPLS service, forwarding based on MAC addresses. All PE routers participating in the VPLS service must have a full mesh of label switch paths (LSP) between them (basically a series of pipes). The reachability of a particular destination is determined by the presence of MAC address in the MAC cache. There is a correlation between the MAC address and the LSP that address is reached on. With VPLS, if an Ethernet frame arrives on an ingress PE router with an unknown MAC destination address (it is not present in the cache), then than frame must be flooded out every LSP to the other PE routers. This is also the mandatory behaviour for all broadcast and multicast Ethernet frames. Therefore an excessive number of Unknown, Broadcast and Multicast frames could behave as a series of “packet bombs” in the MPLS core which could affect other VPNs. The assumption is made here that the customer is using a switch as the CPE (how do you control what type of device they connect) To combat this, threshold filters could be placed on the ingress PE interfaces, to limit the numbers of these types of packets entering the MPLS core. If frames were indiscriminately dropped, it could have an affect on customer traffic, particular control plane traffic such as routing updates or keepalives. This in turn could introduce further problems up the protocol stack. Therefore, it may be necessary to selectively discard traffic so as to avoid dropping bonafide multicast and broadcast traffic. How is this decision made? What thresholds are reasonable? Deep packet inspection would most likely be necessary. This increases the operational complexity of such a service. A Denial of Service attack, whether it is intentional or by customer misconfiguration, would have a higher probability of manifesting itself. Since traffic is carried at layer 2, there is a lot of chatter that could be traversing the MPLS core unnecessarily. This could include many unknown protocols, such as status requests for printers or NETBEUI type traffic that would normally be stopped at the router. The number of MAC address introduced into the PE router would have to be monitored and controlled. How is CoS applied across an MPLS core for a VPLS service? Many protocols make use of the 802.1p bits to propagate CoS from the IP Precedence into the Ethernet frame. How do those protocols that for some reason, possibly legacy applications, do not use 802.1p? How should they be treated in the MPLS core? Should all frames on a VPLS interface be afforded the same class of service? The provision of redundant access circuits for VPLS is an added complexity from an operational perspective. Good network design states that a layer 2 domain should be as small as possible. The IP MAN has reasonably large domains, but the issues are well known and steps are being taken to reduce the layer 2 domain size. VPLS increases the domain size to possibly a national network by allowing a customer to join all its layer 2 domains. To combat these issues and the reduce the operational complexities, if a VPLS service was to be offered, then part of the service description would be that the CPE must be a router. This would address the broadcast and MAC address type problems. However, although VPLS could be viewed as an Ethernet switch network, it does not necessarily behave like one.

76 A Common VPLS Problem Protocols expect LAN behaviour
VPLS is viewed as an Ethernet network Although it does not necessarily behave like one VPLS is “virtual” in its LAN service There are some behaviours which differ from a real LAN An example The OSPF designated router problem…

77 OSPF Designated Router Problem
VPLS View Router A is the DR, Router B is the BDR Router C sees both A and B via Pseudo Wires OSPF DR (A) Pseudo Wires OSPF Backup DR (B) OSPF Neighbour (C) Router View Router A, B and C behave like they are on a LAN OSPF DR (A) OSPF Backup DR (B) OSPF Neighbour (C)

78 OSPF Designated Router Problem
Assume PW between A and B loses connectivity Router A and Router B cannot see each other Router C can still see both the Router A and Router B No arbitration available between Router A and Router B OSPF DR (A) Pseudo Wires OSPF Backup DR (B) OSPF Neighbour (C) Ethernet frames travel along discrete paths a VPLS Therefore Router C can see both Router A and B But Router A and Router B cannot see each other! Router B assumes A has failed and becomes the DR Router C now see two DRs on same LAN segment – Problem! Assume that the LSP between Router A and Router B fails. This poses an interesting situation for Router C. Since Ethernet frames travel down discrete paths in the MPLS core (over different LSPs), Router C can still see both Router A and Router B as active. However, Router A and Router B cannot see each either due to the LSP failure but can both see Router C. Therefore, Router B becomes the designated router for the LAN segment, even though Router A is still the designated router. Router C observed that there are now two designated routers on the LAN segment with no arbitration between them. This is an unusual situation which would not occur in a pure Ethernet switch network. If each router was connected to switch, rather than a VPLS service, then if the link between the Router A and Router B switches failed, spanning tree reroute the Ethernet frames over the A to C switch path.

79 Summary

80 Summary VPLS has its advantages and benefits
Non-IP protocols supported, customers do not have routing interaction etc.. Use routers as the CE device Understand their multicast requirements Then again, maybe MPLS-VPN could do the job? Avoid switches as CPE Otherwise understand customer’s network requirements Devices, applications (broadcast/multicast vs unicast)

81 Q & A

82


Download ppt "An Introduction to VPLS"

Similar presentations


Ads by Google