Advanced

Troubleshooting
CCIE Routing &
Switching
v5.0
www.MicronicsTraining.com

Narbik Kocharians
CCSI, CCIE #12410
R&S, Security, SP

RIPv2
Questions & Answers
CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 1 of 24
© 2014 Narbik Kocharians. All rights reserved
 Lab 1
Troubleshooting RIPv2 Scenario - I

Lo0 Lo0 Lo0

5.100.99.1/32 5.100.99.5/32 5.100.99.2/32
Lo41
192.168.4.1/32

Tunnel 1
E0/0 E0/0.15 .2 E0/0 E0/0
.1 .5 .5 .2 .21
R1 R5 R2 R7
5.100.15.0/24 DMVPN Tunnel 1 5.100.212.0/24
5.100.245.0/24
192.168.4.2/32 .1 E0/1 E0/0.157 .5
Lo42

5.100.157.0/24
.4
Tunnel 1
E0/0 5.100.4.4/24

.3 E0/0
R4
5.100.99.4/32
Lo0

R3
5.100.99.3/32
Lo0

Lab Setup:

To copy and paste the initial configurations, go to “CCIE-TS-Initial-configurations”

folder → “RIPv2” →”TS-RIPv2-Lab-1”.

Ticket 1

R1 is configured to filter its Lo41, however, this interface is still reachable from R5. DO
NOT configure another access-list, Prefix-list, or route-map, you should use two
commands to accomplish this task.

Let’s verify the problem:

On R5:
R5#ping 192.168.4.1

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 2 of 24
© 2014 Narbik Kocharians. All rights reserved
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.4.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/1/4 ms

Let’s verify R5’s routing table entry for R1’s Lo41:

R5#show ip route 192.168.4.1

Routing entry for 192.168.4.0/24

Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 5.100.15.1 on Ethernet0/0.15, 00:00:11 ago
Routing Descriptor Blocks:
* 5.100.157.1, from 5.100.157.1, 00:00:17 ago, via Ethernet0/0.157
Route metric is 1, traffic share count is 1
5.100.15.1, from 5.100.15.1, 00:00:11 ago, via Ethernet0/0.15
Route metric is 1, traffic share count is 1

We can see that R1’s Lo41 is reachable via both E0/0.157 and the E0/0.15 interfaces. The output of the
above show command also reveals that R1’s Lo41 is reachable through a /24 route.

Shouldn’t R1 send a /32 route for its Loopback41?

Let’s check RIP’s database on R1.

On R1:
R1#show ip rip database

5.0.0.0/8 auto-summary
5.100.15.0/24 directly connected, Ethernet0/0
5.100.99.1/32 directly connected, Loopback0
5.100.99.5/32
[1] via 5.100.157.5, 00:00:09, Ethernet0/1
[1] via 5.100.15.5, 00:00:18, Ethernet0/0
5.100.157.0/24 directly connected, Ethernet0/1
5.100.245.0/24
[1] via 5.100.157.5, 00:00:09, Ethernet0/1
[1] via 5.100.15.5, 00:00:18, Ethernet0/0
192.168.4.0/24 auto-summary
192.168.4.0/24 is possibly down
192.168.4.1/32 directly connected, Loopback41
192.168.4.2/32 directly connected, Loopback42

We can see the problem, R1 is auto-summarizing its routes, therefore, it summarized the Lo41 and Lo42 IP

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 3 of 24
© 2014 Narbik Kocharians. All rights reserved
addresses to a single classful /24 route. Let’s verify this in the configuration:

R1#show run | s router rip

router rip
version 2
network 5.0.0.0
network 192.168.4.0
distribute-list toR5 out Ethernet0/0

We can see that the “no auto-summary” command is missing. Let’s correct this and verify.

R1(config)#router rip
R1(config-router)#no auto-summary

To verify the configuration:

On R1:
R1#show ip rip database

