No Title[an error occurred while processing this directive]
Reference: Cisco: Internetworking Basics
To forward packets, a router consults its routing table much like a workstation and sends the packet on its way over the appropriate interface. Where a router differs from a workstation is in what sort of traffic it will accept. When routing is enabled in the Linux kernel (also including Solaris, HP-UX, and others), the router will accept packets destined for its Ethernet address, but with IP destination headers pointing somewhere else. A machine without a router might accept these packets from the wire (because of the correct Ethernet address), but would then discard them when it discovered that they were not destined for its IP address. The router knows that its job is to forward, so it accepts the packet and examines its headers to find out where it's headed. A routing table on a router looks like this and is taken from the router depicted in the following figure:
Figure 1: Sample Router Configuration
We can tell a lot about this router by looking at the routing table (even without the aid of the illustration).
The first two entries are known as host route; they can be used to access only a single destination IP. This is denoted by the H in the Flags field, and the fact that the Genmask is 255.255.255.255 (or /32). Both of these routes have a metric of 1 and a gateway on teh 192.168.10.0/24 network, which is why the Iface is set to eth1. When the kernel encounters a packet destined for one of these exact IP addresses, it will be forwarded to the specified gateway over the eth1 interface.
The next entry is just like the entry that a workstation has for its network interface. It is a network route for the locally connected network, 192.168.10.0/24. You can tell this because the gateway is set to 0.0.0.0 (which implies a local interface), and there is a G in the Flags field. We can safely assume that the eth1 interface has an IP address in the 192.168.10.0/24 subnet. The figure confirms this; the interface is 192.168.10.1.
For those of you familiar with other Unices (other than Linux), this is one point where Linux differs. If does not need to use the IP address of the interface as the gateway for locally connected networks (although this type of configuration will also work). It automatically uses the interface listed in the Iface field. By looking at the figure, we might surmise that the 192.168.10.0/24 network is a network for routers.
The forth entry is just like the third, except that it is for interface eth0, which we can see is connected to teh 192.168.18.0/23 network. This is the network where the workstations are - the LAN.
The next two (fifth and sixth) entries are network routes with point out over gateways on the router network. All traffic which falls into IP address ranges denoted by the network address (Destination) and subnet mask (Genmask) will be forwarded to the appropriate WAN router. A safe bet would be that these correspond to IP address space in use in other locations. If you notice their Genmask, you will understand why they first appear now in the routing table. The table is sorted from most-restrictive to least-restrictive, and 255.255.192.0 is the widest subnet mask yet.
The next to last entry in the table is for the loopback device, lo, just like on a workstation.
The last entry is the default route. Just like workstations, routers have these in case they do not know where else to forward a packet. In our example, the default route points to the 192.168.10.20 machine, and is heavily used (note the Use field). 192.168.10.20 could be the Internet router or firewall.
Note that the table is sorted in reverse order by the number of bits in the Genmask field (just as it is on a workstation). The kernel checks each entry in the table against the destination IP address of the packet it recieved, and it forwards the packet on the first match it finds. This means that multiple (static) routes to the same destination are not used if you have simple static routing. In the case of a tie - two entries with identical Destination and Genmask - the one with the lower metric value is chosen. Should the metrics be equal, the more recent entry is chosen. The kernel doesn't remember when the entries were made for static routes, but it knows that when someone enters a route equivalent to an existing route, the intention is most likely to use the new route. This is convenient if you need to temporarily route around a particular gateway or have some other testing in mind. You can enter the temporary route, and it will be used. When you delete it, the previous route is used.
Each of the other routers must also have routing table entries for the network(s) and host(s) it is expected to forward. If they don't, then they will either use their defualt route, or, if no default route exists, they will reply with an ICMP: host unreachable message. The pathological case is when the route points back to the sending router, which forms a loop. (RouterA sends to routerB, which sends to routerA, and so on...). Fortunately, IP packets all contain a TTL (Time To Live) field which is decremented every time the packet is forwarded. Eventually (actually, very quickly), the packet will be discarded. Nonetheless, such misconfigurations mean that the packet will not find its destination, which results in performance degradation for correctly routed packets on the network.
Another situation arises when routerA forwards a packet to routerB when it could (and should) have forwarded it directly to routerC. That is, all three routers are on the same subnet, but routerA is ignorant of (one or more of) routerC's routes. When routerA forwards a packet to routerB, and routerB notices that the packet should have been sent directly to routerC, it forwards the packet, but alerts routerA to the fact with an ICMP: redirect message telling routerA how to forward packets of that type in the future. RouterA notes this by adding a new (host route) entry in its routing table. You can quickly spot these entries because they have the UDGH flags all set. Of note is the D, which indicates that the route was added either dynamically or due to a redirect.
There are two methods of configuring a routing table. If the table is populated by you (or by a script on your behalf) using the route command, then it is known as static routing. If it is populated automatically by a daemon such as routed, you are using dynamic routing.
Static routing is great because the reassurance of knowing exactly what the router will do with a packet at all times is worth the extra effort. However, static routing cannot be used in every situation, and is by no means the only way to do things with routers.
Jeffrey Hunter is an Oracle Certified Professional, Java Development Certified Professional, Author, and an Oracle ACE. Jeff currently works as a Senior Database Administrator for The DBA Zone, Inc. located in Pittsburgh, Pennsylvania. His work includes advanced performance tuning, Java and PL/SQL programming, developing high availability solutions, capacity planning, database security, and physical / logical database design in a UNIX / Linux server environment. Jeff's other interests include mathematical encryption theory, tutoring advanced mathematics, programming language processors (compilers and interpreters) in Java and C, LDAP, writing web-based database administration tools, and of course Linux. He has been a Sr. Database Administrator and Software Engineer for over 20 years and maintains his own website site at: http://www.iDevelopment.info. Jeff graduated from Stanislaus State University in Turlock, California, with a Bachelor's degree in Computer Science and Mathematics.
Copyright (c) 1998-2018 Jeffrey M. Hunter. All rights reserved.
All articles, scripts and material located at the Internet address of http://www.idevelopment.info is the copyright of Jeffrey M. Hunter and is protected under copyright laws of the United States. This document may not be hosted on any other site without my express, prior, written permission. Application to host any of the material elsewhere can be made by contacting me at firstname.lastname@example.org.
I have made every effort and taken great care in making sure that the material included on my web site is technically accurate, but I disclaim any and all responsibility for any loss, damage or destruction of data or any other property which may arise from relying on it. I will in no case be liable for any monetary damages arising from such loss, damage or destruction.
Last modified on
Sunday, 19-Sep-2010 23:25:41 EDT
Page Count: 14732