無料ブログはココログ

【OSPF】 4. 同時にリスタートできる?

4. 同時にリスタートできる?

RFC3623では、ヘルパーモードに入る条件として 「グレースフル・リスタートを実行中でないこと」としています(セクション3.1の条件5)。 F社のルータは複数同時にリスタートできる、と言ってたのですが、どうも気になってしまいます。 F社のルータは何かしら特殊な処理を入れてるのかもしれませんが・・・

とりあえずJuniperはどうなの?ってことで、試してみました。結論から言うと、グレースフル・リスタートは失敗します。

前回の構成で、R6→R2に向かってpingを打ちつつ、R1とR2をほぼ同時にリスタートさせてみます。 すると、やっぱりパケットロスする期間が長くなってしまいます。

R6c7206#ping
Protocol [ip]:
Target IP address: 192.168.254.2
Repeat count [5]: 10000000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 192.168.254.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
*Sep 30 22:46:22: OSPF: scheduling rtr lsa for area 0
*Sep 30 22:46:22: OSPF: scheduling NET lsa on FastEthernet0/1
*Sep 30 22:46:22: OSPF: scheduling rtr lsa for area 0
*Sep 30 22:46:22: OSPF: scheduling rtr lsa for area 0
*Sep 30 22:46:22: OSPF: scheduling rtr lsa for area 0
*Sep 30 22:46:22: OSPF: scheduling rtr lsa for area 0!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
*Sep 30 22:46:27.332: %OSPF-5-ADJCHG: Process 100, Nbr 192.168.254.1 on FastEthernet0/1 from LOADING to FULL, Loading Done
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!......!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  ☆☆☆通信停止
*Sep 30 22:46:27: OSPF: scheduling rtr lsa for area 0
*Sep 30 22:46:27: OSPF: scheduling NET lsa on FastEthernet0/1
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (29987/29997), round-trip min/avg/max = 1/1/44 ms
R6c7206#

つづく

【OSPF】 3. grace-LSAパケット

3. grace-LSAパケット

それでは、実際に何が起こっているのか実験で突き止めてみましょう。

グレースフル・リスタートを実行するルータは、 再起動前にgrace-LSAをフラッドして周りのルータに協力を求めます。 R1(Juniper)が送信したこのLSAをCiscoで表示してみましょう。 grace-LSAはリンクローカルのオペークLSA(Type 7 Opaque-LSA)なので、 コマンドはshow ip ospf database opaque-linkです。 グレースフル・リスタートの期間中しか表示されませんので、 タイミング良くコマンドを投入しないといけません。

R6c7206#show ip ospf database opaque-link

            OSPF Router with ID (192.168.254.6) (Process ID 100)

                Type-9 Opaque Link Local Link States (Area 0)

  LS age: 8
  Options: (No TOS-capability, No DC)
  LS Type: Opaque Link-Local Link
  Link State ID: 3.0.0.0
  Opaque Type: 3
  Opaque ID: 0
  Advertising Router: 192.168.254.1
  LS Seq Number: 80000001
  Checksum: 0x711B
  Length: 44
  Associate Interface: FastEthernet0/1
  Unable to display opaque data

RFC3623によると、grace-LSAのフォーマットは次の通りです。 grace-LSAはOpaque Type=3, Opaque ID=0で固定です。

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            LS age             |     Options   |       9       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       3       |                    0                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Advertising Router                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     LS sequence number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         LS checksum           |             length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +-                            TLVs                             -+
      |                             ...                               |

Ciscoの表示もだいたいこのフォーマット通りですね。 Opaque LSAなので、Link State IDは存在しません。 Link State IDが3.0.0.0となっていますが、Opaque Type=3, Opaque ID=0の事です。

次にR1-R2間にEtherealを仕込んでパケットをキャプチャしてみましょう。

Etherealのデータ

No.     Time        Source                Destination           Protocol Info
     10 3.529154    192.168.1.1           224.0.0.5             OSPF     LS Update