5.0.0.0/8 auto-summary
5.100.15.0/24 directly connected, Ethernet0/0
5.100.99.1/32 directly connected, Loopback0
5.100.99.5/32
[1] via 5.100.157.5, 00:00:19, Ethernet0/1
[1] via 5.100.15.5, 00:00:02, Ethernet0/0
5.100.157.0/24 directly connected, Ethernet0/1
5.100.245.0/24
[1] via 5.100.157.5, 00:00:19, Ethernet0/1
[1] via 5.100.15.5, 00:00:02, Ethernet0/0
192.168.4.0/24 auto-summary
192.168.4.1/32 directly connected, Loopback41
192.168.4.2/32 directly connected, Loopback42

This didn’t work. The entries are still summarized. Let’s check the routing table of R5:

On R5:
R5#show ip route 192.168.4.1

Routing entry for 192.168.4.1/32

Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 5.100.157.1 on Ethernet0/0.157, 00:00:10 ago

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 4 of 24
© 2014 Narbik Kocharians. All rights reserved
 Routing Descriptor Blocks:
* 5.100.157.1, from 5.100.157.1, 00:00:10 ago, via Ethernet0/0.157
Route metric is 1, traffic share count is 1

The output of the above show command reveals that R1’s Lo41 is ONLY reachable through R5’s E0/0.157
interface, can R5 Ping this route? Let’s try:

R5#ping 192.168.4.1

Type escape sequence to abort.

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

Sure can, let’s verify the configured filter on R1:

On R1:
R1#show ip protocol
*** IP Routing is NSF aware ***

Routing Protocol is "application"

Sending updates every 0 seconds
Invalid after 0 seconds, hold down 0, flushed after 0
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Maximum path: 32
Routing for Networks:
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 4)

Routing Protocol is "rip"

Outgoing update filter list for all interfaces is not set
Ethernet0/0 filtered by toR5 (per-user), default is not set
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 26 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface Send Recv Triggered RIP Key-chain
Ethernet0/0 2 2
Ethernet0/1 2 2 TST
Loopback0 2 2
Loopback41 2 2
Loopback42 2 2

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 5 of 24
© 2014 Narbik Kocharians. All rights reserved
 Automatic network summarization is not in effect

Maximum path: 4
Routing for Networks:
5.0.0.0
192.168.4.0
Routing Information Sources:
Gateway Distance Last Update
5.100.15.5 120 00:00:01
5.100.157.5 120 00:00:19
Distance: (default is 120)

R1#show run | s router rip

router rip
version 2
network 5.0.0.0
network 192.168.4.0
distribute-list toR5 out Ethernet0/0
no auto-summary

The access-list is ONLY applied to the E0/0 interface, whereas, it should have been applied to both E0/0
and the E0/1 interfaces.

This can be solved in two ways:

Solution #1
Remove the “Distribute-list” command and apply it without referencing the interface, in which case it will
be applied to all interfaces.

Solution #2
Add the same access-list to the E0/1 interface.

In this case the second method is used:

On R1:
R1(config)#router rip
R1(config-router)#distribute-list toR5

To verify the configuration:

On R1 and R5:

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 6 of 24
© 2014 Narbik Kocharians. All rights reserved
Rx#clear ip route *

R5#ping 192.168.4.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.4.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R5#show ip route rip | b Gate

Gateway of last resort is not set

5.0.0.0/8 is variably subnetted, 8 subnets, 2 masks

R 5.100.99.1/32 [120/1] via 5.100.157.1, 00:00:00, Ethernet0/0.157
[120/1] via 5.100.15.1, 00:00:01, Ethernet0/0.15
192.168.4.0/32 is subnetted, 1 subnets
R 192.168.4.2 [120/1] via 5.100.157.1, 00:00:00, Ethernet0/0.157
[120/1] via 5.100.15.1, 00:00:01, Ethernet0/0.15

Ticket 2

