5
OSPF-Redundanz über GRE-Tunnel
OSPF-Redundanz über LAN und GRE-Tunnel... was muss konfiguriert werden?
Hallo zusammen,
Zwischen zwei Routern sollen per OSPF Routen ausgetauscht werden. Zwecks Redundanz sind diese sowohl über eine Layer-2-Strecke als auch über das Internet mittels eines GRE-Tunnels verbunden. Allerdings kommt es beim Ausfall einer der Strecken zu erheblichen Problemen mit OSPF.
Die Router sind in einer NSSA-Area konfiguriert. Beide Router hängen an unterschiedlichen Switches, d.h. in Falle eines Problems zwischen diesen beiden Switches bleiben die entsprechenden Links auf den Routern, über welche diese sich direkt erreichen können, aktiv. Die Router haben zusätzlich zu dieser Layer-2-Verbindung noch jeweils eine Verbindung zum Internet, über welche sie einen GRE-Tunnel aufbauen. Über diesen Tunnel soll bei einem Ausfall der LAN-Verbindung OSPF weiter dafür sorgen, dass die üblichen Routinginformationen weiterhin übermittelt werden. Schön wäre es allerdings, wenn der Weg über die Layer-2-Strecke, falls vorhanden, präferiert wird.
Die Konfiguration sieht also (vereinfacht) so aus:
Router A:
Fällt nun die Layer-2-Strecke aus und der Tunnel wir dann aktiviert, funktioniert soweit alles. Ist der Tunnel allerdings bereits vorher aktiv, bekommt scheinbar manchmal z.B. Router B von Router A zwar Routen per OSPF über den Tunnel, hat aber als ip next-hop immer noch die 192.168.0.1. Leider habe ich noch nicht viele Erfahrungen mit OSPF, denke aber da es grundsätzlich wie gewünscht funktioniert (mit wenigen manuellen Eingriffen), müsste eine automatische Lösung ebenfalls realisierbar sein. Meine wichtigsten Fragen wären:
Was muss konfiguriert werden damit der Tunnel wirklich nur im Notfalls genutzt wird?
Offenbar werden LSAs von Router B akzeptiert, obwohl er über das entsprechende Subnetz selbst keinen Neighbor mehr finden kann, woran liegt das?
Wieso macht es einen Unterschied ob der Tunnel vor dem Ausfall der Layer-2-Strecke aktiv war oder nicht?
Vielen Dank für die Hilfe!
Zwischen zwei Routern sollen per OSPF Routen ausgetauscht werden. Zwecks Redundanz sind diese sowohl über eine Layer-2-Strecke als auch über das Internet mittels eines GRE-Tunnels verbunden. Allerdings kommt es beim Ausfall einer der Strecken zu erheblichen Problemen mit OSPF.
Die Router sind in einer NSSA-Area konfiguriert. Beide Router hängen an unterschiedlichen Switches, d.h. in Falle eines Problems zwischen diesen beiden Switches bleiben die entsprechenden Links auf den Routern, über welche diese sich direkt erreichen können, aktiv. Die Router haben zusätzlich zu dieser Layer-2-Verbindung noch jeweils eine Verbindung zum Internet, über welche sie einen GRE-Tunnel aufbauen. Über diesen Tunnel soll bei einem Ausfall der LAN-Verbindung OSPF weiter dafür sorgen, dass die üblichen Routinginformationen weiterhin übermittelt werden. Schön wäre es allerdings, wenn der Weg über die Layer-2-Strecke, falls vorhanden, präferiert wird.
Die Konfiguration sieht also (vereinfacht) so aus:
Router A:
interface Tunnel100
description GRE-Tunnel zu Router B
bandwidth 100000
ip address 10.0.1.1 255.255.255.252
ip mtu 1476
ip route-cache flow
ip ospf cost 500
tunnel source 10.0.5.1
tunnel destination 10.0.6.2
interface FastEthernet0/0
no ip address
ip address 192.168.0.1 255.255.255.248
duplex full
speed auto
no snmp trap link-status
no clns route-cache
router ospf 100
no log-adjacency-changes
area 1 nssa
redistribute connected subnets
redistribute static subnets
network 10.0.1.0 0.0.0.3 area 1
network 192.168.0.0 0.0.0.7 area 1
Router B:
interface Tunnel100
description GRE-Tunnel zu Router A
bandwidth 100000
ip address 10.0.1.2 255.255.255.252
ip mtu 1476
ip route-cache flow
ip ospf cost 500
tunnel source 10.0.6.2
tunnel destination 10.0.5.1
interface FastEthernet0/0
no ip address
ip address 192.168.0.2 255.255.255.248
duplex full
speed auto
no snmp trap link-status
no clns route-cache
router ospf 100
no log-adjacency-changes
area 1 nssa
redistribute connected subnets
redistribute static subnets
network 10.0.1.0 0.0.0.3 area 1
network 192.168.0.0 0.0.0.7 area 1Was muss konfiguriert werden damit der Tunnel wirklich nur im Notfalls genutzt wird?
Offenbar werden LSAs von Router B akzeptiert, obwohl er über das entsprechende Subnetz selbst keinen Neighbor mehr finden kann, woran liegt das?
Wieso macht es einen Unterschied ob der Tunnel vor dem Ausfall der Layer-2-Strecke aktiv war oder nicht?
Vielen Dank für die Hilfe!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 127190
Url: https://administrator.de/contentid/127190
Printed on: April 19, 2024 at 03:04 o'clock
5 Comments
Latest comment
Generell ist deine Konfig so richtig. Was allerdings etwas verwirrend ist, ist deine Cost Berechnung auf dem Tunnel Interface.
Per default wird die OSPF Cost mit 100.000.000 / Bandbreite in bps gemessen ist also invers proportional zur Bandbreite.
Das bedeutet primär wir der Bandbreitenwert zur Cost Kalkulation für das jeweilige Interface herangezogen wenn die Cost nicht statisch gesetzt ist.
Du machst es aber irgendwie doppelt gemoppelt indem du erst zwangsweise die Bandwith setzt um sie mit dem Cost Parameter dann wieder zu killen. Vermutlich bekommst du dadurch irgendwelche Probleme. Die Cost mit 500 also einer fiktiven 200 kBit Leitung anzugeben ist auch sehr konservativ oder hat deine Internet Anbindung nur ISDN NiveaU ??
Fazit: Bandwith Kommando vom Tunnel weglöschen und den Tunnel auf eine OSPF Cost von 50 setzen, was einer 2 Mbit Leitung entspricht und bei heutigen Geschw. eher realistisch ist.
Du kannst aber besser ganz auf ein Cost tuning verzichten, denn wenn du dir mit sh int tunn x mal die default Bandwith auf einem Tunnel Interface ansiehst:
7200test#sh int tunn 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set.....
erkennst du selber das Cisco per default 9kbit annimmt. Damit erübrigt sich also jede Cost Fummelei auf dem Interface. Du solltest auch besser die Tunnel IP MTU auf ip mtu 1440 1440 Byte setzen denn mit deinem Wert kann es passieren das der GRE Encapsulation Overhead noch zu groß wird !
Damit sollte es eigentlich auf Anhieb klappen.
Ein paar Outputs ala show ospf neig oder sh ospf data wären hier auch etwas hilfreicher gewesen...
Guckst du dazu auch hier:
Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
Per default wird die OSPF Cost mit 100.000.000 / Bandbreite in bps gemessen ist also invers proportional zur Bandbreite.
Das bedeutet primär wir der Bandbreitenwert zur Cost Kalkulation für das jeweilige Interface herangezogen wenn die Cost nicht statisch gesetzt ist.
Du machst es aber irgendwie doppelt gemoppelt indem du erst zwangsweise die Bandwith setzt um sie mit dem Cost Parameter dann wieder zu killen. Vermutlich bekommst du dadurch irgendwelche Probleme. Die Cost mit 500 also einer fiktiven 200 kBit Leitung anzugeben ist auch sehr konservativ oder hat deine Internet Anbindung nur ISDN NiveaU ??
Fazit: Bandwith Kommando vom Tunnel weglöschen und den Tunnel auf eine OSPF Cost von 50 setzen, was einer 2 Mbit Leitung entspricht und bei heutigen Geschw. eher realistisch ist.
Du kannst aber besser ganz auf ein Cost tuning verzichten, denn wenn du dir mit sh int tunn x mal die default Bandwith auf einem Tunnel Interface ansiehst:
7200test#sh int tunn 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set.....
erkennst du selber das Cisco per default 9kbit annimmt. Damit erübrigt sich also jede Cost Fummelei auf dem Interface. Du solltest auch besser die Tunnel IP MTU auf ip mtu 1440 1440 Byte setzen denn mit deinem Wert kann es passieren das der GRE Encapsulation Overhead noch zu groß wird !
Damit sollte es eigentlich auf Anhieb klappen.
Ein paar Outputs ala show ospf neig oder sh ospf data wären hier auch etwas hilfreicher gewesen...
Guckst du dazu auch hier:
Cisco, Mikrotik, pfSense VPN Standort Vernetzung mit dynamischem Routing
Hallo,
Ich habe das Testszenario nochmal überarbeitet und wie empfohlen die Cost von dem Tunnel-Interface entfernt. Ich würde nun gerne ein Problem nach dem anderen lösen, das erste ist nun, dass alle Routen nun scheinbar über den Tunnel laufen und ich verstehe nicht warum. Hier meine Konfiguration inkl. einiger Outputs:
Ich habe das Testszenario nochmal überarbeitet und wie empfohlen die Cost von dem Tunnel-Interface entfernt. Ich würde nun gerne ein Problem nach dem anderen lösen, das erste ist nun, dass alle Routen nun scheinbar über den Tunnel laufen und ich verstehe nicht warum. Hier meine Konfiguration inkl. einiger Outputs:
Router A:
interface Loopback100
description Loopback OSPF
ip address 220.0.1.1 255.255.255.255
interface Tunnel100
description Tunnel zu RouterB
bandwidth 100
ip address 10.0.1.1 255.255.255.0
ip mtu 1476
tunnel source 192.168.0.1
tunnel destination 192.168.1.1
interface FastEthernet0/0
description LAN zu RouterB
ip address 10.0.0.1 255.255.255.0
duplex full
speed auto
interface FastEthernet1/0
description Uplink zu Transit
ip address 192.168.0.1 255.255.255.0
duplex full
speed auto
interface FastEthernet1/1
description LAN zu Hosts
ip address 200.0.0.1 255.255.255.0
duplex full
speed auto
router ospf 100
log-adjacency-changes
area 1 nssa
redistribute connected subnets
redistribute static subnets
network 10.0.0.0 0.0.0.255 area 1
network 10.0.1.0 0.0.0.255 area 1
ip classless
ip route 192.168.1.1 255.255.255.255 192.168.0.2
RouterA#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
220.0.0.1 0 FULL/ - 00:00:39 10.0.1.2 Tunnel100
220.0.0.1 1 FULL/BDR 00:00:38 10.0.0.2 FastEthernet0/
0
RouterA#show ip ospf database
OSPF Router with ID (220.0.1.1) (Process ID 100)
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
220.0.0.1 220.0.0.1 136 0x80000011 0x001546 3
220.0.1.1 220.0.1.1 630 0x8000000E 0x00CB93 3
Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.0.0.1 220.0.1.1 635 0x80000001 0x0090FC
Type-7 AS External Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Tag
192.168.0.0 220.0.1.1 636 0x80000008 0x004CEE 0
192.168.0.1 220.0.0.1 79 0x80000009 0x0055E3 0
192.168.1.0 220.0.0.1 79 0x80000009 0x0054E4 0
192.168.1.1 220.0.1.1 636 0x80000008 0x003702 0
200.0.0.0 220.0.1.1 636 0x80000008 0x00CB10 0
200.0.1.0 220.0.0.1 79 0x80000009 0x00D306 0
220.0.0.1 220.0.0.1 79 0x80000009 0x00CFF5 0
220.0.1.1 220.0.1.1 637 0x80000008 0x00B114 0
RouterA#show ip ospf interface
Tunnel100 is up, line protocol is up
Internet Address 10.0.1.1/24, Area 1
Process ID 100, Router ID 220.0.1.1, Network Type POINT_TO_POINT, Cost: 1000
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:06
Index 2/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 3, maximum is 5
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 220.0.0.1
Suppress hello for 0 neighbor(s)
FastEthernet0/0 is up, line protocol is up
Internet Address 10.0.0.1/24, Area 1
Process ID 100, Router ID 220.0.1.1, Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 220.0.1.1, Interface address 10.0.0.1
Backup Designated router (ID) 220.0.0.1, Interface address 10.0.0.2
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:06
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 5
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 220.0.0.1 (Backup Designated Router)
Suppress hello for 0 neighbor(s)
RouterA#show ip route ospf
220.0.0.0/32 is subnetted, 1 subnets
O N2 220.0.0.1 [110/20] via 10.0.1.2, 00:04:15, Tunnel100
O N2 200.0.1.0/24 [110/20] via 10.0.1.2, 00:04:15, Tunnel100
192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
O N2 192.168.1.0/24 [110/20] via 10.0.1.2, 00:04:15, Tunnel100
Router B:
interface Loopback100
description Loopback OSPF
ip address 220.0.0.1 255.255.255.2
interface Tunnel100
description Tunnel zu RouterA
bandwidth 100
ip address 10.0.1.2 255.255.255.0
ip mtu 1476
tunnel source 192.168.1.1
tunnel destination 192.168.0.1
interface FastEthernet0/0
description LAN zu RouterA
ip address 10.0.0.2 255.255.255.0
duplex full
speed auto
interface FastEthernet1/0
description Uplink zu Transit
ip address 192.168.1.1 255.255.255.0
duplex full
speed auto
interface FastEthernet1/1
description LAN zu Hosts
ip address 200.0.1.1 255.255.255.0
duplex full
speed auto
router ospf 100
log-adjacency-changes
area 1 nssa
redistribute connected subnets
redistribute static subnets
network 10.0.0.0 0.0.0.255 area 1
network 10.0.1.0 0.0.0.255 area 1
ip classless
ip route 192.168.0.1 255.255.255.255 192.168.1.2
RouterB#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
220.0.1.1 0 FULL/ - 00:00:20 10.0.1.1 Tunnel100
220.0.1.1 1 FULL/DR 00:00:20 10.0.0.1 FastEthernet0/
0
RouterB#show ip ospf database
OSPF Router with ID (220.0.0.1) (Process ID 100)
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
220.0.0.1 220.0.0.1 343 0x80000011 0x001546 3
220.0.1.1 220.0.1.1 1446 0x8000000E 0x00CB93 3
Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.0.0.1 220.0.1.1 1457 0x80000001 0x0090FC
Type-7 AS External Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Tag
192.168.0.0 220.0.1.1 1457 0x80000008 0x004CEE 0
192.168.0.1 220.0.0.1 214 0x80000009 0x0055E3 0
192.168.1.0 220.0.0.1 214 0x80000009 0x0054E4 0
192.168.1.1 220.0.1.1 1457 0x80000008 0x003702 0
200.0.0.0 220.0.1.1 1457 0x80000008 0x00CB10 0
200.0.1.0 220.0.0.1 214 0x80000009 0x00D306 0
220.0.0.1 220.0.0.1 214 0x80000009 0x00CFF5 0
220.0.1.1 220.0.1.1 1458 0x80000008 0x00B114 0
RouterB#show ip ospf interface
Tunnel100 is up, line protocol is up
Internet Address 10.0.1.2/24, Area 1
Process ID 100, Router ID 220.0.0.1, Network Type POINT_TO_POINT, Cost: 1000
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:08
Index 2/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 3, maximum is 6
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 220.0.1.1
Suppress hello for 0 neighbor(s)
FastEthernet0/0 is up, line protocol is up
Internet Address 10.0.0.2/24, Area 1
Process ID 100, Router ID 220.0.0.1, Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State BDR, Priority 1
Designated Router (ID) 220.0.1.1, Interface address 10.0.0.1
Backup Designated router (ID) 220.0.0.1, Interface address 10.0.0.2
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:01
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 3, maximum is 6
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 220.0.1.1 (Designated Router)
Suppress hello for 0 neighbor(s)
RouterB#show ip route ospf
220.0.1.0/32 is subnetted, 1 subnets
O N2 220.0.1.1 [110/20] via 10.0.1.1, 00:09:41, Tunnel100
O N2 200.0.0.0/24 [110/20] via 10.0.1.1, 00:09:41, Tunnel100
192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
O N2 192.168.0.0/24 [110/20] via 10.0.1.1, 00:09:41, Tunnel100
Hallo nochmal,
das andere Problem habe ich nun offenbar lösen können. Ich habe übersehen das man bei OSPF keine Point-to-Point-Konfiguration (GRE-Tunnel) mit einer Broadcast-Konfiguration mischen darf. Es hat also genügt auf beiden Routern in den Tunnel-Interfaces ip ospf network broadcast zu konfigurieren. Danach sind auch die OSPF-Neighbor über die Tunnel-Interfaces im State FULL/DR bzw. FULL/BDR statt nur FULL/ -. Trotzdem habe ich immer noch das Problem das die Routen nicht wie gewünscht alle erstmal nur über das FastEthernet-Interface reinkommen. Die Cost scheint auch keinen Einfluss darauf zu nehmen. Wenn dazu noch jemand einen nützlichen Hinweis hätte wäre mir wirklich sehr geholfen
das andere Problem habe ich nun offenbar lösen können. Ich habe übersehen das man bei OSPF keine Point-to-Point-Konfiguration (GRE-Tunnel) mit einer Broadcast-Konfiguration mischen darf. Es hat also genügt auf beiden Routern in den Tunnel-Interfaces ip ospf network broadcast zu konfigurieren. Danach sind auch die OSPF-Neighbor über die Tunnel-Interfaces im State FULL/DR bzw. FULL/BDR statt nur FULL/ -. Trotzdem habe ich immer noch das Problem das die Routen nicht wie gewünscht alle erstmal nur über das FastEthernet-Interface reinkommen. Die Cost scheint auch keinen Einfluss darauf zu nehmen. Wenn dazu noch jemand einen nützlichen Hinweis hätte wäre mir wirklich sehr geholfen
Was heisst denn "Erstmal" ?? Die OSPF Updates kommen immer gleichzeitig an auf allen Interfaces wo OSPF aktiv ist !
Wichtig und relevant ist was in deiner Routing Tabelle steht (sh ip route) dort sollte die aktive Route mit einem * gekennzeichnet sein und das MUSS bei korrekter Cost Konfiguration (oder auch ganz ohne ohne, denn das Tunnel Interface hat IMMER eine geringere Cost !) immer das Ethernet Interface sein mit dem Tunnel als Backup !
Broadcast passt eigentlich auch nicht auf einem Tunnel Interface, denn ein Tunnel Interface ist IMMER ein Point to Point Interface !
Richtig wäre hier auf beiden Seiten eigentlich ein "ip ospf network point-to-point".
Nimm doch den Tunnel einseitig erstmal auf shutdown und checke ob die Updates üder das FA Interfaces sauber übertragen werden und die Routing Table korrekt aufgebaut wird !
Wenn das klappt machst du ein no shut auf dem Tunnel und prüfst die Routing Table.
Noch 2 Fragen zur Konfig:
1.) Öffentliche IP Adressen fürs Loopback Interface ?? Mmmmhhh
2.) Warum nimmst du als Tunnel Source und Destination nicht deine Loopback Adressen. So bist du unabhängiger vom physischen Zustand der Interface. Ist dein Interface down geht auch der Tunnel down !! Nimmt man Loopback IPs als Tunnel source und destination kann das nicht passieren !
Das 255.255.255.2 bei Router B ist wohl hoffentlich nur ein Cut and paste Fehler, oder ??
Wichtig und relevant ist was in deiner Routing Tabelle steht (sh ip route) dort sollte die aktive Route mit einem * gekennzeichnet sein und das MUSS bei korrekter Cost Konfiguration (oder auch ganz ohne ohne, denn das Tunnel Interface hat IMMER eine geringere Cost !) immer das Ethernet Interface sein mit dem Tunnel als Backup !
Broadcast passt eigentlich auch nicht auf einem Tunnel Interface, denn ein Tunnel Interface ist IMMER ein Point to Point Interface !
Richtig wäre hier auf beiden Seiten eigentlich ein "ip ospf network point-to-point".
Nimm doch den Tunnel einseitig erstmal auf shutdown und checke ob die Updates üder das FA Interfaces sauber übertragen werden und die Routing Table korrekt aufgebaut wird !
Wenn das klappt machst du ein no shut auf dem Tunnel und prüfst die Routing Table.
Noch 2 Fragen zur Konfig:
1.) Öffentliche IP Adressen fürs Loopback Interface ?? Mmmmhhh
2.) Warum nimmst du als Tunnel Source und Destination nicht deine Loopback Adressen. So bist du unabhängiger vom physischen Zustand der Interface. Ist dein Interface down geht auch der Tunnel down !! Nimmt man Loopback IPs als Tunnel source und destination kann das nicht passieren !
Das 255.255.255.2 bei Router B ist wohl hoffentlich nur ein Cut and paste Fehler, oder ??
Das "erstmal" war vielleicht schlecht formuliert. Die Sache mit den OSPF-Updates ist auch klar, was ich sagen wollte ist, die Routen die ich über OSPF empfangen hatten nicht alleine das Neighbor-Interface des anderen Routers via der FastEthernet-Strecke als Ziel, d.h. der Traffic wäre vermehrt weiter über den Tunnel geflossen (was ja nicht gewollt ist). Das ich diese Informationen nicht aus den Fingern gesaugt, sondern mit "sh ip route", "sh ip ospf route" und ähnlichen Befehlen erhalten habe, dass ist hoffentlich klar
Tunnel shutten und unshutten hatte ich schon ganz am Anfang probiert, das führte schon zu Problemen, da die Routing-Updates dann falsche LSAs erhalten haben. Ist aber nun auch alles gelöst, zunächst noch zu den Fragen:
1.) Ist nur ein Testszenario, war mir einfach gerade in den Kopf gekommen
2.) Ich will ja gar nicht verhindern dass der Tunnel down geht, warum sollte ich? Layer-3-Strecke weg, Tunnel weg. Wozu einen Backup-Tunnel aktiv halten, der nur bei Ausfall der Layer-2-Strecke was machen soll, wenn die Backup-Strecke selbst weg ist?
Und ja, die Subnetmask ist natürlich nur ein Fehler beim Konfig kopieren, da würde der Router würde da eh direkt schreien ;)
Jedenfalls, als Lösung habe ich die Interfaces beide auf "point-to-multipoint" umgestellt. Nach meinen Recherchen hinsichtlich diesen Themas bin ich darauf gestoßen das "point-to-multipoint" als einzige Konfiguration die Möglichkeit gibt einem Neighbor sozusagen direkt eine Cost zuzuweisen. Zudem wird keine LSA-DB aufgebaut, die Verbindungen werden als Punkt-zu-Punkt bewertet. D.h. beide Neighbor-Adresse, sowohl über den Tunnel als auch über das FE-Interface sind nun im Status "FULL/ -", primär wird nun immer das FE-Interface genutzt, fällt dieses aus dann ist der entsprechende Neighbor weg (d.h. es gibt auch keine falschen LSAs über das jeweils andere Interface), der Traffic fliesst über den Tunnel. Damit dies zeitnah passiert habe ich noch die OSPF-Timer runtergesetzt ("ip ospf hello-interval 10").
Es mag durchaus sein das andere Konfigurationen ebenfalls funktionieren würden, diese tut es jedenfalls auch
Tunnel shutten und unshutten hatte ich schon ganz am Anfang probiert, das führte schon zu Problemen, da die Routing-Updates dann falsche LSAs erhalten haben. Ist aber nun auch alles gelöst, zunächst noch zu den Fragen:
1.) Ist nur ein Testszenario, war mir einfach gerade in den Kopf gekommen
2.) Ich will ja gar nicht verhindern dass der Tunnel down geht, warum sollte ich? Layer-3-Strecke weg, Tunnel weg. Wozu einen Backup-Tunnel aktiv halten, der nur bei Ausfall der Layer-2-Strecke was machen soll, wenn die Backup-Strecke selbst weg ist?
Und ja, die Subnetmask ist natürlich nur ein Fehler beim Konfig kopieren, da würde der Router würde da eh direkt schreien ;)
Jedenfalls, als Lösung habe ich die Interfaces beide auf "point-to-multipoint" umgestellt. Nach meinen Recherchen hinsichtlich diesen Themas bin ich darauf gestoßen das "point-to-multipoint" als einzige Konfiguration die Möglichkeit gibt einem Neighbor sozusagen direkt eine Cost zuzuweisen. Zudem wird keine LSA-DB aufgebaut, die Verbindungen werden als Punkt-zu-Punkt bewertet. D.h. beide Neighbor-Adresse, sowohl über den Tunnel als auch über das FE-Interface sind nun im Status "FULL/ -", primär wird nun immer das FE-Interface genutzt, fällt dieses aus dann ist der entsprechende Neighbor weg (d.h. es gibt auch keine falschen LSAs über das jeweils andere Interface), der Traffic fliesst über den Tunnel. Damit dies zeitnah passiert habe ich noch die OSPF-Timer runtergesetzt ("ip ospf hello-interval 10").
Es mag durchaus sein das andere Konfigurationen ebenfalls funktionieren würden, diese tut es jedenfalls auch
