CAL Switches

CAL has 5 modern Gbit switches, located across the 10th, 13th, and 14th floors (see also "Direct connections to CUIT Gbit switch" below). They are:

  • tempel1 (10th floor, IP 128.59.168.37, serial number 16B2584V008D4)
  • shoemaker-levy9 (10th floor, 128.59.168.38, serial 16B2594S00052)
  • borrelly (10th floor, 128.59.168.39, serial 16B2594T00053) - disconnected
  • halley (12th floor, 128.59.168.46, serial 16B2584H00B18) - disconnected
  • hyakutake (13th floor, 128.59.168.48, serial 16B2584T008D2)
  • hale-bopp (13th floor, 128.59.168.47, serial 16B2584U008D3)
  • wild2 (14th floor, 128.59.168.49, serial 16B2584S008D1)

They are all netgear GS724Tv2 24-port switches. (See note on 'v2' below.)

The switches' administrative interfaces should only be accessed from squeak, wombat, canada, phobos, or neptune.

We used to have three netgear GS748T 48-port switches.

Both of these models of switch are IP-addressable, and have a web interface to view/configure them.

However, the 48-port switches are buggy, and we've returned them all. They were all running firmware V1.3.0_0606, which netgear claims to be the latest version of their firmware. Problems include:

  • the switch becomes unresponsive on its IP interface after some period of time running. in a recent test, fernando and dkg reset all the switches at around 18:10 on 2006-01-24, and around 20:30, they all stopped responding to pings.
  • their web interface does not speak valid HTTP, even version 1.0. there are no server response codes at all, the configuration page is just dumped directly into the bytestream. If you have netcat (nc) installed, and $SWITCH is the IP address of one of these switches, try the following to emulate an extremely simple http connection:
     echo "GET /" | nc $SWITCH 80
    

Note, of course, that if the switch has already failed, you'll get no output at all.

compare the above command when connecting to a known-good web server (or even to a GS724T) if you want to see valid HTTP response. Here's what i see:

[dkg@squeak ~]$  echo -e "GET /" | nc $GS724T 80
HTTP/1.0 200 OK
Content-type: text/html

<HTML>
<HEAD>
<TITLE>NETGEAR Web Smart Switch</TITLE>
</HEAD>
<FRAMESET frameBorder=no frameSpacing=0 rows=109,*>
    <FRAME name=top scrolling=no src=/top.html>
    <FRAMESET cols=210,* frameBorder=no frameSpacing=0>
        <FRAME name=left src=/left.html>
        <FRAME name=main src=/cgi/device>
    </FRAMESET>
</FRAMESET>
</HTML>
[dkg@squeak ~]$  echo -e "GET /" | nc $GS748T 80
<html>
<title>NETGEAR Web Smart Switch</title>
<frameset rows='109,*' framespacing=0 frameborder=no>
 <frame name=top src=top.htm scrolling=no>
 <frameset cols='210,*' framespacing=0 frameborder=no>
  <frame name=left src=left.htm noresize>
  <frame name=main src=cgi_login noresize>
 </frameset>
</frameset>
</html>[dkg@squeak ~]$

The former response is a valid http response. the latter is not. however, when analyzing the behavior of many HTTP servers, the latter style of response is actually very common (especially to the extremely crude, unversioned example HTTP request). i'm no longer sure that this http mis-speech is a major bug, but it certainly seems sloppy.

If you are not comfortable with netcat, you can use telnet to perform similar testing (though you'll have to do it interactively instead of piping in echo, since telnet will close the session on termination of stdin).

During the times when the switch is no longer responding to its IP address, it also stops responding to whatever queries are used by the "smartwizard" autodiscovery agent shipped for windows (their tech suggested that they might be using NetBIOS discovery, but i haven't bothered to sniff that traffic yet).

Fortunately, the switch continues to pass regular traffic in this situation. However, plugging a computer into a previously-unused port on the switch once it is in this moribund state leaves the new machine unable to acquire a DHCP address. Haven't tried using a statically-configured IP address on such a dead port yet. perhaps the switch's internal arp cache is no longer being updated?

Note on 'v2': the 24-port switches are GS724Tv2 - you can only find out about the v2 if you look at the label at the bottom of the switches - it's not printed on the front plates! The version of firmware is V1.0.0_0429. This is not even mentioned in the page for updates on this switch - rather, they list V1.01. And yet, the switches seem to be working... so, we have no present need (or desire) to update to latest firmware!

In addition to the above 7 switches, there is an ancient 10Mbit Cisco switch (with one 10/100 uplink port) installed in the utility closet on the 13th floor. Its IP is 128.59.168.35. Only a few of its ports have traffic, as follow: 13 (room 1322); 14 (1022); 15 (1329); 17 (1016); 18 (1018). This switch uplinks to the 12th floor switch at half-duplex 100Mbit via a green cable.

network diagram

here's a rough ASCII-art diagram of the current network topology (subject to change):

     CUITa upstream   CUITb upstream
            |          |
            |          |
            |          |
(100Mbit) PHYS9       CUIT11 (Gbit)
            |          |
            |          |<--- new line
 old line-> X          |
  (gone)    | CAL10b--CAL10a--CAL10c
            |          |
            ----------CAL12-----CAL13(utility closet)
                     /  /  \
                    /  /    \
               CAL13a CAL13b CAL14

At the moment, the "old line" is not present, but the "new line" is. i think it's also possible that the CUITa upstream and the CUITb upstream connections are both actually the same place.

Direct connections to CUIT Gbit switch

CUIT maintains a Gbit switch in a closet inside the 'Nevis Annex' on the western end of the 11th floor in Pupin.

As of summer 2006 we are implementing a project whereby all CAL offices that aren't directly connected to one of our internal Gbit switches described above will be connected directly to the CUIT switch. This will replace many of two sorts of connections: (1) those linked directly to an old 10Mbit/s CUIT switch in the basement; (2) those using jury-rigged setups laid between offices that eventually, after passing through 100Mbit/s mini-switches, end up in one of our internal switches.

At the same time we will also be connecting most of our internal Gbit switches directly to the CUIT switch, thereby making each floor more independent as far as stability of connections, compared to the present situation. The above wiring diagram will change when this occurs.

The new project should therefore result in improved speed and reliability for many users. Also, maintenance and upgrade of this Gbit switch will be the responsibility of CUIT.

We hope to have this project completed around the beginning of the Fall 2006 semester.

The connections to this switch will be (see ticket #264):

Floor Room New Jack Jack # # Live
10 1001 1 1026 3
10 1004 1 1027 3
10 1007 1 1028 3
10 1008a 1 1029 4
10 1008c 2 1031/32/25 4+4+2
10 1009 1 1033 3
10 1010 1 1034 4
10 1011 1 1035 4
10 1012 1 1036 3
10 1016 1 1037 2
10 1018 1 1038 2
10 1020 1 1039 3
10 1022 1 1040 3
10 1024 1 1041 2
10 1026 1 1042 2
10 1031 1 1043 4
10 1027 1 1044 3
12 1220 1 1216 4
12 1216 1 1217 3
12 1210a 1 1218 3
12 1210b 1 1219 3
12 1210c 1 1221 3
13 1322 1 1303 3
13 1327 1 1304 4
13 1329 1 1305 3
13 1334 1 1306 4
13 1333 2 1307/08 4+2
14 1421 1 1401 4
14 1420 2 1402/03 4+4
14 1418 1 1404 4
14 1414 2 1405/06 4+4
14 1410 2 1407/08 4+4
14 1409 1 1409 2
14 1402 1 1410 4
Totals: 39 132 total