Booches.nl

Telnet Time-Out is killing me….

Aaarrrgggghhh, I hate it when I would like to telnet into a device and enter the wrong IP address. This means, by default, waiting for 30 seconds before being able to correct the IP address and start a new telnet session, because there is no escape sequence.

SW01#telnet 10.100.12.250
Trying 10.100.12.250 …
% Connection timed out; remote host not responding

Luckily there is a command to lessen the time for timing out the connection:

SW01(config)# ip tcp synwait-time <seconds>       (Set time to wait on new TCP connections)

Hoera, tcp synwaiting saves the day….

What is an UPLINK port?

A colleague recently encountered some problems with keepalives on switch ports. He wrote a post about it. Keepalives are, quoted from his blog post:

By default Cisco routers and switches periodically test their (Fast) Ethernet links by sending out Loopback frames (ethertype 0×9000) addressed to themselves. Call it a “L2 self-ping” if you will. In a switched environment it can be used to test the functionality of the switch and/or keep the router’s MAC address in the switch’s address table. Another thing what this Loopback frames do, is to check for a loop. If there is a loop in the network, the resulting Loopback frame will be seen by the sending switch and the port will be err-disabled.

Cisco says that starting in 12.2SE based releases, keepalives are NO longer sent by default on fiber and uplink interfaces.

The big question, where I am struggling with is:

When is a port an UPLINK port?

Looking at a Cisco Catalyst 2960-24PC-L I get the following information about the keepalives information on the interfaces.

SW01#sh int | i 0/23|0/24|GigabitE|Keep

FastEthernet0/23 is down, line protocol is down (notconnect)
  Keepalive set (10 sec)
FastEthernet0/24 is down, line protocol is down (notconnect)
  Keepalive set (10 sec)
GigabitEthernet0/1 is up, line protocol is up (connected)
  Keepalive not set
GigabitEthernet0/2 is up, line protocol is up (connected)
  Keepalive not set

The output above shows that keepalives are enabled on the FastEthernet connections by default and disabled on the GigabitEthernet connections. The GigabitEthernet connections are dual-purpose, but I don’t use the fiber connection. But because it is a dual-purpose port I can imagine that keepalives are disabled by default, because of the fiber properties.

So I looked at at Cisco Catalyst 2960-48TT-L switch with Software Version 12.2(44)SE. This switch doesn’t have any fiber connections, but only copper. From this switch I get the following keepalives information.

SW01#sh int | i 0/47|0/48|GigabitE|Keepa

FastEthernet0/47 is down, line protocol is down (notconnect)
  Keepalive set (10 sec)
FastEthernet0/48 is down, line protocol is down (notconnect)
  Keepalive set (10 sec)
GigabitEthernet0/1 is down, line protocol is down (notconnect)
  Keepalive set (10 sec)
GigabitEthernet0/2 is up, line protocol is up (connected)
  Keepalive set (10 sec)

The output tells me that keepalives are enabled on all switch ports. GigabitEthernet0/2 is configured as a trunk port, so now I am very confused.

I draw the following conclusions:

1. Keepalives are disabled on uplink and fiber ports starting in 12.2SE releases. GigabitEthernet0/2 from the 48TT-L switch is configured as a trunk port. So a trunk port doesn’t mean the same as an uplink port;
2. The “special” ports on the right side of a switch are no uplink ports, because else GigabitEthernet0/2 from the 48TT-L switch would have keepalives disabled;

After drawing these conclusion I still don’t know the exact definition of an UPLINK port :-(. Please let me know if you have any suitable definition for an UPLINK port………

Alias IOS Command

When configuring a router I often use different show commands to check or troubleshoot the configuration. I always hate to type in the whole show command, so I use aliases instead. Aliases are also used in the Open Source community, when working with a terminal.

There are multiple options for the alias command, lets take a closer look:

• Alias exec: for Privileged Mode (for Router# prompt);
• Alias configure: for Global Configuration Mode (for Router(config)# prompt);
• Alias interface: for Interface Configuration Mode (for Router(config-if)# prompt;

Cisco IOS includes some built-in command aliases (of course, the Cisco IOS always accepts the shortest unique command). Default command aliases are for example:

Next are some alias command, which I use very often:

ALIAS EXEC

Router(config)# alias exec s show ip int brie | exclu unass

Router(config)# alias exec si show int status

Router(config)# alias exec r show run

Router(config)# alias exec rr show ip route

ALIAS CONFIGURE

Router(config)# alias configure vl1 interface vlan1

Router(config)# alias configure eigrp router eigrp 1024

ALIAS INTERFACE

Router(config)# alias interface ns no shutdown

Router(config)# alias interface load load-interval 30

DSL Terminology

When configuring DSL or other analog connection, I sometimes have problems with the specific terminologies used in these technologies.  I found a post explaining the terminology used for understanding Cisco DSL statistics. Reading this post helps me remember the terminology.

Taken from the post:

To troubleshoot Layer 1 problems, you can use the show dsl interface atm 0 command to verify that the Cisco 877 router is trained to the DSLAM. If the Cisco 877 router is successfully trained to the DSLAM, this command will also display the trained upstream and downstream speed in kbps.

 

Noise Margin (also signal-to-noise ratio)
When DSL service is provisioned in a DSLAM, the minimum acceptable noise margin is usually specified. CAP DSL service is typically provisioned with a downstream margin of 3 dB and an upstream margin of 6 dB. Research has shown that the optimum margins for DMT service are 6 dB downstream and 6 dB upstream.

 

Avoiding configuring a DSL service with more noise margin than appropriate is important because the system will train to an unnecessarily low DSL rate to provide the specified margin. It is also important to avoid specifying an exceptionally low margin, such as 1 dB downstream and 1 dB upstream because a small increase in noise level on the transmission line would probably result in excessive errors and a subsequent retraining to a lower DSL rate.

 

Increasing the transmit power levels will also improve the noise margin but at the cost of interfering with other services in the same cable.

 

Most DSLAMs and CPE report both the provisioned and actual noise margins for each DSL line. If the actual margin is higher than the provisioned margin, the line should provide an acceptable error rate at the present DSL line rate. As the actual margin drops below the provisioned margin, there is a high probability of an excessive error rate and subsequent retrain to a lower DSL rate.

 

Attenuation
Attenuation generally refers to any reduction in the strength of any type of signal, whether digital or analog. More precisely in the case of DSL, attenuation is the normal loss of signal strength over distance. Attenuation specifically is a logarithmic function of the power setting. As power increases, attenuation increases logarithmically. Also called simply loss, attenuation is a natural consequence of signal transmission over long distances. The extent of attenuation is usually expressed in units called decibels (dB).

 

Capacity Used
Percentage of the capacity that is being used.

 

Here are ranges for these values that I received from an AT&T provisioning engineer.

 

For Noise Margin: (the higher this value, the better)
8-13 Average
14-22 Very Good
23-28 Excellent

 

For Attenuation: (the lower this value, the better)
20-30 Excellent
30-40 Very Good
40-60 Average

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:

1. 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.
2. 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.