Supernetting


Arguably the single most powerful advance experienced by the IPv4 address space is the capability known as supernetting. Before we delve too deeply into this topic, let's dispel a very popular misperception. Supernetting was not introduced with CIDR! It was first specified in June 1992 in RFC 1338 as a standalone strategy for improving the aggregatability of IP address blocks. The fact that I'm including it as a subtopic in a chapter on CIDR should tell you something about how pervasive this myth has become. Yet the facts remain publicly available: Supernetting was introduced 15 months before CIDR. However, CIDR made supernetting infinitely more useful simply by creating a classless IP address space. Thus, supernets could be created on any bit boundary, as opposed to the class-based octet boundaries that constrained the authors of RFC 1388.

Supernetting is the concept of taking two or more numerically contiguous network address blocks and consolidating them into a single, larger network address. Thus, if you had a pair of /25 networks that happened to be numerically contiguous, you could probably aggregate them into a single /24 network. This would free you from having to route between the two /25 address spaces. Supernetting would also let you advertise just one network block (the /24) to the world instead of two distinct /25 network addresses.

I say probably because certain rules and limitations apply. Just because two network blocks are numerically contiguous doesn't mean that they can be supernetted. However, if they are not numerically contiguous, they absolutely cannot be formed into a supernet. The next section looks a bit more closely at some of the rules that govern the creation of supernets.

The Rules

Supernetting, like many other topics indigenous to the IP address space, gets a bad reputation for being complex and difficult to understand. That's unfortunate, because supernetting is one of CIDR's most important features. More importantly, it can be remarkably easy to understand if it is explained properly. I have already given you a thumbnail sketch of the supernet function. Now it's time to look at the provisos. There are only three basic rules for supernet creation:

  • Numeric contiguity

  • Even divisibility

  • Single interface

Each of these is examined in the following sections to help you better appreciate their impact on supernetting an address space.

Numeric Contiguity

In order for supernetting to be possible, network addresses must be numbered consecutively. This rule is probably the one that is the most intuitive of the three rules for creating supernets. If two network address blocks are not numerically adjacent, attempts to join them must necessarily include all the addresses that keep them apart. You can more completely understand what that means by looking at an example and learning from it. Table 6-5 demonstrates a /24 network block that has been subnetted into eight fixed-length subnets using a mask of 255.255.255.224. That mask, if you'll refer back to Table 6-1, equates to a /27 CIDR network.

Table 6-5. Numeric Contiguity of Subnets Within a /24

Subnet Number

Decimal Address

Contiguous With Which Numbers

Base

192.168.64.0/24

Not applicable

Subnet 0

192.168.64.0/27

1

Subnet 1

192.168.64.32/27

0 and 2

Subnet 2

192.168.64.64/27

1 and 3

Subnet 3

192.168.64.96/27

2 and 4

Subnet 4

192.168.64.128/27

3 and 5

Subnet 5

192.168.64.160/27

4 and 6

Subnet 6

192.168.64.192/27

5 and 7

Subnet 7

192.168.64.224/27

6


The third column of Table 6-5 identifies the direct contiguity of each of the eight defined subnets. Subnet 0 is numerically contiguous only with subnet 1, and subnet 1 is numerically contiguous with both subnets 0 and 2. This much should be fairly obvious. Getting back to my point about nonadjacent addresses, suppose you want to supernet subnets 1 and 3. You can't do that directly because subnet 2 (with its 32 addresses) lies between them. However, it might be possible to create a much larger subnet by integrating subnets 1, 2, and 3. However, we still have two more rules to examine before we can state with authority that such a supernet is technically feasible!

Even Divisibility

The next test to determine the supernetability of an address space is even divisibility. This test is designed to ensure that network addresses end on the correct bit boundaries to preserve the symmetry of a CIDRized address space. Even divisibility is determined by dividing the octet that contains the boundary between host and network address fields by the number of networks you are trying to supernet together. For example, if you were to combine two /24 networks, the third octet of the first network address must be divisible by 2. If you wanted to combine eight /24 networks, the first network's third octet would have to be divisible by 8.

In essence, the first network block in a supernetted group of addresses forms the base address of the new, larger address block. Everything else in the supernet is built from it. Thus, it is imperative that this initial address block conform to CIDR bit boundaries.

Table 6-6 helps you better understand why this is the case. This table builds on Table 6-5 by showing both the numerically contiguous subnets and whether the appropriate octet is evenly divisible. I have used bold to indicate which octet of each address you look at to make this determination.

