ISE SNS 3595 ARP Cache limit if any?

[Grendizer]

Hi,

We have a customer that will deploy CWA for them in dual home setup (different cables/connections to DMZ and Internal network) and for easy setup and managing is asking us to put the PSNs DMZ connection in the same guest /16 network (instead of creating smaller subnet for ISE nodes) anyway, all this will work but not sure if we have ARP cache limit? If so, what is it since I searched all ISE Docs couldn’t find any reference to that. If we don’t have a limitation then I just want to confirm this will work without problem or at least confirming configuring ISE PSNs in the same guest /16 network will not have any impact on ISE.

Thanks,

[RichardAtkin]

I don’t know the answer, but it just being a /16 won’t be an issue, it’s the number of Clients in the subnet that need to talk to ISE.

Are we talking tens of users, or tens of thousands?

[Grendizer]

Thanks Richard, what we usually do is to configure ISE nodes with small subnet on the DMZ and another small subnet on the internal network but with this request we need to configure ISE nodes on the DMZ side with the same /16 guest client subnet which we have to consider tens of thousands of clients

[RichardAtkin · Accepted solution]

Fair enough. Like you I’m not sure if it’s actually an issue or not, but assuming it is, why not put the ISE in a logically different DMZ than the Guests, that way everything can still be anchored, but as it’s Routed to ISE instead of L2 you won’t have any ARP cache concerns.

[hslai · Accepted solution]

I agree with Richard's comments.

Recent ISE releases are running on a OS based on RHEL 7 so the ARP thresholds are the same as stated in CentOS 7.0 - man page for arp (centos section 7) - Unix & Linux Commands and are not configurable. Thus, I would expect it an issue with more than 512 clients connecting within a short interval in the same subnet as ISE.

[Grendizer]

Thanks you both Richard and Hsing-Tsu, I think we have to go with this route then…Thanks again…

[paul]

Also something else to consider if the customer has no VM resource concerns.  You could have two dedicated guest VMs sitting in a separate DMZ with only a single interface.  Those VMs don't need to be domain joined and they don't have a direct leg into the internal network.  You just need to open the FW ports to allow them to join the deployment, receive RADIUS requests from the WLCs and portal traffic from the client.  This is my default setup for customers that want to put guest portal presence in the DMZ.