R7 is configued to filter all even third octet networks with a mask of /24, however, this
affected all routes and none of them are reachable from R2.

Let’s verify the problem:

On R2:
R2#show ip route rip | b Gate
Gateway of last resort is not set

5.0.0.0/8 is variably subnetted, 9 subnets, 2 masks

R 5.100.15.0/24 [120/1] via 5.100.245.5, 00:00:12, Tunnel1
R 5.100.99.1/32 [120/2] via 5.100.245.5, 00:00:12, Tunnel1
R 5.100.99.5/32 [120/1] via 5.100.245.5, 00:00:12, Tunnel1
R 5.100.157.0/24 [120/1] via 5.100.245.5, 00:00:12, Tunnel1
192.168.4.0/32 is subnetted, 1 subnets
R 192.168.4.2 [120/2] via 5.100.245.5, 00:00:12, Tunnel1

None of the routes from R7 are in the routing table of R2. Let’s see if R2’s e0/0 interface is configured to

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 7 of 24
© 2014 Narbik Kocharians. All rights reserved
receive RIPv2 routes:

R2#show ip protocol
*** IP Routing is NSF aware ***

Routing Protocol is "application"

Sending updates every 0 seconds
Invalid after 0 seconds, hold down 0, flushed after 0
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Maximum path: 32
Routing for Networks:
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 4)

Routing Protocol is "nhrp"

Maximum path: 1
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 250)

Routing Protocol is "rip"

Outgoing update filter list for all interfaces is (prefix-list) plIn
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 29 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface Send Recv Triggered RIP Key-chain
Ethernet0/0 2 2
Loopback0 2 2
Tunnel1 2 2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
5.0.0.0
Routing Information Sources:
Gateway Distance Last Update
5.100.245.5 120 00:00:06
Distance: (default is 120)

Yes it is configured correctly. Let’s debug ip rip:

R2#debug ip rip
RIP protocol debugging is on

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 8 of 24
© 2014 Narbik Kocharians. All rights reserved
RIP: ignored v1 packet from 5.100.212.21 (illegal version)

I think we have seen the problem. Let’s disbale debugging:

R2#undebug all

On R7:
R7#sh ip protocol
*** IP Routing is NSF aware ***

Routing Protocol is "application"

Sending updates every 0 seconds
Invalid after 0 seconds, hold down 0, flushed after 0
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Maximum path: 32
Routing for Networks:
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 4)

Routing Protocol is "rip"

Outgoing update filter list for all interfaces is 10
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 24 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 1, receive any version
Interface Send Recv Triggered RIP Key-chain
Ethernet0/0 1 1 2
(The rest of the output is omitted for brevity)

R7(config)#router rip
R7(config-router)#version 2

R7#clear ip route *

To verify the configuration:

On R2:
R2#show ip route rip | b Gate

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 9 of 24
© 2014 Narbik Kocharians. All rights reserved
Gateway of last resort is not set

5.0.0.0/8 is variably subnetted, 9 subnets, 2 masks

R 5.100.15.0/24 [120/1] via 5.100.245.5, 00:00:19, Tunnel1
R 5.100.99.1/32 [120/2] via 5.100.245.5, 00:00:19, Tunnel1
R 5.100.99.5/32 [120/1] via 5.100.245.5, 00:00:19, Tunnel1
R 5.100.157.0/24 [120/1] via 5.100.245.5, 00:00:19, Tunnel1
192.168.4.0/32 is subnetted, 1 subnets
R 192.168.4.2 [120/2] via 5.100.245.5, 00:00:19, Tunnel1
R 192.168.211.0/24 [120/1] via 5.100.212.21, 00:00:04, Ethernet0/0
R 192.168.213.0/24 [120/1] via 5.100.212.21, 00:00:04, Ethernet0/0
R 192.168.215.0/24 [120/1] via 5.100.212.21, 00:00:04, Ethernet0/0
R 192.168.217.0/24 [120/1] via 5.100.212.21, 00:00:04, Ethernet0/0
R 192.168.219.0/24 [120/1] via 5.100.212.21, 00:00:04, Ethernet0/0

