SGT inline propagation through L3 (Po) subinterfaces

[Gustavo Novais]

Hello,

At a customer we are planning to deploy trustsec in a hub and spoke campus topology.

The hub would be  a VSS pair of 6807 and the spokes would be 3850 stacks.

we have multiple access vlans mapped into VRF's into the 6800 and for some specific vlans we'd like to use SGT and SGACL to microsegment some of the access vlan traffic.

The question I'd like to ask the community is:

- can SGT inline propagation be done between a L2 Port-channel trunk interface (in 3850) and a L3 port-channel with subinterfaces (on 6800)? either Manual or dot1x mode would be acceptable  (even though I think dot1x would not work as the uplink 6800 side is not a L2 port with 802.1X authenticator capabilities).

- just by curiosity, would macsec encryption work in this uplink scenario?

- If we do SXP SGT propagation between the 3850 and 6800 (if inline tagging is not possible), would the SGACL be applied on the traffic being routed inside the same VRF?

- we will need to fusion the VRF's sending traffic through a non-cisco firewall. Obviously the SGT tag would be dropped on traffic egress to firewall, so we'd need SGT mapping in ingress anyway. is the SGT space VRF aware (one SGT table per VRF) or box aware ( a single SGT table per box).

Any insight regarding the possibilities of 6800 on this are most welcome.

Thanks and regards

Gustavo Novais 

[jeaves@cisco.com]

Hi Gustavo,

yes, inline tagging between a 3850 stack and the 6807 is supported. If older Cat6k's are also deployed then ensure the Supervisors are either a Sup2T or Sup6T (Sup720 does not support inline tagging). Trunk to sub-interface port-channels is ok; just makes sure the 'cts manual' command is on the member interfaces, not the port-channel interface.

I say 'cts manual' as dot1x isn't particularly recommended.

I don't see why MacSec shouldn't work.

SXP is VRF aware. So there is an SXP dB per VRF (show cts role-based sgt-map vrf x all). If using SXP then the SGT isn't passed in the packets therefore routing to a FW isn't an issue. If that FW happens to be CheckPoint then that does actually support TrustSec as we have been working with them to implement it (I don't have HW or SW requirements for that).

Regards, Jonothan.

[Gustavo Novais]

Hi Jonothan,

Thank you for your answers. It is very hard to actually find any documentation that mentions the case of L2 trunk to L3 subif with inline SGT.

As soon as we get the material we'll be testing all of this out.

Regards

Gustavo

[jeaves@cisco.com]

Please post the results/config here so we can all learn from your experience.

Thanks a lot.

[Gustavo Novais]

Hello all,

so first feedback from the scenario described above.

everything seems to be working at this time - SGT propagation as well as SGACL

we were just interested on the SGT propagation and not in macsec (and for the moment SXP is not yet under scope).

The scenario we had was simply a pair of individual 3850 dual connected with a portchannel to a pair of 6800 (sup6T) in VSS.

from the 3850.

The 3850 uplinks are L2 802.1Q trunks in port-channel and the 6800 interfaces are L3 interfaces aggregated into a port-channel. Each 802.1Q Vlan leads to a Port-channel subinterface.

The CTS configuration is done on the physical ports of both devices (both sides CTS manual). The portchannel and its subinterfaces have nothing particular to configure.

Lessons learned:

- 3850 (in IOS 16)

--for the uplink SGT propagation only CTS manual mode is supported. no need of SAP-PMK key. simply static sgt policy for switch originated traffic.

--if doing monitor capture of 3850 uplink traffic it looks like the monitor session is capturing traffic before tag is imposed on the outbound direction. Don't be alarmed if captures do not show CMD header in outgoing packets of switch.

--SGACL counters. Before version 16.6.1 there's a bug that prevents SGACL counters to be displayed. Tests in 16.6.3 show that that is fixed - version 16.6.3 seems stable for 3850.

--CDP - apparently there were quite a few changes on CDP processing between IOS 3.6 and 16.3 and 16.6 and a few bugs related to them. Currently 6800 does not receive or is able to process CDP packets coming from 3850, which is odd. We added the native vlan into trunk, but no change. LLDP, LACP, UDLD work fine.

-- troubleshooting

---- do use netflow and other tips as per troubleshooting page here TrustSec Troubleshooting Guide (thanks Jonathan!!).

---- beware of new formats for IOS 16 for troubleshooting, do get familiar with "request/set platform software trace" and platform particularities.

-6800

-- beware of the command "platform cts egress" - requires reload - cannot use ERSPAN if command enabled.

-- do use netflow to troubleshoot/get an idea of where traffic is going.

-- if using management interfaces in VRF do not forget to add VRF binding in aaa server group as well as in aaa client dynamic authorization.

-ISE

-- study carefully the Live Log for CTS request and CTS events - Cisco Identity Services Engine Administrator Guide, Release 2.3 - Cisco TrustSec Policies Configuration [Cisco Identity…

-- if you get CoA NAK's from the 3850 when pushing SGACL's examine if there's simply nothing attached to that switch. If a switch doesn't need it, it won't download the SGACL

-- study carefully the syntax for SGACL. For debugging, remember that "log" is permitted in a SGACL. ISE 2.2 and 2.3 do not validate SGACL syntax.

I think that for the moment these are the lessons learned. Hope this may help someone.

Big thank you for the work that Jonathan is doing in maintaining the "troubleshooting trustsec" community page.

Regards,

Gustavo