L2VNI SW/HW Compatibility

[StevieC666]

Hi all,

I've posed these questions to our Cisco TSA but I'm he's a super busy chappy at present so figured I'd see if I could get an answer here ahead of a reply from him.

Basically we have a critical requirement to be able to provide 'basic' VLANs (basic is the terminology used within the org) to our internal customers whereby they can simply connect things like an internal interface of a SMB firewall to an interface of one fabric edge node and then have endpoints to interfaces on disparate fabric edge nodes all of which are able to leverage IP address configuration provided by the SMB firewall.

We've got to the point whereby we've been able to provide the majority of the functionality required on this 'basic' VLAN by simply enabling L2 flooding on the nets assigned to these interfaces but unsurprisingly DHCP functionality within the fabric eludes us. From reading through prior articles here, having previously attended all the DNA/SDA roadmap briefings and reviewing the Cisco Live collateral I'm pretty confident (although I'm open to being told otherwise) that the L2VN functionality that has been teased via the GUI for so long is the answer.

If my assumption that L2VN functionality is the way forward I've three simple questions that will help us, and most likely others out there in the same position as ourselves, understand more;

1. In which version of DNA Center is the functionality live to create L2VNs? The 2.2.2.x documentation I’ve found makes no mention of the functionality, have to look at the DNA Center 2.2.3.x guide for that
1. https://www.cisco.com/c/en/us/td/docs/cloud-systems-management/network-automation-and-management/dna-center/2-2-3/user_guide/b_cisco_dna_center_ug_2_2_3/b_cisco_dna_center_ug_2_2_3_chapter_01110.html?bookSearch=true#task_upc_4xk_1qb
2. What IOS-XE version will be the minimum version required to support the functionality? Making the assumption that 16.12.3s doesn’t.
3. Will the 3650 switches support L2VN functionality? The current public SDA compatibility matrix doesn’t go into different SDA functionality for switch types and I cant find anything in the release notes either. However when we did try ticking the box and deploying the functionality in one of the fabric sites for giggles the deployment failed mentioning 3650s.

If we find that 3650's aren't compatible for whatever reason then I'll be asking questions like 'but if we leveraged fabric zone functionality and had the 3650s in a zone with no L2VN nets would that be a workaround', of course that then opens a whole other series of debates and even if that would fly the amount of work to re-engineer to achieve that would be huge to the point we might have to accept that replacements with 9200's (not Ls) or 9300's would be the way forward for our 3650s..

I hope that somebody far more learned here can help, of course if I get back information from our TSA (subject to being allowed to disclose) I'll update this as I can.

Cheers, 

Steve

[Jonathan Cuthbert · Accepted solution]

I want to confirm terminology to ensure I am answering the correct question.

We have L2 VNI / L2 VNID today.  We have actually had this functionality since at least Cisco DNA Center 1.2.x.  L2 VNID or what used to be called "Layer 2 Extension to LISP" in the user interface was simply a way for the LISP control plane protocol to register the MAC address as the EID in the EID-to-RLOC binding.  Previously, we could register IPv4-to-RLOC and IPv6-to-RLOC.

From the perspective of LISP, we are binding an instance of LISP to a VLAN switching table.  Before we had this extension, we only had the capability of binding an instance of LISP to a VRF routing table. 

In the current user interface, we use the term "Layer 2 Virtual Network." 

We also have a feature that is sometimes confused with L2 VN / L2 VNI / L2 VNID.
When we create a Layer 2 Virtual Network in Cisco DNA Center, we are basically saying "I would like to create a VLAN on the device.  I would like to be able to register MAC addresses as my EID.  I would like to be able to make forwarding decisions in the overlay based on MAC address."  Again, we have had this for some time. 

What you may be referring to is that we have the capability of having the gateway for that Layer 2 Virtual Network (the SVI) either inside the fabric and outside the fabric.  By default, before this feature, there is an Anycast Gateway provisioned on all Edge Nodes in the Fabric site for the VN.  With Gateway outside of the Fabric (GWOTF), the SVI for the VN would sit on Firewall.  This is likely the feature you are referring to, and sometimes you may here non-official terms such as "pure L2 VN" or "pure L2 fabric."  It's just a Layer 2 Virtual Network with a Gateway outside of the Fabric. 

The feature is currently in Limited Availability (LA) with a large warning message saying as much in the user interface.  Due to its LA status, specific details are not currently in the public domain.  I would urge you to continue reaching out to your TSA for details if this feature is needed for your deployment.

[StevieC666]

Thanks for the reply, everyday is a school day

I can confirm that I was talking about the latter scenario where we want the flexibility of having the SVI for a given network not configured on a fabric edge but rather a device that's an endpoint or indeed outside of the fabric.

I'll get chasing our TSA as this is a major challenge for us.

Steve