Filtering traffic with a route-map

This post describes how to filter packets with a route-map. I have never used
a route-map for the sole purpose of filtering packets before. I ran into this
while doing a vol2 lab and the task was to filter ICMP packets coming in
on a frame-relay interface and out on VLAN 162. The packets should only
be filtered if they were between 100 and 200 bytes long. The topology is
the same as in my previous post.

My first thought was to use MQC to accomplish this but we were not allowed
to do so. We were not allowed to use FPM either. That only leaves us with
a route-map. Often policy routing is not allowed in the CCIE lab unless
specified but in this case it is our only option.

First we create an ACL that matches all ICMP. All configuration is applied to R6.

ip access-list extended ICMP
permit icmp any any

Then we create the route-map and do some matches.

route-map DROP
match ip access-group name ICMP
match interface FastEthernet 0/0
match length 100 200
set interface Null0
int s0/0/0.1
ip policy route-map DROP

The packets have to match all three criterias. The packet must match the ACL ICMP
which means it’s an ICMP packet. The packet is between 100 and 200 bytes long. The
packet is being output on interface FastEthernet 0/0 meaning the VLAN 162 subnet.
We apply the policy to the S0/0/0.1 interface which is the frame-relay interface.
Remember that traffic destined to the router is not affected by this policy, only
transit traffic will be affected. This means that packets won’t be dropped if we
try to ping R6.

Lets confirm that the policy is working. We turn on policy debugging on R6.

Rack24R6#debug ip policy
Policy routing debugging is on

RS.22.24.BB1>ping
Protocol [ip]:
Target IP address: 192.10.24.1
Repeat count [5]:
Datagram size [100]: 50
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 50-byte ICMP Echos to 192.10.24.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/26/32 ms
RS.22.24.BB1>ping
Protocol [ip]:
Target IP address: 192.10.24.1
Repeat count [5]:
Datagram size [100]: 150
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 150-byte ICMP Echos to 192.10.24.1, timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)
RS.22.24.BB1>

The testing is done from BB1. You can see that when the packets are only 50 bytes long
there is no dropping ocurring. If we use a size of 150 bytes packets are being dropped.
The policy is working, lets look at debug output on R6.

Rack24R6#
May 14 14:23:41.110: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 50, FIB policy rejected(no match) – normal forwarding
May 14 14:23:41.130: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 50, FIB policy rejected(no match) – normal forwarding
May 14 14:23:41.162: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 50, FIB policy rejected(no match) – normal forwarding
May 14 14:23:41.202: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 50, FIB policy rejected(no match) – normal forwarding
May 14 14:23:41.222: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 50, FIB policy rejected(no match) – normal forwarding
Rack24R6#
May 14 14:24:02.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, FIB policy match
May 14 14:24:02.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, PBR Counted
May 14 14:24:02.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1 (Null0), len 150, FIB policy routed(drop)
Rack24R6#
May 14 14:24:04.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, FIB policy match
May 14 14:24:04.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, PBR Counted
May 14 14:24:04.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1 (Null0), len 150, FIB policy routed(drop)
Rack24R6#
May 14 14:24:06.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, FIB policy match
May 14 14:24:06.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, PBR Counted
May 14 14:24:06.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1 (Null0), len 150, FIB policy routed(drop)
Rack24R6#
May 14 14:24:08.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, FIB policy match
May 14 14:24:08.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, PBR Counted
May 14 14:24:08.058: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1 (Null0), len 150, FIB policy routed(drop)
Rack24R6#
May 14 14:24:10.062: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, FIB policy match
May 14 14:24:10.062: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1, len 150, PBR Counted
May 14 14:24:10.062: IP: s=54.24.1.254 (Serial0/0/0.1), d=192.10.24.1 (Null0), len 150, FIB policy routed(drop)

The first five packets don’t match the policy so they use normal forwarding. The next five
packets are being dropped. We can also see this with show route-map.

Rack24R6#sh route-map
route-map DROP, permit, sequence 10
Match clauses:
ip address (access-lists): ICMP
interface FastEthernet0/0
length 100 200
Set clauses:
interface Null0
Policy routing matches: 15 packets, 1810 bytes

And this is how flexible route-maps are, we can use them to modify metrics, redistribute and
even filter traffic.