gcavert

Hello group! Was wondering if anyone had experienced a similar problem with their CLAN boards:

It all started a few weeks when one of the 8300LSP remote sites lost contact with mothership 8500. We have a homebrew monitoring tool that watches all the pingable IP's on the voice and data network and the CLAN board that connects that remote site went unpingable for about 10 mins. We saw no errors on the port, ethernet was still up, link integrity OK, but the board couldn't ping out and showed failed network region for the 8300 on the other end. Once the board was pingable again, we reset the 8300 and went on our merry way.

The problem continued to plague us for weeks and only happened in the middle of the day when traffic on the network was at it's heaviest. We swapped boards, we swapped adapters on the back of media gateway, we swapped Catalyst switches and by golly nothing worked.

Finally, I think I've made a breakthrough today on a network segment where the voice network and regular old IP network converge. I reenabled fast-cache switching on a cisco router that was showing heavy CPU% and dropping packets out of the queue. (ip route-cache was disabled because this router tries to load balance over several low speed circuits) The router is happier now and so far no QoS issues or outages with the remote site.

So my question is: Why does the CLAN board go unpingable for what seems like an eternity when this happens? Is there supposed to be a built-in mechanism that disables the board if you lose your remote site? Or perhaps the board crashes if it gets too many ICMP messages from the troubled router?

I was just curious because resolving the routing issue only solves half the problem if the next time the IP network burps we lose CLANs for 10 minutes.

--Glenn

nexSIP

Is this a remote site? why are you thowing this traffic on the general LAN?

__________________
http://www.nexsip.com
Communicate Openly and Freely

PBXtech.info

 

gcavert

It is a remote site, but there are bandwidth constraints to that site so I have to share voice and data traffic over the same same connection for the time being. Everywhere else the PBX has it's own IP network so there's no competition from bursty LAN traffic. Even with priority queueing set up on the router we were still getting packets dumped when it couldn't clear the buffer pools fast enough.

Knock on wood, it's been almost two weeks and no problems, but something still is a bit unsettling about the boards crashing because of traffic problems somewhere on the IP network.

The only thing I can think of off the top of my noggin is that the router blew back a bunch of ICMP source quench messages and that ticked it off.

--g

stubborne

FW 12 notes (real specific info :devil: ):
Firmware Vintage 12 contains the following fixes and enhancements:

Flow control on the C-LAN has been improved. Now, a burst of data in either
direction is handled much better than in the past. Furthermore, RSCL
communications have been improved.

Denial of Service filters are tunable by Tier III Services. The new settings
are stored in Flash memory on the board and are reloaded after a board reset.

The settings are also preserved in the case of a firmware update to the board.

Previously, under extremely high occupancy the CLAN could stop responding.

Previously, under very rare circumstances, CLAN could spontaneously reset.

On earlier vintages, brief duration network outages could cause CLAN boards
to become unresponsive and not accept registration requests.

__________________
Stu

gcavert

Hey Stu. Yah, I checked the firmware vintage and we're all at FW 12 on the CLAN boards. Looks like there's still some kinks to work out of FW 12.

Unfortunately at this point, it looks like we're going to be a footnote in somebody's trouble ticket because the problem seems to have gone away after modifying the IP network, but we'll keep pestering Avaya until FW13.

--g