Adding Stackwise Virtual Switch to existing SD-Access Underlay

[packet2020]

HI All,

I'm currently working on an SD-Access fabric that has been deployed using LAN automation. I need to add a layer 2 border to the existing fabric site that will be configured using stackwise virtual, but from what I understand by reading the LAN automation guide, Stackwise Virtual is not supported by LAN automation and will need to be configured manually.

How would I go about adding the Stackwise virutal switch to an existing underlay that has been configured using LAN automation? I beleive that I could allocate the p2p and loopback IP addresses manually from a range outside of the LAN automation pool, however what would I need to configure for the IS-IS net address as the current net addresses are automated? Is there a safe address range that I can use that wont conflict with LAN automation?

Thanks

[andy!doesnt!like!uucp]

For the new IP-addressing in the Underlay for /31 u can take whatever ranges. Only requirement they are unique within Fabric.
For the RLOCs u can do the same unless u need RLOC to communicate with host(s) outside the Fabric.
If latter is a case for u, be encouraged to inspect your LAN-A range on the ability to borrow 1 IP from there. 

[jedolphi]

Hi Andy, packet2020, please do not manually allocate IP addresses from LAN-A ranges. LAN-A keeps track of what addresses it has assigned and it will not read in configs from manually configured switches, this will create a conflict. Use IP addresses outside of LAN-A range for non-LAN-A switches. For the NET value on your manually configured switch, since LAN-A adjacencies are all L2 (please double check in your network, there is exceptions, but it's 99% true), then NET can be anything you want, IS-IS L2 adjacencies don't check NET. Don't configure a duplicate i.e. don't exactly match another switch in the IS-IS routing domain. Perhaps for intuitiveness try to reverse engineer the LAN-A NET, it's not to hard to work out. From memory is uses either the Lo0 IP address or a serial number from the switch (check show ver). Regards, Jerome

[andy!doesnt!like!uucp]

tnx. more accurately i ment following: 
1) to use for new IS-IS interconnects (/31) w/o LAN-A whatever unique range for specific Fabric & particularly to not use LAN-A pool for this. The reason is Fabric IS-IS interconnects not needed to be reachable from outside of the Fabric. & to not use LAN-A exactly by the reason u've mentioned.
2) "borrow from LAN-A" new RLOC means inspect your LAN-A pool, identify what has remained in LAN-A pool after last LAN-A, identify candidate IP in such a manner that LAN-A pool can be shrinked & still used in the future but will no longer contain RLOC candidate IP. 
do u know now what i mean?

[jedolphi]

inspect your LAN-A pool, identify what has remained in LAN-A pool after last LAN-A, identify candidate IP in such a manner that LAN-A pool can be shrinked & still used in the future but will no longer contain RLOC candidate IP

Understood. I don't think we can shrink an LAN-A pool that has been used since the IP allocation of a LAN-A pool is not linear. When a LAN-A pool is used for first sime it is subdivided for various functions e.g. DHCP, p2p links, loopbacks, etc.

[andy!doesnt!like!uucp]

gotcha... could u pls bring more details on structuring LAN-A pool by DNAC?

tnx in advance