VXLAN | Part 6 - BGP EVPN Configuration on Nexus 9000

now the story of on what network with distributed hosts and the one technology has no choice but to keep them all together is VX Lane welcome back to part 6 we're going to take a simple topology and configure VX land with evpn just like part 5 this is a basic topology to keep things simple if you've come straight to this video I would recommend going back and watching part 5 first it explains a few extra things that we won't cover in detail here we still have two switches with a routed link the routed link is the underlay Network this time we will have two tenants they will have two hosts each one on each switch there will also be some IP addressing overlap on the hosts to confirm that this won't be a problem one of our tenants will have a single VNA the other will have two different VN eyes and will lead routing between them this time we will use head and replication also known as ingress replication this is just so you can see how its configured multicast would also work well we'll also see how to add any caste gateway and ARP suppression you this time we'll focus on getting the underlay up and running first this is the IP network which doesn't know about VX LAN we're going to configure the router link MTU size and OSPF we'll start by getting the OSPF feature enabled and increasing the maximum MTU next we'll get the routed link up and advertised in two hours PF as we're not using multicast this time we will only need one loopback interface this is still where the V tab gets its IP address from and of course repeat everything on the second switch now that's done we can verify that the neighbors come up and there it is ready to move on to the overlay you now it's time for things to get interesting we're going to enable the features we need for the overlay configure the anycast gateway virtual MAC address and perform base configuration of bgp we start by enabling the overlay features we need the BGP feature for peering interface VLAN is the same feature we use when we want to create VLAN s vis in this case we use it to create a virtual anycast gateway interface and env overlay evpn adds the e VPN address family the two other features were covered in part 5 so I won't go over them again here Gateway uses the same vMac on all switches we assign this with the fabric forwarding anycast gateway Mac command just remember to be sensible when you choose a MAC address so you won't cause a conflict the V tap is quite similar to before now though we have the command host reach ability protocol BGP this enables control plane learning on the V tab each switch needs to run an instance of BGP we specify the other switch as a neighbor in the real world you will have many neighbors or a few route reflectors we're going to use loopback zero as the source for bgp communication this is the same IP address that's applied to the V tab under the l2 VPN a VPN address family we need to enable sending communities this is needed so he can send route target information to our neighbors and finally the corresponding config is added to the second switch you there's a fair bit of work to get the first tenant up and running this includes creating a layer three vni and a ver F configuring route distinguishers and route targets configuring the V tip ARP suppression head and replication the anycast gateway and bgp evpn as we work through this remember that some of the config is for layer 3 and summary is for layer 2 this can get confusing I'll try to explain it the best I can but don't be afraid to ask questions in the comments let's get started with creating our first tenant the first thing that we need when we create a tenant is a layer 3 vni this serves two purposes it allows routing on the local switch and it can be attached to a vrf this tenant uses vni nine zero zero zero zero one as their l3 VNA we associate it with VLAN 101 here we're creating the tenants of ERF the first thing we do is add the l3 VNA we also need to set the router distinguisher if you're not familiar with our days they used to keep the vrf unique in the BGP database the Rd value can be manually specified which is what I recommend in a mixed vendor environment in an all Nexus environment I recommend letting the switch assign it automatically route targets are used both to import and export routes and evpn addresses the auto keyword lets the switch select its own unique value if you haven't seen this before let me give you a simplified description exporting marks the routes from the local vrf in the BGP database with the route target value the route and BGP are shared with other neighbors neighbors receive the routes and look for out target values that they want to import imported routes are added into an appropriate vrf in short this is a way to share routes and MAC addresses between peers while still associating them with a tenant you an SV is created for VLAN 101 this is the VLAN associated with the L 3 VNA and is associated with a Tenon's vrf the IP forward command is used to enable this interface to forward traffic this essentially turns on routing VTech configuration is a bit different now we need to add the tenant via NIH's including the l3 VNA the suppress ARP command enables app suppression if you remember back to part 4 this enables a local switch to answer a hosts ARP request without flooding the ingress replication command tells the v-type to use head end replication for bomb traffic as you can see it's a very simple configuration this replaces the need for multicast in this lab the associate vrf keyword tells the V tip that this vni is used for routing let's head back over to BGP we go into the tenants vrf and their ipv4 address family then we use the advertised l2 VPN a VPN command to allow external routes to be advertised as a VPN routes within the vrf this won't make a lot of difference in our lab as we don't have any external routes to advertise in I've included this command for your reference incidentally there is little difference if you want to use ipv6 just remember to use the ipv6 address family now we're just creating our VLANs and villainize for our hosts an S VI is created for VLAN 1,000 so we can configure the anycast gateway you notice that the IP address is the same on both switches this lets any of the switches act as the default gateway for the hosts the evpn section is used to advertise MAC address information through BGP the MAC routes also need to become unique so they will still use route targets this is very similar to how the layer 3 information was shared earlier and finally we can figure out how sports I configured one of the ports incorrectly here but due to the magic of video editing I have invisibly fixed that up that's our first view now for our first tenant there's a fair bit of work getting the initial configure and running we're now adding the second VLAN and vni to this tenant they should all be fairly familiar to you Vanya the basic procedure is add villain and associate VNA create an S VI for the anycast gateway add the vni to the V tip you and add the vni to evpn you now that the first tenant is ready we can start the second one much of this config will be the same so we'll move through it fairly quickly I'll avoid showing you the host port configuration I think you understand that fairly well by now we'll create a V RF for this tenant using layer 3 v ni 9 0 0 0 0 2 this is attached to VLAN 102 and IP forwarding is enabled this tenant uses vni 6000 for their hosts this is attached to VLAN 900 as before the antique ass gateway address is added to this SV I even though this tenant doesn't need to route between the VN eyes the anti cast gateway is still the default gateway for external networks like the internet or when the LTV ni and l3 and I are added to the existing v-type we don't need to create new v tips for each tenant switch to has the same configuration in this case you as you can see adding a new tenant is not as complex as setting up the first one you now the two tenants have been configured let's verify that it's all working the commands were going to use here are useful when troubleshooting I suggest bookmarking this and referring back when you need it we're jumping right in with show BGP l to VPN a VPN summary this command shows us our BGP neighbors if you're used to BGP you should feel comfortable here as usual we can see the neighbor the a s number and their state if the state doesn't list a number of prefixes received you have problems we can CV taps with the show nve PS command notice here on switch 1 that this now shows that the learning type is CP for control plane on the second switch we're using show NVE vni this shows us the VN eyes that are associated with the V tab we also see the control plane learning is configured the multicast group column would normally show the multicast group that the VNA is bound to this is for the BOM traffic that we discussed in part 4 in our case this shows as a unicast BGP this is because we configure the ingress replication instead of multicast on these VN eyes the l3 VN eyes are used for routing so the multicast column is not relevant to them let's get on one of our hosts in this lab I'm using a router to simulate a host first we see there are no pings dropped while we learn about destination addresses this is for two reasons one the local switch already knows all the IP to Mac bindings and to our suppression causes the host ARP requests to be answered very quickly if we try to ping in address owned by another tenant we can see that this fails this proves that we have successfully separated our customer traffic the same is true in Reverse tenant to has access to their resources but not to tenant ones resources back on up suppression we can see the IP to make bindings that the switch are returning to the hosts with the show IP up suppression case detail command this even shows the ports that the hosts are connected on the elf flag shows that the host is connected locally the our flag shows that the host has been learned from a remote V tip we can use show VX land to easily see VLAN to VN I bindings as you know well by now MAC addresses are shared through bgp to see the Mac's that have been learned we can look at the BGP database with show L to route a VPN Mac or the next top column is interesting here this shows the IP of the remote V tab that is used to get this address if the our Mac flag is set this indicates that this is an l-3 VNA used for routing we can change this command slightly to show l2 route evpn back IP all this gives another way to see Mac - IP bindings the VNA that they're on and the V tab there behind if BGP is listed next to an entry this entry has been learned through a remote V tab HHMM is host mobility manager in this context this means that the address has been learned on the local switch the big one is show BGP l - VPN a VPN there's a lot of data in this one this is how you see all the details in the BGP database we can see that MAC addresses have been learned along with the IP that it maps to the route distinguisher is also shown this is the automatically assigned value that we can feed earlier and that's all for the VX land series I hope you've enjoyed watching these videos and have learned something useful or at least interesting please share what you thought of the series in the comments below if you liked it please share and subscribe thanks for staying with me through the series you

Channel: Network Direction

Views: 66,004

Rating: 4.9672937 out of 5

Keywords: vxlan part 6, vxlan evpn nexus 9k, vxlan configuration nexus 9000, nexus 9000 vxlan, cisco nexus 9000 evpn, arp suppression, configure vxlan evpn bgp nexus 9000, ingress replication, vxlan ebgp vpn, vxlan bgp evpn, vxlan evpn configuration, bgp evpn vxlan, vxlan configuration, vxlan evpn bgp, evpn configuration, configuring evpn cisco, bgp evpn configuration, evpn bgp, bgp evpn, vxlan evpn, anycast gateway, configuration nexus 9000, evpn vxlan, vxlan configuration cisco

Id: D9k9_hRdrGc

Length: 18min 6sec (1086 seconds)

Published: Thu Mar 08 2018