This blog covers the following topics:
- Stable and scalable routing designs for EIGRP for IPv4
- Stable and scalable routing designs for OSPF for IPv4
- Stable and scalable routing designs for BGP for IPv4
We cover these topics in the CCNP ENARSI course.
This chapter is essential for CCNP ENARSI certification and it will begin by reviewing some general routing concepts and aspects regarding route summarization. Next, it will analyze other routing topics, such as route filtering and redistribution. Finally, it will explore details and best practices that are essential for scalable routing designs when using EIGRP, OSPF, and BGP.
We cover routing basics in our free Network+ book if you need to brush up.
Concepts of Routing Protocols
Before analyzing details about each individual routing protocol, some general information about IP routing will be presented first. Network designers should know the key characteristics that different routing protocols have because they will be in a position to recommend specific routing protocols for different projects. The first key decision criteria is figuring out whether static or dynamic routing should be used. Static routing implies manually defining routes on devices and dynamic routing implies using a dedicated routing protocol that will build the routing table.
Even though static routes may not seem necessary in modern networks, there are situations in which they can offer granular control and optimization of the information learned by the routing protocols. Static routes can be used in conjunction with dynamic routing protocols to reach specific networks or to provide the default gateway (e.g., pointing to the ISP), which is useful in situations where the destination network is not part of the routing protocol database.
Another scenario in which static routes are used is to override some dynamically learned routing information. Static routing can also be used in the form of floating static routes, for example, setting the Administrative Distance (AD) of a particular static route to a higher (worse) value than the AD value of the same route learned via a routing protocol for failover reasons.
An important decision to be made when choosing the routing protocol is whether an Interior Gateway Routing Protocol (IGRP) or an Exterior Gateway Routing Protocol (EGRP) will be needed. When routing between devices within an organization (Autonomous System – AS), there are many IPv4-based IGRPs to choose from, such as the following:
Note: RIPv1 and IGRP are considered legacy protocols and some modern network devices do not support them.
On Demand Routing (ODR) is a Cisco proprietary protocol designed for hub-and-spoke topologies. It offers basic routing functionality and works over Cisco Discovery Protocol (CDP). The most common interior protocols used in non-hub-and-spoke environments are RIPv2, OSPF, IS-IS, and EIGRP. IPv6 uses specially developed versions of routing protocols, such as the following:
- EIGRP for IPv6
Routing between ASs (from large corporations to the Internet, or between ISPs) is accomplished using special routing protocols called EGRPs. The most common EGRP for both IPv4 and IPv6 is the Border Gateway Protocol (BGP). Some companies have a very complex and large network infrastructure that spans worldwide, so they use BGP inside their network as their IGRP.
Large networks, including the Internet, are based on the AS concept. An AS defines a group of network devices under a common administration, and most often this defines a large organization or an ISP. Routing protocols can be classified based on different criteria. Depending on the zone in which they operate, they can be considered interior (inter-AS) routing protocols or exterior (intra-AS) routing protocols. Interior routing protocols can be further classified as distance vector routing protocols and link-state routing protocols, based on their behavior regarding the router update exchange process. Each routing protocol type will be covered in detail in the following sections, along with their respective design considerations.
Interior Routing Protocols
Interior routing protocols are configured on groups of routers from the same AS; thus, the routing activity never leaves the organization’s premises.
Figure 5.1 – Routing Protocols
Figure 1 above illustrates the different routing protocols available. An important aspect that must be considered when selecting the routing protocol is the difference between distance vector and link-state routing protocols. Link-state routing protocols were developed after distance vector routing protocols and they are much more sophisticated. A special category involves the hybrid routing protocols that feature the best attributes of distance vector and link-state technologies. The only hybrid routing protocol used in modern networks is EIGRP.
Distance vector routing protocols include:
Link-state routing protocols include:
Distance Vector Routing Protocols
Distance vector routing is a property of certain routing protocols that build an internal picture of the topology by periodically exchanging full routing tables between the neighbor devices. The main difference between distance vector routing protocols and link-state routing protocols is the way they exchange routing updates. Distance vector routing protocols function using the “routing by rumor” technique, as every router relies on its neighbors to maintain correct routing information. This means the entire routing table is sent periodically to the neighbors, as illustrated in Figure 2 below:
Figure 2 – Distance Vector Routing Protocol Behavior
The most important advantage of distance vector routing protocols is that they are easy to implement and maintain. The downside is the convergence time. A converged network is a network in which every router has the same perspective of the topology. When a topology change occurs, the routers in the respective area propagate the new information to the rest of the network. Because this is done on a hop-by-hop basis (i.e., every router passes its fully updated routing information to each neighbor), network convergence is finally established after a significant amount of time has passed.
In addition to the downsie of slow convergence, because full routing table exchanges occur between the routers, distance vector routing protocols are more bandwidth intensive than link-state routing protocols are. This happens especially in large networks, where routing tables can be of considerable size. Based on these aspects, distance vector routing protocols are recommended only in small Enterprise Network implementations.
An example of a distance vector routing protocol still used in modern networks is RIPv2 (described in RFC 2453). RIPv2 uses a hop count as the metric for path selection, with a maximum hop count of 15. RIPv2 updates are sent using multicast by default, although they can be configured as unicast or broadcast, and, unlike its predecessor (RIPv1), RIPv2 permits Variable Length Subnet Masking (VLSM) on the network.
Devices receive routing information from their neighbors and pass it on to other neighbors. RIP repeats this process every 30 seconds. The downside in this scenario is that when the network is stable and there are no changes in the topology, RIP still sends its routing table every 30 seconds, which is not very effective because it wastes bandwidth.
Note: Although it is widely believed that all of the routing table information is exchanged between neighbors, actually only the best routes are exchanged through the routing updates. Alternate routes are not included in the routing update packets.
If a router that uses a distance vector routing protocol has inaccurate information, that information will propagate through the entire network. Distance vector routing protocols are prone to major problems, including routing loops.
Link-State Routing Protocols
Link-state routing protocols do not generally “route by rumor.” The routing devices exchange information about their link-states between them. Devices build a map of the network (i.e., they do not rely on a map of a particular node) independently and loop-free based on the link-state information each router generates and propagates to the other routers.
Unlike distance vector routing protocols, link-state routing protocols flood information about its links to a specific area or to all of the routers in a specific area. This way, every router in the topology has detailed knowledge of a specific area, unlike the routers using distance vector routing protocols, where only the best routes are exchanged between neighbors. The routing decisions are made by applying the Shortest Path First (SPF) or Dijkstra’s algorithm to the information received from various sources. The result of this calculation consists of the shortest path to each destination in the network.
Figure 3 – Link-State Routing Protocol Behavior
Figure 3 above illustrates link-state routing protocol behavior. This is a much more efficient approach to building routing databases, and there is no fixed updated timer like in the distance vector technologies case. Link-state protocols re-flood their entire routing information periodically to ensure that the network is properly converged.
Link-state routing protocols offer a series of important advantages compared to distance vector routing protocols. The most important advantage relates to the convergence factor. Convergence occurs much faster because as soon as a network topology changes, only that specific information is sent to the routers in a given area. The routing updates stop after all of the routers learn about the specific change, thus decreasing the need for bandwidth, unlike with distance vector routing protocols that periodically exchange routing tables, even if no topology change occurs. In link-state routing, updates are triggered only when a link-state changes somewhere in the network. Depending on the routing protocol used, this can mean a link going up or down or changing some of its parameters (e.g., bandwidth).
Examples of link-state routing protocols are OSPF (Open Shortest Path First), described in RFC 2328, and IS-IS (Intermediate System-to-Intermediate System), described in RFC 1142.
Note: An interesting and special routing protocol is EIGRP (Enhanced Interior Gateway Routing Protocol), a Cisco proprietary protocol. It has both distance vector and link-state characteristics. It is also called a hybrid or an advanced distance vector routing protocol.
Exterior Routing Protocols
Exterior routing protocols run between ASs and the most common example is BGPv4. The main reason to use different types of routing protocols to carry routes outside of the AS boundaries is to exchange a large amount of route entries. In this regard, exterior routing protocols support special options and features that are used to implement various policies. The routing metrics for these kinds of protocols include more parameters than for interior routing protocols because of the need for flexible routing policies and choosing the best possible path.
While interior routing protocols are used within Enterprise Networks, BGP is typically used in ISP-to-ISP or ISP-to-Enterprise connections. Unlike intra-AS protocols that make routing decisions based exclusively on the metric value, the policies for inter-AS protocols can also include other factors, such as business decisions or possible AS vulnerabilities (e.g., monetary costs, preferred provider, non-secure provider, geographical traffic path, and others). These are technically implemented by configuring different BGP parameters.
A typical scenario in which the use of BGP is beneficial because of its flexible policy implementation is an organization that is connected to multiple ISPs (multi-homing). BGP can interconnect with any interior routing protocol used inside the Enterprise Network, so administrators have maximum flexibility when it comes to choosing a suitable interior routing protocol. A simple example of this scenario is presented in Figure 4 below:
Figure 4 – Enterprise Multi-Homing Scenario
Other Considerations for Routing Protocols
Another key parameter of routing protocols and a measure of their sophistication is whether they have a hierarchical or a flat behavior. IS-IS and OSPF and can be configured in a hierarchical manner and they offer improved scalability. For example, OSPF splits the topology into multiple areas and uses the Area 0 (backbone) concept, which connects to every other area in the topology. Routes can be summarized as they enter or leave the backbone, which leads to increased efficiency and bandwidth optimization. IGRP and RIP are examples of routing protocols that are based on a flat behavior because they are not optimized and they use a single structure, no matter how large the network is.
One task for the router is choosing the best way to get to a destination. If a router learns different paths to a destination from different protocols, the router must decide which prefix it should listen to. To make this decision it uses Administrative Distance (AD). Lower AD values are preferred over higher AD values, so, for example, OSPF routes (AD=110) will be preferred over RIP routes (AD=120). The AD value represents how trustworthy a particular routing protocol is. The most common AD values are summarized below:
|Routing Protocol||AD Value|
|Static Pointing at IP Address||1|
The AD is the way a router selects a route based on one protocol over another, but something else that must be decided is the way in which the device will select a routing table entry over another entry from the same protocol. Routing protocol metrics are used to make this decision.
Different routing protocols use different metrics. RIP uses the hop count as a metric, selecting the best route based on the lowest number of routers it passed through. This is not very efficient because the shortest path can have a lower bandwidth than other paths. OSPF is more evolved and takes bandwidth into consideration, creating a metric called cost. Cost is directly generated from the bandwidth value, so a low bandwidth has a high cost and a high bandwidth has a low cost.
EIGRP is even more sophisticated and uses a composite metric, considering both bandwidth and delay values to create the metric value. BGP, the most sophisticated of all, uses many different attributes grouped in path vectors that can be used to calculate the best path.
Note: One of the reasons RIP has a high AD value is that it uses the hop count metric, which is not very efficient in complex environments. The more sophisticated the metric calculation is, the lower the AD value assigned to different routing protocols.
Routing Problems and Avoidance Mechanisms
As mentioned, distance vector routing protocols are prone to major problems as a result of their simplistic “routing by rumor” approach. Distance vector and link-state routing protocols use different techniques to prevent routing problems. The most important mechanisms are as follows:
- Invalid timers: These are used to mark routes as unreachable when updates for those routes are not received for a long time.
- Hop-count limit: This parameter marks routes as unreachable when they are more than a predefined number of hops away. The hop-count limit for RIP is 15, as it is not usually used in large networks. Unreachable routes are not installed in the routing table as best routes. The hop-count limit prevents updates from looping in the network, just like the TTL field in the IP header.
- Triggered updates: This feature allows the update timer to be bypassed in the case of important updates. For example, the RIP 30-second timer can be ignored if a critical routing update must be propagated through the network.
- Hold down timers: If a metric for a particular route keeps getting worse, updates for that route will not be accepted for a delayed period.
- Asynchronous updates: These offer another safety mechanism that prevents the routers from flooding the entire routing information at the same time. As mentioned, OSPF does this every 30 minutes. The asynchronous updates mechanism generates a small delay for every device so they do not flood the information exactly at the same time. This improves bandwidth utilization and processing capabilities.
- Route poisoning: This prevents routers from sending packets through a route that has become invalid. Distance vector routing protocols use this to indicate that a route is no longer reachable. This is accomplished by setting the route metric to a maximum value.
- Split horizon: Split horizon prevents updates from being sent out of the same interface they came from because routers in that area should already know about that specific update.
- Poison reverse: This is an exception to the split horizon rule for the poisoned routes.
Route Summarization and Filtering
Route summarization results in routing designs that are more scalable, regardless of the routing protocol used (e.g., RIPv2, EIGRP, or OSPF), as it places network addresses into usable blocks, which can be used for multiple purposes; for example:
- NAT blocks
- Blocks used in redistribution
- Blocks for management VLANs
- Blocks for content services
Route summarization can be used in medium-sized to large networks for faster convergence and to better support sensitive traffic and services, such as VoIP and storage. Convergence time is measured based on the time the SPF recalculations take place in OSPF or the diffusing algorithm runs in EIGRP. An example of route summarization is aggregating a number of Access Layer addresses (172.30.16.0/24 through 172.30.23.0/24) into a single prefix (172.30.16.0/21).
A special form of route summarization can be implemented in the form of default routing. Every modern network usually uses some type of default routing. A best practice is to dynamically advertise the default route 0.0.0.0/0 in an organization from the edge routers, as they connect to the ISPs, as opposed to performing a static route configuration on every router in the organization. This way, all of the external traffic can be routed to the ISP.
When configuring a static default route on every router in the organization to the ISP router, the next hop is the ISP-connected router instead of the directly connected peer router. This could be a problem as it can cause black holes in the network if the path to the ISP router is not available. In addition, this creates a great deal of configuration overhead, as every router must be reconfigured as the exit point changes or another ISP connection is added for redundancy or high availability. Since this implies using manual configuration, this process will involve much more overhead.
A more efficient scenario would be to configure a static route on the organization’s edge devices, and then redistribute that route into the dynamic routing protocol. The egress traffic will leverage whatever metric the routing protocol uses and will find the best path to the ISP.
With any interior routing protocol (except for EIGRP), the “default-information originate” command can be used to generate a default route. However, with EIGRP, the “ip default-network <prefix>” command must be used to configure the last-resort gateway or the default route. This network must be in the route, either as a static route or as an IGRP route, before the EIGRP router will announce the network as a candidate default route to other EIGRP routers.
With a site-to-site VPN connection, it might be a good idea to advertise the corporate summary route or a default route to the company’s headquarters. For example, if the goal is to advertise the 10.0.0.0/8 route to remote sites using Easy VPN Server and Easy VPN Remote, Reverse Route Injection (RRI) can be used to make that possible.
Default Routes and OSPF Stub Areas
OSPF can define different types of stub areas. This method allows for automatic route filtering between areas on the Area Border Routers (ABRs). OSPF supports the following area types:
- Normal area
- Stub area
- Totally stubby area
- Not so stubby area (NSSA)
- Totally not so stubby area (totally NSSA)
Whatever information is filtered or suppressed will be replaced by a default route (0.0.0.0/0). OSPF filters routes between areas only on ABRs; it does not filter prefixes within a single area (intra-area).
Figure 5 – Default Route in a Hub-and-Spoke Scenario
In Figure 5 above, R1 is the hub (headquarters) in the hub-and-spoke topology and the default route to R1 is advertised to the spokes (branches). The branches are defined as stub areas and they cover different networks: 192.168.2.0/24, 192.168.3.0/24, and 192.168.4.0/24. When the spoke routers (R2, R3, or R4) need to communicate with another spoke router, they send traffic to the hub because of the default route and the default route forwards it to the specific spoke. This way, spokes do not have knowledge of the entire network topology and they learn to send all external traffic to the hub router. Something similar can be achieved with EIGRP by originating the default route to a remote location and filtering other prefixes to the stub routers.
Route filtering allows the control of network traffic flow and it prevents unwanted transit traffic, especially in situations that feature redundancy or multiple paths. Route filtering protects against erroneous routing updates and there are several techniques that can be used in this regard. For example, if OSPF Core Layer connectivity is lost, traffic should not be rerouted through a remote site.
OSPF inter-area transit traffic is achieved only by transiting Area 0 or by creating a virtual link as a temporary workaround for possible design issues that prevent having a continuous backbone area. With EIGRP, stub routers can be configured or routes other than the default route can be filtered. With BGP, route filtering can be used to stop a router from becoming a transit between two ISPs to prevent a large amount of traffic from going through the network.
“Defensive filtering,” in which route filtering protects against illegal or unwanted routing traffic, can also be implemented. It is very common for organizations to have extranets, partner networks, or connections to other business or strategic partners. Defensive filtering offers protection in situations where unauthorized routing information is received from an external partner network (e.g., the network is advertising back to the campus prefix).
Without defensive route filtering, erroneous partner advertisements can cause many problems. For example, a strategic partner might have a static route to the Microsoft SharePoint server farm because they are using those services on port 80. If these routes start leaking into the EIGRP or OSPF routing process, then part of the original network might think the SharePoint server farm has actually been moved to an area behind the partner router. Defensive filtering will help prevent this type of scenario, as it prevents leakage and network disruption and enhances security. Defensive filtering is also known as route hiding or route starvation and it can be accomplished using a variety of techniques, for example, with route filters and prefix-lists.
Route redistribution is a very effective route manipulation and management tool, and some of the most important reasons for redistributing routes include the following:
- It is an excellent way to control, manipulate, and manage the routing updates.
- It is an essential mechanism when deploying two or more routing protocols.
- It is a beneficial tool after a merger/acquisition has been achieved.
Route redistribution should be carefully implemented because it can cause suboptimal routing and create black holes in the network. Cisco recommends having distinct regions of routing protocols and to carefully redistribute routing information, as opposed to following an ad-hoc approach to implementing routing protocols.
In addition, if there is more than one link between two network regions using different routing protocols (e.g., EIGRP and OSPF), mutual redistribution might be a consideration, with the redistribution of OSPF into EIGRP and EIGRP into OSPF. When implementing mutual redistribution, it is important to prevent the re-advertisement of information back into the routing area from which it originally came.
Figure 6 – EIGRP to/from OSPF Route Redistribution
Analyzing Figure 6 above, filters are used to prevent the OSPF information that was redistributed into EIGRP information from being re-advertised back into the OSPF part of the organization. This is often referred to as “manual split horizon.” If filtering is not used and there is an outage, routing loops or a strange convergence behavior can appear and this leads to instability in the network design. Both OSPF and EIGRP support route tagging, which facilitates this process. Route maps can be used to add numeric tag-specific prefixes. The tag information is passed along in routing updates and other routers can filter routes that match or do not match specific tags. This can be accomplished using route maps in distribution lists.
Note: The tag values of 110 and 90 used in Figure 5.6 above reflect the ADs of OSPF and EIGRP. While this is not mandatory, it is a recommended best practice when carrying out complex redistribution because this technique helps to easily identify the original protocol that generated each route.
Routing Protocol Migration
Some situations call for migrating between routing protocols, for example, where one company is purchased by a larger company that has a security policy that prevents the use of any proprietary protocols anywhere in the organization. If the purchased company previously used EIGRP, it would have to migrate quickly to OSPF to adhere to the new organization’s policy. There are two ways to migrate between routing protocols:
- Using AD: This involves turning on the new protocol (OSPF in the example above) and then making certain that it has a higher AD than the existing EIGRP routing protocol. This procedure enables OSPF and allows adjacency and the routing databases to be referred to, but it will not actually rely on the OSPF routing protocol for routing decisions. When OSPF is fully deployed, the AD can be changed for one of the two protocols so that OSPF will not have the lower AD.
- Performing redistribution by moving the boundary routers in small steps: With migration by redistribution, in each step of the process a different part of the network will be converted from one routing protocol to another (EIGRP to OSPF in the example above).
To migrate between routing protocols in a large enterprise organization, the first approach (changing the AD) is often the best option. To achieve full connectivity using the second option (migration by redistribution), the boundary routers between the two parts of the networks will have to be bidirectionally redistributed between the two routing protocols. Then, filtering can be implemented using the tagging procedure mentioned previously. After this process, the boundary routers will “move” as more of the organization is migrated to the new routing protocol.
EIGRP is a unique protocol because it uses a hybrid approach, combining distance vector and link-state characteristics. Combining these features makes EIGRP very robust and allows for fast convergence, even in large topologies. The first thing a network designer should consider is that EIGRP is a Cisco proprietary protocol, so it can be used only in environments that contain Cisco devices. Like RIPv2, EIGRP is a classless protocol and it allows for VLSM. Another similarity between the two protocols is their automatic summarization behavior, but this can be disabled just as easily.
The algorithm that EIGRP uses is called the Diffusing Update Algorithm (DUAL). DUAL is the engine that makes EIGRP such a powerful protocol. DUAL operates based on a topology table that contains all of the possible prefixes and information about how to reach those prefixes. The topology table is used to identify a best prefix, called the successor, and puts this route into the routing table. After determining the best route in the topology table, EIGRP identifies second-best routes called feasible successors. Feasible successors are not installed in the routing table until the best route is lost. At that moment, the next best successor in the topology table is installed in the routing table almost immediately because there is no need for other computations. This is the reason EIGRP provides such fast convergence times.
EIGRP is the only IGRP that can perform unequal cost load balancing across different paths. This is accomplished using the “variance” command, which defines a tolerance multiplier that can be applied to the best metric and that will result in the maximum allowed metric.
Figure 7 – EIGRP Unequal Cost Load Balancing
Figure 7 above is an example in which there are two routes with a cumulative metric of 100 to a destination and a route with a cumulative metric of 200 to the same destination. By default, EIGRP performs only equal cost load balancing, so it will send traffic across only the first two links, which have the best metric of 100. If traffic was sent over a third link, the variance should be set to 2, meaning the maximum allowed metric is two times the lowest metric, equaling 200. Traffic will be sent proportionally to the metric, meaning for each packet sent over the third link, two packets are sent over the first two links because their metric is better.
EIGRP creates neighbor relationships with adjacent routes and exchanges information with them using Reliable Transport Protocol (RTP). This protocol ensures that neighbors can exchange information in a reliable manner.
Note: Do not confuse the EIGRP-specific RTP (Reliable Transport Protocol) with the Real-time Transport Protocol used in VoIP environments.
By default, EIGRP calculates route metrics based on bandwidth and delay but it can use other parameters in the calculation, including load and reliability. Enabling the metric calculation based on load and reliability is not recommended by Cisco because the network might become unstable.
EIGRP offers more flexibility than OSPF, which is more rigid and is much more governed by operational and technical considerations. A small- to medium-sized business with an arbitrary network architecture can use EIGRP without many problems because the network does not have to be restructured until scaling up to a larger topology. However, if the topology reaches the point where there are hundreds of routers, then EIGRP might become instable and present long convergence times.
When scaling EIGRP, the structured IP hierarchy should include good route summarization. The most important issue with EIGRP as it relates to stability and convergence is trying to lower the propagation of EIGRP queries, especially when trying to find a feasible successor. One of the key aspects of a scalable EIGRP design (especially in large deployments) is to ensure that there are feasible successors. This can be achieved through an efficient equal cost routing design. In addition, summarization points and filtered routes can also limit EIGRP query propagation and lower the convergence times.
Adjusting the delay timers and tuning using variance, unlike one might think, are suboptimal solutions when trying to achieve low convergence times because this will become almost impossible to perform as the network scales to hundreds of routers. Another suboptimal way many organizations have tried to achieve low convergence times is implementing multiple EIGRP ASs or process numbers. Scaling two or three EIGRP ASs to limit EIGRP queries has proven to be an inefficient solution.
Having multiple EIGRP systems would be justified in a limited number of scenarios, the most common of which are as follows:
- After a merger/acquisition, as a migration strategy.
- Having different groups administering different EIGRP ASs, which is a suboptimal option because this will induce a larger degree of complexity in the network infrastructure; however, it might be necessary to have different trust domains or administrative control boundaries.
- Having an organization with an extremely large network that uses multiple EIGRP ASs to divide the network. This will involve using summary routes at the AS boundaries to advertise blocks of prefixes in the large network.
The most efficient methods for limiting EIGRP queries and achieving a scalable EIGRP design are as follows:
- Using a solid summarization design
- Using distribution lists
- Using stubs
- Ensuring there are feasible successors
- Implementing equal cost routing
- Avoiding having many EIGRP routers
- Avoiding scaling by multiple EIGRP ASs, if possible
The OSPF protocol is one of the most complex routing protocols that can be deployed in modern networks. OSPF is an open-standard protocol, whereas EIGRP is not. OSPF is a classless routing protocol and this allows it to support VLSM. OSPF uses the Dijkstra SPF algorithm to select loop-free paths throughout the topology, while EIGRP uses DUAL. OSPF is designed to be very scalable because it is a hierarchical routing protocol, using the concept of “areas” to split the topology into smaller sections.
OSPF usually does not converge as fast as EIGRP but it does offer efficient updating and convergence, as it takes bandwidth into consideration when calculating route metrics (or costs). A higher bandwidth generates a lower cost and lower costs are preferred in OSPF. OSPF supports authentication, as does EIGRP and RIPv2, and it is very extensible, as are BGP and IS-IS, meaning the protocol can be modified in the future to handle other forms of traffic.
OSPF discovers neighbors and exchanges topology information with them, acting much like EIGRP. Based on the information collected and the link costs, OSPF calculates the shortest paths to each destination using the SPF algorithm. The formula for calculating the interface cost is reference bandwidth/link bandwidth. The default reference bandwidth is 100 Mbps but this can be modified, as can the link bandwidth using the “bandwidth” command.
Note: The reference bandwidth should be modified in networks that contain a combination of 100 Mbps and 1 Gbps links because, by default, all of these interfaces will be assigned the same OSPF cost.
Another aspect that adds to the design complexity of OSPF is that it can be configured to behave differently depending on the topology in which it is implemented. OSPF recognizes different network types and this will control issues such as:
- How updates are sent
- How many adjacencies are made between the OSPF speakers
- How the next hop is calculated
OSPF supports six network types:
- Point-to-multipoint non-broadcast
OSPF does a good job of automatically selecting the network type that is most appropriate for a given technology. For example, configuring OSPF in a broadcast-based Ethernet environment will default to the broadcast type; configuring OSPF on a Frame Relay physical interface will default to the non-broadcast type; and configuring OSPF on a point-to-point serial link will default to the point-to-point network type.
Two network types that are never automatically assigned are point-to-multipoint and point-to-multipoint non-broadcast. These are most appropriate for partial mesh (hub-and-spoke) environments and must be manually configured.
The network types can influence the underlying OSPF protocol in many ways. The broadcast type will be the default on broadcast media, and once OSPF is configured on a broadcast environment, the systems will elect a Designated Router (DR) and, optionally, a Backup Designated Router (BDR) on each segment. To communicate with the DRs, OSPF will multicast updates to 18.104.22.168, and to communicate to every OSPF router, packets are multicasted to 22.214.171.124.
In a broadcast network, the DR is the device that all of the other routers will form their adjacency with and this is a protection mechanism to prevent the network from being overwhelmed with a full mesh of adjacencies. In addition to minimizing adjacencies, the DR also helps minimize the amount of OSPF traffic between OSPF nodes because it establishes a full OSPF adjacency only with the DR. The BDR is a node that will take the place of a DR if it fails.
On a broadcast OSPF segment, if every node had to form adjacencies for the information exchange with all of its neighbors, the number of total neighbor relationships would be n*(n-1)/2, where “n” is the number of routers. Using a DR helps reduce the total number of adjacencies and makes the process more efficient because nodes do not need a full mesh of relationships.
OSPF Router Types
The OSPF hierarchy uses the concept of areas to improve the scalability of the protocol. Link-state protocols operate by flooding information about the status of their links, but when the network is divided into areas, only the routers in a specific area have to agree on the topology map. Setting up areas reduces the convergence domain size because this can hide topology details between areas. This leads to the protocol becoming much more efficient.
Area 0 (backbone) is the critical area in an OSPF environment, and every OSPF design must start from this area. It is also called the transit area because all areas must connect to it and traffic between areas must go through Area 0. Another feature of the backbone area is that it must be contiguous, meaning it cannot be broken into multiple parts. Once the backbone area is designed, other areas, called non-transit areas, can be included and they can be assigned any number. This is illustrated in Figure 8 below:
Figure 8 – OSPF Area Types and Router Roles
Network designers should also understand the different router roles that exist within OSPF:
- Backbone router: This is the terminology given to a router that has at least one link in Area 0.
- Internal router: This router has all links participating in one non-transit area.
- Area Border Router (ABR): The ABR is a router that is positioned between multiple areas. This means the router has at least one link to Area 0 and one link to a non-transit area. ABRs pass information between the backbone area and non-transit areas. They are also used to summarize information between the two areas, thus improving the efficiency and the scalability of the OSPF design.
- Autonomous System Boundary Router (ASBR): An ASBR has at least one link to the OSPF domain and at least one link outside of the OSPF domain touching another routing protocol (EIGRP, IS-IS, or BGP). ASBR is used to redistribute information to and from other routing domains and OSPF.
If the backbone area is split into multiple pieces, virtual links can ensure its continuity. A virtual link is an Area 0 tunnel that connects the dispersed backbone areas. Virtual links are not considered a best design practice but they can be useful in particular situations, like company mergers, as depicted in Figure 9 below:
Figure 9 – OSPF Virtual Link (Example 1)
A virtual link is configured between ABRs as a temporary fix to the problem (split Area 0). The virtual link tunnels the backbone area between the devices so the topology is repaired until a network redesign is implemented.
Another classic case in which virtual links might be used is the situation in which there is an OSPF area not connected to the backbone. Looking at Figure 10 below, Area 100 is connected to Area 0 but Area 200 is connected only to Area 100. This poses a design problem because it goes against the principle stating that every area must be connected to Area 0. The solution in this case would be to configure a virtual link between Area 0 and Area 200 so the backbone is extended to reach Area 200.
Figure 10 – OSPF Virtual Link (Example 2)
Note: In the scenario depicted in Figure 10, the virtual link is often considered an extension of the non-transit area (Area 200 in this case) to reach Area 0. This is not true because the virtual link is part of Area 0, so in fact Area 0 is extended to reach the non-transit area (Area 200 in this case).
Another important OSPF aspect is represented by the different Link-State Advertisement (LSA) types. Each LSA type has a unique format that is defined by the type of information it contains (either internal or external prefixes). The LSA types are as follows:
- Type 1 – Router LSA: Used by routers in an area to advertise a link to another router in the same area.
- Type 2 – Network LSA: Generated by the DR to send updates about the attached routers.
- Type 3 – Network Summary LSA: Generated by the ABR to advertise information from one area to another.
- Type 4 – ASBR Summary LSA: Generated by the ABR to send information about the location of the ASBR.
- Type 5 – External LSA: Used by the ASBR to advertise external prefixes to the OSPF domain.
- Type 6 – Multicast LSA: Not implemented by Cisco.
- Type 7 – NSSA External LSA: Used in not so stubby areas to advertise external prefixes.
- Types 8, 9, and 10 – Opaque LSA: Used for extensibility.
The LSA types allow for a hierarchical structure:
- LSAs that only flow within an area (intra-area routes): Types 1 and 2 (O)
- LSAs that flow between areas (inter-area routes): Types 3 and 4 (O, IA)
- External routes: Type 5 (E1/E2) or Type 7 (N1/N2)
OSPF Area Types
OSPF offers the capability to create different area types that relate to the various LSA types presented above and the way they flow inside a specific area. The different area types are as follows:
- Regular area: This is the normal OSPF area, with no restrictions in the LSA flow.
- Stub area: This area prevents the external Type 5 LSAs from entering the area. It also stops Type 4 LSAs, as they are used only in conjunction with Type 5 LSAs.
- Totally stubby area: This area prevents Type 5, Type 4, and Type 3 LSAs from entering the area. A default route is automatically injected to reach the internal destinations.
- Not so stubby area (NSSA): The NSSA blocks Type 4 and Type 5 LSAs but it can connect to other domains and an ASBR can be in this area. The NSSA does not receive external routes injected in other areas but it can inject external routes into the OSPF domain. The external routes will be injected as Type 7 LSAs. These Type 7 LSAs convert to Type 5 LSAs using the NSSA ABR (the router that connects to the backbone), and they reach other OSPF areas as Type 5 LSAs.
- Totally not so stubby area (totally NSSA): This area has the same characteristics as the NSSA, except that it also blocks Type 3 LSAs from entering the area.
Note: All routers in an OSPF area must agree on the stub flag.
The various areas and LSA types are summarized in Figure 11 below:
Figure 11 – OSPF Areas and LSA Types
All of these areas and LSA types make OSPF a very hierarchical and scalable routing protocol that can be tweaked and tuned for very large environments based on all of these design elements. OSPF allows for summarization, which can be carried out in two locations:
- Between areas (inter-area summarization), using Type 3 LSAs
- At the ASBR, summarizing external prefixes, using Type 5 and Type 7 LSAs
When analyzing scalability on a router, there are three resource areas that should be taken into consideration:
- Interface bandwidth
The routing protocol places demands on the underlying router, and there are four factors that lead to the workload calculations:
- The number of adjacent neighbors the router has (OSPF neighbors in this case). OSPF will flood all of the link-state modifications to all of the routers in an area. Typically, one router should have no more than 60 neighbors.
- The number of adjacent routers in an area. Typically, there should be no more than 50 routers in an OSPF area. In situations where a larger number of areas might be needed, the topology can be split into multiple areas.
- The number of areas supported by each router. Since every ABR is in at least two areas (the backbone and one adjacent area), for maximum stability, one router should not be in more than three areas. Following this guideline, an ABR should touch the backbone and a maximum of two other areas. This design recommendation depends on the total number of routers and on the number of routers in one area.
- Choosing the designated router. DRs and BDRs are the “busiest” routers in an OSPF topology because they establish full OSPF adjacencies with all other OSPF routers. Proper routers should be chosen to carry out these tasks, for example, routers that can manage high CPU and memory loads. Avoid choosing the same router to be the DR in multiple LANs at the same time.
In situations where there are many branches or remote routers, the workload should be split across several peers. For example, IPsec VPN peers running OSPF over GRE tunnels form a less stable environment than a non-VPN peer environment. Proper lab testing should be done before implementing the production network.
EIGRP is more flexible and tolerant to an ad-hoc network topology, but OSPF needs a well-defined hierarchy with a clear backbone and area topology. Routing information can be reduced by having a good area design.
OSPF designers should use techniques to minimize the number of advertisements going into and out of an area. Anything in the LSA database must be sent to all of the routers in an area, so anytime a modification needs to be propagated, the CPU, memory, and bandwidth parameters will be affected. Network designers should be conservative in adding routers to Area 0. If possible, this area should contain only the necessary backbone routers and the ABRs to connect other OSPF areas.
If the OSPF design cannot be simplified, every non-backbone area should be configured to be some type of stub area or totally stubby area. Solid summarization techniques should also be used to build a scalable OSPF design.
An important issue network designers often face is deciding whether ABRs should be Core Layer or Distribution Layer routers. This depends on the network topology in the organization. The general guidelines recommend placing different functional network areas into different OSPF areas.
Figure 12 – OSPF Network Design
Analyzing Figure 12 above, different logical areas are separated into dedicated OSPF areas. An OSPF area exists for the following:
- The data center or server arm
- The Enterprise Campus area
- The hub-and-spoke topology to the regional offices
OSPF ABRs provide the ability to support route summarization or to create stubby or totally stubby areas whenever possible. The effectiveness of route summarization will depend entirely on how good the addressing scheme and hierarchy is. Some guidelines regarding summarization in and out of areas include the following:
- Configure the addressing scheme so the range of subnets assigned within an area is contiguous.
- Develop an address space scheme that will be easy to partition as the network grows.
- Assign subnets according to simple octet boundaries, where possible.
- Always plan ahead for new routers and new areas.
- Ensure that new routers are placed properly as ABRs, backbone routers, or other types of routers.
Routes can be summarized and the LSA database size and flooding can be reduced in OSPF by using the “area range” command (internal summarization) and the “summary-address” command (external summarization), by implementing filtering, or by originating default routes into certain areas. Different type of routes can also be filtered in stub and totally stubby areas.
OSPF Hub-and-Spoke Design Considerations
The hub-and-spoke topology in Figure 13 below should be carefully designed, as specific considerations relate to this type of topology. Network designers should take into consideration the fact that any change performed on any of the spokes will be propagated to the hub and then replicated to all of the other spokes. This behavior can put a great deal of overhead on the hub router and this is called “change flooding.” To prevent this issue, use stub areas, totally stubby areas, or totally NSSAs.
Figure 13 – OSPF Hub-and-Spoke Router
In hub-and-spoke scenarios, the number of spokes and the area selection criteria should be carefully controlled. If there are a few remote sites (spokes), the hub and the spokes can be placed within the same area. However, if there are many remote sites, the spokes might need to be split into more areas, which would result in implementing a multi-area design. To summarize in and out of the remote areas, the hub must be an ABR. Another good practice is to design the OSPF network so that it has a small and very stable Area 0 because the backbone area is critical in an OSPF topology.
Note: The most simplified backbone area design involves grouping the ABRs only in Area 0.
If the spokes have low-speed links, the link speeds should be increased to improve the design. Not having enough bandwidth to flood LSAs when there are topology changes is a major issue.
OSPF has several choices for the type of networks to use. Cisco recommends avoiding the use of broadcast or Non-Broadcast Multi-Access (NBMA) network types and instead using one of the following types:
- A single interface on the hub treated as a point-to-multipoint network
- Individual point-to-point interfaces on the hub for each spoke and a point-to-point designation
OSPF Full-Mesh Design Considerations
Some organizations need to deploy their OSPF speaker or their peer into a full-mesh topology, like in Figure 5.14 below. The problem with flooding in an OSPF full-mesh topology is that it is extremely difficult and it is not scalable. A full-mesh topology implies a number of total connections equal to n*(n-1)/2, where “n” equals the number of nodes. If there are eight OSPF neighbors, then 28 links between all the nodes will be needed. Adding one more router to the OSPF full-mesh topology would increase the amount of links, from 28 to 36, which is not scalable. To deploy this implementation, an OSPF “mesh group” can be used. This is a manual method to reduce flooding and it works by selecting two routers (DRs) to handle the flooding process and filter out all of the other routers.
Figure 14 – OSPF Full-Mesh Topology
On broadcast, non-broadcast, and point-to-point networks, the “ip ospf database-filter all out” command in interface configuration mode can be issued on all of the routers that are not selected as DRs to manually prevent the flooding of OSPF LSAs. When using point-to-multipoint networks, the “neighbor <ip_address> database-filter all out” command in routing configuration mode can be used.
An additional feature called OSPF Flood Reduction can also be implemented if LSA flooding is creating too much overhead on the CPU or on bandwidth. This feature can be configured using the “ip ospf flood-reduction” command at the interface level. This feature eliminates the periodic refreshing of unmodified LSAs, which reduces the impact on router resources. An important thing to keep in mind is that OSPF flood reduction eliminates only the effect; it does not deal with the underlying issue of the unoptimized OSPF design. This command should be used in conjunction with some of the guidelines mentioned previously to fix the real OSPF issues that follow:
- Too many routers in an area or too many adjacencies
- An unstable OSPF design
- A heavy adjacency workload
- A large full-mesh topology that uses mesh groups, which does not always offer optimal results
OSPF Fast Convergence
One of the things that can be done to obtain fast convergence in OSPF includes using subsecond OSPF timers. This is implemented by setting the dead interval to one second and using a hello multiplier to designate how many hello packets will be sent in a one-second interval. Using fast hellos is recommended in small- to medium-sized networks but they should not be used in large networks. This can offer fast convergence but it is not a scalable solution.
Network designers should understand the SPF algorithm behavior in the OSPF environment to obtain fast convergence. This behavior depends on the number of nodes, links, and LSAs in the area. iSPF (Incremental SPF) can also be used, which uses a modified Dijkstra algorithm to compute the portion of the path tree that has been changed. Doing this instead of computing the entire tree will offer faster OSPF convergence and will reduce CPU overhead. iSPF has been available since IOS 12.3(2)T, and lab testing has shown that iSPF used on 10,000 nodes offered a 50 ms convergence time. iSPF is implemented using the “ispf” command under the OSPF process.
Another issue related to router convergence is how to detect a link failure. This is usually achieved using some type of keepalive mechanism or electrical signal that helps in detecting the loss of the link. A special technology used for this purpose is Bidirectional Forwarding Detection (BFD). BFD is a routing protocol technology that uses fast Layer 2 link hellos to notify an engineer of any failed links or one-way links. BFD is supported on multiple Cisco platforms, including 6500, 7600, 12000, and CRS routers. This is one method for configuring subsecond Layer 2 failure detection between adjacent network nodes. Routing protocols can also be configured to respond to BFD notifications and immediately begin the Layer 3 route convergence process.
Border Gateway Protocol is the only exterior gateway protocol in use today and its role is primarily to exchange routing information between organizations. BGP is a standard-based protocol defined in RFC 4271 and is the successor of EGP (Exterior Gateway Protocol).
Necessity of BGP
BGP is used to route between ASs and is considered to be a path vector routing protocol. Routing decisions are based on multiple attributes that can be tuned and controlled, resulting in the particular path the AS’s data will take (i.e., this is the routing decision). This is more of a policy based routing approach and policy routing is very important for ISPs routing traffic between each other for different ASs.
BGP is a classless routing protocol and it supports VLSM and summarization (route aggregation). While IGRPs can scale to thousands of routes, BGP can scale to hundreds of thousands of routes, making it the most scalable routing protocol ever developed. Currently, the global BGP routing table has over 300,000 routes.
Another characteristic of BGP is its high rate of stability, as there is never a solid convergence of the Internet routing table (i.e., something is always changing in such a large routing table). In addition, it is stable enough to handle routing and decision making at the same time. Because BGP focuses on the enforcement of policies, it does not use a simple metric value that might be tied to a single parameter (like bandwidth). Instead, BGP has a group of attributes that can be manipulated to dictate a particular routing policy.
When used to exchange routing information between organizations, BGP can be configured in two particular scenarios (see Figure 15 below):
- Transit networks: ISPs that want to provide transit to other destinations on the public Internet.
- Multi-homed networks: Big Enterprise Networks that rely heavily on Internet traffic and have sophisticated connectivity requirements to two or more ISPs. BGP allows them to control inbound and outbound routing policies.
Figure 15 – BGP Deployment Scenarios
Most of the Enterprise Networks do not need BGP and this is for various reasons:
- The network requires single ISP connectivity and default routing configuration is sufficient. A default route will point to the ISP so all Internet traffic is routed to that single ISP.
- Memory and CPU resources are limited and do not support a BGP implementation. The global routing table needs more than 1 GB of memory just for storage.
- Not owning the IPv4 address space in use. This happens in situations where the organization’s addresses are owned by the ISP, which is a frequent occurrence for small- and medium-sized organizations.
Similar to OSPF, IS-IS, and EIGRP, BGP uses a three-table data structure:
- Neighbor table: Contains information about adjacency with peers.
- BGP table (topology table): Contains all of the prefixes learned from peers.
- IP routing table: Contains the best routes from the BGP tables.
The devices running BGP will establish adjacencies to build the neighbor table and will then exchange updates to build the BGP table. After the BGP table is built, the best paths for routing information are chosen and are used to build the IP routing table. BGP allows for different peering types to be created:
- External BGP (eBGP) peering: BGP peering with a neighbor that is outside of the AS.
- Internal BGP (iBGP) peering: BGP peering with devices inside the AS.
Figure 16 – BGP Peering Types
Figure 16 above shows an example of BGP peering types. The BGP peering types a route is being sent to and received from will influence the update and path selection rules. An example of this is that eBGP peers are assumed to be directly connected. If they are not, a special command called “ebgp multihop” must be entered to let the devices know they are not directly connected and to establish the BGP peering. This assumption has no equivalent when considering iBGP peering, where there is no requirement for direct connectivity.
Another example regarding the iBGP versus eBGP behavior is that an eBGP-learned route will not be advertised between iBGP peers because of a special loop prevention mechanism that prevents an update learned via iBGP to be sent to other iBGP peers. This happens because BGP assumes that all routers within an AS have complete information about each other. Multiple solutions exist to solve this issue, including the following:
- Configure a full mesh of iBGP peers
- Use BGP Route Reflectors
- Organize the AS into BGP Confederations
The solution that involves a full mesh of iBGP peers is the least preferred because of the increased number of connections. The total number of connections is n*(n-1)/2, where “n” equals the number of BGP routers, so for 1,000 routers there would be 499,500 peers. This is very hard to implement and maintain, so the Route Reflector and Confederations solutions are recommended instead. Details about BGP Route Reflectors and BGP Confederations will be covered later in this chapter.
BGP Path Vector Attributes
BGP can use multiple attributes to define a routing policy and the most important are as follows:
- Next hop: This attribute must be present in each BGP update; it indicates where the traffic should be sent to reach a particular destination.
- AS-path: This attribute lists all of the Autonomous Systems through which the prefix has passed. AS-path is similar to a hop count, except it uses AS numbers and provides more details about the path.
- Origin: This attribute provides information about how the prefix entered the BGP system, either directly advertised into BGP with the “network” command or redistributed from other routing protocols.
- Local preference: This attribute influences the way traffic enters the AS and the path that it takes; it can also influence the way packets exit the AS and the path that they take.
- Community: This attribute groups destinations in a certain community and applies routing decisions according to those communities.
- Multi-Exist Discriminator (MED): This attribute influences the way traffic enters the AS and the path that it takes.
- Atomic aggregate: This attribute is used when performing BGP summarization.
- Aggregator: This attribute is used when performing BGP summarization.
BGP attributes can be grouped into several categories, such as well-known and optional. The well-known attributes are supported by all BGP vendors and the optional attributes are supported only by certain BGP vendors. BGP attributes can also be mandatory and discretionary. The mandatory attributes are sent in every routing update, while the discretionary attributes may or may not be present in routing updates. Another category relies on the path attribute’s transitivity, which can be either transitive (they pass between eBGP and iBGP neighbors) or non-transitive (they pass between iBGP neighbors only). Valid combinations of BGP attributes include the following:
- Well-known mandatory (next-hop, AS-path, origin)
- Well-known discretionary (local preference, atomic aggregate)
- Optional transitive (aggregator, community)
- Optional non-transitive (MED)
BGP systems will analyze all of these attributes and will determine the best path to get to a destination based on this very complex decision process. Only the best route is sent to the routing table and to the peers. Finding out whether the next hop is reachable must be determined first. If it is not, the prefixes will not have a best path available, but if it is, the decision process will analyze the following aspects:
- Weight (Cisco-specific attribute) – the highest weight is preferred.
- Local preference – the highest local preference is preferred.
- Locally originated routes – these are preferred.
- AS-path – the shortest AS-path is preferred.
- Origin – routes with the lowest origin type are preferred.
- MED – the lowest MED is preferred.
- Neighbor type – routes that came via eBGP over those that were learned via iBGP are preferred.
- IGP metric – if there is still a tie, the lowest IGP metric wins.
- If multiple paths exist in the routing table, the path that was received first is preferred.
- The route that comes from the BGP router with the lowest router ID is preferred.
- The path with the minimum cluster list length is preferred.
- The path that comes from the lowest neighbor address is preferred.
BGP typically has multi-homed links to ISPs and is found in MPLS VPN scenarios. When using BGP as an interior routing protocol, a full mesh of iBGP routers is necessary because they do not re-advertise routes that were learned from other iBGP peers, according to BGP behavior. Two methods for scaling iBGP and avoiding the need for a full-mesh topology are using Route Reflectors and Confederations.
BGP Route Reflectors
Route Reflectors (RRs) are nodes that reflect the iBGP updates to devices that are configured as RR clients. This solution is easy to design and implement and solves the iBGP split horizon rule. A full-mesh connection between RR nodes and normal nodes (non-RR clients) must be configured, but a full-mesh connection between the RR and its clients is not required. This concept is illustrated in Figure 17 below:
Figure 17 – BGP Route Reflectors
BGP RRs, defined in RF 2796, are iBGP speakers that reflect routes that were learned from iBGP peers to RR clients. They also reflect routes received from RR clients to other iBGP peers (non-RR clients). Route reflector client configuration is carried out only on the RR device, using the “neighbor <ip_address> route-reflector-client” command. This configuration process can be performed incrementally as more RRs or RR clients are added. The RR client will often establish peer sessions only with RR devices.
Figure 18 – BGP Route Reflector Redundancy
Often, redundant RRs are needed to avoid a single point of failure. An RR and its associated clients form an RR cluster, as depicted in Figure 18 above. In some situations there can be overlap in the RR clusters but this adds to the complexity of the design. RR functionality respects the following rules when propagating updates:
- When an RR receives a route from an eBGP peer, it sends the route to all clients and non-clients.
- When an RR receives a route from an RR client, it reflects the route to all RR clients and non-clients, as well as to all eBGP peers.
- When an RR receives a route from a non-client, it reflects the route to all RR clients and sends the route to all eBGP peers.
The second BGP scalability method is using BGP Confederations, as defined in RFC 3065. This implies injecting information into BGP routes using the AS-path attribute to prevent loops in the AS. This technique works by dividing a normal BGP AS into multiple sub-ASs. The only AS visible to the outside world is the outer AS (the Confederation AS). The BGP Confederation design is equivalent to having a VLAN and dividing it into private VLANs.
BGP Confederations are more complex than Route Reflectors and they function by creating sub-ASs within the main AS. The connections between sub-ASs behave like eBGP peer sessions and the connections inside sub-ASs are pure iBGP peer sessions. This means that only full-mesh configuration is needed inside the sub-ASs, where RRs can also be configured, so a combination of BGP design technologies is available.
Figure 19 – BGP Confederations
Analyzing Figure 19 above, the Confederation AS 100 has been configured, and within this confederation AS, three sub-ASs (Confederation internal peers) have been configured: 65001, 65002, and 65003. The connections between the devices in the same sub-AS are BGP Confederation internal peers and the connections between the devices in different sub-AS areas are BGP Confederation external peers, and they have many similarities to eBGP connections.
As iBGP information is exchanged within a Confederation AS, the sub-AS numbers are put into the Confederation sequence, which functions similar to the AS-path attribute as a loop prevention mechanism. The route advertisement rules are similar to the RR distribution rules:
- A route that is learned from an eBGP peer is advertised to all the Confederation external and internal peers.
- A route that is learned from a Confederation internal peer is advertised to all Confederation external and eBGP peers.
- A route that is learned from a Confederation external peer is advertised to all Confederation internal and eBGP peers.
Private AS numbers are used within a Confederation AS and are then removed from updates sent out of the Confederation. This makes BGP more scalable and allows the number of connections to be reduced.
Note: AS numbers are defined as 16-bit integers, so they range from 0 to 65535. Sub-ASs are usually assigned private AS numbers, ranging from 64512 to 65535. Because of the exhaustion of public AS numbers, IANA introduced 32-bit AS numbers and began allocating them over the last few years.
Cisco routers do not route IPv6 by default and this capability should be activated with the “ipv6 unicast-routing” command. Cisco routers are dual-stack capable by default, meaning they are capable of running IPv4 and IPv6 simultaneously on the same interfaces.
IPv6 allows the use of static routing and it supports specific dynamic routing protocols that are variations of the IPv4 routing protocols modified or redesigned to support IPv6, such as the following:
- RIPng (RIP new generation)
Note: IS-IS and BGP underwent the least amount of modifications to support IPv6 because they were built with extensibility in mind.
RIPng, OSPFv3, and EIGRPv6 are new routing protocols that work independently of the IPv4 versions and they run in a completely separate process on the device. BGP and IS-IS are exceptions to this rule, as they route IPv6 traffic using the same process used for IPv4 traffic, but they use the concept of address families that hold the entire IPv6 configuration.
Many of the issues with IPv4 (e.g., name resolution and NBMA environments) still exist with IPv6 routing. An important aspect is that IPv6 routing protocols communicate with the remote link-local addresses when establishing their adjacencies and exchanging routing information. In the routing table of an IPv6 router, the next hops are the link-local addresses of the neighbors.
As mentioned, static routing is one of the options that can be used in IPv6 and it has the same implications as in IPv4. The route can point to:
- The next hop (the next hop must be resolved)
- A multipoint interface (the final destination must be resolved)
- A point-to-point interface (no resolution is required)
RIPng, also called RIP for IPv6, was specified in RFC 2080 and is similar in operation to RIPv1 and RIPv2. While RIPv2 uses the multicast address 126.96.36.199 to exchange routing information with its neighbors, RIPng uses the similar FF02::9 address and UDP port 521. Another difference between the two versions is that IPv6 is configured at the interface level while RIPv1 and RIPv2 are configured at the global routing configuration level.
OSPFv3 is defined in RFC 2740 and is similar in operation to OSPFv2 (for IPv4). OSPFv3 even supports the same network types as OSPFv2:
- Point-to-multipoint non-broadcast
EIGRPv6 is similar in operation to EIGRP for IPv4 and uses IP protocol 88 to multicast updates to FF02::A.
Note: An important aspect to consider when implementing EIGRPv6 is that, unlike EIGRP for IPv4, the process is shut down until it is manually enabled by issuing the “no shutdown” command under the routing process.
BGP for IPv6 is configured in the address family configuration mode but it is based on the same configuration principles used by BGP for IPv4:
- An underlying transport IGP is required.
- There is an implicit iBGP loop prevention mechanism that prevents iBGP-learned routes from being advertised to other iBGP neighbors (this can be solved by using Route Reflectors or Confederations).
- There is an implicit eBGP loop prevention mechanism that does not accept routes entering an AS that has the same AS in the path.
- It uses the same best-path selection process.
When designing enterprise routing, network architects should first figure out whether they should use static or dynamic routing. Static routing implies manually defining routes on devices and dynamic routing implies using a dedicated routing protocol that will build the routing table. The dynamic routing protocols most often used in modern networks are EIGRP, OSPF, and BGP.
Large networks, including the Internet, are based on the Autonomous System (AS) concept. An AS defines a group of network devices under a common administration and most often this defines a large organization or an ISP. Routing protocols can be classified based on different criteria. Depending on the zone in which they operate, they can be interior (inter-AS) routing protocols or exterior (intra-AS) routing protocols.
Interior routing protocols can be further classified as distance vector routing protocols or link-state routing protocols, based on their behavior regarding the router update exchange process. Distance vector routing protocols include RIP, IGRP, and RIPng. Link-state routing protocols include OSPF, IS-IS, and OSPFv3.
The main difference between distance vector routing protocols and link-state routing protocols is the way they exchange routing updates. Distance vector routing protocols function using the “routing by rumor” technique, as every router relies on its neighbors to maintain correct routing information. This means the entire routing table is sent periodically to the neighbors.
Link-state routing protocols do not generally “route by rumor” like distance vector routing protocols do. The routing devices exchange information between them about their link-states. Devices build a map of the network independently and loop-free based on the link-state information each router generates and propagates to the other routers.
Link-state routing protocols offer a series of important advantages compared to distance vector routing protocols. The most important advantage relates to the convergence factor. Link-state routing protocols converge must faster because as soon as a network topology changes, only that specific information is sent to the routers in a given area.
Exterior routing protocols run between ASs (inter-AS) and the most common example is BGPv4. The main reason different types of routing protocols are used to carry routes outside of the AS boundaries is the need to exchange a large amount of route entries.
Routers use Administrative Distance (AD) to select the best route when multiple routing protocols advertise the same prefix. The AD value represents how trustworthy a particular routing protocol is.
Route summarization helps make the routing design more scalable, regardless of the routing protocol used (e.g., RIPv2, EIGRP, or OSPF). It also helps place network addresses into usable blocks (listed below), which can be used for multiple purposes:
- NAT blocks
- Blocks used in redistribution
- Blocks for management VLANs
- Blocks for content services
A special form of route summarization can be implemented in the form of default routing. Every modern network usually uses some type of default routing. The best practice is to dynamically advertise the default route 0.0.0.0/0 out of the Enterprise Network to the ISPs, as opposed to performing a static route configuration on every router in the organization.
Route filtering allows the control of network traffic flow and prevents unwanted transit traffic, especially in situations that feature redundancy or multiple paths. Route filtering protects against erroneous routing updates and there are several techniques that can be used in this regard. For example, with OSPF, if Core Layer connectivity is lost, traffic should not be rerouted through a remote site.
There are two ways to migrate between routing protocols:
- Using AD
- Performing redistribution by moving the boundary routers in small steps
Enhanced Interior Gateway Routing Protocol (EIGRP) is a unique protocol in that it uses a hybrid approach, combining distance vector and link-state characteristics. Combining these features makes EIGRP very robust and allows for fast convergence, even in large topologies. EIGRP functions by using DUAL and it is the only IGRP that can perform unequal cost load balancing.
When analyzing scalability on a router, there are three resource areas that should be taken into consideration: memory, CPU, and interface bandwidth.
The most efficient methods for limiting EIGRP queries and achieving a scalable EIGRP design are as follows:
- Using a solid summarization design
- Using distribute lists
- Using stub areas
- Ensuring there are feasible successors
- Implementing equal cost routing
- Avoiding scaling by multiple EIGRP ASs, if possible
Open Shortest Path First (OSPF) protocol is one of the most complex routing protocols that can be deployed in modern networks. OSPF is an open-standard protocol, while EIGRP is not. OSPF functions by using the Dijkstra SPF algorithm and by exchanging Link-State Advertisements (LSAs) between neighbors. LSA types are as follows:
- Type 1 – Router LSA
- Type 2 – Network LSA
- Type 3 – Network Summary LSA
- Type 4 – ASBR Summary LSA
- Type 5 – External LSA
- Type 6 – Multicast LSA
- Type 7 – NSSA External LSA
- Types 8, 9, and 10 – Opaque LSA
OSPF offers the capability to create different area types that relate to the various LSA types presented above and the way they flow inside a specific area. The different area types are as follows:
- Regular area
- Stub area
- Totally stubby area
- Not so stubby area (NSSA)
- Totally not so stubby area (totally NSSA)
The major points that should be taken into consideration when designing a scalable OSPF design are:
- The number of adjacent neighbors the router has (OSPF neighbors in this case)
- The number of adjacent routers in an area
- The number of areas supported by each router
- Choosing the designated router
BGP is a highly scalable path vector routing protocol. Its metric is based on multiple attributes that can be tuned and controlled to decide which path the AS’s data will take.
BGP can be used in transit networks (ISPs that want to provide transit to other destinations on the public Internet) or in multi-homed networks (big organizations that connect to multiple ISPs).
When using BGP as an interior routing protocol, a full mesh of iBGP routers is necessary because they do not re-advertise routes that were learned from other iBGP peers, according to BGP protocol behavior.
Two methods for scaling iBGP and avoiding the need for a full-mesh topology are as follows:
- Route Reflectors
IPv6 allows the use of static routing and also supports specific dynamic routing protocols that are variations of the IPv4 routing protocols modified or redesigned to support IPv6: