Internet Lab Manual: Frequently Asked Questions

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.

Problems with Lab Experiments

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.

Addendum from August 2007:
It has become very difficult to locate a vendor of new 100 Mbps Ethernet hubs.

The following issue is only relevant to lab set ups with Cisco 25xx routers
or other routers that have 10 Mbps Ethernet interfaces.

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.

This Belkin switch is a PS3 switch for older PCs which have PS2 ports for keyboard and 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, 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.

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.

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

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.