CTS SXP design (no SDA)

[Johannes Luther]

Hi team,

let's assume I have multiple campus networks with tons of access and distribution switches.

I want to use SGT for different reasons. The SGT classification happens at the access layer via MAB or 802.1X (basically in ISE authoriization results).

Let's assume I want to use SXP for SGT propagaton. To be scalable, a large campus must make use of SXP aggregator devices, because the ISE only supports a limited amount of SXP peers, right?

So the idea is to use the core switches in each site as SXP aggregators (SXP listener and speaker). The cores have SXP sessions with the ISE.

=> Each access switch must have a SXP peering with the cores in their site.

Now the question: From a configuration and deployment aspect, this is a nightmare, right? If deploying a new access switch the SXP peer must be added at the core.

In BGP (route reflector) designs, there are concepts of dynamic BGP neighbors. So the neighbors are defined based on a range of IP addresses.

Question: Each SXP session between two peers must be configured on both ends of the session, right? So if an aggregation devices has 1000 SXP peers, there are at least 1000 configuration lines on the aggregation devices like:

cts sxp connection peer <PEER-1-IPv4> source 10.1.2.3 password default mode local listener [...]
cts sxp connection peer <PEER-2-IPv4> source 10.1.2.3 password default mode local listener [...]
cts sxp connection peer <PEER-3-IPv4> source 10.1.2.3 password default mode local listener [...]
...
cts sxp connection peer <PEER-1000-IPv4> source 10.1.2.3 password default mode local listener [...]

There is no other way to do it right?

From my point of view - from a dynamic configuration and deployment aspect, the only way is to either use:

- SDA (so basically inline taggin in VXLAN)

- inline tagging within a campus site in combination with SXP over WAN or non-CTS boundaries

- Use SXP propagation to ISE via RADIUS (not SXP) ... however, there is no SGT-to-IPv6 mapping support over RADIUS (CSCvn10038)

Are my assumptions correct or are there some fundamental understanding issues on my side?

[Damien Miller · Accepted solution]

As you have identified, SXP is difficult to scale, but not only from the configuration perspective, you also have limitations in the processing power SXP requires. Each platform will scale SXP and IP-SGT bindings differently and it has a huge range.  

In a SXP reflector design, your assumption about the number of peers is correct. You need a peer statement on both sides, speaker on one, listener on the other. I would not recommend bidirectional connections due to the scaling issues I've experienced with them. Also keep in mind that in a SXP reflector design, it's quite common to have redundancy, this doubles your peer count, connection count, and processing. 

The true scale of TrustSec in large environments is when you leverage CTS inline tagging and I would strongly consider avoiding SXP in the LAN except for points where it's not possible. SXP for the WAN is possible for small/medium deployments but there still comes a point where you start running in to issues, it can't compare to the scale of leveraging an inline tagging capable WAN. You already identified one potentially acceptable option, pairing inline tagging in the LAN, then ISE/reflector as the SXP speaker to the WAN edge.  

The best option when leveraging native TrustSec is to inline tag everything and use SXP as the last resort. 

[Johannes Luther]

Hi Damien,

Thank you for the answer and for confirming my assumptions.

It really bugs me that SGP propagation via RADIUS is not working for IPv6. I would consider this a scalable and viable approach without the need to do inline tagging. This would be great for scenarios, where classification happens at the access layer (via MAB, 802.1X) and enforcement is performed on central firewalls (e.g. towards the datacenter) (no enforcement in the Campus).

The only SXP session (or pxGrid) needed in this scenario is between the ISE and the central firewalls.

Why make everything so **bleep** complicated? :)

Anyway, thank you for your reply.