This webpage addresses encountered problems and potential questions about the lab hardware, the lab configuration, and the lab experiments in the book. Report new problems, with solutions (if available) by sending email to jorg@comm.utoronto.ca.
It is recommended to use Ethernet hubs instead of Ethernet switches, for the following reason: In some lab exercises, two machines are connected by a hub, and a third machine "eavesdrops" on this traffic and displays the traffic. 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 connected by Ethernet and we need to observe traffic between the two). The other exercises still work if you use an Ethernet switch.
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, but the configuration depends on the brand of the Ethernet card. One can avoid the above issue 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.
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)
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, and prevents the mouse from working properly. Changing the XFree86 configuration (adding a keyword that
dynamically sets the mouse configuration to "Auto" mode), does
not fix the mouse problem consistently.
IOGEAR KVMs, specifically, the IOGEAR's 4PORT MINIVIEW SE KVM PS2 switches
seem to work better.
(Source: Armen Babikya, UMass)
On the Fedora Core 3 distribution of Linux, where the default zebra package included in the distribution is 0.97.0, the following problem has been observed. Even when the ripd deamon is running and exchanging 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))
Problem: Reproducing the count-to-infinity problem on Cisco 2621's running IOS "12.2(5d) Release Software fc1". The problem lies in the fact that flash-update-threshold seems to do nothing with regards to disabling triggered updates. As soon as a router with "triggered updating disabled" receives a new message, it immediately (within 2-3 seconds) redistributes this information to the other routers on its other connected link.
Solution: (for Cisco 2611 with IOS v12.0). The problem may be that the flash update does not show as disabled, probably, due to the version of IOS. Try this interface command"no ip rip triggered" to disable triggered updates. This command is introduced in running Cisco IOS Release 12.0(1)T. Also, make sure the holddown timer is set to 0. e
(Source: Sun Woo Kim, UC Irvine)
A Problem has been observed for Intel Pro 100+ Nics. See here.
Problems: (Since these problems were only found recently, they may not show in older versions of dhcpd.)
- In Lab 7 part 2(D), the DHCP server on PC2 does not send a reply back to the relayed DHCP request from PC3. This happens since the DHCP server does not bind to an interface for which no subnet is defined in the configuration file. Note that this is reported as a warning by the server when you are trying to start it. Since the experiment does not ask you in Table 7.7 to add subnet 10.0.2.0/24 to the DHCP configuration, the DHCP server does not bind to the eth1 interface and consequently ignores incoming requests on that interface, even if relayed from other subnets.
(Source: Kent Sebastian, UofT, 2009)
- The dhcpd server gives an error that the "dhcpd.leases" file is missing.
(Source: Kent Sebastian, Richelle Bernardo, Anahita Panthaky, UofT, 2009)
Solutions:
- Add the following lines to the dhcpd.conf file:
subnet 10.0.2.0 netmask 255.255.255.0{
}
- Create the file "dhcpd.leases" with the command:
touch /var/lib/dhcp/dhcpd.leases