<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic L2-SGT treatment during routing in Network Access Control</title>
    <link>https://community.cisco.com/t5/network-access-control/l2-sgt-treatment-during-routing/m-p/4771878#M579741</link>
    <description>&lt;P&gt;Hello Everyone&lt;/P&gt;
&lt;H6&gt;after enabling campus for TrustSec we can notice that client's frame generated on access &amp;amp; provisioned with CMD (with SGT assigned by ISE AAA process) need to be routed on the core (also TrustSec aware by "cts manual" on all its interconnects) from original SVI to let's say transit. The Q is how does Cisco treat this case assuming there is no SGT-enforcement on the core, no IP-SGT mappings nor SGACLs &amp;amp; all core's L2 interfaces configured with cts manual ; propagate cts ; policy static sgt 2 trusted):&lt;BR /&gt;1) replicate CMD from ingress frame on the egress&lt;/H6&gt;
&lt;H6&gt;2) insert on egress CMD with trusted SGT&amp;nbsp;&lt;/H6&gt;
&lt;H6&gt;3) insert on egress CMD with unknown (0) SGT&lt;/H6&gt;
&lt;H6&gt;4) something else&lt;/H6&gt;
&lt;P&gt;Could anyone pls shed a light?&lt;/P&gt;</description>
    <pubDate>Mon, 13 Feb 2023 09:36:36 GMT</pubDate>
    <dc:creator>Andrii Oliinyk</dc:creator>
    <dc:date>2023-02-13T09:36:36Z</dc:date>
    <item>
      <title>L2-SGT treatment during routing</title>
      <link>https://community.cisco.com/t5/network-access-control/l2-sgt-treatment-during-routing/m-p/4771878#M579741</link>
      <description>&lt;P&gt;Hello Everyone&lt;/P&gt;
&lt;H6&gt;after enabling campus for TrustSec we can notice that client's frame generated on access &amp;amp; provisioned with CMD (with SGT assigned by ISE AAA process) need to be routed on the core (also TrustSec aware by "cts manual" on all its interconnects) from original SVI to let's say transit. The Q is how does Cisco treat this case assuming there is no SGT-enforcement on the core, no IP-SGT mappings nor SGACLs &amp;amp; all core's L2 interfaces configured with cts manual ; propagate cts ; policy static sgt 2 trusted):&lt;BR /&gt;1) replicate CMD from ingress frame on the egress&lt;/H6&gt;
&lt;H6&gt;2) insert on egress CMD with trusted SGT&amp;nbsp;&lt;/H6&gt;
&lt;H6&gt;3) insert on egress CMD with unknown (0) SGT&lt;/H6&gt;
&lt;H6&gt;4) something else&lt;/H6&gt;
&lt;P&gt;Could anyone pls shed a light?&lt;/P&gt;</description>
      <pubDate>Mon, 13 Feb 2023 09:36:36 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/l2-sgt-treatment-during-routing/m-p/4771878#M579741</guid>
      <dc:creator>Andrii Oliinyk</dc:creator>
      <dc:date>2023-02-13T09:36:36Z</dc:date>
    </item>
    <item>
      <title>Re: L2-SGT treatment during routing</title>
      <link>https://community.cisco.com/t5/network-access-control/l2-sgt-treatment-during-routing/m-p/4773355#M579776</link>
      <description>&lt;P&gt;&lt;a href="https://community.cisco.com/t5/user/viewprofilepage/user-id/293790"&gt;@Andrii Oliinyk&lt;/a&gt; As you know, I did inline tagging between C9800-CL and C8000V. Although C9800-CL has an SVI for management, the cts configuration goes to the physical interface (in my case, Gi1). For C8000V, each of the sub-interfaces is configured for cts manual and policy static sgt 2 trusted. If an L2 frame has a CMD with SGT, then the SGT is preserved. If no SGT, then SGT2 is sent.&lt;/P&gt;
&lt;P&gt;I've also asked my coworker who wrote the Segmentation Strategy guide to take a look of this thread.&lt;/P&gt;</description>
      <pubDate>Sun, 12 Feb 2023 02:12:09 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/l2-sgt-treatment-during-routing/m-p/4773355#M579776</guid>
      <dc:creator>hslai</dc:creator>
      <dc:date>2023-02-12T02:12:09Z</dc:date>
    </item>
    <item>
      <title>Re: L2-SGT treatment during routing</title>
      <link>https://community.cisco.com/t5/network-access-control/l2-sgt-treatment-during-routing/m-p/4774110#M579791</link>
      <description>&lt;P&gt;OK, remember that the 'policy static sgt x trusted' ONLY has the ability to adjust the assigned SGT in the inbound direction (e.g. int1).&lt;BR /&gt;In the outbound direction (e.g. int2), the 'cts manual / policy static sgt x trusted' just enables the propagation of the CMD.&lt;BR /&gt;So, inbound then on int1, as I've written the command above, the SGT received on the wire will be trusted and will be forwarded out int2 as is.&lt;BR /&gt;If the commands on int1 (inbound) are 'cts manual / policy static sgt x', it means do not trust the SGT on the wire and classify the incoming traffic with SGT x instead. This SGT x will be transmitted via CMD out int2.&lt;BR /&gt;This topic is covered in a couple of slides in an ISE webinar I presented recently, found on YouTube here:&amp;nbsp;&lt;A href="https://www.youtube.com/watch?v=KKbvocNPaOQ&amp;amp;t=34s" target="_blank"&gt;https://www.youtube.com/watch?v=KKbvocNPaOQ&amp;amp;t=34s&lt;/A&gt; starting at 11 minutes 15 seconds.&lt;/P&gt;</description>
      <pubDate>Mon, 13 Feb 2023 11:27:53 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/l2-sgt-treatment-during-routing/m-p/4774110#M579791</guid>
      <dc:creator>jeaves@cisco.com</dc:creator>
      <dc:date>2023-02-13T11:27:53Z</dc:date>
    </item>
    <item>
      <title>Re: L2-SGT treatment during routing</title>
      <link>https://community.cisco.com/t5/network-access-control/l2-sgt-treatment-during-routing/m-p/4774116#M579792</link>
      <description>&lt;P&gt;Hi Jonothan&lt;/P&gt;
&lt;P&gt;highly appreciate your input (inc. reference to utube)! thanks&amp;nbsp; &amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 13 Feb 2023 11:41:17 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-access-control/l2-sgt-treatment-during-routing/m-p/4774116#M579792</guid>
      <dc:creator>Andrii Oliinyk</dc:creator>
      <dc:date>2023-02-13T11:41:17Z</dc:date>
    </item>
  </channel>
</rss>

