The BIG lab – Part 8 – Route-filtering and fixing route recursion using a distribute list (2.90)

Following on from part 7 when we created a tunnel between R5 and R10 (refer to part 1 for the topology) we have a little bit of tidying up to do (basically static routes are verboten on the proper exam), but first we are going to have a dip into filtering some routes.
We can be a bit creative and prevent routers from learning about specific routes – say for instance we have a “secure” network that we don’t want to be advertised to some routers, depending on where we are limiting access to we have a number of options, including access-lists, prefix-lists, distribute-lists and route-maps. We arn’t going to use a route-map to prevent a route, as these are mainly used during redistribution, but we can play around with access-lists, prefix-lists and distribute-lists.

R1 has a loopback interface, which will be our “secure network”:

R1#sh run int lo0
Building configuration...

Current configuration : 95 bytes
!
interface Loopback0
 ip address 10.10.1.1 255.255.255.0
 ip ospf network point-to-point
end
This is accessible by R10:
R10#ping 10.10.1.1
Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.10.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/36 ms

R10#
R10#sh ip route 10.10.1.0
Routing entry for 10.10.1.0/24
 Known via "eigrp 10", distance 170, metric 2937856, type external
 Redistributing via eigrp 10
Last update from 10.31.1.1 on Serial1/0, 00:22:07 ago
 Routing Descriptor Blocks:
 * 10.31.1.1, from 10.31.1.1, 00:22:07 ago, via Serial1/0
   Route metric is 2937856, traffic share count is 1
   Total delay is 50000 microseconds, minimum bandwidth is 1544 Kbit
   Reliability 255/255, minimum MTU 1500 bytes
   Loading 1/255, Hops 2
R10#

Controlling routes through an access-list