Ticket 3

R4 can’t reach R1’s Lo42 using its Lo0 as the source. You should use a single command
to fix this problem.

Let’s verify the problem:

On R4:
R4#ping 192.168.4.2 source lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.4.2, timeout is 2 seconds:
Packet sent with a source address of 5.100.99.4
.....
Success rate is 0 percent (0/5)

Let’s see if R4 can reach R1’s Lo42 interface using its tunnel interface as the source:

R4#ping 192.168.4.2

Type escape sequence to abort.

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

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 10 of 24
© 2014 Narbik Kocharians. All rights reserved
Yes it can. Let’s verify R4’s routing table:

R4#show ip route 192.168.4.2

Routing entry for 192.168.4.2/32

Known via "rip", distance 120, metric 2
Redistributing via rip
Last update from 5.100.245.5 on Tunnel1, 00:00:09 ago
Routing Descriptor Blocks:
* 5.100.245.5, from 5.100.245.5, 00:00:09 ago, via Tunnel1
Route metric is 2, traffic share count is 1

Well, the route is in R4’s routing table. There are two basic possiblities: The packets are filtered, or R1
can’t reach R4’s Lo0. Let’s verify:

On R1:
R1#show ip route 5.100.99.4
% Subnet not in table

We can see that R1 does NOT have a route back to R4’s Lo0. Let’s move closer to R4 by verifying the
routing table of R5:

On R5:
R5#show ip route 5.100.99.4
% Subnet not in table

R5 doesn’t have a route either. Let’s check and see if R5 receives a route for R4’s Lo0:

R5#debug ip rip
RIP protocol debugging is on

RIP: sending v2 update to 224.0.0.9 via Ethernet0/0 (5.100.15.5)

RIP: build update entries
5.100.99.5/32 via 0.0.0.0, metric 1, tag 0
5.100.157.0/24 via 0.0.0.0, metric 1, tag 0
5.100.245.0/24 via 0.0.0.0, metric 1, tag 0

RIP: received packet with MD5 authentication

RIP: received v2 update from 5.100.157.1 on Ethernet0/1
5.100.15.0/24 via 0.0.0.0 in 1 hops
5.100.99.1/32 via 0.0.0.0 in 1 hops
192.168.4.2/32 via 0.0.0.0 in 1 hops

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 11 of 24
© 2014 Narbik Kocharians. All rights reserved
RIP: received v2 update from 5.100.15.1 on Ethernet0/0
5.100.99.1/32 via 0.0.0.0 in 1 hops
5.100.157.0/24 via 0.0.0.0 in 1 hops
192.168.4.2/32 via 0.0.0.0 in 1 hops

RIP: received packet with MD5 authentication

RIP: ignored v2 packet from 5.100.157.3 (invalid authentication)

R5#
RIP: sending v2 update to 224.0.0.9 via Tunnel1 (5.100.245.5)
RIP: build update entries
5.100.15.0/24 via 0.0.0.0, metric 1, tag 0
5.100.99.1/32 via 0.0.0.0, metric 2, tag 0
5.100.99.5/32 via 0.0.0.0, metric 1, tag 0
5.100.157.0/24 via 0.0.0.0, metric 1, tag 0
5.100.245.0/24 via 0.0.0.0, metric 1, tag 0
192.168.4.2/32 via 0.0.0.0, metric 2, tag 0
RIP: sending v2 update to 224.0.0.9 via Ethernet0/1 (5.100.157.5)
RIP: build update entries
5.100.15.0/24 via 0.0.0.0, metric 1, tag 0
5.100.99.5/32 via 0.0.0.0, metric 1, tag 0
5.100.245.0/24 via 0.0.0.0, metric 1, tag 0

