Return to Table of Contents

Chapter 1 - Basic IPv4 Routing

1.1   Traditional IPv4 Routing
1.2   UNIX Configuration Commands
1.3   Cisco IOS Configuration Commands
1.4   IPv4 Dynamic Routing
1.5   UNIX Routed and Cisco RIP Configuration
1.6   Sample Linux Router Setup

All of the operations considered in this book are operations upon a router, whether that router is a Linux box or Cisco dedicated hardware or some other type of machine. In this chapter I consider the traditional methods of IPv4 routing as using static configurations that are manually input by the network administrator.

1.1 Traditional IPv4 Routing

In the simplest case you would have a router and you would only need to consider how to allow two networks to talk between themselves. For this case you would only need to have an appropriate IP address assigned for each of these networks. Since this simple case does not concern any networks other than the two that are directly connected, you need only define the address and mask for each network and dictate the appropriate interface for forwarding packets to that network.

In reality, however, you often need to consider other networks beyond the scope of two connections. In these cases you must have a way to talk to the other networks. This is done by having routes that point to other routers that are responsible for those networks. In the simpler case you will have one of the connected networks that only needs to talk with the rest of the network structure and is routed with only a single default route. A default route is traditionally coded as a route to the 0.0.0.0/0 destination. However, it may be that you are within a structured network with a given finite range or that you want to implement better security, in which case your default route may only cover your network scope. The point is that a default route is really defined as the "route of last resort," which is used if no other route covers the packet destination.

These considerations illustrate the fundamental thought behind traditional IPv4 routing:

All routing is a destination-driven process.

Every packet that enters a router is inspected to determine the destination IP address. Based on that destination address the router then consults the routing table to determine where to send the packet. The only item of interest to the router is the destination address. Nothing else matters.

1.2 UNIX Configuration Commands

You should now understand the fundamental thought behind traditional IPv4 routing. However, at this point, you need to step back and look into the methods of implementation. First consider UNIX commands. These commands are traditional both in function and in age. Once you have learned how to use them under one UNIX, including Linux, you will know essentially how to use them in any UNIX. This section details how to use these commands under Linux to configure a basic two-network router with a single default route. You will also add additional specific routes to illustrate the meaning behind the fundamental thought of traditional routing.

The two primary utilities used in configuring IPv4 routing under UNIX are ifconfig and route. You will step through the use of both of these utilities to configure a simple dual connected router under Linux.

1.2.1 ifconfig Utility

The ifconfig utility has been used with UNIX systems for quite some time and is the original utility for configuring network interfaces under UNIX. The utility is appropriately named InterFace CONFIGuration, or ifconfig. On many UNIXes as well as Linux ifconfig supports multiple protocol suites, or address families. The complete syntax and supported address families can be found in the man pages. This book is only concerned with the inet family, which is the address family for IPv4. There is also an inet6 family for IPv6 but we will not cover that usage in this book. In Chapter 9, “IPv6”, you will learn how the ip utility from Chapter 4 is used for Policy Routing in IPv6.

The basic ifconfig syntax for an IPv4 interface under Linux is as follows:

ifconfig {interface} {IP-address} netmask {netmask} broadcast {broadcast}

The italicized words in brackets will be replaced with the relevant information to configure the interface.

On most UNIXes you can find out the names of the available interfaces through ifconfig by asking it to list all of the interfaces it knows about. Type ifconfig -a and you will see a list of all the interfaces on the system, regardless of whether they are configured. You can also call ifconfig with the name of a single interface to obtain information about that interface only. This feature helps when you are on a strange system and need some quick information.

In UNIX there is an IP interface that should be present whenever the system is enabled for TCP/IP communication. This is the loopback interface, usually specified by the name lo or lo0. By conventional standard this interface has the IPv4 address 127.0.0.1/8 assigned to it. This interface is very important to the correct operation of the TCP/IP networking subsystems. In Chapters 2 - 8 as the details of the Linux Policy Routing structures are illustrated and then exemplified you will see that this interface has a myriad of uses.

The other interfaces that may be on the system will have names that vary according to the UNIX flavor. I will use the Linux conventions herein and refer primarily to using Ethernet (ethxx) and Token Ring (trxx) interfaces.

