ispCP - Board - Support
System Storage Crash - IP problem - Printable Version

+- ispCP - Board - Support (http://www.isp-control.net/forum)
+-- Forum: ispCP Omega Support Area (/forum-30.html)
+--- Forum: System Setup & Installation (/forum-32.html)
+--- Thread: System Storage Crash - IP problem (/thread-12586.html)



System Storage Crash - IP problem - nikolas22t - 01-04-2011 01:47 AM

After a hardware crash on my old datastore and successful recovery to new datastore , the only problem i have is with the IP address on eth0:2 , eth0:3 , eth0:5
my primary address works fine 91.xxx.xxx.32
the other ip 91.xxx.xxx.33 , 34,35 not working from the internet, interfaces are up , i can access the ip from any server in the same subnet but are not accessible through the internet , most probably is routing problem , is there any way to fix this ?

email error received:

Code:
A critical error just was encountered while executing function
virtual_netcard_add() in
/var/www/ispcp/engine/tools/ispcp-net-interfaces-mngr.

Error encountered was:

=====================================================================
Error while trying to add IP 91.xxx.xxx.33 to network card 'eth0'!
=====================================================================



RE: System Storage Crash - IP problem - motokochan - 01-05-2011 03:20 AM

If the IPs are already bound to the card, you'll see that error.

If you can access the server through the IPs on the local network, but from outside, that's certainly a routing problem. Most likely the gateway or a non-routed firewall has the old MAC addresses in memory and so the ARP table is incorrect. This is something you'll need to contact your network administrator to handle.


RE: System Storage Crash - IP problem - ephigenie - 01-05-2011 03:39 AM

(01-05-2011 03:20 AM)motokochan Wrote:  If the IPs are already bound to the card, you'll see that error.

If you can access the server through the IPs on the local network, but from outside, that's certainly a routing problem. Most likely the gateway or a non-routed firewall has the old MAC addresses in memory and so the ARP table is incorrect. This is something you'll need to contact your network administrator to handle.

you can fix that by using arpspoof ...

just use it a "friendly" way :
Code:
arpspoof -i eth0 -t <additional ip> <ip of gateway>

This worked for me in most cases, when switching hosts and gratious arps gets ignored for some unkown reason.