So This is about me Yeah .
i'm back again to give you the second troubleshooting EIGRP lab
First of all, let's get a quick map of the surroundings.
Note that we have 2 sub-interfaces off Serial0/0 - yet we have three branch routers. This tells me that at least one of those interfaces is multipoint and one is point-to-point. To investigate further, we need to take a look at the sub-interfaces.
Note that Serial0/0.1 has two DLCI's and Serial0/0.3 has one - a clear indication that Serial0/0.1 is the multi-point interface and Serial0/0.3 is the point-to-point interface. We can also log in to R1, R2, and R3 and determine that R1 and R2 are on the same network as S0/0.1 and R3 has the point-to-point link to S0/0.3 on R4. While we are at it, we should also note IP addresses of all the interfaces for later reference
Now that we have a clearer network map, we can take a look at the EIGRP configuration. First of all, let's take a look at R4, since it is likely to know about each neighbor.
This is as it should be. Now, let's take a look at the topology to ensure that R4 knows about all the networks.
Sure enough, it's all there. A final check would be the routing table.
Again - everything as it should be. Basically, we can say that if a packet arrives at R4, then R4 knows how to route it. Let's now move on to one of the routers that is having an issue - R1, and take a look at the EIGRP tables (neighbor, topology and routing).
Now, we are expecting to see only one neighbor - R4, so the neighbor table is correct. However, the topology table tells us that we are not receiving routes for 192.168.2.0/24 - the R2 router. This would normally be sent to us via R4. Obviously, without that route being advertised to us, we are not going to put it in our routing table. Since R2 has the same problem, I'd say that R4 is the likely culprit in terms of problem location.
One thing we can do on R4 to try to diagnose the problem is to take a look at the EIGRP relationships using the debug ip eigrp command. To do this, we establish the debug command on R4, then clear the Neighborship, and watch it get re-established. We will see debug messages that show what routes get advertised and where they get advertised. Here is an example message.
Don't forget to do a no debug all after you have the information you are after. In this case, I note (through a page worth of debug messages) that 192.168.3.0/24 is being advertised out of Serial0/0.1, but 192.168.1.0/24 and 192.168.2.0/24 are not. Let's review the reasons why a network would not be advertised:
Taking a look first at route filtering, we can easily check this by checking the output of show ip protocols.
This tells us we are not filtering routes. We can also use show ip protocols to determine automatic and manual summarization. For instance, if we had installed a summary route, this is what it would look like:
As it is, our output is more like this:
That leaves us with split-horizon. Unfortunately, this is the last thing in the list, so it's more a solution by deduction. However, we can easily see if split-horizon is enabled.
That's the definitive proof that is required. We've also, by reason of elimination through the examination, removed other potential problems that would stop R1 from communicating with R2 (except for perhaps ACLs, which would be deliberately installed, not accidentally left off).
The corrective action is amazingly simple:
This will drop and re-establish the EIGRP neighborship on that link, adjusting the routing tables throughout the organization. As such, it should be done during a "maintenance window".
First of all, let's get a quick map of the surroundings.
R4>sh ip int brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 unassigned YES NVRAM administratively down down
Serial0/0 unassigned YES NVRAM up up
Serial0/0.1 172.16.1.254 YES NVRAM up up
Serial0/0.3 172.16.2.1 YES NVRAM up up
FastEthernet0/1 unassigned YES NVRAM administratively down down
Note that we have 2 sub-interfaces off Serial0/0 - yet we have three branch routers. This tells me that at least one of those interfaces is multipoint and one is point-to-point. To investigate further, we need to take a look at the sub-interfaces.
R4>sh fr pvc
PVC Statistics for interface Serial0/0 (Frame Relay DTE)
Active Inactive Deleted Static
Local 3 0 0 0
Switched 0 0 0 0
Unused 0 0 0 0
DLCI = 101, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1
input pkts 12 output pkts 14 in bytes 666
out bytes 907 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 9 out bcast bytes 546
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:07:00, last time pvc status changed 00:05:20
DLCI = 102, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1
input pkts 14 output pkts 16 in bytes 1014
out bytes 1169 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 7 out bcast bytes 388
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:07:05, last time pvc status changed 00:05:25
DLCI = 103, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.3
input pkts 12 output pkts 93 in bytes 666
out bytes 8341 dropped pkts 0 in pkts dropped 0
out pkts dropped 0 out bytes dropped 0
in FECN pkts 0 in BECN pkts 0 out FECN pkts 0
out BECN pkts 0 in DE pkts 0 out DE pkts 0
out bcast pkts 89 out bcast bytes 8081
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:07:07, last time pvc status changed 00:05:27
Note that Serial0/0.1 has two DLCI's and Serial0/0.3 has one - a clear indication that Serial0/0.1 is the multi-point interface and Serial0/0.3 is the point-to-point interface. We can also log in to R1, R2, and R3 and determine that R1 and R2 are on the same network as S0/0.1 and R3 has the point-to-point link to S0/0.3 on R4. While we are at it, we should also note IP addresses of all the interfaces for later reference
Host
|
Interface
|
IP
|
R4
|
S0/0.1
|
172.16.1.254/24
|
R4
|
S0/0.3
|
172.16.2.1/30
|
R1
|
S0/0
|
172.16.1.1/24
|
R1
|
Fa0/0
|
192.168.1.1/24
|
R2
|
S0/0
|
172.16.1.2/24
|
R2
|
Fa0/0
|
192.168.2.1/24
|
R3
|
S0/0
|
172.16.2.2/30
|
R3
|
Fa0/0
|
182.168.3.1/24
|
Now that we have a clearer network map, we can take a look at the EIGRP configuration. First of all, let's take a look at R4, since it is likely to know about each neighbor.
R4>sh ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 172.16.1.2 Se0/0.1 149 00:07:53 1255 5000 0 2
1 172.16.1.1 Se0/0.1 144 00:09:51 26 200 0 2
0 172.16.2.2 Se0/0.3 131 00:09:56 262 1572 0 4
This is as it should be. Now, let's take a look at the topology to ensure that R4 knows about all the networks.
R4>sh ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(172.16.2.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 192.168.1.0/24, 1 successors, FD is 2172416
via 172.16.1.1 (2172416/28160), Serial0/0.1
P 192.168.2.0/24, 1 successors, FD is 2172416
via 172.16.1.2 (2172416/28160), Serial0/0.1
P 192.168.3.0/24, 1 successors, FD is 2172416
via 172.16.2.2 (2172416/28160), Serial0/0.3
P 172.16.1.0/24, 1 successors, FD is 2169856
via Connected, Serial0/0.1
P 172.16.2.0/30, 1 successors, FD is 2169856
via Connected, Serial0/0.3
Sure enough, it's all there. A final check would be the routing table.
R4>sh ip route
Codes: C - connected, S - static, 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
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.1.0/24 is directly connected, Serial0/0.1
C 172.16.2.0/30 is directly connected, Serial0/0.3
D 192.168.1.0/24 [90/2172416] via 172.16.1.1, 00:11:09, Serial0/0.1
D 192.168.2.0/24 [90/2172416] via 172.16.1.2, 00:09:09, Serial0/0.1
D 192.168.3.0/24 [90/2172416] via 172.16.2.2, 00:11:14, Serial0/0.3
Again - everything as it should be. Basically, we can say that if a packet arrives at R4, then R4 knows how to route it. Let's now move on to one of the routers that is having an issue - R1, and take a look at the EIGRP tables (neighbor, topology and routing).
R1>sh ip eigrp neighbors
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 172.16.1.254 Se0/0 149 00:12:35 42 252 0 11
R1>sh ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(192.168.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 192.168.1.0/24, 1 successors, FD is 28160
via Connected, FastEthernet0/0
P 192.168.3.0/24, 1 successors, FD is 2684416
via 172.16.1.254 (2684416/2172416), Serial0/0
P 172.16.1.0/24, 1 successors, FD is 2169856
via Connected, Serial0/0
P 172.16.2.0/30, 1 successors, FD is 2681856
via 172.16.1.254 (2681856/2169856), Serial0/0
R1>sh ip route
Codes: C - connected, S - static, 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
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C 172.16.1.0/24 is directly connected, Serial0/0
D 172.16.2.0/30 [90/2681856] via 172.16.1.254, 00:12:45, Serial0/0
C 192.168.1.0/24 is directly connected, FastEthernet0/0
D 192.168.3.0/24 [90/2684416] via 172.16.1.254, 00:12:45, Serial0/0
Now, we are expecting to see only one neighbor - R4, so the neighbor table is correct. However, the topology table tells us that we are not receiving routes for 192.168.2.0/24 - the R2 router. This would normally be sent to us via R4. Obviously, without that route being advertised to us, we are not going to put it in our routing table. Since R2 has the same problem, I'd say that R4 is the likely culprit in terms of problem location.
One thing we can do on R4 to try to diagnose the problem is to take a look at the EIGRP relationships using the debug ip eigrp command. To do this, we establish the debug command on R4, then clear the Neighborship, and watch it get re-established. We will see debug messages that show what routes get advertised and where they get advertised. Here is an example message.
*Mar 1 00:38:23.335: IP-EIGRP(Default-IP-Routing-Table:1): 192.168.1.0/24 - do advertise out Serial0/0.3
*Mar 1 00:38:23.335: IP-EIGRP(Default-IP-Routing-Table:1): Int 192.168.1.0/24 metric 2172416 - 1657856 514560
Don't forget to do a no debug all after you have the information you are after. In this case, I note (through a page worth of debug messages) that 192.168.3.0/24 is being advertised out of Serial0/0.1, but 192.168.1.0/24 and 192.168.2.0/24 are not. Let's review the reasons why a network would not be advertised:
1. Route Filtering
2. Auto or Manual Summarization
3. Split-Horizon
Taking a look first at route filtering, we can easily check this by checking the output of show ip protocols.
R4#sh ip protocols | section filter list
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
This tells us we are not filtering routes. We can also use show ip protocols to determine automatic and manual summarization. For instance, if we had installed a summary route, this is what it would look like:
R4#sh ip protocols | section [Ss]ummarization
Automatic network summarization is not in effect
Address Summarization:
192.168.0.0/16 for FastEthernet0/0
As it is, our output is more like this:
R4#sh ip protocols | section [Ss]ummarization
Automatic network summarization is not in effect
That leaves us with split-horizon. Unfortunately, this is the last thing in the list, so it's more a solution by deduction. However, we can easily see if split-horizon is enabled.
R4#sh ip int s0/0.1 | section Split horizon
Split horizon is enabled
That's the definitive proof that is required. We've also, by reason of elimination through the examination, removed other potential problems that would stop R1 from communicating with R2 (except for perhaps ACLs, which would be deliberately installed, not accidentally left off).
Corrective Action
The corrective action is amazingly simple:
R4#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R4(config)#int s0/0.1
R4(config-subif)#no ip split-horizon eigrp 1
R4(config-subif)#end
R4#wr mem
This will drop and re-establish the EIGRP neighborship on that link, adjusting the routing tables throughout the organization. As such, it should be done during a "maintenance window".
