Archive for the 'Al Friebe' Category



MPLS – Part 3

When we left off, we were looking at Frame Relay as an example of a Layer-2 infrastructure. Some customers will have very few sites, and others may have thousands. The logical topology (hub-and-spoke, partial-mesh or full-mesh) for a particular customer would be negotiated between that customer and the provider, based on the customer’s number of sites, which sites communicate with which, and with what bandwidth and latency requirements. Of course, the customer’s cost increases as the number of PVCs configured and their bandwidths increase. Once the negotiations are complete, the WAN provider will establish the required PVCs between the customer’s sites.

Speaking of money, it’s in the provider’s best interest to have as many customers as possible, and a large provider may have thousands. Refer to Figure 1, which shows the PVC’s for two customers, “A” (in red) and “B” (in blue).

Note that while each customer has three sites, “A” has a full-mesh, while “B” has a hub-and-spoke (with site B1 as the hub), and that although the customers are sharing the same physical infrastructure, their traffic is kept separate. Thus, each customer has a VPN (Virtual Private Network), which means that the provider’s network acts as if there is a private WAN for each customer.

As you can see, Customer A’s site A1 has the same IPv4 address space as does Customer B’s site B1, etc. Since we’re using VPNs (which act as logically separate networks) there are no “address collisions” despite the overlapping address spaces. In fact, the provider’s addressing scheme (Layer-2) is completely independent of those of the customers’ Layer-3 networks. In other words, the provider doesn’t know or care what IPv4 subnets the customers use, or whether the customers are using IPv4 at all (they could just as well be using IPv6, IPX, Appletalk, DECnet, SNA, or whatever). As long as the packet can be encapsulated using Frame Relay, the provider can get it where it needs to go.

Also, because the provider doesn’t know what routed protocols the customers are using, the provider has nothing to do with the customer routing protocols, either. The system we’re using is commonly referred to as an “overlay VPN”, because we have “overlayed” (superimposed) a VPN for each customer onto the provider’s Layer-2 network

Considering all of this, we can summarize the advantages of overlay VPNs as follows:

  • A common physical infrastructure is shared between customers.
  • Customers can independently choose any logical topology they want.
  • Customers can use any combination of Layer-3 protocols they desire.
  • There are no “address collisions” between customers.
  • The provider does not participate in customer routing.

Since they offered great flexibility at reasonable cost, overlay VPNs using X25, ATM and Frame Relay became very popular over the past few decades.

Next time, we’ll look at the disadvantages of using overlay VPNs.

Author: Al Friebe

MPLS – Part 2

When we left off, we were examining the feasibility of using a Layer-2 topology within a WAN provider’s cloud, as shown in Figure 1:

Having built the physical topology using Layer-2 switches and interconnecting links, let’s see how we might establish customer connectivity, using Frame Relay as an example. With Frame Relay, the Layer-2 address contained within the frame header is a ten-bit value called a DLCI (Data-Link Connection Identifier). The WAN provider builds a table within each switch that forwards frames based on a combination of the inbound interface and DLCI. Here’s an example of a Frame Relay switching table:

Inbound DLCI Inbound Interface Outbound DLCI Outbound Interface
101 1 456 2
246 1 801 3
982 2 101 1
300 3 254 2

For example, when a frame enters the switch with DLCI = 246 on Interface 1, the DLCI is changed (swapped) to 801, and the frame is then forwarded out Interface 3. Note that with Frame Relay, unlike Ethernet, the Layer-2 addresses (DLCIs) can (and usually do) change at each switch hop as a data frame traverses the provider’s cloud. Once the provider has programmed the switches along the path with the correct DLCIs, the customer can then use the circuit. As an example, let’s look at Figure 2: Continue reading ‘MPLS – Part 2′

MPLS – Part 1

You may have heard the term “MPLS”, but not know much about it. If so, it’s time to learn more!

Imagine that you’re a WAN service provider, and that you make your money by leasing bandwidth to customers. A customer’s goal is to reliably connect its sites together so that its applications run correctly, while spending as little as possible on WAN services. Your goal is to make as much profit as possible while keeping your customers reasonably happy. To illustrate the concepts, we’ll need an example topology.

As you can see, the WAN provider has a Customer “A” with six sites that must be connected together. For good performance of the customer’s VoIP application, a full-mesh topology is required. One possible solution would be for the provider to run an actual physical wire, fiber or wireless link (terrestrial or satellite microwave) from one customer site to another, as shown

Continue reading ‘MPLS – Part 1′

OSPF Part 12: Stub Areas

Last time, we had just finished configuring Area 1 as an OSPF stub area.

