Communications within networks heavily depend on dynamic routing protocols, their features, and the benefits they bring to enterprises.
The routing updates they exchange carry essential information that routers need to make proper routing decisions when exchanging data traffic.
However, at the same time, routing updates compete with user data for bandwidth and router resources.
Uncontrolled routing behavior may lead to wasted bandwidth on router interfaces, suboptimal routing, or extreme resource consumption.
That can have a material impact on your business. One 2013 analysis even estimated that the average employee wastes one week per year waiting on networks to respond.
While networks have undoubtedly improved since then, the point remains: any potential slowdown costs your business valuable time. To ensure that your network operates efficiently and the routing traffic is in harmony with the management and data traffic, you need to optimize routing updates.
You can implement several mechanisms on your routers to control and tune the updates exchanged by dynamic routing protocols. Although no one type of route filter is appropriate for each situation, distribute lists, and prefix lists, with their simplicity and flexibility, are among the most commonly used filtering methods.
This article will provide the following:
Not the guide you were looking for today? View some of our popular articles:
A properly deployed network is always the goal of network engineers. However, a wrong design and incorrectly configured route filters can decrease network performance in many ways.
As long as CPU resources of Layer 3 devices are at maximum levels, your network will most likely experience congestion, delays, dropped packets, or even downtime.
One of the reasons for CPU utilization spikes is the usage of unoptimized dynamic routing. When routers, firewalls, or Layer 3 switches receive a large number of routing updates, they must be processed, leading to decreased network performance.
Some routing factors that influence CPU utilization are:
All routing factors should be considered and properly approached to improve network performance significantly.
It is common knowledge that running multiple routing protocols in a single autonomous system could lead to many performance issues. A general recommendation is to run only one routing protocol in a network.
Because each routing protocol operates uniquely, they are incompatible and cannot exchange routing data. Therefore, if you run two routing protocols, such as OSPF and EIGRP in different subnetted networks, none will learn about the other subnet, leading to limited communications within the network.
At the same time, running multiple routing protocols in a single network provides the same results as running a single protocol but with extra resource consumption.
The reason is straightforward and called administrative distance (AD). This parameter defines the trustworthiness of the routing protocols, and routers always use the routing updates from the protocols with the lowest AD.
For example, if you use EIGRP, OSPF, and RIP in your network, the routers will include only the routes learned from EIGRP in the routing table because of the AD of 90 that EIGRP has, compared to the AD values of 110 and 120 used by OSPF and RIP, respectively.
Therefore, running OSPF and RIP alongside EIGRP provides no benefits at all. It just causes extra resource consumption on the devices.
__________________
PivIT offers a unique and wide selection of hardware and financing options. We also offer OEM options that give you the flexibility you need to develop your network.
__________________
Exchanging routing updates in a controlled way can significantly improve network performance. One of the best ways to achieve that is by filtering the routing updates.
Implementing route filters allows you to control route advertisements in the routing updates and prevent updates from being sent or received on specific interfaces. However, it is essential to ensure that the route filters are appropriately configured and applied to the routing devices.
There are several methods to control routing updates. First, you can limit the number of routing protocols in your network, but sometimes you must use more than one routing protocol.
Additionally, you can use passive interfaces on the routers, which prevents routing updates from being advertised or received on an interface. However, it applies to all routing updates, which you may not always want because you want to permit or deny only specific ones.
Using features such as distribute lists and prefix lists allows you to control routing updates in a more controlled and productive way. You can easily block advertisements on only certain specific routes and prevent loops when having two-way redistribution between multiple routing protocols in the network.
A distribute list is a special route filter that brings the best out of the Access Control Lists (ACLs) when filtering routing updates. In other words, a distribute list cannot filter out routing advertisements but references an ACL to do that.
So, why not use the ACLs directly to filter out routing updates but deploy them as part of distribute lists?
Well, there are several reasons.
One of those reasons is that ACLs are typically applied on device interfaces to control IP traffic. The problem with this approach is that routers and other Layer 3 devices may have many interfaces, which could heavily complicate the configuration process and possibly generate undesired outcomes.
In addition, routing updates, besides being received on the device interfaces, can also be obtained through route redistribution, a common routing method in larger enterprise networks where multiple routing protocols simultaneously run. The problem is that this approach does not involve the interfaces, so ACLs cannot filter out routing updates.
Another routing update-related issue with ACLs is that they cannot filter out traffic locally generated by the router. As a result, applying an ACL on an interface would not affect the routing updates sent over a specific interface. That is why distribute lists are needed.
By referencing ACLs, they provide “special powers” that allow them to control routing updates, regardless of the sources.
Using distribute lists provides network engineers with great flexibility in defining which routes the routers should advertise or receive. The configuration of distribute lists is straightforward and does not include any parameters or arguments.
All you have to do is to define a distribute list in the routing protocol configuration mode of the router by using the “distribute-list” command and link an ACL to it.
Because of this approach, you must create an ACL and specify which routes (networks) should be allowed and denied in the routing updates.
Once configured, a distribute list can be applied to inbound or outbound updates. Besides filtering routing updates of the same protocol exchanged on the interfaces, distribute lists allow you to filter routes redistributed from other routing protocols and sources.
Based on your network requirements, you can use the “in” argument to filter incoming routing updates received on an interface and the “out” argument to filter outgoing routing updates exiting an interface or being redistributed into another routing protocol.
As you can see in the image above, the subnets in the 10.0.0.0/8 network behind router R1 are advertised through the EIGRP protocol to R2, but not to R3. The reason for that is a distribute list on R2 that filters out the routing updates sent to R3 that contain information about the 10.0.0.0/8 network in general.
Now, let’s go step by step and take a look at the commands that you need to configure on R2 so that R3 never learns about the subnets behind R1:
The ACL named “DENY_10.0.0.0_NETWORK” permits only the 172.16.1.0 network (used between R2 and R3) and denies everything else, including the subnets, because of the implicit deny statement and the end of the ACL.
The “network” commands enable the EIGRP protocol on both interfaces, Fa0/0, and Fa0/1, so that R2 can exchange routing updates with its neighbors.
The “distribute-list” command references the “DENY_10.0.0.0_NETWORK” ACL and applies it in the outbound direction on the Fa0/1 interface connecting to R3.
As a result, the EIGRP routing updates containing information about the subnets behind R1 are filtered out, and R3 does not learn about them. The only network that R3 learns about from EIGRP is the 172.16.1.0/24 network.
You can think of a prefix list as a replacement for ACLs' filtering method in combination with distribute lists.
Distribute lists can fulfill the filtering requirements in most cases, but sometimes the process is limited because of ACLs' drawbacks.
Initially, the intention for ACLs was for data filtering, not route filtering. Therefore, ACLs cannot be used directly for filtering specific networks in the routing updates and must be referenced by distribute lists.
When applied, the ACLs are also evaluated sequentially for each IP prefix included in the routing table, and it is not that rare to experience difficulties matching subnet masks in some unique use cases.
Last but not least, extended ACLs can be difficult to configure sometimes and extremely complex and unmanageable when they consist of hundreds or even thousands of entries.
In contrast to ACLs, the prefix lists are intended purely for route filtering. Because of that, they provide better overall performance than the ACLs when filtering routes, and their user-friendly approach allows you to configure them easily.
However, the key feature of prefix lists is their reliance on the filtering method that is used. It allows matching routes based not only on a strict combination of IP address and subnet mask but on parts of address space with a subnet mask that can be longer or shorter than a defined number.
Prefix lists are similar to ACLs in several ways. Just like the ACLs, prefix lists can consist of one or more entries the router interprets in the specified order. Although the configured entry is always added as last in the list of entries in the prefix list because of the highest sequence number assigned by default, you can always explicitly insert an entry between existing ones by manually defining a sequence number.
The “ip prefix-list” command allows you to configure prefix list entries and define the permit or deny actions for matching specific networks in the routing updates. When there is a match, the defined action is applied, otherwise, the packet is denied because of the implicit deny rule.
Because the matching uses prefixes, the router compares the defined number of bits in the prefix with the same number of bits in the network included in the routing update.
When there is a match, it checks the number of bits defined in the subnet mask that should also match the length defined for the prefix. The route is considered a match when the prefix and the length match.
A simple example of a prefix list would look like this:
The prefix list name is “EXAMPLE”, where the prefix is 10.0.0.0, and the length is 16. This prefix list permits 10.0.X.X routes but denies everything else, such as networks like 10.1.0.0, 10.10.0.0, etc.
Besides exact matching, you can also filter within a range by using the following arguments:
These arguments provide a more flexible configuration approach that you can gain using only the network/length combination.
A simple example of a prefix list with “ge” and “le” arguments would look like this:
In this example, the network 192.168.1.0/20 is matched, because the prefix and the prefix length belong within the specified address range and the prefix length values in the prefix list entries. On the other hand, network 192.168.1.0/24 is not matched, because the prefix length (24) is higher than the maximum allowed (22) in the first entry.
The biggest benefit of using prefix lists is their flexibility in very complex networks, where advanced and tricky requirements can be more easily implemented compared to ACLs' standard and manual methods.
As you can see in the image above, we are supposed to achieve the same filtering results as before, but now by using a prefix list instead of a distribute list. The commands that you need to configure on R2 look like the following:
The prefix list named “DENY_10.0.0.0_NETWORK” permits exactly the 172.16.1.0 network and denies everything else including the subnets, because of the implicit deny statement.
Same as the ACL in the previous example, the prefix list must be applied under the EIGRP process through the distribute list command.
A network without any routing optimization can sometimes make a network engineer’s life very difficult. As much as the routing protocols help the communications within the network, they can be very harsh on the router CPU resources when not properly handled.
Therefore, by using distribute lists and prefix lists in combination with ACLs, you can control and tune the exchanges of routing updates and improve network performance.
Doing so can lead to more efficiency and a well-run network — something crucial in business today.
If you need a helping hand to configure your network, consider PivIT's EXTEND SmartHands offering to gain access to engineers around the globe to locally access your infrastructure without ever leaving your desk. But don't take our word for it, here's what one of our clients had to say:
"Great response time by the PivIT team, they came through in a pinch and we really appreciate it." - Jarrod S. (Director of Infrastructure)