Consider quickly a router that has one Ethernet interface, eth0, and one Token Ring interface, tr0. The appropriate information is as follows:

eth0 - 192.168.1.254/24

tr0 - 10.1.1.254/24

Default Gateway - 10.1.1.1/24

Two networks are represented here and from the default gateway address you can deduce that the Ethernet network is a stub network off of the main network. The TokenRing could be considered the backbone network if you prefer that terminology because it contains the default gateway.

To set up the interfaces using ifconfig on a typical Linux system, do the following from the command line:

ifconfig eth0 192.168.1.254 netmask 255.255.255.0 broadcast 192.168.1.255

ifconfig tr0 10.1.1.254 netmask 255.255.255.0 broadcast 10.1.1.255

You could then list the interfaces and get information about them using the straight ifconfig command by itself.

1.2.2 route Utility

Now you have a router with three IPv4 configured interfaces. Do not forget about the loopback interface when counting the interfaces! You should now set up your router to actually be able to route between the locally connected networks. In order for the router to do this it needs to have all three of the locally connected networks in the routing table. Here you call upon the route command to populate the routing table.

In general usage the route command is called as follows:

route add -net|-host {IPv4 Address} netmask {netmask} gw {gateway} dev {interface}

Note that there are many other options that can be specified to the route command. Many of the options are UNIX flavor specific. The preceding options are fairly general and should work on most UNIXes. Also the route command, when issued by itself on the command line, will give different outputs depending on the UNIX flavor. In Linux, issuing a route command by itself will dump the main kernel routing table. However, on most UNIXes you will need to use the netstat -r command in order to dump the routing table.

Linux 2.0 Versus Linux 2.2 Routing Changes

In Linux there are some fundamental differences in the IPv4 configuration process between the 2.0 series of kernels and the 2.1 and newer kernels. When configuring an interface for IPv4 using ifconfig under a 2.0 series kernel, only the interface is configured. But the kernel does not know how to get to this address or to the network it defines. You have to add a network route manually in order for the kernel to see where to send the packet.

In kernel 2.1 and newer, the situation is different. When Alexey Kuznetsov rewrote the network routing code for Linux during the 2.1 development kernel series, he added automatic route creation for directly connected networks. Thus, if you run the same ifconfig configuration command on a 2.1 or higher series kernel, you will be able to connect immediately to the network defined by the interface.

Having the route automatically added by the kernel helps users unfamiliar with networking immensely in normal operation of a Linux network. If you want to configure an interface, the kernel will automatically create a connection to the interface address and network. Thus, as soon as you are done configuring the interface, you are ready to use it. However, for advanced usage this can become a nuisance.

For advanced usage you can override this behavior by explicitly configuring the interface with the true host address, which is a netmask of all ones. If you want to have the same behavior in 2.1 and higher that you had in 2.0 for ifconfig, use ifconfig {interface} {IPv4 Address} netmask 255.255.255.255 broadcast {broadcast}, and the automatic route will not be created.

Now that you have seen the syntax for basic routing configuration, it's time to apply it to the router configured in the ifconfig section.

route add -net 127.0.0.0 netmask 255.0.0.0 dev lo

route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0

route add -net 10.1.1.0 netmask 255.255.255.0 dev tr0

Note that the loopback interface route is explicitly included here for completeness. You did not see the actual ifconfig statement in the previous section; it is left as an exercise for the reader to determine what command was needed. Note that in all cases where you would want to ensure that your system is correctly configured you will want to configure all the interfaces, including the loopback interface, manually or through your own set of scripts. Under Linux, and in UNIX in general, any system interface including loopback is not automatically configured.

The router at this point is ready to route all traffic between the 192.168.1.0/24 network and the 10.1.1.0/24 network. But if there is any traffic from either of those networks with a destination address that did not belong to either 192.168.1.0/24 or 10.1.1.0/24, the router would return an error. This is because it has no default route at this point in time.

