Teach Me How to Route

Beer me that Route!

I’ve actually been meaning to write this post for 2 months now, but I keep procrastinating and bingewatching Netflix instead.
I found myself in a precarious situation a while ago, something that we’ve since resolved through changes in our network architecture, but prior to the changes, I learned a thing or two thanks to it.
The issue we were having was an issue where the router which terminated VPN connections sat behind a separate router, usually this would not be an issue as we would have enabled EIGRP on them to exchange the routes. The issue however was that we were utilizing VRF-lite on the VPN terminating router to separate the underlay and overlay networks. Due to this, there was no way to get the border router to properly communicate with the VRF.
Now, a preface to this is that generally speaking, all VPN connections would usually have been over a terrestrial transmission piece (we have our DMVPN clouds separated for full-mesh support on the TDMA), however, we were testing out new campus fiber connections which terminated on our border router. The idea was, due to concerns about wire tapping, that we needed to terminate these connections to our IPSEC DMVPN cloud.
Me being me, I didn’t want to create a separate cloud on the border router to terminate these connections, so I ventured out on a journey to learn how to get them to communicate.
It turns out, it’s actually pretty simple.

Goals

  1. Import campus fiber /24 into the VRF on the internal router.
  2. Export DMVPN loopback /32 to the global RIB on the internal router, and advertise this network to the border router.
  3. Verify Phase-1 DMVPN connectivity on campus fiber sourced spokes.

Here is a representation of what we’re working with so you better understand. Understand the  “Loopback10” is in the “DMVPN-TERR” VRF.

 

Step 1:

First, we’re just going to verify that as we have everything setup in our lab, that the following should happen:

  1. From the inner router, A “show ip route vrf DMVPN-TERR 10.10.150.0” will return 0 entries in the routing table.
  2. From both the inner router and outer routers global RIB, a “show ip route 10.10.151.224” will return 0 entries.
  3. The spoke should not be able to ping the “10.10.151.224” address.

Additionally, at first the /27 for the DMVPN tunnel will be routed to the outer router, this is undesirable.
We need to set in place a route filter, going back to some of our older skills we learned, to prevent recursive routing, which would end up in the looped chain, attempting to stack error.
As expected, all of the following tests responded how we expected!

Changes Needed:

  1. Create a VRF definition for what we’re going to use as our shared routing table.
  2. Place all interfaces which currently reside in the Global RIB on the inner router into our shared VRF.
  3. Create route distinquishers for DMVPN-TERR and our shared VRF.
  4. Configure EIGRP for our VRF.

To create a VRF
Router(config)#vrf definition <vrf-name>
Router(config-vrf)#address-family ipv4
To place an interface in the VRF
Router(config-if)# vrf forwarding <vrf-name>
Once you place the interface in the VRF, re-assign it’s IP address. You will need to do this for anything that currently resides in the default RIB.
After you do that, you must create the EIGRP instance for the VRF, to do this:

Router(config)#router eigrp <asn>

Router(config-router)#address-family ipv4 vrf <vrf-name> autonomous-system <asn>

Router(config-router-af)#network <network> <wildcard>

Since I’ve started working with EIGRP on multiple VRFs, as well as with IPv6, I’ve taken to EIGRP named mode. 
The benefit to named mode is that it’s modular configuration of all EIGRP configurations from within the EIGRP router configuration mode. No longer do I need to enable authentication on a per-interface level. 
To read more about EIGRP named mode:
https://www.rogerperkin.co.uk/ccie/eigrp-named-mode/
https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/200156-Configure-EIGRP-Named-Mode.html
You can also upgrade your current configuration to named mode with the “eigrp upgrade-cli” command.
Next, to assign route distinquishers to a VRF:

Router(config-vrf)# rd [rd:rd]

  1. Our RD for our DMVPN-TERR will be 9001:900
  2. Our RD for our SHARED-GLOBAL will be 9001:999

Now, to verify that the SHARED-GLOBAL looked like before, do a “show ip route vrf SHARED-GLOBAL”
 

Leaking Routes:

Now that we have setup our shared tables, we’re going to use route-maps to select which networks we are going to leak into the shared routing and into the DMVPN-TERR routing table.

  1. We need to leak the 10.10.150.0/24 into DMVPN-TERR
  2. We need to leak the 10.10.151.224/32 into the SHARED-GLOBAL

To do this, use ip prefix-lists:

Router(config)#ip prefix-list <prefix-list> seq <#> permit <network/mask>

