Configuring a Second Router on a Static Network
Given a small static network with one router and 2 computers, you may need to add a second router. You are not putting any computers on the middle segment; you would encounter this typical configuration if you were to lease a private link or virtual circuit from your telephone company or if you were routing over an internal backbone connection on your network.
In this case, the networks you want to route between (containing Computer1 and Computer2) are not directly connected to a single router; rather, one segment is directly connected to each router on your network. Note that you would normally configure each computer to use the local router as the default gateway, so this is expected in this scenario.
When you issue a command such as ping to test the connection to the remote computer whose IP address is 192.168.5.10, the computer performs the logical AND process on your IP address and the remote IP address using the subnet mask. In this case, the AND process identifies the destination address as a remote address.
In all cases where the address is remote, the computer consults its local routing table. In this case, nothing is in the local routing table other than the default routes and the route to the default gateway. Because no routes are closer, the computer uses the “catch all” route through the default gateway.
When the ping command goes through, the results resemble the following. The error may be that the destination host is unavailable. Or it may be that the entire destination network is unavailable because the router at 192.168.1.1 does not know how to get to the destination network segment.
C:>ping 192.168.5.10 Pinging 192.168.5.10 with 32 bytes of data: Reply from 192.168.1.1: Destination host unreachable. Reply from 192.168.1.1: Destination host unreachable. Reply from 192.168.1.1: Destination host unreachable. Reply from 192.168.1.1: Destination host unreachable. Ping statistics for 192.168.5.10: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 1ms, Average = 0ms
The following code does two things. First, it enables routing on the router, which is necessary even to have routing on the two-segment network (this is not a default setting; you must instruct a router to route when there is more than one interface). Second, it adds a route to the 192.168.5.0 network segment (see Figure 4-2 for an illustration).
Router1>enable Password: Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#ip routing Router1(config)#ip route 192.168.5.0 255.255.255.0 192.168.3.2 Router1(config)#exit
When you use the ping command, the remote computer at 192.168.5.10, you receive a slightly different error. The following error can have several causes. In general, Request timed out error means that the routers know how to get the data to its destination (otherwise you have the destination errors from the previous use of ping), or at least they think they do.
C:>ping 192.168.5.10 Pinging 192.168.5.10 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 192.168.5.10: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 1ms, Average = 0ms
If you have an issue with your routing tables, perhaps a router using the default gateway rather than the static route you should have configured, you might see the preceding error because the routers think they can route the data through to its destination.
You may also see this error if the routes to the destination network are correct, but the routers on the reverse path are not correctly configured. The traceroute command may give you a little more information as to the nature of the error. In the following example, the Windows version of traceroute (tracert) is configured to trace the route for only four hops using the –h 4 option to modify the command.
D:utils>tracert –h 4 192.168.5.10 Tracing route to 192.168.3.1 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms 192.168.1.1 2 * * * Request timed out. 3 * * * Request timed out. 4 * * * Request timed out. Trace complete.
This code indicates only that your computer’s routing table is correct and that you passed the data on to your local router. Does your router know where to go from there? You still cannot be sure. You can connect to your router and verify the route, and then you can use ping to test the destination router and attempt to use traceroute to test the destination address, which shows you the router’s route to the destination:
Router1>enable Password: Router1#show ip route static S 192.168.5.0/24 [1/0] via 192.168.3.2 Router1#ping 192.168.3.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.3.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms Router1#traceroute 192.168.5.10 Type escape sequence to abort. Tracing the route to 192.168.5.10 1 192.168.3.2 0 msec 0 msec 4 msec 2 192.168.5.10 0 msec 4 msec 0 msec
If you are using these commands at the router, in my case Router1, you can receive replies, but you cannot get replies from Computer1, which is behind Router1. Because the commands work from Router1, you can be pretty sure that Router1 has the proper routes.
Think about the difference between the source addresses used for Computer1 and Router1. To Router2 and Computer2, the source address of Computer1 is 192.168.1.10, and Router1 is 192.168.3.1. So the source address is the difference, because Router2 knows how to get to 192.168.3.1, but does not know how to get to 192.168.1.10.
The net result is that you cannot communicate from Computer1 to Computer2, but what is the real reason? With the testing that was done, the route to the 192.168.5.0/24 network, so the problem is with the return trip.
Effectively, if you were to use the ping command on Computer2 to test the address of Computer1, you would see the same thing you saw when this exercise started — the results would be either Destination net unreachable or Destination host unreachable. The solution is to get the correct route in place for that data to get back to Computer1 and ensure that IP routing is enabled giving you a network that looks like the following figure.
Because the last test completed successfully, you are sure that the ip routing command had already been run in Global Configuration mode, since if it was not enabled you would not have received any results.
Router2>enable Password: Router2#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router2(config)#ip routing Router2(config)#ip route 192.168.1.0 255.255.255.0 192.168.3.1 Router2(config)#exit
Now to test the connection, go back to the original use of the ping command to test what was done at the very beginning. The result is now successful. You now have a valid route to and from the 192.168.5.0/24 network.
C: >ping 192.168.5.10 Pinging 192.168.5.10 with 32 bytes of data: Reply from 192.168.5.10: bytes=32 time=1ms TTL=253 Reply from 192.168.5.10: bytes=32 time<1ms TTL=253 Reply from 192.168.5.10: bytes=32 time<1ms TTL=253 Reply from 192.168.5.10: bytes=32 time<1ms TTL=253 Ping statistics for 192.168.5.10: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 1ms, Average = 0ms
When you examine the tracert again, success!
C:>tracert -h 4 192.168.5.10 Tracing route to 192.168.5.10 over a maximum of 4 hops 1 <1 ms 1 ms <1 ms 192.168.1.1 2 26 ms 17 ms 21 ms 192.168.3.2 3 9 ms 9 ms 14 ms 192.168.5.10 Trace complete.
The routing is now set up for a small network.
As the network grows, it will be become more complex with more routes that need to be configured and maintained.