carp - interface tracking?

[scip]

Hi,

folgendes Setup:

          Internet
             |
       +-----+------+
       |            |
     fxp0         fxp0
foo   --           --   bar
     fxp1         fxp1
       |            |
       +-----+------+
             |
            LAN

Auf beiden OpenBSD Firewalls foo und bar habe ich je ein Carp Interface carp0 mit einer gemeinsamen IP im Netz von fxp1 (LAN) eingerichtet. foo ist der Master.

Mein Problem ist nun, was passiert, wenn fxp0 auf foo down geht? das Carp Interface bekommt davon natürlich nix mit, bleibt UP und bleibt Master, somit sind alle User offline, obwohl es eigentlich noch einen Backup gäbe, bar nämlich.

Mit OpenBSD Bordmitteln (also ifconfig) kann man so etwas nicht einrichten, daher hier meine Frage: Stand schonmal Jemand von Euch vor diesem Problem (und man hat es zwangsläufig, wenn man Carp für Firewall/Router Redundanz einsetzt) und dafür eine Lösung gefunden?


Beste Grüsse, scip

 

[CW]

Mache dich mit ifstated vertraut und schaue dir auch die Beispielkonfiguration davon an.

Dieser neue Daemon macht genau das, was du automatisch erledigt haben willst. Er überprüft Interfaces und wenn etwas bestimmtes auftritt (Ausfall etc.), dann startet er die von dir vorgegebenen Vorgänge.

 

[scip]

Re: ifstated

Ja, hab ich versucht, von Anschauen kann allerdings keine Rede sein, da das Teil praktisch nicht dokumentiert ist. Wie auch immer ich hab mal folgende Config erstellt (basierend auf der Sampleconfig):

# tests
if_up   = "(le2 link up)"
if_down = "(!le2 link up)"

state auto {
  if $if_down  {
    set-state slave
  }
  if $if_up {
    set-state master
  }
}

state master {
  init {
    run "ifconfig carp0 advskew 10"
  }
  if $if_down {
    set-state backup
  }
}

state slave {
  init {
    run "ifconfig carp0 advskew 100"
  }
  if $if_up {
    set-state master
  }
}

Ausganssituation:

le2: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        address: 00:50:56:e2:5a:bf
        inet6 fe80::250:56ff:fee2:5abf%le2 prefixlen 64 scopeid 0x2
        inet 192.168.130.130 netmask 0xffffff00 broadcast 192.168.130.255
carp0: flags=41<UP,RUNNING> mtu 1500
        carp: MASTER vhid 10 advbase 1 advskew 10
        inet 192.168.141.20 netmask 0xffffffff

Dann hab ich den ifstated angeworfen:

ifstated: initial state: auto
ifstated: changing state to slave
ifstated: running ifconfig carp0 advskew 100
ifstated: started

Da er offensichtlich 'set-state slave' ausgeführt hat, scheint der Test '$if_down' TRUE geliefert zu haben, obwohl das Interface le2 tatsächlich aber UP ist.

Abgesehen davon tut er ab diesem Zeitpunkt auch nichts mehr, jedenfalls kann ich das Interface le2 up oder down setzen wie ich mag, er reagiert nicht darauf.


Gruss, scip

 

[CW]

LINK UP hat nichts damit zu tun, dass ein Interface "up" ist. Linkup ist was anderes und hat damit zu tun, dass eine Verbindung besteht. Ein Interface ist auch dann "up", wenn es keine IP hat und auch an kein Kabel angeschlossen ist. Lass dich also nicht von diesem, zugegeben unfeinen, Unterschied durcheinander bringen.

Konsultiere die Mailinglisten. Da wirst du auch gute Konfigurationen finden.

Außerdem stimmt es nicht, dass es undokumentiert wäre, denn es gibt auch eine Manpage. Und die /etc/ifstated.conf ist (fast) selbsterklärend.

Wenn du ifstated aus dem Sourcen kompiliert hast, dann gibt es da auch eine Manpage.

Hier die Manpage:

IFSTATED(8)             OpenBSD System Manager's Manual            IFSTATED(8)

NAME
     ifstated - Interface State daemon

SYNOPSIS
     ifstated [-dhinv] [-D macro=value] [-f file]

DESCRIPTION
     The ifstated daemon runs commands in response to network state changes,
     which it determines by monitoring interface link state or running exter-
     nal tests.  For example, it can be used with carp(4) to change running
     services or to ensure that carp(4) interfaces stay in sync, or with pf(4)
     to test server or link availability and modify translation or routing
     rules.  The options are as follows:

     -D macro=value
             Define macro to be set to value on the command line.  Overrides
             the definition of macro in the configuration file.

     -d      Do not daemonize and log to stdout.

     -f file
             Specify an alternate location, file, for the configuration file.

     -h      Print help message.

     -i      Ignore initial interface states.

     -n      Config test mode.  Check config validity, then exit.

     -v      Verbose mode.  Use twice to further increase verbosity.

FILES
     /etc/ifstated.conf  ifstated configuration file.

SEE ALSO
     carp(4), pf(4)

HISTORY
     The ifstated program first appeared in OpenBSD 3.5.

OpenBSD 3.6

 

[scip]

Re: ifstated

LINK UP hat nichts damit zu tun, dass ein Interface "up" ist. Linkup ist was anderes und hat damit zu tun, dass eine Verbindung besteht. Ein Interface ist auch dann "up", wenn es keine IP hat und auch an kein Kabel angeschlossen ist. Lass dich also nicht von diesem, zugegeben unfeinen, Unterschied durcheinander bringen.

Achso, aber das ist ja noch weniger das, was ich will. Das Teil muss auf jeden Fall darauf reagieren, wenn das Interface "down" geht (also nicht der Link). Beipiel: irgendein Heini spielt an einem Switch rum und stellt den Port wo die Firewall dranhängt als Trunk ein (weil er ihn mit nem anderen verwechselt hat). Dann ist der Link natürlich immer noch da, das Interface aber down und unbrauchbar, die Firewall muss Slave werden und zwar automatisch, denn sonst hab ich nen Totalausfall an der Backe.