Once you have done that, create a route-map that matches that prefix-list.
Here is what we are going to do:

Router(config)# ip prefix-list PL-FIBER-TO-DMVPN seq 5 permit 10.10.150.0/24

Router(config)# route-map RM-SHARED-TO-DMVPN

Router(config-route-map)# match ip address prefix-list PL-FIBER-TO-DMVPN

Router(config)# ip prefix-list PL-DMVPN-TO-FIBER seq 5 permit 10.10.151.224/32

Router(config)# route-map RM-DMVPN-TO-SHARED

Router(config-route-map)#match ip address prefix-list PL-DMVPN-TO-FIBER

After we do that, we need to configure the import and export maps on our VRFs, to do this:

Router(config)# vrf definition <vrf-name>

Router(config-vrf)# address-family ipv4

Router(config-vrf-af)# import map <map-name>

Additionally, you have to specify which topology you want to target for import and export.
For our use case, the export will be the self RD, and the import will be the opposite RD.

Router(config-vrf)#route-target import [rd]

Router(config-vrf)#route-target export [rd]

Next, we’re going to enable a BGP instance whose sole purpose is to import/export these routes between the routing tables. I’ve come to call this my “ghost” BGP instance, although I’m not sure if that’s proper whatsoever.
To enable the instance to work with multiple VRFs, use the address family command.
Because the routes we are wishing to share are connected, or learned through a routing protocol, we must utilize the “redistribute” command.

Router(config)#router bgp <asn>

Router(config-router)#address-family ipv4 vrf <vrf-name>

Router(config-router-af)#redistribute <method>

  1. On the DMVPN-TERR, we will be redistributing connected.
  2. On the SHARED-GLOBAL, we will be redistributed EIGRP instance 100

Next, verify this by doing a “show ip route vrf SHARED-GLOBAL” and “show ip route vrf DMVPN-TERR”

Next up, redistribute BGP into EIGRP and you should be able to ping from the spoke to the DMVPN loopback interface.

Now, just to verify our adjacency so I can say my job here is done!

 
 
 
 

Posted in RoutingTagged , , , , , Leave a Comment on Beer me that Route!

Essential Constructs: Path Manipulation

One of the things that I think is key from separating a good network engineer from a great network enginner is their ability to control the paths which data travels.
As we all know, each routing protocol has built-in best path algorithms, but sometimes, these just aren’t enough. There may be many reasons for an administrator to need to override these routing protocols, in order to do this, you must understand the best path calculation for each routing protocol.

Understanding Best-Path Selection

Key to understanding which route will be installed in the routing table, is understanding how each routing protocol will select it’s candidate to be presented to the routing table.
Once routes are presented from the routing process, to the routing table, the router will select the route with the lowest administrative distance to be installed into the routing table.
[table id=2 /]
Once a route is installed into the routing table, the router will evaluate whether there are any routing policies installed. If a policy based route (PBR) is installed, the router will forward traffic based on that policy. If there is no PBR, the router will forward traffic out the route which has the most specific prefix.
We have two considerations for path manipulation:

  1. How our router will forward packets.
  2. How adjacent routers will forward packets.

The easiest part is manipulating how our router will forward packets, the two simplest ways to do this are via PBR and route-maps. After we configure our path manipulation, we have to consider how we want other routers in the topology to forward our traffic. The easiest way to do this is to place route-maps on our outbound routes. In the future, I may start begin referring to routes as NLRI (network layer reach ability information), but mostly just when talking about BGP.
Before we go any further, and delve into actually configuring a solution, we need to understand how each routing protocol selects candidate routes for the routing table. This is extremely important since we need to know what to change to manipulate administrative distances and metrics.
RIP:

  • RIP has a default administrative distance of 120.
  • RIP utilizes hop-count to determine its metric, with 1 being the lowest, and 15 being the highest.
  • RIP will not present a route to the routing table with a hop-count of higher than 15.
  • By default, RIP will only route on classful boundaries, it is important that you enable ip classless at the global configuration level and no auto-summary on the router configuration level. This will ensure that RIP includes the complete prefix, instead of just the classful boundary in its routing update.
  • When redistributing routes into RIP, Cisco recommends using a low hop-count (such as 1).

EIGRP:

  • EIGRP Internal Routes have an administrative distance of 90; external, or redistributed routes have an administrative distance of 170.
  • EIGRP Utilizes K-Values for Calculation, by default, the only two used for metric calculation are bandwidth and delay. Cisco recommends not changing this. Note: changing K-values on one EIGRP neighbor will cause neighbor-relationship issues with neighboring routers.
    • K1 – Bandwidth (Enabled by Default)
    • K2 – Load (Disabled by Default)
    • K3 – Delay (Enabled by Default)
    • K4 – Reliability (Disabled by Default)
    • K5 – MTU (Disabled by Default)
  • The bandwidth used for the metric calculation is the lowest bandwidth on any interface in the path.
  • The delay is the total time (in tens of microseconds) a packet takes to travel across an interface.
  • The full metric formula is:
    • metric = ([K1 * bandwidth + (K2 * bandwidth) / (256 – load) + K3 * delay] * [K5 / (reliability + K4)]) * 256
  • The simplified metric formula, when using the default K-Values is:
    • metric = bandwidth + delay
  • When redistributing routes into EIGRP, you must specify the bandwidth, delay, reliability, load and MTU for EIGRP to calculate a metric for these routes.

OSPF:

  • OSPF has a default administrative distance of 110.
  • OSPF utilizes bandwidth in its metric calculation.
  • By default, the reference bandwidth is 100MBps, meaning that any interface with a speed above that, will be seen the same as a 100MBps interface in the eyes of OSPF. It is important to change the reference bandwidth to the highest speed interface installed on your router.
  • Reference bandwidth should also be changed on all routers within the same OSPF area.
  • All redistributed routes will receive a metric of 20, except for BGP routes, which receive a metric of 1

BGP:
BGP has the most robust best-path selection process out of all of the routing protocols. BGP will utilize what is referred to as Path Attributes. BGP has about 13 different attributes it evaluates before selecting a best route. BGP will run through this process until there is a definitive winner. This means that if a path wins and evaluation anywhere along the process, it is selected as the best path.

  1. First and foremost is the Weight, this is generally proprietary to Cisco’s implementation of BGP, the weight attribute is configured by the administrator and is only locally significant.
  2. The path with the highest LOCAL_PREF attribute. BGP assumes a default value of 100 when no LOCAL_PREF has been specified by the administrator.
  3. Path Type; BGP will prefer routes learned through the network or aggregate command, before routes learned through redistribution.
  4. AS_PATH; the AS_PATH defines which autonomous systems the route has past through before it got to us, the route with which traverses the least amount of autonomous systems is preferred.
  5. Origin Type; this informs BGP whether the route was originated from an IGP, EGP or INCOMPLETE. IGP has the lowest origin code, EGP follows, followed by INCOMPLETE. BGP will prefer the route with the lowest origin code.
  6. Multi-Exit Discriminator (MED) – BGP will prefer the path with the lowest MED, the MED is used when routes are received from neighbors with the same ASN. If the router received matching routes from neighbors that are not in the same ASN, this will be ignored.
  7. BGP Neighbor Type; prefer eBGP over iBGP
  8. Lowest IGP metric; self-explanatory
  9. Determine whether we need to present two candidates to the routing table (is BGP multi-path enabled?)
  10. Prefer the path which was received first (oldest path)
  11. Prefer the path which was received from the neighbor with the lowest BGP router-ID.
  12. We’ll skip this; not used unless you are in a BGP RR environment. (I’m also not too sure what the hell it means)
  13. Prefer the path with the lowest neighbor IP address.

The best part about BGP is that it gives us, administrators, the most robust solution to manipulate and engineer traffic in the way we desire. It’s also somewhat confusing, and hard to remember, but don’t be too intimidated, (other than if you’re taking your tests) you can always reference the Cisco support page.

Why Manipulate Paths?

  1. Despite routing protocols having their respective best-path selection algorithms, there may be instances where the router does not take the actual best path.
  2. There may be instances where we need to separate network traffic, and route traffic differently based off of it’s source/destination address.

Methods of Manipulation

  1. Offset Lists; specific to RIP, these will change the outgoing (or incoming) hop-count on a route(I mean, technically you could use them for EIGRP).
  2. Route-Maps; these are powerful, using these we can change the administrative distance, metric, or other attributes to a route.
  3. Policy-Based Routing; policy based routing is essentially static routing, however, we can get extremely granular and specify where we are going to forward traffic based off of the traffic type, source/destination IP address, etc.
  4. IP-SLAs; these are often not considered a method for path manipulation, but can definitely be used as such. IP-SLAs allow us to configure tracked objects and make decisions based off the reach ability, reliability or response time of a path.
  5. Route Filtering; this will be key in manipulating how we want other routers which we are not directly in control of, to forward traffic.

