Einfaches Loadbalancing mit 3 NICs, OPT1 geht nicht



  • Hallo,

    ich habe eine pfSense Kiste mit 3 NICs eingerichtet und moechte ueber 2 verschiedene DSL-Leitungen Loadbalancing betreiben. Setup sieht in etwa folgendermassen aus:

    /(DHCP WAN) - (192.168.11.1 - DSL-Modem) - Inet1
    192.168.2.1 - LAN pfSense Box
                                            (DHCP OPT1) - (192.168.12.1 - DSL-Modem) - Inet2

    Die beiden Modems sind DLink Modelle (321B und 380T) und arbeiten im Bridge-Modus mit DHCP enabled.
    Soweit sogut, pfSense laeuft, beide NICs bekommen ihre IP-Adresse zugeweisen (jeweils die oeffentliche IP des Providers) und ueber WAN bekomme ich auch eine Verbindung ins Inet.
    OPT1 ist aber scheinbar tot, da geht garnix, auch kein Ping, weder ueber Diagnostics->Ping in der Weboberflaeche noch wenn ich mich ueber SSH einlogge und es von da aus mit 'ping -S 192.168.12.2 aaa.bbb.ccc.ddd' versuche. Entsprechend zeigt auch der Loadbalancer Status OPT1 meistens!! als offline an. Ich hab inzwischen alles moegliche versucht, die NICs ausgetauscht und umgesteckt, die Modems vertauscht und das halbe Inet nach aehnlichen Problembeschreibungen durchforstet.
    Ich habe sogar eines der Modems durch einen DSL Router von USRobotics ersetzt - gleicher Fehler, WAN geht immer, OPT1 nie!

    Achja ich vergass zu erwaehnen, ich benutze pfSense 1.2 Release.

    P.S. sorry wenn das ganze komisch aussieht, Preview funktioniert bei mir weder im Firefox noch in Opera :S



  • Sind die beiden WAN's vom gleichen provider/gleiches subnet/gleicher gateway?
    Dann funktioniert es nämlich nicht.



  • Danke fuer die prompte Antwort, beide DSL Leitungen sind bei T-Online.
    Gibts da keinen anderen Workaround ausser den Wechsel einer der beiden Leitungen zu einem anderen Provider?



  • Du kannst eines der modems nicht als bridge betreiben.
    Dabei wird das modem zu einem primitiven router, welcher eine private ip-range intern hat.
    Damit kannst du das zweite WAN "pseudomässig" in ein anderes subnet verschieben, was aber schon reicht.



  • Ich habe, wie schon erwaehnt, auch probiert eines der beiden Modems durch einen USRobotics DSL-Router (kein Modem!) zu ersetzen, das Ergebnis war jedoch das gleiche. Wie erklaert sich das? Oder hab ich was falsch verstanden?



  • Was für eine monitor IP verwendest du für opt1?



  • hab schon alles moegliche ausprobiert, irgendeine normalerweise erreichbare IP im Inet, zB einen oeffentlichen DNS 194.25.2.129 oder einer unserer Root Server.



  • Die monitor IP sollte der erste Hop nach dem gateway deines ISP's sein.

    "Irgendeine IP" aus dem Netz kann unzuverlässig sein.
    Aufgrund der monitor IP wird entschieden ob der link on- oder offline ist.



  • ich habe die Monitoring IPs natuerlich vorher jeweils kurz angepingt um sicher zu gehen dass sie da sind, unter Status->Load Balancer im Webgui werden ja auch beide Verbindungen als online angezeit - aber wenn ich 'von Hand' ueber OPT1 pingen will gehts nicht, und es findet auch keinerlei Traffic auf OPT1 statt.



  • Was meinst du mit "von hand" pingen?
    Den default gateway in der firewal-rule auf OPT1 legen?

    Hast du auch eine statische route für mindestens einen DNS eintrag auf OPT1 erzeugt?
    Wenn WAN down ist will du ja weiterhin in der lage sein namen aufzulösen.



  • mit 'von hand' meine ich sowohl unter Diagnostics->Ping einfach OPT1 waehlen und eine beliebige aber als online bekannte IP anpingen, als auch ueber SSH und dann mit 'ping -S IP.ADDR.VON.OPT1 www.bekannte-ip.de'

    ok das mit der firewall rule werd ich gleich mal probieren! :)

    statische route auf OPT1 - nein, werd ich auch mal probieren…

    kleines Update meiner Beobachtungen: nachdem ich pfSense neugestartet habe und das Modem am WAN interface etwas laenger fuer den Login brauchte ist die Situation genau umgekehrt, d.h. OPT1 hat den gesamten Traffic, WAN geht nix - beide werden unter Status->LoadBalancer als online angezeigt  ???



  • pings von der pfSense her benutzen immer die routing-table.
    Wenn du solche tests machen willst musst du mit einer eigenen testmachine von hinter der pfSense arbeiten.
    Wenn du verschiedene traces machst, kannst du sehen wie die verschiedenen connections auf die beiden WAN's gebalanced werden.




  • ok, gibt es denn irgendeine Moeglichkeit, z.B. ueber die Shell, festzustellen ob ueber OPT1 was geht ohne eine extra Testmaschine hinter pfSense zu klemmen? Mit traceroute? Kannst du mir da bitte ein Beispiel geben, ich gelange langsam an meine Grenzen :P

    Nur um nochmal Unklarheiten zu beseitigen, ich hab inzwischen alles nochmal platt gemacht, normales Setup mit LAN->WAN ohne Loadbalancing, alles auf default. WAN und OPT1 sind per DHCP mit ihren Modems (192.168.11.1 und 192.168.12.1) verbunden. Wie pruefe ich nun die Verbindung von OPT1 nach draussen?



  • Naja du wirst ja wohl irgendwelche clients hinter der pfSense haben mit der du tests machen kannst, oder?

    Alternativ kannst du natürlich eine statische route für eine bestimmte IP auf den gateway von WAN2 einrichten.
    Anschliessend diese IP pingen und schauen ob's über das WAN2 geht.
    Oder du öffnest den port des webgui am WAN2 interface und versuchst von extern auf die IP des WAN2 zuzugreifen.
    Wenn du auf das webgui gelangst scheint WAN2 zu funktionieren.

    Oder was genau versuchst du denn zu testen?
    Einfach ob WAN2 läuft?



  • ja, ich wollte im Prinzip erstmal ganz unten anfangen und gucken was mit OPT1 ueberhaupt los ist.
    Inzwischen hab ich das Problem geloest!
    Dank deiner Hinweise und einiger seltsamer Systemlogs im pfSense weiss ich nun, dass das verwenden von 2 Modems im Bridged Modus beim gleichen Provider nicht nur das Loadbalancing verhindert sondern die ganze Kommunikation durcheinanderkommt (Stichwort ARP Requests und das aufloesen von Ethernet Adressen).
    Nachdem ich nochmal den Router drangeklemmt und, ganz wichtig!, danach pfSense neugestartet habe gings  ;D



  • Ja das ist so.
    Die routing table kann ja immer nur ein subnet pro interface darstellen.
    Wenn dann plötzlich das selbe subnet an zwei interfaces vorhanden ist geht das ganze routing durcheinander.

    Ich weiss nicht ob der neustart wirklich nötig war.
    Wahrscheinlich hätte ein
    "arp -d -a" (arp cache flushen) von der konsole gereicht.


Log in to reply