D.2.1.Displaying a routing table withip route show
In its simplest form,ip routecan be used to display the main routing table output. The output of this command is significantly different from the output of theroute. For comparison, let’s look at the output of bothroute -nandip route show.
ExampleD.11.Viewing the main routing table withip route show
[root@tristan]#route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface192.168.99.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo0.0.0.0 192.168.99.254 0.0.0.0 UG 0 0 0 eth0[root@tristan]#ip route show192.168.99.0/24 dev eth0 scope link 127.0.0.0/8 dev lo scope link default via 192.168.99.254 dev eth0
If you are accustomed to therouteoutput format, theip routeoutput can seem terse. The same basic information is displayed, however. As with our former example, let’s ignore the 127.0.0.0/8 loopback route for the moment. This is a required route for any IPs hosted on the loopback interface. We are far more interested in the other two routes.
The network 192.168.99.0/24 is available on eth0 with a scope of link, which means that the network is valid and reachable through this device (eth0). Refer toTableC.2, “IP Scope underip address”for definitions of possible scopes. As long as link remains good on that device, we should be able to reach any IP address inside of 192.168.99.0/24 through the eth0 interface.
Finally, our all-important default route is expressed in the routing table with the word default. Note that any destination which is reachable through a gateway appears in the routing table output with the keywordvia. This final line matches semantically with the final line of output fromroute -nabove.
Now, let’s have a look at the local routing table, which we can’t see withroute. To be fair, it is usually completely unnecessary to view and/or manipulate the local routing table, which is whyrouteprovides no way to access this information.
ExampleD.12.Viewing the local routing table withip route show table local
[root@tristan]#ip route show table locallocal 192.168.99.35 dev eth0 proto kernel scope host src 192.168.99.35 broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1 broadcast 192.168.99.255 dev eth0 proto kernel scope link src 192.168.99.35 broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1 local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1 local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
This gives us a good deal of information about the IP networks to which the machine is directly connected, and an inside look into the way that the routing tables treat special addresses like broadcast addresses and locally configured addresses.
The first field in this output tells us whether the route is for a broadcast address or an IP address or range locally hosted on this machine. Subsequent fields inform us through which device the destination is reachable, and notably (in this table) that the kernel has added these routes as part of bringing up the IP layer interfaces.
For each IP hosted on the machine, it makes sense that the machine should restrict accessiblity to that IP or IP range to itself only. This explains why, inExampleD.12, “Viewing the local routing table withip route show table local”, 192.168.99.35 has a host scope. Becausetristanhosts this IP, there’s no reason for the packet to be routed off the box. Similarly, a destination of localhost (127.0.0.1) does not need to be forwarded off this machine. In each of these cases, the scope has been set to host.
For broadcast addresses, which are intended for any listeners who happen to share the IP network, the destination only makes sense as for a scope of devices connected to the same link layer[49].
The final characteristic available to us in each line of the local routing table output is thesrckeyword. This is treated as a hint to the kernel about what IP address to select for a source address on outgoing packets on this interface. Naturally, this is most commonly used (and abused) on multi-homed hosts, although almost every machine out there uses this hint for connections to localhost[50].
Now that we have inspected the main routing table and the local routing table, let’s see how easy it is to look at any one of the other routing tables. This is as simple as specifying the table by its name in/etc/iproute2/rt_tablesor by number. There are a few reserved table identifiers in this file, but the other table numbers between 1 and 252 are available for the user. Please note that this example is for demonstration only and has no intrinsic value other than showing the use of thetableparameter.
ExampleD.13.Viewing a routing table withip route show table
[root@tristan]#ip route show table specialError: argument "special" is wrong: table id value is invalid[root@tristan]#echo 7 special >> /etc/iproute2/rt_tables[root@tristan]#ip route show table special[root@tristan]#ip route add table special default via 192.168.99.254[root@tristan]#ip route show table specialdefault via 192.168.99.254 dev eth0
In the above example you get a first glance at how to add a route to a table other than the main routing table, but what we are really interested in is the final command and output. InExampleD.13, “Viewing a routing table withip route show table”, we have identified table 7 by the name "special" and have added a route to this table. The commandip route show table specialshows us routing table number 7 from the kernel.
ip routeconsults/etc/iproute2/rt_tablesfor a table identifier. If it finds no identifier, it complains that it cannot find a reference to such a table. If a table identifier is found, then the corresponding routing table is displayed.
The use of multiple routing tables can make a router very complex, very quickly. Using names instead of numbers for these tables can assist in the management of this complexity. For further discussion on managing multiple routing tables and some issues of handling them seediv10.3, “Using the Routing Policy Database and Multiple Routing Tables”.
你在雨中行走，你从不打伞，你有自己的天空，它从不下雨。
