SXP Domain Filters vs. SXP Deployment Scaling

[Krzysztof Grabowski]

Hi Guys,

We are considering a Hybrid deployment with 4 nodes: 2 x unified PAN+MnT (SNS-3695) and 2 x PSN+SXP (SNS-3595). According to ISE Perf&Scale this deployment could scale up to 10K IP-SGT bindings maximum: 

In our case we'll have 20K+ endpoints and the goal is to publish only a subset of RADIUS originated IP-SGT bindings via SXP to remain within supported 10K+ (for example publish only a couple of subnets with total of 5K bindings). 

The challenge I see here is that "Add radius mappings into SXP IP-SGT mapping table" options enables all RADIUS IP-SGT bindings to populate "default" SXP Domain with 20K bindings... 

The idea to overcome this issue is to configure a non-default SXP domain "PARTIAL_DOMAIN" with SXP Domain filters to populate this domain with a subset of all bindings - say 5K only. All SXP peers (listeners) would be configured in "PARTIAL_DOMAIN". Effectively "PARTIAL_DOMAIN" with its SXP peers would contain supported number of IP-SGT bindings ~5K. The "default" SXP domain would be populated with the remaining 15K, however would not participate in SXP exchange with external devices. 

• Does such configuration satisfy the 10K limit of considered deployment? 
• Do IP-SGT bindings in non-used SXP Domain ("default") affect scaling in this case? 

Cheers,

Chris 

[hslai]

No and yes.

As Joff explained, the ISE scale numbers are global for the whole deployment with all mappings. The filtering will only help with the peers that receiving the mappings.

[Damien Miller · Accepted solution]

I want to point out that those numbers are for 3595's and not 3695's, looks like the scale wasn't tested with new appliances. That aside, it seems kind of odd that we wouldn't support total ip-sgt bindings at the same scale as active endpoints. I've never actually looked at that from a scaling perspective, our issue has never been with ISE handling the bindings, rather overloading network device CPU or running out of memory. Strong argument for inline tagging across the WAN.

[Krzysztof Grabowski]

Thanks Damien!