IP Addressing
IP Addressing
The first and most basic of the Policy Routing structure elements is the addressing structure. This fundamental part of an IP network is often completely taken for granted. In the many sessions I have given on using Policy Routing in Linux, I am always asked why I even bother discussing addresses. In reply, I usually ask if anybody there can explain what an IP address is. With your own answer to this question in mind, let me begin.
When looking at a Policy Routing setup you should start by considering the IP addressing structure. The use and interactions of addressing in an IPv4 network often indicate the fundamental data flow of the network structure. To fully understand how these addresses interact with the routing structure of the network, I will first discuss some of the theory of addressing under IPv4 with some forward references to IPv6 as well. From this basis you can see why some of the problems within routed networks currently exist.
Fundamental IP Address Concept
The fundamental design notion behind IPv4 addresses is that an address uniquely identifies the source of a set of services. Most people consider an IP address as identifying a single network interface on a particular machine. But that is a misperception of the address. Think deeper of the actual sequence of events defining how you would locate a given address on a particular network segment.
When considering the communication on a given physical network, say an Ethernet or Token Ring hub, under IPv4 the IP address is not used in direct communication. Any two network devices under IPv4 communicate over a physical network using their respective Media Access Control (MAC) addresses. This is the reason behind Address Resolution Protocol (ARP). On any physical network you can have as many different IPv4 networks as you want coexistent and unaware of each other. Under such a network scheme you may talk of routing structures required between two machines on the same physical network.
A physical network structure that has coexistent, independent IPv4 networks defined and operational provides a good perspective for understanding the divorce of addressing from physical structure. In those conditions you may have multiple complete IPv4 networks defined as matching identical MAC addresses. When you communicate under such a network setup you use the IP address that is appropriate for the network you want to communicate with. Consider the following information and setup:
Machine A - eth0: MAC Address - 00:11:22:33:44:AA IP Address - 192.168.1.1/24 Machine B - eth0: MAC Address - 00:11:22:33:44:BB IP Address - 10.1.1.1/8 Machine C - eth0: MAC Address - 00:11:22:33:44:CC IP address - 192.168.1.254/24, 10.254.254.254/8
Since Machine C has two IP addresses assigned it is probably the router. Now look at the arp tables on Machine A and Machine B and you will see two different IP addresses associated with the same MAC address. Machine A's arp table lists IP address 192.168.1.254 as having MAC address 00:11:22:33:44:CC and Machine B's arp table lists IP address 10.254.254.254 as having MAC address 00:11:22:33:44:CC.
By seeing the IP address as simply a pointer to the location of a set of services you can see why many of the tricks of IP become a normal conclusion. Spoofing, loopback, and hijacking, along with load balancing, proxy ARP, and NAT, are all functions of the "free" nature of IPv4 addresses.
Consider how you match up a human-readable network name such as http://www.policyrouting.org with the associated IPv4 address. The DNS service provides a correlation between these two items. Then when you want to see what information is available under the http protocol on that network node, your browser queries the IP address returned from the DNS lookup with a specific request for the "well-known" service port. In this case the IP address is providing a reference platform for obtaining the service. But what is that reference platform?
Now the notion that an IP address is associated with a particular interface becomes hazardous. When you consider what reference platform is associated with the IP address you must take into account the fact that there is no reliable association of the IP address to any particular physical system. Indeed, if the http service considered here were behind a hardware load balancer, the notion of that IP address as " belonging " to any particular hardware system is ludicrous. The only definition of the service relies on the provision of many systems feeding a common output.
Implausible and confusing as this may seem at first glance, the type of setup required to implement this scenario is all too familiar. Consider a standard NAT firewall or any IPv4 load balancing system and you will see that the IP addressing mechanisms are used to define a service without reference to any physical interface. When I speak of an IP address, then, I refer to the services and usage of that address and not to any particular physical manifestation of that address.
Now that an IP address no longer belongs to a physical interface you can start to look at the various methods of using it. This is where you start to play with the IP address structure of the network. By defining the IP address structure you can implement additional methods of Policy Routing.
Example 5.1: Multiple IP Addressing
The following exercise in implementing multiple IP addresses will help you further understand the parts of the IP address functions. This hands-on exercise will then be used as the basis for the rest of the addressing structure explanations .
You will create multiple IP addresses and explore several of the additional device structures provided under Linux. All of the features are available under Kernel 2.1.32 or higher. The utility is ip from the IPROUTE2 package.
Your machine has two network interface cards (NICs) installed. One is Ethernet (eth0) and the other is Token Ring (tr0). Additionally you have the Dummy , Tap, and several flavors of Tunnel interface. You start with no addresses configured with the lone exception of loopback. So your system output from ip addr list looks like Listing 5.1.
Listing 5.1 Output of ip addr list
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo inet6 ::1/128 scope host 2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:11:22:33:44:aa brd ff:ff:ff:ff:ff:ff inet6 fe80::211:22ff:fe33:44aa/10 scope link 4: tr0: <BROADCAST,MULTICAST,UP> mtu 2000 qdisc pfifo_fast qlen 100 link/ether 00:11:22:33:44:bb brd ff:ff:ff:ff:ff:ff inet6 fe80::211:22ff:fe33:44bb/10 scope link 5: tap0: <BROADCAST,MULTICAST,NOARP> mtu 1500 qdisc noop link/ether fe:fd:00:00:00:00 brd ff:ff:ff:ff:ff:ff 6: tunl0@NONE: <NOARP> mtu 1480 qdisc noop link/ipip 0.0.0.0 brd 0.0.0.0 7: gre0@NONE: <NOARP> mtu 1476 qdisc noop link/gre 0.0.0.0 brd 0.0.0.0 8: sit0@NONE: <NOARP> mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 9: teql0: <NOARP> mtu 1500 qdisc noop qlen 100 link/generic
Now you will configure your eth0 interface to have three IPv4 addresses: 10.1.1.1/8, 172.16.1.1/16, and 192.168.1.1/24. Your tr0 interface will have the following three addresses: 10.1.1.2/8, 172.16.1.2/16, and 192.168.1.2/24. This is accomplished through the following command sequence:
ip addr add 10.1.1.1/8 dev eth0 brd + ip addr add 172.16.1.1/16 dev eth0 brd + ip addr add 192.168.1.1/24 dev eth0 brd + ip addr add 10.1.1.2/8 dev tr0 brd + ip addr add 172.16.1.2/16 dev tr0 brd + ip addr add 192.168.1.2/24 dev tr0 brd +
Listing 5.2 is the output from ip addr list .
Listing 5.2 Revised ip_addr list Output
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo inet6 ::1/128 scope host 2: dummy: <BROADCAST,NOARP> mtu 1500 qdisc noop link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff 3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:11:22:33:44:aa brd ff:ff:ff:ff:ff:ff inet 10.1.1.1/8 brd 10.255.255.255 scope global eth0 inet 172.16.1.1/16 brd 172.16.255.255 scope global eth0 inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0 inet6 fe80::211:22ff:fe33:44aa/10 scope link 4: tr0: <BROADCAST,MULTICAST,UP> mtu 2000 qdisc pfifo_fast qlen 100 link/ether 00:11:22:33:44:bb brd ff:ff:ff:ff:ff:ff inet 10.1.1.2/8 brd 10.255.255.255 scope global tr0 inet 172.16.1.2/16 brd 172.16.255.255 scope global tr0 inet 192.168.1.2/24 brd 192.168.1.255 scope global tr0 inet6 fe80::211:22ff:fe33:44bb/10 scope link 5: tap0: <BROADCAST,MULTICAST,NOARP> mtu 1500 qdisc noop link/ether fe:fd:00:00:00:00 brd ff:ff:ff:ff:ff:ff 6: tunl0@NONE: <NOARP> mtu 1480 qdisc noop link/ipip 0.0.0.0 brd 0.0.0.0 7: gre0@NONE: <NOARP> mtu 1476 qdisc noop link/gre 0.0.0.0 brd 0.0.0.0 8: sit0@NONE: <NOARP> mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0 9: teql0: <NOARP> mtu 1500 qdisc noop qlen 100 link/generic
You may recall the various items of information in this printout from the discussion of the ip utility in Chapter 4. An important one is the definition of the addresses on the inet lines. For example, the eth0 address 10.1.1.1/8 has a scope global toward the end of the line. This scope parameter is the second important topic of IP addressing.
IP Address Scoping
Many operating systems have methods of assigning multiple IP addresses to an interface. These multiple assignments often code the assignment in terms of fragmented interfaces. A fragmented interface, often referred to as a coloned interface or IP alias, is a subinterface defined as a virtual part of the primary interface. You usually see these addresses and assignments in terms of being allocated one to one with a specific interface fragment. Recalling the multiple IP addresses from Example 5.1 you would have seen that eth0 = 10.1.1.1/8, eth0:1 = 172.16.1.1/16, and eth0:2 = 192.168.1.1/24. This tying of the IP address to a virtual interface fragment violates the fundamental consideration of IP addresses being independent of assignment.
What sets the Policy Routing usage apart, especially under Linux, is the concept of addressing scopes. When you assign multiple IP addresses to a single interface under the fragmented interface setup, you treat the first entered address as the primary and the rest of the addresses as secondaries. If you delete the primary address the interface goes away and you lose all other addresses. The interface is paramount in this scenario.
In Policy Routing the treatment of IP addresses obeys the fundamental disassociation of address from physical assignment. Thus when you assign multiple IP addresses to an interface in Policy Routing, you have complete independence of the addresses. There is no fragmented interface to which the address is associated. Instead, all addresses are treated equal and capable of being used independently. However, this brings up the question of how an IP address is defined with respect to the IP network structure.
The definition of an IP address scope ties together the concept of the address and the network. An address exists independently of the network and other addresses. Defining which addresses fit into which network spaces is purely a matter of definition with respect to the IP address itself. This definition is coded through the Classless Inter Domain Routing (CIDR) mask value.
A CIDR mask specifies the masking bits used on an IP network. This is the subnet mask when referencing the network itself. In Policy Routing addressing, this mask specifies the scope of the address space by defining the network coverage. Thus when you have a CIDR mask of /24, you define a network originally referred to as a Class C network. The address scope is then defined as having that address being a member of that network.
This sounds convoluted but is very simple. An example should clarify this somewhat. Consider the addressing structure you implemented in Example 5.1. Each of the addresses in that example had an independent scope. Thus if you look at the addressing for eth0 from that example you have three scopes ”call them A, B, and C.
10.1.1.1/8 = Scope A 172.16.1.1/16 = Scope B 192.168.1.1/24 = Scope C
To show the extent of the scope, consider a simple quiz. Which of the following addresses belong to which scope listed above?
10.1.1.2/16 172.16.1.2/24 192.168.1.2/24
The answers, in order, are: D (new), E (new), C. Both of the first two addresses and CIDR masks define new scopes, D and E. Only the last one is a member of a preexisting scope. Yes, 10.1.1.2 as an independent address can be considered as belonging to the range of addresses defined by 10.1.1.1/8, but the addition of the /16 CIDR mask defines it as belonging to a new scope. Ditto on the 172.16.1.2 address. In the 192.168.1.2 address the mask also agrees and thus defines that address as belonging to the previously defined scope.
The reason I belabor this point is that the scope has a direct bearing on how the address is treated. In the preceding quiz, the address 192.168.1.2/24 would become a secondary address on the interface. As I discussed in the beginning of this section, a secondary address is removed when the corresponding primary address is removed. Thus if you deleted the original 192.168.1.1/24 address from eth0, then both of the 192.168.1. addresses would disappear. Conversely, since the 10.1.1.2/16 address defines a different scope, deleting the 10.1.1.1/8 address would not affect it. To see this in action work the following example.
Example 5.2: Primary/Secondary IP Addressing
Assume this example starts where Example 5.1 left off. You have two interfaces, each having three addresses defined. See Listing 5.2 for details. Now you define the three new addresses onto eth0 as in the scope discussion. This could be done using the following command sequence:
ip addr add 10.1.1.3/16 dev eth0 brd + ip addr add 172.16.1.3/24 dev eth0 brd + ip addr add 192.168.1.3/24 dev eth0 brd +
Now you have defined several new addresses onto eth0 and one of these addresses is a secondary address. Your ip addr list dev eth0 would look like the Listing 5.3.
Listing 5.3 Output of ip addr list dev eth0
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:11:22:33:44:aa brd ff:ff:ff:ff:ff:ff inet 10.1.1.1/8 brd 10.255.255.255 scope global eth0 inet 172.16.1.1/16 brd 172.16.255.255 scope global eth0 inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0 inet 10.1.1.3/16 brd 10.1.255.255 scope global eth0 inet 172.16.1.3/24 brd 172.16.1.255 scope global eth0 inet 192.168.1.3/24 brd 192.168.1.255 scope global secondary eth0 inet6 fe80::211:22ff:fe33:44aa/10 scope link
Now delete the address 192.168.1.1/24 with the following command:
ip addr del 192.168.1.1/24 dev eth0 You will see the following listing of addresses on eth0:
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:11:22:33:44:aa brd ff:ff:ff:ff:ff:ff inet 10.1.1.1/8 brd 10.255.255.255 scope global eth0 inet 172.16.1.1/16 brd 172.16.255.255 scope global eth0 inet 10.1.1.3/16 brd 10.1.255.255 scope global eth0 inet 172.16.1.3/24 brd 172.16.1.255 scope global eth0 inet6 fe80::211:22ff:fe33:44aa/10 scope link
As expected, both of the 192.168.1.x addresses are gone. If you want to prove to yourself that this is due to scoping, just try deleting any of the other addresses and see which ones go away.
What you have seen through these examples is the two primary concepts of IP addresses within Policy Routing. The first concept is the divorce of usage where an IP address refers to the provision of a set of services and is independent of any particular physical manifestation. The second concept is the grouping of addresses as defined by the scope of the address, which ties together the address with the provision of the network as an entity.
| Top |
