Issue builiding a Trustsec Domain with CTS manual using 16.6.X code

[hsood]

Hi Team,

As we know that CTS dot1x feature has been decommissioned and we are going forward with "CTS manual" method for building a  trustsec domain from code 16.6.X IOS-XE onwards.

My query was, I was trying to build a trustsec domain between two Catalyst 3850 using CTS manual command and unable to do so.

Referencing the following doc for commands for CTS manual configurations:

https://www.cisco.com/c/en/us/td/docs/switches/lan/trustsec/configuration/guide/trustsec/command_sum.html#79442

My configurations are as follows:

LabAccessSwitch# sh run int gi 1/0/2

interface GigabitEthernet1/0/2

description Link to Edge Node #2

no switchport

ip flow monitor NETFLOW input

ip address 192.168.2.6 255.255.255.0

ip router isis

load-interval 30

carrier-delay msec 0

cts manual

isis network point-to-point

isis authentication mode md5

isis authentication key-chain IS-IS_INTERFACE

end

EdgeNode2#sh run int gi 1/0/12

interface GigabitEthernet1/0/12

description Link to Lab Access Switch

no switchport

ip flow monitor NETFLOW output

ip address 192.168.2.2 255.255.255.0

ip router isis

load-interval 30

carrier-delay msec 0

cts manual

isis network point-to-point

isis authentication mode md5

isis authentication key-chain IS-IS_INTERFACE

end

++ I have put in the "propagate sgt" command but it does not show up in the running-config output above.

++ I have tried put int the "sap pmk" command but the port would keep on bouncing between the two switches as SAP stays at negotiating phase.

++ I have attached the topology diagram to the post to have an understanding between what two devices I am trying to establish the trustsec domain.

Also , outputs of the following have been attached to the post as well for both the switches:

++ show cts policy sgt

++ show cts role-based sgt-map all

++ show authentication session int gigabit 1/0/X detail

++ Show run

I am unable to propagate the SGT from the source switch itself when I am trying to ping from the Host connected to EdgeNode2 Switch to reach out to another Host connected via the LabAccess Switch.

EdgeNode2#sh flow monitor NETFLOW cache

  Cache type:                               Normal (Platform cache)

  Cache size:                                10000

  Current entries:                               1

  Flows added:                                  13

  Flows aged:                                   12

    - Inactive timeout    (    15 secs)         12

IPV4 SRC ADDR    IPV4 DST ADDR    TRNS SRC PORT  TRNS DST PORT  FLOW CTS SRC GROUP TAG  FLOW CTS DST GROUP TAG  IP PROT            bytes long             pkts long

===============  ===============  =============  =============  ======================  ======================  =======  ====================  ====================

172.16.201.50    172.16.101.150               0              0                       0                       0        1                   240                     4

I would appreciate if someone could guide or help me out on this issue.

Regards,

Hitesh Sood

[jeaves@cisco.com]

Hi Hitesh,

the default is to propagate the sgt and as you have found, the command does not appear on the CLI as it is default. What you are seeing there is correct.

What is missing is 'policy static sgt x trusted' under 'cts manual'.

Please retest using:

cts manual

  policy static sgt x trusted

where x can be an SGT you assign to all your links or some customers use the SGT they assign to the devices (SGT 2 typically used).

Let us know.

Thanks, Jonothan.

[hsood]

Thanks for the response Jonothan.

++ I tried the command as you suggested on the interface connected to the second switch as follows:

EdgeNode2#sh run int gi 1/0/12

Building configuration...

Current configuration : 370 bytes

!

interface GigabitEthernet1/0/12

description Link to Lab Access Switch

no switchport

ip flow monitor NETFLOW output

ip address 192.168.2.2 255.255.255.0

ip router isis

load-interval 30

carrier-delay msec 0

cts manual

  policy static sgt 4 trusted

isis network point-to-point

isis authentication mode md5

isis authentication key-chain IS-IS_INTERFACE

end

++ The reason for allowing SGT 4 was because the interface connected to the host has SGT 4 applied:

EdgeNode2#sh authentication sessions int gi 1/0/23 detail

            Interface:  GigabitEthernet1/0/23

               IIF-ID:  0x1E58F9A1

          MAC Address:  0050.568d.60fe

         IPv6 Address:  Unknown

         IPv4 Address:  Unknown

            User-Name:  00-50-56-8D-60-FE

               Status:  Authorized

               Domain:  DATA

       Oper host mode:  single-host

     Oper control dir:  both

      Session timeout:  N/A

    Common Session ID:  C0A802020000000DF117209A

      Acct Session ID:  Unknown

               Handle:  0x3c000003

       Current Policy:  POLICY_Gi1/0/23

Server Policies:

            SGT Value:  4

Method status list:

       Method           State

          mab

++ Under the NETFLOW configuration , I still do not see the tagging for the SGT:

EdgeNode2#sh flow monitor NETFLOW cache

  Cache type:                               Normal (Platform cache)

  Cache size:                                10000

  Current entries:                               1

  Flows added:                                   2

  Flows aged:                                    1

    - Inactive timeout    (    15 secs)          1

IPV4 SRC ADDR    IPV4 DST ADDR    TRNS SRC PORT  TRNS DST PORT  FLOW CTS SRC GROUP TAG  FLOW CTS DST GROUP TAG  IP PROT            bytes long             pkts long

===============  ===============  =============  =============  ======================  ======================  =======  ====================  ====================

172.16.201.50    172.16.101.150               0              0                      0                      0        1                   240                     4

Let me know in case you have any more inputs.

Much appreciated !!

Regards,

Hitesh Sood

[jeaves@cisco.com · Accepted solution]

Hi,

The 'policy static sgt x trusted' command does not affect any SGT's being transmitted out that interface. It is only used in certain circumstances for inbound traffic.

So, the fact that a dynamically authenticated endpoint has SGT 4 assigned has nothing to do with the SGT you set on an outgoing interface. If you think about having multiple endpoints authenticated and classified with different SGT's, it doesn't make sense.

So, within the command, use an SGT you assign to all your links or some customers use the SGT they assign to the devices (SGT 2 typically used).

It looks like you are using ISE. Make sure the 'Network Device Authorization' under TrustSec Policy is set to 2 (TrustSec_Device by default), make sure the PAC is downloaded to the switch (sh cts pacs), make sure the environment data is downloaded and the environment data shows the device SGT (near the top) as 2.

I don't like this in your dynamically assigned session:  IPv4 Address:  Unknown

From this I presume there is no mapping created: (show cts role-based sgt-map all).

Code 16.x uses SISF for device tracking, this could well be your problem.

cat6k-enf(config)#device-tracking policy test_sisf

cat6k-enf(config-device-tracking)#tracking enable

cat6k-enf(config)#interface gigabitEthernet 1/0/23

cat6k-enf(config-if)#device-tracking attach-policy test_sisf

[hsood]

Jonathan,

You rock!

It could not have been more pinpoint resolution.

++ Just pasting outputs for the greater good for everyone else.

EdgeNode2#sh cts role-based sgt-map all

Active IPv4-SGT Bindings Information

IP Address              SGT     Source

============================================

172.16.201.1            2       INTERNAL

172.16.201.50           4       LOCAL

172.16.201.131          2       INTERNAL

172.16.201.150          3       CLI

192.168.2.2             2       INTERNAL

192.168.20.2            2       INTERNAL

192.168.255.2           2       INTERNAL

EdgeNode2#sh flow monitor NETFLOW cache

  Cache type:                               Normal (Platform cache)

  Cache size:                                10000

  Current entries:                               1

  Flows added:                                   1

  Flows aged:                                    0

IPV4 SRC ADDR    IPV4 DST ADDR    TRNS SRC PORT  TRNS DST PORT  FLOW CTS SRC GROUP TAG  FLOW CTS DST GROUP TAG  IP PROT            bytes long             pkts long

