FAQ on Lab Experiments

  1. Ethernet hubs versus Ethernet switches

  2. Comment on Dual Speed Ethernet hubs

  3. Problem with some Intel Pro 100+ NICs (721283-008) in Lab 6

  4. Problem with Belkin OmniView SE Port 4 Port KVM switch<>

  5. <>Problem with Zebra on Fedora Core 3

Note: Also see the FAQ on lab experiments and the list of errata. Report new problems, if possible with solutions, by sending email to jorg@cs.virginia.edu.


1. Ethernet hubs vs. Ethernet switches

When setting up the lab equipment, it is strongly recommended to use Ethernet hubs instead of Ethernet switches.  In some  lab exercises, two machines are connected by a hub, and a third machine "eavesdrops" on this traffic and displays the trafffic using ethereal. This only works with an Ethernet hub (See the textbook p. 228).

We note that there are only a small number of exercises that are affected by this (e.g., when two Cisco routers are connnected by Ethernet and we need to observe traffic between the two). Most exercises still work if you use an Ethernet switch.


2. Comment on Dual Speed Ethernet hubs

With dual speed hubs,  devices that connect to the hub will connect either at 10Mbps or 100 Mbps. When devices connect to the same hub with different rates, i.e., some connect at 10 Mbps and others connect at 100 Mbps, then the hub performs buffering between the 10 Mbps ports and the 100 Mbps ports. Also, the hub forwards data between ports at different speeds only if the destination MAC address is at a port with a different speed.  This has two consequences. First, the hub does not necessarily create a broadcast medium (Example: Two routers with 10 Mbps Ethernet and one PC with 100 Mbps Ethernet NICs connect to the same hub. Here, the  PC cannot observe the traffic between routers). Second, there are no collisions between traffic on 10 Mbps ports and  100 Mbps ports.

The Linux PCs will generally connect to a dual-port switch at 100 Mbps and the routers (unless they have "Fast Ethernet " interfaces) connect at 10 Mbps. It is possible to force an Ethernet NIC to always run at 10 Mpbs. However, the configuration depends on the brand of the Ethernet card.

One can avoid the above issues by having only 10 Mbps ports. In this case, an Ethernet NIC detects that the hub does not run at 100 Mbps, and will switch to 10 Mbps.



2. Problem with some Intel Pro 100+ NICs (721283-008) in Lab 6

There may be a problem with Lab 6, when using some older Intel Pro 100+ NICs (with product line number Intel 721283-008). When running gbrctl (see Lab 6) on Redhat 9.0 with these cards, the PCs stall when receiving traffic. Strangely, this occurs on  Redhat 9.0 systems, but not on Redhat 8.x or earlier versions with identical hardware. Any insight on this problem is appreciated.

(Source: Jianping Wang, Matt Spear, UVA )


3. Problem with Belkin OmniView SE Port 4 Port KVM switch (frozen mouse)

On Belkin OmniView SE Port 4 Port KVM switch, when switching to a PC and finding the mouse (sometimes Keyboard also) frozen, try the command "Ctrl + Alt + F1",  which switches to text window 1 of the current PC, and  then try "Alt + F7", which will switch back to graphical window of the current PC. In most cases, it solves the frozen mouse problem.

(Source: Jianping Wang, UVA )

The Belkin OmniView SE Port 4 Port KVM Switch has notoriously bad compatibility with XFree86 with regards to mouse behavior, which ships with RedHat 9.0. On the Belkin KVM switches, switching to another PC meant that the mouse no longer  worked. A user would have to type Control-Alt-F1 to the virtual console, and then type control-alt-F7 to return back to the xserver.

The basic issue is that Belkin's KVM switch sends junk out on the PS/2 line when PCs are switched, and while MS Windows recognizes this junk and resets the mouse driver almost immediately, XFree86 does not recognize this junk, and prevents the mouse from working properly. I've tried changing the XFree86 configuration (adding a keyword that dynamically sets the mouse configuration to "Auto" mode), but it does fix the mouse problem consistently.

Just recently, our Belkin KVMs have been acting very flaky (PCs stop booting because the keyboard cannot be found). I've replaced both our  Belkin KVMs with IOGEAR KVMs, and they work MUCH better. Specifically,  the IOGEAR's 4PORT MINIVIEW SE KVM PS2 switches have exhibited no mouse  problems, which has made all the students much, MUCH happier.

(Source: Armen Babikya, UMass)


5. . Problem with Zebra on Fedora Core 3

Regarding Fedora Core 3 distribution of Linux, the default zebra
package included in the distribution is 0.97.0. We experienced a
problem with this version of zebra as follows. The problem was that
even though ripd deamon was running and exchanging the routing
updates, it (ripd and zebra) was not communicating with the Linux
kernel routing table. An upgrade to zebra 0.97.3 version fixed the
problem.

(Source: Prof. Kamil Sarac, UT Dallas)


(END)