SDA support for silent host

[e-chuah]

Hi,

We are deploying SDA for a building. We have a card reader controller which is a silent host. When connnected to the switch, it will not send out any traffic. It will only send reply traffic when the facial recognition device start sending traffic to it.

Our original intention is to configure MAB using ISE. With the card reader controller being a silent host, the work around we use is

- configure static port vlan instead of using MAB.

Is there other workaround or solutions ? We asked the card reader controller vendor to see if they can configure NTP at their end so as to send out traffic. Unfortunately, they can't. 

Enable Layer 2 flood or IP directed broadcast in DNAC also doesn't help in this case because the card reader controller is not going to receive that broadcast because it is in the default vlan 1.

Thanks

Eng Wee

[jalejand]

L2 Flooding and IP Directed Broadcast will help on allowing traffic to reach the Edge node where the silent host is located, so consider enabling these ones for this purpose.

The main problem would be sending the traffic to the host when not yet authenticated. For that, enable "wake on lan" on the authentication template, so regardless if the client is authenticated or not, egress packets can be still sent out of the port with the silent host.  

Exactly as you mention, without a VLAN, the host will sit under VLAN 1 unless you manually specify the VLAN on the port; this does not mean that you cannot use MAB/authentication on the port, it just means that you need to configure the VLAN on the silent host port via host onboarding, just keep authentication enabled.

Authentication with silent hosts is a problem that has been there even before SDA became a thing, and that has always been the way to make it work

[e-chuah]

Hi Jalejand,

Thanks for the comments. Base on your commends, i did the following and it works.

(1) enable wake on LAN

(2) assign a vlan to the port, (authentication still enabled).

(3) L2 flood and ip directed broadcast enabled.

Managed to get the endpoint MAB authenticated.

I am wondering without doing (1) wake on LAN, just by assigning a vlan to that port, it may also work, if we turn on L2 flooring and ip directed broadcast because the facial recognition device will ARP for the controller and the traffic will be flooded out to the port connected to the controller. Will test this out..

Rgds

Eng Wee

[jalejand]

Hi Eng

Without L2 flooding and IP directed broadcast (L2 flooding is actually enabled when enabling IP directed broadcast on the VLAN by the way) the silent host device can only rely on packets being broadcasted on the same switch/stack, as an example, another device attached to the same switch trying to communicate/ARPing to the host.

By enabling l2 flooding alone, you are increasing the broadcast domain on the fabric so any device inside of the fabric in the same VLAN can attempt to wake up this device with traffic. With IP directed broadcast, two important features are enabled that can help on waking up the device from outside of the fabric:

1) IP directed broadcast/subnet broadcast support. With this you can wake up all the devices at the same time by converting a directed broadcast into a full broadcast that will be flooded to all fabric endpoints on the VLAN.

2) Flood unknown unicast on the Fabric Border: With this, any unicast packet destined to a device that be considered silent (meaning, no longer registered on the control plane of the device) will be considered "unknown" and the Border will trigger an ARP request for it that will be also flooded to all Edges, which can be enough to wake up the device too.

Basically with these two features you are increasing the scope of what can wake up the silent host, L2 flooding increasing the scope fabric wide (same vlan) and IPDB increasing the scope to anything outside of the fabric.

[andy!doesnt!like!uucp]

unfortunately, there is also such type of silent BMS-devices that ignore broadcasts  on their VLAN . & when it's about ARP-specifically, they only respond when they own THA or TIP in packet

[andy!doesnt!like!uucp]

Hi

independently on whatever the extent of silence IP-host could be of, it'll necessary ARP'ing its default GW to sent traffic. ARP can trigger MAB thus hinting u to change authentication order from "dot1x mab" to "mab dot1x"  & authentication control-direction to in. in the ISE, pre-code MAC of IP-host in the specific ID-group ISE can successfully MAB-authenticate it against.
can it be a solution in your case? 

UPD. also take a look here (no idea though how about approach in the background)
(2) Cisco SD-Access for silent hosts, a better solution | LinkedIn

[e-chuah]

Hi Andy,

Thanks for the comments. You are right that the silent host need to send ARP to resolve its default GW. So with that, we should be able to get its mac address and perform MAB. But somehow this is not the case, on the switch end, we can't see the mac address of the silent host. Hence MAB cannot kick in.

Rgds

Eng Wee

[andy!doesnt!like!uucp]

there cannot be mystery, my friend. MACs get aged out in 5 mins by default & if there is no job for scanner it wont send anything (nor ARP nor traffic based on its maybe still alive ARP-entry of default GW.

nevertheless it's cool that @jalejand's solution worked for u.