Fiber optics and UDLD

UDLD (Unidirectional Link Detection) is a protocol to help prevent forwarding loops in switched networks. A fiber cable is build from two separate fibers (transmit and receive), where one of the two fiber could fail, which would result in a switch port not able to receive or send traffic. This scenario could result in some serious problems.

The Problem

Spanning-Tree Protocol (STP) resolves redundant physical topology into a loop-free, tree-like forwarding topology. This is done by blocking one or more ports. By blocking one or more ports, there are no loops in the forwarding topology. STP relies in its operation on reception and transmission of the Bridge Protocol Data Units (BPDUs). If the STP process that runs on the switch with a blocking port stops receiving BPDUs from its upstream (designated) switch on the port, STP eventually ages out the STP information for the port and moves it to the forwarding state. This creates a forwarding loop or STP loop.

Check the following two pictures:

The left pictures shows a regular layer 2 network, where switch B is the designated switch for the B-C segment. Switch C on the B-C link is in blocking state. In the right picture switch C’s Tx is broken, switch C doesn’t receive and BPDU packets from switch B anymore and ages the information received with the last BPDU. Once the STP information is aged out on the port, that port transitions from the blocking state to the listening, learning and eventually to the forwarding STP state. This creates a forwarding loop, as there is no blocking port in the triangle A-B-C. Packets cycle along the path (B still receives packets from C) taking additional bandwidth until the links are completely filled up. This brings the network down.

UDLD explained

UDLD is a Layer 2 (L2) protocol that works with the Layer 1 (L1) mechanisms to determine the physical status of a link. At Layer 1, auto-negotiation takes care of physical signaling and fault detection. UDLD performs tasks that auto-negotiation cannot perform, such as detecting the identities of neighbors and shutting down misconnected ports. When you enable both auto-negotiation and UDLD, Layer 1 and Layer 2 detections work together to prevent physical and logical unidirectional connections and the malfunctioning of other protocols.

UDLD works by exchanging protocol packets between the neighboring devices. In order for UDLD to work, both devices on the link must support UDLD and have it enabled on respective ports.

Each switch port configured for UDLD sends UDLD protocol packets that contain the port’s own device/port ID, and the neighbor’s device/port IDs seen by UDLD on that port. Neighboring ports should see their own device/port ID (echo) in the packets received from the other side.

If the port does not see its own device/port ID in the incoming UDLD packets for a specific duration of time, the link is considered unidirectional. Once the unidirectional link is detected by UDLD, the respective port is disabled and this message is printed on the console and the logging:

UDLD-3-DISABLE: Unidirectional link detected on port 1/2. Port disabled

UDLD can operate in two modes:

Normal: if the link state of the port was determined to be bi-directional and the UDLD information times out, no action is taken by UDLD. The port state for UDLD is marked as undetermined. The port behaves according to its STP state.
Aggressive: if the link state of the port is determined to be bi-directional and the UDLD information times out while the link on the port is still up, UDLD tries to re-establish the state of the port. If not successful, the port is put into the errdisable state.

Depending on the fiber uplink (type of cable, length of the cable, age of backbone and more) I use UDLD aggressive mode. Aggressive mode will put the port in errdisable, but in my opinion it is better to loose some switches then flooding the complete layer 2 network and disturbing even more users.

PIX / ASA – Threat Detection

From software release 8.0 and later the Cisco PIX and Cisco ASA firewalls support the feature called Threat Detection. In the default configuration Basic Threat Detection is enabled on the security appliance.

Using Threat Detection the appliance monitors the rate of dropped packets and security events due to these reasons (Source):

Denial by access lists;
Bad packet format (such as invalid-ip-header or invalid tcp-hdr-length);
Connection limits exceeded (both system-wide resource limits, and limits set in the configuration);
DoS attack detected (such as an invalid SPI, Stateful Firewall check failure);
Basic firewall checks failed (This option is a combined rate that includes all firewall-related packet drops in this bulleted list. It does not include non-firewall-related drops such as interface overload, packets failed at application inspection, and scanning attack detected.);
Suspicious ICMP packets detected;
Packets failed application inspection;
Interface overload;
Scanning attack detected;
Incomplete session detection such as TCP SYN attack detected or no data UDP session attack detected;

When the security appliance detects a threat a syslog message is send. These syslog messages have the following format:

%ASA-4-733100: Object drop rate rate_ID exceeded. Current burst rate is rate_val per second, max configured rate is rate_val; Current average rate is rate_val per second, max configured rate is rate_val; Cumulative total count is total_cnt

Basic Threat Detection affects the performance of the security appliance only when there are drops or potentials threats. I have monitored the CPU with Basic Threat Detection enabled and disabled in an environment with many deny hits on the outside interface, resulting from port scans and (D)DoS attacks. The performance impact on the security appliance is insignificant.

The security appliance has also the option to actively scan all traffic and shun connections if threats rates are exceeded. The security appliance tracks two types of rates:

the average event rate over an interval;
the burst event rate over a shorter burst interval;

More information about configuring Threat Detection can be found in the Cisco Security Appliance Command Line Configuration Guide, 8.0 and more specific the chapter Preventing Network Attacks.

In my own experience with Cisco PIX and Cisco ASA firewalls running software release 8.0 and later, I normally disable Basic Threat Detection. Often I receive questions from customers about the syslog messages generated by Basic Threat Detection. Customers always think that something is terribly wrong with the security appliance. For some customers I enabled Basic Threat Detection in conjunction with the Scanning Threat Statistics. Enabling the statistics give you more detailed information about the discovered threat rates. The statistics can be viewed via the Firewall Dashboard when using ASDM or with various show commands using the CLI. Below the output of the command show threat-detection rate.

Average(eps)    Current(eps) Trigger    Total events
10-min ACL drop:                  1               0       0            119
21-hour ACL drop:                  2               1       0          7556
10-min SYN attck:                  0               0       0            436
1-hour SYN attck:                  0               0       0           2863
10-min Scanning:                 12               9   31963            721
31-hour Scanning:                 20              11   21622         74264
10-min Bad pkts:                  0               0       0            107
1-hour Bad pkts:                  0               0       0            682
10-min Firewall:                  2               1       0           1299
1-hour Firewall:                  2               1       0           8238
10-min Interface:                 10               0       0           6314
1-hour Interface:                 10              10       0          37220

Enabling the use of statistics could have a bad influence on the performance from the PIX / ASA. Especially the memory usage can increase enormously. With Basic Thread Detection, there is also an option for actively scanning all traffic and shun the traffic when certain threshold are reached. Shunning the traffic is accomplished by adding a policy rule to the configuration. This rule is added to the configuration automatically and stays even after a reboot.

I talked with a Cisco engineer about this feature and he advized me not to use Basic Thread Detection with the scanning feature. The feature is rather new and needs a lot of tweaking, because this functionality can basically be compared with Intrusion Detection and Intrusion Prevention System. The engineer also stated that the gathering of statistics can have an influence on the memory usage of the box. Therefore he also advized to only use the statistics feature in certain environments and circumstances.