Can't get this to work (boring Cisco stuff)

[Donny_Dog]

I need to filter routing updates inbound from Eigrp (I have no idea why, I have been asked to do it - outbound filtering FTW).
The device connected directly on a /30 subnet is 192.168.240.2 and it is advertising its own connected route of 192.168.15.0/24.

I do not want to use prefix lists, so have setup the following (on the router that wants to block it inbound):

access-list 99 permit 192.168.240.2

and then:

route-map test deny 10
match ip address 99

route-map test permit 20

and then (under the router eirgrp <process number>:

distribute-list route-map test in

...and it doesn't fcking work.

it doesn't look like anything is being matched....

sh route-map
route-map test, deny, sequence 10
Match clauses:
ip address (access-lists): 99
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map test, permit, sequence 23
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes

Any ideas what is wrong?

 

[Adam.]

Try turning it on and off again. Cookie had a similar issue and this solved it.

 

[Adam.]

Lack of "set" command could be an issue? Or lack of subnet after the first IP.

 

[Cookie]

Doing my icnd2 course this week. Not up to eigrp so I can't help yet

 

[Donny_Dog]

Lack of "set" command could be an issue? Or lack of subnet after the first IP.

You can get away with no subnet after the ip in an ACL as it basically means this host/address only. Its the same as putting a wildcard mask of 0.0.0.0.
But you're right, on interface I.P's etc then you'll need a 'proper' mask following the address.

 

[Donny_Dog]

Fixed it - if anyone gives a sh*t.

access-list 99 permit 192.168.240.2

and then:

route-map test deny 10
match ip route-source 99

route-map test permit 20

and then (under the router eirgrp <process number>:

distribute-list route-map test in




It appears by matching just the ip address in the route-map statement doesn't give the desired results. This might only apply on inbound filtered routes in EIGRP though hence why it was a head scratcher. If you match the route-source (where the route has come from) with a corresponding ACL then it filters routes defined in the ACL (the one host I wanted).

I think this can actually be accomplished by just ACL and distribute list commands though but happy its resolved anyway.