IP Route Summarization

Revised June 27, 2018

Maybe a two got in there!

Questions? Comments? E-mail: AL "at" CatSpace "dot" com

If you're not proficient at subnet masking, I recommend you try the "Subnet Masking" review exercises first. Also, these exercises assume that you are familiar with the summarization commands used with RIP v2, OPSF, EIGRP and BGP. If you aren't now, you will be when we're done!

Your solutions may not look exactly like mine. For some summarization problems, there may be multiple correct solutions, especially when future growth and "style" are considered. The important thing is that you understand and can apply the principles involved.

CCNA students can ignore the CCNP-level command syntax.

EXERCISES:

1. Router R1 is an OSPF ABR that lies between Area 51 and Area 0. Within Area 51 are subnets 169.51.36.0/24, 169.51.37.0/24, 169.51.38.0/24 and 169.51.39.0/24. The remaining 169.51.0.0 subnets are all inside Area 0. What configuration commands should be used on R1 to summarize the Area 51 routes into a convenient block for use by Area 0? When advertising the summary block into Area 0, what type of LSA will R1 send into Area 0? What type of LSA was it using to advertise the subnets before you configured summarization? Assuming that there are no ASBR's in Area 51, what commands should be used to summarize Area 0 routes into Area 51?

2. Colossal Corporation, Autonomous System #3529, has network 17.0.0.0, and they run IS-IS. They have thousands of VLSM subnets in their network ("/23" to "/30", and everything in between), interspersed with WAN links using private addressing. Advertise their assigned network to their ISPs briefly, concisely and specifically.

3. Routers "YODA" and "LUKE" are running EIGRP, in AS #23. YODA is attached to subnets 195.102.21.64/29, 72/29, 80/29, 88/29, and 120/29, and subnets 195.102.21.128/28, 144/28 and 160/28. YODA's S1 interface is connected to router LUKE's S0 interface by a link running HDLC. Using the all-powerful Force of Summarization, can you configure YODA to advertise one or more convenient blocks to LUKE, and thereby halt the "Invasion of the Really Big Routing Tables"?

4. Sprawlco, with IP network 184.29.0.0/16, has its central office in Silicon Valley, and 257 branch offices scattered about the country. They are running a point-to-point Frame-Relay star topology (using sub-interfaces on the central office router). Each remote office is running Ethernet, with a small router that connects it to the WAN. Since they are running short of addresses, they have opted to use private addressing (network 10) on their 257 WAN subnets. They have been using RIP v2 on all routers (to support their discontiguous network), but, for scalability reasons (over 500 subnets!) they are thinking of changing routing protocols. What would you recommend? Based on your choice of routing protocol, provide appropriate summarization commands for the hub and remote routers.

5. As an employee of NerdNet, the solar system's foremost ISP ("We Connect The Cosmos!"), you pride yourself on your company's efficient use of CIDR. As a small part of your prodigious address space, you own the ranges of 172.13.0.0/16 through 172.200.0.0/16 (except for 172.16.0.0/16 through 172.31.0.0/16, which are, of course, private), and 201.146.0.0/24 to 201.191.255.0/24 (201.192.0.0/24 through 201.193.255.0/24 belong to your upstart competitor, "GeekGalaxy"). The fewer prefixes you advertise to your peers, the bigger your daily bonus (and any mistake means no bonus!). Configure your border router to advertise your networks to your peer ISP's as efficiently as possible.

6. Router "Alpha" is attached to subnets 50.60.70.0/28, 16, 32, 64, 80, 96 and 112 (all using "/28" masks). Router "Beta" is attached to subnets 50.60.70.128/27, 160, 192 and 224 (all using "/27" masks). Router Alpha's E0 is attached to Router "Gamma", and they share subnet 50.60.70.48/29. Router Beta's S1 is also attached to router Gamma, they share subnet 50.60.70.56/30. The three routers are running EIGRP with AS #77. Router Gamma's S2 is a link to router "HQ", using subnet 10.15.32.0/24, and HQ is also running EIGRP 77. Summarize routes on routers Alpha, Beta and Gamma as appropriate.

7. Super-Wham-O-Dyne Industries makes digital widgets ("dwigits"), and has network 144.62.0.0/16. They run multi-area OSPF, with their frame-relay WAN (configured in a point-to-multipoint topology) serving as Area 0. Each of their seven sites requires upwards of one thousand IP host addresses, and is an OSPF area. For the convenience of their network managers, they have numbered their OSPF areas based on the subnets each area contains. For example, the first subnet in Area 48 is subnet 144.62.48.0/25 (they are using VLSM). At this point, they have Areas 16, 32, 48, 64, 80, 96 and 112. Their ABR's are keyed to the area numbers, such that the ABR between Area 0 and Area 96 is "R96". One of the routers inside Area 16 has their T-3 connection to the Internet, and therefore functions as an OSPF ASBR. How should they configure summarization on their ABR's? How should they summarize on their ASBR to announce their subnets/network to the Internet?

8. Tripod, a small ISP, has ten routers arranged like bowling pins, and each router has a Gigabit Ethernet connection to its nearest neighbors, as shown: 

            0
           / \
          1---2
         / \ / \
        3---4---5
       / \ / \ / \
      6---7---8---9
All ten routers are running BGP (AS 777). Router 4 is configured as a BGP route reflector, with the other nine routers as its clients. Each router is configured with BGP "no sync". Each of the inter-router links is in private address space, which Tripod does not advertise to its BGP peers. In addition to the links shown in the diagram, each router in the triangle is connected to one public Class "B" network. These networks are parceled out to Tripod's customers. Using BGP "network" statements, the prefixes are injected into BGP, and advertised to peer ISPs through Tripod's "corner" routers (0, 6 and 9), which have EBGP peers.

The Class "B" networks are addressed such that router "X" in the triangle is responsible for network 141.X.0.0/16. For example, router 7 is responsible for network 141.7.0.0/16. Tripod then gives its customer either an entire Class "B" network (unlikely), or a part of a "B", as appropriate, and connects the customer to the router that "owns" that network. Networks 141.10.0.0/16 through 141.255.0.0/16 belong to other Autonomous Systems. Configure BGP summarization on the "corner" routers, so that other Autonomous Systems learn the minimum number of prefixes, but can reach all of Tripod's customers (the "X" networks).

9. Catenet (www.catenet.com) is a growing consortium (a "concatenation", from which it gets its name) of ISPs. At the present time, Catenet "owns" the Class "A" networks 92/8 through 102/8, the Class "B" networks 129.0/16 through 129.163/16, and all Class "C" networks that start with "222". Catenet's BGP peers have requested that Catenet summarize as much as possible, and in addition to the summary routes, that Catenet also advertise its individual networks in the Class "A" space. What commands should Catenet place on its border routers to accomplish this?

10. Consolidated Leviathan Enterprises (C.L.E.) has router CLE1 attached to subnets 165.21.72.0, 165.21.88.0, 165.21.104.0 and 165.21.120.0 (all using "/21" masks). Router CLE2 is attached to subnets 165.21.80.0, 165.21.96.0 and 165.21.128.0 (also using "/21" masks). Router CLE1's S0 is attached to Router HQ1's S0, and they share subnet 192.168.1.0/24. Router CLE2's S0 is attached to router HQ1's S1, and they share subnet 192.168.2.0/24. Router HQ1's S2 (running PPP) connects to router HQ2's S0, and they share subnet 10.97.0.0/16. All routers are running EIGRP with AS #1. When they initially configured things, nothing worked. A CCNP (friend of the CIO) told them to configure "no auto-summary" under their EIGRP process on CLE1 and CLE2, and then she stumbled off, muttering something that sounded like "and shoot the designer". This fixed the problem, but no one knows why. Furthermore, now all subnets show up in all routers. The CIO has heard that this is "bad" (but he doesn't know why). Can you redesign their network so that it operates efficiently from a routing perspective?

ANSWERS:

