The Ten Commandments: #1 Route Filtering

This is something I want to touch on as it’s a very important subject in my eyes.

Our jobs as network engineers and administrators is to provide seamless communications to clients and servers alike, an often overlooked component of which is (in my opinion) route filtering.

For those who aren’t aware, route filtering is the process of filtering routes, either inbound or outbound, based on a certain criteria. The following is a basic list of criteria we can filter based off of, but is not a complete list (when using BGP you have a ton of different options using route-maps and Path Attributes, that’s something I’ll leave for another post).

  1. The prefix itself (the network we don’t want to be routed)
  2. The source of the routing update
  3. Route Tags (this is a little more advanced, but each routing protocol allows for you to tag updates with a route-tag to give the administrator more granularity)

Now that we know what criteria we can filter off of, we’re going to discuss the methods which we could use

  1. Prefix-Lists, prefix lists are similar to ACLs, they permit (or deny) a network based off of it’s CIDR notation. Prefix-Lists can be used independently, but are most often paired with route-maps.
  2. ACLs, ACLs are simple. We have two options here, if we want to filter based off of the source of these routes, we can do an extended ACL, but if we just want to filter the route which we don’t want to be installed in our routing table, we can simply use a standard ACL.
  3. Route-Maps; this is where we can match off of specific Path Attributes, metrics, and manipulate the routes that are coming in (or going out). Route maps are used for a variety of different things, notably policy based routing, which is a topic I’ll cover in the future.

EIGRP Reaction

EIGRP will act very predictably with route filtering. When the router receives an update, it processes it to make sure that it is allowed to be entered into the EIGRP topology table, if it is not, that network is ignored an not installed in the topology table. We should all understand how routing protocols work in the sense that each routing protocol will use it’s methods to determine the best path, and then forward this to the best-path decision matrix within the router (there’s a specific name for this, but I can’t remember it). It forwards the candidate that it wants the router to consider installing into the routing table. Due to the fact that the network was never entered into the EIGRP topology table, EIGRP never performed metric calculations and will never send this route as a candidate to be installed in the routing table.

OSPF Reaction

As we all know, all routers within an OSPF area must have a matching link-state database, because of this, OSPF reacts a little differently. When you route filter in OSPF, it does not suppress the LSAs (link-state advertisements). I’ll put a post up in the future about dumbing down the LSA types within OSPF. Simply put, if you are attempting to filter a network in OSPF,  you will see the respective LSA in the LSD, however, OSPF will not provide the route with a candidate to install into the routing table. I’m not the best with OSPF so I’m going to stop before I say something terribly wrong. Here’s a good link from INE on the details of OSPF route filtering.

http://blog.ine.com/2009/08/17/ospf-route-filtering-demystified/

BGP Reaction

BGP filtering is pretty simply, when the router receives an update from a peer, it runs it against any route filtering which has been instated. If a network is not to be accepted, it simply does not transfer the route into the BGP database. There is something important to know here, BGP will not filter updates until you have manually reset the peer. This can be an issue when you have multiple peers or don’t want to lose complete connectivity for a short period of time. The solution to this is the soft-reconfiguration inbound command on your peer statement. This essentially create a segregated BGP cache in memory for that specific peer, in which it would be able to filter after doing a soft reset on the peer (it would not remove any of the routes from the RIB, routes will be in place until BGP finishes it’s calculations and sends the updated route information to the BGP database).

Why Filter?

  1.  Security – we don’t want networks which we aren’t aware about to be able to traverse our network.
  2. Compliance – more specific to BGP and ISPs, but we definitely can’t route for networks we don’t actually own.
  3. Availability/Path Control – filtering updates is important to availability, because we can prevent a route learned from an unintended location from hijacking a legitimate route sourced from some other location on our network (happens a lot with EIGRP and tunnels….BANDWIDTH)

Prefix Lists