Konsultiere die Mailinglisten. Da wirst du auch gute Konfigurationen finden.

Das hab ich natürlich schon getan und neben der bekannten Beispielconfig aus dem src keine herausragenden Beispiele gefunden. Allerdings hab ich Postings von Leuten gefunden, denen es ähnlich geht wie mir.

Außerdem stimmt es nicht, dass es undokumentiert wäre, denn es gibt auch eine Manpage. Und die /etc/ifstated.conf ist (fast) selbsterklärend.

Das hab ich auch nicht behaupten wollen. Aber die Config ist nicht dokumentiert. Z.b. was er denn mit "demoted" meint, ich kenne das Wort nicht (dict.leo.org leider auch nicht). Oder in welchen Intervallen er sich den Linkstate anschaut, usw.

Abgesehen davon trotzdem Danke für den Hinweis auf den ifstated.


Gruss, scip

 

[CW]

Das hab ich auch nicht behaupten wollen. Aber die Config ist nicht dokumentiert. Z.b. was er denn mit "demoted" meint, ich kenne das Wort nicht (dict.leo.org leider auch nicht). Oder in welchen Intervallen er sich den Linkstate anschaut, usw.

Abgesehen davon trotzdem Danke für den Hinweis auf den ifstated.


Gruss, scip

Demoted ist das Gegenstück zu promoted. D.h. in so einem Zustand "strebt" die Maschine danach, BACKUP zu werden, während im promoted sie es eben versucht, MASTER zu werden.

ifstated selbst schaut non-stop auf die Interfaces.

Außerdem, noch eine Frage:

Hast du auch auf den Firewalls net.inet.carp.preempt auf 1 gesetzt?

Wenn nicht, dann liegt es bestimmt daran, weil erst mit Preemption wir die Maschine (oder DIE Maschinen) alles tun, um MASTER zu werden.

sysctl -w net.inet.carp.preempt=1 auf der Zeile eingeben und für den festen Eintrag in die /etc/sysctl.conf setzen (ohne sysctl -w ... nur die Variable + den Wert).

Grüße

 

[scip]

Re: ifstated

Hi,

Demoted ist das Gegenstück zu promoted. D.h. in so einem Zustand "strebt" die Maschine danach, BACKUP zu werden, während im promoted sie es eben versucht, MASTER zu werden.

Ah - wieder was dazugelernt :-)

Hast du auch auf den Firewalls net.inet.carp.preempt auf 1 gesetzt?

Ja, hab ich.


Das Problem ist doch aber eigentlich, dass er schon von Anfang an meint, dass das le2 DOWN ist und führt dann 'set-state slave' aus. le2 ist aber UP (was link-up impliziert).

Ich hab mal in der Funktion fetch_state() ein zusätzliches Logstatement am Ende der dortigen for{} Schleife eingefügt:

logit(IFSD_LOG_NORMAL, "-- interface: %s, state: %d", oname, ifrdat.ifi_link_state);

neu compiliert und mit gleicher Config gestartet, bekomme ich folgende Ausgabe:

if_up = "(le2 link up)"
if_down = "(!le2 link up)"
ifstated: -- interface: lo0, state: 0
ifstated: -- interface: le1, state: 0
ifstated: -- interface: le2, state: 0
ifstated: -- interface: le3, state: 0
ifstated: -- interface: pflog0, state: 0
ifstated: -- interface: pfsync0, state: 0
ifstated: -- interface: enc0, state: 0
ifstated: -- interface: carp0, state: 2
ifstated: initial state: auto
ifstated: changing state to slave
ifstated: -- interface: lo0, state: 0
ifstated: -- interface: le1, state: 0
ifstated: -- interface: le2, state: 0
ifstated: -- interface: le3, state: 0
ifstated: -- interface: pflog0, state: 0
ifstated: -- interface: pfsync0, state: 0
ifstated: -- interface: enc0, state: 0
ifstated: -- interface: carp0, state: 2
ifstated: running ifconfig carp0 advskew 100
ifstated: -- interface: lo0, state: 0
ifstated: -- interface: le1, state: 0
ifstated: -- interface: le2, state: 0
ifstated: -- interface: le3, state: 0
ifstated: -- interface: pflog0, state: 0
ifstated: -- interface: pfsync0, state: 0
ifstated: -- interface: enc0, state: 0
ifstated: -- interface: carp0, state: 2
ifstated: started

lt. net/if.h ist state 0 = LINK_STATE_UNKNOWN und state 2 = LINK_STATE_UP.

Ich denke dass es ein Bug im ifstated ist. Der state ist nur bei carp Interfaces korrekt, bei den physikalischen Interfaces meint er, dass der State Unknown ist, was dann auch erklärt, warum er das Carp sofort auf slave schaltet.

So gut kenne ich mich leider mit dem OpenBSD Netzcode nicht aus, jedenfalls scheint die struct, die an der Stelle verwendet wird, nur für carp Interfaces belegt zu sein.

Was denkst Du, sollte ich einen Bug aufmachen?


Gruss, scip

 

[CW]

Ich denke dass es ein Bug im ifstated ist. Der state ist nur bei carp Interfaces korrekt, bei den physikalischen Interfaces meint er, dass der State Unknown ist, was dann auch erklärt, warum er das Carp sofort auf slave schaltet.

So gut kenne ich mich leider mit dem OpenBSD Netzcode nicht aus, jedenfalls scheint die struct, die an der Stelle verwendet wird, nur für carp Interfaces belegt zu sein.

Was denkst Du, sollte ich einen Bug aufmachen?


Gruss, scip

Eigentlich sollte ifstated für alle möglichen Interfaces funktionieren, denn er unterscheidet nicht zwischen logischen und tatsächlichen Interfaces.

