Senior Acquisitions Editor: Kenyon Brown Development Editor: Kim Wimpsett
Yüklə 22,5 Mb. Pdf görüntüsü
|
|
Unequal-Cost Load Balancing As with all routing protocols running on Cisco routers, EIGRP automatically supports load balancing over four equal-cost routes and can be configured to support up to 32 equal-cost paths with IOS 15.0 code. As you know, previous IOS versions supported up to 16. I’ve mentioned this a few times in this chapter already, but I want to show you how to configure unequal-cost load balancing with EIGRP. First let’s take a look at the Corp router by typing in the show ip protocols command:
Corp# sh ip protocols Routing Protocol is "eigrp 20" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates Default networks accepted from incoming updates EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0 EIGRP maximum hopcount 100 EIGRP maximum metric variance 1 Redistributing: eigrp 20 EIGRP NSF-aware route hold timer is 240s Automatic network summarization is not in effect Maximum path: 4 Routing for Networks: 10.0.0.0 172.16.0.0 Routing Information Sources: Gateway Distance Last Update (this router) 90 19:15:10 172.16.10.6 90 00:25:38 172.16.10.2 90 00:25:38 Distance: internal 90 external 170 The variance 1 means equal-path load balancing with the maximum paths set to 4 by default. Unlike most other protocols, EIGRP also supports unequal-cost load balancing through the use of the variance
parameter. To clarify, let’s say the parameter has been set to a variance of 2. This would effectively load-balance traffic across the best route plus any route with a feasible distance of up to twice as large. But still keep in mind that load balancing occurs in proportion with and relative to the cost of the route, meaning that more traffic would travel across the best route than the suboptimal one. Let’s configure the variance on the Corp router and see if we can load- balance across our feasible successors now: Corp#
config t Corp(config)# router eigrp 20 Corp(config-router)# variance 2 Corp(config-router)# *Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route installed for 10.10.20.0 *Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route installed for 10.10.20.0 *Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route installed for 10.10.30.0 *Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route installed for 10.10.30.0 *Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route installed for 10.10.40.0 *Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route installed for 10.10.40.0 *Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route installed for 10.10.50.0 *Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route installed for 10.10.50.0 *Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route installed for 192.168.10.0 *Feb 26 22:24:24:IP-EIGRP(Default-IP-Routing-Table:20):route
installed for 192.168.10.0 Corp(config-router)# do show ip route [output cut] D 192.168.10.0/24 [90/2172416] via 172.16.10.6, 00:00:18, Serial0/1 [90/2172416] via 172.16.10.2, 00:00:18, Serial0/0 172.16.0.0/30 is subnetted, 2 subnets C 172.16.10.4 is directly connected, Serial0/1 C 172.16.10.0 is directly connected, Serial0/0 10.0.0.0/24 is subnetted, 6 subnets C 10.10.10.0 is directly connected, GigabitEthernet0/0 C 10.10.11.0 is directly connected, GigabitEthernet0/1 D 10.10.20.0 [90/2300416] via 172.16.10.6, 00:00:18, Serial0/1 [90/2297856] via 172.16.10.2, 00:00:19, Serial0/0 D 10.10.30.0 [90/2300416] via 172.16.10.6, 00:00:19, Serial0/1 [90/2297856] via 172.16.10.2, 00:00:19, Serial0/0 D 10.10.40.0 [90/2297856] via 172.16.10.6, 00:00:19, Serial0/1 [90/2300416] via 172.16.10.2, 00:00:19, Serial0/0 D 10.10.50.0 [90/2297856] via 172.16.10.6, 00:00:20, Serial0/1 [90/2300416] via 172.16.10.2, 00:00:20, Serial0/0 Corp(config-router)# Nice—it worked! Now we have two paths to each remote network in the routing table, even though the feasible distances to each route aren’t equal. Don’t forget that unequal load balancing is not enabled by default and that you can perform load balancing through paths that have up to 128 times worse metrics than the successor route! Split Horizon Split horizon is enabled on interfaces by default, which means that if a route update is received on an interface from a neighbor router, this interface will not advertise those networks back out to the neighbor router who sent them. Let’s take a look at an interface and then go through an example: Corp#
Serial0/0 is up, line protocol is up Internet address is 172.16.10.1/24 Broadcast address is 255.255.255.255 Address determined by setup command MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Multicast reserved groups joined: 224.0.0.10 Outgoing access list is not set Inbound access list is not set Proxy ARP is enabled Local Proxy ARP is disabled Security level is default Split horizon is enabled [output cut] Okay—we can see that split horizon is enabled by default. But what does this really mean? Most of the time it’s more helpful than harmful, but let’s check out our internetwork in Figure 17.8 so I can really explain what split horizon is doing. Notice that the SF and NY routers are each advertising their routes to the Corp router. Now, let’s see what the Corp router sends back to each router in Figure 17.9 . Can you see that the Corp router is not advertising back out the advertised networks that it received on each interface? This is saving the SF and NY routers from receiving the incorrect route information that they could possibly get to their own network through the Corp router, which we know is wrong. FIGURE 17.8 Split horizon in action, part 1 FIGURE 17.9 Split horizon in action, part 2 So how can this cause a problem? After all, it seems reasonable not to send misinformation back to an originating router, right? You’ll see this create a problem on point-to-multipoint links, such as Frame Relay, when multiple remote routers connect to a single interface at the Corp location. We can use logical interfaces, called subinterfaces, which I’ll tell
you all about in Chapter 21, “Wide Area Networks,” to solve the split horizon issue on a point-to-multipoint interface. Verifying and Troubleshooting EIGRP Even though EIGRP usually runs smoothly and is relatively low maintenance, there are several commands you need to memorize for using on a router that can be super helpful when troubleshooting EIGRP! I’ve already shown you a few of them, but I’m going to demonstrate all the tools you’ll need to verify and troubleshoot EIGRP now. Table 17.2 contains all of the commands you need to know for verifying that EIGRP is functioning well and offers a brief description of what each command does.
TABLE 17.2 EIGRP troubleshooting commands Command Description/Function show ip
eigrp neighbors Shows all EIGRP neighbors, their IP addresses, and the retransmit interval and queue counts for the adjacent routers show ip
eigrp interfaces Lists the interfaces on which the router has actually enabled EIGRP show ip route eigrp Shows EIGRP entries in the routing table show ip
eigrp topology
Shows entries in the EIGRP topology table show ip
eigrp traffic
Shows the packet count for EIGRP packets sent and received
show ip protocols Shows information about the active protocol sessions When troubleshooting an EIGRP problem, it’s always a good idea to start by getting an accurate map of the network, and the best way to do that is by using the show ip eigrp neighbors command to find out who your directly connected neighbors are. This command shows all adjacent routers that share route information within a given AS. If neighbors are missing, check the configuration, AS number, and link status on both routers to verify that the protocol has been configured correctly. Let’s execute the command on the Corp router: Corp#
sh ip eigrp neighbors IP-EIGRP neighbors for process 20 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num
1 172.16.10.2 Se0/0 11 03:54:25 1 200 0 127 0 172.16.10.6 Se0/1 11 04:14:47 1 200 0 2010 Here’s a breakdown of the important information we can see in the preceding output: H indicates the order in which the neighbor was discovered. Hold time in seconds is how long this router will wait for a Hello packet to arrive from a specific neighbor. The Uptime value indicates how long the neighbor relationship has been established. The SRTT field is the smooth round-trip timer and represents how long it takes to complete a round-trip from this router to its neighbor and back. This value delimits how long to wait after a multicast for a reply from this neighbor. As mentioned earlier, the router will attempt to establish communication via unicasts if it doesn’t receive a reply. The time between multicast attempts is specified by the Retransmission Time Out (RTO) field, which is based upon the SRTT values. The Q value tells us if there are any outstanding messages in the queue. We can make a mental note that there’s a problem if we see consistently large values here! Finally, the Seq field shows the sequence number of the last update from that neighbor, which is used to maintain synchronization and avoid duplicate messages or their out-of-sequence processing. The
neighbors command is a great command, but we can get local status of our router by also using the show ip eigrp interface command like
this: Corp#
sh ip eigrp interfaces IP-EIGRP interfaces for process 20 Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes Gi0/0 0 0/0 0 0/1 0 0 Se0/1 1 0/0 1 0/15 50 0 Se0/0 1 0/0 1 0/15 50 0 Gi0/1 0 0/0 0 0/1 0 0 Corp#
sh ip eigrp interface detail s0/0 IP-EIGRP interfaces for process 20 Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes Se0/0 1 0/0 1 0/15 50 0 Hello interval is 5 sec Next xmit serial Un/reliable mcasts: 0/0 Un/reliable ucasts: 21/26 Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 9 Retransmissions sent: 0 Out-of-sequence rcvd: 0 Authentication mode is not set The first command, show ip eigrp interfaces , lists all interfaces for which EIGRP is enabled as well as those the router is currently sending Hello messages to in an attempt to find new EIGRP neighbors. The show ip eigrp interface detail interface command lists more details per interface, including the local router’s own Hello interval. Understand that you can use these commands to verify that all your interfaces are within the AS process used by EIGRP, but also note that the passive interfaces won’t show up in these outputs. So be sure to also check to see if an interface has been configured as passive if is not present in the outputs. Okay, if all neighbors are present, then verify the routes learned. By executing the show ip route eigrp command, you’re given a quick picture of the routes in the routing table. If a certain route doesn’t appear in the routing table, you need to verify its source. If the source is functioning properly, then check the topology table. The routing table according to Corp looks like this: D 192.168.10.0/24 [90/2172416] via 172.16.10.6, 02:29:09, Serial0/1 [90/2172416] via 172.16.10.2, 02:29:09, Serial0/0 172.16.0.0/30 is subnetted, 2 subnets C 172.16.10.4 is directly connected, Serial0/1 C 172.16.10.0 is directly connected, Serial0/0 10.0.0.0/24 is subnetted, 6 subnets C 10.10.10.0 is directly connected, Loopback0 C 10.10.11.0 is directly connected, Loopback1 D 10.10.20.0 [90/2300416] via 172.16.10.6, 02:29:09, Serial0/1 [90/2297856] via 172.16.10.2, 02:29:10, Serial0/0 D 10.10.30.0 [90/2300416] via 172.16.10.6, 02:29:10, Serial0/1 [90/2297856] via 172.16.10.2, 02:29:10, Serial0/0 D 10.10.40.0 [90/2297856] via 172.16.10.6, 02:29:10, Serial0/1 [90/2300416] via 172.16.10.2, 02:29:10, Serial0/0 D 10.10.50.0 [90/2297856] via 172.16.10.6, 02:29:11, Serial0/1 [90/2300416] via 172.16.10.2, 02:29:11, Serial0/0 You can see here that most EIGRP routes are referenced with a D and that their administrative distance is 90. Remember that the [90/2300416] represents AD/FD, and in the preceding output, EIGRP is performing equal- and unequal-cost load balancing between two links to our remote networks. We can see this by looking closer at two different networks. Pay special attention to the FD of each output: Corp#
D 192.168.10.0/24 [90/2172416] via 172.16.10.6, 01:15:44, Serial0/1 [90/2172416] via 172.16.10.2, 01:15:44, Serial0/0
The preceding output shows equal-cost load balancing, and here’s our unequal-cost load balancing in action: Corp#
D 10.10.50.0 [90/2297856] via 172.16.10.6, 01:16:16, Serial0/1 [90/2300416] via 172.16.10.2, 01:16:16, Serial0/0 We can get the topology table displayed for us via the show ip eigrp topology
command. If the route is in the topology table but not in the routing table, it’s a pretty safe assumption that there’s a problem between the topology database and the routing table. After all, there must be a good reason the topology database isn’t adding the route into the routing table, right? We discussed this issue in detail earlier in the chapter, and it’s oh so important! Corp’s topology table looks like this: P 10.10.10.0/24, 1 successors, FD is 128256 via Connected, GigabitEthernet0/0 P 10.10.11.0/24, 1 successors, FD is 128256 via Connected, GigabitEthernet0/1 P 10.10.20.0/24, 1 successors, FD is 2297856 via 172.16.10.2 (2297856/128256), Serial0/0 via 172.16.10.6 (2300416/156160), Serial0/1 P 10.10.30.0/24, 1 successors, FD is 2297856 via 172.16.10.2 (2297856/128256), Serial0/0 via 172.16.10.6 (2300416/156160), Serial0/1 P 10.10.40.0/24, 1 successors, FD is 2297856 via 172.16.10.6 (2297856/128256), Serial0/1 via 172.16.10.2 (2300416/156160), Serial0/0 P 10.10.50.0/24, 1 successors, FD is 2297856 via 172.16.10.6 (2297856/128256), Serial0/1 via 172.16.10.2 (2300416/156160), Serial0/0 P 192.168.10.0/24, 2 successors, FD is 2172416 via 172.16.10.2 (2172416/28160), Serial0/0 via 172.16.10.6 (2172416/28160), Serial0/1 P 172.16.10.4/30, 1 successors, FD is 2169856 via Connected, Serial0/1 P 172.16.10.0/30, 1 successors, FD is 2169856 via Connected, Serial0/0 Notice that every route in this output is preceded by a P, which shows that these routes are in a passive state. This is good because routes in the active state indicate that the router has lost its path to this network and is searching for a replacement. Each entry also reveals the feasible distance, or FD, to each remote network as well as the next-hop neighbor through which packets will travel to this destination. Each entry also has two numbers in brackets, with the first indicating the feasible distance and the second, the advertised distance to a remote network. Again, here’s our equal- and unequal-cost load-balancing output shown in the topology table: Corp#
P 192.168.10.0/24, 2 successors, FD is 2172416 via 172.16.10.2 (2172416/28160), Serial0/0 via 172.16.10.6 (2172416/28160), Serial0/1 The preceding output shows equal-cost load balancing, and here is our unequal-cost load balancing in action: Corp#
P 10.10.50.0/24, 1 successors, FD is 2297856 via 172.16.10.6 (2297856/128256), Serial0/1 via 172.16.10.2 (2300416/156160), Serial0/0 The command show ip eigrp traffic enables us to see if updates are being sent. If the counters for EIGRP input and output packets don’t increase, it means that no EIGRP information is being sent between peers. The following output indicates that the Corp router is experiencing normal traffic: Corp#
show ip eigrp traffic IP-EIGRP Traffic Statistics for process 200 Hellos sent/received: 2208/2310 Updates sent/received: 184/183 Queries sent/received: 17/4 Replies sent/received: 4/18 Acks sent/received: 62/65 Input queue high water mark 2, 0 drops All of the packet types I talked about in the section on RTP are represented in the output of this command. And we can’t forget the always useful troubleshooting command show ip protocols . Here’s the output the Corp router gives us after using it: Routing Protocol is
Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates Default networks accepted from incoming updates
EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0 EIGRP maximum hopcount 100 EIGRP maximum metric
Redistributing: eigrp 20 EIGRP NSF-aware route hold timer is 240s
Maximum path: 4 Routing for Networks: 10.0.0.0 172.16.0.0 Routing Information Sources: Gateway Distance Last Update (this router) 90 04:23:51 172.16.10.6 90 02:30:48 172.16.10.2 90 02:30:48 Distance: internal 90 external 170 In this output, we can see that EIGRP is enabled for autonomous system 20 and that the K values are set to their defaults. The variance is 2, so both equal- and unequal-cost load balancing is happening here. Automatic summarization has been turned off. We can also see that EIGRP is advertising two classful networks and that it sees two neighbors. The
show ip eigrp events command displays a log of every EIGRP event: when routes are injected and removed from the routing table and when EIGRP adjacencies are reset or fail. This information is so helpful in determining if there are routing instabilities in the network! Be advised that this command can result in quite a flood of information even for really simple configurations like ours. To demonstrate, here’s the output the Corp router divulged after I used it: Corp#
Event information for AS 20: 1 22:24:24.258 Metric set: 172.16.10.0/30 2169856 2 22:24:24.258 FC sat rdbmet/succmet: 2169856 0 3 22:24:24.258 FC sat nh/ndbmet: 0.0.0.0 2169856 4 22:24:24.258 Find FS: 172.16.10.0/30 2169856 5 22:24:24.258 Metric set: 172.16.10.4/30 2169856 6 22:24:24.258 FC sat rdbmet/succmet: 2169856 0 7 22:24:24.258 FC sat nh/ndbmet: 0.0.0.0 2169856 8 22:24:24.258 Find FS: 172.16.10.4/30 2169856 9 22:24:24.258 Metric set: 192.168.10.0/24 2172416 10 22:24:24.258 Route install: 192.168.10.0/24 172.16.10.2 11 22:24:24.258 Route install: 192.168.10.0/24 172.16.10.6 12 22:24:24.254 FC sat rdbmet/succmet: 2172416 28160 13 22:24:24.254 FC sat nh/ndbmet: 172.16.10.6 2172416
14 22:24:24.254 Find FS: 192.168.10.0/24 2172416 15 22:24:24.254 Metric set: 10.10.50.0/24 2297856 16 22:24:24.254 Route install: 10.10.50.0/24 172.16.10.6 17 22:24:24.254 FC sat rdbmet/succmet: 2297856 128256 18 22:24:24.254 FC sat nh/ndbmet: 172.16.10.6 2297856 19 22:24:24.254 Find FS: 10.10.50.0/24 2297856 20 22:24:24.254 Metric set: 10.10.40.0/24 2297856 21 22:24:24.254 Route install: 10.10.40.0/24 172.16.10.6 22 22:24:24.250 FC sat rdbmet/succmet: 2297856 128256 --More--
Troubleshooting Example with EIGRP Throughout this chapter I’ve covered many of the problems that commonly occur with EIGRP and how to verify and troubleshoot these issues. Make sure you clearly understand what I have shown you so far in this chapter so you’re prepared to answer any question the Cisco exam could possibly throw at you! Just to make sure you’re solidly armed with all the skills you need to ace the exam as well as successfully administer a network, I’m going to provide even more examples about verifying EIGRP. We’ll be dealing with mostly the same commands and problems we’ve already covered, but this is so important, and the best way to get this all nailed down is to practice troubleshooting an EIGRP network as much as possible! With that, after you’ve configured EIGRP, you would first test connectivity to the remote network by using the Ping program. If that fails, you need to check whether the directly connected router is in the neighbor table. Here are some key things to look for if neighbors haven’t formed an adjacency: Interfaces between the devices are down. The two routers have mismatching EIGRP autonomous system numbers. Proper interfaces are not enabled for the EIGRP process. An interface is configured as passive. The K values are mismatched. EIGRP authentication is misconfigured.
Also, if the adjacency is up but you’re not receiving remote network updates, there may be a routing problem, likely caused by these issues: The proper networks aren’t being advertised under the EIGRP process.
An access list is blocking the advertisements from remote networks. Automatic summary is causing confusion in your discontiguous network. Let’s use Figure 17.10 as our example network and run through some troubleshooting scenarios. I’ve preconfigured the routers with IP addresses, and without having to try too hard, I also snuck in a few snags for us to find and fix. Let’s see what we’re facing.
Troubleshooting scenario A good place to start is by checking to see if we have an adjacency with show ip eigrp neighbors and show ip eigrp interfaces . It’s also smart to see what information the show ip eigrp topology command reveals: Corp#
IP-EIGRP neighbors for process 20 Corp# Corp#
sh ip eigrp interfaces IP-EIGRP interfaces for process 20 Xmit Queue Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable SRTT Un/Reliable Flow Timer Routes Se0/1 0 0/0 0 0/15 50 0 Fa0/0 0 0/0 0 0/1 0 0 Se0/0 0 0/0 0 0/15 50 0 Corp#
sh ip eigrp top IP-EIGRP Topology Table for AS(20)/ID(10.10.11.1) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status P 10.1.1.0/24, 1 successors, FD is 28160 via Connected, FastEthernet0/0 Alright—we can see by looking at the neighbor and the interface as well as the topology table command that our LAN is up on the Corp router but the serial link isn’t working between routers because we don’t have an adjacency. From the show ip eigrp interfaces command, we can establish that EIGRP is running on all interfaces, so that means our network statements under the EIGRP process are probably correct, but we’ll verify that later. Let’s move on by checking into our Physical and Data Link status with the show ip int brief command because maybe there’s a physical problem between routers: Corp#
Interface IP-Address OK? Method Status Protocol FastEthernet0/0 10.1.1.1 YES manual up up Serial0/0 192.168.1.1 YES manual up up FastEthernet0/1 unassigned YES manual administratively down down Serial0/1 172.16.10.5 YES manual administratively down down Corp#
Corp# sh protocols s0/0 Serial0/0 is up, line protocol is up Internet address is 192.168.1.1/30 Well, since the Serial0/0 interface shows the correct IP address and the status is up/up, it means we have a good Data Link connection between routers, so it’s not a physical link issue between the routers, which is good! Notice I also used the show protocols command, which gave me the subnet mask for the link. Remember, the information obtained via the two commands gives us only layer 1 and layer 2 status and doesn’t mean we can ping across the link. In other words, we might have a layer 3 issue, so let’s check the Branch router with the same commands: Branch#
sh ip int brief Interface IP-Address OK? Method Status Protocol FastEthernet0/0 10.2.2.2 YES manual up up FastEthernet0/1 unassigned YES manual administratively down down Serial0/0/0 192.168.1.2 YES manual up up Serial0/0/1 unassigned YES unset administratively down down Branch#
sh proto s0/0/0 Serial0/0/0 is up, line protocol is up Internet address is 192.168.1.2/30 Okay, well, we can see that our IP address and mask are correct, and that the link shows up/up, so we’re looking pretty good! Let’s try to ping from the Corp router to the Branch router now: Corp#
Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms Now because that was successful, we’ve ruled out layer 1, 2, or 3 issues between routers at this point! Since everything seems to be working between the routers, except EIGRP, checking our EIGRP configurations is our next move. Let’s start with the show ip
protocols command:
Corp# sh ip protocols Routing Protocol is "eigrp 20" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates Default networks accepted from incoming updates EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0 EIGRP maximum hopcount 100 EIGRP maximum metric variance 2 Redistributing: eigrp 20 EIGRP NSF-aware route hold timer is 240s Automatic network summarization is in effect Maximum path: 4 Routing for Networks: 10.0.0.0 172.16.0.0 192.168.1.0 Passive Interface(s): FastEthernet0/1 Routing Information Sources: Gateway Distance Last Update (this router) 90 20:51:48 192.168.1.2 90 00:22:58 172.16.10.6 90 01:58:46 172.16.10.2 90 01:59:52 Distance: internal 90 external 170 This output shows us we’re using AS 20, that we don’t have an access-list filter list set on the routing tables, and that our K values are set to default. We can see that we’re routing for the 10.0.0.0, 172.16.0.0, and 192.168.1.0 networks and that we have a passive interface on interface FastEthernet0/1. We don’t have an interface configured for the 172.16.0.0 network, which means that this entry is an extra network statement under EIGRP. But that won’t hurt anything, so this is not causing our issue. Last, the passive interface is not causing a problem with this network either, because we’re not using interface Fa0/1. Still, keep in mind that when troubleshooting, it’s always good to see if there are any interfaces set to passive. Let’s see what the show interfaces command will tell us: Corp#
Serial0/0 is up, line protocol is up Hardware is PowerQUICC Serial Description: < Internet address is 192.168.1.1/30
Encapsulation HDLC, loopback not set [output cut] Looks like our statistics are set to defaults, so nothing really pops as a problem here. But remember when I covered the steps to check if there is no adjacency back at the beginning of this section? In case you forgot, here’s a list of things to investigate: The interface between the devices are down. The two routers have mismatching EIGRP autonomous system numbers.
The proper interfaces aren’t enabled for the EIGRP process. An interface is configured as passive. K values are mismatched. EIGRP authentication is misconfigured. Okay, our interfaces are not down, our AS number matches, layer 3 is working between routers, all the interfaces show up under the EIGRP process, and none of our needed interfaces are passive, so now we’ll have to look even deeper into the EIGRP configuration to uncover the problem.
Since the Corp router has the basic default configurations, we need to check the Branch router’s EIGRP configuration: Branch#
Routing Protocol is "eigrp 20" Outgoing update filter list for all interfaces is 10 Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates Default networks accepted from incoming updates EIGRP metric weight K1=1, K2=0, K3=0, K4=0, K5=0 EIGRP maximum hopcount 100 EIGRP maximum metric variance 1 Redistributing: eigrp 20 EIGRP NSF-aware route hold timer is 240s Automatic network summarization is not in effect Maximum path: 4 Routing for Networks: 10.0.0.0 192.168.1.0 Routing Information Sources: Gateway Distance Last Update 192.168.1.1 90 00:27:09 Distance: internal 90 external 170 This router has the correct AS—always check this first—and we’re routing for the correct networks. But I see two possible snags here, do you? First, the outgoing ACL filter list is set, but the metrics are not set to default. Remember, just because an ACL is set doesn’t mean it’s automatically giving you grief. Second, the K values must match, and we know these values are not matching the Corp router! Let’s take a look at the Branch interface statistics to see what else might be wrong: Branch>
sh int s0/0/0 Serial0/0/0 is up, line protocol is up Hardware is GT96K Serial Internet address is 192.168.1.2/30
Encapsulation HDLC, loopback not set [output cut] Aha! The bandwidth and delay are not set to their defaults and don’t match the directly connected Corp router. Let’s start by changing those back to the default and see if that fixes our problem: Branch#
Branch(config)# int s0/0/0 Branch(config-if)# no bandwidth Branch(config-if)# no delay And let’s check out our stats now to see if we’re back to defaults: Branch#
Serial0/0/0 is up, line protocol is up Hardware is GT96K Serial Internet address is 192.168.1.2/30 MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation HDLC, loopback not set [output cut] The bandwidth and delay are now at the defaults, so let’s check our adjacencies next: Corp#
sh ip eigrp neighbors IP-EIGRP neighbors for process 20 Okay, so it wasn’t the bandwidth and delay settings because our adjacency didn’t come up, so let’s set our K values back to default like this: Branch#
config t Branch(config)# router eigrp 20 Branch(config-router)# metric weights 0 1 0 1 0 0 Branch(config-router)# do sho ip proto Routing Protocol is "eigrp 20" Outgoing update filter list for all interfaces is 10 Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates Default networks accepted from incoming updates EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0 [output cut] I know this probably seems a little complicated at first, but it’s something you shouldn’t have to do much, if ever. Remember, there are five K values, so why 6 numbers? The first number listed is type of service (ToS), so always just set that to 0, which means you must type in six numbers as shown in my configuration example. After we chose the default of 0 first, the default K values are then 1 0 1 0 0, which is bandwidth and delay enabled. Let’s check our adjacency now: Corp#
IP-EIGRP neighbors for process 20 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num
0 192.168.1.2 Se0/0 14 00:02:09 7 200 0 18
Bam! There we go! Looks like mismatched K values were our problem. Now let’s just check to make sure we can ping from end to end and we’re done: Corp#
ping 10.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds: .....
Success rate is 0 percent (0/5) Corp#
Rats! It looks like even though we have our adjacency, we still can’t reach our remote network. Next step? Let’s see what the routing table shows us: Corp#
[output cut] 10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 10.1.1.0/24 is directly connected, FastEthernet0/0 D 10.0.0.0/8 is a summary, 00:18:55, Null0 192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.1.0/30 is directly connected, Serial0/0 D 192.168.1.0/24 is a summary, 00:18:55, Null0 The problem is screamingly clear now because I went through this in detail throughout this chapter. But just in case you still can’t find it, let’s look at the show ip protocols command output: Routing Protocol is "eigrp 20" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates Default networks accepted from incoming updates EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0 EIGRP maximum hopcount 100 EIGRP maximum metric variance 2 Redistributing: eigrp 20 EIGRP NSF-aware route hold timer is 240s
Automatic address summarization: 192.168.1.0/24 for FastEthernet0/0 Summarizing with metric 2169856 10.0.0.0/8 for Serial0/0 Summarizing with metric 28160 [output cut] By looking at the Figure 17.10 , you should have noticed right away that we had a discontiguous network. This means that unless they are running 15.0 IOS code, the routers will auto-summarize, so we need to disable auto-summary: Branch(config)# router eigrp 20 Branch(config-router)# no auto-summary 008412:%DUAL-5-NBRCHANGE:IP-EIGRP(0) 20:Neighbor 192.168.1.1 (Serial0/0/0) is resync: peer graceful-restart Corp(config)#
Corp(config-router)# no auto-summary Corp(config-router)# *Feb 27 19:52:54:%DUAL-5-NBRCHANGE: IP-EIGRP(0) 20:Neighbor 192.168.1.2 (Serial0/0) is resync: summary configured *Feb 27 19:52:54.177:IP-EIGRP(Default-IP-Routing- Table:20):10.1.1.0/24 - do advertise out Serial0/0 *Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing-Table:20):Int 10.1.1.0/24 metric 2816 0 - 25600 2560 *Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing- Table:20):192.168.1.0/30 - do advertise out Serial0/0 *Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing- Table:20):192.168.1.0/24 - do advertise out Serial0/0 *Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing-Table:20):Int 192.168.1.0/24 metric 4294967295 - 0 4294967295 *Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing-Table:20):10.0.0.0/8 - do advertise out Serial0/0 Corp(config-router)# *Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing-Table:20):Int 10.0.0.0/8 metric 4294967295 - 0 4294967295 *Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing-Table:20):Processing incoming REPLY packet *Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing-Table:20):Int 192.168.1.0/24 M 4294967295 - 1657856 4294967295 SM 4294967295 - 1657856 4294967295 *Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing-Table:20):Int 10.0.0.0/8 M 4294967295 - 25600 4294967295 SM 4294967295 - 25600 4294967295 *Feb 27 19:52:54:IP-EIGRP(Default-IP-Routing-Table:20):Processing incoming UPDATE packet Finally the Corp looks happy, so it looks like we’re good to go! Let’s just check our routing table to be sure: Corp#
sh ip route [output cut] 10.0.0.0/24 is subnetted, 1 subnets C 10.1.1.0 is directly connected, FastEthernet0/0 192.168.1.0/30 is subnetted, 1 subnets C 192.168.1.0 is directly connected, Serial0/0 What the heck? How can this be! We saw all those updates on the Corp console, right? Let’s check the configuration of EIGRP by looking at the active configuration on the Branch router: Branch#
sh run [output cut] ! router eigrp 20 network 10.0.0.0 network 192.168.1.0 distribute-list 10 out no auto-summary ! We can see that the access list is set outbound on the routing table of the Branch router. This may be preventing us from receiving the updates from remote networks! Let’s see what the ACL 10 list is doing: Branch#
Standard IP access list 10 10 deny any (40 matches) 20 permit any Now who in the world would stick an access list like this on a router? This ACL says to deny every packet, which makes the second line of the ACL irrelevant since every single packet will match the first line! This has got to be the source of our troubles, so let’s remove that list and see if the Corp router starts working: Branch#
config t Branch(config)# router eigrp 20 Branch(config-router)# no distribute-list 10 out Okay, with that ugly thing gone, let’s check to see if we’re receiving our remote networks now: Corp#
sh ip route [output cut] 10.0.0.0/24 is subnetted, 2 subnets D 10.2.2.0 [90/2172416] via 192.168.1.2, 00:00:24, Serial0/0 C 10.1.1.0 is directly connected, FastEthernet0/0 192.168.1.0/30 is subnetted, 1 subnets C 192.168.1.0 is directly connected, Serial0/0 Corp#
Corp# ping 10.2.2.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds: !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms Corp# Clear skies! We’re up and running. We had mismatched K values, discontiguous networking, and a nasty ACL on our routing table. For the CCNA R/S objectives, always check for an ACL on the actual interface as well, not just in the routing table. It could be set on the interface or routing table, either one, or both! And never forget to check for passive interfaces when troubleshooting a routing protocol issue! All of these commands are seriously powerful tools in the hands of a savvy professional faced with the task of troubleshooting myriad network issues. I could go on and on about the profusion of information these commands can generate and how well they can equip us to solve virtually every networking ill, but that would be way outside the scope of this book. Yüklə 22,5 Mb. Dostları ilə paylaş:
|