VPLS MPLS Assistance

Unanswered Question
Jun 14th, 2010

Hi Guys

I've trying to design an interesting VPLS network, Let me take you through my requirements which will help you to gain a better understanding.

I require:-

  • Eight Customer Sites
  • MPLS core P nodes (7600's which IOS do i need)
  • PE's on the edge (7600's which IOS do i need)
  • CE's Routers (2800's which IOS)

The design should be a complete layer 2 domain, as far as i can tell we need one entire bridge domain. What I will also need is some encryption in the core of my network, I was considering using GRE ontop of IPSEC. GRE will provide me with the ability to route my traffic through the core. We also need to bare in mind that we're going to need layer three connectivity in order to obtain GRE tunnel connectivity in my core.

I'm suspecting that we're going to need to deploy GRE tunnels between the P nodes because this is where I'll have layer three connectivity. Also within the core I'll be using OSPF to advertise the core links.

They'll be no routing protocols on the PE's as this will be a layer two domain.

Please can you provide some pointers with regards to whether deploying GRE ontop of IPSEC is the best method in terms of providing encryption in the core.

Please provide pointers on the above requirements.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (2 ratings)
Loading.
Carl Williams Tue, 06/15/2010 - 15:17

Ok I'll make this more simpler, can someone help me set up an VPLS network, from what i understand VPLS MPLS is a layer two version of MPLS VPN.

Simple enough but can some one advise on the type of hardware I'll need and also How this particulular technology works. I have an 8 site design deployment.

can someone provide some advice with regards to the router hardware IOS.

and some configurations examples. This is with regards to VPLS.

Chetan Kumar Ress Wed, 06/16/2010 - 10:38

Hi

VPLS Deployment Models

Compared to point-to-point Layer 2 VPNs, deploying multipoint Layer 2 VPNs that are built on the VPLS architecture is far more complicated. One of the reasons is that a point-to-point Layer 2 VPN resembles a traditional Frame Relay-or ATM-based network in areas such as topologies and forwarding characteristics. For this reason, it is natural to overlap a point-to-point Layer 2 VPN on top of the WAN-based core network.

LAN services, as the name suggests, are designed for networks that are confined to a local or metropolitan area. One fundamental assumption that many LAN services make is that plenty of cheap bandwidth is available in the local or metro-area network (MAN). Many LAN services also rely on broadcasting and flooding to function properly. Despite the phenomenal growth in building high-speed network infrastructures, WAN bandwidth has always been one of the most expensive pieces in the overall network cost. Without carefully engineered VPLS deployment, new VPLS services will not be the only ones to suffer. Broadcast storms seen in a LAN environment can propagate to the multiservice backbone and affect other non-VPLS services. This section examines a few deployment issues, with considerations to loop-free forwarding, broadcast traffic, and scalability.

Basic Topologic Models

In a given VPLS domain, virtual switches are interconnected by pseudowires. The topology formed by these pseudowires plays a critical role in loop-free forwarding and contributes to the overall scalability and performance. A VPLS domain can have the following forms:

  • Full mesh

  • Hub and spoke

  • Partial mesh

Full Mesh

The "Understanding VPLS Fundamentals" section briefly addressed the forwarding and signaling characteristics of a full-mesh VPLS topology, which is the most common deployment model today. In a full-mesh model, every virtual switch has exactly one pseudowire to every other virtual switch in the same VPLS domain. The loop-free forwarding is guaranteed by enabling Layer 2 split horizon on every pseudowire in this topology. Split horizon prevents packets that are received on one pseudowire from being sent to any other pseudowire. It applies to normal forwarding if the destination MAC address matches an entry in the forwarding table, and it also applies to flooding if the packet has an unknown unicast, multicast, or broadcast destination MAC address.

A full-mesh model provides loop-free full connectivity among all virtual switches. It also eliminates the need to run spanning-tree protocols over the backbone, which saves valuable WAN bandwidth. However, such benefits come at the cost of other network resources. Remember from the previous section that the number of signaling sessions and pseudowires grows exponentially when the number of PE routers and virtual switches increases. Supporting numerous signaling sessions and pseudowires requires more bandwidth for exchanging protocol messages and more processing power on PE routers for signaling and packet forwarding. The forwarding performance also degrades when flooding has been performed on a large number pseudowires.

