EIGRP problem
I have 3 routers running EIGRP with ip classless and no auto-summary:
(R1)
(R2)
(R3)
Show ip route from R1:
Gateway of last resort is not set
192.168.1.0/24 is variably subnetted, 2 subnets, 1 masks
D 192.168.1.56/30 [90/2681856] via 192.168.1.2, 00:57:19, Serial1
C 192.168.1.0/30 is directly connected, Serial1
Show ip int brief from R3:
Serial3
192.168.1.58 YES manual up up
I am unable to ping any interfaces on R3 from R1.
What am I doing wrong?
(R1)
(R2)
(R3)
Show ip route from R1:
Gateway of last resort is not set
192.168.1.0/24 is variably subnetted, 2 subnets, 1 masks
D 192.168.1.56/30 [90/2681856] via 192.168.1.2, 00:57:19, Serial1
C 192.168.1.0/30 is directly connected, Serial1
Show ip int brief from R3:
Serial3
192.168.1.58 YES manual up up
I am unable to ping any interfaces on R3 from R1.
What am I doing wrong?
Comments
post configs of other 2 routers
R2 can ping any interface on R3 and vice versa.
R1 cannot ping any interface on R3 nor can R3 ping any interface on R1.
Ping 192.168.1.58 with debug ip packet detail turned on showing only entries that have source or destination ip 192.168.1.58 (serial interface on R3)
IP: s=192.168.1.1 (local), d=192.168.1.58 (Serial1), len 100, sending ICMP type=8, code=0.
IP: s=192.168.1.1 (local), d=192.168.1.58 (Serial1), len 100, sending ICMP type=8, code=0
IP: s=192.168.1.1 (local), d=192.168.1.58 (Serial1), len 100, sending ICMP type=8, code=0
IP: s=192.168.1.58 (Serial1), d=192.168.1.1 (Serial1), len 100, rcvd 3 ICMP type=0, code=0
IP: s=192.168.1.1 (local), d=192.168.1.58 (Serial1), len 100, sending ICMP type=8, code=0
IP: s=192.168.1.58 (Serial1), d=192.168.1.1 (Serial1), len 100, rcvd 3 ICMP type=0, code=0
IP: s=192.168.1.58 (Serial1), d=192.168.1.1 (Serial1), len 100, rcvd 3 ICMP type=0, code=0
IP: s=192.168.1.1 (local), d=192.168.1.58 (Serial1), len 100, sending ICMP type=8, code=0
IP: s=192.168.1.58 (Serial1), d=192.168.1.1 (Serial1), len 100, rcvd 3 ICMP type=0, code=0.
Success rate is 0 percent (0/5)
---R1
Current configuration : 808 bytes
!
version 12.2
no service timestamps debug uptime
no service timestamps log uptime
no service password-encryption
!
hostname R1
!
enable secret
!
ip subnet-zero
!
interface Serial1
ip address 192.168.1.1 255.255.255.252
no ip mroute-cache
clockrate 1200
!
router eigrp 1
network 192.168.1.0
no auto-summary
no eigrp log-neighbor-changes
!
ip classless
no ip http server
ip pim bidir-enable
!
!
line con 0
line aux 0
line vty 0 4
login
!
end
---R2
Current configuration : 737 bytes
!
version 12.2
no service timestamps debug uptime
no service timestamps log uptime
no service password-encryption
!
hostname R2
!
enable secret
enable password cisco
!
ip subnet-zero
!
interface Serial0
ip address 192.168.1.57 255.255.255.252
no ip mroute-cache
clockrate 1200
!
interface Serial1
ip address 192.168.1.2 255.255.255.252
no ip mroute-cache
!
router eigrp 1
network 192.168.1.0
no auto-summary
no eigrp log-neighbor-changes
!
ip classless
no ip http server
ip pim bidir-enable
!
line con 0
line aux 0
line vty 0 4
password cisco
login
!
end
---R3
Building configuration...
Current configuration : 1033 bytes
!
version 12.2
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname R3
!
enable secret
!
ip subnet-zero
!
interface Serial3
ip address 192.168.1.58 255.255.255.252
!
router eigrp 1
network 192.168.1.0
no auto-summary
no eigrp log-neighbor-changes
!
ip classless
no ip http server
!
line con 0
line aux 0
line vty 0 4
login
!
end
Magnanimous as the ocean, persistent as time.
Thanks for trying to help but the problem was the clock rate. I was able to ping all interfaces after setting the clock rate to 2400.
What about the clock rate? was it mismatched?
There is a good lesson here. Too many techs leap to look for routing problems, prior to looking at connectivity. Start at layer1/2 and work your way up. You will be more efficient in the long run
Yankee
For one side to work and the other not to it seems that there would have to have been some variance between the routers bandwith settings because the clockrates were initially identical (1200). We could test Ed's theory more by setting the clock rate on R2-s0 back to 1200 and then lowering the bandwidth settings using the bandwidth interface command on R3-s3. This should also fix the problem.
Another explination for why one side worked and the other didn't: perhaps a lone update + acknowledgement squaked through on the slow link just by chance. It would be interesting to see if that neighbor relationship is maintained after a period of time. If we wanted to get hard core I could bust out the Ciso books and look up EIGRP packet sizes and such.
Comments encouraged - I'm going to post more later because if my idea of clockrate/bandwidth correlation is incorrect then this may need to be rethought.
anywhere about working from one side and not the other?
Unless i'm going blind that is?