At this point, the best paths from R5’s perspective are:

  • Subnet A via R3 (cost = 3)
  • Subnet B via R3 (cost = 3)
  • Subnet C via R4 (cost = 3)
  • Subnet D via R4 (cost = 3)
  • RIP and EIGRP clouds via defaults from R3 and R4 (cost = 1)

Now let’s suppose that R5 wants to get a packet to the RIP cloud. Since R5 is receiving the default route from both R3 and R4, if the metrics are the same (which they would be unless we change them), R5 will load-share traffic for the RIP cloud between R3 and R4. In other words, half of the packets bound for the RIP cloud will take the sub-optimal path via R4. Likewise, since R5 will load-share packets for the EIGRP cloud, half of those packets would take the sub-optimal path via R3. The bottom line is that as a result of hiding information from R5, routing is no longer optimal. The possibility of sub-optimal routing exists whenever summarization is used and there are multiple paths (and OSPF stub areas are a type of summarization).

Continue reading ‘OSPF Part 12: Stub Areas’

OSPF Part 11 – Summarization Options

Continuing with our discussion of OSPF summarization options, refer to the figure below…

When we left off, we had reduced the number of Type-5 LSAs being injected into the OSPF cloud from two hundred to two, a summary route from each ASBR. But what if the prefixes that lie within the RIP or EIGRP clouds cannot be easily summarized (a situation which occurs all too often in real life)? In that case, instead of one large summary block, we could configure the ASBRs with multiple smaller summary blocks, by using multiple OSPF “summary-address” commands. The resulting Type-5 LSAs would then flood through Area 0 and into Area 1, but this is better than having every router know about each individual external prefix.

Notice that to reach any external prefix, R5 must send the packet towards Area 0. We can take advantage of this by configuring Area 1 as an OSPF “stub” area.  To do this, we use the OSPF “area stub” command on all routers connected to the area (including any ABRs). If we do, each ABR will inject a default route into Area 1, and no Type-5 LSAs are injected.

Continue reading ‘OSPF Part 11 – Summarization Options’

OSPF – Part 10

Having discussed how OSPF works without summarization options, let’s take a look at the various summarization options and their effects.

If there are 100 prefixes in the RIP cloud, and another 100 in the EIGRP cloud, each being injected into the OSPF domain by the ASBRs, each OSPF router will be tracking over 200 individual prefixes, and using RAM to store each in its LSDB and routing table. Also, a change to any external prefix will require advertisement of the change to all OSPF routers, which consumes bandwidth. Finally, any change to a router’s LSDB triggers Dijkstra’s SPF algorithm, which consumes CPU. For this reason, running a large OSPF topology “wide open” (without summarization) is not scalable.

Let’s start by using the OSPF “summary-address” command on R3, an ASBR. If we’re lucky (in other words, if the addresses in the RIP cloud have been allocated correctly), we can summarize the prefixes in the RIP cloud into one summary block. Assuming that’s the case, R3 will now be injecting only one Type-5 LSA into the OSPF cloud.

One might wonder, “What OSPF cost will be assigned to the Type-5 LSA for the summary block?” There are two options. One is to set the cost of the block equal to that of the lowest-cost prefix within the block, in accordance with RFC 1583. This is the default method. The second option is to set the cost of the block equal to that of the highest-cost prefix within the block, in accordance with RFC 2328. This is configured with the OSPF command “no compatible rfc1583”. In general, it probably doesn’t matter which method is used, but to prevent sub-optimal routing, it should be consistent within the OSPF autonomous system. We’ll just go with the default (“compatible rfc1583”).

If the EIGRP prefixes fall into a nice block, we can use the OSPF “summary-address” command on R4 to advertise that block into OSPF. At this point, the best paths from R5’s perspective are:

  • Subnet A via R3 (cost = 3)
  • Subnet B via R3 (cost = 3)
  • Subnet C via R4 (cost = 3)
  • Subnet D via R4 (cost = 3)
  • RIP cloud via R3 (1 summary route at cost = 21)
  • EIGRP cloud via R4 (1 summary route at cost = 21)

Note that we’ve saved RAM, bandwidth and CPU within the OSPF cloud due to the reduction in Type-5 LSAs being generated, advertised and stored. We’ve also saved additional RAM due to the reduction in sizes of the routing tables. So far, so good.

Next time, we’ll discuss additional summarization options.

Author: Al Friebe

OSPF – Part 9

Continuing on with our detailed discussion of OSPF, let’s look at how OSPF routers handle prefixes from external routing domains. Refer to Figure 1:

