Re: Problems with connectivity to network over redundant links

dathaide · ‎12-29-2003

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

kkalaycioglu · ‎12-29-2003

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.

kkalaycioglu · ‎12-29-2003

Not sure but FR end-to-end keepalives may help to declare link down faster in case of a DLC failure. Check this:

http://www.cisco.com/en/US/customer/products/sw/iosswrel/ps1830/products_feature_guide09186a0080087a58.html#33085

(I learnt about this feature from a previous post of thisisshanky, Regards.)

ruwhite · ‎12-30-2003

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

dathaide · ‎12-30-2003

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