Hallo allerseits,
ich habe immer noch mit meinem Problem zu kämpfen, das rücklaufende Pakete auf meiner any-Regel auflaufen und mir gehen so langsam die Ideen, und wahrscheinlich auch die Hotline-Kollegen, aus, weswegen ich hier nochmal nachfrage ob irgendwer das Problem kennt und gelöst hat.
Was schon probiert wurde:
- Verbindungswiederherstellung in allen Variationen
- Any Regel auf die Default-Route festlegen
- Loadbalancer testweise per Routing-Regel übersteuern und nur eine
Leitung nutzen.
- Das VPN für die Weiterleitung der zweiten Leitung zum LC ist weg,
wurde durch ein VLAN ersetzt und läuft jetzt per IPoE auf.
- IDS auf weiterleiten
- Einstellungen für die Handhabung von Fragmenten geändert.
- Konfig drucken / Factory reset / neu machen
Das Ergebnis ist das gleiche...
Ich öffne den IE, gebe www.google.de ein und sehe (zu oft, aber auch nicht immer) einen Wimpernschlag später die Meldung das das LC ein Paket vom DNS Server zum Proxy auf der Any-Regel abgelehnt hat (Geht sehr schön, weil ich momentan der einzige Nutzer bin). Bei DNS ist das noch unkritisch, das versucht der Proxy-Server erneut und es dauert dann 2-3 Sekunden länger als nötig. Be HTTP sieht das anders aus. Da kommt sofort das Paket vom Server zurück, stolpert über das LC und der Proxy wartet bis zu seinem Timeout, mit dem Effekt das die Browser-Sitzung hängen bleibt. Das passiert mir, als einzigem Nutzer, schon beim testen recht häufig, wie das aussieht wenn ich da 500 people drauflasse will ich nicht wissen.
Ehrlich, wenn ich nicht jemanden finde der das in den Griff bekommt, dann kann ich nur noch den uns betreuenden Aussendienstler anklingeln, über Rückgabe verhandeln, meinen Urlaub streichen und den Cisco wieder reaktivieren, was ziemlich blöd wäre da ich bei uns in der Firma vor nicht allzu langer Zeit ziemlich für den LC-Einsatz getrommelt habe.
Grüße,
Dirk
Immer noch Probleme mit Antwortpaketen....
Moderator: Lancom-Systems Moderatoren
Hi reuter
Gruß
Backslash
irgendwie kann ich mir das nicht vorstellen - es sei denn die Session, die durch das ursprüngliche Paket erzeugt wurde wäre schon herausgealtert.ich habe immer noch mit meinem Problem zu kämpfen, das rücklaufende Pakete auf meiner any-Regel auflaufen
Wenn eine Session bereits herausgealtert ist, dann bringt die Sitzungswiederherstellung nichts (sie übersteuert nur die Zustandsverfolgung einer Session)Was schon probiert wurde:
- Verbindungswiederherstellung in allen Variationen
wenn die Antwort aus dem Internet kommt, dann ändert das auch nichts (da sie ja über die Deafultroute kommt...)- Any Regel auf die Default-Route festlegen
das hilft alles nichts, wenn die Firewall die urspüngliche Session nicht findet....
Mach doch mal einen Router- und Firewall-Trace davon (trace # ip-router firewall). Solange du der einzige Nutzer bist, sollte das kein Problem sein..Ich öffne den IE, gebe www.google.de ein und sehe (zu oft, aber auch nicht immer) einen Wimpernschlag später die Meldung das das LC ein Paket vom DNS Server zum Proxy auf der Any-Regel abgelehnt hat (Geht sehr schön, weil ich momentan der einzige Nutzer bin). Bei DNS ist das noch unkritisch, das versucht der Proxy-Server erneut und es dauert dann 2-3 Sekunden länger als nötig. Be HTTP sieht das anders aus. Da kommt sofort das Paket vom Server zurück, stolpert über das LC und der Proxy wartet bis zu seinem Timeout, mit dem Effekt das die Browser-Sitzung hängen bleibt.
Gruß
Backslash
Hi Backslash,
genau die beiden Traces habe ich aufgesetzt und dann diesen seltsamen Effekt beobachtet, z.B. bei der DNS Auflösung.
Da kommt ein Paket auf der virtuellen IP vom VRRP in der DMZ rein, wird von dort über meine DNS_PROXY_OUT Regel auf die default Route LB (Load Balancer) geroutet, kommt dann innerhalb von 60-80 ms (Laut Wireshark) auf einem der beiden WAN Interfaces zurück und wird dann, wie es sein soll, auf das physisches DMZ Interface des VRRP Masters weitergeleitet und landet beim Proxy. Manchmal allerdings bringt der Firewall-Trace dann raus das die Deny-Any Regel gezogen hat und das Paket verworfen wurde. Bei HTTP ist es ähnlich, nur passiert es dort mal beim ACK während der Verbindungsaufnahme, mal beim ersten echten Datenpaket, wobei dann noch eine ganze Batterie von Paketen aufläuft. Das erste auf der ANY, die weiteren werden mit der Info das keine Sitzung zu dem Paket existiert un die Sitzungswiederherstellung deaktiviert ist verworfen.
Letzter Stand der Akte X ist, das der Verdacht aufkam das die Anzahl der halboffenen Sitzungen mit dem default von 100 zu klein sein könnte, wenn der Proxy eventuell auf einem Schlag seinen Cache aktualisiert. Da ich das IDS auf "weiterleiten" + Mail gestellt, aber nie eine entsprechende Mail gesehen habe, ist meine Hoffnung da nicht allzu groß, aber immerhin ein neuer Ansatz.
Öhm, was mir grade einfällt. Wie ermitteln die LCs die Timings ? Über den CPU Takt oder gibt es da irgendeinen Baustein der das regelt ? Nicht das der 7011er eine Macke hat und ich hier nach Phantomen buddel. Hmm... Das ist eine Idee. Ich nehme einfach Montag mal den anderen 7011, der momentan als Standby arbeitet, nach vorne, der müsste ja das gleiche Verhalten an den Tag legen.
Grüße
Dirk
genau die beiden Traces habe ich aufgesetzt und dann diesen seltsamen Effekt beobachtet, z.B. bei der DNS Auflösung.
Da kommt ein Paket auf der virtuellen IP vom VRRP in der DMZ rein, wird von dort über meine DNS_PROXY_OUT Regel auf die default Route LB (Load Balancer) geroutet, kommt dann innerhalb von 60-80 ms (Laut Wireshark) auf einem der beiden WAN Interfaces zurück und wird dann, wie es sein soll, auf das physisches DMZ Interface des VRRP Masters weitergeleitet und landet beim Proxy. Manchmal allerdings bringt der Firewall-Trace dann raus das die Deny-Any Regel gezogen hat und das Paket verworfen wurde. Bei HTTP ist es ähnlich, nur passiert es dort mal beim ACK während der Verbindungsaufnahme, mal beim ersten echten Datenpaket, wobei dann noch eine ganze Batterie von Paketen aufläuft. Das erste auf der ANY, die weiteren werden mit der Info das keine Sitzung zu dem Paket existiert un die Sitzungswiederherstellung deaktiviert ist verworfen.
Letzter Stand der Akte X ist, das der Verdacht aufkam das die Anzahl der halboffenen Sitzungen mit dem default von 100 zu klein sein könnte, wenn der Proxy eventuell auf einem Schlag seinen Cache aktualisiert. Da ich das IDS auf "weiterleiten" + Mail gestellt, aber nie eine entsprechende Mail gesehen habe, ist meine Hoffnung da nicht allzu groß, aber immerhin ein neuer Ansatz.
So gehts mir auch. Ich konfiguriere jetzt set fast einer Dekade Firewalls diverser Hersteller und habe hier neben zwei 8011 noch mehrere Dutzend 17xx und 18xx im Einsatz, sowas hab ich aber noch nie gesehen.irgendwie kann ich mir das nicht vorstellen - es sei denn die Session, die durch das ursprüngliche Paket erzeugt wurde wäre schon herausgealtert.
Öhm, was mir grade einfällt. Wie ermitteln die LCs die Timings ? Über den CPU Takt oder gibt es da irgendeinen Baustein der das regelt ? Nicht das der 7011er eine Macke hat und ich hier nach Phantomen buddel. Hmm... Das ist eine Idee. Ich nehme einfach Montag mal den anderen 7011, der momentan als Standby arbeitet, nach vorne, der müsste ja das gleiche Verhalten an den Tag legen.
Grüße
Dirk
So, ein kleines Update zu meinem Problem.
Das Problem tritt nur über die LB-Route auf, niemals wenn eine einzelne Leitung Ziel der Default-Route ist.
Eine meiner Leitungen im Bündel war eine VPN-Leitung. Interessanterweise wird die niemals vom LB aufgebaut, wenn der Aufbau von der Gegenseite durchgeführt wurde aber durchaus genutzt. Aufgrund anderer Probleme (Variable MTUs auf der Funkstrecke, die den ESP-Paketen nicht so gut tat, aber nicht direkt mit der Problem zusammenhängt, da der Fehler auch ohne Funke dazwischen auftritt) habe ich mich zwischenzeitlich um eine andere Lösung anstelle des VPN gekümmert, so das ich nun eine SDSL und eine IPoE Leitung im Bündel habe. Interessanterweise trat das Problem danach nicht mehr ständig, sondern nur noch periodisch auf.
Nach vielen rumgesuche am neuen Proxy, den ich als Verursacher im Auge hatte brachte mich ein längerer Mittschnitt des Vekehrs auf einen anderen Auslöser. Unser Mail-Gateway. Dort schlummern ständig 600+ Schrottmails, die sich nicht zustellen lassen und die, aufgrund gefakter Absender, auch nicht zurückgesendet werden können. Startete der Mail-Server seinen Queue-Run, dann wurden massiv (tote) Verbindungen aufgebaut und das LC musste anscheinend kurzfristig mehr Verbindungen schlucken als gut war, und obwohl "übertragen" gewählt war wurde bei >100 Aufbauten dicht gemacht. Ich habe den Wert nun auf 1000 erhöht (im Status ist die Tabelle für Aufbauten trotzdem nur 100 gross, ist das normal ?), und seitdem ist Ruhe eingetreten, Interessanterweise ist die Erweiterung der Einstellung NUR im LB-Betrieb notwendig, warum auch immer.
Grüße
Dirk
Das Problem tritt nur über die LB-Route auf, niemals wenn eine einzelne Leitung Ziel der Default-Route ist.
Eine meiner Leitungen im Bündel war eine VPN-Leitung. Interessanterweise wird die niemals vom LB aufgebaut, wenn der Aufbau von der Gegenseite durchgeführt wurde aber durchaus genutzt. Aufgrund anderer Probleme (Variable MTUs auf der Funkstrecke, die den ESP-Paketen nicht so gut tat, aber nicht direkt mit der Problem zusammenhängt, da der Fehler auch ohne Funke dazwischen auftritt) habe ich mich zwischenzeitlich um eine andere Lösung anstelle des VPN gekümmert, so das ich nun eine SDSL und eine IPoE Leitung im Bündel habe. Interessanterweise trat das Problem danach nicht mehr ständig, sondern nur noch periodisch auf.
Nach vielen rumgesuche am neuen Proxy, den ich als Verursacher im Auge hatte brachte mich ein längerer Mittschnitt des Vekehrs auf einen anderen Auslöser. Unser Mail-Gateway. Dort schlummern ständig 600+ Schrottmails, die sich nicht zustellen lassen und die, aufgrund gefakter Absender, auch nicht zurückgesendet werden können. Startete der Mail-Server seinen Queue-Run, dann wurden massiv (tote) Verbindungen aufgebaut und das LC musste anscheinend kurzfristig mehr Verbindungen schlucken als gut war, und obwohl "übertragen" gewählt war wurde bei >100 Aufbauten dicht gemacht. Ich habe den Wert nun auf 1000 erhöht (im Status ist die Tabelle für Aufbauten trotzdem nur 100 gross, ist das normal ?), und seitdem ist Ruhe eingetreten, Interessanterweise ist die Erweiterung der Einstellung NUR im LB-Betrieb notwendig, warum auch immer.
Grüße
Dirk