The subject of default routes contains an explicit security concern. Essentially, a default route enables a router to trust all traffic to another router. In many cases this may not be a necessary or wise decision. For example, in the network structure considered here there may only be one or two other networks of interest. Alternatively, you may not want the systems on 192.168.1.0/24 to see any other networks. The route setup at this point would ensure, in the absence of source-routing capabilities, that the systems on 192.168.1.0/24 would only be able to talk externally to systems on 10.1.1.0/24. When we consider the theory of Policy Routing in Chapters 2 and 3 and the actual implementation usages in Chapters 5 through 8, you will see various methods of considering this fundamental security problem.

But to consider standard and traditional usage you should install a default route into your router. This default route provides your router with a router to whom all unknown destination addressed traffic should be forwarded. In this case you have a gateway that has been specified for this route. You can then add it in with the following command:

route add -net 0.0.0.0 netmask 0.0.0.0 gw 10.1.1.1

Note that under Linux and under many other UNIXes this command can also be expressed as route add default gw 10.1.1.1, where the default keyword stands for the -net 0.0.0.0 netmask 0.0.0.0 parts of the given example.

You now have a router that will route traffic between the 192.168.1.0/24 and 10.1.1.0/24 networks and will also provide connectivity to any other network destination from the 192.168.1.0/24 network. Of course that does not mean that those networks can get back to the 192.168.1.0/24 network, but that is a different problem.

1.3 Cisco IOS Configuration Commands

Now that you have seen how to use the standard UNIX tools to configure a simple router, consider configuring a generic Cisco router to perform the same task. Even if you have no interest in using Cisco for this purpose please read on as you will see a marked similarity between the command sets shown here and the Linux Policy Routing toolset. If you are already familiar with Cisco IOS (Internetwork Operating System) command sets, feel free to skip this section.

This section will assume that no special configuration tasks are needed for the Cisco router. I will only show how to set it up to perform the exact same task and configuration as you have just seen with the Linux router.

The Cisco IOS configuration commands are entered at a terminal session with the router directly into the configuration. This session is either directly connected through the management port or a telnet session. Alternatively, you can enter in all the commands to a file, which is then either uploaded into the router or the router can boot off of a TFTP server and load the configuration file. If you want to learn how to do these various items, please refer to the Cisco IOS documentation. This section assumes that you already have this knowledge.

The core command used in most of this section is the ip command. This command is then followed by the action to take. For example, you have the ip address command for adding and deleting TCP/IP addresses, and the ip route command for adding and deleting TCP/IP routes. Other subcommands are covered as you read through this book. For more information refer to the Cisco IOS documentation.

1.3.1 ip address

The ip address form of the command will let you configure your interfaces with IPv4 addresses. On the router you would then have the following configuration command file sections:

interface FastEthernet0
    ip address 192.168.1.254 255.255.255.0
interface TokenRing0
    ip address 10.1.1.254 255.255.255.0

Note that unlike UNIX, the interface to operate upon is specified by a different command, interface. Thus in IOS a group of commands can be specified to operate upon an interface by including them under the appropriate interface section.

In IOS, as in Linux 2.1 and higher, assigning an IP address to an interface automatically places the appropriate network route into the routing table. Thus the preceding configuration file snippet has already defined the directly connected network routes for 192.168.1.0/24 and 10.1.1.0/24.

1.3.2 ip route

In order to complete your configuration you need to specify the default route. This is done through the ip route subcommand. You need to add in the full default route specification:

ip route 0.0.0.0 0.0.0.0 10.1.1.1

This will add in the default route to all other destinations. This Cisco router is now in the same state as your Linux router from the previous section. Of course there are other commands that need to be in the Cisco configuration file in order for this router to work, but this section is only considering what you need to input to enable the same behavior as you saw with the UNIX router system.

1.4 IPv4 Dynamic Routing

Now that you have seen how to configure simple routing on both the Linux and Cisco platforms, consider how to automate some of the routing structure itself.

In most networks today, especially corporate and ISP internal networks, there are more than a few physical and logical networks. These networks also tend to change both through additions and deletions as well as simple reconfiguration. Tracking and updating all of the routers within such a network is painful enough when you consider just a handful of networks and routers, but becomes an absolutely daunting task when the networks and routers exceed the fingers on one hand. Especially when the network spans locations and topologies.

