EIGRP Route filtering (from CCNP study)

I have managed to mock up the 'work' network using GNS3 = great success.
As such, I can apply the CCNP knowledge learned through study on the work based topology to enhance my comfort levels with the various commands.

Today (and the past few weeks) have been focusing on EIGRP which we do not use at work (from the ICND1 days, you'll know that EIGRP is Cisco's proprietory routing protocol) because we have some HP (peh) equipment at the core.

Route Filtering with EIGRP
Filtering inbound routes by source (using a route-map)

I set myself a small task of filtering EIGRP routing updates on an inbound interface.  I inserted the following commands:

acccess-list 99 permit 192.168.240.2and then:route-map test deny 10
match ip address 99route-map test permit 20
and then (under the router eirgrp <process number>:
distribute-list route-map test in

Explaining the above: I wanted to block routing updates from a device with I.P 192.168.240.2 listed in the ACL 99 I created first.  I then created a route-map called 'test' and denied anything that matched the ip address defined in the ACL 99.  Route-maps end with an explicit deny, so a permit statement with a later sequence number (20) was added to permit everything else.
I then inserted the distribute-list command referencing the route-map name and specified it as inbound.

Sounds good - but it didn't work! LOL.

The answer was with the match statement in the route-map:

match ip route-source 99

With this in place, routing updates from 192.168.240.2 were not in the routing table - leason learnt.


Filtering inbound routes by what is inside the route advertisement (Using an ACL)

Now lets say we wanted to receive routing updates from the router 192.168.240.2 but within its route advertisement it was advertising a route to 192.168.15.0/24 and we would like to remove that.

Distribute lists do not work with extended ACL's so its best to create an standard IP ACL.

ip access-list standard test
 deny   192.168.15.0 0.0.0.255
 permit any

Like so.  We have created a standard ACL called 'test' and denied our subnet we want out of the routing update.
Under the router process we define the distribute list:

distribute-list test in

To check the ACL is matching packets you can run a show access-list command and the show ip route command should confirm that the route is being filtered.

I will state as a mini-disclaimer that I do not like route filtering inbound unless it is a real requirement for complex networks.  Route re-distribution plays a role in inbound filtering but for most networks the inbound filtering component can be a headache to manage and understand (especially if not documented correctly).  Also in most enterprises a branch site router over some WAN link would want a route filtered before it traverses the WAN link!  otherwise the bandwidth is being used, only to the have the route removed at destination.
The stages of learning early CCNP text reference route filtering on outbound interfaces only - obviously to keep you sane! but also, its far easier to define what is being filtered out than in (in my opinion) at this early stage of learning.

Only one IP access-group allowed

A network manager needs to allow some inbound traffic from our version of the internet.  To complete this, we need to review our ACL on a border router.  The device uses CBAC or IP Inspect as it's known in the CLI to allow only internal traffic back through the router (traffic must be generated internally first to be allowed back through the stateful inspection list).  Usually these routers deny everything coming in on the internet facing interface - because there are some nasty folk out there.

Whilst it seems normal to create an ACL for the required ranges for the network manager, after I'd done the hard work in configuring the wildcard masks (they are odd, aren't they?) I then 'forgot' that you can only have one IP access-group either inbound or outbound on an interface.  I say forgot, but I actually forgot there already was one (which said deny to anything inbound) applied to the interface.  When I came to type ip access-group... I thought I'd check to see if there was one already. 

And to summarise, yes there was one.  And yes, the ACL I created was a waste.  Instead I had to append the IP ranges and wildcards to the already configured extended access-list - taking care to ensure the deny statement was at the end of list. 

So, only one IP access-group is allowed on an interface (one for each direction) - this in turn may affect how you setup your ACL's.