OpenVZ sporadisch nicht erreichbare VMs

I

informant

Guest
Hallo, wir haben das Problem, dass sporadisch einige VMs auf dem Host nicht erreichbar sind. Es gibt in den Logs keine Fehlermeldungen. Auch die Ressourcen sind frei. Hat jmd. eine Idee, warum die VMs teilweise nicht erreichbar sein könnten? Nach einem Reboot der VM bzw. nach einiger Zeit warten sind diese dann wieder erreichbar. Status auf dem Host ist jedoch online.

Freue mich über Informationen. Vielen Dank.
 
Klingt nach doppelter IP- oder MAC-Adress-Vergabe.
Kommst du denn über die lokale Konsole noch an die nicht erreichbaren Maschinen ran? Wenn ja, versuche von denen mal rauszupingen und teste dann, ob sie wieder erreichbar ist.
 
Hallo, mit der lokalen Console das war ein super Tip.
Intern kann ich die VM anpingen.
Ich habe mich einfach mal auf der Maschine angemeldet und die Prozesse angesehen. Alles normal. Dann habe ich einfach mal den apachen neu gestartet. Und plötzlich ging es wieder. Zufall? Es ist hier noch Confixx drauf installiert. Zusammenhang?

Habt Ihr noch eine idee?

MfG


Hier noch die Cats:

Code:
cat /etc/sysctl.conf && cat /etc/network/interfaces
#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additonal system variables
# See sysctl.conf (5) for information.
#

#kernel.domainname = example.com

# Uncomment the following to stop low-level messages on console
#kernel.printk = 3 4 1 3

##############################################################3
# Functions previously found in netbase
#

# Uncomment the next two lines to enable Spoof protection (reverse-path filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1

# Uncomment the next line to enable TCP/IP SYN cookies
# See http://lwn.net/Articles/277146/
# Note: This may impact IPv6 TCP sessions too
#net.ipv4.tcp_syncookies=1

# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
#  Enabling this option disables Stateless Address Autoconfiguration
#  based on Router Advertisements for this host
#net.ipv6.conf.all.forwarding=1


###################################################################
# Additional settings - these settings can improve the network
# security of the host and prevent against some network attacks
# including spoofing attacks and man in the middle attacks through
# redirection. Some network environments, however, require that these
# settings are disabled so review and enable them as needed.
#
# Do not accept ICMP redirects (prevent MITM attacks)
#net.ipv4.conf.all.accept_redirects = 0
#net.ipv6.conf.all.accept_redirects = 0
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
# net.ipv4.conf.all.secure_redirects = 1
#
# Do not send ICMP redirects (we are not a router)
#net.ipv4.conf.all.send_redirects = 0
#
# Do not accept IP source route packets (we are not a router)
#net.ipv4.conf.all.accept_source_route = 0
#net.ipv6.conf.all.accept_source_route = 0
#
# Log Martian Packets
#net.ipv4.conf.all.log_martians = 1
#

net.ipv4.conf.all.rp_filter=1
net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.conf.default.forwarding=1
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.ip_forward=1
kernel.sysrq = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.eth0.proxy_arp=1
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

auto eth0
# The primary network interface
allow-hotplug eth0
iface eth0 inet static
        address 217.*.254.65
        netmask 255.255.254.0
        network 217.*.254.0
        broadcast 217.*.254.255
        gateway 217.*.254.1
        # dns-* options are implemented by the resolvconf package, if installed
        dns-nameservers 8.8.8.8 8.8.4.4 213.187.64.1 217.69.224.73
        dns-search andromeda.speedloc.de
 
Last edited by a moderator:
Mooooment. Du startest den Apache neu und dann geht alles wieder? Nun definiere erstmal dein "nicht erreichbar". Reden wir nun von dem gesamten Container oder nur von einzelnen Diensten darauf?
 
OT: Die Verschleierung der IP kannst du dir auch sparen. Macht uns nur das lesen schwer und bereitet dir unnötig arbeit. Zumal es in diesem Fall sowieso ein Kinderspiel ist, sie rauszubekommen: 217.69.254.65
Investiere die Zeit lieber in die Problemlösung. ;)
 
Hallo, von außen ist ist kein Ping auf die IP-Adresse möglich und auch kein Dienst erreichbar. Von intern schon. Tracert geht auch nciht bis zum Hostsystem und bleibt zuvor stehen. Alle anderen VMs auf dem Host laufne und sind erreichbar.
 
Das klingt ein bisschen nach doppelter MAC-Adresse... Hat das Problem erst mit dem Erstellen einer neuen VM angefangen?

Poste mal bitte die Ausgabe der.folgenden Befehle vor und während dem Problem:
Code:
ip neigh show
ip route show
 
Vielleicht klären wir erstmal eine Grundsätzliche Frage:
Nutzt du in den VEs venet oder veth? Denn das bedeutet auch für das Debugging 2 völlig unterschiedliche Wege.

Zuvor brauch man gar nicht weiter drüber spekulieren, ob nun doppelte MACs, ein Static-Next-Hop Routingproblem oder sonst was die Ursache ist.
 
Hallo,

