IPv6-Trouble-Shooting-Mini

Size: px

Start display at page:

Download "IPv6-Trouble-Shooting-Mini"

あやかつつの
4 years ago
Views:

1 IPv6 トラブルシューティング株式会社ブロードバンドタワー國武功

2 Agenda IPv6 Troubleshooting! ipv6 nd ra suppress はやめよう! おまけで all なしコマンドの使い所は?- おまけ - アドレス採番についておまけ - PMTUD Blackhole にまつわる誤解もしくは懺悔おまけリンクローカルアドレスが付かない 2

3 ipv6 nd ra suppressの盲点あなたが書きたい設定は ipv6 nd ra suppress ではなく ipv6 nd ra suppress all ではないですか? 3

4 ipv6 nd ra suppress の盲点 ipv6 nd ra suppress all だよね? 4

5 ipv6 nd ra suppress の盲点 ipv6 nd ra suppress all というかこう書こうぜ! 5

6 ご清聴ありがとうございました! 以上で今話したいことはほぼ語り尽くしました! 以下蛇 6

7 なんで? all をつけなくても定期的な RA 送出は抑制されるので RA 抑制ができたように思えますしかしこの状態でも RS(Router Solicitation) パケットを受け取ると RA を返してしまいます (*1) よくある? のは Auto-configuration が On なノードがリンクを上げたタイミングで送出する RS パケットを受け取ってしまうケースいつも良質なマニュアルをありがとう! けどこの箇所は分かりづらい 7

8 定期的に送出される RA ( これはまる ) RS / RA の流れ Packet Router Advertisement Src mac 00:00:5e:00:53:ff Dest mac 33:33:00:00:00:01 Src IPv6 Dest IPv6 fe80::200:5eff:fe00:53ff ff02::1 Hoplimit 255 ICMPv6 Type 134 Prefix info 2001:db8:: All rights reserved. BroadBand Tower, Inc

RS への応答としての RA ( 抑制には ALL が必要 ) RS / RA の流れ Packet Src mac Dest mac Src IPv6 Dest IPv6 Router Solicitation 00:00:5e:00:53:01 33:33:00:00:00:02 (IPv6mcast_02) fe80::200:5eff:fe00:5301 ff02::2 Hoplimit

9 RS への応答としての RA ( 抑制には ALL が必要 ) RS / RA の流れ Packet Src mac Dest mac Src IPv6 Dest IPv6 Router Solicitation 00:00:5e:00:53:01 33:33:00:00:00:02 (IPv6mcast_02) fe80::200:5eff:fe00:5301 ff02::2 Hoplimit 255 ICMPv6 Type 133 Packet Src mac Dest mac Src IPv6 Dest IPv6 Router Advertisement 00:00:5e:00:53:ff 00:00:5e:00:53:01 fe80::200:5eff:fe00:53ff fe80::200:5eff:fe00:5301 Hoplimit 255 ICMPv6 Type 134 Prefix info 2001:db8:: All rights reserved. BroadBand Tower, Inc

10 ipv6 nd ra suppress の盲点従来の実装では RS は基本的に node が I/F を up した時にしか流れない (*1) のでこの RA でついたアドレスを利すると valid lifetime が過ぎたあとに通信ができなくなる危険性がある ( なにも設定変更していないと 30 後 (*2)) (*1) RFC7559 があるがこれは初期化時の RA のパケットロスを想定した仕様 (*2) default のパラメータは RFC4861 に従っている実装が多い 10

11 影響を受けるケースとある Linux の場合 1. RA を受け取る状態にしておく 2. RS に対する RA を受け取る 3. eui64 のアドレスがつく (2001:db8::a00:27ff:feb4:76) :db8::/64 な経路 (Prefix list に追加 ) が作られる 5. static で固定のアドレスを /64 で割り当てる (2001:db8::cafe/64) 6. default gateway として 2001:db8::/64 のアドレスを使って nexthop を指定 2019/7/26 All rights reserved. BroadBand Tower, Inc

12 影響を受けるケース (Cont) とある Linux の場合 ( 続き ) 7. その後 RA が流れない 8. valid lifetime 経過後 eui64 なアドレスが消える 9. static で割り当てたアドレスが残っていても prefix list から 2001:db8::/64 な経路が消える 10. 結果疎通性が無くなる (kernel の version によっては RA 受ける前に static 経路を書いておけば expires 付きの経路の登録を防げるケースも ) サーバ屋さんとネットワーク屋さんとの華麗な共演 ( 設定ミス ) による障害の発現 2019/7/26 All rights reserved. BroadBand Tower, Inc

