TrustSec deployment in large environment

[john5]

Hi,

I have a large implementation of TrustSec micro-segmentation using ISE in a distributed deployment with 2 ISEs for PAN and 2 for MnT and centralized PSNs in multiple regions which will cover alot of branches.

I still need to understand more about the enforcement of TrustSec

Q1:

if there an employee in BR1 and another one in BR2 and my policy says that employee tag can't talk to another employee tag "regardless of their IPs".

so my question if we assume that we let the core switches at every BR do the enforcement , how does this switch know that the destination tag is for employee , is it will be IP-SGT mapping enforced by ISE ? if yes what if I have a large number of branches "more that 1000" should i send all employees IP-SGT mapping to each core to enforce the policy ? is there any other solution ?

Q2:

Is there any tool to calculate the WAN traffic needed between PSNs and the switches in the branches ?

Q3:

Does anyone know if Viptela SD-WAN solution will allow propagation for SGT from branch to another one without any problem ? "I know it will but i want to make sure if someone face that scenario"

Thanks in advance.

[ngriffin@bankozarks.com]

I'm not sure I'm following you completely, still digging into the technology a bit. To clarify currently I have a similar setup in a lab as you described, in that I have ISE configured to be a speaker to a nexus switch that is then a speaker to the access layer 9300 switches. The Nexus learns the dynamic mappings from the auth sessions via SXP and then the 9300 learns the static ip->sgt mappings via SXP from the nexus reflector(s), in addition to the local dynamic mappings. What I am trying to do in the short term is keep most of the SGT configurations on the 9300's versus the 4k routers since they technically will be replaced with sd-wan devices, I don't want any dependencies on the wan routers that drives the code version I deploy on the sd-wan boxes, at least not initially. 

[Damien Miller]

The only reason I suggested leveraging WAN edge was because it would fewer SXP connections than going to each access switch which can be a scaling issue. Total mappings support on the Cat 9k's is also quite limited, they can only handle 10,000 IP-SGT mappings where as an ISR can support 125,000+. It sounds like you have a fairly large environment, so 10k mappings could easily be a scale issue.

I would want to inline tag everything in the LAN to enable east west enforcement anyways. You would be dealing with fewer connections and no inline tagging work to add in for the future state. When (if) SDWAN ever supports native SGT inline tagging, then you would still need inline tagging in the LAN up to the router, you would just be dropping the SXP connections on the router when moving to SDWAN inline tagging. I have not spun up the SDWAN code on an ISR, but I know the commands are there for inline tagging, not sure if SXP is still in there, I would want to go this route if possible. I haven't tested it on SDWAN code, but after this discussion I think I will when I get time in the next couple of weeks.

Your understanding of the mapping flow sounds correct, ISE will speak all static mappings you manually create as well as dynamic mappings created during authorization. It is a single point of truth for all IP-SGT mappings regardless of how they are generated, unless manually tagged on NADs.