Hi all, long time reader asking first question. Be kind! 😊
In the post : https://community.cisco.com/t5/networking-documents/vlans-used-in-cisco-dna-center-software-defined-access-solution/ta-p/3945667 it says:
VLANs 3001-3500 - Used for Border Uplinks Automation towards Peer Network
The above VLANs will be incremented and counted up. If in Fabric Site1, Cisco DNA Center provisioned VLANs 3001, 3002 then it would start at VLANs 3003 and up for Fabric Site2. These VLANs are not re-used today across different Fabric Sites.
VLANs 1021 and above - Used for Fabric Edge Any-cast Gateway (SVIs) Automation towards Endpoints or Hosts or Extended Nodes
Cisco DNA Center will re-use the VLANs across different Fabric Sites. For example, VLANs 1021 - 1025 are provisioned by Cisco DNAC in Fabric Site1, then in Fabric Site2, it starts provisioning the first IP Pool / Subnet (SVIs) starting from VLANs 1021 and up.
VLAN 2045 - AP_VLAN
VLAN 2046 - VOICE_VLAN (Critical Voice Vlan)
VLAN 2047 - CRITICAL_VLAN (Critical Data Vlan)
Before I call TAC, or use my get out of jail free card and reach out to my account manager to find help, I figured I’d try posting my query into the community. I’ve had a search through previous posts and have found a couple of questions similar but not exactly what I need, also as DNAC/SDA is an ever changing beast things might have changed.
As part of the long winding journey we’re planning to migrate all L3 functionality from our non-Cisco core network into the Fusion Router/DC/Shared Services setup (different people like different terminology) that for the purposes of simplicity we call the Cisco core.
Simple enough at the two sites within Campus 2, the VLAN IDs on the networks with IP interfaces (in non Cisco speak) fall outside of the 3001-3500 range and have no overlap with 2045 through 2047 if they need to be forwarded out the border to the fusion (I’m not sure they do but belts and braces huh?). This means we can simply forward them to the Cisco ‘core’, create a corresponding SVI, do a little routing jiggery pokery and boom our non-Cisco devices in Campus 2 become dumb L2 distribution devices.
I'm thinking all should be good in Campus 2 and for the networks that that during migration we will need to configure L2 handoff we shouldn’t have any issues plumbing the ‘core’ into the relevant border and forwarding the required VLANs. Whilst the aforementioned VLAN IDs overlap with the “VLANs 1021 and above ”range that range if I interpret it correctly is only used at the fabric edge and not in the path edge > border?
Below is our current topology diagram with all company identifiable information redacted.
Campus 1 however I think we have challenges if the above rules on VLAN IDs is hard and fast:
Challenge - We have existing networks at two of our sites at Campus 1 that use VLAN IDs in the range 3001 – 3500, more specifically 3001 through 3087. We already have VLANs in range 3025 through 3036 configured on one or the other Campus 1 ‘core’ devices as Transit VLANs from the Fabric 1 borders which adds a little complexity especially as when it comes to migration these nets in the legacy world would most likely require L2 handoff but they’re only a few of many nets and I think we might have a much larger challenge if we can’t use any of the legacy nets let alone a few.
Questions:
- Can we use VLAN IDs 3001-3500 on the ‘core’ devices at Campus 1 and migrate our legacy L3 nets knowing that at Campus 1 we’re unlikely to create any more Transit VLANs at Campus 1?
- We’re about to build Fabric 2, is our assumption correct that any automatically allocated VLAN IDs for transit between the Campus 2 borders and the ‘core’/Fusion role devices at Campus 2 wont clash with existing legacy VLAN IDs already forward into the ‘core’ at Campus 2, as we’re not forwarding anything within the 3001 through 3005 range?
- Can we use VLAN ID’s within the ranges 1021 and above including 3001 through 3500 at Campus 1 for L2 handoff between the Fabric 1 borders and the ‘core’/Fusion role devices at Campus 1?
- Can we use VLAN ID’s within the ranges 1021 and above including 3001 through 3500 at Campus 2 for L2 handoff between the Fabric 2 borders and the ‘core’/Fusion role devices at Campus 2?
- Where the guidance states “The above VLANs will be incremented and counted up“ is this incremental count maintained through the DNAC lifecycle of patches and version upgrades? If so could we ‘simply’ create a shed load of dummy transits to burn through the range 3001 through 3100 and then recreate our transit VLANs that already sit in that range?
I might be over complicating things and somebody will point me to the ‘just make it work’ button hidden deep within the menu system 😊
Hi Stevie,
What version of DNA Center are you running? I’m not sure if you are already aware, but as of DNA Center version 1.3.3.x you can now customise the VLAN IDs that are used for Border L3 handoff. You still have to use VLANs in range 3001-3500, but you can now manually map each VN to a VLAN instead of DNA Center allocating automatically. This should allow you to create your own VLAN design to avoid any clashes on your core and worry about how DNAC manages the allocations. Screenshot below. You still cannot reuse the same Border L3 handoff VLAN IDs between fabric sites so they will need to be unique for Campus 1 and Campus 2.
The only challenge that you may still have is with the Layer 2 border handoff, as you cannot map any IP pools to external VLAN IDs 1,1002-1005,2045-2047 and 3000-3500. DNA Center will generate the below error if attempt to do this. Fortunately I have not had a situation where I have needed to migrate any legacy VLANs in these ranges to SDA so I’m not sure what the suggested workaround is. Cisco/another member of the community will need to advise on this.
Also you are correct when you state that VLANs 1021+ are only provisioned on the fabric edge nodes so these VLANs, as well as 2045-2047, will not be automated between the fabric borders and your core for IP transit. In addition, as far as I’m aware, if DNA Center has provisioned an IP pool on the fabric edges using a VLAN in range 1021+, such as 1030, you can still map an IP pool to external VLAN 1030 on the L2 border without any conflicts.
One other area to note for L2 border handoff - it is not supported to map the same external VLAN ID on more than one border. For example in your design, you cannot map external VLAN 2930 to border 1 and border 2 in Campus 2. If you need node/link resiliency for the L2 border handoff, the suggested design is to use a dedicated stack with 2 links connected to your core in a port-channel or using STP blocking.
Hope this helps