13 ipv6 nd ra suppress の盲点 (Cont) RFC Prefix List - A list of the prefixes that define a set of addresses that are on-link. Prefix List entries are created from information received in Router Advertisements. Each entry has an associated invalidation timer value (extracted from the advertisement) used to expire prefixes when they become invalid. A special "infinity" timer value specifies that a prefix remains valid forever, unless a new (finite) value is received in a subsequent advertisement. 某にお聞きしたところ RA 以外で成された prefix は prefix list のエントリではない解釈をしている実装があれば影響を受けないかもとのこと 13

14 まとめ RA めたいなら細かいことは気にせず ipv6 nd ra suppress all と書いとけば OK! 14

15 おまけで all なしコマンドの使い所は?-

16 ipv6 nd ra suppress ってどこで使うの? ISATAP( もう使ってないよね?) ISATP では tunnel を通じて RA を流しますルータでは tunnel を通じて multicast パケットを流すのが難しいので RS にだけ答えるモードが求められていたそうです Wi-Fi の Gateway 無線ではなるべく flooding するようなパケットを抑制したいので RS にだけ答えるモードを使うという選択をするケースがあるようです ( これが本当に運に耐えるかどうかはユースケースに依存するでしょうけど ) 2019/7/26 All rights reserved. BroadBand Tower, Inc

17 おまけ - アドレス採番について -

18 Multicast address 2001:db8::dead:beaf このアドレス宛の NS は ff02::1:ffad:beaf が destination 2001:db8:aaad:beaf このアドレス宛の NS も ff02::1:ffad:beaf が destination たまたま同じ multicast group に join しているルータが分宛でないにも関わらず破棄せずまた同じセグメントに送り出しちゃうやつがいた ( もちろんバグ ) 18

19 教訓 IPv6 で多様されるマルチキャストパケット基本的には負荷低減ホスト側で関係ないパケットを簡単に捨てられるようにしている同じマルチキャストグループに属していることがあるということを意識していればトラブルシューティングの際に役につかも? $ ip maddress show dev eth1 3: eth1 link 01:00:5e:00:00:01 link 33:33:00:00:00:01 link 33:33:ff:d3:66:67 inet inet6 ff02::1:ffd3:6667 inet6 ff02::1 inet6 ff01::1 19

20 おまけ PMTUD Blackhole にまつわる誤解

23 ごめんちゃうねんたとえば Linux サーバでは DF ビットててパケット投げてるので IPv4 でもルータではフラグメントしません ip_no_pmtu_disc INTEGER Disable Path MTU Discovery. If enabled in mode 1 and a fragmentation-required ICMP is received, the PMTU to this destination will be set to min_pmtu (see below). You will need to raise min_pmtu to the smallest interface MTU on your system manually if you want to avoid locally generated fragments. default で 0 なので DF ビットてて送ります 1 なら PMTUD を disable にしますつまりフラグメント期待して DF ビットてません /7/26 All rights reserved. BroadBand Tower, Inc

25 おまけ link-local address がつかない!

こんなときに重複チェックに引っかかるかも前提 :RHEL7/CentOS7 系のお話 NetworkManager が ON IPV6INIT=yes

28 4 台から IPv6 での通信が 1 台 stable-privacy な link-local アドレスがつく 2 台 1 台と同じ stable-privacy な link-local アドレスが DAD failed 新しい stable-privacy なアドレスを成 link-local アドレスがつく 2019/7/26 All rights reserved. BroadBand Tower, Inc

29 4 台から IPv6 での通信が (Cont) 3 台 4 台 1 台と同じ stable-privacy な link-local アドレスが DAD failed 2 台と同じ stable-privacy な link-local アドレスが DAD failed 新しい stable-privacy なアドレスを成 link-local アドレスがつく 1 台と同じ stable-privacy な link-local アドレスが DAD failed 2 台と同じ stable-privacy な link-local アドレスが DAD failed 3 台と同じ stable-privacy な link-local アドレスが DAD failed stable-privacy なアドレス成を諦める NS が投げられなくて詰む 2019/7/26 All rights reserved. BroadBand Tower, Inc

スライド 1

スライド 1 忘れがちな IPv6 のアドレス構成 Matsuzaki maz Yoshinobu 1 IPv4 と IPv6 パケット転送などの考え方は同じつまり基本はほとんど一緒 IP ヘッダがちょっと違うアドレス長が伸びてる IPv4 32bit 長 IPv6 128bit 長 2 IPv4 パケット送信同じネットワークに属していれば直接送信 inet 192.168.0.1