I've got some use cases where I'd like to use something like OTV, but on Nexus 9Ks. Say two datacenters where each datacenter / site is 2 spine and 4 to 6 leaf switches, and only a few VLANs. I see little point to running VXLAN/EVPN within such small sites, just VPC and VLANs with SVI's on the core / spine switches.
VXLAN/EVPN Multi-Site with pseudo-Border GW looks like just the approach I want. However, the use case focuses on migration, where's I'm more interested in a non-VXLAN new N9K based site operating "in legacy mode".
Question #1: The documentation I've seen is a bit unclear, it says something about SVI's and trunks are not supported for external entities. I'd maybe add the word "**routing**" to that -- external entities that would want dynamic routing? I'd hope trunks and SVI's would be supported for internal clients, i.e. servers and other devices that are connected within a VLAN. Seeing as that's how the "legacy" network would be operating, and the description about putting the anycast GW on the border GW. What exactly IS the caveat here?
Question #2: With OTV, one only transports selected VLANs between datacenters. With the Multi-Site writeup, there is no discussion of VLANs that are *not* associated with VNI's, etc., mixed into the same VRF as the VNI-backed VLANs. Questions come to mind, like does routing between the two types of VLAN work, etc.? I built a small VIRL model (not multi-site per se, since the available Nexus image is not quite new enough) and routing between non-VNI and VNI-backed VLANs works fine, locally or over the overlay. I did have to put network statements into the VRF section of BGP for the non-VNI-backed VLANs. What is / is not supported in basic VXLAN/EVPN or Multi-Site along these lines?
I should note that associating non-extended VLANs with unique VNI's appears to be one way of dodging this whole discussion. Might that be a Best Practice? (Makes the configurations more uniform...).
Howdy out there in automation land!!!! Again... two in one day... wow :) So onwards we press. If you have not read Part 1, please go back and do that as it might not make sense. In this part of the Less is More series we are going to install Cloud...
Howdy out there in Automation land!!! Today... I have the start of a long set of two blogs for my readers. We are going to do something exciting and really useful... but purely about system setup and design... no real "automation" today. But first...
Cisco Intersight Account Reset Tool
The Cisco Intersight Account Reset Tool is designed to increase the efficiency of developers, engineers, sellers and trainers working with Cisco Intersight by automating the Intersight account reset process.
Howdy out there in Automation land!! Hope everyone is having a great summer. We draw into the last true month of summer and we are going to take you further on your Action Orchestrator journey. Since we are on our last "Back to the Basics", I think we wil...