Prefix Lists are extremely similar to an ACL. When filtering with prefix-lists alone (not paired with a route-map), you will only be able to filter the actual network which you either want to permit or deny. Prefix Lists use the CIDR notation of the network and can match based off of how many bits of the subnet you want to match up to (le or ge ). If you do not specify the minimum/maximum length to match, the prefix list will only match the specific prefix which you have defined.

What the keywords mean:

le – minimum prefix length to be matched

ge – maximum prefix length to be matched

Similar to an ACL, prefix-lists use sequence numbers and permit or deny statements, here is how you would configure a prefix-list:
Router(config)#ip prefix-list [name] seq [#] [permit | deny] [network/length] [le | ge #]

The below would match any network from 192.168.1.0-192.168.1.255
ip prefix-list PL-EXAMPLE seq 5 deny 192.168.1.0/24 ge 32
The below would the default route, exactly, and nothing else
ip prefix-list PL-DR seq 5 permit 0.0.0.0/0

To view configured prefix-lists, utilize the command
Router#show ip prefix-list

Standard ACLs

Filtering using standard ACLs is very simple. If you wanted to deny a route update, you’d simply configure an ACL denying the network. Standard ACLs will only filter based off of the destination included in the update (the network we are receiving an update for).
Router(config)#access-list [#] [seq#] [permit | deny] network wildcard-mask
To view configured ACLs:
Router#show ip access-list

Extended ACLS

This ones pretty useful, using extended ACLs we can filter based off of the source of the routing updates, as well as the network we which to filter. When you think about the structure of the extend access-list, think of the source field as who we are going to filter addresses from, and the destination as the specific networks we are going to filter.
Confused? Don’t be, it’s pretty simple. Here’s what the syntax should look like
Router(config)#ip access-list extended [name] [permit | deny] ip [peer] [mask] [net] [mask]
The following would deny updates from the peer 192.168.1.10 with a network of 10.0.0.0/8
ip access-list extended 101 deny host 192.168.1.10 10.0.0.0 0.255.255.255

Route-Maps

Route-maps are awesome! Okay, going to curb my enthusiasm here, but their ability to provide a network administrator with complete control is unmatched. Route maps allow you to do everything from manipulating route metrics and route selection, all the way up to (and not limited to) importing and exporting routes between VRFs.

Route maps work off of match and set commands, think of it as a program or script where match is your if statement, and set is the action which would included within that code block.

I won’t go to far into these, I’m trying to keep this a relatively quick post.

The basic syntax for a route-map would be like:
Router(config)#route-map [name] [permit | deny]
Router(config-route-map)#match ip address [prefix-list | acl]


To view configured route-maps
Router#show route-map

Applying them to EIGRP

I’m going to keep this simple and only provide instruction for applying these to EIGRP, I’ll link you to the guides for OSPF and BGP. EIGRP supports filtering via ACLs, Prefix-Lists and Route-Maps.

In every network I’ve been a part of administering, I’ve made it a point that we need to define every back-end network that is going to connect to us, and white-list them from the start. Another use-case  is denying these networks from being routed to the WAN, when they have yet to be scanned by our beloved IA (I know, it’s cyber security now…), but still allowing them access to LAN resources and ability to add machines to workstations, verify CLO and pull updates from our WSUS server.

First, enter the EIGRP sub configuration mode. The in and out keywords do exactly what they sound like, the in command will filter updates incoming, and the out command will filter outbound updates. Lastly, you can actually specify a specific interface which you want that route-filter to apply to, instead of applying it to the entire EIGRP instance.

To configure route filtering using a prefix-list:

distribute-list prefix [prefix-list-name] [in | out]

To configure route filtering using an ACL:

distribute-list [acl-name] [in | out]

To configure route filtering using a route-map:

distribute-list route-map [route-map-name] [in | out]

To view applied filters to EIGRP:
Router#show ip protocols

Posted in Routing, The Ten CommandmentsTagged , , , , , ,

Leave a Reply

Your email address will not be published. Required fields are marked *