Trustsec third-party access switches possibility

[Maxim Bezzubov]

Hi guys I am planning for a Cisco ISE applicability in a new office. We are have the whole network core on Cisco, but access switches have bought Dlink :\. It is not a my decision, but now I have somehow dealing with it. I am not experienced in third-party switches within ISE deployment or dot1x infra itself. As far I know from datasheet those dlink switches supports 802.1x in a some way. I wanna to deploy ISE in the TrustSec way, but have a lot of doubt if It works? Could it SXP helps in that case, how SGT could apply on user access switch port in that way? Does anyone having experience in dlink integration with ise in the trustsec or basic 802.1x?

[Cory Peterson]

There is no way to do Trustsec on dLink at the port level. It is not supported and I doubt it will be any time soon. At this current time Only Cisco supports trustsec. 

As far as Validated 3rd party devices dLink is also not one of them, this does not mean it will not do standard RADIUS and 802.1x but it has not been tested with ISE. Also the features supported may vary. 

AS far as Trustsec, You could try and push the enforcement point further from the client but you need to verify that the devices further up support SXP and SGACL. 

[jeaves@cisco.com]

The way to use 3rd party switches for a Trustsec deployment is to utilise dynamic IP:SGT mapping and SXP on ISE.

As an example, see here: https://www.youtube.com/watch?v=QElQoY-dql0

As explained above, RADIUS authentication and accounting would need to be supported between the network access device and ISE to allow an ISE session to be created. If an ISE session can be created then an SGT can be assigned.

BTW there are some third parties that support TrustSec, for example CheckPoint. IETF drafts and code in git hub have allowed other well known vendors to produce code as well; customers speaking to vendors will help to push along the development.

[Maxim Bezzubov]

Hi

Thanks for youtube link you've provided.

But if access switches does not support SXP (because its Dlinks) how it would work? Per my understanding enforcement should be done from the access switch port with sgacl in,there isnt it?

I suppose if there are no trustsec in there only basic 802.1x with dacl or vlan on dlink access port could ve assigned, then IP to SGT mapping play in game, am I right?

[Cory Peterson]

Yes, enforcement should be at the port level. Seeing that is not supported with these access switches you can look at moving the enforcement point further up the stack be it to a switch that supports both SXP and SGACL or to an ASA/checkpoint that supports rules based on SGT. 

If you go down the route of dACLs you will most likely not be able to do this on the Dlink switches either as they will most likely not support this. Pushing dACLs/authentication to a port on the core switch could also cause issues as it may overload the TCAM on the switch. 

I would say your best and really only feasible option at this point it to run basic 802.1x auth. It is a bit disappointing that ISE was purchased and you will not be able to use the features due to the decision to roll out a switch that does not support the advanced features. I would be sure to relay that the DLink switches are a huge inhibitor to the goals/features when it comes to ISE as a whole. And hopefully in the future the whole picture will be looked at instead of just the cheapest switch that can be purchased. 

[jeaves@cisco.com · Accepted solution]

Hi Maxim,

hopefully you have watched the YouTube video. You'll see users on the AP being enforced by Trustsec for User to DC flows. The Meraki AP does NOT support TrustSec.

So, in your case, the Dlinks don't support TrustSec either (SGT assignment, SXP, SGACL etc).

The way it works is that users connecting to the Dlink instigate RADIUS requests to ISE. ISE is the device that assigns the SGT and ISE itself sends the IP:SGT mapping to a separate enforcement device via SXP. So SXP is only needed on ISE and the enforcement point, not on the Dlink.

Watch the video again, the AP in the video has nothing to do with TrustSec (and in your case the Dlink wouldn't either). It's the ability of ISE to receive a RADIUS request, map the learned IP to an SGT and send that mapping to an enforcement device over SXP.

I hope that is clear.

The caveat is whether the Dlink can send the correct attributes for RADIUS Authentication and Accounting in order to setup a session in ISE in the first place.

Regards, Jonothan.

[Maxim Bezzubov]

Hi Jonothan

Thanks for the comprehensive answer,

One more question. What is the enforcement device in the suggested scenario, if it not a core cisco switch or access dlink, ISE itself?

[jeaves@cisco.com]

No, ISE does not sit in the data path, it is just used for control.

Devices in the data flow path carry out the enforcement. FW's like the ASA and NGFW, switches like the 3650, 3850, Cat4k, Cat6k, Cat9k, N7kv etc and routers like the ASR1k, ISR4k and CSR.

The latest platform capability matrix is a good source of information:

https://www.cisco.com/c/en/us/solutions/enterprise-networks/trustsec/solution-overview-listing.html

[jeaves@cisco.com]

Just came across this item again by chance. Just to say that Meraki 802.11ac wave 2 and Wi-Fi 6 MR AP's do support TrustSec now, along with the MS390 switches. For details search for 'Meraki Adaptive Policy'.