SD-Access Routing Gotcha: Heads Up!
I recently heard about a gotcha with underlay routing for SD-Access. I’m posting what I know about it in the hope it will save readers some time and head-scratching.?
TL;DR?If you manually deploy an underlay or use a prior routing design and then migrate to SD-Access, route summarization can break SD-Access that is based on SDA Transit.?
SD-Access with LISP Pub-Sub (and maybe/probably non-Pub-Sub) doesn’t work if you summarize underlay prefixes in your IGP. The apparent specific issue is that the underlay loopback 0 IP’s are key items as LISP tunnel endpoints that must be visible in routing.?
My guess is that LISP is checking the routing table for each tunnel destination as a clue to reachability. I don’t have a lab to check this out.?
Note that there is a documented caveat about the prefix for your wireless controller specific subnet being visible in the routing table for WiFi to work, which may be a related type of checking in DNAC.?
(Disclaimer: I’ll note that I ramped up on LISP years ago for a complex HA customer design, spent some quality lab time with it, and have forgotten most details due to lack of use. That included two weeks of Northern Virginia Cisco lab just when Cisco laid off most of the LISP team. You probably don’t want LISP forwarding stuff to a tunnel endpoint that isn’t there, and so checking is likely built in, I just don’t recall for sure.)
The Back Story
What NetCraftsmen is seeing some of is the following scenario.?
Budgets and staffing and COVID delays can lead to equipment refreshes, where the priority is getting the equipment into use. Once migration is done and stable, attention then turns to migrating to SD-Access, DNAC for automation, etc. And at any scale, SDA Transit is a lot simpler to deploy than VRF-Lite everywhere.?
If you’re in that situation, the logical thing is to “redo L2/L3 and routing the right way.” Where “right way” for some of us includes scalability based on summarizable addressing and routing summaries.?
Testing revealed that making an SD-Access site a non-OSPF backbone area worked. That includes having the multi-site TCN and overall egress border node prefixes in local routing.??Whereas making the test site totally stubby did not.?
By the way, my clandestine source (thanks!) tells me the DNAC GUI will happily provision a fabric site with no error messages or other GUI indications of a problem. But try pinging to the datacenter or another fabric site, not so good!
I did extensive google and Cisco search, but didn’t find the topic easily. Eventually I found the one link below, not on Cisco.com.?
The lack of explicit cautions such as this blog may be related to the fact that DNAC by default deploys IS-IS routing protocol, no summarization.?
领英推荐
Links
https://www.dclessons.com/sd-access-overview?says underlay loopback /32's need to be explicitly advertised for SDA. It doesn't say why.
Conclusion
FWIW, in general I’ve had really mixed luck using google search to find cisco documentation content. When needed, I used to be able to find IOS and IOS-XE switch CLI commands in most cases. Problems arose when the Cisco feature name diverged from what I would have guessed.?
SD-Access and DNAC topics come up pretty well in search, but a lot of what comes up is a bit general, lacking in fine details. E.g. I can find documents on how to use the DNAC GUI to do it the “official” way, but not other underlay routing, nor caveats.?
Tenative conclusion:?From the above and some other experiences I’ve had, Cisco’s documentation staffing may have become leaner in recent years.
Gratuitous Advice:?You may avoid snags like this by following the documented deployment paths, and maybe have a conversation about any proposed design with the Cisco account team.?
Thanks to the NetCraftsmen-ites who shared this with me and labbed it, also for not using four letter words!
Comments
Comments are welcome, both in agreement or constructive disagreement about the above. I enjoy hearing from readers and carrying on deeper discussion via comments. Thanks in advance!?
Twitter:?@pjwelcher
LinkedIn:?Peter Welcher
Mastodon:?@[email protected]