Networking Tips

  


[an error occurred while processing this directive]

No Title

[an error occurred while processing this directive]

Reference: Cisco: Internetworking Basics

Contents

Introduction

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


$ route -n Kernel IP routing table Destination Gateway Genmark Flags Metric Ref Use Iface 192.168.5.20 192.168.10.7 255.255.255.255 UGH 1 0 180 eth1 192.168.1.81 192.168.10.5 255.255.255.255 UGH 1 0 187 eth1 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 63311 eth1 192.168.18.0 0.0.0.0 255.255.254.0 U 0 0 753430 eth0 192.168.64.0 192.168.10.5 255.255.192.0 UG 1 0 47543 eth1 192.168.128.0 192.168.10.7 255.255.192.0 UG 1 0 89011 eth1 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 564 lo 0.0.0.0 192.168.10.20 0.0.0.0 UG 1 0 183436 eth1

We can tell a lot about this router by looking at the routing table (even without the aid of the illustration).

Preference for Two Equivalent Routes

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.

Unroutable Packets

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.

Misconfigred Routes - ICMP Redirects

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.

Static vs. Dynamic Routing

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.

About the Author

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-2017 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 jhunter@idevelopment.info.

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: 13966