[OSPF] DRとBDRの話

最近になってOSPFでDRに関する認識が間違えていたことに気がついた。

ということでメモ。
何かというと, DRが落ちるとBDRがDRに昇格されるまでの間, そのネットワーク内ではルートが消失するということ。
正直, BDRがDB保持しているのでネイバーはそれを即時引き継ぐものだと思っていた。
しかし, とある環境で「なーんかメインの経路じゃないルータが落ちてPingロストするなー」なんて思って調べていて, わかったのがこれ。◯十年ネットワークエンジニアやっていたけど, この挙動は全く知なかったし意識したこともなかった。「障害ポイントによっては収束に時間がかかる場合があるよな」くらいの認識でした。
まだまだ知らないことばかり。
OSPF v2のRFC「https://www.ietf.org/rfc/rfc2328.txt」にも書いてありました。
Section 2 of this document discusses the directed graph
representation of an area. Router nodes are labelled with their
Router ID. Transit network nodes are actually labelled with the
IP address of their Designated Router. It follows that when the
Designated Router changes, it appears as if the network node on
the graph is replaced by an entirely new node. This will cause
the network and all its attached routers to originate new LSAs.
Until the link-state databases again converge, some temporary
loss of connectivity may result.
This may result in ICMP
unreachable messages being sent in response to data traffic.
For that reason, the Designated Router should change only
infrequently. Router Priorities should be configured so that
the most dependable router on a network eventually becomes
Designated Router.

改めて検証してみる。
ルータ3台でOSPFを組むシンプルな構成。
PC1からPC2の経路はRouter1~Router2となるようにOSPFのコストを調整する。その上で, Router 1のPriorityを0にしてDR選出から外し, 2のPriorityを50, 3のPriorityを100にする。これで, 通信経路はRouter2をメインとするが, DRはRouter3になる。

正常時のshow ip ospf neとshow ip ro の出力結果。設定どおり。

Router1のネイバー

IOU1#sh ip ospf ne

Neighbor ID Pri State Dead Time Address Interface
192.168.3.2 50 FULL/BDR 00:00:35 192.168.2.2 Ethernet0/0
192.168.3.3 100 FULL/DR 00:00:31 192.168.2.3 Ethernet0/0

IOU1#sh ip route
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override

Gateway of last resort is not set

192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.1.0/24 is directly connected, Ethernet0/1
L 192.168.1.1/32 is directly connected, Ethernet0/1
192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.2.0/24 is directly connected, Ethernet0/0
L 192.168.2.1/32 is directly connected, Ethernet0/0
O 192.168.3.0/24 [110/110] via 192.168.2.2, 00:10:35, Ethernet0/0

Router 2のネイバー

IOU2#sh ip ospf ne
Neighbor ID Pri State Dead Time Address Interface
192.168.2.1 0 FULL/DROTHER 00:00:33 192.168.2.1 Ethernet0/0
192.168.3.3 100 FULL/DR 00:00:35 192.168.2.3 Ethernet0/0
IOU2#sh ip route 
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override

Gateway of last resort is not set

O 192.168.1.0/24 [110/110] via 192.168.2.1, 00:11:53, Ethernet0/0
192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.2.0/24 is directly connected, Ethernet0/0
L 192.168.2.2/32 is directly connected, Ethernet0/0
192.168.3.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.3.0/24 is directly connected, Ethernet0/1
L 192.168.3.2/32 is directly connected, Ethernet0/1

Router 3のネイバー

IOU3#sh ip ospf
*Apr 18 07:04:07.804: %SYS-5-CONFIG_I: Configured from console by console
IOU3#sh ip ospf ne

Neighbor ID Pri State Dead Time Address Interface
192.168.2.1 0 FULL/DROTHER 00:00:38 192.168.2.1 Ethernet0/0
192.168.3.2 50 FULL/BDR 00:00:34 192.168.2.2 Ethernet0/0
IOU3#sh ip route 
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override

Gateway of last resort is not set

O 192.168.1.0/24 [110/210] via 192.168.2.1, 00:12:06, Ethernet0/0
192.168.2.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.2.0/24 is directly connected, Ethernet0/0
L 192.168.2.3/32 is directly connected, Ethernet0/0
192.168.3.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.3.0/24 is directly connected, Ethernet0/1
L 192.168.3.3/32 is directly connected, Ethernet0/1

と, ここまでやってCiscoでは収束が早くて事象が出ない。 たまにPingロスト起きるけどこれOSPF関係ないやつだ。

Debugとってみたらコンマ数秒で切り替わっていたのでCiscoはよく出来ているということがわかりました。


