"Hub Hunting" in an SDA Environment

[anthony.wild]

Hello All,

I have a question here around best practices for rendering unauthorized network devices such as hubs or non-Cisco branded switches inoperable, specifically in an SDA environment. We have run into a spate of issues at some of our remote plants where contractors or personnel purchase and install non-standard network infrastructure to quickly add port density for devices like surveillance cameras or other IoT devices. While ISE is doing its job to restrict or deny access to devices we do not approve, some devices like those aforementioned surveillance cameras are profiled and allowed by MAB, and therefore work even though the upstream intermediate hub/switch is not allowed by our policy. I know there's a whole separate discussion around GRC and forcing a stronger policy, but I had some thoughts around the following on a technical level;

The command "access-session host-mode multi-domain" seems to allow two hosts, one voice and one data. Any more seem to trigger a "%AUTHMGR-5-SECURITY_VIOLATION" on the port to where it basically restricts traffic down to one MAC address or in some cases inconsistently or not at all (which I'd be fine with because it would force the offender to call me and spur the conversation around acceptable use).

In an SDA environment, could I create a template/tag that would inject the "access-session host-mode multi-domain" into the DefaultWiredDot1xOpenAuth template that SDA creates? Or would I be better off asking Cisco for a feature enhancement? Or, is there another solution altogether that I am missing? I see the the single host vs unlimited radio selector in the authentication profiles in DNA, but this won't work in a scenario where we have a PC connected to the switch port on an IP phone.

Thanks in advance for the help.

[willwetherman · Accepted solution]

Hi @anthony.wild 

Restricting the number of hosts that can authenticate to the fabric edge port, or by configuring no authentication on the fabric edge port and enabling port security (which can be applied manually or by using a template) are two solutions that I have used in the past to prevent the connection of unauthorised hubs/unmanaged switches. Another possible solution that I am yet to explore, is the use of automation to check for any ports with multiple hosts connected/authenticated and then to shutdown any offending ports.

Regarding the DNAC authentication templates - I have been meaning to raise this with Cisco TAC as I recently noticed a discrepancy with the description of the 'Single' option under the authentication templates and with what DNAC actually configures on the fabric edge.

If you change the 'Number of Hosts' setting under any of the authentication templates to 'Single' DNAC actually configures 'access-session host-mode multi-domain' under the applicable template on the fabric edge and not 'access-session host-mode single-host' which is suggested by the name of the setting and its description.

As an example, this is the configuration of the Closed Authentication Template when the number of hosts is set to 'Unlimited'. The host mode is set to multi-auth which is the default mode and hence not displayed in the config

template DefaultWiredDot1xClosedAuth
dot1x pae authenticator
dot1x timeout supp-timeout 7
dot1x max-req 3
switchport mode access
switchport voice vlan 2046
mab
access-session closed
access-session port-control auto
authentication periodic
authentication timer reauthenticate server
service-policy type control subscriber PMAP_DefaultWiredDot1xClosedAuth_1X_MAB
source template DefaultWiredDot1xClosedAuth

This is the configuration of the Closed Authentication Template when the number of hosts is set to 'Single'. As you can see the host mode is actually set to multi-domain which allows the authentication of one data device and one voice device on the port. 

template DefaultWiredDot1xClosedAuth
dot1x pae authenticator
dot1x timeout supp-timeout 7
dot1x max-req 3
switchport mode access
switchport voice vlan 2046
mab
access-session host-mode multi-domain
access-session closed
access-session port-control auto
authentication periodic
authentication timer reauthenticate server
service-policy type control subscriber PMAP_DefaultWiredDot1xClosedAuth_1X_MAB
source template DefaultWiredDot1xClosedAuth

This is the output of the archive config log on the fabric edge switch which shows dnac changing the host mode to multi-domain.

1 0 dnac@vty1 |template DefaultWiredDot1xClosedAuth
2 0 dnac@vty1 | access-session host-mode multi-domain
3 0 dnac@vty1 | exit

You will need to test this in isolation as once you alter the authentication template, you need to apply which pushes out the updated settings to all fabric edges switches in the fabric site. I would also raise this with Cisco TAC to confirm that multi-domain is the intended setting on the fabric edge when single host is configured and that the description in DNAC is incorrect/misleading. Hopefully using Single host will meet your requirements and will prevent the need to manually change any of the settings using a custom template. 

Hope that this helps

EDIT

For info, the above was tested using DNAC 2.3.3.4 and IOS-XE 17.6.4

[anthony.wild]

Hi @willwetherman ,

So it sounds like the "Single" (albeit totally misleading) is actually the option that I want and the desired target state. If I select single, it will in effect do what my template is doing. Now I just have to worry about them "fixing it" and making it do what it actually purports to do after I slowly roll this out. If you wouldn't mind in your feedback (TAC Case / Make a Wish), suggesting that they have 3 radio buttons for single, multi-domain, and unlimited... I will do the same.

Marked as resolved for the thorough reply and great assist on this one.