1. If we convert the four Area 51 subnets to binary, we have ... 

 169.51.36.0 -> 10101001 00110011 00100100 00000000 (subnet #1)
 169.51.37.0 -> 10101001 00110011 00100101 00000000 (subnet #2)
 169.51.38.0 -> 10101001 00110011 00100110 00000000 (subnet #3)
 169.51.39.0 -> 10101001 00110011 00100111 00000000 (subnet #4)
To determine the summary mask, we care about the columns (starting from the left) where the bits are the same. Once we find any column where the bits aren't the same, we don't care from there on. If we indicate a "Care" with a binary "1", and a "Don't Care" with a binary "0" (this is a summary mask, not a "wildcard" mask), we get: 
 169.51.36.0 -> 10101001 00110011 00100100 00000000 (subnet #1)
 169.51.37.0 -> 10101001 00110011 00100101 00000000 (subnet #2)
 169.51.38.0 -> 10101001 00110011 00100110 00000000 (subnet #3)
 169.51.39.0 -> 10101001 00110011 00100111 00000000 (subnet #4)
                -------- -------- -------- --------
                11111111 11111111 11111100 00000000 (1=Care, 0=Don't)
This is our summary mask! We can also write it as 255.255.252.0, or as "/22". We're almost done (with this part!). All that is left to do is write the command syntax. We are summarizing from Area 51 (into Area 0), the first subnet in the block is 169.51.36.0, and the summary mask is 255.255.252.0, so the correct command for the ABR is: 
 area 51 range 169.51.36.0 255.255.252.0
This command goes under the "router ospf #" section of the config, where "#" is the OSPF process ID. Note that we are using a "/22" mask for summarization, and the mask on the subnets is "/24". Since we have moved two bits to the left, we are summarizing into a block of four (if we had moved three bits, it would be a block of eight). Regarding the LSA types that ABR's use to advertise routes from other areas, they use "Type-3" (Summary) LSA's, whether we are summarizing or not.

How would it look in the ABR's running config? Something like this: 

router ospf 200
 network 169.51.16.0 0.0.15.255 area 51
 network 0.0.0.0 255.255.255.255 area 0
 area 51 range 169.51.36.0 255.255.252.0
Recall that OSPF network statements work just like IP access lists, in that they use a wildcard mask (0=match, 1=ignore), and they are top-down, first-match. In other words, since all interfaces in the range 169.51.16.0 through 169.51.31.255 match on the first "network" statement, they are placed in Area 51. Any other interfaces with IP addresses will match on the second network statement (in effect a "match any"), and will be placed in Area 0. The "area ... range" command does our summarization.

That takes care of going from Area 51 to Area 0. Going the other direction, we could summarize in several different ways. The brute force approach would be to have the ABR announce that it can get Area 51's routers to all 169.51.0.0 subnets. This could be done using the config command: 

 area 0 range 169.51.0.0 255.255.0.0
If we do this, we are lying to the routers in Area 51, because not all of the subnets of network 169.51.0.0/16 are in Area 0 ... some of them are in Area 51! The Area 51 routers are smart enough to realize this, though, because the "suspect" routes are in their area. Remember, in "prefix routing" the best (longest) match wins, and "/24" beats "/16", so it would work despite our deception.

Another (better?) approach would be to examine the subnets that actually exist in Area 0 ... 

 169.51.0.0   -> 10101001 00110011 00000000 00000000
 169.51.1.0   -> 10101001 00110011 00000001 00000000
 169.51.2.0   -> 10101001 00110011 00000010 00000000
     --          
 169.51.14.0  -> 10101001 00110011 00001110 00000000
 169.51.15.0  -> 10101001 00110011 00001111 00000000
 -----------
 169.51.16.0  -> 10101001 00110011 00010000 00000000
 Subnets in the range of 16 through 31 are in Area 51!
 169.51.31.0  -> 10101001 00110011 00011111 00000000
 -----------
 169.51.32.0  -> 10101001 00110011 00100000 00000000
 169.51.33.0  -> 10101001 00110011 00100001 00000000
     --
 169.51.63.0  -> 10101001 00110011 00111111 00000000
 169.51.64.0  -> 10101001 00110011 01000000 00000000
 169.51.65.0  -> 10101001 00110011 01000001 00000000
     --
 169.51.127.0 -> 10101001 00110011 01111111 00000000
 169.51.128.0 -> 10101001 00110011 10000000 00000000
 169.51.129.0 -> 10101001 00110011 10000001 00000000
     --
 169.51.254.0 -> 10101001 00110011 11111110 00000000
 169.51.255.0 -> 10101001 00110011 11111111 00000000
While all subnets agree through the first 16 bits, we've decided not to do that, since the "missing" subnets punch a hole in our block. How about if we try using blocks on either side of the missing block? Let's take a look at the the subnets in the range from 0 through 15. Since the first two octets are identical for all subnets, and we're never interested in the host bits, we'll just look at the third octets: 
 0  -> 00000000
 1  -> 00000001
 2  -> 00000010
 --  
 14 -> 00001110
 15 -> 00001111
       --------
       11110000 (1=Care, 0=Don't)
We notice that they have the first four bits in the third octet in common, so the summary mask for the third octet is 1111000, or 240 in decimal. Therefore, we can cover this block with: 
 area 0 range 169.51.0.0 255.255.240.0
using a block size of sixteen (we moved four bits to the left, and two to the fourth power is sixteen). As far as the subnets from 32 through 255 go, we can't cover them all without including the "missing" subnets. Looks like we'll have to work harder. Note that all subnets in the range from 32 through 63 have the first three bits in common in the third octet. We can cover this block with: 
 area 0 range 169.51.32.0 255.255.224.0
which is a block of 32 (we've moved left five bits from our original mask of "/24"). For the subnets from 64 through 255, again, we can't cover them all in one block, but we can get 64 through 127 into one block, using: 
 area 0 range 169.51.64.0 255.255.192.0
and this is a block of 64 (moved left six bits). Finally, we can cover 128 through 255 using: 
 area 0 range 169.51.128.0 255.255.128.0
which is, of course, a block of 128 (seven bits). Therefore, what we would add to the config would be: 
 area 0 range 169.51.0.0 255.255.240.0
 area 0 range 169.51.32.0 255.255.224.0
 area 0 range 169.51.64.0 255.255.192.0
 area 0 range 169.51.128.0 255.255.128.0
While not as nice as one block, it results in only four routing table entries on the Area 51 internal routers (assuming that at least one subnet from each block actually exists in Area 0), instead of the 240 entries that might otherwise appear. The question is, can we do better? Of course! Since there are no ASBR's in Area 51, we can make it a "Totally-Stubby" area. This has the result of sending no "Type-3" LSA's (except for the default, which uses a Type-3) into the area. In that case, we don't have to configure in-bound summarization for Area 51 at all, and that what we just did was a waste of time (but if you don't need the practice, why are you reading this?). The commands to make Area 51 "Totally-Stubby" are simply: 
 area 51 stub no-summary
on the ABR, and: 
 area 51 stub
on the Area 51 internal routers. Overall, then, how would it look in the running config of the ABR? How about: 
router ospf 200
 network 169.51.16.0 0.0.15.255 area 51
 network 0.0.0.0 255.255.255.255 area 0
 area 51 range 169.51.36.0 255.255.252.0
 area 51 stub no-summary
And on the internal routers in Area 51? 
router ospf 200
 network 169.51.0.0 0.0.255.255 area 51
 area 51 stub
And on the internal routers in Area 0? 
router ospf 200
 network 169.51.0.0 0.0.255.255 area 0
You could certainly get more creative with the network statements, but these configs would do the trick.

2. This one is easier than it looks. We are interested in advertising network 17 to the outside world. How it is subnetted (VLSM, discontiguous, whatever) is immaterial. What routing protocol they run is immaterial. The outside world does not want to know. If BGP is not yet running on this router, we can start it up with "router bgp 3529" in global config mode. The next step would be to configure our router and our external peer with neighbor statements. After that, we configure BGP to inject network 17. Finally, we do the summarization. It would look something like this: 

 router bgp 3529
  neighbor w.x.y.z remote-as nnn
  network 17.0.0.0
  aggregate-address 17.0.0.0 255.0.0.0 summary-only
where "w.x.y.z" is our EBGP peer's address, and "nnn" is its Autonomous System number. This will advertise 17.0.0.0/8 to the BGP neighbors, and "automatically" place a BGP-generated null-zero route for that prefix into the routing table (which will appear as a "B" route).

Note that there is another way to configure things so that only the summary is advertised. What you can do is manually configure the summary route, using the global-config command: 

 ip route 17.0.0.0 255.0.0.0 null 0
This will result in the appearance of a statically-generated null-zero route (it will appear as an "S" route). Then, advertise exactly that route into BGP with: 
  network 17.0.0.0 mask 255.0.0.0
Both methods will have the same effect, which is that the router will inject the prefix 17.0.0.0/8 into BGP, and its own routing table will gain a route to "null 0" for that prefix. The choice is yours, but it is recommended that you use the "aggregate-address" method. It just seems cleaner, somehow!

3. We need to find the "high-order" (left-most) bits in common, so let's take a look at the binary ... 

 195.102.21.64  -> 11000011 01100110 00010101 01000000 (subnet #1)
 195.102.21.72  -> 11000011 01100110 00010101 01001000 (subnet #2)
 195.102.21.80  -> 11000011 01100110 00010101 01010000 (subnet #3)
 195.102.21.88  -> 11000011 01100110 00010101 01011000 (subnet #4)
        --
 195.102.21.144 -> 11000011 01100110 00010101 10010000 (subnet #5)
 195.102.21.160 -> 11000011 01100110 00010101 10100000 (subnet #6)
The first four subnets have bits in common all the way up through the third bit in the last octet. The last two subnets have bits in common up through the second bit of the last octet. Therefore, we need to look at summarization in two blocks. Let's do the first four subnets: 
 195.102.21.64 -> 11000011 01100110 00010101 01000000 (subnet #1)
 195.102.21.72 -> 11000011 01100110 00010101 01001000 (subnet #2)
 195.102.21.80 -> 11000011 01100110 00010101 01010000 (subnet #3)
 195.102.21.88 -> 11000011 01100110 00010101 01011000 (subnet #4)
                  -------- -------- -------- --------
                  11111111 11111111 11111111 11100000 (1=Care, 0=Don't)
So, our summary mask is 255.255.255.224, and the IOS syntax for summarization would be: 
 ip summary-address eigrp 23 192.102.21.64 255.255.255.224
Looking at the second block: 
 195.102.21.144 -> 11000011 01100110 00010101 10010000 (subnet #5)
 195.102.21.160 -> 11000011 01100110 00010101 10100000 (subnet #6)
                   -------- -------- -------- --------
                   11111111 11111111 11111111 11000000 (1=Care, 0=Don't)
Our summary mask is 255.255.255.192, and the IOS syntax for summarization would be: 
 ip summary-address eigrp 23 195.102.21.144 255.255.255.192
Here we have to be careful. This summarization statement says that any subnet which has the first 26 bits in common with 192.102.21.144 can be reached through YODA. Since we are using a "/28" mask with these subnets, this is a block of four (we moved two bits to the left). What are the missing subnets? Why, 195.102.21.128 and 195.102.21.176, of course! Where are the missing subnets? Good question! If they are nowhere, we're safe ... for now, anyway. If they're going to be added in with our block, we're in good shape. If they get added somewhere on the other side (the Dark Side?) of LUKE, we could be in trouble if someone advertises a summary block that includes them. Since this summarization would only save us one entry, and could cause routing to fail, maybe we should play it safe, and only use the first summary block.

Another option would be to use 128 instead of 160. We could then summarize 128 and 144 with a "/27" mask: 

 ip summary-address eigrp 23 195.102.21.128 255.255.255.224
One more variation would be to use 176 instead of 144, allowing: 
 ip summary-address eigrp 23 195.102.21.160 255.255.255.224
Either of these solutions is clean, but would involve re-addressing hosts. Probably better off to just stick with the first block, until we get more subnets in the 128 to 176 range.

4. Well, let's see ... they have over 500 subnets, and they are running RIP v2. Since RIP v2 is a classless routing protocol, it advertises the subnet mask. It also uses hop count for a metric, and a little investigation reveals that the hop count field is eight bits (despite the fact that RIP considers anything over 15 hops to be unreachable). That means that each subnet advertised requires 32 bits of address, 32 bits of subnet mask, and eight bits of metric, for a total of 72 bits. If we advertise 500 subnets (at 72 bits per) every thirty seconds, that's 36,000 bits every thirty seconds, or 1200 bps. Not a big load, even on a 56Kbps link (just a hair over 2%, actually). That's not much. Seems that they don't have a problem.

On the other hand, each of the remote routers has a routing table entry for every subnet. What we could do is have them run static and default. Simply configure all remote site routers with a default pointing to the central site, and then configure the central site with a static route for each remote site. That's 257 static routes. Yuck! At least they don't change very often. While it wouldn't save much in terms of WAN bandwidth, it would shrink the routing tables on the remote routers from over 500 entries to only three (remote LAN, the WAN link, and the default). Another option would be to run RIP v2 on all routers, configure the remotes with defaults, and then set all of the central router's sub-if's passive for RIP. This would have the result of the central site automatically learning the remote subnets, without having to configure them as static routes. The remote sites would keep their three entries. Granted, you would have to tell RIP that each of the 257 sub-if's was passive, but you have to add another sub-if whenever you add a new remote site, and you wouldn't have to put in the static routes.

A better solution (if we don't mind that all WAN links share one subnet) is to use "point-to-multipoint" mode on the WAN (and keep the current star PVC topology). Run RIP v2 on all routers, configure the remote routers with a default, and set the central site router to be passive for RIP on the WAN interface. That way, you only need to put in one "passive" statement, the central router knows everything, the remote routers have three-entry routing tables, and it still doesn't require much bandwidth.

5. As always, we're interested in bits in common. Let's check out the 172's .. 

 172.13.0.0    -> 10101100 00001101 00000000 00000000
 172.14.0.0    -> 10101100 00001110 00000000 00000000
 172.15.0.0    -> 10101100 00001111 00000000 00000000
 ----------
 172.16.0.0    -> 10101100 00010000 00000000 00000000
 Networks in the range of 16 thorugh 31 are private!
 172.31.0.0    -> 10101100 00011111 00000000 00000000
 ----------
 172.32.0.0    -> 10101100 00100000 00000000 00000000
 172.33.0.0    -> 10101100 00100001 00000000 00000000
     --
 172.63.0.0    -> 10101100 00111111 00000000 00000000
 172.64.0.0    -> 10101100 01000000 00000000 00000000
 172.65.0.0    -> 10101100 01000001 00000000 00000000
     --
 172.127.0.0   -> 10101100 01111111 00000000 00000000
 172.128.0.0   -> 10101100 10000000 00000000 00000000
 172.129.0.0   -> 10101100 10000001 00000000 00000000
     --
 172.191.0.0   -> 10101100 10111111 00000000 00000000
 172.192.0.0   -> 10101100 11000000 00000000 00000000
 172.193.0.0   -> 10101100 11000001 00000000 00000000
     --
 172.199.0.0   -> 10101100 11000111 00000000 00000000
 172.200.0.0   -> 10101100 11001000 00000000 00000000
We can lump 172.14.0.0 and 172.15.0.0 into a block of two, thus: 
 aggregate-address 172.14.0.0 255.254.0.0 summary-only
We can't advertise the three (13, 14 and 15) together (as a block of four), because we would have to start at 12, and we don't own 12. Skipping over 16 through 31 (which are private), the next convenient block starts at 32 and runs through 63: 
 aggregate-address 172.32.0.0 255.224.0.0 summary-only
Then we do 64 through 127: 
 aggregate-address 172.64.0.0 255.192.0.0 summary-only
What about the rest? We could do: 
 aggregate-address 172.128.0.0 255.128.0.0 summary-only
but that includes everything from 172.128.0.0 through 172.255.0.0, and we don't own all of those. So, let's take care of 128 through 191: 
 aggregate-address 172.128.0.0 255.192.0.0 summary-only
And now 192 through 199: 
 aggregate-address 172.192.0.0 255.248.0.0 summary-only
And network 172.200.0.0/16 stands alone! That takes care of the 172's, now on to the 201's ... 
 201.146.0.0   -> 11001001 10010010 00000000 00000000
 201.147.0.0   -> 11001001 10010011 00000000 00000000
 201.148.0.0   -> 11001001 10010100 00000000 00000000
     --
 201.151.0.0   -> 11001001 10010111 00000000 00000000
 201.152.0.0   -> 11001001 10011000 00000000 00000000
     --
 201.159.0.0   -> 11001001 10011111 00000000 00000000
 201.160.0.0   -> 11001001 10100000 00000000 00000000
     --
 201.175.0.0   -> 11001001 10101111 00000000 00000000
 201.176.0.0   -> 11001001 10110000 00000000 00000000
     --
 201.191.255.0 -> 11001001 10111111 11111111 00000000
We can do blocks containing 146 and 147 (block size of 2), 148 through 151 (block of 4), 152-159 (8), 160-175 (16), and 176-191 (16): 
 aggregate-address 201.146.0.0 255.254.0.0 summary-only
 aggregate-address 201.148.0.0 255.252.0.0 summary-only
 aggregate-address 201.152.0.0 255.248.0.0 summary-only
 aggregate-address 201.160.0.0 255.240.0.0 summary-only
 aggregate-address 201.176.0.0 255.240.0.0 summary-only
If you don't like binary, it's a pain to calculate the summarizations (especially when there are holes in what would otherwise be nice big blocks), but when you consider that our peers will receive nine prefixes, instead of a possible 27,712 (172 Class "B" and 27,540 Class "C"), it's worth it. If every AS could reduce their advertisements by just one prefix, that would reduce the size of the Internet's core routing tables by about 9000 entries. Think about that the next time you do a "show ip route"!

6. We need to be careful. Let's look at router Alpha first. Notice that subnet 56, which should be over by 16, 32, 64 and 80, is not. Also, subnets 0 and 112 are missing entirely. We could live dangerously, and do a summary block from 0 to 127, like so: 

 ip summary-address eigrp 77 50.60.70.0 255.255.255.128
If we do this, we are telling router Gamma that Alpha can provide access to the entire block from 0 to 127, which is not true. The missing routes are not a problem, but 56 could be, since it's in the "wrong" place. Through the magic of prefix routing, though, Gamma will still route correctly, because the "/30" on the 56 route is more specific than the "/25" of our summary. Now let's look at router Beta. It owns the 128, 160, 192 and 224 subnets. If we assume that any new subnets having second octets above 128 will fall into Beta's domain, then we can handle this with a nice block of four: 
 ip summary-address eigrp 77 50.60.70.128 255.255.255.192
If we're the conservative type (conservative when it comes to wanting it to work, at the price of conserving routing table entries!), we could dispense with internal summarization altogether (there are, after all, only eleven internal subnets). Use your engineering judgement!

As far as summarizing the internal routes to the external world, since the internal routes are part of 50.0.0.0/8, and the link to the outside is part of 10.0.0.0/8, router Gamma will do auto-summarization at the classful boundary. This results in the HQ router learning only 50.0.0.0/8. If we want HQ to learn our subnets (there are likely other sites using network 50, and that means that our network is discontiguous!), we will have to disable auto-summary. At that point, we could perform manual summarization if desired.

7. This one is relatively straight-forward. Since each ABR is responsible for a piece of the network that is "16-wide" in the third octet, we can use a summary mask of 255.255.240.0, or "/20". This means that the ABR's will be configured as follows: 

 R16  -> area 16 range 144.62.16.0 255.255.240.0
 R32  -> area 32 range 144.62.32.0 255.255.240.0
 R48  -> area 48 range 144.62.48.0 255.255.240.0
 R64  -> area 64 range 144.62.64.0 255.255.240.0
 R80  -> area 80 range 144.62.80.0 255.255.240.0
 R96  -> area 96 range 144.62.96.0 255.255.240.0
 R128 -> area 128 range 144.62.128.0 255.255.240.0
Going the other direction, if Areas 32, 48, 64, 80, 96 and 128 have no connections to the outside world, we can make them "Totally-Stubby" areas. Area 16 does contain an ASBR, so we can't make it "Stubby" or "Totally-Stubby". We can, however, make it a "Not-So-Stubby-Area" (NSSA), or even "Totally-NSSA". The syntax for this is easy, just do: 
 area 16 nssa
on all Area 16 routers (including R16, the ABR) for NSSA. If you want "Totally-NSSA", then do exactly the same thing on the internal routers, and: 
 area 16 nssa no-summary
on R16 (the ABR).

To advertise their internal network to the Internet, since they own an entire Class "B" network, they can just do: 

 aggregate-address 144.62.0.0 255.255.0.0 summary-only
under their BGP process on the ASBR.

8. A lot of this is fluff, meant to throw you off the track. The important part is that Tripod owns ten Class "B" networks, 141.0.0.0/16 through 141.9.0.0/16. All they need to do is configure their border routers to summarize these routes. Since ten is not a power of two, they have to do it in two blocks, a block of eight, and a block of two. Let's look at the networks ... 

 141.0.0.0  -> 10001101 00000000 00000000 00000000
 141.1.0.0  -> 10001101 00000001 00000000 00000000
 141.2.0.0  -> 10001101 00000010 00000000 00000000
 141.3.0.0  -> 10001101 00000011 00000000 00000000
 141.4.0.0  -> 10001101 00000100 00000000 00000000
 141.5.0.0  -> 10001101 00000101 00000000 00000000
 141.6.0.0  -> 10001101 00000110 00000000 00000000
 141.7.0.0  -> 10001101 00000111 00000000 00000000
 141.8.0.0  -> 10001101 00001000 00000000 00000000
 141.9.0.0  -> 10001101 00001001 00000000 00000000
Focusing on the first eight, we can see that they have their first 13 bits in common: 
 141.0.0.0  -> 10001101 00000000 00000000 00000000
 141.1.0.0  -> 10001101 00000001 00000000 00000000
 141.2.0.0  -> 10001101 00000010 00000000 00000000
 141.3.0.0  -> 10001101 00000011 00000000 00000000
 141.4.0.0  -> 10001101 00000100 00000000 00000000
 141.5.0.0  -> 10001101 00000101 00000000 00000000
 141.6.0.0  -> 10001101 00000110 00000000 00000000
 141.7.0.0  -> 10001101 00000111 00000000 00000000
               -------- -------- -------- --------
               11111111 11111000 00000000 00000000 (1=Care, 0=Don't)
Therefore, the BGP command: 
 aggregate-address 141.0.0.0 255.248.0.0 summary-only
will take care of it. The last two networks, 8 and 9, get a block of their own: 
 141.8.0.0  -> 10001101 00001000 00000000 00000000
 141.9.0.0  -> 10001101 00001001 00000000 00000000
               -------- -------- -------- --------
               11111111 11111110 00000000 00000000 (1=Care, 0=Don't)
which of course gives: 
 aggregate-address 141.8.0.0 255.254.0.0 summary-only
Is this a good or bad physical and/or logical (BGP) topology for an ISP? E-mail your feedback to: AL "at" CatSpace "dot" com

9. If we examine the Class "A" networks, we see that they fall into several power-of-two blocks: 

 92.0.0.0  -> 01011100 00000000 00000000 00000000
 93.0.0.0  -> 01011101 00000000 00000000 00000000
 94.0.0.0  -> 01011110 00000000 00000000 00000000
 95.0.0.0  -> 01011111 00000000 00000000 00000000
    --
 96.0.0.0  -> 01100000 00000000 00000000 00000000
 97.0.0.0  -> 01100001 00000000 00000000 00000000
 98.0.0.0  -> 01100010 00000000 00000000 00000000
 99.0.0.0  -> 01100011 00000000 00000000 00000000
    --
 100.0.0.0 -> 01110100 00000000 00000000 00000000
 101.0.0.0 -> 01110101 00000000 00000000 00000000
    --
 102.0.0.0 -> 01110110 00000000 00000000 00000000
Let's look at the first four subnets. Note that all subnets in the range of 92 through 95 have the first six bits in common (010111), so we care about those bits, but not the rest: 
 92.0.0.0  -> 01011100 00000000 00000000 00000000
 93.0.0.0  -> 01011101 00000000 00000000 00000000
 94.0.0.0  -> 01011110 00000000 00000000 00000000
 95.0.0.0  -> 01011111 00000000 00000000 00000000
              -------- -------- -------- --------
              11111100 00000000 00000000 00000000 (1=Care, 0=Don't)
We can symbolize this by specifying that the block starts at 92.0.0.0, with a summary mask of 252.0.0.0, which would be written for BGP as: 
 aggregate-address 92.0.0.0 252.0.0.0 summary-only
The block from 96 through 99 has the same bits in common. Because the actual bit pattern is different, but the bit positions are the same, the block starts at a different place, but uses the same summary mask: 
 96.0.0.0  -> 01100000 00000000 00000000 00000000
 97.0.0.0  -> 01100001 00000000 00000000 00000000
 98.0.0.0  -> 01100010 00000000 00000000 00000000
 99.0.0.0  -> 01100011 00000000 00000000 00000000
              -------- -------- -------- --------
              11111100 00000000 00000000 00000000 (1=Care, 0=Don't)
Hence, we can write this as: 
 aggregate-address 96.0.0.0 252.0.0.0 summary-only
We have to be careful with the next block. We don't own network 103.0.0.0/8, so we had better not include it in any block we advertise. That limits us to a block of two, 100 and 101: 
 100.0.0.0 -> 01110100 00000000 00000000 00000000
 101.0.0.0 -> 01110101 00000000 00000000 00000000
              -------- -------- -------- --------
              11111110 00000000 00000000 00000000 (1=Care, 0=Don't)
which we can take care of with: 
 aggregate-address 100.0.0.0 254.0.0.0 summary-only
Network 102.0.0.0/8 will be advertised on its own, which is what was happening before we configured summarization. As a matter of fact, all networks were advertised individually before we started summarizing. Putting a stop to it is the whole point! Now let's look at the 129 networks ... 
 129.0.0.0   -> 10000001 00000000 00000000 00000000
 129.1.0.0   -> 10000001 00000001 00000000 00000000
 129.2.0.0   -> 10000001 00000010 00000000 00000000
    --
 129.127.0.0 -> 10000001 01111111 00000000 00000000
 129.128.0.0 -> 10000001 10000000 00000000 00000000
 129.129.0.0 -> 10000001 10000001 00000000 00000000
    --
 129.159.0.0 -> 10000001 10011111 00000000 00000000
 129.160.0.0 -> 10000001 10100000 00000000 00000000
 129.161.0.0 -> 10000001 10100001 00000000 00000000
 129.162.0.0 -> 10000001 10100010 00000000 00000000
 129.163.0.0 -> 10000001 10100011 00000000 00000000
Note that we can summarize everything from 129.0.0.0/16 through 129.127.0.0/16 into one block of 128 entries: 
 129.0.0.0   -> 10000001 00000000 00000000 00000000
 129.1.0.0   -> 10000001 00000001 00000000 00000000
    --
 129.126.0.0 -> 10000001 01111110 00000000 00000000
 129.127.0.0 -> 10000001 01111111 00000000 00000000
                -------- -------- -------- --------
                11111111 10000000 00000000 00000000 (1=Care, 0=Don't)
Which is written as: 
 aggregate-address 129.0.0.0 255.128.0.0 summary-only
We'll follow that with a block starting at 129.128.0.0/16 ... 
 129.128.0.0 -> 10000001 10000000 00000000 00000000
 129.129.0.0 -> 10000001 10000001 00000000 00000000
    --
 129.158.0.0 -> 10000001 10011110 00000000 00000000
 129.159.0.0 -> 10000001 10011111 00000000 00000000
                -------- -------- -------- --------
                11111111 11100000 00000000 00000000 (1=Care, 0=Don't)
This is a block of 32 Class "B" networks, and the appropriate command is: 
 aggregate-address 129.128.0.0 255.248.0.0 summary-only
Finally, we have the last four, which can be handled with: 
 129.160.0.0 -> 10000001 10100000 00000000 00000000
 129.161.0.0 -> 10000001 10100001 00000000 00000000
 129.162.0.0 -> 10000001 10100010 00000000 00000000
 129.163.0.0 -> 10000001 10100011 00000000 00000000
                -------- -------- -------- --------
                11111111 11111100 00000000 00000000 (1=Care, 0=Don't)
And this, of course, requires the command: 
 aggregate-address 129.160.0.0 255.252.0.0 summary-only
Handling the Class "C" networks that start with 222 is easy, just do: 
 aggregate-address 222.0.0.0 255.0.0.0 summary-only

Therfore, the BGP summary commands that Tripod will use are: 
 aggregate-address 92.0.0.0 252.0.0.0
 aggregate-address 96.0.0.0 252.0.0.0
 aggregate-address 100.0.0.0 254.0.0.0
 aggregate-address 129.0.0.0 255.128.0.0 summary-only
 aggregate-address 129.128.0.0 255.248.0.0 summary-only
 aggregate-address 129.160.0.0 255.252.0.0 summary-only
 aggregate-address 222.0.0.0 255.0.0.0 summary-only

10. We can see the problem. CLE has a discontiguous network. Therefore, when they turned off automatic summarization, routing started working. Speaking of summarization, let's look at the subnets, starting with router CLE1 ... 

 165.21.72.0  -> 10100101 00010101 01001000 00000000
 165.21.88.0  -> 10100101 00010101 01011000 00000000
 165.21.104.0 -> 10100101 00010101 01101000 00000000
 165.21.120.0 -> 10100101 00010101 01111000 00000000
                 -------- -------- -------- --------
                 11111111 11111111 11000000 00000000 (1=Care, 0=Don't)
If we place these four subnets into a block starting at 165.21.72.0, and configure it on CLE1's S0 using this command: 
 ip summary-address eigrp 1 165.21.72.0 255.255.192.0
We should be in good shape. Now let's look at CLE2 ... 
 165.21.80.0  -> 10100101 00010101 01010000 00000000
 165.21.96.0  -> 10100101 00010101 01100000 00000000
                 -------- -------- -------- --------
                 11111111 11111111 11000000 00000000 (1=Care, 0=Don't)

 165.21.128.0 -> 10100101 00010101 10000000 00000000
We can do a summary block for the first two, but the third subnet doesn't fit in. So, let's configure the summary block on CLE2's S0 using: 
 ip summary-address eigrp 1 165.21.80.0 255.255.192.0
Having configured our summarizations, we tested the configs using ping and trace, and found that it wasn't working! We couldn't reach some of the subnets. When we checked the configs, we found that they both said: 
 ip summary-address eigrp 1 165.21.64.0 255.255.192.0
That's not what we told them to do! We deleted those commands: 
 no ip summary-address eigrp 1 165.21.64.0 255.255.192.0
and then carefully put in the correct commands. E-gads! When we looked at the configs, they were wrong again! What's going on? Well, when we did the summaries on CLE1 and CLE2, we effectively told the routers that, if it falls into the block, we don't care about anything past the eighteenth bit. Therefore, the routers zeroed those bits out! The routers are smart enough to know that what we meant was the block that starts at 64, which is the lowest address that has all bits in common with what we specified (72 and 80). At least that's what they think we meant! In their quest to do us a favor, however, the routers are actually helping us to dig ourselves a hole! What we have done is told router HQ1 that we can get to everything from 64 through 127 by going to either CLE1 or CLE2, and since it is using EIGRP, it will pick the path with the best bandwidth and delay. The moral of the story is that HQ1 is sending traffic for all of the 72 through 104 subnets to CLE1 or CLE2, or load-balancing between them. Whoops! It would be nice if the router would object if you tried to start a block with the "wrong" address. It would also be nice if it would read your mind. Fat chance!

How do we fix it? The best thing to do would be to re-design the network, so that the subnets are not scattered haphazardly between CLE1 and CLE2. Ideally, we would put 64, 72, 80 and 96 on CLE1, and subnets of 128 and beyond (like 136) on CLE2. Then, we could summarize into nice blocks. For example, let's say we had the following on CLE1 ... 

 165.21.64.0  -> 10100101 00010101 01000000 00000000
 165.21.72.0  -> 10100101 00010101 01001000 00000000
 165.21.80.0  -> 10100101 00010101 01010000 00000000
 165.21.88.0  -> 10100101 00010101 01011000 00000000
                 -------- -------- -------- --------
                 11111111 11111111 11100000 00000000 (1=Care, 0=Don't)
We could summarize up through bit number 19, and get just the four we want, using: 
 ip summary-address eigrp 1 165.21.64.0 255.255.224.0
And if we put the other subnets on CLE2, say, for example ... 
 165.21.128.0 -> 10100101 00010101 10000000 00000000
 165.21.136.0 -> 10100101 00010101 10001000 00000000
 165.21.144.0 -> 10100101 00010101 10010000 00000000
                 -------- -------- -------- --------
                 11111111 11111111 11100000 00000000 (1=Care, 0=Don't)
We could summarize all three of them using: 
 ip summary-address eigrp 1 165.21.128.0 255.255.224.0
if we make sure that if 152 ever appears, it goes with this block.

Now, as far as summarizing from HQ1 to HQ2, we might expect this to happen automagically if we enable auto-summary on HQ1, since the link between HQ1 and HQ2 is on a different classful network. Since we have disabled it on CLE1 and CLE2, however, the subnet advertisements coming from CLE1 and CLE2 are flagged "Don't Auto-Summmarize Me!". If se want summarization to occur for the 165.21/16 routes, we will need to tell HQ1 to do it. This should be easy enough, but ... since we have blocks starting at 64 and 128, we can't come up with a block that will include them both, unless we use a block that covers all of 165.21/16, which would be: 

 ip summary-address eigrp 1 165.21.0.0 255.21.0.0
If all of the 165.21.0.0/16 routes are actually on this side of HQ2, this would be okay, otherwise we had best just advertise the two blocks from CLE1 and CLE2 through to HQ2.

Speaking of the link between HQ1 and HQ2, why anyone would use a Class "A" subnetted with a "/16" mask for a point-to-point link is beyond me. If we're going to waste private addresses, maybe we could use 192.168.3.0/24, instead. At least this would be consistent with the other inter-router links.

Well, that's it. Have fun with summarization!

Return to the top of this Exercise!

Return to the directory of Goodies!

Copyright © 2018 Alchemy, Inc. All rights reserved.