Booting DIMENSION4 under STP and 802.1x

From DIMENSION4 3.7 SP1 onwards, sensors will boot reliably on networks where the Ethernet switches are configured with Spanning Tree Protocol (STP), and 802.1x plus MAB.

As is commonly the case with endpoints that use DHCP, it will usually be necessary to reduce a switch’s MAB timeout from the default value in order to boot a sensor configured to use DHCP, but all other sensor boot modes will support most switches’ default configurations for STP and 802.1x.

This document describes how the sensor boot process relates to 802.1x plus MAB and STP and shows how to configure recommended timeouts to support sensors using DHCP on a typical switch.

Why STP and 802.1x can affect sensor booting

Both STP (see Spanning Tree Protocol - Cisco) and 802.1x (see Wired 802.1X Deployment Guide - Cisco) are layer 2 protocols that carry out housekeeping tasks when an Ethernet link comes up. STP calculates optimum routes through a layer 2 network and ensures that network loops are eliminated; 802.1x authenticates the device that has just been introduced to the network. Both these protocols guard against malign end points: STP guards against a new endpoint that creates a network loop; and 802.1x guards against an unauthorized device that may create a security hazard. Therefore, to be as safe as possible, no network traffic is forwarded from or to the device until the protocols have succeeded, and this creates a delay at the start of the booting process just after the sensor has come up.

Ubisense DIMENSION4 sensors perform various network tasks at boot time (see DIMENSION 4 boot process overview) and will signal an error and fail if network service is unavailable for an excessive period at after the sensors are plugged in or restarted. If a sensor boot attempt fails, the sensor will restart, taking the Ethernet link down and up again, and restarting the STP and 802.1x protocols. Therefore, if the delays in network service due to STP or 802.1x are too great, the sensors will fail to boot.

Details of protocol timeouts

DIMENSION4 timeouts at boot time

Firmware DHCP timeout

When the sensor starts up, if it is configured to use DHCP, its boot firmware will send DHCP Discover packets at intervals of 3 seconds for a total of 60 seconds before timing out.

Firmware configuration server timeout

After the sensor has received an IP address (either through DHCP or stored in its EEPROM), it will send Ubisense configuration protocol requests at intervals of 8 seconds for a total of 180 seconds before timing out.

After the sensor configuration is received from the configuration server, the sensor will load its Linux kernel and file system into RAM, either by downloading it from the network or by retrieving it from its on-board flash memory. When the Linux kernel and file system are loaded, the sensor will start the kernel, and at this point the network link will be dropped by the firmware and picked up by the sensor’s Linux OS, meaning that a new connection to the switch is created and STP and 802.1x protocols will be restarted.

Linux DHCP timeout

When Linux starts up on the sensor, if it is configured to use DHCP, it will send DHCP Discover packets at intervals of 3 seconds for a total of 60 seconds before timing out.

Linux configuration server timeout

After the sensor has received an IP address (either through DHCP or passed to the Linux kernel by the boot firmware if the sensor has an IP address stored on EEPROM), it will send Ubisense configuration protocol requests at intervals of 8 seconds for a total of 180 seconds before timing out.

802.1x timeouts

When a link comes up, the switch’s 802.1x protocol will send EAP-Request Identity frames to solicit the sensor to request authentication with the RADIUS server. DIMENSION4 sensors will not respond to EAP-Request Identity frames and must be authenticated using MAB. After some time, if no response is received, the switch will fail over to MAB. Before a device has been authenticated, network packets will normally not be forwarded to or from the device, therefore there will be no response to DHCP Discover requests from the sensor during this period.

The timeout period for failover to MAB is normally calculated from two factors (this example taken from Wired 802.1X Deployment Guide - Cisco): tx-period is the timeout before an attempted retransmission of the EAP-Request Identity frames, and max-reauth-req is the number of times that retransmission will be attempted, therefore the total timeout is (max-reauth-req + 1) * tx-period.

On Cisco switches the default value of tx-period is 30 seconds, and the default value of max-reauth-req is 2, making the default total MAB timeout equal to 90 seconds. It is a common procedure, in environments with DHCP clients, to reduce tx-period to 10 seconds, making the total MAB timeout equal to 30 seconds.

STP timeouts

After a device has been authenticated, the switch’s STP protocol will send BDPU frames to learn the topology of the new network created by plugging in the device. Of course, in this case the device is an end-point and the topology of the network is unchanged, so DIMENSION4 sensors do not engage in the STP protocol.

When the link comes up, the switch will normally transition to the STP Listening state on receipt of the first Ethernet frame from a sensor. After 15 seconds it will time out into the Learning state, and after a subsequent 15 seconds it will time out into the Forwarding state, at which point the network will be fully available to the sensor. Thus the spanning tree protocol adds 30 seconds to the period for which the sensor has no networking.

Example configurations

DIMENSION4 sensor with STP enabled and 802.1x disabled

Sensor configured to use DHCP