Table 6-6. Numeric Contiguity and Even Divisibility of Subnets Within a /24

Subnet Number

Decimal Address

Contiguous With Which Numbers

Even Divisibility of Third Octet?

Base

192.168.64.0/24

Not applicable

Not applicable

Subnet 0

192.168.64.0/27

1

Yes

Subnet 1

192.168.64.32/27

0 and 2

Yes

Subnet 2

192.168.64.64/27

1 and 3

Yes

Subnet 3

192.168.64.96/27

2 and 4

No

Subnet 4

192.168.64.128/27

3 and 5

Yes

Subnet 5

192.168.64.160/27

4 and 6

Yes

Subnet 6

192.168.64.192/27

5 and 7

Yes

Subnet 7

192.168.64.224/27

6

Yes


Let's look at some of these individual base addresses a bit more closely so that you can better appreciate the logic behind the rule of even divisibility. Table 6-7 shows the binary mathematics that underlie the test of even divisibility. The 2 bits that are critical to determining even divisibility for our supernet example are shown in bold italic.

Table 6-7. Binary Mathematics of Even Divisibility

Decimal Address

Binary Address

192.168.64.32/27

11000000. 10101000.01000000.00100000

192.168.64.64/27

11000000. 10101000.01000000.01000000


In effect, this proposed supernet reduces the size of the network's mask from 27 bits to 26 bits. For the symmetry of the address space to be conserved, that 26th bit must start at 0. In Table 6-7, 192.168.64.32/27 and 192.168.64.64/27 are supernetted together and are advertised as 192.168.64.32/26. In binary math, the next increment above 00 is 01. Thus, the two /27 network blocks can both be referenced by the same 26-bit network address.

The next example does not conform to symmetry and doesn't work as expected. Although in binary math 01 increments to 10, the increment requires you to reset the least-significant bit to 0 and then increment a more-significant bit (the leftmost of the two number columns) to 1. Thus, the bitstring differs for the two subnets, and they cannot be supernetted together. Table 6-8 shows you how this bitstring differs. The bits significant for supernetting are in bold italic.

Table 6-8. Binary Mathematics of Uneven Divisibility

Decimal Address

Binary Address

192.168.64.95/27

11000000. 10101000.01000000.01011111

192.168.64.128/27

11000000. 10101000.01000000.10000000


Table 6-6 shows that the only subnet that can't become the base of a two-network supernet is subnet 3. Its final octet is an odd number95. Now you know why. All the other subnets can become the base of a two-network /26 supernet. Thus, of all the potential combinations for supernetting, the only set that doesn't meet both the criteria (even divisibility and numeric contiguity) is the pairing of subnets 3 and 4.

Single Interface

The last critical precondition for supernetting is that the two or more network blocks that are to be aggregated must be connected to the same interface. Otherwise, why bother? If they are connected to different interfaces, you must route between the two networks. In practical terms, this rule does not preclude you from creating a supernet from two networks that are connected to different router interfaces. However, this rule forces you to reconfigure your physical topology so that the combined supernet connects to only one interface.

Figures 6-2 and 6-3 better demonstrate how the single-interface rule can have a physical impact on a network's topology. Together they demonstrate the before-and-after perspective of supernetting.

Figure 6-2. Before: Two /27 Networks Routed Together


Figure 6-3. After: Two /27 Networks Supernetted to Form a /26


Figure 6-3 shows a network after supernetting. Two small LANs are routed together; all traffic flowing between them must be routed.

Obviously, this criterion adds a physical element to the purely mathematical requirements of supernetting's first two prerequisites. You must accept the fact that, unless a pair of subnets are physically constructed such that they can be interconnected, and then use the same router interface, they cannot be supernetted. This is true even if two or more subnets pass the criteria for contiguity and divisibility. Thus, the actual number of supernets that can be formed is a subset of those that are mathematically feasible. It is impossible to determine which subnets are supernetable without physically examining each subnetwork.

Aggregation Versus Supernetting

Supernetting and aggregation are extremely similar concepts, especially mathematically. It is how they are implemented that makes them distinct. Aggregation is what routers to do reduce their workload. They try to shorten network prefixes to minimize the total number of prefixes that must be advertised externally either to the rest of the network or to the Internet. Supernetting, by virtue of its single-interface rule, requires physical consolidation of networks as opposed to just a logical consolidation of the network addresses into a smaller prefix.

Figures 6-4 and 6-5 better demonstrate aggregation versus supernetting.

