7. RIP Assessment
Prev Internal Routing Next

7. RIP Assessment

Using RIP is actually very simple. Most of the time will likely be spent waiting for the routing tables to converge to a stable solution.

Important

Don’t forget that you need to remove any static routes from the routers R1-3 before you start on this section.

7.1.

Configure the routers for use with RIP. You must refer to the Vyatta documentation to find out how to do this.

Tip

You will find you have a choice between advertising a “network” or an “interface”. In this case, advertising the “interface” is preferable, because it means that it will use the address assigned to a particular interface. This could reduce typing mistakes, but could also make it harder to check if you have many interfaces, as Vyatta doesn’t allow for easily renaming interfaces.

7.2.

Observe RIP traffic using tcpdump. Listen on R3’s eth0.20 or eth0.30 interface. You will notice that the some routes appear to be missing in the advertisements. Explain why this happens.

7.3.

Go back into configuration mode, and enable poison-reverse using the configuration command set interfaces ethernet ethX vif Y ip rip split-horizon poison-reverse for each interface on each router.

Using tcpdump as before, what has changed?

7.4.

Rather than using the system command tcpdump, as was done in the previous questions, we can get a lot more debugging information from Vyatta itself. Investigate which debugging commands might be useful for showing what advertisements are being received.

Note that show log tail is a particularly important command for actually seeing the logs, but it is unfortunately not at all obvious when reading the documentation for the debug commands related to RIP and others.

Be aware that it order to stop debugging output being produced, you will want to use no debug … instead of debug …. The arguments need to be the same. You can use show debugging rip to see what debugging options are enabled.

7.5.

In VirtualBox, we can connect and disconnect adaptors from a machine reasonably easily. In the bottom part of a VirtualBox VM window, you can click on the network icon to unplug or plug an interface. This is the same as plugging or unplugging a cable. We’re going to use this feature to disconnect the 192.168.4.0/24 network from R1, and see how long it takes for R2 to learn of the outage.

To see modifications to the kernel’s routing table on R2, we shall use the system command ip monitor (look back to the early lab where tools such as ifconfig were introduced). In modern versions of Vyatta that feature the FusionCLI interface, we can enter shell commands as well as Vyatta commands; only the Tab completion shows Vyatta commands, never shell commands.

  1. In operator mode (ie. not configuration mode) run show log tail on R1; we should see a notification here when we unplug the interface.

  2. On R2, run ip -timestamp monitor. This will start reporting for changes to the routing table.

  3. On R1, un-tick the Adaptor 1 interface so it becomes unplugged, a log will be printed on-screen.

  4. On R2, there will shortly be a message reporting the change. Note the time it took; the clocks will be synchronised, so use the timestamps from both machines.

  5. That was fail-over. Re-enable the interface on R1. Measure how long it takes to fail-back.

What were the fail-over and fail-back times? What improvement to basic RIP is being used here?

7.6.

The previous exercise simulated a situation whereby the isolation occured on the far side of a router, and the router could therefore tell us about it. Let’s now simulate a fault on the near side of the router where the router R1 is cut-off from the routers R2 and R3.

Consider the physical topology diagram shown earlier. If you disconnect Apaptor 2 (ie. eth1) on R1, both the 192.168.1.0/24 and 192.168.2.0/24 network links on R1 would be useless (which are build from VLANs that go over the same cable). Therefore, if Adaptor 2 goes down, it completely separates the network.

Try it; take down Adaptor 2 on R1, and measure how long it takes for R2 to respond by removing routes for those prefixes which are no-longer reachable.

How long does this take? What prefixes are removed from R2’s routing table? Put the interface back, how long does fail-back take?

7.7.

In the previous exercise, it took R3 a while to realise that it hadn’t received a message from R1 for a while and to place it in the “hold-down” state, which allows it to ignore updates about this route for a while in order to let any old routing information expire from the network. In this scenario, we are going to simulate a routing problem whereby this time the routers can route around the problem.

On R2, quit out of ip monitor using Control-C and use the operational command show ip route to observe the current state of the routing table (our “steady-state”). Then start ip -timestamp monitor to watch for R2’s reaction to the change we are about to make.

Simulate the network failure by withdrawing RIP on the eth1.10 interface of the router R1. You can do this using the command delete protocols rip interface eth1.10 and then committing your change. Use the command date immediatly after to determine when you made the change. Remember that the clocks on R1 and R2 are running on the same host, and are implicitly synchronised.

When you see R2’s reaction, quit the monitor and observe the routing table again. How has it changed (look closely to which next-hop is being used for each network)? Ensure you can describe the meaning of any changes. Was an alternative route used immediately by R2, or was there some gap? How long was the gap?

Start the monitor again and allow R1 to participate in RIP on eth1.10 again. Don’t forget to commit the change and run date. How long does it take for R2 to fail back to the optimal path?

Prev Up Next
6. TCPDump Home 8. [Optional] Connecting to the Outside World