Success. In this case the STP will impose a 30 second delay before the sensor firmware can get an address via DHCP, but the sensor’s firmware DHCP timeout is set to 60 seconds, so the DHCP will succeed, and the sensor will subsequently load Linux, at which point the link will be reset and there will be another 30 second delay before the Linux DHCP client can get an address via DHCP, but the sensor’s Linux DHCP timeout is set to 60 seconds, and so the DHCP will succeed and the sensor should start up correctly.

Sensor configured with static IP address in EEPROM

Success. In this case the STP will impose a 30 second delay before the sensor firmware can get its Ubisense configuration, but the sensor’s firmware configuration timeout is set to 180 seconds, so this will succeed, and the sensor will subsequently load Linux, at which point the link will be reset and there will be another 30 second delay before the Linux configuration client can get its Ubisense configuration, but the sensor’s Linux configuration timeout is set to 180 seconds, and so the configuration request will succeed and the sensor should start up correctly.

DIMENSION4 sensor with STP and 802.1x enabled with defaults

Sensor configured to use DHCP

Failure. In this case the 802.1x MAB timeout will impose a 90 second delay before the sensor firmware can get an address via DHCP, but the sensor’s firmware DHCP timeout is set to 60 seconds, so the DHCP will fail and the sensor will be unable to boot.

Sensor configured with static IP address in EEPROM

Success. In this case the 802.1x MAB timeout will impose a 90 second delay followed by an extra 30 second delay from the STP protocol totaling 120 seconds before the sensor firmware can get its Ubisense configuration, but the sensor’s firmware configuration timeout is set to 180 seconds, so this will succeed, and the sensor will subsequently load Linux, at which point the link will be reset and there will be another 120 second delay before the Linux configuration client can get its Ubisense configuration, but the sensor’s Linux configuration timeout is set to 180 seconds, and so the configuration request will succeed and the sensor should start up correctly.

DIMENSION4 sensor with STP and 802.1x with tx-period of 10s

Sensor configured to use DHCP

Success but marginal. In this case the 802.1x MAB timeout will impose a 30 second delay followed by an extra 30 second delay from the STP protocol totaling 60 seconds before the sensor firmware can get an address via DHCP, but the sensor’s firmware DHCP timeout is set to 60 seconds, so the DHCP will (only just) succeed, and the sensor will subsequently load Linux, at which point the link will be reset and there will be another 60 second delay before the Linux DHCP client can get an address via DHCP, but the sensor’s Linux DHCPtimeout is set to 60 seconds, and so the DHCP will (only just) succeed and the sensor should start up correctly. Note that this behavior succeeds every time on our test networks using Cisco switches, but the timeouts are right on the edge, so it may be advisable to confirm that this will also work in your environment, and to reduce tx-period to 9 seconds if you encounter frequent DHCP timeouts.

Sensor configured with static IP address in EEPROM

Success. In this case the 802.1x MAB timeout will impose a 30 second delay followed by an extra 30 second delay from the STP protocol totaling 60 seconds before the sensor firmware can get its Ubisense configuration, but the sensor’s firmware configuration timeout is set to 180 seconds, so this will succeed, and the sensor will subsequently load Linux, at which point the link will be reset and there will be another 60 second delay before the Linux configuration client can get its Ubisense configuration, but the sensor’s Linux configuration timeout is set to 180 seconds, and so the configuration request will succeed and the sensor should start up correctly.

Summary of configuration recommendations

Spanning Tree Protocol without 802.1x

When using STP, the default behavior will normally result in a timeout of 30 seconds or less. If no additional delays are imposed by the switch then DIMENSION4 booting will work in all cases.

802.1x (plus MAB) without Spanning Tree Protocol

Configure sensor MAC prefix in the RADIUS server

To simplify configuration, most RADIUS servers support MAC prefixes, which mean that it is not necessary to configure every single end point. All DIMENSION4 sensors have a MAC address prefix of 00:11:CE which should be configured as authorized in your server.

DIMENSION4 sensors using DHCP

When using 802.1x plus MAB, the default timeouts will usually be too long for sensors to boot using DHCP. In this case, adjust tx-period. For example, on a Cisco 3560 setting port 0/15:

cisco3560# enable
cisco3560(config)# configure interface 0/15
cisco3560(config-if)# dot1x timeout tx-period 10

This should ensure that the switch starts forwarding before the sensor DHCP times out.

DIMENSION4 sensors using static IP settings

When using static IP settings the default timeouts are unlikely to be too long to exceed the configuration server timeout of 180 seconds. Therefore, if no additional delays are imposed by the switch then DIMENSION4 booting will work when a static IP address is set.

802.1x (plus MAB) with Spanning Tree Protocol

DIMENSION4 sensors using DHCP

Continue to use the configuration change to tx-period as described above, but check that this works in your setup because the switch inactivity period of 60 seconds is very close to the DHCP timeout of (also 60 seconds).