Hm, gute Frage, ob man den Bug melden soll.

Was mich bei ifstated stutzig macht, ist eben, dass man ihn extra kompilieren muss, bevor man ihn benutzen kann.

Und das heißt wiederum, dass die OpenBSD-Jungs eben aus dem Grund, dass ifstated noch nicht ausgereift ist, diesen nicht bei "make build" mit kompilieren lassen.

Ich würde mal bei tech@openbsd.org diesen Umstand melden.

Zumindest werden es die Leute dort wissen, ob es ein Bug ist oder was anderes.

Dass es nicht die gewünschte Funktionalität anbietet ist ja schon ersichtlich und ein Grund, es zu melden.

Grüße

 

[CW]

Ich habe ein bisschen mit meiner ifstated.conf herumexperimentiert und siehe, was daraus geworden ist (incl. deiner Erweiterung des ifstated.c-Codes):

carp_up = "(tun0 link up)"
carp_down = "(! tun0 link up)"
carp_sync = "((tun0 link up and dc0 link up)"
net = "( "ping -q -c 1 -w 1 134.99.128.2 > /dev/null" every 10 and  "ping -q -c 1 -w 1 134.99.128.5 > /dev/null" every 10)"
peer = "( "ping -q -c 1 -w 1 192.168.30.33 > /dev/null" every 10)"
ifstated: -- interface: lo0, state: 0
ifstated: -- interface: dc0, state: 1
ifstated: -- interface: de0, state: 0
ifstated: -- interface: pflog0, state: 0
ifstated: -- interface: pfsync0, state: 0
ifstated: -- interface: enc0, state: 0
ifstated: -- interface: tun0, state: 0
ifstated: initial state: auto
ifstated: changing state to backup
ifstated: -- interface: lo0, state: 0
ifstated: -- interface: dc0, state: 1
ifstated: -- interface: de0, state: 0
ifstated: -- interface: pflog0, state: 0
ifstated: -- interface: pfsync0, state: 0
ifstated: -- interface: enc0, state: 0
ifstated: -- interface: tun0, state: 0
ifstated: running echo backup
backup
ifstated: -- interface: lo0, state: 0
ifstated: -- interface: dc0, state: 1
ifstated: -- interface: de0, state: 0
ifstated: -- interface: pflog0, state: 0
ifstated: -- interface: pfsync0, state: 0
ifstated: -- interface: enc0, state: 0
ifstated: -- interface: tun0, state: 0
ifstated: started

Da ich kein CARP fahre, habe ich einfach mal meine DLS-Verbindung (tun0) und eine weitere, unbenutzte Karte (dc0) mit einer non-routablen IP zum Testen genommen. Ich konnte es einfach nicht wahr haben, dass ifstated keine "echten" Interfaces sehen kann.

Hier sieht man genau, dass bei dc0 eine 1 vorhanden ist.

Leider geht auch hier alles auf BACKUP, was ja nicht sein sollte,

 

[CW]

Wie ich erfahren habe, ist ifstated nicht notwendig, da CARP dies selber regelt.

Sobald nämlich ein Interface ausfällt (sprich: nicht "link up" ist), wird der advskew-Wert für alle anderen Interfaces auf 240 raufgesetzt, was dazu führt, dass die andere Maschine MASTER wird.

ifstated selbst ist also nicht notwendig und macht eher Sinn für solche Sachen, wie "ich stecke die Netzkarte in mein Notebook rein und DHCP geht sofort los".

Grüße

 

[scip]

carp regelt selber

Tja, und wenn ich das nun nicht will? Evtl. habe ich auf der Firewall 8 Interfaces und nur zw. 2 von ihnen habe ich Traffic der über Carp geht. Wenn eines der anderen 6 Interfaces down geht, hat das rein gar nichts mit den 2 balancten Interfaces zu tun. Wenn das mal kein Bug ist. Der Punkt ist einfach: die Enscheidung, was wann wie zu tun ist, möchte ich treffen. Wenn es anders wäre, kann ich mir gleich ne Windoof Kiste hinstellen und mir Popups um die Ohren sausen lassen..

Übrigens, auf der tech@openbsd.org Liste ist leider auch nix gescheites rausgekommen. Als Bug wurde es dort jedenfalls nicht betrachtet, ich bekam nur den Hinweis, dass der le Treiber keinen Link Status liefert (worum es mir aber eigentlich gar nicht ging, denn ifconfig ist auch in der Lage es als 'down' anzuzeigen, wenn es gerade down ist). IMHO werd ich dann lieber versuchen den FreeBSD vrrpd zum Laufen zu kriegen.


- scip

 

[CW]

Tja, und wenn ich das nun nicht will? Evtl. habe ich auf der Firewall 8 Interfaces und nur zw. 2 von ihnen habe ich Traffic der über Carp geht. Wenn eines der anderen 6 Interfaces down geht, hat das rein gar nichts mit den 2 balancten Interfaces zu tun. Wenn das mal kein Bug ist. Der Punkt ist einfach: die Enscheidung, was wann wie zu tun ist, möchte ich treffen. Wenn es anders wäre, kann ich mir gleich ne Windoof Kiste hinstellen und mir Popups um die Ohren sausen lassen..

Übrigens, auf der tech@openbsd.org Liste ist leider auch nix gescheites rausgekommen. Als Bug wurde es dort jedenfalls nicht betrachtet, ich bekam nur den Hinweis, dass der le Treiber keinen Link Status liefert (worum es mir aber eigentlich gar nicht ging, denn ifconfig ist auch in der Lage es als 'down' anzuzeigen, wenn es gerade down ist). IMHO werd ich dann lieber versuchen den FreeBSD vrrpd zum Laufen zu kriegen.


- scip

Du musst zwischen "link up" und "interface up" unterscheiden.

Der CARP-Code kümmert sich nur um CARP-Interfaces. Sprich: es ist ihm absolut egal, was mit nicht-CARP-Interfaces passiert.

