IP Routing problem after 2.1.27 upgrade

[NickBall]

IPO 406, upgraded to 2.1.27. Upgraded VM Pro to 2.1.14.
Upgraded delta server to 4.0.36
Upgraded Soft Console to 2.1.7
After succesful upgrade we have issues with IP phones (Hard & Soft) on different sub nets.
Using Sys Monitor we can see the incoming connection from IP Phones, but no response from IPO.
IPO, VMpro, Keyserver all on the same Subnet - VMpro connected directly to the IPO.
IPO Config file is identical to previous 2.0.18 version ... Has anything changed with IP Routing??

 

[MrIPO]

What firmware are your IP Phones now running since updating to 2.1(27)

 

[NickBall]

IP Hard phones all on the latest firmware level - It's as if the static routing within the IPO isn't working ....

 

[NickBall]

Further information ....

although we have a default route in place of
IP 0.0.0.0 Mask 0.0.0.0 GW 192.168.0.253 LAN1, nothing worked.
However adding the individual subnets has brought most things back to life - All using the same Gateway.
We will try from a remote location that hasn't got a specific subnet added to see if the default route is the problem and post the results ...

 

[erniethr]

I’m experiencing similar IP Routes problem.

I have tried to send calls (IP Network) from my IPO403 to VoIP Provider. LCR and stuff configured fine and working, few test call connected ok... after few days of testing, IPO just stop responding to test calls.
It was hell 2 weeks and I have finally decided to erase IPO trough serial port (fells goooood!). After testing 2.1.24 and upgrade to 2.1.27 version, few bogus things are disappeared.

But I’m still unable to send traffic from my IPO (192.168.1.254) trough my Router (192.168.1.1) to VoIP provider’s network.
(IP 213.1.13.39 Mask 255.255.255.255 GW 192.168.1.254)

Strange thing is that I have managed to configure IP route to dial ISP (ISDN lines) and then test calls are connecting again. Router is configured OK (firewall is open in both ways to VoIP providers network)
(IP 213.1.13.39 Mask 255.255.255.255 Dest ISP)

Probably is something screwed in IP table...

 

[NickBall]

Erniethr

When you did the erase off the DTE port, did you do X2, X3, X4, X5 and X1?
I was of the understanding that this would take the system back to default, erasing everything including the Routing Table?
It was my next 'plan of attack', although I wasn't going to upload an existing config, but a blank 'default one' and then go and add everything back in, step by step ... although I need some serious 'free time' for this which is difficult as the site is 24 7!

 

[erniethr]

Well, according to Avayas documents it should be a clean erase.
I have used AT to check response from IPO, AT-X2 and AT-X3 to erase configuration (do that, otherwise you get that config files are not right) and finally AT-X. It seems that OS is on one memory block and cfg files on another...

First I have upgrade to 1.99 version (just to be sure) and then to 2.1.27...

One thing also, you must be very (and i mean very) fast at switching back power on IPO and "esc" pressing, or you will loosing xy of your time scratching your head what went wrong..

You can try to Copy/paste (from one Manager to another) users and other parts of config that is not critical such LCR, IP Routes, servcices, etc...

well, good luck in getting a free time...

 

[MrIPO]

Hi

Can you please connect Sysmonitor and produce a Route Table display and then post it.

Note, both .bin and .cfg files are stored in Flash Memory.

Only upgrade to the 1.99 loader on a 403 that has not been upgraded to 2.0 or 2.1. Basically the 1.99 loader reconfigures the Flash memory to be able to receive 2.0 or 2.1 firmware (Frees up space). Also allows after it has been done to beable to create a max .cfg size as the Manager Manual states.

Hope this helps

 

[NickBall]

Mr IPO

From Sys Monitor the only routing information I get, regardless of the filters I select is as follows;
9300584mS Monitor IP Routing Table Packet Size not as expected (expected 1204, got 436)

 

[MrIPO]

Under Routing select Route Table, it should then be displayed in sysmon

Umm anotherprivatebuild !!!

 

[NickBall]

Mr IPO

Under Routing Tab, Route Cahce, Routing Table & Routing Table changes selected.
The ONLY Routing output from sysmon is as follows ...

0mS PRN: Monitor Started IP=192.168.0.116 IP 406 2.1(27) CPI
0mS PRN: LAW=A PRI=2, BRI=0, ALOG=0, ADSL=0 VCOMP=20, MDM=2, WAN=0, MODU=4 LANM=0 CkSRC=1 VMAIL=1(VER=2 TYP=1) CALLS=6(TOT=316)
996mS Monitor IP Routing Table Packet Size not as expected (expected 1204, got 436)
1702mS PRN: National Number in prefix 0
1705mS PRN: AdjustCount 1,0 -> cur=7 out=2 v=7 d=0
1710mS PRN: CMACDQueue::StatusAdded Main

 

[erniethr]

MrIPO,

"...Note, both .bin and .cfg files are stored in Flash Memory..."

Yup, but seems that they are not stored on the same place in one Flash Memory, maybe they are, but why AT-X command does not erase cfg files also?

I can confirm what has NickBall copy/pasted... 2.1.24 version in sysmon is showing what is selected, but 2.1.27 does not...

 

[IPGuru]

AT-X does not erase the cfg because if you did get a corrup bin file on a unit you may want to recover the IPO without trashing the useres CFG

 

[Morrack]

I'm having problems with a 406 running 2.1.27 that are very reminiscent of the old TFTP bug. I can't retrieve the config more than 3 or 4 times after a power cycle, DND (and other) buttons are not working, etc.

The thing is, it seemed to start after I made adjustments to the IP routes to get some remote hardphones on various subnets working (which they are btw).

I also tried to produce a routing table in sysmon and got the same errors reported above - expecting a certain number of bytes but actually receiving a much smaller number of bytes.

Has anyone found a solution to this yet?

Peter

 

[NickBall]

@ Morrack

We removed our default route - The one that wasn't working - Leaving the sub net specific routes in place.
Also changed TFTP away from our VMPro Server to another machine, running Avaya recommended TFTP Server. Rebooted IPO.
Re-added default route and rebooted again and this resolved the problem.
Reboot was done using manager on VMPro machine, connected directly to the IPO, no other manager apps running on the network. However when running a trace on IP Route table, we still get an error on number of bytes expected and received.
As it is now 'Working' I'm leaving it be .....

 

[NuggiFirst]

@erniethr

To delete the .cfg in Terminalmode, you also need AT-X4 on a 403.

 

[Spanning]

Delete the blank ip route

ip address blank
mask blank
gw blank
dest blank

delete it if you got it remove it and reboot.

 

[Morrack]

duh... customer has a second subnet so we added an IP Route a while back to accomodate it. 192.168.0.0 255.255.0.0. Well, guess what? It was the problem - it seems that with IP Routes the IPO doesn't do most/least specific matching, which I had expected it to. So the remotemanager entry of 192.168.99.0 and this new entry were interfering with each other.

Weird thing is it didn't seem to cause any problems until we had IP Hardphones connected.

Peter