Another problem often seen in larger routed networks is maintaining a list of networks that are non-operational. In such a case the reachability of the network becomes a prime concern. When a network is unreachable packets sent to it are just discarded and the emphasis is placed on the ICMP error messages providing the routers with this information. In an automated, or dynamic, routing environment the routing protocol itself can often fulfill this notification function in a more consistent manner.

The early answer to this was the original Routing Information Protocol, RIP. Version 1 of this protocol, as defined in RFC-1058, under IPv4 provided an automated means for routers and systems to transfer knowledge of the routing structure of the network between the devices. For serious study and details, see Stevens and RFC-1058. Note that RIPv1 has been declared historic (see RFC-1923), which means that it is good for study only. This is due to it's classfull nature. As the RFC's define in many cases the actual protocol specifications and implementations for many facets of networking you would want to know where to obtain and read them. A good place to start is the official core repository located at http://www.rfc-editor.org.

1.4.1 RIP/Distance Vector

RIPv1, and the next generation RIPv2 as defined in RFC's 1387-1389, which I will generally refer to simply as RIP, is the primary dynamic routing protocol considered on IPv4 networks. RIP is based on the Bellman-Ford (or distance vector) algorithm. The Bellman-Ford algorithm has been used for routing computations in computer networks since the early days of the ARPAnet. RIP is most useful as, and is usually seen as, an "interior gateway protocol." This concept refers to the dynamic routing methods used within a single network structure such as a corporate network.

Under RIP the concept of passing a packet through a router is considered as a discrete action. This action is referred to as a hop, and the number of times a packet passes through routers from source to destination is the hop count. Routers that participate in the RIP routing structure will pass information to each of the local directly connected networks about all of the routes it has and the associated hop count for each route listed. This information is presented on the directly connected network using a broadcast. Usually there is one router that has a defined default route that it also provides through RIP.

By configuring RIP on a router you can remove the need to define static default and additional routes on each system. You need only ensure that the router knows about its own directly connected networks and how to talk with other RIP-enabled routers. Then the various routers talk among themselves and provide routing information to each other.

One of the few drawbacks to RIP is that routes with a hop count greater than the network defined radius of 15 will be ignored by the receiving router. Also, RIP does not provide a method of having more than one route between any two networks. These and other limitations are discussed in Chapter 2, "Policy Routing Theory" and Chapter 7, "Dynamic Routing Interactions."

The basic problem with using RIP in a large-scale network lies in the core algorithm. The Bellman-Ford distance vector concept refers to a partial routing state within the scope of the locally connected networks. In other words, none of the routers participating in RIP can know the full extent and state of the network. All they know is the local routers within their directly connected networks and the routes that are known to those routers. This is often referred to as "routing by rumor". Since the routers cannot know the full routing state of the network all they know is what they obtain by gossiping with their neighbors.

1.4.2 OSPF/Link State

This gossiping limitation leads into the higher stage of "interior gateway protocols," where each router has full knowledge of the entire network scope. This type of dynamic routing protocol refers to the link-state of the network. A link-state encompasses the current status of an individual connection between two routers on a common network. This includes allowing for the relative speeds, types, and uses of the intermediary network and routers. Since each router participating in a link-state routing structure has knowledge of all other connections within the network scope, you can have multiple connections between networks and multiple definitions of the logical networks themselves.

The defining protocol for link-state is Open Shortest Path First, referred to as OSPF. The OSPF protocol was first defined in RFC-1131 and has been updated to version 2 and a forthcoming version 3 also known as OSPF for IPv6. OSPFv2 is the preferred protocol for use within a single structure network due to the ability to correctly handle large IP-based networks with multiple connections.

As detailed in RFC-1245, OSPF routers exchange link-states through link-state advertisements (LSAs) that describe pieces of the OSPF routing domain. These LSAs are flooded throughout the routing domain, with each router aggregating these LSAs to form the link-state database. Thus each router has an identical link-state database. Synchronization of link-state databases is maintained via a reliable flooding algorithm, which is based on multicast capabilities with fallback to directed broadcast or single programmed connections. From this link-state database, each router builds a routing table by calculating a shortest-path tree, with the root of the tree being the calculating router itself. This calculation is commonly referred to as the Dijkstra procedure.

