IP Trunks - not connecting 1

[AnthonyHardy]

I have two CS1000 switches connected via ip trunks. We changed our core switch (layer 3, also routing) out yesterday and everything was fine. This morning, you cannot dial between the two CS1000's.

In ld 96, the dch's both said EST, yet no calls would pass. I'm not sure how to debug anything here (I am a network guy, been admin'ing the nortel stuff for nearly 10 years, but I'm not a setup guy, just basic MAC stuff).

If I disables the dch on one side and enl it and it "looks" EST on both sides, but no calls go through. On occassion the connection actually establishes itself after a dis/enl of the dch, but only for a short period of time (1-2 minutes).

I restarted the signalling server on the remote side. Once back up, the dch on that side still said EST. The main switch's dch wouldn't go to EST, so I'm restarting the signalling server at the main switch.

Any ideas? Where can I look for a debug of some sort? I have access to the Element Manager on both sides.

This is on 4.0 btw.

THanks for any help!

 

[AnthonyHardy]

Alright, it seems that Foundry has a problem with TPS elections. My SS has been plugged into a Foundry switch for ever and worked fine, but as soon as we moved the "core" vlan definition to the foundry, tps elections broke. Of course, this took two days of troubleshooting to determine.

Yesterday afternoon, I decided to move the vlan definition (no physical equipment move, since it hadn't moved before anyway) back to the cisco. I then routed the subnets for both the ELAN and the TLAN back to the cisco for routing.

Restarted the SS. Waiting 5 mins. Restarted the MC32. The MC32 came up as master. I was livid! However, the Nortel tech I was talking to said that the elections are held every 15 minutes. I gave it up and went home, intending on opening a ticket with Nortel themselves this morning (via my vendor). No need. Apparently, the elections happen at a little more than 15 minutes (maybe 30?) and the system came back up on its own last night shortly after I left, exasperated.

I can only assume that Foundry somehow blocks the TPS elections unintentionally? Not sure, but I'm functional again.

Thanks again for all of your help guys.

 

[allenmac]

The election signaling is handled by UDP Port 16550 on both the E-LAN and T-LAN.

For a complete list of ports used by Nortel VoIP, check out NTP NN43001-260 - Nortel Communications Server 1000 Converging the Data Network with VoIP Fundamentals.

 

[AnthonyHardy]

Thanks again allen.

One more update. I found that I was much more stable, but still dropping the ip trunks occassionally. I also saw that the MC32 and SS still were both considering themselves masters.

To test, I telnetted into our remote location (which also has it's own SS and MC32) and did a disServices/enlServices on the MC32 to force an election. You could see both the SS and the MC32 talking for the election. I wasn't seeing this at the main site, so I knew the election wasn't taking place properly.

I found this thread:

http://www.tek-tips.com/viewthread.cfm?qid=1554567&page=1

that mentions very similar conditions to mine. My foundry is on v4.3 and not 5.0, but as soon as I moved my SS over to cisco, it started working properly and I can see elections taking place and working properly.

I will beat up foundry on this and get an answer as to why the udp broadcast wasn't working and post it back here, for future reference.