Let’s say that there are 100 subnets in the RIP cloud. If we configure R3 to redistribute the RIP routes into OSPF (using the “redistribute” command under OSPF), R3 will be an ASBR (Autonomous System Boundary Router). Likewise, let’s assume that there are also 100 prefixes within the EIGRP cloud, and that we have configured R4 as an ASBR, redistributing EIGRP into OSPF. As part of their ASBR function, R3 and R4 will advertise each individual prefix within their respective external routing domain into Area 0, using a Type 5 (external) LSA. Since by default Type 5 LSAs have autonomous system flooding scope, they will be passed into Area 1 by R3 and R4. Thus, R5 will have two possible paths (via R3 or R4) to all 200 external prefixes.

When configuring an ASBR, we have the option of including or ignoring internal costs (those of the links within the OSPF cloud) when calculating the metrics to external destinations. Let’s assume that “O E1” (“OSPF External Type 1”) routes are used, for which the internal metrics are considered. If we look at things from R5’s perspective, each of the destinations listed would be reached using the lowest-cost path, via the specified next hop:

  • Subnet A via R3 (cost = 3)
  • Subnet B via R3 (cost = 3)
  • Subnet C via R4 (cost = 3)
  • Subnet D via R4 (cost = 3)
  • RIP cloud via R3 (100 prefixes, each at cost = 21)
  • EIGRP cloud via R4 (100 prefixes, each at cost = 21)

At this point, each router within the OSPF routing domain will know the best path to each individual prefix within the OSPF cloud, as well as to each individual prefix within the RIP and EIGRP clouds. The best path to each external prefix will appear in R5’s IP routing table as “O E1” route.

Next time, we’ll take a detailed look at OSPF’s route summarization features, including possible unintended consequences of their use.

Author: Al Friebe

OSPF – Part 8

Having discussed OSPF route summarization and the various types of stub areas, let’s look at the potential drawbacks of using those features. We’ll start by reviewing how OSPF acts before any summarization features are configured. Refer to Figure 1:

As you can see, R3 connects Area 0 and Area 1 together, making R3 an OSPF ABR (Area Border Router), and likewise for R4 (for fault-tolerance, it’s always a good idea to have two ABRs connecting a pair of areas). As part of their ABR function, both R3 and R4 will advertise each individual prefix within Area 0 into Area 1 (and vice-versa) using a Type 3 (Summary) LSA (Link State Advertisement). Each individual Type 3 LSA sent into Area 1 by the ABRs will appear in R5’s LSDB (Link State Data Base).

As we know, each OSPF router uses Dijkstra’s SPF (Shortest Path First) algorithm to determine the lowest-cost path to each prefix. For this simple topology, we can see by inspection that R5 (an OSPF internal router) will have two possible paths (via R3 or R4) to each prefix within Area 0.

Assuming that all of the links within the OSPF domain are Fast Ethernet, each link will have an OSPF cost of 1 (by default Cisco routers set the OSPF link cost equal to 100 Mbps divided by the bandwidth). Therefore, from R5’s perspective, we should have the following lowest-cost paths:

  • Subnet A via R3 (cost = 3)
  • Subnet B via R3 (cost = 3)
  • Subnet C via R4 (cost = 3)
  • Subnet D via R4 (cost = 3)

Note that all four subnets can also be reached the “long way around” (for example, Subnet A via R4 at a cost of 4), but those paths would not be used if a lower-cost path exists. The best path to each prefix within Area 0 will appear in R5’s IP routing table as an “O IA” (OSPF Inter-Area) route.

Next time, we’ll discuss how R5 sees the prefixes within the RIP and EIGRP clouds.

Author: Al Friebe

OSPF, Part 7

Yep, we’re up to part seven … there is a lot you can do with OSPF! For this discussion, we’ll use the example topology shown in Figure 1.

From here, we can see that R2, R3 and R5 are ABRs (connecting OSPF areas), and that R5 and R6 are ASBRs (connecting the OSPF autonomous system to other routing domains). Because they are not ABRs, R1, R4 and R6 are referred to as “internal routers”. Also, because R2, R3, R4 and R5 have connections to Area 0 (the OSPF backbone), they are “backbone” routers. Note that a router can play several roles simultaneously, such as R5, which is a backbone router, an ABR, and an ASBR. When assigning a router multiple functions, take care that you don’t run it out of RAM and/or CPU.

Let’s assume that we have configured summarizations on the ABRs for routes being advertised from Area1 and Area 2 into Area 0, and on the ASBRs for routes being redistributed from RIP and EIGRP into OSPF. Instead of summarizing routes from Area 0 into Area 1 or Area 2, though, we’ll make use of another common OSPF feature, the “stub” area.

