IP500V2 Release 9 to Server Edition Virtual

[VTTD1870]

Had customer running on release 9 on IP500V2. Moved to Virtual machine sever Edition. SIP Trunks won't register. Had them coming in on LAN2 on IP500V2. Have same configure on Virtual but not working.

 

[tlpeter]

You need to be more specific as your info is lacking that
But configuring a SIP trunk on a server edition is nothing different to be honest.
I would have exported the trunk as binary and imported it on the server edition.
This way the settings could not have been changed.
Did the IP address change perhaps?


BAZINGA!

I'm not insane, my mother had me tested!

 

[VTTD1870]

I think we have some sort of routing issue. Have SIP coming in on LAN2. Cannot even ping from LAN2 to SIP Provider's gateway IP address on router 5 feet away.

 

[tlpeter]

I think you do.
What does your IP route look like?

BAZINGA!

I'm not insane, my mother had me tested!

 

[VTTD1870]

Customer moved from one location to another. Is it possible to roll back to original virtual machine before an changes were made to the configuration? Would that affect the SSID?

 

[tlpeter]

SSID depends on IP addresses and hostname but you can check that in the manual.
Hostname does change it for sure.

BAZINGA!

I'm not insane, my mother had me tested!

 

[derfloh]

SID depends on time zone also!

Sadly until today I got no answer if there are other Informations it depends on.

Once Avaya support desk wanted me to reinstall a virtual primary server. I asked if they guarantee that I get the same SID again so that licences will still work and from that point the support guy didn't want to give me a GO. So no one knows for sure? I think I will try it in our lab. Install, configure, delete the machine. Install and configure a new one on another host with same IPs and host names and time zone.

Two hours of work but useful to know what's possible or not.

Reinstall from scratch and wait one or two days for a license swap because you get a new SID is not an option. Especially in bigger Serber Edition solutions.

 

[VTTD1870]

I feel like there is a problem in routing. I cannot get sip trunks going on the customer's vm. I brought a R210 from our lab, I cannot get the sip trunksgoingon that either. However, I have no problem making the sip trunks work on our IP500 V2.

 

[VTTD1870]

In SSA I can ping lan1 address to lan2 address and the system that can successfully register sip trunks. I cannot ping from lan1 to lan2 on either of the server deployments.

 

[derfloh]

Did you set up the relations of Linux network interfaces (eth0/eth1) and IPO interfaces (LAN1/LAN2) in Web Management correct?

 

[tlpeter]

Does the system have the correct gateway?
Lan1 and Lan2 have the same gateway but you route your traffic with an IP route if lan2 needs a different gateway ofcourse.


BAZINGA!

I'm not insane, my mother had me tested!

 

[VTTD1870]

The network interfaces in web control look correct and they have the same gateway. The route we built in the lab ip500v2 is the same as the one built in the server.

 

[VTTD1870]

In sysmon it appears as though the sip invite is being initiated from lan1 instead of lan2.

 

[derfloh]

Have a look at my last post again...

 

[VTTD1870]

Eth0: 192.168.42.1 255.255.255.0 192.168.42.254
Eth1: 192.168.16.5 255.255.255.0 192.168.42.254

Ip route for sip (lan2):192.168.16.1 (sip gateway) from 192.168.16.5 (lan2)

 

[amriddle01]

But 42.254 is not a valid gateway for a 16.x addressed device, it can't work like that

 

[Smitty23]

On site with VTTD1870. We have the same IP address built on our demo unit and the SIP trunks come up right away. Should we still change this .254 address?
As far as the Linux network relation from eth/0 and eth/1 to LAN 1/ LAN 2, do we need to set up the sub interface section in the web portal?

 

[amriddle01]

The gateway is correct I imagine, but a 16.x device can't have a 42.x address as its gateway with a 24 bit mask, it needs a gateway in the same range....

 

[Smitty23]

Followed all of your collected advice and it paid off. Tried a few things and the SIP trunks have successfully registered. Thank you very much. That's the good news. The bad news is that we had an Avaya Engineer in the system last night (supposedly to help) and I believe he flipped the LAN1 and LAN2 settings on the IPO and did a reboot. We are now unable to communicate with 192.168.42.1. We can only talk on 192.168.16.5 which is not what we need. Is there a way for us to figure out what change he made and how to reverse it?

 

[amriddle01]

What is your IP range internally? Why does the IP you programme over important?