Ich habe deinen Beitrag in der tech@ gelesen.

Die Jungs haben dir richtig geantwortet: bei CARP-linkdown geht advskew auf 240 und das andere Interface wird MASTER.

Lass dich nicht von physikalischen Interfaces durcheinanderbringen. Es kann zwar auch ein physikalisches Interface tatsächlich ausfallen, aber nur wenn es zugleich für ein CARP-Interface zuständig war, wird es die Lawine in Gang setzen. Ansonsten passiert rein gar nichts.

Grüße

 

[CW]

Und deine Vorgabe, dass du entscheidest, wann es geschehen soll und vor allem was, läuft diametral gegen das CARP-Konzept. Oder allgemein gegen das Highavailability-Konzept.

Es geht eben darum, dass dies OHNE Interaktion geschehen kann.

Das ist doch, was man will.

Wenn eine Maschine platt ist, übernimmt die andere.

Da willst du doch nicht, das die Kisten erst einmal auf deinen Mausklick warten, oder?

Ich würde sagen, dass das was du willst eher Windows entspricht als das was die Jungs bei OpenBSD machen.

 

[scip]

Re

Und deine Vorgabe, dass du entscheidest, wann es geschehen soll und vor allem was, läuft diametral gegen das CARP-Konzept. Oder allgemein gegen das Highavailability-Konzept.

Es geht eben darum, dass dies OHNE Interaktion geschehen kann.

Natürlich soll es ohne Interaktion geschehen, aber nach meinen Vorgaben.

Wenn eine Maschine platt ist, übernimmt die andere.

Nö. Ich will nur einen Traffic Pfad woanders hinschwenken, wenn Interfaces auf down gehen. Davon nicht betroffener Traffic darf drauf bleiben. Es geht nicht um "Maschine platt".

Da willst du doch nicht, das die Kisten erst einmal auf deinen Mausklick warten, oder?

Ich würde sagen, dass das was du willst eher Windows entspricht als das was die Jungs bei OpenBSD machen.

Hey - das war ein Witz, ok :-)

Jedenfalls ist es völlig an der Realität vorbei gedacht, dass CARP nur CARP Interface überwacht - die interessieren mich net, ich will halt die physikalischen Interfaces überwachen, u.a. auch die, an denen *kein* Carp dranhängt. Was ist, wenn ich auf der Maschine nur 1 Carp Interface hab? Soweit ich das bis jetzt verstanden habe, wird dann rein gar nichts passieren. Das ist doch ein Schmarrn, der primitivste Cisco Router mit nem 11er IOS kann das.

Naja, Gruss, scip

 

[CW]

Natürlich soll es ohne Interaktion geschehen, aber nach meinen Vorgaben.



Nö. Ich will nur einen Traffic Pfad woanders hinschwenken, wenn Interfaces auf down gehen. Davon nicht betroffener Traffic darf drauf bleiben. Es geht nicht um "Maschine platt".

Diese Dinge haben nichts mit CARP zu tun.

CARP ist eben für die Ausfallsicherheit einer MASCHINE gedacht und (eigeschränkt) für Load-Balancing.

Und beides hat mit deinen Wünschen nichts zu tun, denn du willst den Traffic nach bestimmten Gesichtspunkten verteilen.

In der Manpage steht klar und deutlich beschrieben, wofür CARP gut ist.

Und als ich gelesen habe, dass du vrrpd ausprobieren willst, musste ich lachen, denn CARP ist eben ein nicht-lizenzgebundener Ersatz für das Cisco-eigene VRRP-Protokoll.

Nur mit dem Unterschied, dass CARP Verschlüsselung kennt, IPv6 und ein paar Dinge noch dazu. Außerdem ist es absolut FREI.

Hey - das war ein Witz, ok :-)

Und wer sagt, dass ich keine Witze machen kann?

Jedenfalls ist es völlig an der Realität vorbei gedacht, dass CARP nur CARP Interface überwacht - die interessieren mich net, ich will halt die physikalischen Interfaces überwachen, u.a. auch die, an denen *kein* Carp dranhängt. Was ist, wenn ich auf der Maschine nur 1 Carp Interface hab? Soweit ich das bis jetzt verstanden habe, wird dann rein gar nichts passieren. Das ist doch ein Schmarrn, der primitivste Cisco Router mit nem 11er IOS kann das.

Naja, Gruss, scip

Ich würde einfach mal sagen, dass du dich mit CARP nicht 100%-ig vertraut gemacht hast.

CARP ist für die Ausfallsicherheit/LoadBalancing zuständig, nicht für die expliziten Wünsche eines Users, der seine Maschinen nach irgendwelchen Vorgaben und wie auch immer "up" und "down"-en will bzw. den Traffic nach bestimmten Vorgaben umleiten möchte.

Und außerdem deine Beispiele mit "nur einem CARP-Interface" belegen, dass du eben nicht begriffen hast, dass CARP IMMER mindestens ZWEI MASCHINEN impliziert.

Es spielt also keine Rolle, wieviele CARP-Interfaces du auf einer Maschine hast, sondern immer nur, DASS jedes CARP-Interface IMMER zwei PHYSIKALISCHE Interfaces VERTEILT auf zwei verschiedenen Maschinen IMPLIZIERT.

Lies die Manpages und schaue hier mal rein: http://www.countersiege.com/doc/pfsync-carp/

Außerdem kannst du, wenn du möchtest, bei der freeX-Ausgabe 4'2004 nachsehen. Da habe ich ein Artikel über CARP verfasst. Hier der Index: http://www.cul.de/data/freex42004inh.pdf

Grüße

 

[scip]

Re

Diese Dinge haben nichts mit CARP zu tun.

AFAIK soll CARP eine freie Alternative für VRRP und HSRP sein, und dort hat das schon was damit zu tun.