Example #1: RIP Offset List

This example is going to be extremely simple, given the network topology, we’re going to create an access-control list and apply an offset list to our routes going outbound on a specific interface.

Our objective for this lab is extremely simple, we are going to make sure that R1 utilizes path 1 to forward traffic to the 10.10.10.0/24 network. As we all know, RIP only utilizes hop-count for it’s metric, so although Path 1 has a higher bandwidth, both paths would be seen equally from R1. Due to the fact that both paths would be seen equally, R1 would load balance. This is not a desired action whatsoever, as the traffic share ratio would be 1:1, and RIP would not do what EIGRP does where it will calculate the percentage of packets to be routed out each interface (this is more specific to EIGRPs ability of unequal cost load balancing).
We are not going to make any changes on R1, all changes will be made from R2.
This lab will be utilizing 4 Cisco IOSv 15.6(2)T routers in GNS3. I have posted all the lab files (including diagrams) on the “Lab Files” page, which can be found in the menu bar at the top.
First, verify that the hop-count for the “10.10.10.0/24” network on R1 is 2, also verify that your routing table has two entries for this network:

The first step; creating the access list. For this, we can simply use a standard ACL which matches the network for interface “Loopback 1”.
Router(config)#access-list 1 permit 10.10.10.0 0.0.0.255
After creating the access list, you need to go into router configuration mode for the RIP process on R2; the lab already should have RIP enabled and all the interfaces configured. (I’ll post the initial configs in case GNS3 didn’t export them for some reason). For this network, we’re going to offset the hop-count by 3, going out interface G0/0, which leads to path 2.
Router(config)#router rip
Router(config-router)#offset-list 1 out 3 GigabitEthernet0/0

Once completed, do a “show ip protocols”; you will see something along the lines of “Outgoing routes in GigabitEthernet0/0 will have 3 added to metric if on list 1”
If you know somebody at Cisco that could please fix the English on that statement, that would be great. That just perturbs me.

This simply means that if the network is in the access-list 1, and being sent out interface GigabitEthernet0/0 we will report the hop-count as 3 to R3; thus ensuring that path 1 is the preferred path to this network. To verify this, console into R1 and do a traceroute to the 10.10.10.0/24 network, you should see it traverse through R4.

That was pretty simply, though when using RIP, remember to keep in mind that RIP will not present a route to the routing table if it has a hop-count of higher than 15. This means you can’t offset the route too much, especially if your network has alot more hops than this lab does.
The syntax for the offset list is as follows:
offset-list [acl-name] [in | out] [0-16] [interface-name]
The 4th argument is the hop count which you want to offset, and the final argument is optional (though pretty pointless if you don’t do it, for RIP anyway.)

Example #2: EIGRP Policy-Based Routing and Offset Lists

In this example, we’re going to go with pairing a few things together to get granular control over the path traffic takes. As we all know, EIGRP utilizes bandwidth and delay in it’s calculations, important to know here is that it will use the default interface bandwidth and delay, unless otherwise specified. Sure, it’s absolutely easy to change that, but that’s not the point of this lab. The point of this lab is to show you different ways in which you could manipulate the path for which you want data to travel.
For this lab, we are going to a 6 router topology. All links will be connected via gigabit ethernet, so EIGRP will calculate the same metric for all paths. Given the topology, ensure that voice traffic will always flow over the most desirable path. You will need to do so without configuring interface bandwidth or delay, and you do not have control over any router other than R2. (Well, you can console into all the other routers just to verify, but you cannot configure anything on them).

 
The first thing we will need to do is create access-lists for the voice and user networks, we will reference these throughout multiple parts of our lab.

ip access-list standard User-Network
permit 10.10.25.0 0.0.0.255
ip access-list standard Voice-Network
permit 10.10.24.0 0.0.0.255

The first part we’re going to do is create multiple IP SLAs and tracked object. These will give us the ability to monitor the reachability of a network over a certain path. Our first tracked object will monitor the interface on R1 over path 3, the second will monitor the interface on R1 over path 1.
ip sla 1
icmp-echo 10.10.10.9 source-interface GigabitEthernet0/0
timeout 6000
ip sla schedule 1 life forever start-time now
ip sla 2
icmp-echo 10.10.10.1 source-interface GigabitEthernet0/1
timeout 6000
ip sla schedule 2 life forever start-time now

After defining the IP-SLAs, next create the tracked objects which are linked to these SLAs, these will allow us to define specific actions based on the state of the tracked object.
track 1 ip sla 1
track 2 ip sla 2

