Deploying TrustSEC into a Production Network

[mbowyer]

All, I have a customer with a fully operational 802.1x network using ACS as the AAA. We are converting to ISE2.1 and they wish to also implement TrustSEC. Each closet has one or two Catalyst 4506 switches with Sup8-E, and all support in-line tagging. Given that in-line tagging changes the Ethernet header type, how do we perform a "phased roll-out" of TrustSEC or must we enable support for in-line propagation on every switch in the facility during a single (very long) maintenance window? Each 4506 is a layer-2/3 boundary and routes traffic to a central Catalyst 6509, so would SXP be the way to propagate traffic between the "edge" 4506 and the core 6509? Seems like in-line would be the better choice but I can't see anyway of implementing in-line in a phased approach.

[arohyans]

Inline tagging would be the preferred option as this traffic is processed within hardware (which maintains line-rate performance) - alleviating CPU involvement. SXP on the other hand, being a Control Plane protocol, will chew up CPU cycles depending on how many tags you are propagating back and forth and how often. Generally, this doesn't affect the Data Plane, but can impact other Control Plane functions of the switch.

That said, going back to your question, there are a couple of different ways to skin this cat. My recommendation is as follows. To start with, no, you don't need to enable inline tagging globally... in fact, it's best to start small and localized. Since your C6K is aggregating all of this traffic, your first option could be to just enable inline tagging on the downlinks to specific closets (and conversely, uplinks from the C4Ks). This will allow the C6K to glean edge tagging information in-band. From there, you can peer the C6K with ISE via SXP to glean tagging information on the rest of the network out-of-band. You would still enjoy the benefits of intra-VLAN/closet segmentation while allowing the C6K to perform inter-closet segmentation using a mix of SXP and inline tagging. Inline tagging-learned tags will trump SXP-learned tags. Thus, as you schedule new maintenance windows and enable inline tagging deeper within your network, the propagated tags from these newly enabled segments will supersede the SXP-learned tags from ISE... eventually negating the need for the peering.

Hope this helps!

Aaron

[mbowyer]

Aaron,

Thank you for your response... since you specifically mention scheduling new maintenance windows, I guess I am correct in that to configure in-line propagation between the edge switches and the 6509, I will have to configure "cts manual", which will cause a temporary outage until I get the psk entered on both ends of the link (C6509 - C4506)... fortunately, both devices are in the same building, and if I team up with a co-worker, one of us can be on each device, reducing the potential outage to a minimum. Still an outage, but it can't be helped if we want to take advantage of the hardware processing on the equipment that can support it... Or, am I still confused?

[Mark Sturtevant]

Based on my experience deploying SGT Tagging in production it's always best to start off starting with a single non-seed device (access-switch) and one seed device (core/distro) and ensure authentication and traffic flow is working to include egress restriction.

[arohyans]

Nope - you got it!

Yes, you can expect a brief disruption when you enable 'cts manual'.

Are you planning to run MACSec encryption on your uplinks/downlinks? If you're just preparing to send/receive SGTs for TrustSec, you don't need a PSK on either end. Just enable 'cts manual' and setup your propagation policy:

interface GigabitEthernet1/0/1

  cts manual

    policy static sgt 2 trusted

The policy above dictates the following:

• The peer switch is statically authorized (as opposed to dynamically via 802.1X)
• SGT 2 will be assigned to traffic that enters the switch without a tag
• Incoming tagged frames will be trusted rather than remarked

...and yes, if you have a co-worker at the other end it will make the change go smoother

Aaron

[mbowyer]

Aaron,

Well, you are officially my TrustSEC Hero! Many thanks, especially regarding the MACsec portion (which we are not planning on implementing, thus saving me from the extra configuration). In one sense, the documentation seemed to reference the CTS manual/dot1q configuration only when referencing MACsec, but then mentioned that "cts manual" was needed to enable propagation (therefore, needed whether doing MACsec or not)... very confusing. Thanks for clearing that up for me. However, I will likely not apply the "static SGT tag" (similar in function to native VLAN setting on trunk ports), since I'll need untagged traffic to remain so until the client settles on a full categorization plan. As it is, SGT 2 is currently assigned to Network Access Devices (default value in ISE 2.1), although I'm sure your suggestion was just meant to be an example. Again, many many thanks for the assistance.

Mike

[arohyans]

Great! Glad to help!

Yes, the documentation on TrustSec/MACSec can get a bit confusing as to what does what and what's needed for each feature. You are correct on SGT 2 - I just used it in my example, but you can pick anything you want. It very much compares to the 802.1q Native VLAN, even from a security perspective (i.e. don't use the Native VLAN for data transport and change it from 1 to an unused/restricted VLAN). In a TrustSec mindset, you may want to use this feature similarly as a bit bucket or quarantine tag. That way, if any rogue infrastructure devices pop up on the network and start sending traffic, they (and their traffic) will be properly segmented.

Hope this helps!

Aaron