CARP ist eben für die Ausfallsicherheit einer MASCHINE gedacht und (eigeschränkt) für Load-Balancing.

Dafür will ich es verwenden. (schrieb ich das nicht schon ein paar mal?..)

Und beides hat mit deinen Wünschen nichts zu tun, denn du willst den Traffic nach bestimmten Gesichtspunkten verteilen.

Nein, ich will keinen Traffic verteilen. Ich will, dass der CARP Master zur anderen Firewall schwenkt, wenn sein Uplink (z.b.) down ist. Es gibt also 2 Maschinen, jede hat 2 ph. Interfaces und am internen Interface fahren sie CARP. Wenn am Master der Uplink ausfällt (wo kein CARP drauf ist, weil man es dort nicht braucht), wird er Slave und die andere Node übernimmt. Ist doch ganz einfach.

Ich würde einfach mal sagen, dass du dich mit CARP nicht 100%-ig vertraut gemacht hast.

Das bringt mich richtig weiter, wenn in jedem zweiten Posting behauptet wird, ich hätte CARP nicht verstanden. Ich habe es verstanden. Es kann nur annähern die Hälfte dessen was man für eine anständige HA Firewall Lösung braucht, es ist buggy, verhält sich nicht so, wie in der Doku beschrieben. Oder anders ausgedrückt: es ist meiner Meinung nach einfach noch nicht fertig. Ich bin also nicht zu dumm für CARP, bitte.

CARP ist für die Ausfallsicherheit/LoadBalancing zuständig, nicht für die expliziten Wünsche eines Users

Das ist ja mal ein echter Lacher. CARP ist also ein reiner Selbszweck?! Natürlich ist es zuständig, meine Wünsche zu erfüllen, einen anderen Zweck hat Software nicht. Wenn sie das nicht tut, muss ich es ihr entweder beibringen oder eine andere Software benutzen.

Und außerdem deine Beispiele mit "nur einem CARP-Interface" belegen, dass du eben nicht begriffen hast, dass CARP IMMER mindestens ZWEI MASCHINEN impliziert.

Offensichtlich hast Du nicht begriffen, was ich eigentlich will. Klar hab ich 2 Maschinen, aber auf jeder einzelnen nur EIN Carp Interface. Das bleibt Master, was auch immer auf *dieser* Maschine passiert.

Lies die Manpages

Es gibt nur eine manpage zu Carp. Und sag mir bitte nicht ich soll die ifconfig manpage anschauen.

http://www.countersiege.com/doc/pfsync-carp/

Ja, da war ich schon vor einigen Monaten. Übrigens steht dort (u.a.):

..
Additionally, a daemon which monitors network connectivity by link state transitions on network interfaces and performs active network tests is in the process of being developed. This daemon can be used to run local commands to reconfigure the system or start and stop services based on network events it detects.
..

Die Rede ist vom (leider auch unfertigen, bzw. fehlerhaften) ifstated Daemon, eigentlich genau das, was ich brauche.



Gruss, scip

PS: wenn ich das mal anmerken darf (und bitte nicht persönlich nehmen), es ist schon ein wenig deprimierend, auf meine Fragen immer wieder lesen zu müssen, ich solle "die manpages lesen" oder ich "hätte es nicht verstanden". In der kommerziellen HA Welt ist Interfacetracking eine Selbstverständlichkeit, die man nicht gross erklären muss. Und wenn ich auf nem Cisco bei ner hsrp Gruppe interface-tracking auf serial2/1 mache und es funktioniert nicht, bekomme ich von denen nicht gesagt: "du hast HSRP nicht verstanden".

 

[CW]

AFAIK soll CARP eine freie Alternative für VRRP und HSRP sein, und dort hat das schon was damit zu tun.

Nein, eben nicht. CARP/VRRP hat damit zu tun, dass man die Verfügbarkeit einer Maschine gewährleistet und nicht, dass man irgendeinen Teil des Traffics weiterleitet/umleitet oder sonstwie manipuliert.

Bei CARP geht es darum, zu gewährleisten, dass man eine IP auch nach dem Ausfall der Maschine immer noch erreichen kann. Und die Verfügbarkeit einer IP-Adresse IMPLIZIERT die Verfügbarkeit einer Maschine. Das ist ja wohl logisch.

Und warum sollte sich CARP jetzt um irgendein anderes Interface kümmern, welches nicht zu seinem Aufgabenbereich gehört???

Wo steht das geschrieben, dass es sein muss.

Gib mir doch Belege.

Nein, ich will keinen Traffic verteilen. Ich will, dass der CARP Master zur anderen Firewall schwenkt, wenn sein Uplink (z.b.) down ist. Es gibt also 2 Maschinen, jede hat 2 ph. Interfaces und am internen Interface fahren sie CARP. Wenn am Master der Uplink ausfällt (wo kein CARP drauf ist, weil man es dort nicht braucht), wird er Slave und die andere Node übernimmt. Ist doch ganz einfach.

Wenn du keinen Traffic verteilen willst, warum sagtest du oben, dass ein bestimmter Teil in die eine Richtung gehen soll und der andere nicht?

Und wenn eben ein nicht-CARP-Interface ausfällt, was hat, bitte, denn CARP damit zu tun???

Denkst du, dass CARP "denken" kann??? Oder zaubern???

Das bringt mich richtig weiter, wenn in jedem zweiten Posting behauptet wird, ich hätte CARP nicht verstanden. Ich habe es verstanden. Es kann nur annähern die Hälfte dessen was man für eine anständige HA Firewall Lösung braucht, es ist buggy, verhält sich nicht so, wie in der Doku beschrieben. Oder anders ausgedrückt: es ist meiner Meinung nach einfach noch nicht fertig. Ich bin also nicht zu dumm für CARP, bitte.

Natürlich hast du es nicht verstanden, wenn du versuchst CARP dort anzuwenden, wofür es nicht gedacht worden ist.

