IP trunks lock up

[telnettech]

All,

I have tried to get Ericsson to help since May but it has not been answered by them and customer is getting tired of problem

Scenario:

I have an MD110 with 2 ELU32 cards in it. They have been upgraded to R7 firmware. Also I have a webswitch at another location that has 5 extensions in it that registers to the MD110 as ip extensions. I am having QOS 355 errors showing up in my alarm logs of the MD110 for the IP trunk board. Eventually the MD110 IP trunk board locks up and we have to restart the board. The webswitch doesnt see the T-1 drop( it doesnt actually lose connection to the Telco prvided T-1) and doesnt route to the secondary copper trunks that are setup in the webswitch. and the phones stay registered to the MD110. The callers at the webswitch site are not able to make calls out until we restart the IP trunk board. Also the customer says that they have voice as a priority on the routers that would be used for the connection between these offices. Does anybody have any experience with this that can give me some advise in what can be the problem and what to do. Before the installation a VRA test was done on the network and overall the network was certified to work fine for Voip deployment.

Any help is greatly appreciated
Brian


To error is human.....if the machine doesnt work, then KICK IT !!!!!!!!!!!!!

 

[whosrdaddy]

ELU32 is known for blocking.

IMHO if you want a good/final solution: upgrade to TSW and use IPLU with EBN instead.

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[dstrang1]

Thanks Daddy, but, unfortunately "an upgrade will fix that" isn't a viable solution at this point -- at least not without some back-up justification from ///.

This one is a real head-scratcher (I've been working with Brian on this install). It's a 1-LIM BC12sp10 with an EEBG set up as a branch node across an MPLS T-1. The IP extensions at the branch site register with the ELU32 in the MD and use the Webswitch as backup if the T-1 drops.

What actually happens at the branch location is that the IP extensions suddenly become unable to place external outbound calls. During this condition, the IP extensions are still registered with the MD and can be called or place internal calls successfully.

The only way to clear this condition is to restart the ELU32 used for the IP trunks. None of the IP extensions ever appear blocked in the system, nor do the IP trunks.
Calls placed to the analog lines that terminate in the Webswitch and route across the IP route to the MD also are successful during the condition in which the IP ext's cannot dial out.

If the T-1 is completely dropped, the IP phones do indeed register with the Webswitch, but otherwise, the IP phones do not lose connection with the MD/ELU32 to which they are primarily registered, so they never fall back to the Webswitch.

The code 355's occur on the ELU-32 used for the IP extensions. Occassionally,the ELU32 used for the IP trunks shows a 114 Device board activated, but with no real correlation to the 355's for extension card -- the 355's occur pretty frequently (20 - 100 per day).

I do know from the customer contact at the MD site that the T-1 is subject to semi-random high bursty traffic.

I'm also reasonably sure that NO QoS or packet prioritization has been set up on the T-1. The VRA thas was done for this customer only verified that the T-1 could handle up to 5 simultaneous voice calls with no voice quality degradation, and that QoS or a separate VLAN was recommended but not necessary.

I'm trying to get the net admin folks on the customer side to look at the history/event logs for their routers to see if they can correlate high traffic periods with occurrances of the IP extensions not being able to dial out, but I haven't got anything.

In the mean time, this customer is PISSED and thinks the MD/webswitch is a piece o' crap!

Do the debug ports on the ELU32's provide any useful info?
Enough to justify the trouble of connecting up to them?

Should the Webswitch and IP phones be reconfigured to be a standalone system and use the IP trunks as tie lines? (what I originally suggested but was shot down by the installing vendor).

Any of you guys out there dealt with something similar?

Thanks,

Dave Strang

 

[whosrdaddy]

I would use the Webswitch as a standalone system.
unfortunately the ELU32 has never been a good board. It is known that it can block under high traffic cases (a swedish service advice exists for this issue). what you can do is add ELU32 boards so the blocking will occur less.
but I repeat my POV, the only GOOD solution (maybe in your cast not the BEST soultion) is to use IPLU.

/Daddy

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[dstrang1]

whosrdaddy (Vendor) 26 Jul 07 2:25 sed:

>I would use the Webswitch as a standalone system.

They wouldn't listen.....

>unfortunately the ELU32 has never been a good board. It is >known that it can block under high traffic cases (a >swedish service advice exists for this issue).

Got any additional info for that service bulletin (date or solution number)? I've been hunting for it on infochannel but haven't found anything specific to this issue.

The most aggravating thing is that when the condition occurs, nothing ever actually shows as "blocked" on any sort of status print...the IP phones just can't place external calls until the ELU-32 used for the TL65 route is restarted.

Thanks,

Dave Strang

 

[TBLuk]

I'm having the same woes with ELU32s, only in an IP extension basis.

They just aren't stable at all to be honest.

We have a small IP solution using BC12 and ELU32, and it goes haywire frequently.

We have a few large IP solution using BC13 and IPLU and it works almost problem free.

 

[whosrdaddy]

quote from BC12 SP8 release notes

4 Information
During high traffic load the ELU32 board can restart. Restart takes about 10 seconds and all ongoing calls will be cut. This problem also exists on previous ELU32 versions. Work is ongoing and plan is to have a solution for next SP.

Comfort noise for the ELU32 is not included in SP8, this is planned to be included in next SP.

but the problem we see with the ELU32 is not quite the same, it just stops working after a certain amount of time and only a rfboi gets it back up.

It's no wonder E/// discontinued the ELU32, the board was not powerfull enough from the start. if try to report this problem you'll get a pasive sustaining response from E///, so the only solution we are left with is to upgrade the customer, throw out the ELU32's and put IPLU's instead...

-----------------------------------------------------
What You See Is What You Get
Never underestimate tha powah of tha google!

 

[dstrang1]

Thanks for the info!

Typical response from E///.....but also interesting since this sytem was sold new only a year ago w/BC12sp10.

C-ya,

Dave Strang