12-29-2003 06:07 PM - edited 03-02-2019 12:36 PM
hi
I have a remote site with a 2651XM and a 2950xl switch . The site has two 64K satellite uplinks to the corporate office to a 3660 already in production and have several circuits terminating on it.
The 2651XM and 2950XL and brand new. As i mentioned above we have two redundant satellite links.
Everything works great.
However when i disconnect one of the serial links two of the 4 PC on the remote network cannot ping a router or any device on the other end. It takes about 3 minutes for the 2 devices to finally come online and ping the remote device. During this time you can ping the PCS from the routers and the switch.
It seems that the PC's are chosen at random.
The switches and routers are brand new and i have replaced them so eliminate hardware failure.
I used cef per packet and per destination and still have the same problem.
Below is the config of the router
interface FastEthernet0/0
ip address 10.61.5.20 255.255.255.0
ip helper-address 156.15.92.100
duplex auto
speed auto
!
interface Serial0/0
description to
bandwidth 64
ip address 10.61.
encapsulation frame-relay
frame-relay class 64K_WAN
frame-relay traffic-shaping
frame-relay interface-dlci 605
frame-relay ip rtp header-compression
hold-queue 1024 in
hold-queue 1024 out
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/1
descripti
bandwidth 64
ip address 10.xx.xx.xx
encapsulation frame-relay
frame-relay class 64K_WAN
frame-relay traffic-shaping
frame-relay interface-dlci 606
--More-- frame-relay ip rtp header-compression
hold-queue 1024 in
hold-queue 1024 out
!
router eigrp 5000
network 10.0.0.0
no auto-summary
!
ip http server
ip classless
!
!
!
!
map-class frame-relay 64K_WAN
frame-relay cir 64000
frame-relay bc 640
frame-relay be 0
frame-relay mincir 64000
frame-relay fair-queue
frame-relay fragment 80
frame-relay ip rtp priority 16384 16383 33
!
System image file is "flash:c2600-js-mz.122-15.ZJ3.bin"
Below is config of switch
System image file is "flash:/c2950-i6q4l2-mz.121-14.EA1a.bin"
hostname Switch
!
!
ip subnet-zero
!
!
!
spanning-tree mode pvst
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id
spanning-tree uplinkfast
!
!
interface FastEthernet0/1
spanning-tree portfast
!
interface FastEthernet0/2
!
interface FastEthernet0/3
!
interface FastEthernet0/4
spanning-tree portfast
!
interface FastEthernet0/5
!
interface FastEthernet0/6
!
interface FastEthernet0/7
!
interface FastEthernet0/8
!
interface FastEthernet0/9
spanning-tree portfast
!
interface FastEthernet0/10
!
interface FastEthernet0/11
!
interface FastEthernet0/12
!
interface FastEthernet0/13
!
interface FastEthernet0/14
!
interface FastEthernet0/15
!
interface FastEthernet0/16
spanning-tree portfast
!
interface FastEthernet0/17
!
interface FastEthernet0/18
!
interface FastEthernet0/19
!
interface FastEthernet0/20
!
interface FastEthernet0/21
!
interface FastEthernet0/22
!
interface FastEthernet0/23
!
interface FastEthernet0/24
!
interface FastEthernet0/25
!
interface FastEthernet0/26
!
interface Vlan1
ip address 10.61.5.2 255.255.255.0
no ip route-cache
!
ip default-gateway 10.61.5.20
ip http server
!
!
line con 0
line vty 5 15
!
end
12-29-2003 10:56 PM
Problem is that your FR interfaces don't realize that DLC is down in a few LMI queries . And your serial interfaces running fast switching or CEF, by default perform per destination or per source-destinatin-pair load balancing. This way traffic of some PCs allocated to this serial line will be dropped until fr understands that it's down. I can explain what's going on but can't reccomend something at the moment, still researching.
Regards.
12-29-2003 11:13 PM
Not sure but FR end-to-end keepalives may help to declare link down faster in case of a DLC failure. Check this:
(I learnt about this feature from a previous post of thisisshanky, Regards.)
12-30-2003 08:25 AM
It sounds like it's taking three minutes for the routing protocol to figure out that the links are down, and take them out of the routing and cef tables. Could you verify whether this is true or not, by looking at the routing table just after you pull one of the serial links, and make certain the paths are still in the routing table?
If so, you probably need to detect the down condition on the links faster, which either means using a bit signalling combined with asynch lmi, or faster layer three hello's on the circuits, or end to end lmi, one of the three. I'm not certain what your options are on these three, from what you've told us so far, but those are the three things I'd be looking at.
As for the mystery of why only two of the hosts cannot ping, this is probably because of CEF's use of the source and the destination address to load share between multiple equal cost paths. When you fail one link, those two hosts probably fall into the hash bucket for the link that's failed, while the other two hosts don't.
:-)
Russ.W
12-30-2003 10:58 AM
hi
Thanks all for your help
I too though the same and disable cef and had the very same problem. What it turned out to be an inverse arp problem. Cisco recommended i build subinterfaces on my 2600 and thus use point to point frame relay thus eliminating the inverse arp. Once i did that it works great. Redundancy kicks in in about 7 secs or less. I also enable per destination cef. Thus to conclude it was the inverse arp that caused my grief.I even used the map statment on the physical interface but did not help. Sub interfaces was the way to go
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide