Port Assignment for non-SDA VLANs

[Sylvain_Che]

Hello,

In our SDA Fabric, we deployed some switches without LAN Automation. This manual underlay is built using SVIs and the Fabric Edge uplinks are L2 trunks.

On those switches we are carrying non-SDA VLANs, with default gateway being located outside of the fabric.

We configured the client-facing switchports as Access or Trunk via CLI to assign non-SDA VLANs. All was working fine for more than 4 years, no complain from CatC/DNAC.

But recently, after pushing a Fabric Fix update (banner appearing in Fabric Site page), DNAC reconfigured some of those switchports to inherit the Global Authentication Template as defined in Fabric Site/Port Assignment. Hence it removed our manual CLI config.

I understand the "intent configuration" defined and pushed by CatC, but I'm wondering how you manage such non-SDA VLANs in a Fabric environment?

Using L2VNI for those non-SDA VLANs is by nature not possible because of the L2 trunk uplinks (that would cause L2 loops otherwise). Using template or EEM script is a possibility to re-enter the correct configuration in case CatC overrides it but it would always be in reaction of CatC action. The only possibility I see so far is to remove those special switches from the Fabric, use them as traditional switches, and make use of L2Border in case a VLAN/subnet needs to co-exist between both traditional and SDA worlds.

I understand that in CatC 3.1.x, it will be possible to define client-facing trunk ports with non-SDA VLANs, but it looks like there is no plan for access switchports...

Regards,

Sylvain.

[Andrii Oliinyk]

only after looking on your diagram i understood why u concerned of L2-loops. but with trunking arbitrary non-SDA VLAN across ethernet rectangle like yours, wouldnt u expect that STP will block some port for this VLAN or u dont run STP for this case? :0)
i'd say u, Guys, went too far beyond acceptable level of mixing legacy R&S with LISP/VXLAN...

[Sylvain_Che]

STP is not my problem here. STP is running fine for these non-SDA VLANs. L2 Loops would occur if L2VNI were deployed to accomodate those non-SDA VLANs.

My concern is about Port Assignment and CatC erasing our manual config.

[Andrii Oliinyk]

"L2 Loops would occur if L2VNI were deployed to accomodate those non-SDA VLANs." - why it would considering u added L2BN role to one of your BNs & made L2HO (to FN in your case)?
"My concern is about Port Assignment and CatC erasing our manual config." - i'd predict u will meet other unpleasant artifacts if u dont escape from this design. Sometimes "unsupported design" it's not only about vendor doesnt like it. 

[jedolphi]

Two separate problems here. 1. Can we move the L2 segments into SDA, why would there be loops? 2. The update logic that broke your ports. For #2 I'll need to do some research and get back.

[Andrii Oliinyk]

for #2 i woudnt even expect something different from CatC rewrote ports assignments with default configuration (i'm pretty sure their non-SDA-VLAN ports are like this in CatC) according to configuration kept in CatC's DB. from other hand, they would leverage DayN templates bound to target ENs network profiles, but i'm still not sure that CatC automatically reprovision switches after "updating" Fabric, or this reprovision must be made manually after Fabric was updated. 

[jedolphi]

@Sylvain_Che , CatC should not be overwriting trunk ports, can you please open a TAC case for RCA? If TAC engineer needs details they can contact me. Thank you

[Sylvain_Che]

@jedolphi :

1. Some of the L2 segments cannot be moved to L2VNI or makes no sense to move them. And L2 loops would occur in current situation if we move those segments to L2VNI because the links between switches (Edge<->Border) are trunk links and those VLANs are carried in those trunks. Traditional L2 VLAN + L2VNI is not a good mix, I tested it in my lab.

2. CatC doesn't overwrite my trunk ports. It overwrites my access ports. TAC case already raised for this: there is no native and safe way to manage non-SDA VLANs in CatC without risking CatC to overwrite the access switchport configuration. EEM/Template can only be used as a reactive approach.

@Andrii Oliinyk :

For sure, this design is not the best but has been accepted and validated by Cisco some years ago.

[Andrii Oliinyk]

what i dont really get is that in your deployment VSL-based FN is basically SPoF for maintenance. So i understand your design to make non-SDA VLAN traffic highly redundant & that's why u avoided recommended configuration (stacked|VSL'ed L2BN handoff to FN). Ok, RPVST (i guess it's your case) will quickly converge in case of single BN or link or VSL-member failure. Ok, u r able to make independent maintenance for BN. BUT it's not a case for VSL'ed FN - u upgrade it & introduce significant downtime on non-SDA VLANs. 
Getting back to properly designed L2HO, i understand that SDA L2HO suffers from lack of design options from reliability perspective. But still you could use complicated EMM to automate switching between 2 L2HOs presumably made on each of your BNs toward FN (f.e. on your VSL'ed FN by continuously analysing states on the downlinks toward BNs & making corresponding decision on spanning non-SDA VLANs over them etc). (Remark: only syntheticless & still HA L2HO i'm aware off is L1-2 adjacency with platform implemented in Active/Standby mode e.g. A/S FW).
In summary, staying with recommended L2 EID space termination would give you more protection from interference between SDA & legacy L2 switching.

[jedolphi]

Hi Sylvian, more discussion/detail required on point 1, wont solve in this in a back and forth forum. You may well be correct, but for us to get on same page a detailed discussion is required.

For point 2, please "Make a Wish" in the CatC UI and explain the situation, I think perhaps we could have an option to ignore custom ports. Also, in CatC, if you could test setting the port to "none" authenticaiton template and dummy access VLAN, then overwrite with your specific VLAN requirements. Or go with EEM.

[Sylvain_Che]

@jedolphi :

Sure, I'll contact you privately.

Make a Wish already sent, and the 'None' authentication with dummy template already tried. It works until CatC pushes again its Intent-based configuration, defined in WebUI.

@Andrii Oliinyk :

The full picture is not shown here. We have a 2nd Fusion SWV, and we also have redundant L2Borders as well.

I agree with you, and separating SDA and L2 switching is one of our options to avoid any interference. Today CatC is not ready to handle such case.

In short, I understand that there is no existing solution today for CatC to understand non-SDA VLANs in Port Assignment and that we have to manage it with some custom solutions and their associated risks. Easiest solution (might be only on paper based on our specific environment) would be to separate traditional L2 and SDA environments.

Thanks for your inputs.