1721 & 8141 router with WIC 1 56K DSU

jeffsmith · ‎02-19-2008

I have configured many 1602 and 1721 routers and never ran into this problem before. This problem has now happened on two new routers. A 1721 and a 8141 software Ver 12.4 (16).

Using a 56 K wic 1 dsu connected to a frame relay I am able to ping and telnet to the Ip address on the frame side of the router. The frame side address is 10.3.0.44 255.255.255.0! The problem is that I am unable to ping the FastEthernet side of the router without a laptop or other ethernet device connected to the router. The FastEthernet IP address is 10.4.17.1 255.255.255.0! The FastEthernet sh Interfaces cmd shows: the FastEthernet is up but the line protocol is down until something is pluged in. Only then will the line protocol come up and I will then be able to ping the FastEthernet side of the router.

The Sh Run Config is below:

sawmill#

sawmill#sh run

Building configuration...

Current configuration : 1732 bytes

!

! Last configuration change at 13:08:39 EST Fri Feb 15 2008 by sawmill

! NVRAM config last updated at 13:10:49 EST Fri Feb 15 2008 by sawmill

!

version 12.4

no service pad

service timestamps debug datetime

service timestamps log datetime

no service password-encryption

!

hostname sawmill

!

boot-start-marker

boot-end-marker

!

no logging buffered

!

no aaa new-model

!

resource policy

!

clock timezone EST -5

clock summer-time EDT recurring

mmi polling-interval 60

no mmi auto-configure

no mmi pvc

mmi snmp-timeout 180

ip subnet-zero

no ip cef

!

no ip dhcp use vrf connected

!

no ip domain lookup

!

username sawmill privilege 15 secret xxx

!

interface FastEthernet0/0

ip address 10.4.17.1 255.255.255.0

ip access-group 101 in

duplex auto

speed auto

!

interface FastEthernet0/1

no ip address

shutdown

duplex auto

speed auto

!

interface Serial0/0/0

bandwidth 56000

ip address 10.3.0.45 255.255.255.0

ip access-group 101 in

ip helper-address 10.3.1.1

ip helper-address 10.3.2.1

encapsulation frame-relay

no fair-queue

frame-relay lmi-type ansi

!

router rip

redistribute connected

network 10.0.0.0

!

ip classless

ip route 10.3.0.0 255.255.255.0 10.3.0.1

ip route 10.3.0.0 255.255.255.0 10.3.0.2

!

no ip http server

!

access-list 101 deny 53 any any

access-list 101 deny 55 any any

access-list 101 deny 77 any any

access-list 101 deny pim any any

access-list 101 permit ip any any

access-list 101 permit icmp any any

snmp-server community ononwep RO

!

control-plane

!

line con 0

login local

line aux 0

line vty 0 4

privilege level 15

login local

transport input telnet

line vty 5 15

privilege level 15

login local

transport input telnet

!

sntp server 10.3.1.4

end

sawmill#

Can someone tell me what I'm doing wrong! I have always been able to ping the router on the FastEthernet side before without equipment attached.was there a change in the 12.4(16) software or have I left some thing out of the config file????

Thanks

Jeff

Richard Burts · ‎02-19-2008

Jeff

What you are describing has been standard behavior of IOS for a very long time - if there is not anything plugged in to an Ethernet interface of the router then the Ethernet interface will show as interface is up line protocol is down. The interface comes to up and up when something is plugged in to the interface.

If you want the interface to be up and up even with nothing plugged in then you can add the command no keepalive under the Ethernet interface.

HTH

Rick

HTH

Rick

jeffsmith · ‎02-19-2008

Thanks Rick

Should this command be removed after an ethernet device is connected for the interface to work properly?

Jeff

Richard Burts · ‎02-19-2008

Jeff

I believe that it would be best to remove the command after some device is connected to the interface.

To put the question into prespective lets think about what the command does and the implications of disabling the interface keepalives. The interface does keepalives as a sort of mechanism to validate whether it is capable of forwarding packets out the interface. If the line protocol is up, then it indicates that keepalives are working and that the interface should be able to forward packets sent to its subnet. If the interface is protocol down then it indicates that it is not able to forward packets sent to its subnet. For Ethernet interfaces when nothing is plugged in then keepalives will fail and the interface will be protocol down.

One implication of interface being protocol down is that you can not ping the interface (which is what you discovered). When you configure the interface to disable keepalives it will go into line protocol up, and it will respond to pings, and it will signal that it can forward packets. So during the period that keepalives are disabled you have created the possibility of a black hole. The router is indicating that it can forward packets out the interface but in fact the packets will drop because there is nothing to forward them to. So enabling keepalives will help the router to accurately report its forwarding status.

HTH

Rick

HTH

Rick