EIGRP problem

Dzy_Az

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?

keenon

have u checked if R2 can ping R3? or R1 can ping R2? although i see R1 can see them in ip route doesn't mean it will work..
post configs of other 2 routers

Dzy_Az

R1 can ping any interface on R2 and vice versa.
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)

Webmaster

Don't hesitate to take up some space, just post the entire configs of all three routers.

Dzy_Az

Webmaster wrote:

Don't hesitate to take up some space, just post the entire configs of all three routers.

Thanks.

---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

2lazybutsmart

You only have the 192.168.1.0 network. Where's the 192.168.1.56 network in the eigrp??? I think you should add that to the eigrp protocol of the routers.

Dzy_Az

2lazybutsmart wrote:

You only have the 192.168.1.0 network. Where's the 192.168.1.56 network in the eigrp??? I think you should add that to the eigrp protocol of the routers.

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.

sputnic68

No need for the 192.168.1.56 network in EIGRP because it automatically includes that in the routing table because of the classfull network 192.168.1.0 under the EIGRP process

sputnic68

Oh yeah, that clockrate can become quite troublesome. It's good practice for the troubleshooting exam! I'd mess around with things like that to get you better acquainted with the troubleshooting while you are working on the other tests.

cisco_trouble

hi there

What about the clock rate? was it mismatched?

Yankee

There was none. He is basically saying he forgot to setup the DCE side.

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

EdTheLad

The problem was the clock rate he specified.The clock rate which he originally specified was 1200, when he highered the clock rate to 2400 all was good.This problem was probably due to no bandwidth available for eigrp packets.Since the EIGRP allocated BW is 50% of the configured BW on the Serial interface EIGRP would imagine it had more bandwidth than was phsically available and hence the problem.

cisco_trouble

Yeah, but why was it originally 1200? Thats the question?

pizzafart

EIGRP uses the bandwidth setting of the interface which in this case is probably going to be a lot higher than a wimpy 1200 clock rate. Typical serial line is set at T1 speed by default (1544) which I -think- matches a 1544000 clock rate. This means that EIGRP is willing to chuck .8mbits worth of packets through a slow link. Someone let me know if clockrates don't match bps --- actually, this is interesting so I'll probably repost later today after testing it out at work.

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.

EdTheLad

Hi Pizzafart, i think you misread the inital post as it doesnt mention
anywhere about working from one side and not the other?
Unless i'm going blind that is?

pizzafart

Yeah I guess you're right, it doesn't explicitly say that the other side was working. I just sorta assumed a situation where there were neighbors accounted for in the left network and not on the right. Not sure why I did that.