Appendix F. Answers to Troubleshooting Exercises
Answer to Chapter 1 Troubleshooting Exercise
1 In Figure 1-17, router RTG has been added to the internetwork.
Figure 1-17 The Internetwork for Troubleshooting Exercise 1
Although it is peering with RTB and exchanging reachability information, there is a configuration error. Based on the information in Example 1-29, what is the error?
Example 1-29 The EGP Tables of RTB and RTG in Figure 1-17
Answer: The EGP configuration of RTG is router egp 65505 rather than router egp 65531.
Answers to Chapter 3 Troubleshooting Exercises
Figure 3-37 shows the internetwork diagram for Troubleshooting Exercises 1 through 6.
Figure 3-37 The Internetwork for Troubleshooting Exercises 1 through 6
1 Example 3-165 shows the BGP configuration of router R2 in Figure 3-37.
Example 3-165 BGP Configuration of Router R2
router bgp 10
no synchronization
network 0.0.0.0
neighbor 172.16.254.2 remote-as 10
neighbor 172.16.254.2 next-hop-self
neighbor 172.16.254.6 remote-as 10
neighbor 172.16.254.6 next-hop-self
no auto-summary
!
ip classless
ip route 0.0.0.0 0.0.0.0 Ethernet10
Example 3-166 shows the BGP table and routing table for R2. Although there are routes to the destinations in the autonomous systems shown in Figure 3-37, pings to those destinations fail. Why?
Example 3-166The BGP and Routing Tables of R2 in Figure 3-37
Answer: R2 has no routes to the next-hop addresses referenced in the BGP table. R1 and R3 must advertise routes to these addresses or use the neighbor next-hop-self command.
2. Example 3-167 shows debug output from routers R1 and R5 in Figure 3-37. What problem do the messages indicate?
Example 3-167 debug Output from R1 and R5 in Figure 3-37
R1#debug ip bgp
BGP debugging is on
R1#
BGP: 172.16.255.5 open active, local address 172.16.255.6
BGP: 172.16.255.5 sending OPEN, version 4
BGP: 172.16.255.5 received NOTIFICATION 2/2 (peer in wrong AS) 2 bytes 000A
BGP: 172.16.255.5 closing
__________________________________________________________________________
R5#
6d08h: BGP: 172.16.255.6 open active, delay 28272ms
6d08h: BGP: 172.16.255.6 open active, local address 172.16.255.5
6d08h: BGP: 172.16.255.6 sending OPEN, version 4
6d08h: BGP: 172.16.255.6 OPEN rcvd, version 4
6d08h: BGP: 172.16.255.6 bad OPEN, remote AS is 10, expected 30
6d08h: BGP: 172.16.255.6 sending NOTIFICATION 2/2 (peer in wrong AS) 2 bytes 000A
6d08h: BGP: 172.16.255.6 remote close, state CLOSEWAIT
6d08h: BGP: 172.16.255.6 closing
Answer: R5’s BGP configuration contains the statement neighbor 172.16.255.6 remote-as 30, when the statement should be neighbor 172.16.255.6 remote-as 10.
3 Example 3-168 shows the BGP tables of R1 and R3 in Figure 3-37. The first table indicates that 172.17.0.0/24 can be reached either via R6 (172.16.255.25) or R3 (172.16.254.9). Which path is R1 using, and why?
Example 3-168 BGP Tables from R1 and R3 in Figure 3-37
Answer:R1 is using the path through R6, because EBGP paths are preferred over IBGP paths.
4 Example 3-169 shows the BGP and IGP configurations for R1, R3, R6, and R7 in Figure 3-37.
Example 3-169 BGP and IGP Configurations for Routers R1, R3, R6, and R7
R1
router bgp 10
neighbor 172.16.254.1 remote-as 10
neighbor 172.16.254.1 next-hop-self
neighbor 172.16.254.9 remote-as 10
neighbor 172.16.254.9 next-hop-self
neighbor 172.16.255.5 remote-as 20
neighbor 172.16.255.9 remote-as 30
neighbor 172.16.255.25 remote-as 60
_________________________________________________________________________
R3
router bgp 10
neighbor 172.16.254.5 remote-as 10
neighbor 172.16.254.5 next-hop-self
neighbor 172.16.254.10 remote-as 10
neighbor 172.16.254.10 next-hop-self
neighbor 172.16.255.13 remote-as 40
neighbor 172.16.255.17 remote-as 50
neighbor 172.16.255.21 remote-as 60
neighbor 172.16.255.21 next-hop-self
_________________________________________________________________________
R6
router eigrp 60
redistribute bgp 60 metric 1000 100 255 1 1500
network 172.17.0.0
!
router bgp 60
network 172.17.0.0
neighbor 172.16.255.26 remote-as 10
_________________________________________________________________________
R7
router eigrp 60
redistribute bgp 60 metric 1000 100 255 1 1500
network 172.17.0.0
!
router bgp 60
network 172.17.0.0
neighbor 172.16.255.22 remote-as 10
Example 3-168 shows the BGP tables for R1 and R3. For each of the following destinations, what next-hop address does R6 use? Explain why R6 uses the addresses you name.
Destinations:
172.20.7.102
172.18.58.35
10.53.12.6
172.20.7.102: Next-hop 172.17.1.1
172.18.58.35: Next-hop 172.16.255.26
10.53.12.6: Packet is dropped
Neither R1 nor R3 has synchronization turned off. As a result, each advertises only the addresses it has learned from EBGP neighbors. R6 has learned 172.18.0.0/24 from R1, but R1 does not advertise 172.20.0.0/24, which it learned from an IBGP neighbor. R3 advertises that route to R7, which advertises it to R6 via EIGRP. Both R1 and R3 have learned the default route from IBGP neighbor R2, so neither router advertises the default.
5 Example 3-170 shows the BGP configurations for R1 and R3 in Figure 3-37.
Example 3-170 BGP Configurations for Routers R1 and R3
R1
router bgp 10
no synchronization
aggregate-address 172.16.0.0 255.255.248.0 summary-only
neighbor 172.16.254.1 remote-as 10
neighbor 172.16.254.1 next-hop-self
neighbor 172.16.254.9 remote-as 10
neighbor 172.16.254.9 next-hop-self
neighbor 172.16.255.5 remote-as 20
neighbor 172.16.255.9 remote-as 30
neighbor 172.16.255.25 remote-as 60
_______________________________________________________________________
R3
router bgp 10
no synchronization
aggregate-address 172.16.0.0 255.255.248.0 summary-only
neighbor 172.16.254.5 remote-as 10
neighbor 172.16.254.5 next-hop-self
neighbor 172.16.254.10 remote-as 10
neighbor 172.16.254.10 next-hop-self
neighbor 172.16.255.13 remote-as 40
neighbor 172.16.255.17 remote-as 50
neighbor 172.16.255.21 remote-as 60
neighbor 172.16.255.21 next-hop-self
The objective is to suppress all the more-specific routes and advertise only an aggregate. R8’s BGP table, in Example 3-171, still shows the more-specific routes. What is wrong?
Example 3-171The BGP Table of R8 in Figure 3-37
Answer: The mask specified in the aggregate-address command should be 255.248.0.0. The aggregate specified does not match anything in the routing tables of R1 or R3 and so is not advertised.
6 Packets from AS 60 destined for any of the other autonomous systems shown in Figure 3-37 should be forwarded across the link between R6 and R1. The link between R7 and R3 should be used only as a backup for this traffic, although packets destined for the Internet can still use this link. To implement this policy, R3 should advertise only the default route and the aggregate 172.16.0.0/13. R1 should advertise the more-specific routes. Example 3-172 shows the configurations for R1, R3, R6, and R7.
Example 3-172 Configurations for Routers R1, R3, R6, and R7
R1
router bgp 10
no synchronization
neighbor 172.16.254.1 remote-as 10
neighbor 172.16.254.1 next-hop-self
neighbor 172.16.254.9 remote-as 10
neighbor 172.16.254.9 next-hop-self
neighbor 172.16.255.5 remote-as 20
neighbor 172.16.255.9 remote-as 30
neighbor 172.16.255.25 remote-as 60
_________________________________________________________________________
R3
router bgp 10
no synchronization
aggregate-address 172.16.0.0 255.248.0.0 summary-only
neighbor 172.16.254.5 remote-as 10
neighbor 172.16.254.5 next-hop-self
neighbor 172.16.254.10 remote-as 10
neighbor 172.16.254.10 next-hop-self
neighbor 172.16.255.13 remote-as 40
neighbor 172.16.255.17 remote-as 50
neighbor 172.16.255.21 remote-as 60
neighbor 172.16.255.21 next-hop-self
_________________________________________________________________________
R6
redistribute bgp 60 metric 1000 100 255 1 1500
network 172.17.0.0
!
router bgp 60
network 172.17.0.0
neighbor 172.16.255.26 remote-as 10
_________________________________________________________________________
R7
router eigrp 60
redistribute bgp 60 metric 1000 100 255 1 1500
network 172.17.0.0
!
router bgp 60
network 172.17.0.0
neighbor 172.16.255.22 remote-as 10
Example 3-173 shows R7’s routing table. Has the objective been accomplished? If not, why not?
Example 3-173R7’s Routing Table for Troubleshooting Exercise 6
R7#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
T - traffic engineered route
Gateway of last resort is 172.16.255.22 to network 0.0.0.0
172.17.0.0/24 is subnetted, 3 subnets
C 172.17.1.0 is directly connected, Ethernet0
D 172.17.3.0 [90/409600] via 172.17.1.2, 09:18:50, Ethernet0
C 172.17.2.0 is directly connected, Ethernet1
172.16.0.0/30 is subnetted, 1 subnets
C 172.16.255.20 is directly connected, Serial0
D EX 172.19.0.0/16 [170/2611200] via 172.17.1.2, 00:19:08, Ethernet0
D EX 172.18.0.0/16 [170/2611200] via 172.17.1.2, 00:19:08, Ethernet0
B* 0.0.0.0/0 [20/0] via 172.16.255.22, 00:18:37
B 172.16.0.0/13 [20/0] via 172.16.255.22, 00:18:09
R7#
Answer: The objective has not been fully accomplished. The routes to 172.18.0.0/24 and 172.19.0.0/24 are correct, but the routes to 172.20.0.0 and 172.21.0.0/24 are not in the routing table. The aggregate-address command at R3 has suppressed the advertisement of more-specific routes not only to R3’s EBGP peers, but also to its IBGP peers. As a result, R1 does not know about 172.20.0.0/24 and 172.21.0.0/24.
7 Reexamine Figure 3-19 and Example 3-98 and the associated discussion. Meribel advertises its local route 172.17.0.0 to its EBGP peers with an ORIGIN of Incomplete, whereas Lillehammer advertises the route back to Meribel with an ORIGIN of IGP. Will this cause Meribel to prefer the route from Lillehammer, thereby causing a routing loop?
Answer: No. Although an ORIGIN of IGP takes precedence over an ORIGIN of Incomplete in the BGP decision process, administrative weight takes precedence over ORIGIN. By default, Meribel assigns a weight of 32768 to locally originated routes and a weight of 0 to learned routes, so the local route is preferred.
8 Example 3-174 shows the configuration for the router named Colorado in Figure 3-24.
Example 3-174 Configuration for Router Colorado in Figure 3-24
router bgp 100
network 10.1.11.0 mask 255.255.255.0
network 10.1.12.0 mask 255.255.255.0
neighbor CLIENTS peer-group
neighbor CLIENTS ebgp-multihop 2
neighbor CLIENTS update-source Loopback2
neighbor CLIENTS filter-list 2 in
neighbor CLIENTS filter-list 1 out
neighbor 10.1.255.2 remote-as 200
neighbor 10.1.255.2 peer-group CLIENTS
neighbor 10.1.255.3 remote-as 300
neighbor 10.1.255.3 peer-group CLIENTS
neighbor 10.1.255.4 remote-as 400
neighbor 10.1.255.4 peer-group CLIENTS
neighbor 10.1.255.5 remote-as 500
neighbor 10.1.255.5 peer-group CLIENTS
neighbor 10.1.255.6 remote-as 600
neighbor 10.1.255.6 peer-group CLIENTS
no auto-summary
!
ip classless
ip route 10.1.255.2 255.255.255.255 Serial0/1.305
ip route 10.1.255.3 255.255.255.255 Serial0/1.306
ip route 10.1.255.4 255.255.255.255 Serial0/1.307
ip route 10.1.255.5 255.255.255.255 Serial0/1.308
!
ip as-path access-list 1 permit ^$
ip as-path access-list 2 permit ^[2-6]00$
All router IDs shown in Figure 3-24 are configured on loopback interfaces, and no routing protocol other than BGP is running on any of the routers. Assuming that all the links shown in the figure are functioning properly, are all the other five routers EBGP peers of Colorado? If not, why not?
Answer: No. Router NewHampshire is not a peer, because there is no static route entry at Colorado for 10.1.255.6/32.
9 Refer to the configuration shown in Troubleshooting Exercise 8 for router Colorado in Figure 3-24. What will be the result of removing the no auto-summary statement from the configuration?
Answer: Removing the statement has no effect on the topology shown in Figure 3.82, because all the router IDs and all the addresses of all the autonomous systems are subnets of 10.0.0.0.
10 Refer again to the configuration shown in Troubleshooting Exercise 8. What routes does the incoming route filter permit?
Answer: The incoming route filter refers to AS_PATH list 2. The one line of that list permits any route whose AS_PATH meets the following criteria:
• The route’s AS_PATH consists of a single AS number.
• The decimal representation of the AS number must be three digits.
• The first digit must be a number between 2 and 6, inclusive.
• The second and third digits must be 0s.
11 Refer to Figure 3-24 and the configuration for router Colorado in Troubleshooting Exercise 8. What subnets, other than those local to its own AS or the inter-AS links, can a host on subnet 10.1.3.0/24 ping?
Answer: Only subnets 10.1.11.0/24, 10.1.12.0/24, and 10.1.255.1/32. The outgoing route filter at Colorado prevents its EBGP peers from learning of any routes other than local routes.
Answers to Chapter 4 Troubleshooting Exercises
1 Identify the mistake in the configuration in Example 4-33.
Example 4-33 Configuration for Troubleshooting Exercise 1
ip nat pool EX1 192.168.1.1 192.168.1.254 netmask 255.255.255.0 type match-host
ip nat pool EX1A netmask 255.255.255.240
address 172.21.1.33 172.21.1.38
address 172.21.1.40 172.21.1.46
ip nat inside source list 1 pool EX1
ip nat inside source static 10.18.53.210 192.168.1.1
ip nat outside source list 2 pool EX1A
!
access-list 1 permit 10.0.0.0 0.255.255.255
access-list 2 permit 192.168.2.0 0.0.0.255
Answer: The IG address in the static mapping overlaps with the pool EX1.
2 RTR1 in Figure 4-30 connects two internetworks with overlapping addresses.
Figure 4-30 The Internetwork for Troubleshooting Exercise 2
NAT is implemented on the router as configured in Example 4-34, but devices cannot communicate across the router. What is wrong?
Example 4-34 Configuration for Troubleshooting Exercise 2
interface Ethernet0
ip address 172.16.10.1 255.255.255.0
ip nat inside
!
interface Ethernet1
ip address 172.16.255.254 255.255.255.0
ip nat outside
!
router ospf 1
redistribute static metric 10 metric-type 1 subnets
network 10.0.0.0 0.255.255.255 area 0
!
ip nat translation timeout 500
ip nat pool NET1 10.1.1.1 10.1.255.254 netmask 255.255.0.0
ip nat pool NET2 192.168.1.1 192.168.255.254 netmask 255.255.0.0
ip nat inside source list 1 pool NET1
ip nat outside source list 1 pool NET2
!
ip classless
!
ip route 10.1.0.0 255.255.0.0 Ethernet0
ip route 192.168.0.0 255.255.0.0 Ethernet1
!
access-list 1 permit 172.16.0.0 0.0.255.255
Answer:The problem is not with the NAT itself, but with routing. All translations are dynamic, and there is no way for a host on either side to determine the initial address to which packets must be sent to reach the other side.
3 Refer to the configurations of Cozumel and Guaymas in Figure 4-21. If the first line of access list 1 in both configurations is removed, what is the result? Can Guaymas and Cozumel still ping each other?
Answer: When either router sends a packet to the other sourced from its E1 interface, the source address is translated to an address out of the IG pool. The two routers can still ping each other even if the source address is translated. If Cozumel pings Guaymas, for example, its source address of 10.255.13.254 might be translated to 206.100.176.50. Although Guaymas does not recognize this address as part of its directly connected subnet, it has a route to 206.100.176.0/20 pointing to Cozumel. When it sends a response to the ping, the response is forwarded to Cozumel, which translates the destination address back to 10.255.13.254.
Answers to Chapter 6 Troubleshooting Exercises
1 What is the output of Example 6-63 telling you?
Example 6-63 The Output for Troubleshooting Exercise 1
R1#
Turban#debug ip mpacket
IP multicast packets debugging is on
R1#
IP: s=192.168.14.35 (Serial0/1.307) d=228.13.20.216 len 573, mrouting disabled
IP: s=192.168.14.35 (Serial0/1.307) d=228.13.20.216 len 573, mrouting disabled
IP: s=192.168.14.35 (Serial0/1.307) d=228.13.20.216 len 573, mrouting disabled
IP: s=192.168.14.35 (Serial0/1.307) d=228.13.20.216 len 573, mrouting disabled
IP: s=192.168.14.35 (Serial0/1.307) d=228.13.20.216 len 573, mrouting disabled
IP: s=192.168.14.35 (Serial0/1.307) d=228.13.20.216 len 573, mrouting disabled
IP: s=192.168.14.35 (Serial0/1.307) d=228.13.20.216 len 573, mrouting disabled
IP: s=192.168.14.35 (Serial0/1.307) d=228.13.20.216 len 573, mrouting disabled
IP: s=192.168.14.35 (Serial0/1.307) d=228.13.20.216 len 573, mrouting disabled
IP: s=192.168.14.35 (Serial0/1.307) d=228.13.20.216 len 573, mrouting disabled
IP: s=192.168.14.35 (Serial0/1.307) d=228.13.20.216 len 573, mrouting disabled
IP: s=192.168.14.35 (Serial0/1.307) d=228.13.20.216 len 573, mrouting disabled
IP: s=192.168.14.35 (Serial0/1.307) d=228.13.20.216 len 573, mrouting disabled
Answer: Multicast packets are being dropped because multicast routing is not enabled on the router.
2 What is the output of Example 6-64 telling you?
Example 6-64 The Output for Troubleshooting Exercise 2
R2#
IP: s=192.168.13.5 (Ethernet0) d=227.134.14.26 len 583, not RPF interface
IP: s=192.168.13.5 (Ethernet0) d=227.134.14.26 len 583, not RPF interface
IP: s=192.168.13.5 (Ethernet0) d=227.134.14.26 len 583, not RPF interface
IP: s=192.168.13.5 (Ethernet0) d=227.134.14.26 len 583, not RPF interface
IP: s=192.168.13.5 (Ethernet0) d=227.134.14.26 len 583, not RPF interface
IP: s=192.168.13.5 (Ethernet0) d=227.134.14.26 len 583, not RPF interface
IP: s=192.168.13.5 (Ethernet0) d=227.134.14.26 len 583, not RPF interface
IP: s=192.168.13.5 (Ethernet0) d=227.134.14.26 len 583, not RPF interface
IP: s=192.168.13.5 (Ethernet0) d=227.134.14.26 len 583, not RPF interface
Answer: Packets for group 227.134.14.26, sourced by 192.168.13.5, are being received on interface E0. This interface is apparently not the upstream interface toward the source, however. Therefore, it is not the RPF interface, and the packets are failing the RPF check and are being dropped.
3 What is the output of Example 6-65 telling you?
Example 6-65 The Output for Troubleshooting Exercise 3
R3#debug ip mpacket
IP multicast packets debugging is on
R3#
IP: s=172.16.3.50 (Serial0.405) d=224.0.1.40 (Serial0.407) len 52, mforward
IP: s=172.16.3.50 (Ethernet0) d=224.0.1.40 len 62, not RPF interface
IP: s=172.16.3.50 (Ethernet0) d=224.0.1.39 len 62, not RPF interface
IP: s=172.16.3.50 (Serial0.405) d=224.0.1.39 (Serial0.407) len 52, mforward
Answer: A router at address 172.16.3.50 is both a C-RP (224.0.1.39) and a mapping agent (224.0.1.40). The Auto-RP messages are being received on interface S0.405 and are being forwarded out interface S0.407. The messages also are being received on interface E0 and are failing the RPF check. Therefore, interface S0.405 is the upstream interface to 172.16.3.50.
4 In Figure 6-12, which of the four routers is the PIM-designated router?
Figure 6-12 The Topology for Troubleshooting Exercises 4, 5, and 6
Answer: The PIM DR is the router with the highest IP address. Therefore, RT4 is the PIM DR.
5 In Figure 6-12, which router is sending IGMPv2 queries to the group member?
Answer: The IGMPv2 querier is the router with the lowest IP address. Therefore, RT2 is the querier.
6 Table 6-5 shows the unicast routes to source 172.16.12.18 in Figure 6-12. Which router is the PIM forwarder?
Table 6-5 Unicast Routes to 172.16.12.18 in Figure 6-12
Answer: The PIM forwarder is the router with the lowest administrative distance. Given equal administrative distances, the forwarder is the router with the lowest metric. The administrative distance of EIGRP is 90, and the distance of OSPF is 110, so EIGRP is lower. Between the two EIGRP routes, R2’s route has a lower metric, so R2 is the PIM forwarder.
7 Example 6-66 shows an RPF trace taken from the PIM domain in Figure 6-10, which is running RIP-2 as its unicast IGP. Does this trace indicate a possible problem?
Example 6-66 The mtrace for Troubleshooting Exercise 7
Sombrero#mtrace 192.168.14.35 192.168.10.8 235.1.2.3
Type escape sequence to abort.
Mtrace from 192.168.14.35 to 192.168.10.8 via group 235.1.2.3
From source (?) to destination (?)
Querying full reverse path...
0 192.168.10.8
-1 192.168.10.1 PIM [192.168.14.0/24]
-2 192.168.200.2 PIM [192.168.14.0/24]
-3 192.168.201.2 PIM [192.168.14.0/24]
-4 192.168.204.1 PIM [192.168.14.0/24]
-5 192.168.14.35
Sombrero#
Answer: Yes. There are equal-cost paths between Beret and Boater via either Turban or Fez. Beret can have only one RPF neighbor, so it picks the neighbor with the highest IP address. In this case, Turban has the highest IP address, but the trace shows that the path through Fez is used. Therefore, there is an apparent problem between Beret and Turban.