We don’t see any routing update for that route. Let’s disable the debugging:

R5#undebug all
All possible debugging has been turned off

Let’s verify R4’s RIP configuration:

On R4:
R4#show run | s router rip

router rip
version 2
passive-interface default
network 5.0.0.0
no auto-summary

R4 is configured NOT to send any updates out of any of its interfaces and that’s the reason R1 is not
getting the route. Let’s fix this problem:

R4(config)#router rip
R4(config-router)#no passive-interface tunnel 1

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 12 of 24
© 2014 Narbik Kocharians. All rights reserved
R4#ping 192.168.4.2 source lo0

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 192.168.4.2, timeout is 2 seconds:
Packet sent with a source address of 5.100.99.4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/50/52 ms

Ticket 4

R2 is configured to filter its E0/0 interface with an IP address of 5.100.212.2/24, but R5

can’t reach R2’s Lo0.

Let’s verify the problem:

On R5:
R5#ping 5.100.99.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 5.100.99.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Let’s check and see if R5 has an entry for R2’s Lo0 in its routing table:

On R5:
R5#show ip route 5.100.99.2
% Subnet not in table

R5 doesn’t have a route for that Loopback interface in its routing table, let’s verify R2’s configuration:

On R2:
R2#show ip protocol
*** IP Routing is NSF aware ***

Routing Protocol is "application"

Sending updates every 0 seconds

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 13 of 24
© 2014 Narbik Kocharians. All rights reserved
 Invalid after 0 seconds, hold down 0, flushed after 0
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Maximum path: 32
Routing for Networks:
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 4)

Routing Protocol is "nhrp"

Maximum path: 1
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 250)

Routing Protocol is "rip"

Outgoing update filter list for all interfaces is (prefix-list) plIn
Incoming update filter list for all interfaces is not set
Sending updates every 30 seconds, next due in 27 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface Send Recv Triggered RIP Key-chain
Ethernet0/0 2 2
Loopback0 2 2
Tunnel1 2 2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
5.0.0.0
Routing Information Sources:
Gateway Distance Last Update
5.100.245.5 120 00:00:06
5.100.212.21 120 00:00:17
Distance: (default is 120)

Let’s check the prefix-list:

R2#show ip prefix-list

ip prefix-list plIn: 2 entries

seq 5 deny 5.100.212.0/24
seq 10 permit 0.0.0.0/0

The prefix-list plIn is filtering outgoing RIP updates. Can you see the problem in the prefix-list?

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 14 of 24
© 2014 Narbik Kocharians. All rights reserved
The prefix-list denies R2’s E0/0 interface and allows 0.0.0.0/0 which is a default route instead of a catch-
all entry (Permit any) which should have been configued as “0.0.0.0/0 Le 32”. Let’s correct this problem:

R2(config)#no ip prefix-list PlIn

R2(config)#ip prefix-list PlIn seq 5 deny 5.100.212.0/24
R2(config)#ip prefix-list PlIn seq 10 permit 0.0.0.0/0 le 32

Let’s verify and see if R5 can reach R2’s Lo0:

On R5:
R5#show ip route 5.100.99.2

Routing entry for 5.100.99.2/32

Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 5.100.245.2 on Tunnel1, 00:00:14 ago
Routing Descriptor Blocks:
* 5.100.245.2, from 5.100.245.2, 00:00:14 ago, via Tunnel1
Route metric is 1, traffic share count is 1

R5#ping 5.100.99.2

Type escape sequence to abort.

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

Ticket 5

R4 can’t reach R2’s Lo0 interface. DO NOT configure “Neighbor” command , or change
the DMVPN phase, or configure DMVPN in a dynamic manner.

Let’s verify the problem:

On R4:
R4#ping 5.100.99.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 5.100.99.2, timeout is 2 seconds:

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 15 of 24
© 2014 Narbik Kocharians. All rights reserved
.....
Success rate is 0 percent (0/5)

Let’s check the routing table of R4:

R4#show ip route 5.100.99.2

% Subnet not in table

Let’s see if R2 is advertising its Lo0:

On R2:
R2#show run | s rip

router rip
version 2
network 5.0.0.0
distribute-list prefix plIn out
no auto-summary

R2 is advertising its Lo0, we should now check R5’s routing table and see if it has the route in its routing
table:

On R5:
R5#show ip route 5.100.99.2

Routing entry for 5.100.99.2/32

Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 5.100.245.2 on Tunnel1, 00:00:19 ago
Routing Descriptor Blocks:
* 5.100.245.2, from 5.100.245.2, 00:00:19 ago, via Tunnel1
Route metric is 1, traffic share count is 1

Let’s see if R5 can reach R2’s Lo0:

R5#ping 5.100.99.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 5.100.99.2, timeout is 2 seconds:
!!!!!

Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 16 of 24
© 2014 Narbik Kocharians. All rights reserved
In order for R4 to receive an update for R2’s Lo0 interface it has to disable the “IP Split-horizon”, because
R5 is the hub route. Let’s verify this:

R5#show run int tunn 1 | i split-horizon

R5#

OK, we can se the problem, let’s disable the split-horizon on the tunnel 1 interface of R5:

R5(config)#int tunn 1
R5(config-if)#no ip split-horizon

We should verify the routing table of R4:

On R4:
R4#sh ip rou 5.100.99.2

Routing entry for 5.100.99.2/32

Known via "rip", distance 120, metric 2
Redistributing via rip
Last update from 5.100.245.2 on Tunnel1, 00:00:23 ago
Routing Descriptor Blocks:
* 5.100.245.2, from 5.100.245.5, 00:00:23 ago, via Tunnel1
Route metric is 2, traffic share count is 1

Let’s verify reachability:

R4#ping 5.100.99.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 5.100.99.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Based on the output of “Show ip route 5.100.99.2” command, the next hop to reach 5.100.99.2 is
5.100.245.2, let’s see if R4 has reachability to the next-hop IP address for this loopback interface:

R4#ping 5.100.245.2

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 5.100.245.2, timeout is 2 seconds:
.....

Success rate is 0 percent (0/5)

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 17 of 24
© 2014 Narbik Kocharians. All rights reserved
Let’s check the tunnel configuration of R4 and R2:

R4#show run int tunnel 1 | b inter

interface Tunnel1
ip address 5.100.245.4 255.255.255.0
no ip redirects
ip nhrp map 5.100.245.5 192.1.5.5
ip nhrp map multicast 192.1.5.5
ip nhrp network-id 444
tunnel source Ethernet0/1
tunnel mode gre multipoint
end

This looks ok. Let’s check R2’s tunnel interface:

On R2:
R2#show run int tunnel 1 | b inter

interface Tunnel1
ip address 5.100.245.2 255.255.255.0
no ip redirects
ip nhrp map 5.100.245.5 192.1.5.5
ip nhrp map multicast 192.1.5.5
ip nhrp network-id 222
tunnel source Ethernet0/1
tunnel mode gre multipoint
end

This also looks good, let’s enable conditional debugging while pinging R2’s tunnel IP address from R4:

On R4:
R4#debug condition interface tunnel 1
Condition 1 set

R4#debug ip packet
IP packet debugging is on

NOW, let’s ping the next-hop IP address again:

R4#ping 5.100.245.2 rep 1

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 18 of 24
© 2014 Narbik Kocharians. All rights reserved
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 5.100.245.2, timeout is 2 seconds:

IP: s=5.100.245.4 (local), d=224.0.0.9 (Tunnel1), len 72, sending

broad/multicast

IP: s=5.100.245.4 (local), d=224.0.0.9 (Tunnel1), len 72, sending full

packet

IP: s=5.100.245.4 (local), d=5.100.245.2 (Tunnel1), len 100, sending

IP: s=5.100.245.4 (local), d=5.100.245.2 (Tunnel1), len 100,

encapsulation failed.
Success rate is 0 percent (0/1)

We can see the problem, R4 does NOT have a mapping for R2’s Tunnel IP address and this is why it is
failing with “encapsulation failure”. Let’s disable the debug and correct the problem and verify:

R4#undebug all
All possible debugging has been turned off

R4(config)#int tunnel 1
R4(config-if)#ip nhrp map 5.100.245.2 192.1.2.2

For return traffic:

On R2:
R2(config)#int tunnel 1
R2(config-if)#ip nhrp map 5.100.245.4 192.1.4.4

On R4:
R4#ping 5.100.99.2

Type escape sequence to abort.

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

Ticket 6

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 19 of 24
© 2014 Narbik Kocharians. All rights reserved
 R3 can’t ping R1’s Lo0.

Let’s verify the configuration:

On R3:
R3#ping 5.100.99.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 5.100.99.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Let’s check R3’s routing table:

R3#show ip route 5.100.99.1

% Subnet not in table

Let’s enable “debug ip rip”:

R3#debug ip rip
RIP protocol debugging is on

RIP: received packet with MD5 authentication

RIP: ignored v2 packet from 5.100.157.1 (invalid authentication)

The problem is obvious. Let’s disable the deugging and correct this problem:

R3#undebug all
All possible debugging has been turned off

The only way to see this is to compare the configuration on all routers involved:

On R1:
R1#show run | s key chain

key chain TST

key 1
key-string ccie

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 20 of 24
© 2014 Narbik Kocharians. All rights reserved
R1#show run int e0/1 | b interface

interface FastEthernet0/1
ip address 5.100.157.1 255.255.255.0
ip rip authentication mode md5
ip rip authentication key-chain TST
end

R1#show run | i _ccie$

key-string ccie

The last command is entered to check for spaces after the password.

On R3:
R3#show run | s key chain

key chain TST

key 1
key-string ccie

R3#show run int e0/0 | b interface

interface FastEthernet0/0
ip address 5.100.157.3 255.255.255.0
ip rip authentication mode md5
ip rip authentication key-chain TST
end

R3#show run | i _ccie$

R3#

OK, we can see the problem, there must be a space after the password. Let’s correct this problem:

R3(config)#key chain TST

R3(config-keychain)#key 1
R3(config-keychain-key)#key-string ccie

To verify the problem:

On R3:
R3#show run | i _ccie$

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 21 of 24
© 2014 Narbik Kocharians. All rights reserved
 key-string ccie

To test the configuration:

On R3:
R3#ping 5.100.99.1

Type escape sequence to abort.

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

Ticket 7

R3 is configured to filter all routes received from R5, however, the routes are still there.
DO NOT use another method to fix this problem, correct the existing problem.

Let’s verify the problem:

On R3:
R3#show ip route rip | b Gate
Gateway of last resort is not set

5.0.0.0/8 is variably subnetted, 11 subnets, 2 masks