Frame 10 (106 bytes on wire, 106 bytes captured)
    Arrival Time: Oct  1, 2004 19:28:32.826318000
    Time delta from previous packet: 0.002328000 seconds
    Time since reference or first frame: 3.529154000 seconds
    Frame Number: 10
    Packet Length: 106 bytes
    Capture Length: 106 bytes
Ethernet II, Src: 00:90:69:92:34:00, Dst: 01:00:5e:00:00:05
    Destination: 01:00:5e:00:00:05 (01:00:5e:00:00:05)
    Source: 00:90:69:92:34:00 (JuniperN_92:34:00)
    Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.1.1 (192.168.1.1), Dst Addr: 224.0.0.5 (224.0.0.5)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0xc0 (DSCP 0x30: Class Selector 6; ECN: 0x00)
        1100 00.. = Differentiated Services Codepoint: Class Selector 6 (0x30)
        .... ..0. = ECN-Capable Transport (ECT): 0
        .... ...0 = ECN-CE: 0
    Total Length: 92
    Identification: 0x247f (9343)
    Flags: 0x00
        0... = Reserved bit: Not set
        .0.. = Don't fragment: Not set
        ..0. = More fragments: Not set
    Fragment offset: 0
    Time to live: 1
    Protocol: OSPF IGP (0x59)
    Header checksum: 0xf25b (correct)
    Source: 192.168.1.1 (192.168.1.1)
    Destination: 224.0.0.5 (224.0.0.5)
Open Shortest Path First
    OSPF Header
        OSPF Version: 2
        Message Type: LS Update (4)
        Packet Length: 72
        Source OSPF Router: 192.168.254.1 (192.168.254.1)
        Area ID: 0.0.0.0 (Backbone)
        Packet Checksum: 0xac99 (correct)
        Auth Type: Null
        Auth Data (none)
    LS Update Packet
        Number of LSAs: 1
        LS Type: Opaque LSA, Link-local scope
            LS Age: 1 seconds
            Options: 0x2 (E)
            Link-State Advertisement Type: Opaque LSA, Link-local scope (9)
            Link State ID Opaque Type: grace-LSA (3)
            Link State ID Opaque ID: 0
            Advertising Router: 192.168.254.1 (192.168.254.1)
            LS Sequence Number: 0x80000001
            LS Checksum: 8a01
            Length: 44
            Unknown LSA Type 3

