MPLS VPN tutorial with configuration example for HP A-Series (H3C)

Ok, this post is about basic configuration of MPLS and the basic MPLS VPNs theory so you can understand the HP Networking (HPN) A-Series (or commonly known as H3C series) configuration and maybe also with the theory other vendors configurations. I will into detail of the MPLS/MPLS VPN/BGP architecture and quickly go through the overall theory to and give HPN/H3C syntax reference at the end of this post. I quess this article can be used for vendor independent MPLS VPN introduction as well because configuration of HPN devices is quite properly separated.

MPLS VPNs

Now a super quick theory lesson. MPLS has the ability to do end to end switched Label Switched Paths (LSPs) that are essentially a tunnel between to points. This natural tunnels in combination with virtualization on the end Provider Edge (PE router) can enable carriers to create one physical network and sell it virtalized to customers. The customers connect with their Customer Edge (CE router) and exchange routing information with virtual routing instances in the PE routers.

The diagram below is what we are going to be creating in this example. We will have CUSTOMER_A and CUSTOMER_B that we are going to route in different locations and the customer routing is completely virtualized so even if the customer will have a network addressing collision (both using private subnets) there will be no collision.

On the following diagram you can see a very basic scheme:

H3C/HPN MPLS VPN example

H3C/HPN MPLS VPN example

Requirements:

  • HPN/H3C router capable of virtualization of routing and forwarding called “vpn-instance” (on Cisco called Virtual Routing and Forwarding or “VRF”)
  • BGP-MultiProtocol (BGP-MP) extension running between PEs
  • MPLS support (including stacking)
  • MTU at minimum of 1508B (every MPLS label takes 4B, and you have to have two for MPSL VPN, one for forwarding and the other for Customer identification on the LSP)

Route Target,

The BGP-MP carries with itself and extended communities to be able to import/export routes between varios virtual vpn-instances (“VRF”s). One of the most important ones are Route Targets (RT). When you create a virtual vpn-instance, you usually assign it at least one import and one export RT. When a route is taken from this vpn-instance to the BGP-MP, the route is assigned the RT to the extended community of the route. Then this route comes to other PEs as a BGP update, it will be imported to all the vpn-instances that have the same RT assigned as import RT. You might correctly quess that in our example and typically you will simply create one import/export RT for every customer and use the same on every PE vpn-instance having this customer. The extended community is called Export and Import lists and can carry multiple RTs, the rules for import and export are:

Export list: All MBGP routes must carry export RT list.
Import list: When one export RT list match with import RT list, the route
could be added into the VPN instance.

 Route Distinguisher

As I mentioned, you can have customers that have a collision between each other subnetting, this is completely OK as they are separated by virtualization. The BGP process however handles this internally by getting additional 64bit identification called RouteDistinguisher (RD) and attaches this to every 32bit IPv4 address creating a unique 96bit address called VPNv4 address that is unique across all the virtualized vpn-instances/customers.

Inside BGP-MP update

Basically when all this information gets to and BGP-MP session, this is quick and simplified overview of what gets transported:

Also included are Import list and Export lists inside Extended_Communities of the BGP UPDATE that contain all the RTs.

CUSTOMER_B route distribution via MPLS cloud

CUSTOMER_B route distribution via MPLS cloud

Also this is how the Label will be redistributed for LSP by LD protocol and for MPLS VPN Labels by BGP-MP Protocol:

BGP-MP and LDP update content

BGP-MP and LDP update content

And at the end this is how the packets will be forwarded based on different MPLS labels and IPs:

Packet MPLS/IP encapsulation end-to-end for CUSTOMER_B

Packet MPLS/IP encapsulation end-to-end for CUSTOMER_B

HPN (H3C) MPLS VPN configuration example

For very good reasons, I will show here only configuration example for CUSTOMER_B Router R1 and PE1 routers. For PE to CE communication I chosen BGP in this example, if you want other protocols, you have to look to the configuration guides for them. Also basic MPLS must be activated for all PE and P devices that is shown in the beginning.

Basic MPLS configuration for P and PE devices

This part must be done on all MPLS routers in the provider network so that all LSP paths can be build.

To start basic MPLS forwarding + LDP on a H3C Router, you have to go through these steps:

  • Configure a Label Switch Router ID (best loopback IP)
  • Enable MPLS on the router as a whole
  • Specify what traffic can trigger the LSP establishment
  • Enable LDP at the Global level
  • Enable LDP on the interfaces

In code syntax, this is it for the most general (ergo Cisco-like) configuration:

CUSTOMER_B Router R1 configuration (no MPLS here!)

In summary the configuration on the CE router is very basic, you can have a quick look at my previous article about BGP on HPN to learn a bit more about BGP configuration on HPN devices.

PE1 router BGP/MPLS VPN configuration

The configuration omitted other customers but the configuration would be the same with only different interface/RD/RT/peers and I believe that from the information showed here you can create it without issue yourself.

Summary

In summary MPLS VPNs (Also called MPLS L3 VPNs because also L2 version was created afterwards) are a very, very … very common place both provider and data center environment solutions.

If you enjoyed this blog, please share.

About Peter Havrila

Author's Profile