SDA IP Pool VLAN Assignment

[dm2020]

Hi All,

I'm currently deploying a multi-site SDA fabric and I wanted to find out how others are managing the VLAN IDs that are assigned to IP address pools.

When testing, DNA Center auto allocates VLAN IDs to IP Pools starting from VLAN 1021, however this is not kept in sync between fabric sites. For example (depending on the order of provisioning) DNAC allocates VLAN 1021 to our Workstation VLAN in fabric site 1 and VLAN 1023 to the corresponding Workstation VLAN in fabric site 2. The VLANs have been allocated the same name which keeps our ISE authorisation policies clean, however from a management and operational perspective, having different VLANs between different site can cause some complexity.

I just wanted to see how other are managing this. Do you manually assign VLAN IDs to IP pools during provisioning to keep common IP pools consistent across fabric sites, or do you simply not worry and let DNA Center allocate automatically?

Thanks

[andy!doesnt!like!uucp]

u still have an ability to assign custom VLAN ID to IP-POOL when u configure AnycastGW for target pool.
p.s. so far i have no troubles with operating different vlan ids with the same purpose/name. what is you operating issue here?

[dm2020]

Its not necessarily an operating issue really as everything works correctly, however from a management and troubleshooting perspective, keeping a common VLAN ID scheme between sites has always been a common approach that we have followed in a traditional network. SDA changes a lot of fundamentals so perhaps following this traditional approach is no longer relevant. I just wanted to get the perspective of others. 

So are you just allowing DNAC to auto allocate the VLAN ID for each IP Pool with a manually specified VLAN name?

[andy!doesnt!like!uucp]

No. in account where i'm working with SDA there is a scheme of the VLAN ID assignment for IP-pools (f.e. WiredOfficeLan is everywhere VLAN ID 101) & we follow it.
i meant concurrently we have several accounts with no VLAN-ID-to-Purpose scheme, but still no troubles there with OAM as soon as there are good OAM tools :0)

[Torbjørn]

We maintain the same mappings across sites for the reasons you outlined above. It makes it both easier to deploy in an automated fashion and operate/troubleshoot the network.

[dm2020]

Thanks @Torbjørn - So as a base example, are you doing something similar to the following with the VLAN names set as the same across all fabric sites?

Fabric Site 1

Site1_Workstation - 1021

Site1_Phones - 1022

Site1_Printers - 1023

Site1_Guest - 1024

Fabric Site 2

Site2_Workstation - 1021

Site2_Phones - 1022

Site2_Printers - 1023

Site2_Guest - 1024

Do you also see any value with reserving blocks of VLANs for a given VN? So VLANs 100 to 149 Corp VN, VLANs 150 to 199 Guest VN etc? This has been suggested to me but maybe difficult to scale.

[Torbjørn]

Yes, we do something similar to that scheme.

You will probably reduce the number of VLANs quite a lot compared to your legacy network, scalability shouldn't be an issue. Most  things that would previously require its own VLAN can reside in the same VLAN in SDA by utilizing SGT/SGACLs for segmentation. Reserving a few VLANs per VN could be a good idea, I have reserved 10 VLAN IDs per VN(1030-1039, 1040-1049 etc.) for a few customers and haven't come close to "maxing" it out for a VN yet. This is something you should plan out in your design so that you don't run into issues down the line.