===============  ===============  =============  =============  ======================  ======================  =======  ====================  ====================

172.16.201.50    172.16.101.150               0              0                      4                       0        1                   240                     4

I will create the test for the complete scenario and keep you posted in case I landed into any more issue.

Thanks again!

Regards,

Hitesh Sood

[hsood]

Hi Team/ jeaves

I have been able to send the traffic tagged from the source switch but the tagged packet never reaches the destination switch. The SGT tag drops at the direct interface connected between the two.

I have IS-IS running between the two switches.

My query is , Does the switch running 16.6.X code which has routed interfaces between the two support SGT inline tagging?

If you refer the diagram in the original post, I have the following roles:

EdgeNode1 --- CTS manual config done ; Host connected

EdgeNode2 --- CTS manual config done ; Host connected

LabAccessSwitch --- Non-CTS manual config

++ Host 1 ---- EdgeNode1 --- LabAccessSwitch---- EdgeNode2 ---- Host 2

I have enabled SXP on all the Switches for both (Listener as well as Speaker to peer ISE) and all have the Role-based configurations on them as follows:

EdgeNode2#sh cts role-based sgt-map all

Active IPv4-SGT Bindings Information

IP Address              SGT     Source

============================================

172.16.101.1            2       SXP

172.16.101.50           3       SXP

172.16.101.150          3       SXP

172.16.201.1            2       INTERNAL

172.16.201.50           4       LOCAL

172.16.201.131          2       INTERNAL

172.16.201.150          3       CLI

192.0.0.1               2       SXP

192.168.1.1             2       SXP

192.168.1.6             2       SXP

192.168.2.2             2       INTERNAL

192.168.2.6             2       SXP

192.168.3.6             2       SXP

192.168.4.6             2       SXP

192.168.10.1            2       SXP

192.168.20.2            2       INTERNAL

192.168.100.6           2       SXP

192.168.255.1           2       SXP

192.168.255.2           2       INTERNAL

192.168.255.6           2       SXP

198.18.100.6            2       SXP

IP-SGT Active Bindings Summary

============================================

Total number of CLI      bindings = 1

Total number of SXP      bindings = 14

Total number of LOCAL    bindings = 1

Total number of INTERNAL bindings = 5

Total number of active   bindings = 21

++ Packet sourced from Host2 on EdgeNode 2 to Host1 on EdgeNode1 and I am unable to see the tagging carried forward:

EdgeNode2#sh flow monitor NETFLOW ca

  Cache type:                               Normal (Platform cache)

  Cache size:                                10000

  Current entries:                               4

  Flows added:                                1157

  Flows aged:                                 1153

    - Active timeout      (    60 secs)        252

    - Inactive timeout    (    15 secs)        901

IPV4 SRC ADDR    IPV4 DST ADDR    TRNS SRC PORT  TRNS DST PORT  FLOW CTS SRC GROUP TAG  FLOW CTS DST GROUP TAG  IP PROT            bytes long             pkts long

===============  ===============  =============  =============  ======================  ======================  =======  ====================  ====================

172.16.101.150   172.16.201.50                0              0                       0                       0        1                   240                     4

172.16.201.50    172.16.101.150               0              0                       4                       0        1                   240                     4

LabAccessSwitch#

LabAccessSwitch#sh flow monitor NETFLOW ca

  Cache type:                               Normal (Platform cache)

  Cache size:                                10000

  Current entries:                               2

  Flows added:                                1207

  Flows aged:                                 1205

    - Active timeout      (    60 secs)        248

    - Inactive timeout    (    15 secs)        957

IPV4 SRC ADDR    IPV4 DST ADDR    TRNS SRC PORT  TRNS DST PORT  FLOW CTS SRC GROUP TAG  FLOW CTS DST GROUP TAG  IP PROT            bytes long             pkts long

===============  ===============  =============  =============  ======================  ======================  =======  ====================  ====================

172.16.201.50    172.16.101.150               0              0                       0                       0        1                   240                     4

