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!
