SD-Access and multiple DHCP and DNS setups

[bfbcnet]

Hi,

I am a bit stuck with DNA-C and the interrelation of DHCP and DNS settings in different areas of DNA-C. We mainly segregate our network between Corporate and Guest Traffic as a gross simplification. This is our main VN segregation. We have separate 'shared services' for our Corporate and Guest Traffic. That is our Corperate devices get their DHCP and DNS from different servers to where Guest devices would get them.

I know that these settings can be set up very specifically in the IP Pools for DHCP servers at least and then rely on the DHCP servers to assign appropriate DNS settings to the clients.

The problem is that I believe you have to set up at least DHCP servers in the Design / global / network - settings for them to be available in the IP pools section.

This gives a problem to our WLC setup as the WLC then gets all DHCP and DNS servers set globally for all SSIDs and also put into any pre-auth ACLs for guest portal setups.

If there was a way of not setting these bits up in the network setting area, would that not cause an issue with, say, the DNS setup on the switches themselves?

Basically, I am trying to work out how they have separate DHCP and DNS setups on our switches, WLC's, vs our Corporate Devices, vs our guest devices. I have been struggling to find any great documentation that explains each area's relation. Just documents that say here is where you add a DHCP setting without context of the effect that setting will have.

[andy!doesnt!like!uucp]

Hi
"The problem is that I believe you have to set up at least DHCP servers in the Design / global / network - settings for them to be available in the IP pools section."
i've just added random IP as DHCP server in IP-pool in lab. it hasnt necessarily to be in network settings / servers section.

[andy!doesnt!like!uucp]

going further with this i've noticed that Fabric reconfiguration is needed for the switch reprovision to pass w/o error (now idea why it's like this but in deployed config preview there were nothing useful or new :0)
but now i could reprovision the switch with target anycast SVI updated with new ip helper. interesting was in the   deployed config preview there were nothing about provisioning SVI with new helper :0)
i discarded reprovision & just resynced switch. after this i found SVI updated with new ip helper.
Thus recap is: u dont need to configure all DHCP servers in the Design/NetworkSettings/Servers to be able to use DHCP of your choice under arbitrary IP-pool 

[Boort]

The DHCP servers under network settings is just made available for you to select during IP scope creation. No config to my knowledge is pushed to your switches and WLC if you just add DHCP servers to network settings.

DNS under network settings gets applied during provisioning. Think of this as "system settings"

DNS under ip pool does not actually do anything to my knowledge. I suspect that it is there for IPAM integration reasons.

So, just add all the DHCP servers you need to global and apply as needed to your IP pools. For DNS you can go to the site you want other settings for and disable inheritance. Then you can define whatever you want.

Another option if you are not planning on doing SDA is to just add the WLC to inventory and to assurance only. This way you manage the WLC the old-school way so to speak.

If however you are planning on doing fabric wireless you need it managed from DNA center. But you would also need to do away/modify your wireless setup to work in a "flexconnect" way since fabric wireless is basicly flexconnect with VXLAN

[bfbcnet]

Thanks for the responses.

So, to give a bit more detail about our environment:

-Some sites are fabric sites, and some that are non-fabric but with AP's that are managed by DNA-C

-All sites are within located not too far from each other, so the largest site-to-site latency is about 15 ms.

-We have around 100 AP's.

-Due to the above we are using a single active and backup pair of WLC's to look after Fabric and Non-Fabric AP's using different DNA 'Network Profiles' for each site type.

-For our non fabric AP sites, the clients should be getting their DHCP via a broadcast to the gateway-providing device. 

Our experience of the behaviour of the settings global / site network settings areas.

For DHCP settings, anything set is added as IP helpers to all non-fabric physical interfaces / vlans that are set up on DNA-C and pushed out to the WLC's. This means the clients are looking at the wrong place to get DHCP.

Also, all these DHCP servers are added to any default or manually set-up Pre-auth ACLs applied to Guest portal authentication schemes, for example.

For DNS network settings:

Gets added to switches as the DNS to use for their self-originating traffic.

Gets added to all Pre-auth ACL's on the WLCs.

We did some testing for others' feedback. So yes, you don't need to have the DHCP config in the global / site settings areas to have them in the IP pools. As such, the site config for DHCP seems a bit pointless unless it has a non-SD-A purpose. It is probably what has already been covered above for our WLCs that is counterproductive for us.

So, we will remove all DHCP settings from the Network settings area unless someone has a warning about it breaking something we have not considered.

For DNS, in order to keep the config for self-originating traffic on network devices, we may have to just accept these settings will get added to places it is not needed, like pre authorisation ACLs, etc.

[Boort]

No problem.

When you say fabric sites (plural), do you mean with separate border/control nodes for each fabric site, or one distirbuted fabric site? Keep in mind that you can only have one WLC manage one fabric site, not multiple.

Mix mode is sort of supported within the same fabric site. I have never tried to mix a WLC that is SDA enabled with non SDA enabled sites. I see no reason as to why it should not work, but i would still try to stear clear of it to keep a clean line between SDA and non-SDA sites. With the amount of access points you have the Catalyst Embedded WLC sounds perfect for your SDA sites to be honest.

Which DNA Center version are you running? Im on 2.3.5 and i can not add "free-hand" DHCP servers to my IP pools.

As for your guest and pre-auth acl issue, i had that one as well so i created a custom one with CLI tempaltes and used that one instead. Works better for me.

But yeah, i think you should look into eWLC for your SDA site(s). This would solve a lot of the problems you are facing i think.

---

[bfbcnet]

For the sites it will be a mix of a distributed fabric and some fabrics in a box, with the 9k switch doing that also being the eWLC for that site.

I thought eWLC outside of SD-A had annouced EoL? So it would be no help for non-EoL scenarios.

Anyway, I think this is getting a bit of a topic with SD-A and non-SD-A being talked about. So, let me simplify the scenario. I am trying to understand how, via DNA-C, you can have different DHCP and DNS setups on a WLC whether SD-A or not. I don't think it is an out-there need to have different DNS and DHCP settings on, say, internal SSIDs vs Guest SSIDs.

I understand the templating option but that is defeating the object of having DNA's vs just setting the stuff up via logging into the CLI.

[andy!doesnt!like!uucp]

In terms of arbitrary user-facing SVI (anycast GW) DNS is something u define in DHCP-server corresponding scope (among with other parameters u want to communicate in DHCP exchange). ip-helpers though is something u define in DNAC for arbitrary pool. as declared previously it's possible to have them per-specific-pool customized w/o need to have all the DHCP-servers to be defined in the Network settings/ Servers part. no need in the Network templates also...  

[bfbcnet]

Hi, Thanks for the response.

The issue is that for pools, yes, you set DNS on the DHCP server. You do, though, have to put in DNA the DNS that devices it manages should use. This is the thing causing an issue, specifically with WLC, where it then conflicts with the DNS setup of guest setup as DNA DNS setup informs pre-auth ACL. This ALC then doesn't sync with what is on the DHCP server for connecting devices to use.

In the end, though, it seems that it means having to do more with CLI templates vs. via DNA managing the settings, which is not the best solution with what DNA aims to achieve (i.e., doing less via CLI config), but it just seems that is the current lay of the land.

Also, conflicts with DHCP setup when you use a WLC for both fabric and non fabric APs. However, this pain is not enough to justify the extra investment of having separate WLCs for one main fabric and for non-fabric APs.