Cisco SDA Part IX - need for duplicate IPs on fabric borders

Looking at the some of the configuration that is automatically pushed from DNAC, you should spot some very interesting things in there. This post aims to demystify these and help the reader understand why these were needed in the first place, hopefully giving you a better understanding of how the SDA fabric is built.


Let's consider the following topology for this:





Since a SDA fabric implements an anycast gateway type SVI across all edges, you would see the same IP address to SVI mappings created on all your edges in the fabric. Interestingly enough, the same IP address is also mapped to a loopback interface on the borders of the fabric (one loopback on the border for every SVI created on the edge). Look at the following configuration snippets from an edge and a border:





Why do we do this? Remember when we talked about how DHCP works with SDA and the need for option82? Well, this ties directly into that (if you'd like to read that once again, here it is https://www.theasciiconstruct.com/post/cisco-sda-part-viii-dhcp-challenges-in-sda). In that post, I stated:



"And here's the second major problem that DHCP needs to deal with in SD-Access - this 'giaddr' address is essentially the interface VLANs IP address, which (as you might have guessed it) is the anycast gateway IP address across all Edge's. Essentially, the same VLAN and IP address mapping will exist across all Edge's. How can the DHCP offer be directed to the Edge that actually sourced the DHCP discover?"

The answer to this was given slightly later in the same post. For ease of reading, here is a direct quote from the post regarding how this works:


"So, when this offer hits the Border, it is leaked to the CPU and this RLOC + VNI information is extracted from option82."

However, I did not explain the little configuration "hack" that was done to make it leak to the CPU. When the DHCP offer comes back from the DHCP server, the destination IP address is the anycast gateway IP address. If this is not created on the border, how else would it leak the packet to the CPU and allow for DHCP snooping to process this and interpret the option82 data?


So, there you have it - the reason DNAC pushes /32 loopbacks to the border with the same IP address as your anycast gateway IP addresses is to allow for the DHCP packets to leak to the CPU for processing of option82. The packet is then rebuilt and sent towards the appropriate edge switch.


A second, equally interesting bit of configuration lies within the LISP and BGP sections of the border.


On the border, apart from configuring these /32 loopbacks with the same IPs as the anycast gateway IPs, we also advertise this into BGP:





What is odd about this is that we're redistributing LISP into BGP already. This implies that my /32 LISP host entries in the server cache will be pushed into the BGP table and aggregated out to the peer anyway. So, what purpose does this very specific network statement serve?


Well, consider a scenario where there are no hosts in the fabric at all. The first host connects to the network and tries to get an IP address via DHCP. At this point in time, will there be any entry in the LISP database? No - because the host doesn't even have a valid IP address yet.


Naturally, the redistribution of LISP into BGP is useless at this point in time - there is nothing in the LISP server cache to redistribute. Because of this, the packets that come back from the DHCP server will get blackholed eventually - the upstream router (from the perspective of the border) will have no route to the anycast gateway IP address.


This is why a manual network statement is needed to advertise this anycast gateway IP to the outside world.


Interesting little tricks, innit?

For any queries, concerns or conversations, please email contact@theasciiconstruct.com