ifconfig in der VM sagt venet und aufm Host ebenfalls venet und eine veth, da ein server eine eth0 emuliert bekommt für confixx.

Die Befehle von oben zeigen:

217.69.254.1 dev eth0 lladdr 00:a0:57:14:86:f5 REACHABLE
217.69.254.67 dev eth0 lladdr 00:1a:4b:af:8c:d2 REACHABLE

217.69.254.99 dev venet0 scope link
217.69.254.0/23 dev eth0 proto kernel scope link src 217.69.254.65
default via 217.69.254.1 dev eth0

in beiden Situationen.

MfG
 
Doppelt vergebene IPs auf mehrere VMs sind bei OpenVZ soweit gar nicht möglich, das lässt vzctl gar nicht erst zu.

An einer doppelten MAC Adresse kann es auch nicht liegen, da der Traffic auf dem Hostsystem via ethX rein und raus geht.

Bitte noch posten:

Code:
vzlist -a

//Edit: Die Netzwerkkonfiguration / Kernelkonfiguration sieht soweit gut aus.
 
Last edited by a moderator:
Welche von den VEs ist denn nun betroffen? Die mit venet oder die mit veth?
Ausgabe von "ifconfig -a" oder "ip a l" von Hostsystem und VE mit veth wäre praktisch.

@virtual2
Wenn er veth im Einsatz hat, sind doppelte MACs sehr wohl möglich. Auch doppelte IPs wären dann kein Problem. ;)
 
Hostsystem:

Code:
 ifconfig -a
eth0      Link encap:Ethernet  Hardware Adresse 00:1e:0b:4b:a1:b6
          inet Adresse:217.69.254.65  Bcast:217.69.254.255  Maske:255.255.254.0
          inet6-Adresse: fe80::21e:bff:fe4b:a1b6/64 Gültigkeitsbereich:Verbindung
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metrik:1
          RX packets:189752869 errors:0 dropped:0 overruns:0 frame:0
          TX packets:419780901 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:28962874728 (26.9 GiB)  TX bytes:61139207524 (56.9 GiB)
          Interrupt:18 Speicher:f8000000-f8012800

eth1      Link encap:Ethernet  Hardware Adresse 00:1e:0b:4b:a1:b2
          BROADCAST MULTICAST  MTU:1500  Metrik:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interrupt:19 Speicher:fa000000-fa012800

lo        Link encap:Lokale Schleife
          inet Adresse:127.0.0.1  Maske:255.0.0.0
          inet6-Adresse: ::1/128 Gültigkeitsbereich:Maschine
          UP LOOPBACK RUNNING  MTU:16436  Metrik:1
          RX packets:1092144 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1092144 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0
          RX bytes:700927350 (668.4 MiB)  TX bytes:700927350 (668.4 MiB)

venet0    Link encap:UNSPEC  Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          UP BROADCAST PUNKTZUPUNKT RUNNING NOARP  MTU:1500  Metrik:1
          RX packets:419019294 errors:0 dropped:0 overruns:0 frame:0
          TX packets:188909857 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:0[CODE]
RX bytes:53261966141 (49.6 GiB) TX bytes:25177696069 (23.4 GiB)

veth4130.0 Link encap:Ethernet Hardware Adresse 00:18:51:1b:b5:2b
inet6-Adresse: fe80::218:51ff:fe1b:b52b/64 Gültigkeitsbereich:Verbindung
UP BROADCAST RUNNING MULTICAST MTU:1500 Metrik:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:2 overruns:0 carrier:0
Kollisionen:0 Sendewarteschlangenlänge:0
RX bytes:384 (384.0 B) TX bytes:244 (244.0 B)
[/CODE]

betroffene VM:

Code:
 ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:18:51:f7:8d:19
          inet addr:217.69.254.99  Bcast:0.0.0.0  Mask:255.255.255.255
          inet6 addr: fe80::218:51ff:fef7:8d19/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4 errors:0 dropped:0 overruns:0 frame:0
          TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:244 (244.0 B)  TX bytes:384 (384.0 B)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:1486 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1486 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:252701 (246.7 KiB)  TX bytes:252701 (246.7 KiB)

venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:127.0.0.1  P-t-P:127.0.0.1  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          RX packets:43378 errors:0 dropped:0 overruns:0 frame:0
          TX packets:44913 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:17124206 (16.3 MiB)  TX bytes:27521206 (26.2 MiB)

venet0:0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:217.69.254.99  P-t-P:217.69.254.99  Bcast:0.0.0.0  Mask:255.255.255.255
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
 
Wie du ansich selbst bemerken solltest, ist 217.69.254.99 in dem Container ein mal unter eth0 und ein mal unter venet0:0 up.
 
Hallo, so muss das ja auch sein, da Confixx nur per eth erreichbar/nutzbar ist. Da es virtualisiert und gemappt ist, spielt es meines Wissens nach keine Rolle. Confixx wird eh abgelöst, von daher wird das Problem sich nicht mehr lange hinziehen. Informativ ob es wirklich daran liegt wäre es dennoch, da es ja nur sporadisch ist und nicht ständig, was es ja bei Doppelnutzen wäre :cool:
 
Back
Top