0000  01 00 5e 00 00 05 00 90 69 92 34 00 08 00 45 c0   ..^.....i.4...E.
0010  00 5c 24 7f 00 00 01 59 f2 5b c0 a8 01 01 e0 00   .\$....Y.[......
0020  00 05 02 04 00 48 c0 a8 fe 01 00 00 00 00 ac 99   .....H..........
0030  00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 01   ................
0040  02 09 03 00 00 00 c0 a8 fe 01 80 00 00 01 8a 01   ................
0050  00 2c 00 01 00 04 00 00 00 d2 00 02 00 01 02 00   .,..............
0060  00 00 00 03 00 04 c0 a8 01 01                     ..........

LS Updateパケットでフラッドしてます。 RFC3623のフォーマット通りなのですが、EtherealではOpaque LSAの中身までは解析できていません。 仕方ないので、手動で追ってみます。 データ部は次の部分です。

00 01 00 04 00 00 00 d2    00 02 00 01 02 00 00 00    00 03 00 04 c0 a8 01 01
----- ----- -----------    ----- ----- -----------    ----- ----- -----------
Type  Len   Value          Type  Len   Value(+pad)    Type  Len   Value
GracePeriod=0xd2=210秒     Reason=02=soft reload      IP interface address=192.168.1.1

仕様の通り、必要なTLVは全て揃ってます。グレース期間が210秒になっているのは、Juniperのデフォルトでしょうか。イーサネットなので、IP interface addressが必須になっています。

次にパケットの流れを追ってみましょう。

   Time        Source        Destination   Protocol Info
 3 0.429764    192.168.1.2   224.0.0.5     OSPF     Hello Packet
10 3.529154    192.168.1.1   224.0.0.5     OSPF     LS Update       ☆ grace-LSA
21 4.540671    192.168.1.2   224.0.0.5     OSPF     LS Acknowledge  ☆ LS ack遅すぎ
35 5.715653    192.168.1.1   224.0.0.5     OSPF     LS Update       ☆ grace-LSA再送
36 5.716834    192.168.1.2   192.168.1.1   OSPF     LS Update       ☆ DRの再送
50 6.725669    192.168.1.1   224.0.0.5     OSPF     LS Update       ☆ grace-LSA再送
51 6.726758    192.168.1.2   192.168.1.1   OSPF     LS Update       ☆ DRの再送
52 7.725888    192.168.1.1   224.0.0.5     OSPF     LS Update       ☆ grace-LSA再送
53 7.726746    192.168.1.2   192.168.1.1   OSPF     LS Update       ☆ DRの再送
54 8.725889    192.168.1.1   224.0.0.5     OSPF     LS Update       ☆ grace-LSA再送
55 8.726998    192.168.1.2   192.168.1.1   OSPF     LS Update       ☆ DRの再送
57 9.725977    192.168.1.1   224.0.0.5     OSPF     LS Update       ☆ grace-LSA再送
58 9.727042    192.168.1.2   192.168.1.1   OSPF     LS Update       ☆ DRの再送
61 10.310466   192.168.1.2   224.0.0.5     OSPF     Hello Packet
62 10.726050   192.168.1.1   224.0.0.5     OSPF     LS Update       ☆ grace-LSA再送
63 10.726912   192.168.1.2   192.168.1.1   OSPF     LS Update       ☆ DRの再送
64 11.736033   192.168.1.1   224.0.0.5     OSPF     Hello Packet    ☆ 再起動後のHello
73 19.211217   192.168.1.2   224.0.0.5     OSPF     Hello Packet    ☆ 再起動後のHello
74 19.213039   192.168.1.1   192.168.1.2   OSPF     DB Descr.
75 19.213207   192.168.1.1   224.0.0.5     OSPF     Hello Packet
76 19.214947   192.168.1.2   192.168.1.1   OSPF     DB Descr.
77 19.256350   192.168.1.1   192.168.1.2   OSPF     DB Descr.
78 19.257948   192.168.1.2   192.168.1.1   OSPF     DB Descr.
79 19.258150   192.168.1.2   192.168.1.1   OSPF     LS Request
80 19.306368   192.168.1.1   192.168.1.2   OSPF     DB Descr.
81 19.306559   192.168.1.1   192.168.1.2   OSPF     LS Request
82 19.306810   192.168.1.1   192.168.1.2   OSPF     LS Update       ☆ Router-LSA, Network-LSAの送信
83 19.308054   192.168.1.2   192.168.1.1   OSPF     LS Update       ☆ grace-LSAの送信
84 19.377657   192.168.1.1   224.0.0.5     OSPF     Hello Packet
85 20.321602   192.168.1.2   224.0.0.5     OSPF     LS Acknowledge
86 21.386654   192.168.1.1   224.0.0.5     OSPF     LS Update       ☆ grace-LSAを再生成
87 22.401730   192.168.1.2   224.0.0.5     OSPF     LS Acknowledge

グレースフル・リスタート中、grace-LSAが行ったり来たりしてます。 何しろリスタート中なので、これは仕方ないのかもしれません。 flagをerrorにセットして、Juniperでデバッグしてみると、次のようにエラーをクレームします。 納得です。

[edit protocols ospf traceoptions]
gsi@R1# Oct  1 16:18:17 trace_on: Tracing to "/var/log/ospf-debug" started
Oct  1 16:18:18 OSPF packet ignored: can't find neighbor for 192.168.1.2 (router-id 192.168.254.2)
Oct  1 16:18:18 OSPF rcvd LSAck 192.168.1.2 -> 224.0.0.5 (fe-0/0/0.0, IFL 0x43)
Oct  1 16:18:18   Version 2, length 44, ID 192.168.254.2, area 0.0.0.0
Oct  1 16:18:18   checksum 0x0, authtype 0
Oct  1 16:18:19 OSPF packet ignored: can't find neighbor for 192.168.1.2 (router-id 192.168.254.2)
Oct  1 16:18:19 OSPF rcvd LSUpdate 192.168.1.2 -> 224.0.0.5 (fe-0/0/0.0, IFL 0x43)
Oct  1 16:18:19   Version 2, length 72, ID 192.168.254.2, area 0.0.0.0
Oct  1 16:18:19   checksum 0x0, authtype 0
Oct  1 16:18:19   adv count 1
Oct  1 16:18:19 OSPF packet ignored: can't find neighbor for 192.168.0.6 (router-id 192.168.254.6)
Oct  1 16:18:19 OSPF rcvd LSUpdate 192.168.0.6 -> 192.168.0.1 (fe-0/0/3.0, IFL 0x45)
Oct  1 16:18:19   Version 2, length 72, ID 192.168.254.6, area 0.0.0.0
Oct  1 16:18:19   checksum 0x0, authtype 0
Oct  1 16:18:19   adv count 1
Oct  1 16:18:19 OSPF packet ignored: can't find neighbor for 192.168.0.6 (router-id 192.168.254.6)
Oct  1 16:18:19 OSPF rcvd LSAck 192.168.0.6 -> 224.0.0.5 (fe-0/0/3.0, IFL 0x45)
Oct  1 16:18:19   Version 2, length 44, ID 192.168.254.6, area 0.0.0.0
Oct  1 16:18:19   checksum 0x0, authtype 0
Oct  1 16:18:20 OSPF packet ignored: can't find neighbor for 192.168.0.6 (router-id 192.168.254.6)
Oct  1 16:18:20 OSPF rcvd LSUpdate 192.168.0.6 -> 192.168.0.1 (fe-0/0/3.0, IFL 0x45)
Oct  1 16:18:20   Version 2, length 72, ID 192.168.254.6, area 0.0.0.0
Oct  1 16:18:20   checksum 0x0, authtype 0
Oct  1 16:18:20   adv count 1
Oct  1 16:18:21 OSPF packet ignored: can't find neighbor for 192.168.1.2 (router-id 192.168.254.2)
Oct  1 16:18:21 OSPF rcvd LSUpdate 192.168.1.2 -> 224.0.0.5 (fe-0/0/0.0, IFL 0x43)
Oct  1 16:18:21   Version 2, length 72, ID 192.168.254.2, area 0.0.0.0
Oct  1 16:18:21   checksum 0x0, authtype 0
Oct  1 16:18:21   adv count 1
Oct  1 16:18:21 OSPF packet ignored: can't find neighbor for 192.168.0.6 (router-id 192.168.254.6)
Oct  1 16:18:21 OSPF rcvd LSUpdate 192.168.0.6 -> 192.168.0.1 (fe-0/0/3.0, IFL 0x45)
Oct  1 16:18:21   Version 2, length 72, ID 192.168.254.6, area 0.0.0.0
Oct  1 16:18:21   checksum 0x0, authtype 0
Oct  1 16:18:21   adv count 1
Oct  1 16:18:22 OSPF packet ignored: can't find neighbor for 192.168.1.2 (router-id 192.168.254.2)
Oct  1 16:18:22 OSPF rcvd LSUpdate 192.168.1.2 -> 224.0.0.5 (fe-0/0/0.0, IFL 0x43)
Oct  1 16:18:22   Version 2, length 72, ID 192.168.254.2, area 0.0.0.0
Oct  1 16:18:22   checksum 0x0, authtype 0
Oct  1 16:18:22   adv count 1
Oct  1 16:18:22 OSPF packet ignored: can't find neighbor for 192.168.0.6 (router-id 192.168.254.6)
Oct  1 16:18:22 OSPF rcvd LSUpdate 192.168.0.6 -> 192.168.0.1 (fe-0/0/3.0, IFL 0x45)
Oct  1 16:18:22   Version 2, length 72, ID 192.168.254.6, area 0.0.0.0
Oct  1 16:18:22   checksum 0x0, authtype 0
Oct  1 16:18:22   adv count 1
Oct  1 16:18:23 OSPF packet ignored: can't find neighbor for 192.168.1.2 (router-id 192.168.254.2)
Oct  1 16:18:23 OSPF rcvd LSUpdate 192.168.1.2 -> 224.0.0.5 (fe-0/0/0.0, IFL 0x43)
Oct  1 16:18:23   Version 2, length 72, ID 192.168.254.2, area 0.0.0.0
Oct  1 16:18:23   checksum 0x0, authtype 0
Oct  1 16:18:23   adv count 1
Oct  1 16:18:24 OSPF packet ignored: can't find neighbor for 192.168.1.2 (router-id 192.168.254.2)
Oct  1 16:18:24 OSPF rcvd LSUpdate 192.168.1.2 -> 224.0.0.5 (fe-0/0/0.0, IFL 0x43)
Oct  1 16:18:24   Version 2, length 72, ID 192.168.254.2, area 0.0.0.0
Oct  1 16:18:24   checksum 0x0, authtype 0
Oct  1 16:18:24   adv count 1
Oct  1 16:18:25 OSPF packet ignored: can't find neighbor for 192.168.1.2 (router-id 192.168.254.2)
Oct  1 16:18:25 OSPF rcvd LSUpdate 192.168.1.2 -> 224.0.0.5 (fe-0/0/0.0, IFL 0x43)
Oct  1 16:18:25   Version 2, length 72, ID 192.168.254.2, area 0.0.0.0
Oct  1 16:18:25   checksum 0x0, authtype 0
Oct  1 16:18:25   adv count 1
Oct  1 16:18:26 OSPF packet ignored: can't find neighbor for 192.168.1.2 (router-id 192.168.254.2)
Oct  1 16:18:26 OSPF rcvd LSUpdate 192.168.1.2 -> 224.0.0.5 (fe-0/0/0.0, IFL 0x43)
Oct  1 16:18:26   Version 2, length 72, ID 192.168.254.2, area 0.0.0.0
Oct  1 16:18:26   checksum 0x0, authtype 0
Oct  1 16:18:26   adv count 1
Oct  1 16:18:27 RPD_OSPF_NBRUP: OSPF neighbor 192.168.1.2 (fe-0/0/0.0) state changed from Init to 2Way due to Two way communication established
Oct  1 16:18:27 RPD_OSPF_NBRUP: OSPF neighbor 192.168.1.2 (fe-0/0/0.0) state changed from Loading to Full due to OSPF loading done
Oct  1 16:18:32 RPD_OSPF_NBRUP: OSPF neighbor 192.168.0.6 (fe-0/0/3.0) state changed from Init to ExStart due to Two way communication established
Oct  1 16:18:33 RPD_OSPF_NBRUP: OSPF neighbor 192.168.0.6 (fe-0/0/3.0) state changed from Loading to Full due to OSPF loading done

実はこの実験、ちょっと失敗してます。 本当ならR1は再起動しているので、リンクステートデータベースは空っぽになっているはずです。 にもかかわらず、DB Descrで既にLSAをたくさん所持してしまってます。

これはR6-R1の隣接が先に同期化してしまい、LSAをR6から学習してしまっているためです。 しかも、grace-LSAをパージするパケットが抜けてます。キャプチャの停止が早すぎたようです・・・

気に入らないので、またキャプチャしなおすかもしれません。

【OSPF】 2. 有効性の実証実験

2. 有効性の実証実験

最初に比較実験を行ってみたいと思います。 手元にはルーティングエンジンを二重化した機器がないので、OSPFプロセスを単独で再起動してみます。 このとき、グレースフル・リスタートのあるなしで、結果がどう違うのかを観察してみたいと思います。

次の図で、R1とR2はJuniper M10(JUNOS6.4)です。R6はCisco7204でIOS12.3(8)T3です。 R6からR2に向かってpingをうち続けます。 R1でrestart routingコマンドを投入してルーティングプロセスを再起動します。

普通にリスタートした場合

結果は次の通りです。

R6c7206#ping
Protocol [ip]:
Target IP address: 192.168.254.2
Repeat count [5]: 10000000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 192.168.254.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
途中省略
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!UUUUUUUUUUUU.............!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 99 percent (4735/4760), round-trip min/avg/max = 1/1/40 ms
R6c7206#

UはICMP Unreachableですが、恐らく自分で生成しています。 結果的に30秒ほど通信できない時間が発生しています。 R6-R1間、およびR1-R2間のネイバー状態が初期化されてしまうため、 OSPFはネイバーの確立から開始することになります。 これに時間がかかるのでしょう。

グレースフル・リスタートを使った場合

では次に、Graceful Restartを有効にしてみます。 Ciscoは12.2(15)T以降ならヘルパーモードを実行でき、設定は特に必要ありません。 Juniperは次の設定が必要です。

routing-options {
    graceful-restart {
        restart-duration 300;
    }
    router-id 192.168.254.1;
}

先ほどと同じく、R1でrestart routingコマンドを叩くと・・・
R6→R2のpingがまったく落ちません。

R6c7206#ping
Protocol [ip]:
Target IP address: 192.168.254.2
Repeat count [5]: 100000
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 100000, 100-byte ICMP Echos to 192.168.254.2, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
途中省略
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (10481/10481), round-trip min/avg/max = 1/1/40 ms
R6c7206#

効果絶大ですね。

つづく。

【OSPF】 1. Graceful OSPF Restartとは

1. Graceful OSPF Restartとは

グレースフル・リスタートと呼ばれる一連のプロトコル拡張の一つです。 グレースフル・リスタートを使うと、パケットロスなしでソフトウェアの再起動ができるようになります。 もちろん動かすには条件があります。

  • 制御プレーンが再起動してもパケット中継を続けられるルータであること
  • 周りのルータが協力してくれること

最初の条件は、Cisco社でいうとGSRやCRS-1、JuniperではM10i以上の機種でないとクリアできません。 2番目の条件はソフトウェアを新しくすればクリアできるでしょう。 CiscoではNSF(Non-Stop Forwarding)と呼んでますので、NSFを実装したIOSに入れ替える必要があります。

グレースフル・リスタートはプロトコルごとに規定され、OSPF, LDP, BGP辺りは既にRFCが発行されてます。 ここではOSPFのグレースフル・リスタートを試してみたいと思います。

OSPFのグレースフル・リスタートはRFC3623で規定されてます。 軽く日本語にしてみましたので、前提知識として読むとよいでしょう。

RFC3623の日本語版

グレースフル・リスタートするルータの動作手順

  1. grace-LSAを広告する。相手がLS ACKするまで再送してもいいが、再起動が遅くなるので、どっちでもよい。
  2. 再起動する前に、消えない場所にグレース期間中であることをメモっておく。その他の情報は忘れてよい。
  3. 周りのルータがヘルパーになってくれるか分からないが、とにかく再起動してみる。
  4. かつてのネイバー達と完全に同期が取れたら成功。かつてのネイバー達というのは、ルータLSAとネットワークLSAを見れば分かる。
  5. LSAの内容に一貫性がない、あるいはグレース期間が満了してしまうと、グレースフル・リスタートは失敗。
  6. グレースフル・リスタートを抜けると、grace-LSAをフラッシュ。LSAを再生成。経路を再計算してインストール。

ヘルパーモードの動作手順

  1. grace-LSAを受信する。
  2. そのルータと同期してるかチェック。再送リストにLSAが残ってないかチェック。
  3. グレース期間が短すぎて既に満了してないかチェック。
  4. 自分自身がグレースフル・リスタート中でないかチェック。
  5. 問題なければ、そのルータが生きているかのように振る舞う。

ヘルパーモードは次の条件で中止されます。

  • grace-LSAがフラッシュされた(グレースフル・リスタート成功)
  • grace-LSAで指定されたグレース期間が満了した。
  • リンクステートデータベースの内容が変化し、トポロジが変わったことが明らかになった。

つづく