Wieso soll CARP sich mit einem Interface befassen, wenn er nichts mit ihm zu tun hat?

Ich verstehe, was du haben willst, aber CARP kann dir das nicht geben.

Und wenn du "buggy" meinst, dann gib mir bitte Belege dafür. Buggy ist für mich ein Ausdruck, dass etwas im Code nicht stimmt oder dass etwas fehlt.

Na bitte, code doch ein paar Patches und präsentiere die doch in der tech@.

Nur so kann man weiter kommen.

Aber: hier gibt es nichts zu coden in der Richtung.

CARP hat sich um CARP-Interfaces zu kümmern und mehr nicht.

Sonst könntest du gleich sagen, dass POP3 sich doch bitte auch um SMTP-Aufgaben kümmern sollte.

Das ist ja mal ein echter Lacher. CARP ist also ein reiner Selbszweck?! Natürlich ist es zuständig, meine Wünsche zu erfüllen, einen anderen Zweck hat Software nicht. Wenn sie das nicht tut, muss ich es ihr entweder beibringen oder eine andere Software benutzen.

Du kannst gerne Lachen, aber davon bekommst du nicht viel.

Und von CARP bekommst du halt auch keine Erledigung der Aufgaben, für welche er nicht gedacht war.

CARP ist für die Ausfallsicherheit eines Maschinenverbunds gedacht (oder genauer: deren IP-Adressen) und mehr nicht.

Und wenn es dir nicht passt, dass er keine eierlegende Vollmilchsau ist, dann entweder:

1.) nicht anwenden

2.) oder coden, coden, coden ...

Ich bin kein Coder, ich kann nur darüber schreiben ... wenn du coden kannst, dann würde ich mich freuen, wenn ich was von dir in der tech@ zu CARP lesen würde.

Ehrlich ...

Offensichtlich hast Du nicht begriffen, was ich eigentlich will. Klar hab ich 2 Maschinen, aber auf jeder einzelnen nur EIN Carp Interface. Das bleibt Master, was auch immer auf *dieser* Maschine passiert.

Es gibt kein "ein einzelnes CARP-Interface", sondern "ein Interface dessen BASIS sich auf mindestens zwei Maschinen befindet"!

CARP wird von AUßEN als ein Interface angesehen (eine IP-Adresse), aber für den Administrator BESTEHT es aus mindestens zwei physikalischen Interfaces, welche die Ausgangsbasis für ein LOGISCHES Interface bilden, welchen auf diesen beiden aufsetzt.

Kapiert?

Es gibt nur eine manpage zu Carp. Und sag mir bitte nicht ich soll die ifconfig manpage anschauen.

Natürlich, weil ifconfig CARP-Interfaces konfiguriert/einrichtet/entfernt/manipuliert.

Außerdem findest du dort gute Beispiele.

Ja, da war ich schon vor einigen Monaten. Übrigens steht dort (u.a.):

..
Additionally, a daemon which monitors network connectivity by link state transitions on network interfaces and performs active network tests is in the process of being developed. This daemon can be used to run local commands to reconfigure the system or start and stop services based on network events it detects.
..

Die Rede ist vom (leider auch unfertigen, bzw. fehlerhaften) ifstated Daemon, eigentlich genau das, was ich brauche.

Und was hat CARP damit zu tun???

Siehst du dass da zu Anfang steht "Additionally"....

Es ist kein Muss.

Und es ist also für dich ken Grund gegeben, dich zu beschweren, dass CARP entwas nicht kann, wofür es nicht gedacht war.

Du kannst, wie ich sagte, selber coden, wenn die Leute bei OpenBSD nicht so weit sind, aber du solltest nicht auf etwas Steine werfen, was nicht die Aufgabe hat, das zu tun, was du getan haben willst.

Gruss, scip

PS: wenn ich das mal anmerken darf (und bitte nicht persönlich nehmen), es ist schon ein wenig deprimierend, auf meine Fragen immer wieder lesen zu müssen, ich solle "die manpages lesen" oder ich "hätte es nicht verstanden". In der kommerziellen HA Welt ist Interfacetracking eine Selbstverständlichkeit, die man nicht gross erklären muss. Und wenn ich auf nem Cisco bei ner hsrp Gruppe interface-tracking auf serial2/1 mache und es funktioniert nicht, bekomme ich von denen nicht gesagt: "du hast HSRP nicht verstanden".

Nun, noch deprimierender ist es, zum zehnten Mal zu wiederholen, was CARP ist und woraus es besteht und trotzdem zu hören, dass es nicht gut genug sei.

Außerdem, es ist klar und ersichtlich, dass du CARP nicht verinnerlicht hast, wenn du in deinen Postings immer von CARP-Interfaces als einzelnen Interfaces redest, die auf einem Rechner sitzen. Das ist eben nicht wahr, denn ein CARP-Interface als solches impliziert immer mindestens zwei Maschinen im Hintergrund mit mindestens zwei Interfaces, welche die Basis für das GEMEINSAME Carp-Interface bilden. Das CARP-Interface selbst ist also ein logisches Gerät, welches die Existenz zweier physikalischer Interfaces bedingt, damit es auf diese aufsetzen kann, um die hohe Verfügbarkeit zu gewährleisten.

Oder, kurz gesagt, CARP steht für die Verfügbarkeit einer IP-Adresse und somit zugleich für die Verügbarkeit einer Maschine.

Dies kann man dann noch detaillierter beschreiben, wenn z.B. auf der Maschine irgendein wichtiger Dienst läuft, welcher auch auf der BACKUP-Maschine laufen sollte, damit im Falle des Ausfalls die Verfügbarkeit des Dienstes selbst gewährleistet werden kann.

Verstanden?

 

[scip]

nochmal

Bei CARP geht es darum, zu gewährleisten, dass man eine IP auch nach dem Ausfall der Maschine immer noch erreichen kann. Und die Verfügbarkeit einer IP-Adresse IMPLIZIERT die Verfügbarkeit einer Maschine. Das ist ja wohl logisch.

