Hello my friend,

with this article we’ll close our series of EVPN/VXLAN articles, we started some time ago with pure switching (L2) and distributed gateway (L3) for EVPN/VXLAN. In present article we’ll talk about so called L3 OUT functionality, where customer within tenant should speak dynamic routing with the leaf switch.

Disclaimer

Start with the L2 configuration and L3 configuration for EVPN/VXLAN to get full understanding of what is going on here.

Brief description

Related use case, where we need to make dynamic routing between customer VNF in tenant and our DC fabric, isn’t quite common. It isn’t standard web-based application or something similar. But it’s still valid. For example, distributed load balancer, which distributes customer sessions across lots of frontends, or distributed NAT/FW application, which pass the customer traffic between security zones. From example above we can distinguish two important capabilities of such flows:

• They are statefull. So traffic flow should pass only certain device in both directions.
• System, which traffic pass, is distributed. Probably, if you have big HW-load balancer, you might not need to have routing protocols, but of you used set of VNFs across different racks, you will need to know, which exactly VNF the traffic has pass in one direction in order to send it back through the same VNF

What we are going to test?

In order to show, how BGP peering is working between VM and Leaf, we’ll announce loopback from each VM to the cloud. The success criteria for the lab is possibility to reach any VM’s loopback from any another VM’s loopback.

Software version

The following infrastructure is used in my lab:

• CentOS 7 with python 2.7.
• Ansible 2.4.2
• Nokia (Alcatel-Lucent) SR OS 14.0.R4
• Cisco IOS XRv 6.1.2

See the previous article to get details how to build the lab

Topology

The physical topology is standard for our labs:

Logical topology is the same, as we have in previous lab. But as we are touching only service part, only respective servies will be shown. Service#1 looks like:

Service #2 has the following topology:

Initial configuration files in this lab are the finish one, from the previous one

Configuration eBGP PE-CE peering between Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR

From the point of view of the activities, we need to do the following stuff:

• Enable propagation of EVPN type-5 routes
• Configure BGP and policies on Leaf within customer VPN
• Configure BGP and policies at VM side

Let’s view in details, what we configure per vendor

#1. Configuration of leaf switches // Nokia (Alcatel-Lucent) SR OS

Pay attention that only incremental configuration is shown here. The rest of the configuration you can find in Part 1 and Part 2

Here we go:

In the VPLS part we need to enable type 5 routes of EVPN. Though we did it previously, I have highlighted it here once more.

Then we configure BGP for PE-CE peering. In order to advertise routes, learned from EVPN, we need to allow them in the export policy. There are several ways, how we can achieve that. Here we take just the option to control export by allowing certain prefixes in prefix lists.

The third important point is changing of preference (administrative distance – AD – in Cisco words). The reason, why we need to do that, is that by default AD of BGP routes is 170 and 169 for BGP EVPN. So, routes are getting in kind of loop, that Leaf switches shows to another Leaf, as learned back routes have better priority. When we change AD so that locally learned BGP routes are more preferable, than the loop is broken and routing works properly.

Let’s review configuration of Cisco side now.

#2. Configuration of VMs // Cisco IOS XR

Here the configuration is quite trivial:

The only point that is worth mentioning is changes of local-as in order to simulate different customers.

See more details on BGP configuration in the corresponding article.

Verification

We start verification with routing tables. On SR1, which is Nokia (Alcatel-Lucent) SR OS based data centre leaf, we see the following picture:

As we have changed the preference for routing table, you see the correct routing here. On connected VM, which is Cisco IOS XR router we see:

Of the particular interest would be the BGP EVPN RIB on Nokia (Alcatel-Lucent) SR OS devices:

You might see in this table, that best IP route within EVPN still points to another leaf, though routing table is correct. In this table you see all the related routes.

At Cisco IOS XR side, which is VM2, there is no something special:

The final part of our verifications, as we have discussed so far, is ping between loopbacks.

So.. Ping time!

Final configuration files: 114_config_final_linux 114_config_final_SR1 114_config_final_SR2 114_config_final_XR3 114_config_final_XR4

Ansible playbook to reach that state from initial configurations:

Lessons learned

What goes around, comes around. I mean that toolset, regardless of technologies is always the same. For example, preference or administrative distance. This tool is very old, but we suddenly it comes back into game, when we start speaking about EVPN as replacement for traditional IP VPNs. So, don’t forget old school tools, even if you deal with the mega modern technologies

Conclusion

As you have seen over a couple of last articles, EVPN can do all things, like L2 VPNs, L3 VPNs and even incorporate PE-CE routing. By the end of the day, it means that this particular address-family can replace all other BGP signalling flavours. Especially, when we take into consideration, that it can works both with MPLS and VXLAN data plane, EVPN is really powerful. Take care and good bye!

P.S.

If you have further questions or you need help with your networks, I’m happy to assist you, just send me message. Also don’t forget to share the article on your social media, if you like it.

Support us

Support new interop and automation articles at karneliuk.com
EUR

I want to support with:
9.99 EUR4.99 EUR24.99 EUR49.99 EUR99.99 EUR199.99 EUR

BR,

Anton Karneliuk