R 5.100.4.0/24 [120/2] via 5.100.157.5, 00:00:01, Ethernet0/0
R 5.100.15.0/24 [120/1] via 5.100.157.5, 00:00:01, Ethernet0/0
[120/1] via 5.100.157.1, 00:00:18, Ethernet0/0
R 5.100.99.1/32 [120/1] via 5.100.157.1, 00:00:18, Ethernet0/0
R 5.100.99.2/32 [120/2] via 5.100.157.5, 00:00:01, Ethernet0/0
R 5.100.99.4/32 [120/2] via 5.100.157.5, 00:00:01, Ethernet0/0
R 5.100.99.5/32 [120/1] via 5.100.157.5, 00:00:01, Ethernet0/0
R 5.100.212.0/24 [120/2] via 5.100.157.5, 00:00:01, Ethernet0/0
R 5.100.245.0/24 [120/1] via 5.100.157.5, 00:00:01, Ethernet0/0
192.168.4.0/32 is subnetted, 1 subnets
R 192.168.4.2 [120/1] via 5.100.157.1, 00:00:18, Ethernet0/0
R 192.168.211.0/24 [120/3] via 5.100.157.5, 00:00:01, Ethernet0/0
R 192.168.213.0/24 [120/3] via 5.100.157.5, 00:00:01, Ethernet0/0
R 192.168.215.0/24 [120/3] via 5.100.157.5, 00:00:01, Ethernet0/0

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 22 of 24
© 2014 Narbik Kocharians. All rights reserved
R 192.168.217.0/24 [120/3] via 5.100.157.5, 00:00:01, Ethernet0/0
R 192.168.219.0/24 [120/3] via 5.100.157.5, 00:00:01, Ethernet0/0

Sure enough we can see bunch of routes from R5, let’s see how R3 was configured to accomplish this
filtering:

R3#show ip protocol
*** IP Routing is NSF aware ***

Routing Protocol is "application"

Sending updates every 0 seconds
Invalid after 0 seconds, hold down 0, flushed after 0
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Maximum path: 32
Routing for Networks:
Routing Information Sources:
Gateway Distance Last Update
Distance: (default is 4)

Routing Protocol is "rip"

Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is 157
Sending updates every 30 seconds, next due in 6 seconds
Invalid after 180 seconds, hold down 180, flushed after 240
Redistributing: rip
Default version control: send version 2, receive version 2
Interface Send Recv Triggered RIP Key-chain
Ethernet0/0 2 2 TST
Loopback0 2 2
Automatic network summarization is not in effect
Maximum path: 4
Routing for Networks:
5.0.0.0
Routing Information Sources:
Gateway Distance Last Update
5.100.157.5 120 00:00:08
5.100.157.1 120 00:00:21
Distance: (default is 120)

Let’s verify the access-list:

R3#show access-list 157

Extended IP access list 157

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 23 of 24
© 2014 Narbik Kocharians. All rights reserved
 10 deny ip any host 5.100.157.5
20 permit ip any any (182 matches)

We can see a brave attempt to filter those routes using an extended ACL, but the ACL was misconfigured.
When using an extended ACL for filtering, the “SOURCE” section should be configured to reference the
advertising router, and the “DESTINATION” section of the access-list should be configured to reference
the actual route.

In R3’s configured ACL, the advertising router states “ANY” and the actual route is configured to be
5.100.157.5, these need to be swapped. Let’s configure R3 to correct this mistake:

On R3:
R3(config)#no access-list 157
R3(config)#access-list 157 deny ip host 5.100.157.5 any
R3(config)#access-list 157 permit ip any any

R3#clear ip route *

To verify the configuration:

On R3:
R3#show ip route | b Gate
Gateway of last resort is not set

5.0.0.0/8 is variably subnetted, 5 subnets, 2 masks

R 5.100.15.0/24 [120/1] via 5.100.157.1, 00:00:15, Ethernet0/0
R 5.100.99.1/32 [120/1] via 5.100.157.1, 00:00:15, Ethernet0/0
C 5.100.99.3/32 is directly connected, Loopback0
C 5.100.157.0/24 is directly connected, Ethernet0/0
L 5.100.157.3/32 is directly connected, Ethernet0/0
192.168.4.0/32 is subnetted, 1 subnets
R 192.168.4.2 [120/1] via 5.100.157.1, 00:00:15, Ethernet0/0

Much better.

Ticket 8

Erase the startup configuration and reload the devices before proceeding to the next
lab.

CCIE R&S by Narbik Kocharians Advanced CCIE R&S Troubleshooting v5.0 Page 24 of 24
© 2014 Narbik Kocharians. All rights reserved