Hub and Spoke

In a hub-and-spoke model, exactly one PE router that is acting as a hub connects all other PE routers that act as spokes in a given VPLS domain. The virtual switch on a spoke PE router has exactly one pseudowire connecting to the virtual switch on the hub PE router. No pseudowire interconnects the virtual switches on spoke PE routers. A hub-and-spoke topology by definition is loop-free, so it does not need to enable spanning-tree protocols or split horizon on pseudowires. To provide Layer 2 connectivity among the virtual switches on spoke PE routers, the hub PE router must turn off split horizon on the pseudowires. When split horizon is disabled, you can forward or flood packets among different pseudowires at the hub PE router.

The simplicity of a hub-and-spoke model makes it an attractive choice for small VPLS deployment. Realize, though, that the hub PE router is a single point of failure. Because all traffic has to go through the hub PE router, the router requires ample processing power to relay and flood packets across pseudowires.

Partial Mesh

The most flexible topologic model is partial mesh. To guarantee loop-free forwarding in an arbitrary partial-mesh model, you need to run spanning-tree protocols on pseudowires throughout the backbone. Spanning-tree protocols are typically chatty and take a considerable amount of expensive WAN bandwidth. In addition, deploying spanning-tree protocols in a large-scale network is always a great challenge. Network design considerations such as root bridge selection, redundancy, and load balancing are highly complex, which means they are more vulnerable to configuration and operation mistakes. Service providers typically do not deploy a partial-mesh model because they want to avoid running spanning-tree protocols in the core network.

Hierarchical VPLS

Aiming at having the benefits of both basic topologic models while mitigating their problems, a hybrid between the full-mesh and hub-and-spoke models is now available, known as hierarchical VPLS. A hierarchical VPLS consists of a top tier and a bottom tier. Depending on the type of network that is deployed at the bottom tier, hierarchical VPLS comes in two forms:

  • Hierarchical VPLS with MPLS access network

  • Hierarchical VPLS with QinQ access network

Hierarchical VPLS with MPLS Access Network

As shown in Figure 15-5, for a given VPLS domain, virtual switches in the top tier are fully meshed through pseudowires. Each virtual switch in the bottom tier has exactly one pseudowire that connects to a top-tier virtual switch, which is effectively a hub-and-spoke model. This form of hierarchical VPLS is known as hierarchical VPLS with MPLS access. PE routers in the top tier and bottom tier are also known as network-facing PE (N-PE) routers and user-facing PE (U-PE) routers, respectively. To ensure loop-free forwarding, an N-PE router must enable Layer 2 split horizon on all pseudowires that connect to other N-PE routers and disable split horizon on all pseudowires that connect to U-PE routers. On an N-PE router, packets are forwarded to other pseudowires only if they arrive on a pseudowire that connects a U-PE router. Packets that arrive on a pseudowire that connects an N-PE router can be forwarded to pseudowires that connect to U-PE routers only.


Hierarchical VPLS with QinQ Access Network

Hierarchical VPLS has an alternate form that uses Ethernet QinQ tunnels between U-PE and N-PE routers, as depicted in Figure 15-6. It is also known as hierarchical VPLS with QinQ access. Instead of a pseudowire, you can use an Ethernet QinQ tunnel between a U-PE router and an N-PE router. Despite the absence of pseudowires in the bottom tier, the overall bridging architecture is still based on two logically separated layers, where an N-PE router forwards packets to pseudowires that connect to other N-PE routers only if they arrive on QinQ tunnels that connect to U-PE routers. The hierarchical VPLS models significantly reduce the total number of signaling sessions and pseudowires; therefore, they improve network scalability and performance. The scalability benefit also surfaces when you add or relocate a PE router. If the object is an N-PE router, you need to reconfigure only other N-PE routers. If the object is a U-PE router, you need to reconfigure only the attached N-PE router.