As you can see from Figure 1, the only way to get from Area 1 to the EIGRP and RIP routing domains is via R2 or R3. We can exploit this by configuring Area 1 as an OSPF stub area. The effect will be that instead of advertising external routes into Area 1, the ABRs will each advertise a default route. R1 will now know:

  • All of the individual subnets within Area 1
  • Summary routes via R2 and R3 for the other areas
  • Default routes via R2 and R3 which allow it to reach the outside world.

R1 will choose the lowest-cost paths between R2 and R3 to the other areas and the outside world, and load-share between them in case of a tie.

So far, so good, but when it comes to conserving RAM, bandwidth and CPU on R1, we can do even better by configuring Area 1 as “totally stubby”. R2 and R3 will now suppress the advertisements of inter-area routes into Area 1, with the result that R1 will now know:

  • All of the individual subnets within Area 1
  • Default routes via R2 and R3 which allow it to reach everything beyond Area 1

Note that “totally-stubby” is a Cisco term, but other vendors’ routers may have a functionally-equivalent mode.

Continue reading ‘OSPF, Part 7′

OSPF – Part 6

Carrying on with our discussion of multi-area OSPF, refer to the example topology shown in Figure 1:

Recall that we’ve allocated the IP address space as follows:

  • Area 0: 10.0.0.0/24 through 10.0.255.0/24 (256 subnets)
  • Area 1: 10.1.0.0/24 through 10.1.255.0/24 (256 subnets)
  • Area 2: 10.2.0.0/24 through 10.2.255.0/24 (256 subnets)

By default, all routers will know about the existence of all 768 subnets, but we can configure the ABRs to advertise summary routes between areas with the OSPF “area range” command. Assuming that R2 is running OSPF process ID 1, we’d tell R2 to summarize the “/16” block of routes within Area 1 into Area 0 like this:

  • R2(config)#router ospf 1
  • R2(config-router)# area 1 range 10.1.0.0 255.255.0.0

Likewise, we tell R2 to summarize the “/16” block of routes that lies within Area 0 into Area 1:

  • R2(config-router)# area 0 range 10.0.0.0 255.255.0.0

Note that in each case the area number specified is that of the area which contains the routes, not the area into which the summary block is being advertised. Similarly, we can configure route summarization on R4 between Area 2 and Area 0:

  • R4(config-router)# area 2 range 10.2.0.0 255.255.0.0
  • R4(config-router)# area 0 range 10.0.0.0 255.255.0.0

That’s it! We’ve just dramatically reduced the sizes of the routing tables on all routers in the OSPF autonomous system.

Now, let’s say that for fault-tolerance, there are two ABRs joining a pair of areas. Refer to Figure 2, in which R6, an additional ABR between Area 1 and Area 0, has been added:

What happens if we configure R2 to summarize the routes from Area 1 into Area 0, but we don’t configure R6 to do the same? Since R6 is advertising the individual subnets, the routers within Area 0 will know them, as well as the summary route they learn from R2. Since a router prefers the longest match to a particular destination, the traffic bound from Area 0 into Area 1 will flow via R6 (a “/24” beats a “/16”). Thus, to minimize the size of the routing tables in the adjacent areas, we should configure the same summarizations on both R2 and R6. This will also facilitate load-sharing between the ABRs for traffic traveling between the areas.

What about connections to the outside world? Refer to Figure 3, in which R5 has been made an ASBR (Autonomous System Boundary Router), connecting the OSPF autonomous system to a RIP routing domain:

To make R5 an ASBR, we would need to configure “route redistribution” from RIP into OSPF (redistribution is a CCNP topic). Once that’s done, R5 will advertise the individual prefixes it learns via RIP into OSPF, and they will be passed throughout Area 2, into Area 0, and also into Area 1. If we like, we can also configure route summarization on the ASBR. Assuming that the RIP cloud contains subnets that fall within the address block of 172.16.0.0/16, we would configure the OSPF summary route like this:

  • R5(config-router)#summary-address 172.16.0.0 255.255.0.0

The result would be that R5 will advertise the summary block 172.16.0.0.16 into Area 2, where it will be learned by R4, which will advertise it into Area 0. The advertisement will flood across Area 0 and be learned by R2 and R6, which will both advertise the summary route into Area 1. The result is that R5 (the ASBR) will know all of the individual routes it learned via RIP, and all of the other routers in the OSPF autonomous system will know the summary route for the external routing domain.

Next time, we’ll discuss some additional OSPF scalability features.

Author: Al Friebe

« Previous PageNext Page »


Follow us on Twitter

CCNP Prep Kit

Posts by Author & Technology

Archives