We have set our IP-SLAs to change their state to failure if they are not able to ping the destination within a 6000 millisecond timeframe.
To view the statistics of your IP SLAs:
show ip sla summary
show ip sla statistics


To view the state of our tracked objects:
show track
For our route-map, we are going to utilize sequence numbers. Sequence numbers are used in access-lists, but also route-maps. Think of route-maps as ACLs for how we want to manipulate routing. If a packet does not match anything defined in the match claw within a sequence, then the router will proceed to the next entry in the route map. If nothing is matched, it will route based off of the routing table.
For our route-map, we’re simply going to match the source IP, and set the next-hop (there are plenty of other things we could do as well, but just trying to show you examples). For our “set ip next-hop” clause, we are going to utilize the “verify-reachability” argument. This will allow us to link the action to a tracked object, the route map will only set this as the next-hop if the tracked object state is “UP”. We will use multiple set entries to set the backup next-hop to R5.
route-map RM-EIGRP-PBR permit 5
match ip address Voice-Network
set ip next-hop verify-availability 10.10.10.22 1 track 1
set ip next-hop 10.10.10.18
!
route-map RM-EIGRP-PBR permit 10
match ip address User-Network
set ip next-hop verify-availability 10.10.10.14 1 track 2
set ip next-hop 10.10.10.18
!

Something to note about route-maps is that multiple match clauses, on the same line are viewed as logical OR statements.
Match statements on different lines are viewed as logical AND statements
After you define the route-map, you must apply it to the interface on which we are going to match the inbound traffic, this would be GigabitEthernet0/2. Do this with the command (from interface configuration level):
ip policy route-map RM-EIGRP-PBR
At this point, if you were to ping R1 with traffic sourced from the User network, it would take Path 1, and voice would take path 3. If you want to see R2 forwarding this traffic, enable the below command and send traffic from R3 to R1 sourced from one of our loopback interfaces.
debug ip policy


For manipulating our metrics, we’re simply going to do what we did earlier with  RIP, and use offset lists. These offset lists will reference the ACLs we already created earlier.
This is extremely simple. On G0/3, we’re going to offset the voice and user networks by +1000, on G0/0 we’re going to offset the User network by +2000 and on G0/1, we’re going to offset the voice network by +2000. Note that for outbound updates on G0/3, we will have to create a new ACL which contains both the User and Voice networks.
ip access-list standard User-and-Voice-Network
permit 10.10.24.0 0.0.0.255
permit 10.10.25.0 0.0.0.255

Next, hammer down into the router subconfiguration mode for the EIGRP proccess and apply those offset lists:
offset-list User-Network out 2000 GigabitEthernet0/0
offset-list User-and-Voice-Network out 1000 GigabitEthernet0/3
offset-list Voice-Network out 2000 GigabitEthernet0/1

 
Please note that as part of my initial configuration, I emplaced a route-filter on R1 to ensure that the transport routers (R4,R5,R6) do not receive routes for the User or Voice network from R1.
Now that that is done, you can console into R1 and do a show ip route, you will notice that there is no longer 3 entries in the routing table. You will notice that the user network is seen best out of G0/0, and that the voice network is seen best out of G0/1.

 
Next, let’s verify our PBR by shutting down G0/0 on R6. Once complete, just wait a few seconds and do a “show track”, you should see a changed state for the tracked object. This should also come up as a syslog message. 
Just verify that our PBR is working by pinging from Lo2 on R3 to anything on R1. Keep the “debug ip policy” running on R2. This is what your output should look like. On R2, you should see the router setting the gateway, or next-hop to 10.10.10.18

I hope you liked these two examples, and the discussion on path manipulation. Even if this example doesn’t exactly make the most sense, I think it still shows the variety of possibilities we have when configuring path control. There’s alot you could do with path manipulation and it isn’t limited to outbound routes either. We could easily manipulate inbound routes based on a number of properties.
One cool thing that I want you guys to see real quick is that you can tag routing updates with a a value in either decimal format, or dotted decimal format. This is great for EIGRP because by doing this, on the origin router, I can basically tell any other routers within the topology who originated these routes and then filter or modify metrics based off of that.
Hint: I really like the AS_PATH attribute in BGP, because it just makes sense that I want to see who originated these routes.
 

Posted in RoutingTagged , , , , , , , , , , , , Leave a Comment on Essential Constructs: Path Manipulation

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 Comment on The Ten Commandments: #1 Route Filtering