SGT Propagation: Inline tagging vs. SXP

[Josh Morris]

First of all, I have a campus network entirely capable of running inline tagging. I'm wondering though, should I run SXP instead of inline tagging to get tags to my switches. The reason I ask is because I have had trouble getting the CTS commands deployed correctly and stable in my network. There have been quite a few cases where the CTS commands have caused traffic issues (particularly on my cores). In my Cat4ks, the interfaces have to be shut/no shut after adding the cts commands. I am running port-channeled uplinks on top of that, so I have to deploy the commands with an EEM script because otherwise I will get disconnected because the port-channel members will have inconsistent config. I have some cat9ks where this isn't an issue.

The point is that CTS manual has given me heartburn. Would it be easier/better to just run SXP from my access layer switches to ISE?

[Damien Miller · Accepted solution]

As you have observed, applying cts manual and it's subcommand will typically break a link until you get the matching commands on the other side. As you pointed out, this behavior can deviate a little and be inconsistent, but the expectation is that the link will break when you are applying it. It's also considered a best practice to shut/no shut any link you apply it to so you have to finesse it in to the config. 

SXP is a lot to manage, and it has it's own complexities and scaling limitations. If it was me, I would push through getting the inline tagging/cts manual working everywhere it is supported. I would only use SXP for specific enforcement points, ASAs, or across unsupported link.

You mention an EEM script, I've never done it that way but instead use text files and ftp to apply the config to remote switches. 

Process would go something like this

1. Generate a text file with the required configuration steps for the downstream device and save it as uplink.txt. At this time I would also generate a config file for the core since you need matching config for a working link. This would mean two file. 
   !
   int TenGigabitEthernet1/1/1
   shutdown
   no channel-group 1 mode active
   cts manual
   policy static sgt 2 trusted
   !!
   int TenGigabitEthernet3/1/1
   shutdown
   no channel-group 1 mode active
   cts manual
   policy static sgt 2 trusted
   !
   int TenGigabitEthernet1/1/1
   channel-group 1 mode active
   no shutdown
   !
   int TenGigabitEthernet3/1/1
   channel-group 1 mode active
   no shutdown
   !
2. Set a reload in 10 to allow recovery if something goes wrong
3. Disable UDLD if enabled or set the err-disable recovery timer to 30 seconds and the recovery cause udld commands
4. Copy the new uplink config to the downstream device with copy ftp://x.x.x.x/uplink.txt running-config. This will copy the file, then do a config merge. Pasting cts manual/policy static will usually just break the link and your ssh session with it while missing the policy static command. 
5. Apply the same configuration to the upstream device (usually the core)
6. Cancel the scheduled reload when you have access back.