Service Providers

pmoyer

Innovation: Routing Over VPLS with NetIron Software 5.4

by pmoyer on ‎09-26-2012 04:57 PM (256 Views)

Back in January of this year I wrote about a really cool NetIron feature called “MCT with VPLS”. That feature was released in the NetIron 5.3 software. Well, in the NetIron 5.4 software release (which is GA this week!) we have a new innovative twist on how you can use VPLS. It’s called “Routing over VPLS” and this new capability allows a VPLS endpoint to provide simultaneous layer-3 routing on NetIron products.

So, layer-3 routing (& forwarding) is now supported over a VPLS endpoint! Previously, only layer-2 forwarding was supported for VPLS. Recall that VPLS provides a multi-point layer-2 Ethernet service, but with this new feature one can now combine layer-2 and layer-3 services on the same interface that maps to a VPLS instance.

It looks like this –

routing_over_vpls.jpg

In the simple diagram above there are two data centers, each with two Brocade NetIron MLXe Series chassis (for high-availability purposes). Each data center also has a Brocade VCS Ethernet fabric. The inter-DC connectivity is provided by the VPLS layer-2 Ethernet service, which runs between the four MLXe chassis. In essence, all four of the MLXe chassis’s are layer-2 adjacent to each other over the VPLS service. Each MLXe is also running the Virtual Router Redundancy Protocol (VRRP-E), which is a layer-3 gateway redundancy protocol. Each data center has its own Internet connection for external connectivity.

The way it works is this: If a server or end host is forwarding packets to another server or end host at layer-2, the packets are forwarded by the VCS Ethernet fabric if the two servers are in the same data center (eg. Intra-DC), or the packets are forwarded over the VPLS service if the two servers are in different data centers (eg. Inter-DC). In either case, the traffic is forwarded at layer-2. In the intra-DC use case, no MLXe should be in the forwarding path; the VCS Ethernet fabric handles all the forwarding. That is pretty straightforward from a layer-2 service perspective.

But what if a server or end host needs to send packets to external destinations; in other words, at layer-3? Previously, this layer-3 traffic had to be forwarded over a different layer-3 enabled interface on the MLXe or depending on the topology and design, by a different layer-3 gateway router. That was an inefficient, non-optimal way of providing both layer-2 and layer-3 services.

With NetIron software release 5.4, both layer-2 and layer-3 services can be simultaneously provided over the same VPLS interface on the MLXe. This maximizes the customers’ investment in terms of ports while also simplifying the topology and network design.

Back to the diagram: Now when a server or end host sends layer-3 packets to external destinations, the traffic entering the MLXe on its VPLS interface can be routed directly to the Internet (assuming the Internet connection is on the same MLXe, as is shown here). The diagram shows that Data Center 1 has an MLXe acting as the VRRP-E master router and it is forwarding the packets directly to the Internet. This is what this new feature provides; enabling the VPLS endpoint to provide both layer-2 and layer-3 services. Another way of thinking of this feature is “VE over VPLS”. VE refers to a Virtual Ethernet interface, which is a virtual routing interface in NetIron terminology.

But what about Data Center 2 in the diagram? Its showing an MLXe acting as a VRRP-E backup router and this router is also forwarding packets directly to its Internet connection. How does that work you might ask? Well, one thing I didn’t mention is that the “E” in the VRRP-E solution is an extended tweak that we’ve done for VRRP. This is not new in NetIron software; this has been in the code for many years. It’s when you combine this feature with the routing over VPLS feature that you gain additional benefits. Basically, an MLXe acting as a backup VRRP-E router can also forward packets to external destinations if it knows how to get there (eg. It has an active routing path there). The backup router does not need to send all its packets to the router acting as the VRRP-E master. If it did, you will notice that the traffic would have to be forwarded back to Data Center 1 where the VRRP-E master router resides, which clearly results in a highly sub-optimal traffic pattern (often referred to as a “trombone traffic” pattern). While not the same scenario as we are describing, here is one explanation of traffic trombone.

So there you have it! Routing over VPLS provides simultaneous layer-2 and layer-3 services on VPLS endpoints. And I should also mention that the configuration of this is really simple. Here is an example where VE 200 is enabled under the VPLS VEoVPLS instance 10:

    

     router-mpls

          vpls VEoVPLS 10

          router-interface ve 200

          vlan 10

                    tagged ethe 4/1

          vlan 200 

                    tagged ethe 2/1

This is an innovative feature and the benefit to the customer is pretty clear in terms of maximizing their investment while also simplifying their design. As usual, comments or questions are always welcome!

Comments
by (anon) on ‎10-10-2012 12:17 PM

This is by far the most important feature for me for 5.4

I have been wondering though. On a VPLS instance, a vpls-peer will remain up as long as the device has a port active in the VPLS. Let's say I put routing on VPLS on a box, and that box only has a single active port in the VPLS. If that port goes down, does the box consider a port to still be active and the vpls will stay up?

Thanks

by pmoyer on ‎11-13-2012 10:51 AM

Hi Darren,

Thanks for your comment. I'm very sorry for this belated reply. Please unicast email me and we can discuss this scenario you describe. I want to be sure I understand the details before answering.

Thanks!

by chairul on ‎12-10-2012 11:36 PM

I have a case, where I want to connect my VPLS network to Internet via VPLS router-interface In MLX, then I realize that I cant, because MLX have no NAT feature.

Did you guys ever find the same problem? if you do, could you please share.

by (anon) on ‎01-18-2013 10:54 AM

Hi Chairul,

You are correct, the MLX does not perform NAT. We have an Application Delivery Platform, called the ADX, that performs this function. Please take a look here -

http://www.brocade.com/products/all/application-delivery-switches/product-details/serveriron-adx-ser...

Thank You.

by (anon) on ‎01-31-2013 08:36 AM

Hello,

This is a great feature, but it only seems to work for ve in the default-vrf... Am I right ?

Thanks,

Julien

by pmoyer on ‎02-05-2013 02:30 PM

Hi Julien,

You are correct; this feature is only supported in the default-VRF. There is a work-around using a loopback interface that could be used. If you'd like more information on that, please unicast me.

Thanks.