SD-Access - Overlay subnet size (one large subnet or multiple subnets)

[HNETENG]

Dears,

       in SD-Access technology, if I want to reserve an IP range subnet for Employees_Data for example in a network which consist of 10 of switches stacks (Edge nodes) that are connected to two collapsed (Boarder / Control ) node. shall I reserve on the SD-Access a single IP subnet of size /20. or i shall reserve multiple of /24 (for example qty 16 of /24) to have small broadcasts domains.

which option to follow form below:

Option A:  reserve single large IP subnet of size /20 to address 4,094 hosts. 

1- EMPLOYEE_DATA 10.0.16.0 / 20

OR

Option B:  reserve multiple of IP subnets (Qty 16 of subnet size of /24 to reach total client of 4,094). 

1- EMPLOYEE_DATA_1 10.0.16.0 / 24

2- EMPLOYEE_DATA_2 10.0.17.0 / 24

.

.

16 - EMPLOYEE_DATA_16 10.0.31.0 / 24

BR

[balaji.bandi · Accepted solution]

Since SD-Access uses anycast gateway, /20 is the good option, until you have any reason each building need to get different IP

i suggest to plan bigger subnet looking future requirement (changing this is pain) since its RFC 1918 address i go with higher address space like /16

[HNETENG]

So, the size of the subnet doesn't matter since we have anycast gateway. So, even we can reserve a subnet of size /16 for any systems such as Data Subnet. right ? 

[balaji.bandi]

There are some guide line to be minimum subnet should be used.

sure /16 you can use for any service ( as long as they are not overlapping)

some guide line i have attached for information.

[HNETENG]

So, referring to page (16) in above attached file (CX-DNAC-IpAddressWorksheet_v2.pdf) can I instead of below way of segregating the network into multiple networks 1,2,3 and 4 in the same site (site 1) of multiple /24 as below:

- Wired Client (Network 1)  / 24  (Site 1)   172.48.101.0/24

- Wired Client (Network 2)  / 24  (Site 1)   172.48.102.0/24

- Wired Client (Network 3)  / 24  (Site 1)   172.48.103.0/24

- Wired Client (Network 4)  / 24  (Site 1)   172.48.104.0/24

 to make it a single subnet /22 in a single (site 1)

- Wired Client (Network 3)  / 22  (Site 1)   172.48.101.0/22

[M02@rt37]

@HNETENG,

Yes, that's correct. When using an anycast gateway in a network, the size of the subnet becomes less critical for host communication, as long as it provides the necessary address space for your current and foreseeable future needs. An anycast gateway allows multiple gateway devices to share the same IP address, so hosts can use the same gateway IP regardless of which gateway device they actually use for routing.

Therefore, you can indeed reserve a subnet of size /16 for your Data Subnet (or any other purpose) in an SD-Access network if it aligns with your addressing plan and scalability requirements. This approach provides ample address space for hosts within the subnet, and the anycast gateway ensures that host traffic can reach the appropriate gateway device. By choosing a larger subnet, you reduce the chances of running into address space exhaustion issues as your network evolves and grows. It also simplifies IP address management and minimizes the need for frequent subnet adjustments, which can be a complex and disruptive process.

[Preston Chilcote]

My understanding is that there's a more important factor than anycast gateway.  L2 Flooding.  SDA by default disables flooding which means you can make subnets bigger without worrying about all the broadcast traffic that can come with that.

https://www.cisco.com/c/en/us/td/docs/solutions/CVD/Campus/cisco-sda-design-guide.html
"Reduce subnets and simplify DHCP management—In the overlay, IP subnets can be stretched across the fabric without flooding issues that can happen on large Layer 2 networks.  Use fewer subnets and DHCP scopes for simpler IP addressing and DHCP scope management.  Subnets are sized according to the services that they support, versus being constrained by the location of a gateway.  Enabling the optional broadcast flooding (Layer 2 flooding) feature can limit the subnet size based on the additional bandwidth and endpoint processing requirements for the traffic mix within a specific deployment."