Note that the Dijkstra algorithm itself is now public domain and actually refers to a solution space for an early 1900's math problem called the “traveling salesman problem”.

OSPF brings several levels of security and robustness to the dynamic routing structure. For more details please see RFC-1245 http://www.ietf.org/rfc/rfc1245.txt which discusses the OSPFv2 protocol technical details. For this book's purposes I will treat OSPF as the preferred dynamic routing structure and will detail how it can interoperate with the Policy Routing structures in Chapter 7.

1.4.3 Dynamic Routing Tradition

At this stage you are probably wondering why I am talking about all of these routing protocols. They sound as if they take care of a lot of problems with an IP-routed network. They do. But they still adhere to and promote the fundamental thought of traditional IPv4 routing: All routing is a destination-driven process. Dynamic routing protocols merely make it easier to spread the destination driven routing information around the network. When you begin to consider Policy Routing structures and the needs that drove their creation, as discussed in Chapter 2, then this dissemination of information becomes a hindrance. In Chapter 7 you will take up the question of how to strike the best balance between the ease of dissemination provided by dynamic routing and the needs for structure in the Policy Routing world.

1.5 UNIX routed and Cisco RIP Configurations

In order to ensure complete coverage of traditional IPv4 routing setups, I will show you how to configure and use the RIP protocol within your router. I will illustrate both the UNIX and Cisco viewpoints. While I will assume only that you are going to be running the RIP or RIPv2 protocols, much of what I say will be valid for running other dynamic routing protocols. In Chapter 7 I will cover the link-state, inter-AS, and distance-vector dynamic routing protocols as they work within the framework of a fully policy-routed network.

To this end, recall where I left off at the end of section 1.2 "UNIX Configuration Commands." You had a fully functional Linux router running a static routing configuration. This router was capable of routing between the 10.1.1.0/24 and the 192.168.1.0/24 IPv4 networks. It also possessed a default route pointing to a previously known router, 10.1.1.1. It's time to add to that router the ability to participate in a dynamic routed IPv4 network through the use of RIP.

1.5.1 routed

In general, UNIX usage and Linux in particular offer many extra functions through the use of daemons. In the case of dynamic IPv4 routing, this is particularly true. Indeed, the very RFCs that define the original RIP protocol refer to the protocol as the description of the operation of the routed daemon. This is because the routed daemon came along before the RIP protocol was ever formally defined. Thus the very definition of the RIP structure came from the mechanism and workings of the routed daemon functions. So to configure RIP on a Linux system you merely have to run the routed daemon.

The routed daemon may be run from the command line but is usually started in the networking initialization script for the system. In normal operation, routed listens on UDP port 520 for routing information packets from other systems. If the system is considered a router, it also periodically broadcasts copies of its routing tables to all directly connected networks.

When routed is first started it finds all directly connected interfaces configured and running on the system ignoring the loopback interface. If multiple interfaces are found, the system is defined as a router for the purpose of sending out broadcasts. After determining the interface(s) to which it will bind, routed transmits a request packet on each interface and loops listening for request and response packets from other routers.

Upon receiving a request packet routed replies using the information maintained in the system routing table. The response packet generated contains a list of routes marked with a hop count metric. The metric associated with each route provides a rough distance as relative to the originating router.

From the man page for routed, response packets received by routed may update the routing tables if any of the following conditions are satisfied:

1: No routing table entry exists for the destination network or host, and the metric indicates the destination is reachable (hop count < 16).

2: The source of the packet is the same as the router in the existing routing table entry. That is, updated information is being received from the router through which packets for the destination are being routed.

3: The existing entry in the routing table has not been updated for some time (standard definition of 90 seconds) and the route is of the same or lesser hop count as the current route.

4: The new route describes a shorter route to the destination than the one currently stored in the routing tables; the metric of the new route is compared against the one stored in the table to decide this.

In addition to processing incoming response and request packets, routed also periodically checks the routing table entries. If an entry has not been updated for 3 minutes, the hop count is set to 16 and marked for deletion. Before actually deleting the route from the table, routed will wait an extra 60 seconds to insure that the deleted route will propagate correctly. routed will periodically broadcast the routing tables every 30 seconds to all directly connected networks. This timeout can be adjusted but since it is part of the standard setup, you will want to leave it alone for most networks.

