This is a heads-up and advisory - and also to see if other are having similar issues on R 12.0 SE on physical server (or any other arrangement).
Since installation we have had numerous issues with push notification server timeout, DNS lookup timeout, SMTP failure, VM SMTP failure - we have 7 Tier 4 tickets open. Yesterday, a Cisco Meraki engineer may have figure it all out.
Our routes are as follows:
0.0.0.0 0.0.0.0 192.168.10.1 LAN1 (192.168.10.15)
10.0.1.0 255.255.255.0 10.0.1.1 LAN2 (10.0.1.15)
In other words, we want all outside traffic heading out over LAN1. After running packet captures on the Meraki, we determined that the IPO is sending all traffic out over the LAN2/eth1 interface.
We received countless errors - DNS lookup timeout, APN push notification server timeout, SMTP connection timeout, VM SMTP connection timeout - some pushes worked, most didn't.
When we physically disconnected LAN2/eth1, traffic (all of the above types) started properly routing using the correct IP of 192.168.10.15 via the correct interface (LAN1/eth0) - and we have not had ONE error since this change.
Second issue: when the system reboots (either by pushing a restart config, rebooting using 7071, or power outage), the routes above get replaced with:
0.0.0.0 0.0.0.0 192.168.10.1 LAN1 (192.168.10.15) (no change)
0.0.0.0 0.0.0.0 10.0.1.1 LAN2 (10.0.1.15) (changed)
which is a conflict. We have to manually change the routes back.
Avaya says they've had a several customer reports of the second issue (let's call that the "reboot" issue). They were not sure if this was fixed in 12.1.
Avaya also advised against using eth1/LAN2 in general - they said that's leftover from 500v2 days and shouldn't be used unless absolutely necessary. They said it was meant for outside IP connection and has a firewall part of it and that's why it shouldn't be used. We are fine not using eth1/LAN2 - our concern is on reboot, it seems like the system wants to use that...
I am concerned if the machine reboots again, we won't be able to get in remotely/VPN because routes are screwed up!
- Has anyone had similar issues?
- Other posts about same issue (could not find any...)
- Is there a fix or workaround to either issue (other than disconnecting LAN2/eth1 - which we've done)?
- Is Avaya aware of any of these issue? (beyond what they told me - which is not an official position or documented)
- Is this fixed in 12.1?
Thanks.
Since installation we have had numerous issues with push notification server timeout, DNS lookup timeout, SMTP failure, VM SMTP failure - we have 7 Tier 4 tickets open. Yesterday, a Cisco Meraki engineer may have figure it all out.
Our routes are as follows:
0.0.0.0 0.0.0.0 192.168.10.1 LAN1 (192.168.10.15)
10.0.1.0 255.255.255.0 10.0.1.1 LAN2 (10.0.1.15)
In other words, we want all outside traffic heading out over LAN1. After running packet captures on the Meraki, we determined that the IPO is sending all traffic out over the LAN2/eth1 interface.
We received countless errors - DNS lookup timeout, APN push notification server timeout, SMTP connection timeout, VM SMTP connection timeout - some pushes worked, most didn't.
When we physically disconnected LAN2/eth1, traffic (all of the above types) started properly routing using the correct IP of 192.168.10.15 via the correct interface (LAN1/eth0) - and we have not had ONE error since this change.
Second issue: when the system reboots (either by pushing a restart config, rebooting using 7071, or power outage), the routes above get replaced with:
0.0.0.0 0.0.0.0 192.168.10.1 LAN1 (192.168.10.15) (no change)
0.0.0.0 0.0.0.0 10.0.1.1 LAN2 (10.0.1.15) (changed)
which is a conflict. We have to manually change the routes back.
Avaya says they've had a several customer reports of the second issue (let's call that the "reboot" issue). They were not sure if this was fixed in 12.1.
Avaya also advised against using eth1/LAN2 in general - they said that's leftover from 500v2 days and shouldn't be used unless absolutely necessary. They said it was meant for outside IP connection and has a firewall part of it and that's why it shouldn't be used. We are fine not using eth1/LAN2 - our concern is on reboot, it seems like the system wants to use that...
I am concerned if the machine reboots again, we won't be able to get in remotely/VPN because routes are screwed up!
- Has anyone had similar issues?
- Other posts about same issue (could not find any...)
- Is there a fix or workaround to either issue (other than disconnecting LAN2/eth1 - which we've done)?
- Is Avaya aware of any of these issue? (beyond what they told me - which is not an official position or documented)
- Is this fixed in 12.1?
Thanks.