Colocation / Netzwerkkabel angeschlossen aber trotzdem keine Netzwerkverbindung

nog76

New Member
Hallo zusammen,

ich habe ein Problem mit einem Colocation-Server.
Dieser ist per ILO-IP erreichbar und ich kann per Remoteconsole zugreifen für die OS-Installation.
Auch die Netzwerkports sind verkabelt, die Netzwerkconfig auf die entsprechende IP etc. eingestellt, aber trotzdem ist keinerlei Netzwerkverbindung nach außen möglich.

Ich kann den Server weder von außen anpingen, noch von innen andere Systeme anpingen.

Geprüft wurde bereits:
- Firewall beim Provider ist offen
- Kabel sind definitiv angeschlossen (ethtool gibt z.B. auch Status linked aus)
- es wurden auch die anderen Netzwerkinterfaces probeweise angeschlossen mit gleichem Ergebnis

Wir sind inzwischen ziemlich ratlos; haben das Problem schon auf unser Debian-Image geschoben, aber auch eine Probeinstallation eines anderen OS (Ubuntu und sogar Windows) zeigten das gleiche Verhalten.

Der RZ-Betreiber behauptet weiterhin, dass alles korrekt auch am Switch freigeschalten ist.
Interessanterweise tritt das Problem auch mit 3 weiteren Servern auf, die in diesem RZ stehen.

Wer hat eine Idee, was man noch prüfen kann? Wie kann ich feststellen, ob uns z.B. der Switch blockiert?

Gruesse,
Chris
 
wie sind die network settings? Ip, subnet; default gateway.
dhcp oder manuell? welches hops folgen laut anbieter?
schon mal einen arping auf das default gateway durchgeführt?
 
Server steht bei einem Partnerunternehmen von uns in den USA.

Netzwerksettings (static) sind korrekt und schon x mal geprüft.
Code:
# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 2c:9e:c8:23:e9:8a
          inet addr:A.A.A.A  Bcast:A.A.A.159  Mask:255.255.255.224
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:312673 errors:0 dropped:0 overruns:0 frame:0
          TX packets:44 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:24398788 (23.2 MiB)  TX bytes:3048 (3.0 KiB)
          Interrupt:24
Code:
# ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
								1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
								1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes

Ping auf Gateway (B.B.B.B):
Code:
# ping B.B.B.B
PING B.B.B.B (B.B.B.B) 56(84) bytes of data.
From A.A.A.A icmp_seq=1 Destination Host Unreachable
From A.A.A.A icmp_seq=2 Destination Host Unreachable
From A.A.A.A icmp_seq=3 Destination Host Unreachable

Code:
# traceroute B.B.B.B
traceroute to B.B.B.B (B.B.B.B), 30 hops max, 60 byte packets
 1  myhost (A.A.A.A)  2990.670 ms !H  2990.325 ms !H  2990.165 ms !H
 
... und die Routen passen auch :

Code:
# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
A.A.A.0    	  0.0.0.0         255.255.255.224 U     0      0        0 eth0
0.0.0.0         B.B.B.B    		0.0.0.0         UG    0      0        0 eth0

B.B.B.B = Gateway
A.A.A.0 = Netzadresse
 
Code:
# arping B.B.B.B
ARPING B.B.B.B from A.A.A.A eth0
...
Sent 65 probes (65 broadcast(s))
Received 0 response(s)
 
für mich es ziemlich eindeutig, dass der Betreiber hier einen Fehler gemacht hat.
TCPDUMP vom ping und arping und ab als Beweis an den Betreiber.
 
Was sagt denn tcpdump auf dem Interface? Irgendwelcher Multicast oder Broadcast Traffic zu sehen? Eventuell Vlan Tags zu sehen?
 
So, Provider ist informiert und mit allen Gegenargumenten versorgt, die beweisen, dass das Problem doch auf deren Seite besteht.
 
Back
Top