172.16.101.150   172.16.201.50                0              0                       3                       0        1                   240                     4

LabAccessSwitch#

The source switch unable to send the tagged SGT to the the next hop  (Non-CTS) switch that in turn needs to go to a CTS switch which can have the SGACL applied in the end.

Let me know if there is any more information required.

I will be glad if someone can point me in the right direct for the issue I am facing. Thanks in advance!

Regards,

Hitesh Sood

[Damien Miller]

So for the first question, yes, 16.6.x supports inline tagging on routed interfaces via the "cts manual/policy static trusted" command set. 

I'm not sure if I am following your question correctly or not.  Are you expecting the bidirectional SXP connections from edge 1 - ISE and edge 2 - ISE to bridge the gap between the lab switch that does is not utilizing inline tagging? 

Or are you expecting the tag to be carried inline from edge 1 - edge 2?  The SGT will not be written into the header unless a link has cts manual(inline tagging) configured.  You need it on both ends of every link in the path or the packet will drop, non cts interfaces will see it as a malformed packet. 

[hsood]

Hi Damien,

Thank you for looking into this.

I will go with option 1, I have "CTS manual" configured on both the ends of the link between EdgeNode 1  (CTS enabled) and LabAccessSwitch (Non-CTS enabled) as well as between the EdgeNode 2 and LabAccessSwitch switch.

LabAccessSwitch#sh run int gi 1/0/2

Building configuration...

Current configuration : 302 bytes

!

interface GigabitEthernet1/0/2

description Link to Edge Node #2

no switchport

ip address 192.168.2.6 255.255.255.0

ip router isis

load-interval 30

carrier-delay msec 0

cts manual

isis network point-to-point

isis authentication mode md5

isis authentication key-chain IS-IS_INTERFACE

end

===============================

EdgeNode2#sh run int gi 1/0/12

Building configuration...

Current configuration : 371 bytes

!

interface GigabitEthernet1/0/12

description Link to Lab Access Switch

no switchport

ip flow monitor NETFLOW input

ip flow monitor NETFLOW output

ip address 192.168.2.2 255.255.255.0

ip router isis

load-interval 30

carrier-delay msec 0

cts manual

isis network point-to-point

isis authentication mode md5

isis authentication key-chain IS-IS_INTERFACE

end

=======================================

Hosts are connected to EdgeNode 1 and EdgeNode 2 and the LabAccessswitch is just an intermediate switch that the traffic passes through.

The issue I have is that the LabAccessswitch does not get the packet tagged when it is coming from either of the EdgeNode switches. Although, from the source switch (EdgeNode1 or EdgeNode2), it is indeed tagged after enabling the device tracking.

Let me know if any further outputs or queries are required.

Regards,

Hitesh

[Damien Miller]

I would suggest following the guide published for inline tagging and adding the command found in step 6 to your switch-switch links, then retesting.  This was mentioned early in this thread by Jeaves. SGT's need to be treated much like DSCP marking from ip phones, you need to trust what is coming in. 

https://www.cisco.com/c/en/us/td/docs/switches/lan/trustsec/configuration/guide/trustsec/sgt_inline_tagging.html

Step 6

Device(config-if-cts-manual)# policy static sgt tag trusted

Configures a static SGT ingress policy on the interface and defines the trustworthiness of an SGT received on the interface.

Note The trusted keyword indicates that the interface is trustworthy for Cisco TrustSec. The SGT value received in the Ethernet packet on this interface is trusted and will be used by the device for any SG-aware policy enforcement or for the purpose of egress-tagging

[hsood]

Hi Damien,

Yes, I tried those commands already but no luck. I removed those because these did not make a difference in tagging either way. I just tried those again now.

There is a second issue as well with that command that jeaves told me earlier that this would not work in this thread.

The "policy static sgt tag trusted" command can allow only one sgt as trusted. I assume (and you can correct me if I am wrong) this command would be more ok for a host connected directly to such a switch for the tags to be trusted but the host connected switch seem to be working fine already.

Regards,

Hitesh Sood