Hallo allerseits,
ich habe hier ein zeimlich nerviges Problem mit der Anbindung eines neuen Werkgeländes über einen 1721. Die Verbndung soll im Normalfall über eine WLAN-P2P Strecke hergestellt werden, im Backup-Fall soll eine VPN-Verbindung über eine SDSL-Leitung hergestellt werden. Dazu habe ich folgendes versucht:
- Das ADSL-Modem ist ausgeschaltet
- DSL 1 ist mit Layer IPOE und zugeordneter Adresse über einen Switch an einen Microsense Konverter angeschlossen der zu einem weiteren Konverter und dann zu einem OAP führt.
- DSL 2 ist mit Layer IPOE und zugeordneter Adresse direkt am SDSL-Modem des Providers angeschlossen.
- Ein VPN Tunnel zu einem anderen 1721 ist konfiguriert und funktioniert (Genauso angeschlossen).
- Backup-Verbindung mit Backup-Leitung VPN ist für die DSL-1 Strecke konfiguriert
- Ein Polling für DSL-1 mit dem Ende der WLAN-Bridge als Ziel ist konfiguiert.
Zu Anfang sieht das ganze gut aus. Der Router pollt, die Leitung steht. Starte ich nun den Router neu, oder hänge die WLAN-Bridge auf DSL-1 irgendwo ab passiert aber etwas ziemlich seltsames. Auch wenn die Leitung wieder steht bekomme ich im LAN-Monitor einen Layer 1 ICMP-Fehler angezeigt und die Leitung kommt nicht wieder in Gang. Das ganze passiert eben auch dann wenn ich den Router neu starte. Entferne ich nun den Polling Eintrag ist die Strecke sofort wieder aktiv....
Ok, dachte ich mir... dann bau ich das eben über den Load-Balancer. Funktioniert auch erstmal, bis zum reboot bzw. bis DSL-1 ein Problem hatte (Ist übrigens egal ob ich am Switch, am Microsense oder direkt den LWL ziehe). Nach dem aufstöpseln sind beide Leitungen aktiv doch der Router Trace meldet chronisch "No Channel available Frame Dropped".
Auch hier hilft es einfach die Default-Route vom LB entweder auf die Funkstrecke oder das VPN umzustellen und voila, die Pakete fliessen wieder.
Das ganze passiert an beiden Routern, die beide die 7.28 fahren.
Da ich nicht das erstemal sowas baue denke ich das ich irgendwo über eine der Neuheiten in der 7er stolpere..... doch wo ?
Grüße
Dirk
Layer 1 / ICMP Fehler in Verbindung mit Backup-Verbindung
Moderator: Lancom-Systems Moderatoren
Hmm, ich glaube ich bin da auf einen Bug gestossen.
Inzwischen habe ich an ganz anderer Stelle zwei weitere 1721 mit 7.28 bei denen das Layer 1 ICMP-Fehler Problem in Verbindung mit einem Polling-Eintrag auftritt.
Wenn das mal bitte jemand nachstellen könnte:
1. ADSL-Modem aus (An einem Router habe ich eine WLAN-Bridge, an den beiden anderen wo das Problem jetzt auftritt jeweils ein SDSL-Modem, einmal direkt, einmal mit einem HP 4108 Switch dazwischen)
2. DSL-1 mit Layer IPOE und fester IP-Adresse (Bei zwei von drei Routern ist das eine private Adresse, einmal eine öffentliche). De Geschwindigkeit für das DSL-Interface steht auf 99999 und hat eine Haltezeit von 9999.
3. Polling Eintrag auf einen entfernten Router über IP-Adresse. Bis auf die Adresse steht alles auf Default.
4. Routen habe ich bis auf die Default-Route keine in der Tabelle, wobei ich in zwei Fällen NAT an und bei der WLAN-Bridge aus habe.
5. Die Firewall ist aus (Wenn die an ist macht das aber auch keinen Unterschied).
6. Backup hab ich keins konfiguriert, macht aber auch keinen Unterschied.
Zu dem Zeitpunkt funktioniert alles. Der Router pollt, die Verbindung steht und alles ist gut. Mache ich den Router kurz stromlos (oder einen Neustart per do /o/c), oder trenne die Leitung vom Port ab dann war es das. Die Leitung steht im Lanmonitor auf einem Layer 1 ICMP Fehler, die LEDs des Ethernet-Ports blinken als wäre Wahnsinns-Traffic auf der Leitung und auf dem Switch sehe ich das ca. alle 10-15 Sekunden der Port kommt und geht.
Wenn ein Backup konfiguriert ist wird es nack kurzer Verzögerung aktiv, die Hauptleitung, obwohl intakt, kommt jedoch nie wieder ins Rennen.
Das einzige was ich tun muss um den Zustand zu beheben ist es den Polling-Eintrag zu entfernen. Einen Wimpernschlag später ist die Leitung dauerhaft wieder.
Wenn sich keine andere Lösung findet fahre ich nächste Woche vor Ort und werde einen der 1721 (Die sind alle schon mit der 7er gekommen) mal versuchsweise auf eine 6.32 umbauen (Neue Hardware Revision gab es in letzter Zeit keine, oder ?). Mit der 6er habe ich noch einige im Einsatz bei denen das definitiv nicht auftritt.
Ideen ?
Grüße
Dirk
Inzwischen habe ich an ganz anderer Stelle zwei weitere 1721 mit 7.28 bei denen das Layer 1 ICMP-Fehler Problem in Verbindung mit einem Polling-Eintrag auftritt.
Wenn das mal bitte jemand nachstellen könnte:
1. ADSL-Modem aus (An einem Router habe ich eine WLAN-Bridge, an den beiden anderen wo das Problem jetzt auftritt jeweils ein SDSL-Modem, einmal direkt, einmal mit einem HP 4108 Switch dazwischen)
2. DSL-1 mit Layer IPOE und fester IP-Adresse (Bei zwei von drei Routern ist das eine private Adresse, einmal eine öffentliche). De Geschwindigkeit für das DSL-Interface steht auf 99999 und hat eine Haltezeit von 9999.
3. Polling Eintrag auf einen entfernten Router über IP-Adresse. Bis auf die Adresse steht alles auf Default.
4. Routen habe ich bis auf die Default-Route keine in der Tabelle, wobei ich in zwei Fällen NAT an und bei der WLAN-Bridge aus habe.
5. Die Firewall ist aus (Wenn die an ist macht das aber auch keinen Unterschied).
6. Backup hab ich keins konfiguriert, macht aber auch keinen Unterschied.
Zu dem Zeitpunkt funktioniert alles. Der Router pollt, die Verbindung steht und alles ist gut. Mache ich den Router kurz stromlos (oder einen Neustart per do /o/c), oder trenne die Leitung vom Port ab dann war es das. Die Leitung steht im Lanmonitor auf einem Layer 1 ICMP Fehler, die LEDs des Ethernet-Ports blinken als wäre Wahnsinns-Traffic auf der Leitung und auf dem Switch sehe ich das ca. alle 10-15 Sekunden der Port kommt und geht.
Wenn ein Backup konfiguriert ist wird es nack kurzer Verzögerung aktiv, die Hauptleitung, obwohl intakt, kommt jedoch nie wieder ins Rennen.
Das einzige was ich tun muss um den Zustand zu beheben ist es den Polling-Eintrag zu entfernen. Einen Wimpernschlag später ist die Leitung dauerhaft wieder.
Wenn sich keine andere Lösung findet fahre ich nächste Woche vor Ort und werde einen der 1721 (Die sind alle schon mit der 7er gekommen) mal versuchsweise auf eine 6.32 umbauen (Neue Hardware Revision gab es in letzter Zeit keine, oder ?). Mit der 6er habe ich noch einige im Einsatz bei denen das definitiv nicht auftritt.
Ideen ?
Grüße
Dirk
Hi reuter
unabhängig von dem beschrieben Problem hast du noch ein weiteres, nämlich:
Wenn du keine Sperroute für Multicasts in der Routing-Tabelle hast, dann erzeugst du u.U. einen "Elektonenbeschleuniger", sobald auch nur ein IGMP-Paket in deinem Netz auftaucht (siehe hierzu auch: http://www.lancom-forum.de/ptopic,38645,igmp.html#38645)
Gruß
Backslash
unabhängig von dem beschrieben Problem hast du noch ein weiteres, nämlich:
das ist in einer 7.28 ein großer Fehler, da die 7.28 ein "Multicastrouting für Arme" unterstützt (siehe: http://www.lancom-forum.de/ptopic,38397,igmp.html#38397).Routen habe ich bis auf die Default-Route keine in der Tabelle,
Wenn du keine Sperroute für Multicasts in der Routing-Tabelle hast, dann erzeugst du u.U. einen "Elektonenbeschleuniger", sobald auch nur ein IGMP-Paket in deinem Netz auftaucht (siehe hierzu auch: http://www.lancom-forum.de/ptopic,38645,igmp.html#38645)
Gruß
Backslash
Hi Backslash,
Bisher ist in der Richtung bei uns nichts an Problemen aufgetaucht, und von den 8 Zweigstellen die mit 7.26 und 7.28 laufen hat bisher niemand in der Richtung Probleme gemeldet. Auch dort wo ich mit 7.28 und VRRP arbeite habe ich bisher ohne dier 224er Route keinen Stress gehabt.
Derzeit habe ich nur das im Thread beschriebene Problem, und das bin ich bisher nicht losgeworden. Und da wär nun schön zu wissen ob das eventuell an irgendeinem geänderten Verhalten im LCOS begraben liegt oder ich einfach nur wieder mal zu blöd bin die richtige Option anzuhaken
Bei zweiterem wüsste ich dann gerne welche
Grüße
Dirk
Ups, klingt auch nicht gut. Was tu ich nun aber wenn ich das nicht blocken darf, weil sonst Anwendungen wie Officescan oder die Lan Desk Management Suite definitiv nicht sauber funktionieren. ? Wenn ich dort mit der Standard-Multicast Route richtung Nirvana arbeite bekomme ich Stress bei der Verteilung von Richtlinien und Softwarepaketen.Wenn du keine Sperroute für Multicasts in der Routing-Tabelle hast, dann erzeugst du u.U. einen "Elektonenbeschleuniger"
Bisher ist in der Richtung bei uns nichts an Problemen aufgetaucht, und von den 8 Zweigstellen die mit 7.26 und 7.28 laufen hat bisher niemand in der Richtung Probleme gemeldet. Auch dort wo ich mit 7.28 und VRRP arbeite habe ich bisher ohne dier 224er Route keinen Stress gehabt.
Derzeit habe ich nur das im Thread beschriebene Problem, und das bin ich bisher nicht losgeworden. Und da wär nun schön zu wissen ob das eventuell an irgendeinem geänderten Verhalten im LCOS begraben liegt oder ich einfach nur wieder mal zu blöd bin die richtige Option anzuhaken
Bei zweiterem wüsste ich dann gerne welche
Grüße
Dirk
Hi reuter
Wenn du aber irgendwelche anderen Multicasts in deinem Netz hast, die das LANCOM nicht selbst abnimmt, passiert folgendes:
- Das Multicast-Paket im Netz wird an den Router weitergeleitet und geht von dort auf die Default-Route...
- die andere Seite empfängt das Paket und schickt es über seine Defaultroute wieder raus
Ergebnis: zigtausend IGMP-Pakete, die auf der WAN-Strecke hin und her laufen - da paßt dann auch kein ICMP-Polling mehr zwischen...
Nach Ablauf der TTL des Multicastpakets ist der Spuk vorbei - solange das Paket kein IGMP-Paket ist... IGMP-Pakete werden immer mit einer TTL von 1 weitergeleitet, weshalb sie niemals "herausaltern"...
Wenn du wirklich Multicasts benötigst, dann mußt du das ab der 7.28 so konfigurieren, wie in diesem (zugegebenermassen etwas langen) Thread beschrieben: http://www.lancom-forum.de/ptopic,38397,igmp.html#38397).
Gruß
Backslash
ich sag's mal so: Firmwaren vor 7.28 haben Multicasts sowieso nicht übertragen, daher kannst du auch vorher mit der Sperroute kein Problem gehabt haben...Ups, klingt auch nicht gut. Was tu ich nun aber wenn ich das nicht blocken darf, weil sonst Anwendungen wie Officescan oder die Lan Desk Management Suite definitiv nicht sauber funktionieren. ?
nun ja: VRRP greift das LANCOM auch selbst ab, weshalb das nicht über den Router geht....Auch dort wo ich mit 7.28 und VRRP arbeite habe ich bisher ohne dier 224er Route keinen Stress gehabt.
Wenn du aber irgendwelche anderen Multicasts in deinem Netz hast, die das LANCOM nicht selbst abnimmt, passiert folgendes:
- Das Multicast-Paket im Netz wird an den Router weitergeleitet und geht von dort auf die Default-Route...
- die andere Seite empfängt das Paket und schickt es über seine Defaultroute wieder raus
Ergebnis: zigtausend IGMP-Pakete, die auf der WAN-Strecke hin und her laufen - da paßt dann auch kein ICMP-Polling mehr zwischen...
Nach Ablauf der TTL des Multicastpakets ist der Spuk vorbei - solange das Paket kein IGMP-Paket ist... IGMP-Pakete werden immer mit einer TTL von 1 weitergeleitet, weshalb sie niemals "herausaltern"...
Wenn du wirklich Multicasts benötigst, dann mußt du das ab der 7.28 so konfigurieren, wie in diesem (zugegebenermassen etwas langen) Thread beschrieben: http://www.lancom-forum.de/ptopic,38397,igmp.html#38397).
Eine Möglichkeit ist nunmal die fehlende Multicastsperroute...Derzeit habe ich nur das im Thread beschriebene Problem, und das bin ich bisher nicht losgeworden. Und da wär nun schön zu wissen ob das eventuell an irgendeinem geänderten Verhalten im LCOS begraben liegt oder ich einfach nur wieder mal zu blöd bin die richtige Option anzuhaken
Gruß
Backslash
Hi Backslash,
ich habe die Multicast-Route wieder integriert, allerdings ohne Erfolg. Im LAN-Monitor sieht das wie im Anhang aus, wobei DSL-1 eine WLAN-Bridge ist, DSL-2 wäre SDSL für den VPN-Backup der Richtfunkstrecke. Der Screenshot ist kurz nach dem Neustart des Routers. Werfe ich nun den Polling-Eintrag weg steht die Verbindung sofort.
Grüße
Dirk
ich habe die Multicast-Route wieder integriert, allerdings ohne Erfolg. Im LAN-Monitor sieht das wie im Anhang aus, wobei DSL-1 eine WLAN-Bridge ist, DSL-2 wäre SDSL für den VPN-Backup der Richtfunkstrecke. Der Screenshot ist kurz nach dem Neustart des Routers. Werfe ich nun den Polling-Eintrag weg steht die Verbindung sofort.
Grüße
Dirk
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
So, ich denke ich habe etwas gefunden.
Und zwar gibt es in der 7er beim Polling das Feld für die Absender Adresse. Bisher stand dort nichts drin und keiner der wählbaren Einträge hatte irgendeinen Einfluss. Trage ich dort jedoch, wie unter den IP-Parametern der Verbindung, die feste externe Adresse des Interfaces ein, dann läuft der Laden wieder.
Ich konnte das bisher an zwei Routern, einer mit, einer ohne NAT auf der Route, nachstellen.
Grüße
Dirk
Und zwar gibt es in der 7er beim Polling das Feld für die Absender Adresse. Bisher stand dort nichts drin und keiner der wählbaren Einträge hatte irgendeinen Einfluss. Trage ich dort jedoch, wie unter den IP-Parametern der Verbindung, die feste externe Adresse des Interfaces ein, dann läuft der Laden wieder.
Ich konnte das bisher an zwei Routern, einer mit, einer ohne NAT auf der Route, nachstellen.
Grüße
Dirk
Hi reuter
Sobald du dort etwas einträgst, dann wird genau die dort eingetragene Adresse verwendet - bzw. wenn du dort ein ARF-Netz eingibst, dann wird die Adresse verwendet, die das LANCOM in diesem Netz hat.
Im allgemeinen reicht es aus, das Feld leer zu lassen. Es wird dann z.B. benötigt, wenn man mit ARF mehrere virtuelle Router aufzieht, die alle ihre eigenen (d.h. voneinander isolierten) VPP-Tunnel haben. Hier muß beim Polling tatsächlich angegeben werden, mit welcher Absenderadresse das Paket verschickt werden soll, damit es nicht gleich von den IPSec-Regeln verworfen wird...
Gruß
Backslash
wenn nichts in dem Feld steht, dann bestimmt das LANCOM die Absender-Adresse automatisch, so wie in allen früheren Firmwaren vor 7.2x auch.Und zwar gibt es in der 7er beim Polling das Feld für die Absender Adresse. Bisher stand dort nichts drin und keiner der wählbaren Einträge hatte irgendeinen Einfluss.
Sobald du dort etwas einträgst, dann wird genau die dort eingetragene Adresse verwendet - bzw. wenn du dort ein ARF-Netz eingibst, dann wird die Adresse verwendet, die das LANCOM in diesem Netz hat.
Im allgemeinen reicht es aus, das Feld leer zu lassen. Es wird dann z.B. benötigt, wenn man mit ARF mehrere virtuelle Router aufzieht, die alle ihre eigenen (d.h. voneinander isolierten) VPP-Tunnel haben. Hier muß beim Polling tatsächlich angegeben werden, mit welcher Absenderadresse das Paket verschickt werden soll, damit es nicht gleich von den IPSec-Regeln verworfen wird...
Gruß
Backslash
Hi Backslash,
das ganze tritt auch ohne IPSEC auf. Ganz banal eine DSL-Verbindung mit IPOE-Layer, fester IP, einer Polling Regel, bei der nur eine Ziel-IP eingetragen und der Rest im Standard belassen ist, und eine Default Route über die Verbindung, zusätzlich zu dem was schon defaultig in der Tabelle drin ist. Wenn die noch ohne NAT ist, dann tritt das Problem direkt nach dem Router-Neustart auf und verschwindet erst dann wenn man die Externe IP einträgt oder die Polling-Regel löscht. Mit NAT tritt das weniger häufiger auf, zumindest konnte ich das dort nicht immer reproduzieren.
Inzwischen musste ich leider feststellen das der Eintrag der externen IP zwar nun funktioniert, aber die nächste Untiefe gleich parat hält. Pinge ich nun eine Adresse aus dem externen Subnetz, in dem sich der Router befindet, an, dann stehen die Chance gut, das entweder wieder ein ICMP Fehler auftritt, der aber mit anderem Fehlercode, oder mein Test 1711er verabschiedet sich und startet neu, bekommt dann aber die Leitung wieder ins Rennen. Wenn die Meldungen vom Trace zeitlich hinkommen, dann passiert das genau in dem Moment wo der Router zusätzlich zum Ping seinen Poll-Ping absetzt.
Grüße
Dirk
das ganze tritt auch ohne IPSEC auf. Ganz banal eine DSL-Verbindung mit IPOE-Layer, fester IP, einer Polling Regel, bei der nur eine Ziel-IP eingetragen und der Rest im Standard belassen ist, und eine Default Route über die Verbindung, zusätzlich zu dem was schon defaultig in der Tabelle drin ist. Wenn die noch ohne NAT ist, dann tritt das Problem direkt nach dem Router-Neustart auf und verschwindet erst dann wenn man die Externe IP einträgt oder die Polling-Regel löscht. Mit NAT tritt das weniger häufiger auf, zumindest konnte ich das dort nicht immer reproduzieren.
Inzwischen musste ich leider feststellen das der Eintrag der externen IP zwar nun funktioniert, aber die nächste Untiefe gleich parat hält. Pinge ich nun eine Adresse aus dem externen Subnetz, in dem sich der Router befindet, an, dann stehen die Chance gut, das entweder wieder ein ICMP Fehler auftritt, der aber mit anderem Fehlercode, oder mein Test 1711er verabschiedet sich und startet neu, bekommt dann aber die Leitung wieder ins Rennen. Wenn die Meldungen vom Trace zeitlich hinkommen, dann passiert das genau in dem Moment wo der Router zusätzlich zum Ping seinen Poll-Ping absetzt.
Grüße
Dirk
Hallo Dirk,
Viele Grüße,
Jirka
Tritt das ebenfalls noch mit der neuen Firmware 7.30 auf?Pinge ich nun eine Adresse aus dem externen Subnetz, in dem sich der Router befindet, an, dann stehen die Chance gut, das entweder wieder ein ICMP Fehler auftritt, der aber mit anderem Fehlercode,
Danach bitte ein show bootlog (in Telnet eingeben) und hier posten.oder mein Test 1711er verabschiedet sich und startet neu,
Viele Grüße,
Jirka
Hallo Jirka,
nach Update auf die 7.30 kann ich den Absturz nicht mehr provozieren und auch im LANmonitor sehe ich die ICMP-Layer 1 Meldung nicht mehr. Die feste externe Absendeadresse beim Polling muss ich aber weiterhin eintragen, sonst tritt wieder das ursprüngliche Layer 1 - ICMP Problem auf.
Grüße
Dirk
nach Update auf die 7.30 kann ich den Absturz nicht mehr provozieren und auch im LANmonitor sehe ich die ICMP-Layer 1 Meldung nicht mehr. Die feste externe Absendeadresse beim Polling muss ich aber weiterhin eintragen, sonst tritt wieder das ursprüngliche Layer 1 - ICMP Problem auf.
Grüße
Dirk