Figure 6-4. From the Internet's Perspective, a Pair of /24 Networks Are Aggregated as a /23


Figure 6-5. The Pair of /24 Networks Are Supernetted into a /23


In Figure 6-4, you can see that interconnectivity between the two /24 networks is achieved via the same router. This router recognizes that the two networks are numerically contiguous, and it advertises just a single /23 network prefix to the Internet. Thus, the Internet can reach both networks using just 23 bits of their network addresses. Inbound packets get only as far as the router shared by the /24 networks. That router must then examine the destination address of each inbound packet to determine which of its two /24 networks the packet is destined for. Making such a determination requires the router to make a routing decision based on all 24 bits of the two network prefixes.

This captures the essence of aggregation, albeit on a very small scale. There is a strong correlation between geographic distance and the number of bits you need in order to reach any given destination. A good way to think about how this works is navigating your way to your favorite restaurant. If that restaurant is located in Kansas City, Mo., your initial directions can be as simple as "Go west" if you are located east of the Mississippi River. However, after you reach that city, you need much more precise information in order to find your way through the complex network of streets and storefronts in order to find your destination. IP-based networks are no different. Precision is just defined in terms of how many of the network prefix's bits you are looking at.

Figure 6-5 shows the same network topology and also advertises just a single /23 network prefix to the Internet. However, that's where the similarities end. The two /24 networks have been integrated into a /23 network. This network requires only a single connection to the router. More importantly, the router need not look at the 24th bit of an inbound packet to figure out what to do with it: All inbound packets can be forwarded using just the /23 network. The individual /24 networks have, in effect, ceased to exist. In their place is a single, larger network.

This pair of examples use a limited scale to demonstrate aggregation versus supernetting. In reality, aggregation can occur on a very large scale. In fact, ISPs might aggregate hundreds or thousands of customer networks into just one network prefix that gets communicated to the entire Internet. This, of course, raises an issue. Is it possible to overaggregate? In other words, which is better: longer or shorter network prefixes?

Which Is Better: Longer or Shorter?

Under CIDR supernetting rules, no distinction is made between network and subnetwork addresses. Both are regarded as a network prefix to a host address, and routing decisions can be made on the entire prefix. I say "can" because it isn't mandatory.

We tend to take the Internet for granted. Everything we could ever hope to find is always right at our fingertips. At least, that's how it seems! However, if you look a little deeper, you discover a concept known as reachability. Reachability is a general term that describes whether any given destination can be reached through the Internet. The very fact that such a term exists should tell you that reaching intended destinations is not necessarily guaranteed. Which ISP networks you need to traverse to satisfy any given communication request across the Internet, and which approaches those ISPs use for routing, can have a huge impact on the reachability of destination networks. This is a by-product of network aggregation.

NOTE

A /20 is considered the smallest network size for global routability. That's not to say you couldn't advertise a smaller block, such as a /24 network. Smaller blocks run the risk of not being accepted universally throughout the Internet simply because each ISP sets its own policy as to how long a prefix it will support. Ideally, there won't be any standalone /24 network addresses; all should be created from within much larger ISP network address blocks and be advertised to the Internet as those larger blocks.


Each ISP decides how it will route across its own network. There are many different approaches, one of which is based on the principle of the longest numeric "match." Having examined how supernetting and CIDR were intended to improve route aggregation across the Internet, you can now better appreciate the pros and cons of network prefix length. It's a concise debate. Longer prefixes are much more precise. But they result in the need to track a greater overall number of routes than if you abstract a smaller network prefix from among a larger number of more-specific prefixes.

The aggregatability of the CIDR IPv4 address space gives you the best of both worlds: You can use very long (and therefore very precise) network prefixes where you have to, and very short, less-precise network prefixes where you can. Ostensibly, the closer you are in an internetwork to the destination network, the greater the precision you require of the network address. The farther you get from that destination, the less precise the network prefix can be. In this manner, routes can be generalized, with specificity increasing with proximity to the destination. In simpler terms, and as discussed earlier in this chapter, you might be able to accurately route an IP packet to a service provider network using just 16 network address bits. Then you can look at additional bits to figure out what to do with that packet after it's on the service provider's network.

The bottom line is that both longer and shorter prefixes play an important role in the proper functioning of an IP network. This works due to the concept of aggregation.




IP Addressing Fundamentals
IP Addressing Fundamentals
ISBN: 1587050676
EAN: 2147483647
Year: 2002
Pages: 118
Authors: Mark Sportack

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net