Dividing the Network for OSPF Implementation
When implementing OSPF on a network, one design decision affects the implementation of everything else. So, it is important that you figure out how you are going to divide the network before beginning with your implementation of OSPF. Area border points will decide where you can do summarization, what areas can be stubby or not, and how the network can grow in the future. The solution to this dilemma tends to be confusing because OSPF uses a two level hierarchy and, here, you're working with a three level hierarchy.
OSPF's two level hierarchy has a core area and areas hanging off of that core. The network uses a three level design with a core, a distribution layer, and an access layer. The third layer really isn't accounted for in OSPF.
The chapter begins by looking at where to divide the network out toward the remote sites. Should the area borders be at the edge of the core or in the distribution layer?
Distribution Layer Design Issues: The Core Routers as ABRs
First, consider putting the area borders at the edge of the network core, which means defining the core network as area 0. All of the distribution layer routers connected to a given core router will be placed in one area. There are some major advantages to placing the area border routers (ABRs) at the edge of the core; look at Figure 5-1 to see where this will lead you.
Figure 5-1. Dividing the Areas at the Core/Distribution Boundary
Following are some of the advantages of placing the ABRs at the edge of the core:
Area 0 is very small.
There shouldn't be any problems with suboptimal routing because the core routers only receive one route for any given set of destinations (summary). There aren't any distribution layer routers with two connections into the core.
All the redundant links from the remote sites into the distribution layer are within the same area.
Because all summarization will be done at the core/distribution layer border, the routing table in the core will be very small—possibly as low as six routes to reach all of the remote sites.
There are some disadvantages to placing the area borders at the core as well. The sections that follow address these disadvantages:
Summarization at the core
Dial backup past the summarization point
Redundancy and router scaling
Summarization at the Core
If you make each of the core routers ABRs, all summarization takes place at the core. As noted in Chapter 1, "Hierarchical Design Principles," this isn't something that should be done in the core. Of course, you can break this rule if the stability of the network doesn't suffer (remember, stability is the goal of this entire exercise); however, you do need to be cautious with summarizing on the core routers.
This can also cause problems with scalability when this network grows because most of the growth is likely to take place in the distribution and access layers. You face the choice of either building a larger number of areas in these layers or having rather large areas, which could be a problem. Making these areas some sort of stub (covered later in this chapter) could improve the scalability.
Dial Backup past the Summarization Point
The rebuild of the network in Chapter 4, "Applying the Principles of Network Design," opted to remove the redundant links between the distribution and core routers in favor of a dial backup link from each distribution layer router and the DMZ-to-Core router (the same router the dial-in terminal server backs up to).
If you summarize at the core routers, the process of dialing in from a distribution layer router to a different core router that it normally attaches to effectively circumvents summarization.
To get a better feel for the problems involved, consider Figure 5-2.
When the link between Router A and Router B fails, Router A is configured so that it automatically dials into Router C, restoring connectivity. But what routes does Router C advertise?
If Router B is summarizing to a relatively short prefix (for example, 172.16.0.0/16), then Router C could summarize to a slightly longer prefix length (for example, 172.16.64.0/20), and this will all work. Because Router C will be advertising a longer prefix length for these routes, the path through Router C will be chosen.
Figure 5-2. Dial Backup past the Point of Summarization
But what if Router B is advertising 172.16.64.0/20? Router C could advertise each route learned through Router B, but this effectively circumvents summarization—not good. The other option is for Router C to summarize to two longer prefixes so that some summarization is taking place. Here you could use 172.16.64.0/21 and 172.16.72.0/21.
Because the distribution layer routers have dial backup links into the core, and the core routers would be doing the summarization if the area border is between the core and the distribution layer, this is a problem in the network. On the other hand, the only time dial backup should be a problem is if the core Router B itself fails.
If the link between Router A and Router B fails, Router A will still have routes to all of the destinations reachable through the core because each remote site is dual-homed. Router A will learn all the routes it needs through some remote site back to the other distribution layer router in this area.
Of course, you don't want these dual-homed remotes to become transit paths. However, the chances of that happening isn't likely because the path through the other distribution layer router would always be better than the path through Router A, through another remote site, and, finally, up through the core.
The Distribution Layer Becomes Extraneous
If you summarize at the core router, you can effectively take the distribution routers out of the network because all they are providing you with is a bit of redundancy. By placing the area borders at the core of the network, you've effectively made this into a two-tier hierarchy.
This isn't to say that distribution layers can't be important in two-layer hierarchies. For instance, it might make sense to have a distribution layer even with a two-tier model. For example, a group of geographically close remote sites might be better off feeding into a distribution router and then to the core instead of running individual links to the core from each remote site.
Another issue is simply the number of links a router should have attached. The distribution layer isolates the core routers, to some degree, from having a large number of remote sites connected. Therefore, it isolates the core routers from various router-scaling issues. Most of these issues deal with queuing and packet forwarding rates and are out of the scope of this chapter.
Distribution Layer Design Issues: The Distribution Layer Routers as ABRs
Rather than putting the border between area 0 and the other areas at the core routers, try putting the links between the distribution routers and the core into area 0. All of the remotes behind one distribution layer router are then in the same area. Look at Figure 5-3 to see where this takes you.
Because summarization of internals can take place at the ABRs, you can summarize at the distribution layer routers. This design solution also avoids having any summarization problems with the dial backup links into the core because you can just have the distribution layer router advertise what it normally does through the dial connection.
The major drawback of this solution is that if the physical topology isn't designed correctly, the distribution layer routers can be drawn into acting as core routers. In other words, distribution layer routers can end up transiting traffic not just for the access layer devices attached to them, but also between two core routers or a core router and another distribution layer router. The physical layer design doesn't allow this to happen because there is only one link between each distribution layer and core router.
Figure 5-3. The Distribution Layer Routers as ABRs
Why wasn't the access layer broken up into to four areas? Because each access layer router is dual-homed into a single distribution layer router. The redundant links between the remote sites and the distribution layer routers would be crossing area borders. See "Case Study: Which Area Should This Network Be In?" later in this chapter to get a better feel for why this is a bad idea in general.
Finalizing ABR Placement in the Distribution Layer Design
Is it better to put the area borders at the edge of the core, or at the edge of the distribution layer? Assume the following criteria:
Summarization should occur at the distribution layer.
The physical layer design prevents the distribution layer routers from being pulled into the core.
No problems exist with dial-in between the distribution layer routers and core.
Given the options and tradeoffs, it seems best to partition the areas at the distribution layer.
Placing the HQ VLAN Routers
Next, move toward the HQ VLANs and figure out where the ABRs should be; Figure 5-4 shows only the core and the HQ VLANs in order to focus on this area.
Figure 5-4. Examining HQ VLAN Routers for OSPF Implementation
Although it isn't immediately obvious that putting the area border on the HQ VLAN routers versus the core routers to which they are attached is going to make any difference, you should run through the exercise anyway.
If you make Routers A and B the ABRs, then you summarize toward the core from them. Ignore this for now, due to the fact that you are summarizing on a core router, and consider instead what happens if Router C loses its connection to just one of the VLANs. Assume the connection is lost to 172.16.1.0/24.
Routers A and B would be oblivious to this event. They would still be advertising the 172.16.0.0/20 route toward the rest of the core. If, however, a packet were to arrive on Router A with a destination of 172.16.1.10, it will look in its routing table and find that the only route it has to this destination is the summary route.
The critical point to remember here is that when a Cisco router builds a summary route, it puts a route in the routing table to null0 for that entire range of addresses. Router A would forward this packet to 172.16.1.10 to the only route it has for that destination—null0. null0 is the bit bucket, so all traffic to 172.16.1.0/24 would be dropped by Router A.
How would this change if you were to make Routers C and D the ABRs? Go back to the scenario of Router C losing its connection to the 172.16.1.0/24 network. Instead of Router C having only a summary address in its routing table, it will have a specific route through Router D.
Of course, this assumes that all of the parallel VLANs will be running OSPF—but is this really what you want to do? You don't want these VLANs to transit traffic. (It's never a good idea to have transit traffic on a link with hosts attached.) You can configure all of these interfaces as passive and not configure OSPF on all but one of them.
You do need to run OSPF on at least one of these links to prevent packets from being sent to null0 if either Router C or Router D loses its connection to one (or more) of the VLANs. You should set aside a VLAN just for this purpose with no hosts or servers connected to it.
So, with all of the options considered, it's best to put the area border at the routers connected to the HQ VLANs rather than at the edge of the core.
Placing the Common Services Routers
Because the design of the common services networks is so similar to the HQ VLANs, the coverage won't be as in depth in this section. Consider Figure 5-5.
The major issue you face is dropping packets if either Router A or Router B loses its connection to one of the server farm segments, or the segment the mainframe is connected to.
To get around this, include the links between the core routers and the common services routers in area 0 and run OSPF on one of the links between the common services routers. This way you can summarize the parallel LANs between Routers A and B down to one advertisement, 172.16.16.0/22, into the core without risking dropping packets.
Figure 5-5. Connections to the Common Services
Placing Routers to Dial-In Links
The dial-in links connected to the terminal server are next; Figure 5-6 is reduced to only the links and routers involved for clarity.
The major problem you need to deal with here is that each time a client dials in, the Point-to-Point Protocol (PPP), which is the protocol used on the terminal server for connections to these dial-in users, installs a host route to the client's IP address in the routing table. If there is a network statement that includes that host route, it will be flooded to the entire area.
Likewise, when the client disconnects, the host route is removed from the routing table, and the removal of the route will need to be flooded to the rest of the routers in the area.
Figure 5-6. Dial-In Links and Terminal Server
You have a couple different options for reducing flooding in an area caused by dial-in users:
Make the terminal server an ABR
Stop PPP from creating the host routes
Don't run OSPF on dial-in links
Advertise the dial-in clients off of a loopback interface
The sections that follow analyze each solution before arriving at a conclusion of which solution will work best for the network segment illustrated in Figure 5-6.
Solution 1: Make the Terminal Server an ABR
One of the easiest ways to handle dial-in links in OSPF is to simply summarize these host routes out at the nearest area border—and the closer the area border is, the better. You want to affect the fewest routers possible with these constantly flapping dial-in links.
Another problem you face is that the terminal server dials into another core router for backup. If the ABR is placed on the core router, the second core router must also be an ABR for this same area in case the terminal server ends up dialing into it.
The easiest thing to do, then, is to make the terminal server itself an ABR, and summarize the host routes into one destination, 172.16.22.0/24, toward the core.
Solution 2: Stop PPP from Creating the Host Routes
You can also stop PPP from creating these host routes by configuring no peer neighbor-route on the dial interface:
interface BRI0
ip address 192.168.11.6 255.255.255.252
encapsulation ppp
dialer-group 1
ppp authentication chap
no peer neighbor-route
This gets rid of the host routes, but it doesn't provide any method to advertise the dial-in clients. One way you could advertise the dial-in clients is to use a redistributed static route, which leads us to the next solution.
Solution 3: The Static Alternative
It seems silly to make the terminal server into an ABR just to summarize these routes, and no peer neighbor-route leaves us without any way of advertising the dial-in clients.
Another way to handle this terminal server, which may or may not be easier (depending on the number of dial-up links and so forth), is to not run OSPF on the dial-in links at all. (In other words, don't cover the dial-in links with a network statement.)
Put the links between the terminal server and the core in area 0, create a static route summarizing all of the dial-in clients pointing to null0, and redistribute this static into OSPF. So, on the terminal server, you have:
ip route 172.16.22.0 255.255.255.0 null0
!
router ospf 1
redistribute static
default-metric 10
Solution 4: Advertise the Dial-In Clients Off of a Loopback Interface
Using a "static" means the route to the dial-in clients will be an external route. This may not be a problem in our network, but it could be a problem in a network where there are lots of dial-in clients attaching to terminal servers scattered all over the network because external LSAs are flooded everywhere in OSPF.
It's possible to make the route to the dial-in clients come out as an OSPF internal by assigning the address range of the clients to a loopback interface and including the loopback in OSPF. The key is to keep OSPF from advertising the network attached to the loopback interface as a host route as it normally does.
This can be accomplished by configuring the loopback interface as a point-to-point network type:
interface loopback 0
ip address 172.16.22.1 255.255.255.0
ip ospf network-type point-to-point
!
router ospf 1
network 172.16.22.1 0.0.0.0
One warning about this approach: If a loopback interface is configured as an OSPF network type point-to-point, the router will not use the loopback address as its router ID. (It normally does.)
Notice that the loopback interface is included only in the network statement under router ospf. This is so that the individual dial-in client host routes don't get picked up and advertised, as well as the loopback address.
Determining the Best Solution for Dial-In Link Router Placement
If you don't mind the external OSPF route redistributing the static route, it seems this is the least confusing solution with the lowest administrative overhead. If there were a number of terminal servers in the network, and you didn't want externals flooded from each one, advertising the route off a loopback interface is probably better.
The only problem with advertising the route off of a loopback interface is that it can be confusing to understand what's being done with the configuration, and it changes the way OSPF chooses its router ID.
To avoid confusion, use the redistributed static solution. For more information on dial-in for backup, see "Case Study: Dial Backup," at the end of this chapter.
Establishing External Connection Routes
There are two sides to external routers in OSPF. First, they must be flooded throughout the network; they can't be summarized or filtered at ABRs into area 0 at all. Other than stubby areas, external link-state advertisements (LSAs) are flooded throughout the entire network.
Furthermore, each autonomous system boundary router (ASBR) in the network floods a Type 5 LSA, advertising that it, indeed, is an ASBR and any external destinations it advertised can be reached along the path to the ASBR.
On the other hand, losing an external route only produces a partial shortest path first (SPF) run in better implementations of OSPF. Because external routes always represent leaf nodes on the SPF tree, there is no reason to recalculate the entire tree when an external route is lost.
In general, you want to reduce the number of external routes in OSPF. This is something you must consider when trying to decide how to handle links to the partner networks and the Internet. Figure 5-7 presents a better idea of what your options are.
Figure 5-7. External Network Connections
The obvious solution to all of this is to advertise a single default route from Router B into the core, which effectively summarizes all of the partner network's address space into one destination.
The problem occurs in the second link to the Internet off Router A. If you only advertised a default from Router B into the remainder of the core, you would lose connectivity to the partner networks if the Internet link failed from Router C and the alternate Internet link on Router A were to come up.
Although it would be nice to conditionally advertise destinations in the partner networks, OSPF doesn't have any sort of conditional advertisement as BGP does. Because you don't have conditional advertisement for anything but the default route, you need to examine the choices presented in the next few sections:
Advertise the default and all externals
Conditionally advertise a default route
Solution 1: Advertise the Default and All Externals
You could make Router B an ABR, putting all of the external connections into a separate area. Each router that connects to an external network would become an ASBR, redistributing routes as necessary into the rest of the network. Router C would advertise a default route.
This all sounds fine, but for each external connection made, you end up with a new external and ASBR advertisement being flooded throughout your network. You can reduce the number of ASBR advertisements readily enough by a slight change in strategy.
If you run a routing protocol other than OSPF on the DMZ (such as EIGRP, IS-IS, or RIPv2), you can redistribute all of the external destinations into this secondary routing protocol and then redistribute this protocol into OSPF at Router B. What is the advantage of doing this?
Because the DMZ is a broadcast network, when Router B redistributes the external route into OSPF, the forwarding address will be set to the router that Router B heard the advertisement from. See "Case Study: OSPF Externals and the Next Hop," later in this chapter.
As long as Router B is running OSPF on the DMZ (although no other router is running OSPF on the DMZ—it could even be a passive interface on Router B), any addresses on the DMZ will appear to be OSPF internal routes to all the other routers on the network.
This solution converts Router B into a route server for all of the external routes. This cuts down on the number of Type 5 LSAs flooded into the network by cutting down on the number of ASBRs, although the overall number of external routes aren't affected.
To handle the second Internet connection, you would make certain that Router C is actually originating the default route, and Router B is redistributing it. On Router A, you can configure a floating static route so that if the external default route being originated by Router C ever fails, the floating static route configured on Router A would take over.
Solution 2: Conditionally Advertise a Default Route
If the floating static route on Router A seems a little messy, or if you would rather have the default route originated from Router B as an internal route, you can configure a conditionally advertised default route on Router B.
You can set up a route-map to make certain the network between Router C and the Internet service provider (ISP) is up, advertising the default route only when it is. You don't have the address for the link between the ISP and Router C, so you can fake it and say it's x.x.x.x:
access-list 10 permit x.x.x.x x.x.x.x
!
route-map advertise-default permit 10
match ip address 10
!
router ospf 1
default-information originate route-map advertise-default
With this configured, Router B will advertise the default route as long as network x.x.x.x exists. You still need some way of advertising a default route from Router A to make this work correctly, either a floating static or another conditional default route. Again, you don't know the link address between Router A and the Internet connection, so use y.y.y.y:
!
ip route 0.0.0.0 0.0.0.0 y.y.y.y 200
!
router ospf 1
redistribute static
default-metric 10
Solution 3: Move the Backup Internet Connection onto the DMZ
One additional solution is to move the alternate Internet connection onto the DMZ. The advantage of this is that it simplifies routing somewhat. You don't need to conditionally advertise anything, nor do you need to advertise any of the external destinations. Just a simple default-information originate always configured on Router B will do the trick. On Router B, this looks like the following:
!
router ospf 1
default-information originate always
!
ip route 0.0.0.0 0.0.0.0 x.x.x.x
You can run some other protocol within the DMZ, which also provides some routing isolation from the rest of the network. This is the best option because it's the least troublesome to maintain, and it requires that only one link be moved (the alternate Internet connection).
It does leave a single point of failure, but this could be dealt with by adding a second router between the DMZ and the core, or some other strategy. Figure 5-8 shows what the DMZ looks like after implementing these changes.
Figure 5-8. DMZ Design with a Second Routing Protocol
To Stub or Not to Stub
Up to this point in the chapter, it seems as though the dilemma of where to place all of the ABRs in the network has been solved. With OSPF, this leaves just one other question to consider—which areas should be stubbed? There are three types of stub areas in OSPF:
Stubby— External routes are not advertised into stub areas, nor can they be generated from stub areas; routers in these areas rely on the default route to reach all externals.
Not-so-stubby areas (NSSAs)— External routes are not advertised into NSSA areas (unless they originate within the area), but they can be generated within the area.
Totally stubby— Neither external nor internal routes are advertised into a totally stubby area; all routers rely on a default route to reach any destination outside the area.
Refer to Figure 5-9, which presents how the areas are set up, to see if any of them can be stubbed.
Figure 5-9. OSPF Areas
Totally Stubby Areas
Generally you wouldn't make an area totally stubby unless it had only one exit point. None of the areas in Figure 5-9 have only one exit point. Therefore, it doesn't seem useful to totally stub any of them.
Not-So-Stubby Areas
Not-so-stubby areas are generally used for areas that originate externals and don't need any information about the interior of the network. Since you aren't originating any external routes into the network, you probably won't need any NSSAs either.
Stubby Areas
Depending on traffic flow, some of these areas might make good candidates for regular stubs. In each area, it depends on the amount of traffic destined to external hosts and whether optimum routing is important:
area 0— This area cannot be made into any type of a stub in an OSPF network.
area 1— This area probably has a good deal of traffic to external links, although that's not certain. If it does, it should remain a normal area. The number of routers in the area (two) also influences you, here; it's small enough that flooding some externals into area 1 probably isn't going to be a problem.
area 2— This area probably has very little contact with outside networks. If there is some host or service that external hosts will need to contact, suboptimum routing isn't much of an issue because both paths to the DMZ area are two hops. This could be a stub area.
areas 3 and 4— There could be a great deal of traffic to external services from these areas, but there isn't much of a chance of suboptimal routing from them to the DMZ area. These can be stub areas.