Like point-to-point Layer 2 VPN architectures, you can deploy VPLS in an inter-autonomous system (AS) or multidomain environment using a hierarchical model. In their simplest form, the peering VPLS PE routers of different administrative domains operate in such a fashion that each PE router treats itself as an N-PE router, and treats the peering PE as a U-PE router in the hierarchical model.

VPLS Redundancy

In the hierarchical VPLS model, an N-PE router can still be a single point of failure for attached U-PE routers. To solve this problem, each U-PE can connect to multiple N-PE routers through redundant pseudowires or QinQ tunnels. This method for providing redundancy is also known as multihoming. In this case, Layer 2 split horizon alone is no longer sufficient for providing loop-free forwarding. You need to enable spanning-tree protocols between U-PE and N-PE routers.

In Metro Ethernet deployment, you can view each metro area as an island of which U-PE and N-PE routers are closely located and are connected through a LAN. You can view VPLS as a collection of islands interconnected by pseudowires. When you confine spanning-tree protocols within individual islands, each island becomes a separate spanning-tree domain of which the boundary stays within the LAN, and the core network does not suffer bridging protocolrelated problems such as bandwidth inefficiency, operation complexity, and other drawbacks.

When a U-PE router multihomes with N-PE routers, you must enable spanning-tree protocols on the U-PE router for all the pseudowires or QinQ tunnels that exist between the U-PE and N-PE routers. However, an N-PE router can choose whether to participate in spanning-tree protocols. If it does, it behaves like an Ethernet bridge that exchanges and processes BPDUs with U-PE and other N-PE routers of the same island. If it does not, it acts as an Ethernet hub that simply relays BPDUs without processing. In the next section, a case study shows how to achieve VPLS redundancy using multihoming.

Example PE Configuration

hostname XXX
!
mpls label protocol ldp
mpls ldp logging neighbor-changes
mpls ldp router-id Loopback0
!
l2 vfi l2vpn manual  --------> VFI Fro Customer 
 vpn id 1
 neighbor x.x.x.x encapsulation mpls -----> Need to Define Static neighbor ( Currently Auto Discovery will Support with BGP )
neighbor x.x.x.x encapsulation mpls neighbor x.x.x.x encapsulation mpls ! interface Loopback0 ip address x.x.x.x x.x.x.x -----> LoopBack Form Neighbor

interface POS3/1          ------> Connect to Core ip address x.x.x.x x.x.x.x
  mpls ip ! interface FastEthernet4/2  ------? Connected to Cutomer Port no ip address switchport switchport access vlan 2 switchport mode dot1q-tunnel ! interface Vlan2         ------> Cutomer L3 Vlan use xconnect no ip address xconnect vfi l2vpn

Regards

Chetan Kumar

Attachment: 
Carl Williams Wed, 06/16/2010 - 10:53

Hi Chetan

Can someone advise me on a basic VPLS implementation. i.e. the configurations on the PE's and P nodes and customer CE devices. CE device's will be routers. Its for a single customer. The requirement will be for 8 sites.

But for now i just need an overview of how to implement VPLS over MPLS technology.

I've tried to make this post as simple as possible, my previous posts I think went into to much detail.

Thanks

C Williams

Carl Williams Wed, 06/16/2010 - 13:45

Hi

What I will also need is some encryption in the core of my network, I was considering using GRE ontop of IPSEC. GRE will provide me with the ability to route my traffic through the core. We also need to bare in mind that we're going to need layer three connectivity in order to obtain GRE tunnel connectivity in my core.

I'm suspecting that we're going to need to deploy GRE tunnels between the P nodes because this is where I'll have layer three connectivity. Also within the core I'll be using OSPF to advertise the core links.

Please can you provide some pointers with regards to whether deploying GRE ontop of IPSEC is the best method in terms of providing encryption in the core.

If you can I'll need to see also see how the P nodes will be configured. The P nodes will run layer three protocols between them so I suspect GRE over IPSEC will be the best method.

regards

Carl Williams

Actions

This Discussion