OVH Community, your new community space.

Virtuelle IPs kein ausgehendes Routing


maxs97
30.09.14, 19:38
Hey,

bitte prüfe deine Konfiguration mal mit folgender Anleitung gegen; http://hilfe.ovh.de/BridgeClient
Andere Konfigurationen können, bzw haben funktioniert. Seit einiger Zeit stellt OVH anscheinend das Netzwerk um, sodass nun die oben genannte Konfiguration die einzig funktionalle zu sein scheint. Auf den ersten Blick fällt mir da bei dir der Broadcast auf. Das das ganze dann durch eine Neuzuweisung wieder funktioniert kann ich mir allerdings nicht erklären.

peterdoo
30.09.14, 16:44
Die Konfiguration sieht so aus:

eth0 Link encap:Ethernet HWaddr 02:00:00:90:4f:0c
inet addr:188.165.186.216 Bcast:0.0.0.0 Mask:255.255.255.255
inet6 addr: 2001:41d0:2:9d77::216/80 Scope:Global
inet6 addr: fe80::ff:fe90:4f0c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:519802 errors:0 dropped:219 overruns:0 frame:0
TX packets:510460 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:165677845 (158.0 MiB) TX bytes:224018638 (213.6 MiB)

eth1 Link encap:Ethernet HWaddr 00:15:5d:d2:77:00
inet addr:192.168.215.254 Bcast:192.168.215.255 Mask:255.255.255.0
inet6 addr: fe80::215:5dff:fed2:7700/64 Scope:Link
inet6 addr: 2001:41d0:2:9d77:fab::216/80 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:552145 errors:0 dropped:0 overruns:0 frame:0
TX packets:496287 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:207817999 (198.1 MiB) TX bytes:149117926 (142.2 MiB)

Die IPV4 und die MAC vom eth0 sind im OVH Manager verknüpft. Seit mehr als einem Jahr unverändert und so lange gab es auch keine Probleme damit. Bis Freitag. Bleibt es mal stehen, sieht man Folgendes mit tcpdump -ennti eth0 arp or icmp :

40:55:39:8d:f8:26 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.0.107 tell 192.168.0.1, length 46
40:55:39:8d:f8:26 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.0.107 tell 192.168.0.1, length 46
40:55:39:8d:f8:26 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.0.107 tell 192.168.0.1, length 46
40:55:39:8d:f8:26 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.0.107 tell 192.168.0.1, length 46
40:55:39:8d:f8:26 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.0.107 tell 192.168.0.1, length 46
40:55:39:8d:f8:26 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.0.107 tell 192.168.0.1, length 46
40:55:39:8d:f8:26 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.0.107 tell 192.168.0.1, length 46
00:02:b3:ee:7a:8f > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 188.165.210.254 tell 188.165.210.4, length 46
02:00:00:90:4f:0c > 00:07:b4:00:01:01, ethertype ARP (0x0806), length 42: Request who-has 188.165.210.254 tell 188.165.186.216, length 28
ec:30:91:e0:df:80 > 02:00:00:90:4f:0c, ethertype ARP (0x0806), length 60: Reply 188.165.210.254 is-at 00:07:b4:00:01:02, length 46
00:25:90:7f:27:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 188.165.210.254 tell 188.165.210.119, length 28
00:25:90:7f:27:78 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: Request who-has 188.165.210.250 tell 188.165.210.119, length 28
00:25:90:7d:19:70 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 188.165.210.254 tell 188.165.210.211, length 46
ec:30:91:e0:df:80 > 02:00:00:90:4f:0c, ethertype IPv4 (0x0800), length 60: 27.25.3.30 > 188.165.186.216: ICMP echo request, id 10209, seq 30763, length 8
02:00:00:90:4f:0c > 00:07:b4:00:01:01, ethertype IPv4 (0x0800), length 42: 188.165.186.216 > 27.25.3.30: ICMP echo reply, id 10209, seq 30763, length 8
40:55:39:8d:f8:26 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.0.107 tell 192.168.0.1, length 46
40:55:39:8d:f8:26 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.0.107 tell 192.168.0.1, length 46
40:55:39:8d:f8:26 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.0.107 tell 192.168.0.1, length 46
40:55:39:8d:f8:26 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 192.168.0.107 tell 192.168.0.1, length 46

Man sieht, dass ARP schön antwortet. Ping (ICMP) kommt rein, wird beantwortet und zum Router verschickt, kommt jedoch bei der Ziel-IP nicht an, egal welche das ist. Genausowenig wie TCP und UDP (V4). IPV6 funktioniert.

Nehme ich jetzt im OVH Manager bei einer anderen IP, die demselben Server zugewiesen ist, aber gar nicht im Betrieb ist (die VM läuft nicht) die virtuelle MAC weg oder füge eine virtuelle MAC hinzu, läuft sofort wieder alles. Die Zuweisung der IP/MAC von eth0 fasse ich im OVH Manager gar nicht an. tcpdump sieht, wenn es wieder funktioniert, gleich aus, nur dass dann die Pakete auch bei den Ziel-IPs ankommen.

Die ARP Anfragen 192.168.0.x kommen definitiv aus dem OVH Netz und haben nichts mit meinem Server zu tun. Die MAC-Adressen sind vom Cisco. Entferne ich die zuweisung der MAC zu meiner IP im OVH Manager, verschwinden diese ARP Anfragen sofort aus dem tcpdump.

maxs97
30.09.14, 15:06
Am besten du schickst uns einmal die Konfiguration deiner Ip-Adressen. Dann können wir besser helfen.

peterdoo
30.09.14, 11:45
Hallo,

beim Server habe ich eine virtuelle MAC für mehrere Failover IPs konfiguriert. Seit Freitag passiert es sehr oft (heute schon mehrmals), dass die Pakete von dieser MAC Adresse vom Router 188.165.210.254 ab einem Moment nicht mehr weitergeleitet werden. Die "normale" MAC des Servers funktioniert in dem Zustand weiterhin normal. Auch IPV6 auf der virtuellen MAC funktioniert weiterhin problemlos. Mit tcpdump sehe ich, dass der Router 188.165.210.254 auf die ARP Anfragen der virtuellen MAC antwortet. Alle Pakete von Außen kommen zu der virtuellen MAC. Nur alle IPV4 Antworten und Sonstiges IPV4, das die virtuelle MAC an den Router 188.165.210.254 sendet, versinken einfach und kommen nirgendwo an.

Inzwischen habe ich herausgefunden, dass es reicht im OVH ManagerV6 bei irgendeiner Failover IP die virtuelle MAC zu löschen oder neu hinzufügen. Ab dann funktioniert sofort wieder alles. Meine Konfiguration der Virtuellen MAC/IPs ist seit mehr als einem Jahr unverändert. Es kommt keine Benachrichtigung von OVH, dass irgendwas abgeschaltet wurde und unter travaux.ovh.net sehe ich nichts Verdächtiges. Soll man davon ausgehen, dass der OVH Router nicht korrekt funktioniert? Oder kann es eine absichtliche Sperre von OVH sein?