BGP/quagga und Routing-Präferenzen

02/04/2015 - 21:32 von Christian Garbs | Report spam
Mahlzeit!

Wir haben ein paar Netze über DSL-Dialups zusammengelegt und benutzen
BGP, um die untereinander bekanntzumachen. Jedes Teilnetz ist ein AS.
(Warum? "Weil wir es können." Und lernen tut man auch was :-)

Es gibt dickere und dünnere Leitungen. Wenn man über zwei Hops geht,
ist die dickere Leitung deutlich zu pràferieren, statt sich
nacheinander durch zwei langsame DSL-Uploads zu quàlen.

Zum Bevorzugen der schnellen Leitungen habe ich zwei Route-Maps
angelegt, die mit 'set metric' eine höhere bzw. niedrigere Metric
setzen und manuell für meine Nachbarn die passende der beiden
Route-Maps gesetzt.

Jetzt ist die Tage folgendes zu sehen gewesen und ich weiß nicht,
warum. Auszug aus 'show ip bgp':

Network Next Hop Metric LocPrf Weight Path
* 192.168.9.0 169.254.65.3 10 0 65003 65009 65005 i
* 169.254.65.9 10 0 65009 65005 i
* 169.254.65.19 200 0 65019 65009 65005 i
*> 169.254.65.1 200 0 65001 65005 i


Laut http://openmaniak.com/quagga_case4.php#MED làuft die
Routingentscheidung in der folgenden Reihenfolge ab:

1. Weight -> gibt's hier nicht
2. LocPrf -> gibt's hier auch nicht
3. Pfadlànge -> Zeilen 2 und 4 bleiben im Rennen (via …65.9 und …65.1)
4. Metric -> die niedrigste Metric gewinnt

Die _niedrigste_ Netric hat Zeile 2 über …65.9

Warum hat sich quagga/bgpd hier stattdessen für Zeile 4 mit der
_höheren_ Metric entschieden?

Das verstehe ich nicht. Spielt da noch etwas anderes mit rein?

Groß rumgeflappt ist zu dem Zeitpunkt nichts, das war schon lànger so.
Das passiert auch nicht immer, "meistens" ist es so, wie ich das
geplant habe und die 10er-Metric wird bevorzugt.



Plan B:

Ich habe das jetzt mal probehalber von Metric auf LocalPreference
umgestellt und beobachte, ob das dort dauerhaft so klappt wie
beschrieben (höchste LocPrf gewinnt).

Das macht die Konfiguration dann aber komplizierter, weil die
LocalPreference vor der Pfadlànge zum Tragen kommt und eine direkte
Verbindung zweier langsamen Systeme (niedrige LocPrf) zu einem Umweg
über ein schnelleres System (höhere LocPrf, aber ein Hop mehr) führen
würde.

Die aktuelle Lösung dafür ist eine weitere Regel, die einer langsamen
Verbindung für den Fall, dass sie eine direkte Verbindung ist
(as-path ^[0-9]*$), eine höhere LocPrf als einer schnellen Verbindung
verpasst.

Scheint auf den ersten Blick auch zu funktionieren.

Wàre das denn gegenüber der Steuerung per Metric zu bevorzugen?

Bei den Metrics habe ich nur zwei Werte, bei den LocalPreferences muss
ich schon mit drei verschiedenen hantieren. Das ist zumindest
unübersichtlicher.


Danke und Gruß
Christian
Christian.Garbs.http://www.cgarbs.de
Rap's Gesetz der unbeseelten Reproduktion:
Wenn man etwas oft genug auseinandernimmt und wieder
zusammensetzt, hat man schließlich zwei davon.
 

Lesen sie die antworten

#1 Juergen Ilse
03/04/2015 - 17:45 | Warnen spam
Hallo,

Christian Garbs wrote:
Zum Bevorzugen der schnellen Leitungen habe ich zwei Route-Maps
angelegt, die mit 'set metric' eine höhere bzw. niedrigere Metric
setzen und manuell für meine Nachbarn die passende der beiden
Route-Maps gesetzt.
Jetzt ist die Tage folgendes zu sehen gewesen und ich weiß nicht,
warum. Auszug aus 'show ip bgp':

Network Next Hop Metric LocPrf Weight Path
* 192.168.9.0 169.254.65.3 10 0 65003 65009 65005 i
* 169.254.65.9 10 0 65009 65005 i
* 169.254.65.19 200 0 65019 65009 65005 i
*> 169.254.65.1 200 0 65001 65005 i


Laut http://openmaniak.com/quagga_case4.php#MED làuft die
Routingentscheidung in der folgenden Reihenfolge ab:
1. Weight -> gibt's hier nicht
2. LocPrf -> gibt's hier auch nicht
3. Pfadlànge -> Zeilen 2 und 4 bleiben im Rennen (via …65.9 und …65.1)
4. Metric -> die niedrigste Metric gewinnt
Die _niedrigste_ Netric hat Zeile 2 über …65.9
Warum hat sich quagga/bgpd hier stattdessen für Zeile 4 mit der
_höheren_ Metric entschieden?



Keine Ahnung, ich habe bei BGO noch nie mit umsetzen der Metrik
herumgedoktert ...

Plan B:
Ich habe das jetzt mal probehalber von Metric auf LocalPreference
umgestellt und beobachte, ob das dort dauerhaft so klappt wie
beschrieben (höchste LocPrf gewinnt).
Das macht die Konfiguration dann aber komplizierter, weil die
LocalPreference vor der Pfadlànge zum Tragen kommt und eine direkte
Verbindung zweier langsamen Systeme (niedrige LocPrf) zu einem Umweg
über ein schnelleres System (höhere LocPrf, aber ein Hop mehr) führen
würde.



Warum versuchst du es nicht einfach damit, bei allen Announcements
ueber eine langsame Leitung eine AS-Path-Verlaengerung ueber eine
entsprechende Route-Map zu konfigurieren? Damit haettest du nur
noch die AS-Path-Laenge als Kriterium, und die Konfiguation waere
evt. trotz laengerer AS-Pfade uebersichtlicher ...

Tschuess,
Juergen Ilse ()
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.

Ähnliche fragen