routed also supports the notion of distant passive and active routers. When routed starts up it looks for the optional configuration file /etc/gateways and if it exists it reads the file to find routers that may not be located by other means. Routers marked passive in the file do not exchange routing information but may be referred to, while routers marked active will exchange routing information. Routes through passive routers are specified using manual static routes that refer to those routers, but those static routes are not included in any routing information transmitted. Routers marked external are also passive, but are not placed in the kernel routing table or included in routing updates. The function of external entries is to inform routed that another routing process, such as gated, will install a route using that router so routed will not override that route. Such entries are only required when both routers may learn of routes to the same destination. You will see in Chapter 7 that there are many complexities to this when combined with policy routing.

Run routed from the command line to illustrate how to turn on RIP routing:

routed

Difficult - no? Actually there are several options to routed that you can specify. These include forcing routed to consider the system a router and also allowing routed to only listen for packets but not send any. Refer to the man pages for routed and the relevant configuration files for more information.

1.5.2 Cisco IOS RIP Configuration

Now that you have seen how easy it is to configure and run routed on a Linux system, it is time to set up the same level of functionality on a Cisco router.

Since we are considering RIP you can see that just as in Linux the actual initiation of the protocol is to simply turn it on. Now in Cisco IOS there is no concept of active interfaces, so you must manually specify all networks for which you want the RIP protocol to be included in the active broadcasts. Thus where Linux routed will listen to and accept RIP information about any network from a connected router, Cisco will passively listen to RIP broadcasts from any routers but will only broadcast information about networks it has been told to advertise. Following is a simple example of turning on RIP for our Cisco router.

router rip
    network 10.1.1.0
    network 192.168.1.0

This told the Cisco router to turn on and start using the RIP protocol on all interfaces connected to networks 10.1.1.0/24 and 192.168.1.0/24. The zeros in the network command above refer to full class-based networks.

There are many options in Cisco RIP that you can specify and use. You can specify the type of RIP, as in version 1 or version 2, which is important in that RIPv2 allows for authentication, CIDR, and multivalued netmasks. With routed you must use a version of routed that understands RIPv2, but you would usually in that case use gated or zebra, as you will see in Chapter 7. Also, you can specify changing the various timeouts, apply passive interface rules, and specify active and passive routers as in the /etc/gateways file. See the Cisco IOS documentation for all of the details.

Essentially you now have a fully functioning RIP router participating in the dynamic routing structure of your network.

1.6 Sample Linux Router Setup

Keeping in mind all you have seen, consider a quick overview of a Linux router setup. I will show you a script that takes the setup illustrated in the beginning of this chapter and turns on all the IPv4 traditional networking functions needed to perform traditional dynamic routing as you would see in countless small network connections.

So consider again the scenario. You have two networks, an Ethernet with IPv4 scope 192.168.1.0/24 and a Token Ring with IPv4 scope 10.1.1.0/24. The default router for the world as you know it is 10.1.1.1 on the Token Ring. You are running RIPv1 and want to participate in the dynamic routing scheme. You need to create one single script that will take your Linux system and turn on IP routing, configure the system, and enable dynamic routing.

Here is your script:

#!/bin/bash
# Turn on IPv4 packet forwarding
echo "1" > /proc/sys/net/ipv4/ip_forward
# We know our interfaces ...
/sbin/ifconfig eth0 192.168.1.254 netmask 255.255.255.0 broadcast 192.168.1.255
/sbin/ifconfig tr0 10.1.1.254 netmask 255.255.255.0 broadcast 10.1.1.255
# the above ifconfigs defined the routes also (2.2 kernel) so...
# default route
/sbin/route add default gw 10.1.1.1
# and enable RIP
/sbin/routed
exit 0
# Thats all folks....

Now this seems like a sneaky end to the chapter, but bear in mind that I told you in the beginning of this chapter the only thought you need to know for traditional IPv4 routing:

All routing is a destination-driven process.

The rest of the chapter showed you how IPv4 is configured in the traditional manner and was intended as a quick refresher or overview. The rest of the book is concerned with the limitations of the traditional routing thought and the ways of policy routing.


Return to Table of Contents