You’ve come on a long journey with me. We’re finally at part 5, where the configuration
begins. In part 4, we looked at the two ways that
addresses can be learned. One of these is through data plane learning,
also known as flood-and-learn. In this video, we’re going to configure
VxLAN with data plane learning on some Nexus 9000 series switches. If you watched part 4, you may remember that
I said that control plane learning was preferred. So, why then, are we going to configure data
plane learning here? Isn’t is a waste of time? We’re doing this because it’s much simpler. This is an easier way to learn VxLAN, as you’ll
get to see VTEP configuration, VNI’s, the overlay, and verification. In part 6, we’ll get complicated and see
how the control plane is configured. Let’s get started... We’re going to use a very basic topology
to make configuration as simple as possible. We will use two Nexus 9000 switches. Each switch will have a VTEP interface. There is a single routed link between the
switches. This routed link will simulate the underlay
network. I have attached a host in each of these switches. They will connect to access ports, configured
with VLAN 1000. As they’re both in the same subnet, they
will not be able to communicate initially, due to the routed link. This is what we’ll fix with VxLAN. During the configuration, we will associate
VLAN 1000 with VNI 5000. We’ll also configure multicast to handle
BUM traffic. We’ll start with configuring the underlying
infrastructure. This includes enabling features, setting the
MTU, mapping VLAN 1000 to VNI 5000, configuring the routed link, configuring host ports, and
creating loopback interfaces. We’ll start by getting our three features
enabled. OSPF is used to manage the underlay. The PIM feature is for multicast, which handles
BUM traffic. The nv overlay feature enables VxLAN. NV means ‘Network Virtualization’. Notice that there’s a warning about a system
routing template. The routing template is how the Nexus formats
certain data structures in memory. On the 9000 series platform, this is required
on version 7.0(3)I5(1) and earlier. Newer versions take care of this transparently,
so you won’t get this warning. The vn-segment-vlan-based feature enables
tagging frames with the VxLAN header. We enter the ospf routing instance, simply
to start the OSPF process. We don’t need to add anything else to OSPF
yet. We define VLAN 1000 for the hosts. The vn-segment command maps this VLAN to VNI
5000. Remember that the extra VxLAN headers will
lead to larger packets. The MTU needs to be increased to allow for
this. Keep in mind that the maximum MTU may vary
on different platforms. Now, we’ll set that routing template from
earlier. As mentioned before, if you’re running a
newer version of NXOS, you won’t need to do this. Changing the routing template needs a reboot,
so we’ll save the config, and do that now. Don’t worry, I won’t make you watch the
whole reboot process. :) Now to configure port 49 as the routed link
with the no switchport command. Next, give it an IP address and add the interface
to OSPF. We will be running multicast, so let’s set
the interface to sparse mode. Let’s verify that this is working so far… We can ping, and eventually… OSPF neighbours will form. The host ports are quite simple. They’re just configured as access ports
in VLAN 1000. No special VxLAN config here. We will need loopback interfaces for two reasons. For one, we’ll use the loopback IP as the
rendezvous point in the multicast topology. Also, the VTEP gets its IP address from the
loopback. We’ll see both of these in the next section. Make sure all loopback interfaces are added
into OSPF, and are in sparse mode. A second loopback interface is used as the
anycast rendezvous point. As this is anycast, it is the same on both
switches. And finally, quickly verify that the loopback
interfaces are reachable We’ll now move on to configure the rest
of the multicast infrastructure. This is a very simple multicast topology. I won’t get into how multicast works, as
it’s way outside the scope of this video. After that we’ll look at configuring the
VTEP, also known in the Nexus world as the NVE interface. To start, we’ll configure the rendezvous
point address. Remember that this is based on the loopback
1 interface, which has the same IP on both switches. The RP’s are responsible for a very wide
list of multicast groups in this demo. In the real world, you’ll want to tighten
this up a bit. Next, RP anycast is configured for these two
routers. The anycast RP address is bound to the real
RP addresses. That’s all there is for the multicast configuration. Pretty simple isn’t it? Of course, it could could get quite complicated
in the real world. Now, it’s time to configure the VTEP. VTEP is the generic term for the interface
that encapsulates traffic. On the Nexus platform, this uses a virtual
interface called the NVE interface. The IP address of the NVE is not configured
directly. Rather, it is taken from the loopback interface. This is also where we bind VNI’s to their
multicast groups. This is how BUM traffic is handled. If you need more information on multicast
and BUM traffic, have a look back at part 4. We can verify this with show nve interface. This NVE interface is up, is configured with
VXLAN, uses data plane learning, and gets its IP from loopback 0. The configuration is all done. Were you expecting it to be harder? I know I was when I first started investigating
VxLAN. If you’re looking for more complication
in your life, don’t worry. We’ll get complicated in part 6 when we
look at EVPN. But for now, let’s see dataplane learning
in action. We can use the show nve peers command to see
which VTEPs have been learned. And… there’s nothing. Why’s that? This is because there has not been any flooding
yet. When a host sends an ARP over VNI 5000, it
will be flooded to multicast group 230.1.1.1. We can see this with the show nve vni command. We can also confirm that this VNI uses data
plane learning. Let’s jump onto one of the hosts. This one is 192.168.0.10, so we should be
able to ping 192.168.0.20. This shows that VxLAN is configured correctly. It also should have flooded an ARP request
on the VNI, to all VTEPs in the multicast group Back on the switches, we can now see that
the remote VTEPs have been discovered. We’ll run through a quick summary of some
verification commands. These will help with troubleshooting later. Show nve interface shows us the learning mode. VxLAN encapsulation shows that this is the
VTEP interface. We can also see that it gets its IP from loopback0 Show nve vni also shows the learning mode. This also has a list of all the VNI to multicast
group mappings. You can also see that VNI 5000 is bound to
VLAN 1000 Show nve peers shows discovered VTEPs. As this uses flood-and-learn behaviour, these
addresses are cached, and will time out. If we go to one of the hosts and run a ping,
the VTEPs are discovered again In the sixth and final part of this series,
we’ll cover EVPN configuration, for control-plane learning If you found this video useful or interesting,
please subscribe to the channel, and hit the notifications button. Also, let me know what you thought of the
video in the comments section. I’ll see you in Part 6