hab ich vielleicht was anderes behauptet?

Und warum sollte sich CARP jetzt um irgendein anderes Interface kümmern, welches nicht zu seinem Aufgabenbereich gehört???

Meine ursprüngliche Frage war, wie ich diese Aufgabenstellung bewerkstelligen kann, nicht, wie ich das mit CARP machen kann.
Dann wurde ich auf den ifstated verwiesen und später hat es geheissen, dass CARP das selber machen würde. *Mir* ist es egal, wer oder was Hauptsache es tut.

Wo steht das geschrieben, dass es sein muss.

Und was nicht geschrieben ist, geht net? Ich *will* es so. Sehr einfach :-)

Wenn du keinen Traffic verteilen willst, warum sagtest du oben, dass ein bestimmter Teil in die eine Richtung gehen soll und der andere nicht?

Weil das System mehrere Aufgaben hat (bzw: haben kann), die nix miteinander zu tun haben müssen.

Und wenn eben ein nicht-CARP-Interface ausfällt, was hat, bitte, denn CARP damit zu tun???

Ich will, dass es zum Backup wird auf der Maschine, wo das passiert. Ob CARP das tut, ein Daemon, ein beschissenes Shellscript als Cronjob, tut nix zur Sache. Ich wollte nur wissen, OB es eine funktionierende Lösung dafür gibt.

Denkst du, dass CARP "denken" kann??? Oder zaubern???

Denkst Du dass ich ein bischen blöd bin?

Ich verstehe, was du haben willst, aber CARP kann dir das nicht geben.

Nein tust Du offensichtlich nicht, denn sonst würdest Du Dich nicht die ganze Zeit darüber aufregen, was ich angeblich von CARP will.

Es gibt kein "ein einzelnes CARP-Interface", sondern "ein Interface dessen BASIS sich auf mindestens zwei Maschinen befindet"!

Das weiss ich! Ich meinte das Pseudo Device!

Und es ist also für dich ken Grund gegeben, dich zu beschweren

Ich hab mich nicht beschwert, ich hab gefragt.

aber du solltest nicht auf etwas Steine werfen, was nicht die Aufgabe hat, das zu tun, was du getan haben willst.

Ich werfe keine Steine und z.b. der ifstated hat genau diese Aufgabe.

Nun, noch deprimierender ist es, zum zehnten Mal zu wiederholen, was CARP ist und woraus es besteht und trotzdem zu hören, dass es nicht gut genug sei.

Kann ich da was dafür? Ich wollte nicht wissen, was CARP ist oder wie es funktioniert. Ich wollte Interface-Tracking.


Gut Nacht, scip

 

[CW]

Nun, wie ich sehe, bist du in voller Fahrt. Und das kann und werde ich nicht in meinem (unserem) Forum zulassen. Du weißt genau, was du geschrieben hast und ich muss dich nicht daran erinnern.

Außerdem: dein Thread heißt eben -> carp ... interface-tracking ...

Nun, wenn du schon mit Worten "beschissen" anfängst, muss ich dich aufmerksam machen, dass uns dies sicherlich nicht weiter bringt.

Vor allem dann, wenn mit Polemik angefangen wird, wie z.B. "*Mir* ist es egal, wer oder was Hauptsache es tut.".

Ich kann schlussendlich sagen (und das ist eben das, was ich über CARP gelernt habe), dass CARP sich nur um CARP-Interfaces kümmert.

Für alles andere musst du etwas anderes anwenden oder was neues coden, wenn du der Meinung bist, dass etwas "buggy" ist.

Ich bin, wie schon gesagt, kein Coder und kann dir dabei wenig helfen. Aber was die ANWENDUNG von CARP anbetrifft, kann ich dir sicherlich sagen, was geht und was eben nicht geht.

CARP sorgt für die Verfügbarkeit einer IP-Adresse und nicht für die Verfügbarkeit irgendeines anderen Interfaces, welches nicht in seinem Bereich liegt.

 

[scip]

Re

Ich wollte Dir ja wirklich nicht auf die Füsse treten. Ich schätze wir haben einfach aneinander vorbei geredet.

Ich versuchs daher einfach nochmal, unabhängig von den Vorpostings:

Ich habe 2 Firewalls, auf denen eine virtuelle CARP IP läuft, die im Netz dahinter als Defaultroute verwendet wird. Davon unabhängig habe ich auf jeder der beiden Firewalls nach draussen ein WAN Interface, z.b. ppp, o.ä. Ich weiss auch (oder habe verstanden, wie Du magst), dass sich CARP natürlich nicht für die ppp Interface interessiert.

Was ich nun gerne hätte, ist dass ein Daemon die WAN Interface überwacht und im Fehlerfall die Prio des jeweiligen CARP Masters runtersetzt, so dass er Backup wird. Die Software der Wahl dazu ist an und für sich der ifstated, muss wahrscheinlich noch angepasst werden. Ich könnte das selbstverständlich auch selber programmieren (dürfte z.b. mit Python kein grosser Akt sein), aber ich persönlich vermeide gerne das Rad neu zu erfinden, weswegen ich hier gefragt habe ob Jemand weiss, wie man das mit existierenden Mitteln machen kann.

Oder kurz ausgedrückt, ich möchte mit OpenBSD das machen, was u.a. hier dokumentiert ist: http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/cs009.htm#wp3475

Ich denke also, dass wir uns eigentlich einig sind.


Beste Grüsse, scip

 

[CW]

Ich wollte Dir ja wirklich nicht auf die Füsse treten. Ich schätze wir haben einfach aneinander vorbei geredet.

Ich versuchs daher einfach nochmal, unabhängig von den Vorpostings:

Ich habe 2 Firewalls, auf denen eine virtuelle CARP IP läuft, die im Netz dahinter als Defaultroute verwendet wird. Davon unabhängig habe ich auf jeder der beiden Firewalls nach draussen ein WAN Interface, z.b. ppp, o.ä. Ich weiss auch (oder habe verstanden, wie Du magst), dass sich CARP natürlich nicht für die ppp Interface interessiert.

Was ich nun gerne hätte, ist dass ein Daemon die WAN Interface überwacht und im Fehlerfall die Prio des jeweiligen CARP Masters runtersetzt, so dass er Backup wird. Die Software der Wahl dazu ist an und für sich der ifstated, muss wahrscheinlich noch angepasst werden. Ich könnte das selbstverständlich auch selber programmieren (dürfte z.b. mit Python kein grosser Akt sein), aber ich persönlich vermeide gerne das Rad neu zu erfinden, weswegen ich hier gefragt habe ob Jemand weiss, wie man das mit existierenden Mitteln machen kann.

Oder kurz ausgedrückt, ich möchte mit OpenBSD das machen, was u.a. hier dokumentiert ist: http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/cs009.htm#wp3475

Ich denke also, dass wir uns eigentlich einig sind.


Beste Grüsse, scip

Nun, dann hättest du erst gar nicht mit Carp kommen dürfen, aber das ist jetzt egal.

Ich kann dir nur empfehlen, einen kleinen Shell-Script zu schreiben, der in der Crontab z.B. alle paar Minuten ausgeführt wird.

Dieser Skript sollte natürlich per ifconfig überprüfen, ob dein gewünschtes Interface "up" ist. Was mit "up" gemeint sein soll, entscheide du selbst. Ob "link up" oder "interface up", ist deine eigene Sache.

Und wenn jetzt das überprüfte Interface nicht "up" ist, in welchem Sinne auch immer, dann wird dieser Skript per ifconfig dem CARP-Interface mitteilen, dass sein advskew auf z.B. 240 raufgesetzt wird, damit die Backup-Maschine eben zum Master wird.

Oder du kannst was anderes machen. Mit ifconfig hast du unendlich viel Spielraum, was die Konfiguration der Interfaces angeht.

Deswegen habe ich ja auch empfohlen, deren Manpage zu lesen, weil eben dort viele gute Beispiele dazu stecken.

Die Jungs von OpenBSD geben sich wirklich allergrößte Mühe, die Manpages leicht lesbar zu machen.

Grüße

 

[scip]

Oder du kannst was anderes machen. Mit ifconfig hast du unendlich viel Spielraum, was die Konfiguration der Interfaces angeht.

Deswegen habe ich ja auch empfohlen, deren Manpage zu lesen, weil eben dort viele gute Beispiele dazu stecken.

Ich weiss nicht, wodurch ich bei Dir den Eindruck hinterlassen habe, keine Ahnung von ifconfig zu haben.

Wie auch immer, falls es wen interessiert, ich hab (zumindest für meinen Anwendungsfall) eine Lösung gefunden: ich habe mir den ifwatchd (http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/ifwatchd/) von NetBSD installiert (ich musste SPPP_IF_SUPPORT deaktivieren, ansonsten liess er sich anstandslos compilieren), der tut exakt das, was ich wollte.


Bis die Tage, scip

 

[CW]

Ich weiss nicht, wodurch ich bei Dir den Eindruck hinterlassen habe, keine Ahnung von ifconfig zu haben.

Wie auch immer, falls es wen interessiert, ich hab (zumindest für meinen Anwendungsfall) eine Lösung gefunden: ich habe mir den ifwatchd (http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/ifwatchd/) von NetBSD installiert (ich musste SPPP_IF_SUPPORT deaktivieren, ansonsten liess er sich anstandslos compilieren), der tut exakt das, was ich wollte.


Bis die Tage, scip

Ich habe niemals von ifconfig, sondern von seiner Manpage gesprochen

Wegen der guten Beispiele, die sich in ihr befinden.

Darum ging es mir.

Guter Tipp, das mit ifwatchd ...

Kannst du das ein bisschen detaillierter machen. Damit die Community darauf zugreifen kann, wenn sie es brauchen würde.

Grüße

 

[scip]

Guter Tipp, das mit ifwatchd ...

Kannst du das ein bisschen detaillierter machen. Damit die Community darauf zugreifen kann, wenn sie es brauchen würde.

Jo, ist sogar recht simpel:

### Ausgangssituation:

tier3@mort: # ifconfig le2
le2: flags=8863<UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 00:50:56:e2:5a:bf
inet6 fe80::250:56ff:fee2:5abf%le2 prefixlen 64 scopeid 0x2
inet 192.168.130.10 netmask 0xffffff00 broadcast 192.168.130.255

tier3@mort: # ifconfig carp0
carp0: flags=41<UP,RUNNING> mtu 1500
carp: MASTER vhid 10 advbase 1 advskew 10
inet 192.168.141.10 netmask 0xffffff00

### Down Script f. ifwatchd:
tier3@mort: # cat carp0-down.sh
#!/bin/sh
ifconfig carp0 advskew 200
logger "ifconfig carp0 advskew 200"


### Starten des Daemons:
tier3@mort: # ifwatchd -i -d /viper/ifwatchd/carp0-down.sh le2
Nov 15 04:49:28 mort ifwatchd[14494]: watching interface le2

### Fehler verursachen:
tier3@mort: # ifconfig le2 -alias

### Reaktion:
Nov 15 04:51:36 mort ifwatchd[29182]: calling: /viper/ifwatchd/carp0-down.sh le2 /dev/null 9600 192.168.130.10 192.168.130.255
tier3@mort: # Nov 15 04:51:36 mort root: ifconfig carp0 advskew 200


(die Ausgaben mit Datum sind übrigens Syslog Ausgaben).


Gruss, scip

 

[CW]

Fantastisch!

Es scheint wohl problemlos zu klappen. Notiere ich mir sofort.

Man weiß ja nie, vielleicht brauche ich es auch eines Tages.

Grüße