SD access unmanaged switch

[mikhailov.ivan]

Hello all! I need some help with simple question:

Case: You have DNA\SDA architecture and you want to connect dumb switch for any endpoint devices in SD-Access port (e.g 9300 sw) and you need to auth thes endpoint devices. 

Again: SDA C9300----dumb SW----endpoint1

                                             |-------endpoint2

What will occur in this case? I cant find describe , maybe i am bad finder )

Thanks!

[mnagired]

Hi..
Not supported..Use Policy extended nodes for extending fabric one layer below if you intend to authenticate the endpoint..

Today we only support IE3400 as Policy extended nodes.. There are plans to support Cat9K as Policy Extended node in future releases..

[mikhailov.ivan]

I understand that is not traditional case, and yes we can use extended nodes like IE 4k (industrial) for SGT to vlans mapping, but could you explain what really occur in this case more detailed? Maybe i can authenticate my devices per MAC-address(we will have multi-MAC per one SDA port.) I think this is a popular scenario, because in some situation you cant install physical cables for each devices to dedicated SDA ports..

Thanks for help!

[Benjamin-A · Accepted solution]

Hi Ivan,

I recently tested it in our lab (DNA-C 1.3.3; ISE 2.6; C9300 16.12.3a).

I attached an unmanaged switch to one of the C9300. Host-Onboarding is in Closed Authentification Mode 802.1x & MAB.

I have a topology with 3 VNs and one IP Pool per VN. I attached Clients of every VN to the unmanaged Switch and the following is the result:

But first I want to annotade that the following is not officially supported by Cisco and for general I definitely won't recommend this as best practice solution in production - just a little Lab Insight and maybe a workaround ;).

• All clients will authenticate and get the right SGT and VLAN/VN assignment
• Policy enforcement will be as described in the picture. EndpointX is representative of any Client (in any VN/IP Pool) which is not attached to the unmanaged switch.

• Enpoint 1 and Endpoint 2 will be able to communicate regardless of the SGT Policy
• All other on the same unmanaged switch won't

The command "show int .... status" will show only the VLAN of the first client and it still will be in mode Access.

edge#show access-session interface gi2/0/1 details
            Interface:  GigabitEthernet2/0/1
               IIF-ID:  #######
          MAC Address:  aaaa.aaaa.aaaa
         IPv6 Address:  Unknown
         IPv4 Address:  1.1.1.1
            User-Name:  #######
          Device-type:  Un-Classified Device
          Device-name:  Unknown Device
               Status:  Authorized
               Domain:  DATA
       Oper host mode:  multi-auth
     Oper control dir:  both
      Session timeout:  N/A
  Acct update timeout:  172800s (local), Remaining: 172760s
    Common Session ID:  #######
      Acct Session ID:  #######
               Handle:  #######
       Current Policy:  PMAP_DefaultWiredDot1xClosedAuth_1X_MAB


Local Policies:

Server Policies:
           Vlan Group:  Vlan: 1020
            SGT Value:  1


Method status list:
       Method           State
        dot1x           Authc Success
          mab           Stopped

----------------------------------------

            Interface:  GigabitEthernet2/0/1
               IIF-ID:  0x#######
          MAC Address:  bbbb.bbbb.bbbb
         IPv6 Address:  Unknown
         IPv4 Address:  2.2.2.2
            User-Name:  ##########
          Device-type:  Un-Classified Device
          Device-name:  #####
               Status:  Authorized
               Domain:  DATA
       Oper host mode:  multi-auth
     Oper control dir:  both
      Session timeout:  N/A
  Acct update timeout:  172800s (local), Remaining: 172121s
    Common Session ID:  #######
      Acct Session ID:  #######
               Handle:  #######
       Current Policy:  PMAP_DefaultWiredDot1xClosedAuth_1X_MAB


Local Policies:

Server Policies:
           Vlan Group:  Vlan: 1021
            SGT Value:  2


Method status list:
       Method           State
        dot1x           Authc Success

----------------------------------------

edge#show int gi2/0/1 status

Port         Name               Status       Vlan       Duplex  Speed Type
Gi2/0/1      lan               connected     1020       a-full  a-100 10/100/1000BaseTX

So as you see the VLAN + SGT is bound to the Session ID :) 

Hope this example will help you.

[mnagired]

Hi

