Posts tagged ‘switch’

As a follow up on my previous article with the WRT320N, here’s my journey for the WRT610N revision 2 (which is very similar, but has two radio’s).

Continue reading ‘Converting a WRT610N to dd-wrt’ »

I bought myself a new WiFi router. When in the shop, I specifically searched for a router that is supported by dd-wrt, and has (at least) 8MB of flash. I settled for the Linksys WRT320N: it has a dual band (switchable between 2.4GHz and 5GHz, not simultaneous) 802.11a/b/g/n radio, a 4 port GbE switch, and a WAN port. It houses a Broadcom BC4717 processor running at 354MHz, 8MB of flash and 32MB of RAM.

The default Linksys firmware is actually not bad, but dd-wrt just offers a ton more features: Multiple SSIDs, IPv6 support (including Sixxs tunneling), WAN volume monitoring, custom firewalling, traffic shaping, … So I decided to void my warranty and put my router on steroids! Mandatory note: this may very well turn your router in to a very expensive brick.

Continue reading ‘Converting a WRT320N to dd-wrt’ »

Everyone that has used the Cisco IOS command line knows this problem. When you mistype a command, the router tries to resolve the “hostname” and you have to wait for 24 very long seconds:

Translating "conft"...domain server (
Translating "conft"...domain server (
% Unknown command or computer name, or unable to find computer address

Until recently I used the “no ip domain-lookup” configuration entry to counter this. This disables DNS-lookups altogether, which might not always be what you want. I recently found the proper solution to fix this:

Continue reading ‘Avoiding the typo penalty in Cisco IOS’ »

I was bored of constantly looking for updates on a website. A little googling turned up this nice site. It turns (a part of) a webpage into an RSS feed. Here are the ones I created:

Cisco switches are very verbose in their layer 1 error reporting as shown in the output below:

FastEthernet0/1 is down, line protocol is down
  Hardware is Fast Ethernet, address is 0030.94bd.4041 (bia 0030.94bd.4041)
  MTU 1500 bytes, BW 0 Kbit, DLY 100 usec, rely 255/255, load 1/255
  Encapsulation ARPA, loopback not set, keepalive not set
  Duplex setting unknown, Unknown Speed, 100BaseTX/FX
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input never, output 00:35:31, output hang never
  Last clearing of "show interface" counters never
  Queueing strategy: fifo
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     1 packets input, 64 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     0 watchdog, 0 multicast
     0 input packets with dribble condition detected
     3 packets output, 444 bytes, 0 underruns
     0 output errors, 0 collisions, 1 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

On this page on the Cisco website, there is a table listing all error counters and their meaning for Ethernet interfaces.

When troubleshooting a slow network connection I wanted to get an idea of the link load. Usually I power up my linux-based Virtual Machine which polls the SNMP interface counters and draws nice graphs. But I was working remotely over an RDP connection, so SNMP was not possible.

So I had to use the build-in tools of the ProCurve switch. The “show interface” output looks like this:

Status and Counters - Port Counters for port 24

  Name  :
  Link Status     : Up
  Totals (Since boot or last clear) :
   Bytes Rx        : 819,265,344        Bytes Tx        : 1,217,179,587
   Unicast Rx      : 4,052,391          Unicast Tx      : 5,062,876
   Bcast/Mcast Rx  : 1,142,020          Bcast/Mcast Tx  : 7,390,717
  Errors (Since boot or last clear) :
   FCS Rx          : 0                  Drops Rx        : 0
   Alignment Rx    : 0                  Collisions Tx   : 0
   Runts Rx        : 0                  Late Colln Tx   : 0
   Giants Rx       : 0                  Excessive Colln : 0
   Total Rx Errors : 0                  Deferred Tx     : 0
  Rates (5 minute weighted average) :
   Total Rx  (bps) : 501944             Total Tx  (bps) : 504256
   Unicast Rx (Pkts/sec) : 0            Unicast Tx (Pkts/sec) : 0
   B/Mcast Rx (Pkts/sec) : 0            B/Mcast Tx (Pkts/sec) : 4
   Utilization Rx  : 00.04 %            Utilization Tx  : 00.04 %

Note the values on the bottom indicating the “Rates”? They’re not what they claim to be! This particular interface has approximately 1kbps input (Rx) and 3kbps output (Tx); not exactly the 500kbps the output claims. Also, try to explain how to receive 502kbps of data with less than 1 packet per second…

This particular switch is a 2610-24PWR with firmware R.11.16; but it’s probably a more general problem.

To deal with loops in switched networks, the Spanning Tree Protocol was developed. For a description of how STP works, see the Wikipedia page on the subject; in short, it disables certain ports on certain switches to break loops. So far so good.

When using VLANs, there are several alternatives:

  • Use a Common Spanning Tree: i.e. use the same topology for all VLANs.
  • Use Per Vlan Spanning Tree: i.e. run a separate STP instance for each VLAN.
  • Use Multiple Spanning Tree: This is the IEEE standard and is a compromise.

In MST, VLANs can be mapped to instances. All VLANs mapped to the same instance share the same Spanning Tree. This allows some flexibility by using multiple instances, without the CPU problems of running a single instance for each and every VLAN.

Now consider the following situation:

This diagram uses only 2 VLANs: a data VLAN, drawn in blue, and a management VLAN, in red. The data VLAN is used to connect the Left and Right switch together, along with the attached servers. The management VLAN is only used to manage the switches.

When implementing this on Cisco switches (I tried it on Catalyst 3750s), everything works as expected. The two servers can talk to each other, both switches are manageable.

When implementing this on HP ProCurve switches (I tried it on 5400s, 2610s and 2810s), this does not work: Depending on the MAC-addresses of the switches, either the servers cannot talk to each other or one of both switches is disconnected from the management station…

Continue reading ‘HP ProCurve: MST misbehaves’ »