OSPF Routing

[MrBean]

Hi,
nun hab ich ja wie auch in einem anderen Beitrag von mir bekannt geworden ist, in meinem WAN OSPF Routing aktiviert. Betrachtet man 2 unabhängige Router von einander die beide den Eingang ins LAN realisieren sollen (der eine sichert den anderen gegen Ausfall ab). Ist dann OSPF eine gute Lösung, wenn nein, was wäre die bessere Wahl und, wenn ja, was kann ich mit OSPF noch tun um die WAN-Eingänge noch redundanter zu gestallten? Bisher habe ich einfach nur das OSPF Routing aktiviert.

Vielen Dank im Voraus.

[#9370]

OSPF ist die richtige Lösung. Dynamische Rouitingprotokolle sind dafür ausgelegt, um Redundanzen und Backup Wege dynamisch realisieren zu können. Da muss sonst nichts gemacht werden.

/#9370

[MrBean]

...und da gibt es auch innerhalb von OSPF nichts zu optimieren?

[#9370]

keine Ahnung, warum du so auf Optimierung stehst, aber für 99% aller Einsatzgebiete passen die Default Einstellungen. Die Leute, die das gemacht haben, wissen warum die Timer usw. so sind wie sie sind. Wenn du mir sagst, warum du am OSPF drehen willst und was ihr drüber machen wollt, dann gibt es vielleicht ein paar Dinge zu tun.

/#9370

[Zwerg#7]

Möchte mich da #9370 anschließen, an Timern herumzuschrauben verkompliziert das ganze und führt leicht zu instabilen Services! OSPF ist eigentlich gut so wie es ist.
Hast du wirklich Bedarf die Umschaltzeiten zu optimieren? Hat es eine größere, nicht tragbare Unterbrechung gegeben? Und vor allem; sind diese langen Unterbrechungen dann auf OSPF zurück zu führen???

Also nur mal so als Hinweis: Unsere OSPF-Umgebung konvergiert im Fehlerfall innerhalb von einer Sekunde. Wir testen das regelmäßig und konnten dabei noch nie irgendwelche Ausfälle von Applikationen verzeichnen! Und natürlich haben wir auch nie an den Timern gedreht!


Ich denke es wäre besser an anderen Stellen nach Optimierung zu suchen:
#redundante Netzteile
#redundante Stromversorgungen (d.h. zwei Stromkreise, zwei Sicherungen, zwei Quellen wie Normalstrom und USV, ...)
#redundante Kabelführungen
#räumlich getrennter Einbau
#zwei WAN-Provider (natürlich auch mit redundanter Kabelführung bis zu deren POP)

Hängt natürlich alles vom Bedarf und den örtlichen Gegebenheiten ab aber man täte gut daran dafür zu sorgen, dass die dynamischen Protokolle die das Netzwerk stabilisieren, gar nicht erst beginnen müssen zu arbeiten.
Bei uns sind gut 80-90% aller Ausfälle auf Stromunterbrechungen zurück zu führen. Und das halt dann bei den Geräten die nur ein Netzteil haben... Aber das ist ok so, teurere Geräte mit doppelten Netzteilen sind dort nicht gerechtfertigt.

[MrBean]

Also, danke erstmal für eure Geduld. 

Ich möchte natürlich nicht das dynamische Routing neu erfinden. Was ich möchte ist es ein Netz zu entwerfen, was im Fehlerfall möglichst nicht spürbar für den User weiter läuft. Warum das so sein soll..., später sollen Anwendungen nur noch auf einem Server laufen und User nur remote Zugriff darauf haben.
Die Punkte die aufgeführt wurden, sehe ich natürlich als genauso relevant an, wie ihr es tut und werden auch alle mit einbezogen.

[MrBean]

Hi, mal wieder eine Frage zu OSPF.
Macht es Sinn, wenn ich ein durch OSPF geroutetes Netzwerk habe, an bestimmten Stellen Kosten zu vergeben. Z.B. soll er generell immer über einen bestimmten Router gehen, nur wenn dieser oder eine Verbindung dort hin ausfällt, soll er eine Ersatzroute gehen?

[#9370]

wenn es einen guten Grund gibt, dann schon. Aber wie schon bei den anderen Tuning Sachen tut man das in der Regel nur, wenn man weiß, warum. Das Problem bei den Einstelliungen ist meistens folgendes: Man erweitert das Netz und die Einstellungen werden vergessen -> das Netz wird instabil und die unmöglichsten Fehler treten auf. Ich habe schon bei vielen nächtlichen Troubleshooting Sessions erlebt, dass entweder veränderte OSPF Costs oder STP Einstellungen oä. Schuld an der Misere waren.
Wenn ein Netz von Anfang an gut geplant ist, dann ist Tuning an den Porokollen im Normalfall nicht nötig.

/#9370

[MrBean]

Ja das war auch mein Gedanke, wenn dann müßte man es überall machen, und das kann schnell nach hinten losgehen.
Bei mir ist momentan das Problem, das er über einen Weg vom Sender zum Empfänger geht und über einen anderen zurück. Wenn ich dann eine Leitung im "VRRP-Netz" kappe, dann bekommt er schnell Probleme weil er die Rückroute nicht finden kann, was das Netz dann ziemlich langsam konvergieren läßt.

[Zwerg#7]

In einer genau definierten Umgebung würde ich allerdings schon ein Tuning mit Costs empfehlen.

Hat den Vorteil, dass man genau weiß wo der Traffic fließt und tut sich somit wesentlich leichter beim Designen und Troubleshooten -> das Netz ist einfach berechenbarer
In manchen Fällen ist Cost-Tuning sogar unerlässlich zB wenn man redundante Wege über 10GBit und 1GBit hat (die sind für OSPF alle gleichwertig) oder wenn man Firewalls oder Loadbalancer einsetzt (Hin und Rücktraffic müssen dann den selben Weg gehen)

Nachteil ist natürlich, dass man immer gut überlegen sollte was man tut und, dass man "Equal-Cost" Loadbalancing verliert d.h. im Normalbetrieb manche Links ungenutzt lässt.



Im Großen und Ganzen sehe ich Tuning mit Costs viel viel viel weniger kritisch als das drehen an irgendwelchen Hello- oder Holddown-Timern. Im schlimmsten Fall kann man durch schlechte Wahl der Costs, eine ineffiziente Wegwahl verursachen. Wenn man Timer verstellt kann man wirklich OSPF instabil machen und im schlimmsten Fall das Routing zum erliegen bringen.

Die Fehlersuche ist beim Timer-Tuning schwierig, beim Tunen mit Costs reicht ein bloßer Traceroute 

[#9370]

In manchen Fällen ist Cost-Tuning sogar unerlässlich zB wenn man redundante Wege über 10GBit und 1GBit hat (

das stimmt nicht ganz - die Berechnungsgrundlage für die costs kann man verändern, was ich per Default auch empfehlen würde. Dann hat man keine Probleme.
-> auto-cost reference-bandwidth 10000

Hat den Vorteil, dass man genau weiß wo der Traffic fließt und tut sich somit wesentlich leichter beim Designen und Troubleshooten

eben nicht - die Altlasten, die man sich damit automatisch einfängt, sind oft gravierend
-> bei einem gut designten Netz braucht man keine Kosten tunen

/#9370

[Zwerg#7]

-> auto-cost reference-bandwidth 10000

Danke für den Tipp, wußte ich noch nicht 

bei einem gut designten Netz braucht man keine Kosten tunen

Hmm, gehen wir mal von einem LAN mit typischem Layer Design aus -> Core, Access-Distribution, Server-Distribution, WAN-Distribution,... und natürlich alles redundant (soll'n ja manche tatsächlich so umgesetzt haben  )
Dann hat man doch ohne Tuning keine definierten Wege sondern eben Equal-Cost Loadbalancing. Manche wollen das vielleicht so aber wenn nicht dann kommt man IMHO wohl nicht um Cost-Tuning herum.

Aber zugegeben, ich hab da ein bisschen den LAN-Fokus; Im WAN würde ich wohl auch keine Costs verändern...

[#9370]

Dann hat man doch ohne Tuning keine definierten Wege sondern eben Equal-Cost Loadbalancing. Manche wollen das vielleicht so aber wenn nicht dann kommt man IMHO wohl nicht um Cost-Tuning herum.

Hmm - das müsste man sich im Detail anschauen, aber vielleicht habt ihr ja die falschen Consultants   

/#9370

[MrBean]

Also im Lan sollte Loadbalancing schon ok sein, da muss er keinen bestimmten Weg nehmen, ist sogar besser, wenn die Leitungen auch alle genutzt werden, die da sind, dafür ist es ausgelegt. Was über das WAN reinkommt, wäre schon nicht schlecht, wenns geregelt ist...

[#9370]

Was über das WAN reinkommt, wäre schon nicht schlecht, wenns geregelt ist...

Warum? Wenn du unterschiedliche Bandbreiten hast, dann wird das ja automatisch über die Cost geregelt (bandwidth command nicht vergessen!)

/#9370