|
Example 3-168 BGP Tables from R1 and R3 in Figure 3-37 (Continued)
R3#show lp bgp
BGP table version is 5, local router ID is 172.16.255.22
Status codes: s suppressed, d damped, h history valid, best i internal
R3#show lp bgp
BGP table version is 5, local router ID is 172.16.255.22
Status codes: s suppressed, d damped, h history valid, best i internal
|
Origin codes: i
|
IGP e EGP
|
|
incomplete
|
|
|
|
|
Network
|
Next Hop
|
|
Metrjfcp
|
LocPrf Weight
|
Path
|
|
10.0.0.0
|
172.16.254,
|
,5
|
0
|
100
|
0
|
l
|
|
1172.17.0.0
|
172.16.254
|
10
|
0
|
100
|
0
|
60 l
|
|
*>
|
172.16.255,
|
.21
|
0
|
|
0
|
60 l
|
|
1172.18.0.0
|
172.16.254
|
10
|
0
|
100
|
0
|
30 l
|
|
1172.19.0.0
|
172.16.254
|
10
|
0
|
100
|
0
|
20 l
|
|
*> 172.20.0.0
|
172.16.255.
|
,13
|
0
|
|
0
|
40 l
|
|
*> 172.21.0.0
|
172.16.255.
|
,17
|
0
|
|
0
|
50 l
|
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 Rl, R3, R6, and R7 in Figure 3-37
Example 3-169 BGP and IGP Configurations for Routers Rl, R3, R6, and R7 Rl 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
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
router eigrp 60 redistribute bgp 60 metric 1000 100 255 1 1500 network 172.17.0.0
Example 3 169 BGP and IGP Configurations for Routers R1 R3 R6 and R7 (Continued) i router bgp 60 network 172 17 0 0 neighbor 172 16 255 26 remote as 10
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
Answer:
172 20 7 102: Next hop 172 17 11 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
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
Example 3-170 BGP Configurations for Routers R1 andR3 (Continued)
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
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-171 The BGP Table ofR8 in Figure 3-37
|
R8#show îp bgp
|
|
|
|
|
BGP table version is 163, local router ID is 172.21 1 1
|
|
|
Status codes, s
|
suppressed, valid.
|
, best internal
|
|
|
Origin codes, i
|
IGP e EGP
|
incomplete
|
|
|
Network
|
Next Hop
|
Metric LocPrf Weight
|
Path
|
|
*> 0.0.0.0
|
172.16.255.18
|
0
|
10 1
|
|
*> 172.17.0.0
|
172.16.255.18
|
0
|
10 60 l
|
|
*> 172.18.0.0
|
172.16.255.18
|
0
|
10 30
|
|
*> 172.19.0.0
|
172.16.255.18
|
0
|
10 20
|
|
*> 172.20.0.0
|
172.16.255.18
|
0
|
10 40
|
|
*> 172.21.0.0
|
0.0.0.0
|
0 32768
|
|
|
R8#
|
|
|
|
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 andR7
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
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
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
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-173 R7's Routing Table for Troubleshooting Exercise 6
R7#show lp route
Codes. C connected, S static, I IGRP R RIP EIGRP EX EIGRP external, 0 OSPF IA
D N1 E1
M mobile, B BGP OSPF inter area
OSPF NSSA external type 1 OSPF external type 1 E2 IS-IS, L1 IS-IS level 1 per-user static route, o traffic engineered route
N2 Q$PF NSSA external type 2 OSPF external type 2, E EGP L2 IS-IS level 2, candidate default 0DR
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, Ethernet©
D 172.17.3.0 [90/409600] via 172.17 1.2, 09"18:50, Ethernet©
C 172.17.2.0 is directly connected, Ethernetl
172.16.0.0/30 is subnetted, 1 subnets C 172.16.255.20 is directly connected, Serial©
D EX 172.19.0.0/16 [170/2611200] via 172.17 1.2, 00:19:08, Ethernet© D EX 172.18.0.0/16 [170/2611200] via 172.17 1.2, 00:19:08, Ethernet© 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 m 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 i ip classless ip route 10 1 255 2 255 255 255 255 SerialO/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 i 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 ASoiumber 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 ping4?
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 m Figure 4-30 connects two internetworks with overlapping addresses.
Figure 4 30 The Internetwork for Troubleshooting Exercise 2
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 EthernetO
|
|
|
ip address 172 16 10 1 255 255 255 0
|
■
|
|
|
interface Ethernetl
|
|
|
ip address 172 16 255 254 255 255 255 0
|
|
|
ip nat outside i
|
|
|
router ospf 1
|
|
|
redistribute static metric 10 metric type 1 subnets
|
|
|
network 10 0 0 0 0 255 255 255 area 0
i
|
|
|
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 i
|
|
|
i ip classless i
|
|
|
ip route 10 1 0 0 255 255 0 0 EthernetO
|
|
|
ip route 192 168 0 0 255 255 0 0 Ethernetl i
|
|
|
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 El 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
|
