MXe III - Calls intermittently dropping out

[EddieV3]

Hi,

I'm really struggling to resolve an issue. Any help would be appreciated.

We have an MXe III running MCD 4.2. Calls are intermittently cutting off, at least once a day.

Looking in the maintenance log, I see a number of logs which give me cause for concern.

The first is a warning "IP Networking MIPS, port 1, down", which is followed by "Port 1, 1G, full duplex". The second is another warning "ISDN VDsu-1 Mod 1 Port 1, Layer RED alarm active", which is followed by "ISDN VDsu-1 Mod 1 Port 1, D-Channel forced DOWN!".

I get a follow on from this "Call Control Maintenance - MC269CA Universal E1 at location 06 1 02 01 (The location of my T1/E1), Type of diagnostics : background, scope of report : Hybrid, Reason (s) for report: Synchronization : Absent".

The ISDN will then come up, as well as the layer 2 port on the system.

I then get a number of messages indicating that "Device Detection, An IP device, with DN xxx, registered at CDP L2 MAC address Not Supported, CDP L2 Not supported, CDP L2 IP address:".

This happens all the space of a minute, and afterwards all is working as normal. I just have no idea what is causing it. Seeing the IP networking error, I thought it may be an issue with a IP conflict. I've checked the ARP table on the 3300 as it's acting as the DHCP server, and found nothing suspicious. I've cehcked CDP on the switches, checked what devices are connected, and I'm still no closer to resolving the issue.

 

[Supernova99]

It looks like you have 2 faults here
The MIPS is the actual network connection to the controller.
Do you have 2 connections? if so are you using STP? or are you network switches providing BPDU?

The loss of synch could be a few things
First I would check and replace the physical cables from the NTE
Next check that the card is seated correctly and attached with the 3 screws to the main board.
Next check the clock sync source is programmed and active.
Lastly check with the circuit provider to see if there are any issues with the connection.

Share what you know - Learn what you don't

 

[EddieV3]

Hi Supernova,

Thanks for taking the time to reply.

The controller only has 1 connection, and STP is enabled.

Regarding the loss of sync, I've checked the cable, it appears ok. Need to have an agreed outage with the customer so that I can check the card.

Thanks

 

[LoopyLou]

IF the controller only has one connection why would you enable STP? From my understand thats only necessary if you have 2 connections to the 3300 and is used to ensure no loops occur in conjuction with STP throughout the customers network.

When you say dropped calls:
1). Do all calls drop?
2). or Do only trunk calls drop while IP remain?

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[Supernova99]

@Loopylou
Agreed STP is only required to provide port blocking to prevent network loops.
I am not sure this is the issue but if you only have the one connection then I would disable STP as a test to see if this stops the log from being generated and the port going down.

Share what you know - Learn what you don't

 

[EddieV3]

Sorry, gave some mis-information. STP is disabled.

And from the customer reports, it has only been trunk calls that have disconnected.

Thanks.

 

[LoopyLou]

If it was a network issue I would expect IP to IP calls to drop at the same time. More likley an issue with the PRI cards. What do the DTSTATs show for the link. Do you see lots of errors?



I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[EddieV3]

These are the stats I get for the last 24

Universal E1 6 1 2 1
Link is Available
duty bit
cycle framing error
Time (%) losses slips rate
------------------------------------------------
10:09 100 0 0 0
10:00 100 0 0 0
9:00 100 0 0 0
8:00 100 0 0 0
7:00 100 0 0 0
6:00 100 0 0 0
5:00 100 0 0 0
4:00 100 0 0 0
3:00 100 0 0 0
2:00 100 0 0 0
1:00
0:00 100 0 0 0
23:00
22:00 100 0 0 0
21:00
20:00 100 0 0 0
19:00
18:00 100 0 0 0
17:00 99 2 0 0
16:00 99 1 0 0
15:00 100 0 0 0
14:00 99 2 0 0
13:00
12:00 100 0 0 0
11:00

I've also found that there was a power issue on the ISDN NTE, which has now been replaced, but I'm still getting the same issues.

 

[LoopyLou]

Stats look clean. How about the cable from the embedded card to the ISDN NTE?

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.

 

[EddieV3]

I've changed the cable, and the ISDN card. I maybe have overlooked something though from the start, the power that the switches and NTE are connected to might be causing the issue. It would explain why the L2 port and NTE are dropping out, and the system staying up. The MCD is on a different UPS. I've changed the supply that the switches are on, and I'm waiting on the next "incident". Hopefully we only lose the trunks, which would indicate the power has been the cause all along......

I'm clutching at straws now......

 

[Mitelpassion]

this sounds like everything but the controller "dies" when this happens - basically comes back into service.

if these are IP phones, do they stay connected?

 

[EddieV3]

Hi,

I have resolved this now, it was the power causing the issue. The nte and switch was on a circuit connected to a volatge optimizer, which was set to 220v, but dipped well below that on occasion. Equipment was obviously very sensitive!

Thanks for your help though chaps.

 

[LoopyLou]

Good catch

I'd tell you a UDP joke but I'm afraid you won't get it. TCP jokes are the best because you always get them.