Cisco OTV (or Overlay Transport Virtualisation) is a technology inside Cisco Nexus switches (7K) for extending VLANs across a routed network. You can read all about OTV here and here. This post consists of an example configuration for a lab where you have a single Nexus 7K and you want to get OTV over multicast running between VDCs and comes from my CCIE study notes for when I was practicing with OTV. I’ve heard some people have issues with getting the multicast configuration working, so I figured I would share mine here.

First off, to create the illusion of a routed network, this will be an “OTV on a stick” type configuration and not a directly connected one (that would be too easy). Let’s take a look at the topology we want to create:

Cisco_OTV_Lab_with_Multicast_concept

We want the two servers in 10.0.10.0/24 to reach each other through the routed fabric in between. The supervisor we’re using has a 4 VDC limit and in this example I will be using all 4. The smaller router icons are VRFs on the SW1 and SW2 VDCs which you will see return in the configuration.

I’m going to assume you have a working knowledge of basic NX-OS, OSPF and OTV knowledge and have the VDCs set up, have the proper licenses, made the proper interface allocations (mind your M and F linecards and make sure absolutely no other connections are active and trunking, you’ll have a field day looking for why it doesn’t work otherwise) and can start from there. First, some basic information:

OTV Extended VLAN: 10
OTV Site-VLAN: 99
OTV Site-IDs: 0x1 & 0x2
OTV Control: 239.1.1.1
OTV Data Range: 232.1.1.0/24

Let’s begin with numbering all the interfaces and creating the OSPF network:

OTV1

SW1

SW1

OTV2

With that out of the way you should have a routed network and OTV1 should be able to reach OTV2:

Now it’s time for the multicast and OTV configuration. Disclaimer: I am not a multicast expert, but I know enough to get it to work. It might be very well that there is a more efficient way of setting this up, this is just what I did to get it working.

OTV1

SW1

SW2

OTV2

If you’ve come this far, you’ve got the following topology:

Cisco_OTV_Lab_with_Multicast_topo

At this time, you should have a working OTV adjacency between OTV1 and OTV2. Don’t freak out when there’s no connectivity at first, as OTV adjacencies could take a while before they are actually forwarding. If there’s no connectivity, check the output of this command:

If your output is similar to the above output, wait patiently for the countdown to finish. After that grace period the VLAN status should switch to active.

If everything is working correctly, you should have these types of output:

If your adjacency is not online, you have some troubleshooting to do. Here’s a few links that could help you in that case:



Share the wealth!

2 comments on “Cisco OTV Lab with Multicast example

  • Hello there…

    Im also looking to setting up otv in a lab…but luckily, i have two separate 77ks to mess with…my question is, what is the reason for connecting sw1 and sw2?…also, is the multicast routing b/w sw1 and sw2 needed since that is done at the aed vdc?
    thanks in advance

    • Hi Sam,

      Thanks for your message. As for your questions, I’ll try to answer here. The reason for connecting sw1 and sw2 is to form essentially what is your dark fiber running between locations. This is where your traffic goes from location 1 to location 2. There is no way to create a ‘virtual wire’ between sw1 and sw2 internally, so you have to use a physical cable.

      Multicast is definitely also necessary on the sw1 and sw2 as that is the backbone of OTV. You’re right that multicast is used in the OTV VDCs, but it uses it to reach the other OTV instance on the other location. If your transport devices (sw1 and sw2) do not route multicast, the OTV instances won’t be able to talk to each other and form the OTV adjacency.

      Hope that helps.

Leave a Reply

Your email address will not be published. Required fields are marked *