Firstly, it’s not a architecture we support today.. It may work, but if there are issues, TAC work support it.. If you ok please go ahead..

2ndly, Topology, used for test.. which Switch is the Authenticator ? Dummy Switch or Edge??

[Benjamin-A]

Hi
yeah it is not supported and for general I definitely won't recommend this as best practice solution. I just don't wanted to mention it again as it was annotated multiple times before that. But there are some scenarios this can be very helpful to know - for a little workaround ;).
The Authenticator is the FE. The unmanages switch is just a dumb switch doing nothing as just forwarding frames.
And the Access Port Config on FE is default as provides by DNA-C best Practice for Closed Authentification.

[mnagired]

Thanks Benjamin ..

If the Authenticator switch is FE and link between the Fabric edge and Dummy switch is access link with dot1x enabled,DNAC pushes IPDT limit of 10 to all Layer2 ports on FE .. This is one restriction and Scott called it out as well..

I understand your ask and we don’t want to go the route of testing all Layer 2 switches out there to support above scenario.. Hence, Policy extended node ( Cat9K* or IE3400) if you need endpoint authentication on switch connecting to fabric edge.. Else Trunk on Fabric edge and any Layer 2
Switch without endpoint authentication with limit of not more than 100 endpoints on trunk interface are the supported topology..

You may even consider daisy chaining for fabric edges if required..

[Scott Hodgdon]

Ivan,

Would all of the clients be in the same VLAN ? How many clients would be on a single "dumb SW" ?

Cheers,

Scott Hodgdon

Senior Technical Marketing Engineer

Enterprise Networking Group

[mikhailov.ivan]

sure, in this case all clients will in same vlan. It is just example,  lets imagine 7 clients )

I am just interest how this case will processing by SDA\DNA and how i can authorize clients.

Thanks.

[Scott Hodgdon · Accepted solution]

Ivan,

The reason I ask is that it does make a difference.

If all clients are in the same subnet and there are 10 or less clients, then there is no problem with support. In SDA, each Fabric Edge Node client-facing switch port has an IP Device Tracking policy that allows up to10 clients, but only if they are in the same VLAN as the default port type is an access port and not a trunk. We would be able to authenticate all clients separately with a multi-auth capability on the port, and we can tag the traffic with SGTs to achieve the micro-segmentation capability of SD-Access. So the example you give (1 VLAN, 7 clients) is supported.

If clients are in different subnets then that is where things get trickier as we can no longer use the default access port type in that situation. We could create a trunk port by configuring the client-facing port in DNA Center as a "Server" port (this is an option in the host onboarding page). However, you then lose 802.1x auth on the port, you would have to manually assign SGT mappings to the subnets/VLANs of the trunk , and we really don't want to do anything manually if we can help it. There is also no Spanning Tree run on that trunk port, so you would have to be careful not to accidentally create a loop. 

In both cases I have mentioned (access port and trunk port), you would not have East-West policy enforcement via SGT on the "dumb SW" attached to the 9300. As Mahesh mentioned, the best option is to use a Policy Extended Node (PEN) that can do 802.1x, SGT tagging and East-West policy enforcement between the clients on the PEN attached to the 9300.

Hope that helps.

Cheers,

Scott Hodgdon

Senior Technical Marketing Engineer

Enterprise Networking Group

[mikhailov.ivan]

Awesome! It was really helpful. Now all clear for me.

Thanks a lot!

[jedolphi]

One small clarification. If we have an unmanaged hub connected to SDA FE access port, then each endpoint on that unmanaged hub can be mapped to a different VLAN and IP pool using ISE, up to 10 IP address per FE access port. I have a slide on this on DGTL-BRKENS-3822, https://www.ciscolive.com/global/on-demand-library.html?search.event=ciscoliveus2020&search=dolphin#/session/1570575336196001v4R5 .

The concept is explained in "Scenario One" here: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/16-12/configuration_guide/sec/b_1612_sec_9300_cg/configuring_ieee_802_1x_port_based_authentication.html "When a second host (H2) is connected and gets assigned to VLAN ( V2), the port will have two operational VLANs (V1 and V2). If H1 and H2 sends untagged ingress traffic, H1 traffic is mapped to VLAN (V1) and H2 traffic to VLAN (V2), all egress traffic going out of the port on VLAN (V1) and VLAN (V2) are untagged. "