ということでVyOSで検証。

VyOSではBDRがいなくなるとルートアップデートしないというバグらしき挙動をするので構成はちょっと変えた。

VyOS1のステータス。VyOS3がDRでVyOS2がBDR。PC2への宛先はVyOS2に向いている。なお, Helloは5秒。Deadは15秒にした。

vyos1@vyos:~$ sh ip ospf ne

Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL
10.10.20.2 50 Full/Backup 11.994s 10.10.10.2 eth0:10.10.10.1 0 0 0
10.10.10.3 100 Full/DR 10.991s 10.10.10.3 eth0:10.10.10.1 0 0 0
vyos@vyos:~$ sh ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route

O 10.10.10.0/24 [110/10] is directly connected, eth0, 00:17:16
C>* 10.10.10.0/24 is directly connected, eth0
O>* 10.10.20.0/24 [110/30] via 10.10.10.2, eth0, 00:00:08
O>* 10.10.30.0/24 [110/40] via 10.10.10.2, eth0, 00:00:08
C>* 127.0.0.0/8 is directly connected, lo
O 192.168.1.0/24 [110/10] is directly connected, eth3, 00:17:16
C>* 192.168.1.0/24 is directly connected, eth3
O>* 192.168.2.0/24 [110/40] via 10.10.10.2, eth0, 00:00:08

この時点で, PC1からPC2への経路はVyOS1~VyOS2~VyOS4となっている。VyOS3はバックアップラインとなっている。
ここで, 通信に影響の無いはずのVyOS3(DR)のインタフェースをDisableにする。
VyOS3

vyos3@vyos# set interfaces ethernet eth0 disable
[edit]
vyos@vyos# commit
[edit]
vyos@vyos#

VyOS1

vyos1@vyos:~$ sh ip ro
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route

C>* 10.10.10.0/24 is directly connected, eth0
C>* 127.0.0.0/8 is directly connected, lo
O 192.168.1.0/24 [110/10] is directly connected, eth3, 00:33:43
C>* 192.168.1.0/24 is directly connected, eth3
vyos@vyos:~$
vyos@vyos:~$ sh ip ospf ne

Neighbor ID Pri State Dead Time Address Interface RXmtL RqstL DBsmL
10.10.20.2 50 Full/DR 14.753s 10.10.10.2 eth0:10.10.10.1 1 0 0

Pingの状態はというと・・・。

84 bytes from 192.168.2.10 icmp_seq=136 ttl=61 time=4.304 ms
84 bytes from 192.168.2.10 icmp_seq=137 ttl=61 time=5.105 ms
*192.168.1.1 icmp_seq=138 ttl=64 time=0.999 ms (ICMP type:3, code:0, Destination network unreachable)
*192.168.1.1 icmp_seq=139 ttl=64 time=0.832 ms (ICMP type:3, code:0, Destination network unreachable)
*192.168.1.1 icmp_seq=140 ttl=64 time=0.925 ms (ICMP type:3, code:0, Destination network unreachable)
*192.168.1.1 icmp_seq=141 ttl=64 time=1.416 ms (ICMP type:3, code:0, Destination network unreachable)
192.168.2.10 icmp_seq=142 timeout
*192.168.1.1 icmp_seq=143 ttl=64 time=1.184 ms (ICMP type:3, code:0, Destination network unreachable)
192.168.2.10 icmp_seq=144 timeout
*192.168.1.1 icmp_seq=145 ttl=64 time=1.185 ms (ICMP type:3, code:0, Destination network unreachable)
192.168.2.10 icmp_seq=146 timeout
*192.168.1.1 icmp_seq=147 ttl=64 time=1.224 ms (ICMP type:3, code:0, Destination network unreachable)
192.168.2.10 icmp_seq=148 timeout
*192.168.1.1 icmp_seq=149 ttl=64 time=0.886 ms (ICMP type:3, code:0, Destination network unreachable)
192.168.2.10 icmp_seq=150 timeout
192.168.2.10 icmp_seq=151 timeout
192.168.2.10 icmp_seq=152 timeout
84 bytes from 192.168.2.10 icmp_seq=153 ttl=61 time=3.531 ms

16秒ほどパケロスしていた。
VyOSなので, DRが切り替わってBDRが選出されるまでの間が通信断になっていると思われる。

OSPFの仕様ということでしょうがないのかもしれないが, アクティブなルートに関係ないところでDRが落ちると影響出るというのは設計時には要注意ですね。
アップデートの負荷が小さいのであれば, イーサネットでもPoint-to-Multipointにした方が良いのではないかと思いました。