Customer with Hipath 4K V5.0 at 3 different sites. These are 3 different systems. At some point in the past 3 months all 3 sites have experienced major phone outages OptiIP Phones. User picks up the handset, can dial the number but no call completion. Reviewing the error logs shows 100% packet loss. IT Dept. swears they have done nothing and can see no problems. Sniffer traces taken during this outage shows call setup packets traversing the network. It appears TCP packets are fine for call setup, no UDP packets are moving, hence 100% packet loss. To solve the issue the entire PBX was reloaded at one site. At another site the STMI cards were reseated and immediately started working properly again. Are these cards going to sleep? Are they reacting to some spurious event on the customer network? Customer insists there has to be a patch from Siemens to fix this. I think something is happening on their network to cause this. 3 different sites over a 3 week period, too strange. Any comments?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
STMI HFA 100% packet loss
- Thread starter kevin906
- Start date
Iamnothere
Technical User
It is possible that the loadware needs to be updated on those HFA boards. It is possible that the IT department is wrong.
Has the 4K received all of it's hotfixes? Applying hotfixes is the mechanism used by SEN to keep the customer's system up-to-date with the latest patches and loadware updates. HiPath 4000 V5 has been released since 2009, and I know of no widespread problem such as what you are describing.
If Dirext Media Connection (DMC) is setup properly on these HFA phones, when an internal call is setup (HFA to HFA), the payload connection (UDP) is setup directly between the phones. No UDP packets travel thru the STMI. So if DMC is enabled, and there is 100% packet loss, the problem is most likely the network.
Check the SDAT > Attribut section. Each phone needs "DMCALLWD" there.
Good luck.
Has the 4K received all of it's hotfixes? Applying hotfixes is the mechanism used by SEN to keep the customer's system up-to-date with the latest patches and loadware updates. HiPath 4000 V5 has been released since 2009, and I know of no widespread problem such as what you are describing.
If Dirext Media Connection (DMC) is setup properly on these HFA phones, when an internal call is setup (HFA to HFA), the payload connection (UDP) is setup directly between the phones. No UDP packets travel thru the STMI. So if DMC is enabled, and there is 100% packet loss, the problem is most likely the network.
Check the SDAT > Attribut section. Each phone needs "DMCALLWD" there.
Good luck.
I was going to suggest deactivating and reactivating the STMI cards in case there was some kind of handshake problem. I see you commented that reseating the board at one site fixed the problem - reseating will cause the board to reset as well, but I am new to the 4000 and don't know if you can get away with just yanking and reinserting an STMI board like you can with the station boards. When you deactivate and activate the board it should reload some of its software off the hard disk, and if it was working before it should work again.
Note this WILL drop calls and reset all the phones on the board.
I would use DEA-BSSU, type = DI, <pen of board>
and ACT-BSSU, type = AUL, <pen of board>
unless someone suggests otherwise. The STMI board might require a different command if that doesn't work, but I'm pretty sure I used that a few months ago before making some configuration changes.
Note this WILL drop calls and reset all the phones on the board.
I would use DEA-BSSU, type = DI, <pen of board>
and ACT-BSSU, type = AUL, <pen of board>
unless someone suggests otherwise. The STMI board might require a different command if that doesn't work, but I'm pretty sure I used that a few months ago before making some configuration changes.
Iamnothere
Technical User
How long did these boards work before the problem occurred? What level of loadware is running on these STMI boards? To determine both answers, access the STMI via Web-Based Management. Use Assistant > Expert Access > Web-Based Management for HG35xx. Look in the lower right corner after the auto-logon. You should see the loadware revision info, and the length of time that the board(s) have been up. If you have recently rebooted the boards, the length of time will have been reset. It is VERY IMPORTANT that you know how long the STMIx boards ran before the problem occurred. Re-post with that info ASAP.
We had the SAME problem. It is a software bug. Have TAC pull diag logs from your gateway cards. If you want to know how do that and have "engr" access, I can walk you through it.
Be aware, resseting the boards is onyl resetting the timers from the errors below. This will crop up again in another 240 days.
3. NO CALLS POSSIBLE FROM IP GW (HG3530/HG3550/HG3570/HG3575):
The error can happen after 240 days of continues running on the IP GW. In the GW eventlog the following errors can be seen:
EventLogEntry from MSC (MSCSessionCtrlTask "09/25/2010 13:09:04.748707" \cm_ams_lib\msc\MSCVoiceLAN.cpp 1056):
EventType: Major
EventCode: MSC_ERROR
EventText: MSCAllocateLanLeg failed!
EventLogEntry from LAN (WrkThrd02 "09/25/2010 13:09:04.750957" lan_resource.cpp 199):
EventType: Warning
EventCode: MSG_DVMGR_OPEN_LEG_FAILED
EventText: Open of LAN Leg failed; MSC Error Code -4
EventLogEntry from MSC (MSCSessionCtrlTask "09/25/2010 13:12:20.994746" \cm_ams_lib\msc\MSCTables.cpp 563):
EventType: Major
EventCode: MSC_NO_FREE_ENTRY_LEFT
EventText: No free entry found in MSCAllocateLanLeg ()
The error is only present from V4 upwards (and in all variants of the V4 .23 and V5 .53 GW loadware lines).
Be aware, resseting the boards is onyl resetting the timers from the errors below. This will crop up again in another 240 days.
3. NO CALLS POSSIBLE FROM IP GW (HG3530/HG3550/HG3570/HG3575):
The error can happen after 240 days of continues running on the IP GW. In the GW eventlog the following errors can be seen:
EventLogEntry from MSC (MSCSessionCtrlTask "09/25/2010 13:09:04.748707" \cm_ams_lib\msc\MSCVoiceLAN.cpp 1056):
EventType: Major
EventCode: MSC_ERROR
EventText: MSCAllocateLanLeg failed!
EventLogEntry from LAN (WrkThrd02 "09/25/2010 13:09:04.750957" lan_resource.cpp 199):
EventType: Warning
EventCode: MSG_DVMGR_OPEN_LEG_FAILED
EventText: Open of LAN Leg failed; MSC Error Code -4
EventLogEntry from MSC (MSCSessionCtrlTask "09/25/2010 13:12:20.994746" \cm_ams_lib\msc\MSCTables.cpp 563):
EventType: Major
EventCode: MSC_NO_FREE_ENTRY_LEFT
EventText: No free entry found in MSCAllocateLanLeg ()
The error is only present from V4 upwards (and in all variants of the V4 .23 and V5 .53 GW loadware lines).
Iamnothere
Technical User
Exactly my point, with less specifics! But the original poster has not responded. Probably rebooted the boards and went on. Oh well...
)The error is known and is fixed with the latest LW for V5 R1.1.0 (or V5 R1.2.0).
But here is one other thing to be on the lookout for. This verion of Loadware seems to have a new parameter on the NCUI cards LAN interface called Ethernet Link Mode. This HAS to be set to 100FDX. If your network switch port is hard strapped to 100 Full and the card is set to Auto, you are going to run into sysmptons of the same issue, i.e. packet loss.
Do yourself a favor and have your tech double check this parameter on every NCUI card you have.
But here is one other thing to be on the lookout for. This verion of Loadware seems to have a new parameter on the NCUI cards LAN interface called Ethernet Link Mode. This HAS to be set to 100FDX. If your network switch port is hard strapped to 100 Full and the card is set to Auto, you are going to run into sysmptons of the same issue, i.e. packet loss.
Do yourself a favor and have your tech double check this parameter on every NCUI card you have.
Iamnothere
Technical User
Ethernet Link Mode" is not new. That parameter has been there since Day 1 of IPDA. Anyone who has been officially trained by SEN on the 4K knows about the potential mismatch if/when a fixed speed/mode ethernet port is connected to an AutoNegotiate port: the result can be a 10MBHD connection. This problem is an Ethernet problem, not a SEN problem. On the 4K, all of the IP-capable boards should be set to match the port Speed/Mode to which they are connected.
- Status
Similar threads