So assuming that everything before R10 is allowed to this “private” network we need to prevent R10 from seeing this route (but lets keep access to R1’s interface (1.2.3.4/24) accessible. we can do this in a number of ways. The most obvious place to put any configuration would be on R8’s s0/2 interface.
I am going to use a distribute list for this, which references an access-list.
router eigrp 10
 distribute-list 1 out Serial0/2
 network 10.0.0.0
 no auto-summary
!
access-list 1 deny 10.10.1.0 0.0.0.255
access-list 1 permit any
Then I shut down the S0/2 interface on R8, cleared the IP routing table on R10 using “clear ip route *” and brought up the S0/2 interface on R8.
And now do we see the 10.10.1.0/24 network magically disappear from R10?
R10#sh ip route | beg 10.10
D EX  10.10.1.0/24 [170/27136000] via 10.120.2.1, 00:02:47, Tunnel0
D     10.20.1.0/24 [90/3193856] via 10.31.1.1, 00:02:47, Serial1/0
No, it has now learned it from its tunnel interface, that we created in part 7.
So let’s add the same access-list to R5 (the other end of the tunnel):
R5(config)#access-list 1 deny 10.10.1.0 0.0.0.255
R5(config)#access-list 1 permit any
R5(config)#router eigrp 10
R5(config-router)#distribute-list 1 out Tunnel 0
R5(config-router)#exit
R5(config)#int tunnel 0
R5(config-if)#shut
Now let’s clear the route from R10
R10#
*Nov 25 13:06:24.635: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.120.2.1 (Tunnel0) is down: holding time expired
R10#sh ip route | i 10.10
R10#
And bring the tunnel back up again, does R10 still have a route to the loopback on R1?
R10#
*Nov 25 13:10:36.375: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.120.2.1 (Tunnel0) is up: new adjacency
R10#sh ip route | i 10.10
R10#
No, it doesn’t.

Controlling routes through a prefix-list

Suppose we are told¬†(for some reason)¬†that we are not allowed to use an access-list, we could use a prefix list. So let’s first put the 10.10.1.0/24 network back onto R10.
R10#
*Nov 25 13:17:31.431: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.120.2.1 (Tunnel0) is down: peer restarted
R10#
*Nov 25 13:17:35.935: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.120.2.1 (Tunnel0) is up: new adjacency
R10#sh ip route | i 10.10
D EX  10.10.1.0/24 [170/27136000] via 10.120.2.1, 00:00:31, Tunnel0
R10#sh ip route | i 10.10
D EX  10.10.1.0/24 [170/2937856] via 10.31.1.1, 00:00:01, Serial1/0
R10#
*Nov 25 13:18:08.659: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.31.1.1 (Serial1/0) is resync: peer graceful-restart
R10#sh ip route | i 10.10
D EX  10.10.1.0/24 [170/2937856] via 10.31.1.1, 00:00:13, Serial1/0
R10#
We can also use a prefix-list to accomplish the same thing, again we will need to put it on both R8 and R5
R8(config)#ip prefix-list deny-10.10.1.0 seq 5 deny 10.10.1.0/24
R8(config)#router eigrp 10
R8(config-router)#distribute-list prefix deny-10.10.1.0 out s0/2
R8(config-router)#
*Nov 25 13:21:29.207: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.31.1.2 (Serial0/2) is resync: route configuration changed
R8(config-router)#
We can see that EIGRP does its stuff, and again R10 gets its path to 10.10.1.0/24 through the tunnel.
R10#sh ip route | i 10.10
D EX  10.10.1.0/24 [170/2937856] via 10.31.1.1, 00:03:19, Serial1/0
R10#
*Nov 25 13:21:29.223: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.31.1.1 (Serial1/0) is resync: peer graceful-restart
R10#sh ip route | i 10.10
D EX  10.10.1.0/24 [170/27136000] via 10.120.2.1, 00:00:08, Tunnel0
So lets do the same commands on R5:
R5(config)#ip prefix-list deny-10.10.1.0 seq 5 deny 10.10.1.0/24
R5(config)#router eigrp 10
R5(config-router)#distribute-list prefix deny-10.10.1.0 out tunnel 0
R5(config-router)#exit

R10#sh ip route | i 10.10
D EX  10.10.1.0/24 [170/27136000] via 10.120.2.1, 00:00:08, Tunnel0
R10#
*Nov 25 13:23:50.015: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.120.2.1 (Tunnel0) is resync: peer graceful-restart
R10#sh ip route | i 10.10
R10#
Now R10 has no knowledge of the 10.10.1.0/24 network, but has also lost many of the other routes:
R10#sh ip route | beg Gateway

Gateway of last resort is not set
   10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
S    10.1.7.1/32 is directly connected, Serial1/0
C    10.31.1.0/24 is directly connected, Serial1/0
L    10.31.1.2/32 is directly connected, Serial1/0
C    10.120.2.0/24 is directly connected, Tunnel0
L    10.120.2.2/32 is directly connected, Tunnel0
   172.20.0.0/16 is variably subnetted, 9 subnets, 3 masks
C    172.20.20.0/24 is directly connected, Loopback0
L    172.20.20.1/32 is directly connected, Loopback0
C    172.20.30.0/24 is directly connected, Loopback1
L    172.20.30.1/32 is directly connected, Loopback1
D    172.20.40.0/23 is a summary, 00:40:49, Null0
C    172.20.40.0/24 is directly connected, Loopback2
L    172.20.40.1/32 is directly connected, Loopback2
C    172.20.41.0/24 is directly connected, Loopback3
L    172.20.41.1/32 is directly connected, Loopback3
R10 has lost the other routes due to a default deny in the prefix-list. We can overcome this by adding the following permit any any rule:
R8(config)#ip prefix-list deny-10.10.1.0 seq 10 permit 0.0.0.0/0 le 32

R5(config)#ip prefix-list deny-10.10.1.0 seq 10 permit 0.0.0.0/0 le 32
And now R10 can still reach R1, but on a different IP address:
R10#ping 1.2.3.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.2.3.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/40 ms
R10#

Fixing recursive routing using a distribute list

Remember back in part 7 when we set up our tunnel, to avoid route recursion and that annoying %TUN-5-RECURDOWN error we had to add a few static routes, well Cisco (in the exam at least) don’t like you to use static routes, if they did then the exam would be so much easier, and where would the fun in that be? So what can we do to keep our tunnel working and still control our metrics?

Lets start by shutting down our tunnel and removing the static routes:

R5(config)#int tunnel 0
R5(config-if)#shut
R5(config-if)#
*Nov 25 14:33:24.711: %DUAL-5-NBRCHANGE: EIGRP-IPv4 10: Neighbor 10.120.2.2 (Tunnel0) is down: interface down
R5(config-if)#exit
R5(config)#
*Nov 25 14:33:26.711: %LINK-5-CHANGED: Interface Tunnel0, changed state to administratively down
*Nov 25 14:33:27.715: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R5(config)#no ip route 172.20.40.0 255.255.255.0 Serial0/0
R5(config)#no ip route 172.20.40.0 255.255.255.0 Serial 0/2 10

R10(config)#int tunnel 0
R10(config-if)#shut
*Nov 25 14:34:27.411: %LINK-5-CHANGED: Interface Tunnel0, changed state to administratively down
*Nov 25 14:34:28.411: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
R10(config-if)#no ip route 10.1.7.1 255.255.255.255 Serial1/0
R10 knows of 10.1.7.0/24 through EIGRP, so the easiest thing to do is to use an incoming distribute list, coupled with an ACL to deny the EIGRP process from learning about the tunnel endpoint on R10. R5 is being used as this is the router that is complaining about route recursion.
router eigrp 10
 distribute-list prefix deny-10.10.1.0 out Tunnel0
 distribute-list 20 in
 network 10.0.0.0
 redistribute rip metric 10000 1000 255 1 1500
 no auto-summary
!
ip prefix-list deny-10.10.1.0 seq 5 deny 10.10.1.0/24
ip prefix-list deny-10.10.1.0 seq 10 permit 0.0.0.0/0 le 32
access-list 20 deny 10.120.2.2
And with this in place our tunnel is stable and we have avoided using any static routes.

 

In part 9 we will add IPv6 onto our network, which should be interesting!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.