2015年12月28日月曜日

IPv6ルーティングの初歩的な設定お試し

構成はこのように。

PC----L2----R1
   |---R2

IPv6の設定の前に、IPv6でのSSDPのマルチキャストが気になるが、ここで関わってしまうといつまで経っても先に進まないので保留。

既存の設定としてはvlan1に

ipv6 address autoconfig

のみ、ここから順次。

IPv6-R1(config)#ipv6 ?
  access-list        Configure access lists
  cef                Cisco Express Forwarding for IPv6
  cga                Configure IPv6 certified generated address
  dhcp               Configure IPv6 DHCP
  flowset            Set flow label random for originated packets
  general-prefix     Configure a general IPv6 prefix
  hop-limit          Configure hop count limit
  host               Configure static hostnames
  icmp               Configure ICMP parameters
  inspect            Context-based Access Control Engine
  local              Specify local options
  mfib               Multicast Forwarding
  mld                Global mld commands
  mobile             Mobile IPv6
  multicast          Configure multicast related commands
  multicast-routing  Enable IPv6 multicast
  nat                NAT-PT Configuration commands
  nd                 Configure IPv6 ND
  neighbor           Neighbor
  ospf               OSPF
  pim                Configure Protocol Independent Multicast
  port-map           Port to application mapping (PAM) configuration commands
  prefix-list        Build a prefix list
  radius             RADIUS configuration commands
  route              Configure static routes
  router             Enable an IPV6 routing process
  source-route       Process packets with source routing header options
  spd                Selective Packet Discard (SPD)
  tacacs             TACACS configuration commands
  traffic            Configure traffic parameters
  unicast-routing    Enable unicast routing

IPv6-R1(config)#

ここで

IPv6-R1(config)#ipv6 unicast-routing

を投入した後、


IPv6-R1#ping ipv6 ?
  WORD  Ping destination address or hostname
  <cr>

IPv6-R1#
IPv6-R1#ping ipv6 fe80::226:99ff:fec8:287c
Output Interface: vlan1
% IPv6 isn't enabled on this interface

なるほど、vlan1がupしてなかった。そらenabled なわけないわ。vlan1を上げて自アドレスにpingが通ったところで続いてL2を介してつながっているPCのリンクローカルアドレスにping
 
IPv6-R1#ping ipv6  fe80::ec3d:80d5:e7ea:9fa0
Output Interface: vlan1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::EC3D:80D5:E7EA:9FA0, timeout is 2 seconds:
Packet sent with a source address of FE80::226:99FF:FEC8:287C%Vlan1
.....
Success rate is 0 percent (0/5)

通らない。PC側では受信していて応答を返していないのでPC側の問題。これも掘り下げると進まないので、ルータ間で確認する。

R1とR2間のリンクローカルアドレス同士はPing OK。ルータ間についてdebugで見るとこの通り。

IPv6-R1#debug ipv6 icmp
  ICMP Packet debugging is on
IPv6-R1#
Pv6-R1#ping ipv6 fe80::2e54:2dff:fe99:b815
Output Interface: vlan 1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to FE80::2E54:2DFF:FE99:B815, timeout is 2 seconds:
Packet sent with a source address of FE80::226:99FF:FEC8:287C%Vlan1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/1/4 ms
IPv6-R1#
Dec 27 15:22:33.752: ICMPv6: Sent echo request, Src=FE80::226:99FF:FEC8:287C, Dst=FE80::2E54:2DFF:FE99:B815
Dec 27 15:22:33.752: ICMPv6: Received echo reply, Src=FE80::2E54:2DFF:FE99:B815, Dst=FE80::226:99FF:FEC8:287C
Dec 27 15:22:33.752: ICMPv6: Sent echo request, Src=FE80::226:99FF:FEC8:287C, Dst=FE80::2E54:2DFF:FE99:B815
Dec 27 15:22:33.752: ICMPv6: Received echo reply, Src=FE80::2E54:2DFF:FE99:B815, Dst=FE80::226:99FF:FEC8:287C
Dec 27 15:22:33.752: ICMPv6: Sent echo request, Src=FE80::226:99FF:FEC8:287C, Dst=FE80::2E54:2DFF:FE99:B815
Dec 27 15:22:33.756: ICMPv6: Received echo reply, Src=FE80::2E54:2DFF:FE99:B815, Dst=FE80::226:99FF:FEC8:287C
Dec 27 15:22:33.756: ICMPv6: Sent echo request, Src=FE80::226:99FF:FEC8:287C, Dst=FE80::2E54:2DFF:FE99:B815
Dec 27 15:22:33.756: ICMPv6: Received echo reply, Src=FE80::2E54:2DFF:FE99:B815, Dst=FE80::226:99FF:FEC8:287C
Dec 27 15:22:33.756: ICMPv6: Sent echo request, Src=FE80::226:99FF:FEC8:287C, Dst=FE80::2E54:2DFF:FE99:B815
Dec 27 15:22:33.760: ICMPv6: Received echo reply, Src=FE80::2E54:2DFF:FE99:B815, Dst=FE80::226:99FF:FEC8:287C
IPv6-R1#
Dec 27 15:22:38.824: ICMPv6: Received N-Solicit, Src=FE80::2E54:2DFF:FE99:B815, Dst=FE80::226:99FF:FEC8:287C
Dec 27 15:22:38.828: ICMPv6: Sent N-Advert, Src=FE80::226:99FF:FEC8:287C, Dst=FE80::2E54:2DFF:FE99:B815
IPv6-R1#
IPv6-R1#
IPv6-R1#
Dec 27 15:22:43.924: ICMPv6: Sent R-Advert, Src=FE80::226:99FF:FEC8:287C, Dst=FF02::1
IPv6-R1#

pingに前後してネイバーソォリィシット、ネイバーァエドヴァト、それから定期なルータぁえどヴぁっとも見られる。

リンクローカルアドレスとこのpingについてはCisco社のこちら。
http://www.cisco.com/cisco/web/support/JP/110/1109/1109812_ipv6-lla.html




続いて、具体的にIPv6アドレスの設定を。設定にあたってのアドレス設計だが、ULAを使う。

IETFから Unique Local IPv6 Unicast Addresses
https://tools.ietf.org/html/rfc4193


JPNIC ユニークローカルIPv6ユニキャストアドレス
https://www.nic.ad.jp/ja/newsletter/No32/090.html

具体的には、fc00::/8 でなく fd00::/8 から。下図ではfc00だが。また、ここでのグローバル識別子は仮に、10進で言うところの277。


 サブネット識別子は、テスト構成でいろいろやるのでIPv4の下16ビットにでも合わせるか。ま、そこはテキトーに。


ともあれ設定。

IPv6-R1(config-if)#ipv6 address ?
  WORD                General prefix name
  X:X:X:X::X          IPv6 link-local address
  X:X:X:X::X/<0-128>  IPv6 prefix
  autoconfig          Obtain address using autoconfiguration
  dhcp                Obtain a ipv6 address using dhcp

IPv6-R1(config-if)#ipv6 address FC00:0:115:1302:0:0:0:1/64

設定後のdebug ipv6 icmpの出力は

Dec 27 17:05:46.206: %SYS-5-CONFIG_I: Configured from console by console
Dec 27 17:05:55.434: ICMPv6: Received R-Advert, Src=FE80::2E54:2DFF:FE99:B815, Dst=FF02::1
Dec 27 17:07:02.707: ICMPv6: Sent R-Advert, Src=FE80::226:99FF:FEC8:287C, Dst=FF02::1
Dec 27 17:07:03.707: ICMPv6: Received N-Advert, Src=FC00:0:115:1302:2E54:2DFF:FE99:B815, Dst=FF02::1
Dec 27 17:07:03.835: ICMPv6: Received N-Advert, Src=FC00:0:115:1302:F8E4:95D1:C4DA:1759, Dst=FF02::1
Dec 27 17:08:50.129: ICMPv6: Received R-Advert, Src=FE80::2E54:2DFF:FE99:B815, Dst=FF02::1
Dec 27 17:10:19.878: ICMPv6: Sent R-Advert, Src=FE80::226:99FF:FEC8:287C, Dst=FF02::1


・・・やらかした。fd00を使うつもりがfc00で設定してる。これぞまさに誤3っぷり、愚かにも程がある。 いったん設定削除。

IPv6-R1(config-if)#no ipv6 address FC00:0:115:1302:0:0:0:1/64
IPv6-R1(config-if)#
Dec 27 17:17:20.170: ICMPv6: Sent type 254, Src=FE80::226:99FF:FEC8:287C, Dst=FF02::16
Dec 27 17:17:20.690: ICMPv6: Sent type 254, Src=FE80::226:99FF:FEC8:287C, Dst=FF02::16

ff02::16向けに更新をかけるようだ。マッタク意図していなかったが目にすることができて幸い。ここであらためて、

 ff02::16

とはなんぞや?であるのだが。IPv6なマルチキャストの末尾16ビットが 0x16、つまり
00000001 00000110。いやだから?

Google先生で検索をすると The Cisco Learning Network の CCIE Routing & Switching > Discussions から、

IPv6 address FF02::16 Significance
https://learningnetwork.cisco.com/thread/13865

このようなやりとりが。私程度ではそもそも、しぐにふぃけいす って何ですか?からなのだが。ほかにもほとんど解せない単語として、destinedbehaviormistique などが。そこを Weblioさんに頼りつつ何とか目を通してわかったことは。とりあえず FF02::16 とは All MLDv2-capable routers を指すということ。

IANA - IPv6 Multicast Address Space Registry
http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

タイプ254が何を示すのかも追いたいところだが CiscoのWebコンテンツでも触れないこともある ぐらいなのでとりあえず保留。


さて、設定すべきアドレスをfd00にあらためてみたところ今度は、

Dec 27 17:24:49.278: ICMPv6: Sent type 254, Src=FE80::226:99FF:FEC8:287C, Dst=FF02::16
Dec 27 17:24:49.282: ICMPv6: Sent N-Solicit, Src=::, Dst=FF02::1:FF00:1
Dec 27 17:24:50.198: ICMPv6: Sent type 254, Src=FE80::226:99FF:FEC8:287C, Dst=FF02::16
Dec 27 17:24:50.282: ICMPv6: Sent N-Advert, Src=FD00:0:115:1302::1, Dst=FF02::1

先のログでは保留してしまったがICMPv6タイプ253と254は、ネイバーディスカバリであるようだ。ここでWindows PC側を見てみると

   自動構成有効. . . . . . . . . . . . .: はい
   IPv6 アドレス . . . . . . . . . . . .: fc00:0:115:1302:ec3d:80d5:e7ea:9fa0(優先)
   IPv6 アドレス . . . . . . . . . . . .: fd00:0:115:1302:ec3d:80d5:e7ea:9fa0(優先)
   一時 IPv6 アドレス. . . . . . . . . .: fc00:0:115:1302:f8e4:95d1:c4da:1759(優先)
   一時 IPv6 アドレス. . . . . . . . . .: fd00:0:115:1302:f8e4:95d1:c4da:1759(優先)
   リンクローカル IPv6 アドレス. . . . .: fe80::ec3d:80d5:e7ea:9fa0%3(優先)
   IPv4 アドレス . . . . . . . . . . . .: 172.19.19.171(優先)
   サブネット マスク . . . . . . . . . .: 255.255.255.0
   デフォルト ゲートウェイ . . . . . . .: fe80::2e54:2dff:fe99:b815%3
                                          fe80::226:99ff:fec8:287c%3

ユニークローカルユニキャストアドレスが生成されている。それも、誤って設定したfc00と修正したfd00と両方。また、ルータ側のアドレスをfc00からfd00へ修正した後も、PC側のfc00アドレスはping的には有効。そうでなければipconfig /allに表示もされないだろうがなるほど。そして、IPv6のデフォゲはユニークローカルユニキャストアドレスになっていない点もなるほど、確かにでふぉげなのでリンクローカルアドレスで事足りそうではあるが。


ここで、ユニークローカルユニキャストアドレスの生成ルールがわからなくなった。これ以前にリンクローカルアドレスの生成は?と、ここでさらに、いまさらながら IPv4のリンクローカルアドレスが169.254.0.0/16であることを知る。どうにもわかっていない。ともあれ、

Windows8 ゼロ・コンフィギュレーション しくみ
https://technet.microsoft.com/ja-jp/library/bb726952.aspx

いろいろ探してみるものの、Windowsにおけるリンクローカルアドレス生成については不明なので、これは掘り下げない。とりあえず、EUI-64ではないしRFC4941でもないということで。

話をユニークローカルユニキャストアドレスの生成に戻して。

ルータにユニークローカルゆにきゃすとアドレスを設定したのち、PCにおいてアドレスを確認するとPC側でもユニークローカルユニキャストアドレスが生成されている。このとき、ルータ側の設定ではffc0に始まるアドレスとffd0に始まるそれを続けざまに設定削除再設定したわけだが、PC側には両方のアドレスがだぶって設定されている。

そして、これらのアドレスは、インターフェースID相当の64ビット分についてそっくり、PCのリンクローカルアドレス値がそのまま転写されている。また、当たり前といえばそれまでだがグローバル識別子40ビットと、サイト識別子16ビットはルータに設定した値そのままに。






















2015年12月25日金曜日

IPv6ルーティングの設定の前段


設定作業の前に動作状況。先日トラフィックを眺めたルータとはまた別の機器で。

PC----L2----R1
    |---R2

今回はR2のほう。R2の電源ON後に発生するトラフィックは

VLAN1のアドレスについてぐらちゅーたすあrp
OSPFハロー

(ここからねくすとへっだーフィールドぷろとこる番号58が登場)

ネイバーそりしていしょんを未指定(::)から自分のリンクローカルアドレス宛

SNTPサーバアドレスに対するARP要求

ルータそりてぃていしょんを未指定(::)からマルチキャスト全ルータへ

syslogサーバアドレスに対するARP要求
 <---応答

ねいばーアドバタイズメント 自分のリンクローカルアドレスからマルチキャスト全ノード宛て
 (ICMP136の中身はターゲット:自分のリンクローカルアドレス&リンクレイヤアドレス)

マルチキャストリスナーレポートめっせーじv2 自分のリンクローカルアドレスからマルチキャスト::16へ

ルータそりしていしょん 自分のリンクローカルアドレスからマルチキャスト全ルータ
 (ICMP133の中身は自分のリンクレイヤアドレス)

4秒後にふたたび
ルータそりしていしょん 自分のリンクローカルアドレスからマルチキャスト全ルータ
 (ICMP133の中身は自分のリンクレイヤアドレス)


余談: Catalystが約5秒おきにSVIなアドレスのぐらちゅーたすあrpを投げる仕様のようだが、そんなだったか。

ともあれ設定。これまではインターフェースにautoconfigでアドレスをふっただけなのでルーティングテーブルはこんな状態。

R2#show ipv6 route
IPv6 Routing Table - default - 1 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, HA - Home Agent, MR - Mobile Router, R - RIP
       D - EIGRP, EX - EIGRP external, NM - NEMO, ND - Neighbor Discovery
       l - LISP
       O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
L   FF00::/8 [0/0]
     via Null0, receive
R2#


それから、下手に手を出す前に Ciscoの公式なコンフィギュレーションガイドを。

IPv6 アドレッシングと基本接続の実装
http://www.cisco.com/cisco/web/support/JP/docs/CIAN/IOS/IOS15_1M_T/CG/011/ip6-addrg_bsc_con.html?bid=0900e4b182530486

そういえばいつからv6対応だったのか?と思えば、12.0S、12. x T、12.2S ファミリ、12.3、12.4、15.0、および 15.1 のリリース トレインとのこと。機能とサポート状況の表を眺めると何とも項目の数が多いこと。

さておき、ここにIPv6の通信の初歩的な部分について再び。

---引用ここから---

IPv6 ネイバー ディスカバリ

IPv6 ネイバー ディスカバリ プロセスでは、ICMP メッセージおよび請求ノード マルチキャスト アドレスを使用して、同じネットワーク(ローカル リンク)上のネイバーのリンクレイヤ アドレスを判断し、ネイバーに到達可能かどうかを確認し、ネイバー ルータを追跡します。

ネイバー ディスカバリ機能の IPv6 スタティック キャッシュ エントリにより、IPv6 ネイバー キャッシュ内にスタティック エントリを作成できます。スタティック ルーティングでは、管理者が、各ルータの各インターフェイスの IPv6 アドレス、サブネット マスク、ゲートウェイ、および対応する MAC アドレスをテーブルに入力する必要があります。スタティック ルーティングによって、より詳細な制御が可能になりますが、テーブルの保守作業が増えます。ルートが追加または変更されるたびにテーブルを更新する必要があります。


---引用ひとまずここまで---

先生のところでは全く出てこなかったが "ネイバーでぃすかばりプロセス" なる概念がIPv6にはあるようだ。


---引用ここから---


ネイバー アドバタイズメント メッセージは、ローカル リンク上のノードのリンクレイヤ アドレスが変更されたときにも送信されます。このような変更がある場合、ネイバー アドバタイズメントの宛先アドレスは全ノード マルチキャスト アドレスです。

ネイバー請求メッセージは、ネイバーのリンクレイヤ アドレスが識別されたあとに、ネイバーの到達可能性の確認にも使用されます。ネイバー到達不能検出では、ネイバーの障害またはネイバーへの転送パスの障害が識別されます。この検出は、ホストとネイバー ノード(ホストまたはルータ)間のすべてのパスで使用されます。ネイバー到達不能検出は、ユニキャスト パケットだけが送信されるネイバーに対して実行され、マルチキャスト パケットが送信されるネイバーに対しては実行されません。


---引用ここまで---

ネイバーソリシテイションとアドバタイズメントは

・素性確認
・死活確認
・自分の素性が変わったら更新のお知らせ

少なくとも3つの機能があると。


---引用ここから---

ネイバーから返信された請求ネイバー アドバタイズメント メッセージは、転送パスがまだ機能しているという肯定確認応答です(請求フラグが値 1 に設定されたネイバー アドバタイズメント メッセージは、ネイバー請求メッセージへの返信としてだけ送信されます)。非請求メッセージでは、送信元ノードから宛先ノードへの一方向パスだけが確認されます。請求ネイバー アドバタイズメント メッセージは、両方向のパスが機能していることを示します。

(注) 請求フラグが値 0 に設定されたネイバー アドバタイズメント メッセージは、転送パスがまだ機能していることを示す肯定確認応答とは見なされません。


---引用ここまで---

ICMPメッセージ中に32ビットの"Flags"が在り、この先頭から3ビットが、


1ビット目が ルータ
2ビット目が ソリシテッド
3ビット目が オーバーライド

そして4-32ビットはレザーブドとなっている。Ciscoのドキュメント中の「請求フラグ」とはおそらくこれのようだ。ネイバーソリティテイション中にこのフラグスは無く、アドバタイズメンにだけ在る。ルータアドバタイズメントではフラグスの項目がまた全く異なる。


1ビット目 マネージドアドレスコンフィギュレーション
2同上 アザーコンフィギュレーション
3 ホームエージェント
4-5 PRF(デフォルトルータぷリファレンス)
6 プロキシ
7 リザーブド

8ビット目は未使用か?


これに続いて16ビットで ルータライフタイム (この例では1800秒だった)
32ビットで リーチャブルタイム (ここでは0ミリ秒だった)
やはり32ビットで リトランスタイマー (0ミリ秒)


となっている。次に、技術としてもっとずっと初期段階な内容のこの記述


--- 引用ここから ---

ネイバー請求メッセージは、ユニキャスト IPv6 アドレスがインターフェイスに割り当てられる前にそのアドレスが一意であることを確認するために、ステートレス自動設定プロセスでも使用されます。新規のリンクローカル IPv6 アドレスに対しては、アドレスがインターフェイスに割り当てられる前に、最初に重複アドレス検出が実行されます(重複アドレス検出の実行中、新規アドレスは一時的な状態のままです)。具体的には、ノードは未指定の送信元アドレスと一時的なリンクローカル アドレスをメッセージの本文に含むネイバー請求メッセージを送信します。そのアドレスが別のノードですでに使用されている場合、ノードは一時的なリンクローカル アドレスを含むネイバー アドバタイズメント メッセージを返します。別のノードが同じアドレスの一意性を同時に検証している場合は、そのノードもネイバー請求メッセージを返します。ネイバー請求メッセージの返信としてネイバー アドバタイズメント メッセージが受信されず、同じ一時アドレスの検証を試行している他のノードからのネイバー請求メッセージも受信されない場合、最初のネイバー請求メッセージを送信したノードは、一時的なリンクローカル アドレスを一意であると見なし、そのアドレスをインターフェイスに割り当てます。

リンク上のすべての IPv6 ユニキャスト アドレス(グローバルまたはリンクローカル)が一意であることを検証する必要がありますが、リンクローカル アドレスの一意性が確認されるまでは、リンクローカル アドレスに関連付けられている他の IPv6 アドレスに対して重複アドレス検出は実行されません。Cisco IOS ソフトウェアでの重複アドレス検出のシスコ実装では、64 ビット インターフェイス識別子から生成されるエニーキャスト アドレスまたはグローバル アドレスの一意性は確認されません。



--- 引用ここまで ---

Neighbor の solicitation と Advertisement のごく基本的な動作について極めて初歩的な説明である。文書の性質上少々冗長な感はあるがたいへんすっきりした内容だ。

はて!? 私がIPv6のおべんきょうに取り掛かってからずいぶん経っているような気がするが、なぜ今頃になってこの記述を読んでいるのだろうか???つまり、そもそも学ぶべき対象は正しく選択しなければならないということ。



続いてルータアドバタイズメントについて。引用はきりがないので箇条書きで。

・タイプフィールド値134
・定期的に送信
・ステートレスを正常に稼働させるためにプリフィクスは/64
・全ノードマルチキャスト
・自動設定のためのプリフィクス情報とこのライフタイムを含む
・ステートレス/ステートフルいずれかを指定するフラグ
・デフォルトルータにかかる情報
・ホストがつかうべきホップリミットやMTU
・アドバタイズメントは要請(タイプ133)に対する応答としても使用
・ホストはデフォでシステムスタート時に要請を出す
 この時のソースは未指定(::)


ルータの設定にたどり着くまでもうちょっとかかりそうだ。


IPv6の当面の運用

運用といっても、座学における運用(as contrasted to practical operating)であって、実際の運用のことではなく。

イージス先生の解説なさっているところでは、

・デュアルスタック
・トランスレータ
  プロキシ
  NAT-PT(プロトコル変換を伴うNAT)
  TCPリレー
・トンネリング

先生の説明の中には、NAT-PTについてDNS-ALGと併用、とあるのだが、誤3程度ではDNS-ALGって初耳です!?!という体たらくなので。

しようがないので、Juniperのこちら。
http://www.juniper.net/techpubs/en_US/junos12.1x46/topics/concept/security-alg-dns-overview.html

SRXあたりだとこんな設定になるようで。
http://www.juniper.net/techpubs/en_US/junos12.1x46/topics/example/security-alg-dns-configuring.html


と思ったら先生のコンテンツの末尾に

CiscoルータではNAT-PTの使用は推奨されていません。今後はNAT64を使用することを推奨しています。

・・・左様でございますか、というオチ。

NAT64についてはこちら。もう4年前のコンテンツだがアットマークアイティさんから、A10ネットワークスのエンジニアさんの記事。

NAT64でIPv6端末をIPv4サーバにつなげよう
http://www.atmarkit.co.jp/fnetwork/rensai/transfer03/01.html



トンネリング周りについては、当面保留・・・としたいところだが放り出すのも気持ち悪いので少しだけ。


< トンネリングの区分 >

手動トンネリング
 手動 tunnel mode ipv6ip
 GRE tunnel mode gre ip

自動トンネリング
 6to4 tunnel mode ipv6ip 6to4
 ISATAP tunnel mode ipv6ip isatap
 Teredo IPv4のUDPでカプセル化・・・ルータきゃんどぅえにてぃんぐ



-- 手動・手動 --

v4でカプセリングをルータ間で行う
・トンネルインターフェースの設定
・v6アドレスをふる
・(いーじす先生のところではなぜかripらしき設定1行)
・ トンネルソースとトンネルでいすてぃねいしょんの設定
tunnel mode ipv6ip


 -- 手動・GRE --

先生は非推奨のようなのでこちらで。

Cisco IOS Interface Configuration Guide, Release 12.2 - Configuring Logical Interfaces
http://www.cisco.com/c/en/us/td/docs/ios/12_2/interface/configuration/guide/finter_c/icflogin.html#wp1031768




-- 6to4 --

カプセル化したv4のルーティングが自動であること以外、何が手動の静的隧道と違うのか?という印象。しかも、2002::/16のユニキャストの中に、v4のグローバルIPアドレスをあらかじめアドレスとして組み込むという、この方式が作られた背景をお察しすることが少々困難。というのは誤3blogの無知っぷりがそもそも尋常でないからだが。


-- ISATAP --

あいさたっぷは、IんとらSいと・Aーとまちっく・Tんねりんぐ・Aどれっしんぐ・Pろとこる。隧道のためのアドレス割り当てを自動化な・内部ネット向けのプロトコル。アイサタップほすと<--->アイサタップるーた間のトンネルでIPv4接続の後にルータ側でアドレッシングの主導権をとるものの、ホスト側にイチイチ・・・という解釈がはたしてどれだけ的を射ていないことやら。

 ISATAPホストからアドレス要請--->ISATAPルータが通知

グローバルルーティングプレフィクス
 +インターフェースID(ISATAPあいでんてぃふぁいぁ32bit+IPv4アドレス32bit)

また、あいさたぷ identifier は固定値で0000:5EFEとのこと。


出たての頃らしきTechnetの記事はこちら。
https://technet.microsoft.com/ja-jp/magazine/2008.03.cableguy.aspx

Windowsにおける設定(削除についても)はこのあたりで。

Internet Protocol Version 6, Teredo, and Related Technologies in Windows Vista
https://technet.microsoft.com/ja-jp/library/cc722030%28WS.10%29.aspx




-- Teredo --

ISATAPもえーかげん古いがこれも2009年当時には既にひろく露出しているようで。ここ誤3な浦島太郎ぶりもさらに露呈、というか恥の上塗りというもの。

ともあれまずJPNICによる概説
https://www.nic.ad.jp/ja/basics/terms/teredo.html

last resortだそうで。座学としてはいっそ無視べきかもしれないが、現実の一面である以上は相応の背景がある。誤3がもしも「アタシのスキルでキャリアアップでナルシスト自意識過剰ドヤブス」であれば、見向きもしないかもしれない。

Windowsにおける実装はVISTAからであるようで、これについてはこちら。


日経BP - 日経NETWORK テレード Teredoとは
http://itpro.nikkeibp.co.jp/article/Keyword/20090407/327951/

日経BPの解説画像
http://itpro.nikkeibp.co.jp/article/Keyword/20090407/327951/?SS=imgview&FD=60191400

読み切れないがこれも
https://en.wikipedia.org/wiki/Teredo_tunneling




IPv6アドレスをautoconfigしただけのルータのIPv6関連トラフィクの観察

PC----L2----ルータ

PCはWindowsでIPv6は有効にしただけで何もせず、パケットは条鮫でキャプチャ。ルータはVLAN1にIPv6アドレスを設定したのみ、それもautoconfig、ほかは何もせず。IPv6ユニキャストルーティングさえ手をつけていない。

で、L2とPCを先に上げておき、ルータの電源をONにしてIPv6のトラフィックがあがってくる様子を見ると、


Multicast Listner Report Message v2 ::-->ff02:16 ICMP143 exclude:ff02:2
Multicast Listner Report Message v2 ::-->ff02:16 ICMP143 exclude:ff02::1:FF下位24ビット
# 全ルータ宛てと自ルータの要請ノードマルチキャスト宛て

Nieghbor Solicitation ::-->ff02::1:FF下位24ビット ICMP135 Target:ff02::1:FF下位24ビット
# ネイバーソリシテイションを自ルータの要請ノードマルチキャスト宛て
# 自分宛てなので応答があるはずもなく重複確認かもしくは他の何らかの目的か

Multicast Listner Report Message v2 ::-->ff02:16 ICMP143 exclude:ff02:2
Multicast Listner Report Message v2 ::-->ff02:16 ICMP143 exclude:ff02::1:FF下位24ビット
# 再びマルチキャストリスナーレポートが全ルータと自分の養成ノードマルチキャスト宛て

Multicast Listner Report Message v2 自ルータのリンクローカルアドレス-->ff02:16 ICMP143 exclude:ff02:2
Multicast Listner Report Message v2 自ルータのリンクローカルアドレス-->ff02:16 ICMP143 exclude:ff02::1:FF下位24ビット
# 3回目にしてソースがリンクローカルアドレス(fe80::上位24ビットの7ビット目反転FF下位24ビット)に変わる


Nieghbor Advertisement 自リンクローカルアドレス-->ff02:1 ICMP136 Target:ff02::1:FF下位24ビット Target:ルータMACアドレス
Router Advertisement 自リンクローカルアドレス-->ff02:1 ICMP134 Router Lifetime(1800)+MACアドレス+MTU
# ネイバーアドバタイズメントとルータアドバタイズメント

Neighbor Solicitation "PCの"リンクローカルアドレスから-->ルータの要請ノードアドレス ICMP135 ソースMAC
Neighboor Advertisement ルータのリンクローカルアドレス-->PCのリンクローカルアドレス
# この時点で、PCはアドレス自動取得になっているだけでルータに対して何も設定していない。
# また直前にルータは全ノード宛てのネイバーアドバタイズメントを出しているので、PCはルータのリンクローカルアドレスを知っているはず。
# しかし、PCが発したトラフィックはネイバーソリシテイションであって宛先はルータの要請ノードマルチキャスト
# さらに全く同じやりとりが2回、まだまだ基礎知識が足りず意味がわからない。

Router Solicitation ルータのリンクローカルアドレス-->ff02::2 ICMP133 中身はルータのMACアドレスのみ
# ここまでルータとしてはネイバー要請、ネイバー広告、ルータ広告、ルータ要請の順番で実施。
# あて先はノード向けマルチキャストだが、ルータ要請は当然ルータ向けマルチキャスト。

Multicast Listner Report Message v2 ルータのリンクローカルアドレス-->ff02:16 ICMP143  exclude:ff02::1:FF下位24ビット


以後も続くが、今の段階では追うだけの前提が全く備わっていない。




2015年12月24日木曜日

RAによるグローバルユニキャストアドレス付与の経過

ICMPを用いたハードウェアアドレス解決方法、Neighbor Solicitation (ICMPタイプ135)を送って相手からNeighbor Advertisement (ICMPタイプ136)が返答されるあんなこんなやり取りとちょっと似ているかもだが。

順序立ててひも解くと、

ノードA: 

 オレ IPv6でグローバルユニキャストなアドレスやゲートウェイ必要!

 だから、Router Solicitation (じゃっぷ的にはるーた要請)送っちまうぜ!

 あて先はRAなルータ、不特定のルータだからマルチキャストでFE02::2さ!
 宛先MACは知らねーから、??すぉりしてっどノードマルチキャストアドレス??
 オレの リンクローカルアドレスはFE80::8988:88FE:FE88:8888、
 オレのMACアドレスは88:88:88:88:88:88。

  133ルーターそぉりしてぃしょんめっせーじ行けやー!


ノードB=RAなルータ:
 
 何や、ICMP133 ルーターすぉりしていしょんめっせーじ来たで!?

 134 ルーターあどばたいずめんと返さんとならんやないかメンドイわー。

 で、誰や相手は。IPv6アドレスがリンクローカルやな
 FE80::8988:88FE:FE88:8888
 んでもってMACアドレスは
 88:88:88:88:88:88
 かいな、わいのMACアドレスは
 22:22:22:22:22:22
 やで。ほれ、134ルーターあどばたいずめんと送るで、
 プリフィクス、げーとうぇい、それから有効期限や!!



ノードA: 

 おー、RAなルータはノードBさんやったんか!
 ぷりふぃくすありがとー、これでグローバルユニキャスト生成であとウハウハやねん!


ちゅーハナシと思ってんねんけど、ホンマかどうか知らんてゆうか、あからさまにアヤシイ以前にもかなりアヤシかったネタのコピペ。


で、誤認識どころか間抜け想像なネタはおいといて、リアルはどうなっているかというと


WinなPC ------ L2 -------- RAなルータ


と、そういえばL2のSPANポートな設定どうなっていたっけ!? 単純にWinなPCのトラフィックをモニタしよう段で、PCやルータをモニタする設定していたらワケがわからなくなる。


monitor session 1 source interface Fa0/7
monitor session 1 destination interface Fa0/1

って、設定入れたまんまだし。ここは接続ポートを変更して開始。まず、WinなPCとL2間のみ生きている状態でWindows8.1のDHCPv6リクエストパケット
これでWindows上の設定はどうなっているか。ipconfig /all からv6絡みを抜粋すると

 イーサネット アダプター イーサネット:

   DHCP 有効 . . . . . . . . . . . . . .: いいえ
   自動構成有効. . . . . . . . . . . . .: はい
   リンクローカル IPv6 アドレス. . . . .: fe80::ec3d:80d5:e7ea:9fa0%3(優先)
   DHCPv6 IAID . . . . . . . . . . . . .: 53765289
   DHCPv6 クライアント DUID. . . . . . .: 00-01-00-01-1D-A8-71-DE-34-64-A9-CE-39-95
   DNS サーバー. . . . . . . . . . . . .: fec0:0:0:ffff::1%1
                                          fec0:0:0:ffff::2%1
                                          fec0:0:0:ffff::3%1


IAIDと、DUIDってナニ?とここでも躓く、誤3blogの程度のすさまじい低さ。

IAID (Identity Association ID)についてはアットマークアイティさんのこちら。

Windows管理者のためのIPv6入門:
第5回 IPv6アドレスをDHCPで割り当てる
http://www.atmarkit.co.jp/ait/articles/1303/14/news095_2.html


DUIDについてCiscoさんのIPv6コンフィギュレーションガイドから、引用を一部。

DHCP for IPv6 の実装 ~ クライアントとサーバの識別

各 DHCPv6 クライアントとサーバは、DHCP Unique Identifier(DUID; DHCP 固有識別子)によって識別されます。DUID は、クライアント識別子およびサーバ識別子オプションで伝送されます。DUID はすべての DHCP クライアントとサーバで一意であり、特定のクライアントまたはサーバに固定されます。DHCPv6 では、クライアントとサーバの両方の識別子にリンク層アドレスに基づく DUID を使用します。デバイスは、最も小さい番号のインターフェイスの MAC アドレスを使用して DUID を形成します。ネットワーク インターフェイスは、デバイスに永続的に接続されていると見なされます。

IPv6 DHCP クライアントが 2 つのプレフィクスを要求し、そのプレフィクスの DUID が同じで IAID が 2 つの異なるインターフェイス上で異なる場合、これらのプレフィクスは 2 つの異なるクライアント用と見なされ、両方のインターフェイス情報が保持されます。

引用ここまで。詳しくはこちら。
http://www.cisco.com/cisco/web/support/JP/docs/CIAN/IOS/IOS15_1S/CG/009/ip6-dhcp.html?bid=0900e4b1825ae751


つまるところ、冒頭のただでさえしょぼい芸人ごっこは、根本的に劣悪なものということで。



さて、WindowsとL2の間を確認したところで、VLANにIPv6アドレスをautoconfigで設定しただけのルータをブートさせる。すると、

・自VLANアドレス宛のぐらちゅーたすARP
・OSPF Hello

に続いて

a. IPv6アドレスオールゼロからFE02::16宛のマルチキャストリスナーリポートv2
b. IPv6アドレスオールゼロからFE02::16宛のマルチキャストリスナーリポートv2
c. IPv6アドレスオールゼロからFE02::1:FF下位24ビット宛のネイバーソリシテーション


が見られた。aとbはソースも宛先も同じだが、ICMP 143 マルチキャストリスナレポートV2メッセージ中の

 Multicast Address change to exclude:

の値が異なる。前者はすべてのルータ、後者はこのルータのソシィリエいテッドノードアドレス。どうやら、すべてのルータおよび自身の要請ノードマルチキャストアドレスをソースとするマルチキャストは除外ですよ、と通告しているようだ。この動作は



ヤマハ アドバンストネットワーク > IPマルチキャストについて > IPマルチキャスト概要 
http://jp.yamaha.com/products/network/solution/multicast/outline/

アラクサラ MLDの動作
https://www.alaxala.com/jp/techinfo/archive/manual/AX7800R/HTML/10_10_/APGUIDE/0398.HTM


Multicast Listener Discovery によるところ、IPv4ならIGMPに相当する機能によるものであるようだ。が、個人的には何しろIPv4でマルチキャストの設計運用に関わったことがない、ちゅー以前に傲慢不勉強だったので全く知らなかった。バカ過ぎて痛い。が、傲慢もバカも痛がらずにジブン放置し続けるよりはずいぶんマシか。片っ端から手をつけるほかないわ。



以降を追うのは時間を要するので次回。






2015年12月23日水曜日

ルータ広告とは

前々エントリの宿題。

RA (Router Advertisement; ルータ広告)とは
https://www.nic.ad.jp/ja/basics/terms/ra.html


RA=IPv6アドレスの自動設定を行う機能

Stateless Address Autoconfiguration

=SLAACの一部分。



どのノードにどのアドレスを割り当てているか管理アリorナシ---> ステートフル or レス


RAのごくごくごくカンタンなしくみ

・IPv6のアドレスがほしいノードがルータを探すため
 マルチキャスト問い合わせ (FF02::2)
・RAに対応したルータが問い合わせに対してマルチキャスト応答(FF02::1)
・ノードは応答からプリフィクスを得て自分でアドレスを生成


で、イージス先生のIPv6についてのご指導・解説
http://www.infraexpert.com/study/study35.html

から、Neighbor Discovery


続いてping。まずWindows側、ここでひとつ疑問となったのが既定のDNSサーバアドレス。ipconfig /all のDNS サーバー. . . . . . . . . . . . .: な部分で

fec0:0:0:ffff::1%1
fec0:0:0:ffff::2%1
fec0:0:0:ffff::3%1

でふぉ、でした。

MDSNから IPv6 構成項目
https://msdn.microsoft.com/ja-jp/library/cc783049%28v=ws.10%29.aspx

そしてここに、

> DNS サーバーが IPv6 クライアントとは異なるサブネット上にある場合は、DNS サーバーのサブネット上で利用可能な任意の IPv6 ルーターに、DNS サーバーへの静的ルートを構成します。

とのこと。脱線ついでにMicrosoftの世界における名前解決がIPv6でどうなったかについてアットマークアイティさんから

第6回 LLMNRを使ったローカル・セグメント上での名前解決
http://www.atmarkit.co.jp/ait/articles/1305/23/news107.html


話を戻して、Cisco的なIPv6のping。

# ping ipv6 宛先IPv6アドレス

IPv4で言うところの show arp に近いものとしては

# show ipv6 neighbors

まだ、fe80なリンクローカルアドレスしかテストできてないが。続いてCiscoルータにおけるIPv6アドレスの設定が3通り、

あ) IPv6-Router(config-if)#ipv6 address 2001:1234:5678:9abc::1/64

い) IPv6-Router(config-if)#ipv6 address 2001:1234:5678:9abc::/64 eui-64

う) IPv6-Router(config-if)#ipv6 address autoconfig


autoconifgについては、イージス先生の開設によれば default オプションをつけるとRAによりデフォルトルートが設定されるとのことだった。が、私が一度試す限りでは、defaultオプションをつけなくても・・・?別途要確認。

それから、eui-64のアドレス生成を再確認、


0226:99FF:FE+下24ビット
0026.99+下24ビット

で、7ビット目がしっかり反転と。次いでホストのアドレッシングな概念。まず、 そもそもRAとDHCPv6の併用が事実上必須であるというのが実情のようだ。

お勉強的なパターンとしては、


・全手動


・RAによる自動(ホスト・プレフィクス・GW)+DNSほか手動


・RAによる自動(RFC6106によってDNSまで自動化*)


 RFC6106によるDNSの自動設定の概要は yuyarinの日記 さんのこちらから

  RFC 6106: IPv6 Router Advertisement Options for DNS Configuration
  http://d.hatena.ne.jp/yuyarin/20101130/1291126339

 野良猫=ジコチュー廃棄猫ならぬ、野良RAが問題とは…なるほど。


・RAでホスト/プリフィクス/GW+DHCPでDNSほか

 じっけんのためにCentOSでDHCPv6の設定をやらんとならんか・・・正直面倒。


・DHCPv6でステートフル・・・GWを配布できないので運用に難


アドレス割り当てについてはこちら様も。

 Windows管理者のためのIPv6入門:
 第5回 IPv6アドレスをDHCPで割り当てる
 http://www.atmarkit.co.jp/ait/articles/1303/14/news095.html




2015年12月22日火曜日

RAの前にWindows ファイアウォール

ping ipv6がテストPC向けに通らないのでさては、と思ったらやはり。


再びIPv6ヘッダ

アットマークアイティの15年前のWebコンテンツ
IPv6ネットワークへの招待(3): IPv6のヘッダフォーマット
http://www.atmarkit.co.jp/ait/articles/0110/05/news002.html


実際のパケットを見るとこのような。













これをビットで見ると










ソース/ディスティネーションアドレスは手抜き。

拡張ヘッダについては、私のこの時点ではまだ言及する程度でない。それから、イージス先生のNA向けコンテンツでは、IPSecの標準サポートとモバイルIPについての記述がある。


続いてIPv6 ICMPヘッダ。

 ICMPv6のメッセージについてはこちらなど。
https://ja.wikipedia.org/wiki/Internet_Control_Message_Protocol_for_IPv6


ICMPを用いたハードウェアアドレス解決方法について

・Neighbor Solicitation (ICMPタイプ135)を送って相手から
   Neighbor Advertisement (ICMPタイプ136)が返ってくる

概要はこんだけ。もうちょっと順序立ててひも解くと、

ノードA: 

 オレ ナニナニサーバに通信始めたい!
 ナニナニのIPv6グローバルユニキャスト(またはエニィャスト)は
 2001:0db8:0000:0001 : 0000:0000:7777:7777

 でもナニナニのMACアドレスがわからない!

 だからNeighbor Solicitationメッセージ送る!

 宛先IPv6アドレスは すぉりしてっどノードマルチキャストアドレスだから
 FF02:0000:0000:0000 : 0000:0001:FF77:7777
 ジブンのアドレスは
 2001:0db8:0000:0009 : 0000:0000:9999:9999

 宛先MACアドレスはわからんからソリシテッド端末マルチキャストから当て込んで
 33:33:FF:77:77:77
 そんで、ジブンのMACアドレスは
 88:88:88:88:88:88

 135ねいばーそぉりしてぃしょんめっせーじ行けやー!


ノードB=ナニナニサーバ

 何や、135ねいばーすぉりしていしょんめっせーじ来たで!?
 末尾24ビットワイのNICに合うとるやないか、ワイ宛かい!
 136ねいばーあどばたいずめんと返さんとならんやないかメンドイわー。

 で、誰や相手は。IPv6アドレスが
 2001:0db8:0000:0009 : 0000:0000:9999:9999
 んでもってMACアドレスは
 88:88:88:88:88:88
 かいな、わいのMACアドレスは
 22:22:22:22:22:22
 やで。ほれ、136ねいばーあどばたいずめんと送るで!

ちゅーハナシやねんと思ってんねんけど、ホンマかどうか知らんねん。


ARPもとい、ねいばーそりしてぃていしょんとこの応答あどばたいずめんとの確認方法は、

# show ipv6 neighbors

出力は、

IPv6 Address
Age
Link-layer Addr
State
Interface

以上。


次に、RAなるものが突然出てくるわけだがこれは、JPNICのこちらで要予習。

RA (Router Advertisement; ルータ広告)とは
https://www.nic.ad.jp/ja/basics/terms/ra.html












IPv6えにぃきゃすと

何のことやらさっぱりだったが、イージス先生のご説明を拝読して、理解するための断片のきっかけをいただいた。

と、このような言い方をするのは、当方の理解が浅はかすぎるから先生のコンテンツを拝読してもこのきっかけ程度にしかならないという意味なのでくれぐれも誤解なきよう。

さて。

冗長構成と負荷分散に使えることを教えていただいたものの、IPv6のルーティングメトリックによるというシステムがどれほど有用か。浅はか誤3blog程度ではサッパリ。同じ目的のシステムをそんなに散らかって置くものだろうか?ISPのような規模にもなれば置くか。ま、これも私の無知ゆえ、ペンディングでとりあえず次。


IEEEの定める64ビットの識別子
http://itpro.nikkeibp.co.jp/free/v6start/word_v6/20020325/1/

ずいぶん昔に読んだ記憶があるがカンゼンに忘れてた。

上位24ビットが Organizationally Unique Identifier = かんぱにーID
下位40ビットが extension identifier

7ビット目が特殊 universal/localの識別ビット ゼロでユニバーサル
8ビット目も特殊 マルチキャストか否か

EUI-48を上位下位各24ビットに2分して間にFEFE(1111111011111110)を挟むと、EUI-64に変換できるとのこと。EUI-48においても7ビット目と8ビット目は特殊だった、ということか。

そしてEUI-64からIPv6ユニキャストアドレスのインターフェースIDを生成するには、EUI-64の7ビット目を反転させる、ということのようだ。EUI-64では0がユニバーサルだが、IPv6のインターフェースIDでは1がユニークを示すようだ。実際に設定してみると、

IPv6-Router(config-if)#ipv6 address ?
  WORD                General prefix name
  X:X:X:X::X          IPv6 link-local address
  X:X:X:X::X/<0-128>  IPv6 prefix
  autoconfig          Obtain address using autoconfiguration
  dhcp                Obtain a ipv6 address using dhcp

IPv6-Router(config-if)#ipv6 address autoconfig ?
  default  Insert default route
  <cr>

IPv6-Router(config-if)#ipv6 address autoconfig
IPv6-Router(config-if)#end
IPv6-Router#
IPv6-Router#
IPv6-Router#
IPv6-Router#show ipv6 int
Vlan1 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::2E54:2DFF:FE下位24ビット
  No Virtual link-local address(es):
  Stateless address autoconfig enabled
  No global unicast address is configured
  Joined group address(es):
    FF02::1
    FF02::2
    FF02::1:FF下位24ビット
  MTU is 1500 bytes
  ICMP error messages limited to one every 100 milliseconds
  ICMP redirects are enabled
  ICMP unreachables are sent
  Input features: Common Flow Table Stile classification
  Output features: Common Flow Table Stile Classification
  ND DAD is enabled, number of DAD attempts: 1
  ND reachable time is 30000 milliseconds (using 30000)
  ND advertised reachable time is 0 (unspecified)
  ND advertised retransmit interval is 0 (unspecified)
  ND router advertisements are sent every 200 seconds
  ND router advertisements live for 1800 seconds
  ND advertised default router preference is Medium
  Hosts use stateless autoconfig for addresses.
IPv6-Router#

元の上位24ビットは2C54:2D、設定後は2E54:2Dになっている。あたま8ビットだけ抜粋すると 00101100 --> 00101110 ということでなるほど。


次に、特殊なアドレス。

1. ループバック ::1 と非常にシンプル
2. オールゼロ=未指定アドレス :: で表記
  IPアドレス取得時のソースに使ったりするらしいが、追って確認。

3. IPv4互換アドレス 96ビットがゼロ+IPv4アドレス
4. IPV4射影アドレス 80ビットがゼロ+16ビットが1+IPv4アドレス

互換アドレスは廃止とのこと。



何とか、IPv6に目がついていくようになったきた。先はまだまだ長いが。
















IPv6 マルチキャストのMACアドレスとアドレス解決機能

そもそも、IPv4のマルチキャストのMACアドレスがどのようになっているかさえ知らんかったという、"blogタイトルである誤算"にさえなってないバカっぷり、をこの冒頭でお断りしておきます。


IPv4のマルチキャストにおけるMACアドレスについては、アラクサラのこちら。
https://www.alaxala.com/jp/techinfo/archive/manual/AX5400S/HTML/10_10_/APGUIDE/0136.HTM


IPv6のマルチキャストにおけるMACアドレス48ビットのうち、先頭16ビットは33:33で固定。残り32ビットは、レイヤ3のアドレスをそのまま転用。


で、IPv4で言うところのARPに相当するところについて Microsoft Technet のコンテンツから一部引用。


Solicited-node address

The solicited-node address facilitates efficient querying of network nodes during address resolution.

In IPv4, the ARP Request frame is sent to the MAC-level broadcast, disturbing all nodes on the network segment, including those that are not running IPv4.

IPv6 uses the Neighbor Solicitation message to perform address resolution. However, instead of using the local-link scope all-nodes address as the Neighbor Solicitation message destination, which would disturb all IPv6 nodes on the local link, the solicited-node multicast address is used.

The solicited-node multicast address consists of the prefix FF02::1:FF00:0/104 and the last 24-bits of the IPv6 address that is being resolved.

For example, for the node with the link-local IPv6 address of FE80::2AA:FF:FE28:9C5A, the corresponding solicited-node address is FF02::1:FF28:9C5A.

To resolve the FE80::2AA:FF:FE28:9C5A address to its link layer address, a node sends a Neighbor Solicitation message to the solicited-node address of FF02::1:FF28:9C5A.

The node that is using the address of FE80::2AA:FF:FE28:9C5A is listening for multicast traffic at the solicited-node address and, for interfaces that correspond to a physical network adapter, has registered the corresponding multicast address with the network adapter.

The result of using the solicited-node multicast address is that address resolution, which commonly occurs on a link, is not required to use a mechanism that disturbs all network nodes.

In fact, very few nodes are disturbed during address resolution.

In practice, because of the relationship between the Ethernet MAC address, the IPv6 interface ID, and the solicited-node address, the solicited-node address acts as a pseudo-unicast address for very efficient address resolution.

(引用ここまで)


うん、ナメくさって読めるかと思ったがダメだった。MACアドレス-->IPv6ユニキャストアドレス-->solicitedノードなマルチキャストアドレス、ざっくりな仕組みしか察することができない。efficeiencyがいまいち、いや、かなりわからない。イージス先生のところでも

・IPv6においてIPv6ディスティネーションのMACアドレスを解決する場合
 ICMP135:ねいばー要請メッセージを要請のーどマルチキャスト宛で送る。

という把握はできるが、えにーキャストから要請ノードマルチキャストを生成する意味がわからない。DNSに対してARP要求とと考えればわかるが、そもそもDNSが同じセグメントにいるなんてことがあるのか? これ以前にネイバーディスカバリの概念が前段に無い。

どうにも、門前の小僧になるための修業が不足と。ま、先へ進んでまたやり直して、を繰り返すしかない。


とりあえず先。先生のところでIE R&S向けとしてはいるが、


インターフェースローカルの1 オールノーズ(ノードローカル)
リンクローカルの1 オールノーズ(リンクローカル)

インターフェースローカルの2 オールルーターズ(ノードローカル)
リンクローカルの2 オールルーターズ(リンクローカル)

リンクローカルの5 全OSPFv3ルータ、なるほどIPv6だからOSPFv3か。
リンクローカルの6 全OSPFv3 DR/BDR

リンクローカルの9 全RIPng、そういやRIPのIPv6版はRIPngだった。
リンクローカルのA EIGRPルーターズ

そして

リンクローカルのB モバイル エージェンツ
リンクローカルのC DHCPサーバーズ/リレー/DHCPエージェンツ
リンクローカルのD PIMルーターズ

まー、なるほど。
















2015年12月21日月曜日

IPv6の様々なアドレス種別のビット

IPv6の学び始めにタコの塩もみもとい、自分の発想のでぃべいとほっとりい

ま、とにかく試行錯誤。

グローバルユニキャストインターネット
2001::~2001:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
プリフィクスは/16、先頭をビットであらわすとこうか。




グローバルユニキャスト6to4用
2002::~2002:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
プリフィクスは/16。 


グローバルユニキャスト未割り当て
2003::~3FFD:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
プリフィクスはやはり/16で

末尾をビット表記するとこうか。


おそらくあるいはホント腕(かいな)。


ISP割り当て範囲について、グローバルルーティングプレフィクス(48ビット)サブネットID(16ビット)、インターフェースID(64ビット)について。


実際にISPがどんな割り当てをしているか存じ上げないが、あるいはグローバル1コもらうとサブネットを65536、サブネット毎にホストをドえらい数が使える、ということ?

ともあれグローバルユニキャストはここまで、次にサイトローカルアドレス…はとうにRFCで廃止が明記されたとのことなのでいっそ無視で、


次にリンクローカルアドレス。





 先頭10ビットが固定、54ビットが任意?64ビットがインターフェースID。であればたぶんアドレス範囲は、

 FE80:0:0:0:インターフェースID ~ FEBF:FFFF:FFFF:FFFF:インターフェースID

ということ、ではないか?と迷走中。



迷走ではない、イージス先生のまとめから引用させていただくと。

・エニーキャストアドレスにはユニキャストアドレスを用いる
・一意のエニーキャストアドレスは複数の機器やNICで用いる
・ひとつの機器やNICに対して複数のアドレスを割り当てる(必要時)
 たとえばリンクローカルアドレスとグロバールユニキャストの両方を割り当てる



次にマルチキャスト。














基本がこの構造。アタマ8ビットは固定なのでFF、次の4ビットがフラグを意味しアイアナ指定か否かで0または1、さらに次の4ビットがスコープ指定でこちらは4ビット全部使って意味するところがイロイロだが主なところは1,2,4,8,Eか。
 
残り112ビットは無視して先頭16ビットが次の場合

FF01 (0001)・・・インターフェースローカル(自分宛てにまるちきゃすと?)
FF02 (0010)・・・リンクローカル(同一せぐめんと内?)
FF04 (0100)・・・管理ローカル

FF08 (1000)・・・組織ローカル
FF0E (1110)・・・グローバル

あと、5(0101)はサイトローカルだが。ビットの立ち方をちょっと見出せない。


次に、イージス先生によると、Cisco機器でIPv6を有効にした際にデフォで参加するマルチキャストは、リンクローカルでの末尾4ビット

末尾1 同じリンク上の全ノード
末尾2 同じリンク上の全ルータ

この2つともうひとつ、要請ノードマルチキャストアドレスが FF02::1:FF00:0 から。わっかり難いのでビット表を、


 すぉりしてっどな範囲は、FF02::1:FF00:0 から FF01::1:FFFF:FFFFまで、であるようだ。

すぉりしと
http://ejje.weblio.jp/content/solicit


さらによく使われそうなところとして、

同じリンク上の全OSPFルータが当然リンクローカルな FF02::5
同じリンク上の全でじぐねOSPFルータ(DR/BDR)が FF02::6
同じリンク上の全RIPルータが えふえふぜろいーWコロンの9
同上NTPサーバが 同101
サイトローカル上のNTPサーバがFF05::101


とのこと。


とりあえず目には慣れてきた。アタマの中ではまだまだ全く慣れないが。


2015年12月20日日曜日

IPv6のアドレス表記と省略に慣れる

IPv6のヘッダの話は少々保留にして、とりあえずIPv6に見慣れる、手慣れる、アタマを慣らす。

慣れの問題、ただそれだけ。それだけだが慣れていないうちはシンドイ。鈍りきった筋肉を回復させるのと同じ。128ビットを8区分、1区分あたり16ビットを16進数表記=4ビット単位なので必然的に16進数*4桁*8区分、となるわけだが反射的には出てこない。

そしてイージス先生によれば、大文字小文字の区別はない。それから省略の作法は

1. 区分毎に上の桁が0である場合は表記しない

2. 1区分まるまるゼロである場合は単に0

3. ゼロの区分(前項2.のケース)が連続する場合は
  Wコロン…整いましたねづっちです!ではなくて「コロン記号2つ」で省略
  このときゼロの区分が複数続いてもコロン2つに省略
  であるので、全体を眺めて区分数が8未満の場合は
  コロン2つでいくつ省略されているか考えなくてはならない。

4. コロン2つで省略できる部分が2か所ある場合は上の桁のほうで省略するようだ


プレフィクスと集約の概念はIPv4と同じだが見慣れない、計算に慣れてないというかまだ練習してない。64ビットはサブネットプレフィクスで64ビットはインターフェース識別子/ Modified EUI-64(ふぉーまっと)に基づく。



・ユニマルチエニー問題

 まるちキャスト

 えにーキャスト

multiとanyの単語の意味からすればその通りなのだが、えにきゃすとを何にどう使うかがピンと来ない。そしてマルチキャストがブロードキャストに代わるという点も、実際にトラフィックを見てみないとピンと来ない。



 ・スコープ問題

リンクなローカル・・・るーてィンgされない

サイトなローカル・・・IPv4でいうところのプライベートのはずだったが廃止とか

グローバル



さて、かなりふざけたこのblogをアテにする人はゼロ以下マイナスだとは承知しつつ、IPv6は自分で何を書いているかさえマッタクわからない錯綜ぶりなので、イージス先生以外にもいくつか引用を。


JPNIC インターネット10分講座:IPv6アドレス~技術解説~
https://www.nic.ad.jp/ja/newsletter/No32/090.html

このWebコンテンツが掲載されてからかれこれ10年なんですね・・・。


アットマークアイティ Windows管理者のためのIPv6入門:
http://www.atmarkit.co.jp/ait/articles/1109/22/news115_2.html



とりあえずチョー入門ないくつかの点についてのみ抜粋整理すると、


2000::/3  グローバル・ユニキャストアドレス(GUA)
fc00::/7 ユニーク・ローカル・ユニキャストアドレス(ULA)
fe80::/10 リンクローカル・ユニキャストアドレス
ff00::/8 マルチキャスト・アドレス

プレフィックスのならびは3,7,10,8で、順ににせんGUA/3、エフシーと言ってもサッカーでなくてゼロゼロULA/7、ふぇハチマルスラテン、ふふれれ8がマルチキャスト。

で、門前の小僧状態では必然的に目にするアドレスがリンクローカルユニキャストになるわけだが、これを手元のWindows PCで確認・・・IPv6外してあるし、チェックを入れてみてみると、リンクローカルIPv6が

 fe80::884:290e:3f57:1454%3(優先)

パーセンテージ記号はスコープを示すらしい。

プロンプト記号 ping アドレス
プロンプト記号 ping -6 ホスト名

名前解決には、Link-local Multicast Name Resolution りんくろーかる・まるちきゃすと・ねーむりぞりゅーしょん、LLMNRが使われるとのこと。


ここでいったん休憩。










2015年12月19日土曜日

坂本・いのっち・岡田・長野・三宅・森田 以上

いのっちはたしか井ノ原?自信はあまりないがIPv6はそれこそ全く自信がない。というか、これまでろくに学ぼうとさえしなかったので自信などあるわけがない。


教科書的な特徴

・ルーティングが高速

…あとなんだっけ。いーじす先生によれば

・自動設定機能
・階層構造が厳密で経路集約が効率的
・ヘッダがシンプルであるためルーティング処理の負荷が軽い
・モバイルIPv6により移動中でも同一IPを保持可能
・IPv6はIPSecの実装がmustでありIPv6サポート=IPSec使用可能

…自分何も知らんやインタニスト


ここで脱線。

2進数表記で32ビットは
10進数表記で0-255の4区分で
これが16進数表記の場合だと16*16=256なので2桁の4区分表記でおさまる

16進1桁=4ビット、こんな当たり前のことがぱっと出てこないことに自嘲せざるをえない。

IPv6の前にIPv4のヘッダ例


ヘッダ書き覚えのためのワークシート
https://drive.google.com/file/d/0BxydDz6vccykZFBjNXdzNkgyT2s/view?usp=sharing_eid&ts=56743377


IPv6のヘッダは次回。












2015年12月18日金曜日

OSPF けんばじぇんす後

OSPFにおける障害情報の伝わり方

・インタゥふぇいすがダウンしたOSPFルータが224.0.0.6でLSUを発送

・DRとBDRが受信するがDRだけが224.0.0.5でLSUを発送
 このときBDRは6宛てLSUを受信してからWaitタイマーを回しはじめ
 DRが5宛てを発送するまで待機
 
・時を同じくしてOSPFをしゃべる別セグメントにもLSUを発送
 このとき当該ルータが別せぐにおいてDROTHERなら224.0.0.6で発送


のだめとマキちゃんほどではないが不思議な友人関係…もといOSPF隣接関係。



・DROTHER同士は2wayでねいばー止まり
・相手がDRまたはBDRの場合はFullであぁだじぇじぇ、言えてねぇ。はい、アダジャセンシ。

前者はブロードキャストマルチアクセスでないと起こりえない。後者はどんなつながり方でも起こりうる、ようだ。OSPFのつながりかたは概念的に3つあって、ブロードキャストマルチアクセス(BMA)、ポイントツーポイント、ブロードキャストじゃないマルチアクセス(NBMA)だが今となってはいみなっしん!? 先生によれば IEを目指すなら必須とのことだが。これらの違いについてコマンドの上において、

 ip ospf network なんちゃら

の一行のみであるようだ。

ip ospf network non-broadcast
ねいばーを手動で設定しなくてはならず。Helloのでふぉが30秒。

ip ospf network broadcast
特に意識することもない。

ip ospf network point-to-point
ip ospf network point-to-multipoint
DR/BDR選出が無い。そして後者の場合はhelloが30秒毎とのこと。

ip ospf network point-to-multipoint nonbroadcast
のんぶろーどきゃすとなのでネイバーは手動設定。そしてぽいんとつーぽいんとなマルチキャストなのでHelloは30秒と。


要素は単純だが、何のケースにおいてどれを使うかが誤3ブログな低レベルではなんとも。


設定についてさらに。

・エリアID
有線鮫でキャプチャした中身では、IPアドレスのようにドット区切りで見ることができる。コマンド上の0はおそらく0.0.0.0に相当するようで、見かけの数字マイナス1がドット区切り表示になっている。

・ワイルドカードマスク
イージス先生の解説によって、自分の認識が根本的に違っていたことに気付いた。まさかこんな謎設定だったとは。

・ループバック0
この数値が設定できることを知らなかった。

・show ip protocols のマキシマムパス:4
マキシマムパス自体の意味を認識したことがなかった。でふぉは4と。

・ 参照帯域幅は100mbps
 分子

・show ip protocols に OSPFネイバが出てこないから何かと思ったら立ち上げるべきL2機材を間違えていた。

OSPF-Router#show ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
172.19.19.2       1   2WAY/DROTHER    00:00:38    172.19.19.2     Vlan1
OSPF-Router#show ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
172.19.19.2       1   2WAY/DROTHER    00:00:37    172.19.19.2     Vlan1
OSPF-Router#show ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
172.19.19.2       1   FULL/BDR        00:00:39    172.19.19.2     Vlan1
OSPF-Router#show ip ospf nei

Neighbor ID     Pri   State           Dead Time   Address         Interface
172.19.19.2       1   FULL/BDR        00:00:39    172.19.19.2     Vlan1
OSPF-Router#

インターフェースがアップしてからもちょっとだけ時間はかかる。運用上の留意点。


・show  ip ospf
OSPF 全般の情報
スタートタイマの意味を知らない情けなさ。イラァぷdは


・show ip ospf interface
インターフェース毎、特定インターフェースを指定することも可。

これら2つのコマンドの活用は、誤3にとってはちょっと先のハナシ。


・show ip ospf neighbor
アドレス指定可能。デッドタイマーについて追って要確認。


・show ip ospf database
ルータIDとプロセス番号
ルータリンクステータス:リンクID、アドバタイズ元のルータ、エイジ、
シーケンスNo. チェックサム、リンクカウント。
ネットリンクステータス:同上 (リンクカウントを除く)

OSPF-Router#show ip ospf database ?
  adv-router        Advertising Router link states
  asbr-summary      ASBR summary link states
  database-summary  Summary of database
  external          External link states
  internal          Internal LSA information
  multicast         Multicast Topology
  network           Network link states
  nssa-external     NSSA External link states
  opaque-area       Opaque Area link states
  opaque-as         Opaque AS link states
  opaque-link       Opaque Link-Local link states
  router            Router link states
  self-originate    Self-originated link states
  summary           Network summary link states
  topology          Unicast Topology
  |                 Output modifiers
  <cr>

OSPF-Router#


・でばっぐは、events/packets/adjecency

















2015年12月16日水曜日

OSPFにおけるリンクステートリクエストとアップデートあたり

 --------R254-------------------R2--------

なルータ2台間の、相互のあいさつ ~ 力関係の明確化 ~ 情報交換 な過程のお作法のお稽古。

・R254が誰もいないのにOSPFハローをまるちきゃすとな孤独状態
・R2が通電して目をさます
・事務所の言いなりだったタレントが目を覚ました拍子に正気に戻る
・正気に戻ってマジで出ていこうとするので事務所逆ギレ
 ~うちのタレントが洗脳されたネガキャン開始/タレントを潰しにかかる

…ではなくて、

・R2が通電して目をさます
・R2がふつうにOPSFハローパケットをまるちきゃすと <--この時点を時間軸0秒として
・R254がR2のはろーはお構いなしに10秒毎の定期はろー

・R2が定期Helloの8秒後に、R254宛のユニキャストでDB ですくりぷしょん発送
・ほぼ同時にR254宛のユニキャストなはろーを発送

・間髪おかずにR254がR2向けにユニキャストでDBでぃすくりぷしょ

・さらに間髪おかずにR2がR254向けにユニキャストでDBでィ(略

 ただしここで OSPF DBD内の主従ビットがゼロ=セットされなくなる
 そしてここからLSAヘッダがつく

・また間髪おかずにR254からR2向けにユニキャストDBデ
 主従ビットは1
 LSAヘッダつき

・またまた100分の1秒以下で
 今度はR2からR254宛にリンクステートリクエスト
 LS-Type は タイプワン Router-LSA
・さらにR2は1万分の1秒以下の間隔で
 R254向けにDBディスクリプション
 この中身は以前のDBDと変わったようには見受けられないが
 きっと私が気づいていないだけ

・するとR254がR2宛にLSアップデート
 LS-Type は タイプ1 Router-LSA
 ・さらにR254は10万分の1秒以下の間隔で
 R254宛にリンクステートリクエスト


・続いて100分の1秒以下でR2がR254向けにリンクステートアップデート

・ここからコンマ5秒後に
 R2から224.0.0.5まるちきゃすとなリンクステートアップデート

・R2のマルチキャストなLS Updateから100分の4秒後に
 R254から224.0.0.5宛ののLS Update

 ・この約1秒後にR2から224.0.0.5にHelloがあるも10秒毎の定時ごあいさつのような

・さらに約1秒後にR2から224.0.0.5宛にLS Ack。
・直後にR254から224.0.0.5宛にLS Ack。

 ここまで、R2が起きだして最初のHelloを投げてからほぼ10秒。 これ以降は定時Helloが淡々と。




読みなおすと



R254 <---ユニキャストDBD R2(主)
R254(主) ユニキャストDBD---> R2
R254 <---ユニキャストDBD+LSA R2(従)
R254(主) ユニキャストDBD---> R2
R254 <---ユニキャストLSR R2(従)
R254 <---ユニキャストDBD R2(従)
R254(主) ユニキャストLSU---> R2
R254(主) ユニキャストLSR---> R2R
254 <---ユニキャストLSU R2(従)

コンマ5秒ほど経って

R2のマルチキャストLSU
R254のマルチキャストLSU

さらに2秒ほど過ぎて

R2のマルチキャストLS ACK
R254のマルチキャスト ACK


で、これらの意味を次のエントリで。

無論、「意味」などとは言ったところで技術的に掘り下げることが到底ムリであるのは、ゲロケバいモデルが「てっちゃん…」と嘆くぐらいムリだが。

ムリは無理でも、発掘ならぬ箒をかける程度にはあらためてみたい。


2015年12月15日火曜日

OSPF adjecencyなやりとりの断片

あーだじぇんせしぃな関係が始まる直前のごあいさつ

















これが、ルータが起動して最初のOSPFパケット。ここで「最初」というのは、次の接続状況下において
 
 --------R254-------------------R2--------

 R254という名のOSPFルータが先に立ち上がった状態で、R2の電源を入れて最初に見られるOPSFのパケット、ということ。

ここで OSPF LLSデータブロックとはハテサテ?なわけだが、よりによって誤3blogごときが言及するのは無礼千万どころではないので、詳しいことはこちらで。

 RFC 5613 - OSPF Link-Local Signaling - IETF Tools
 https://tools.ietf.org/html/rfc5613


さておき、2台のうち後から立ち上がってきた方は、OSPF Helloの中で

LR: LSDB Resynchronization (LR-bit)is SET

を相手に送ってるぞと。LR-bitは以前もどこかで見かけていて、LR/左右ってなんだろう!? ぐらいにしか認識してなかったが、あまりにも認識力が弱すぎて泣ける。

ともかく、このHello中の つながり状況情報倉庫再同期なビットは、これ以前のR254ルータのHelloでも同じだし、これ以降のR254ルータでもR2ルータでも同じ。


次に行こう。

R2からR254に向けて、DB ですくりぷしょんメッセージが飛ぶ。
 どうもこの段階で、どちらが主人でどちらが従者かを決めるためのやりとりを始めた?そして同時に、224.0.0.5でなくユニキャストなHelloが一発。
 すると直後に、R254ルータから でーびーDescriptionなパケットが。


 おそらくたぶん、これも主従関係を決めようじゃないか手続き、のように見えるのだが。次に続くパケットは、

 今度はR2から、DBデスクりぷしょん内のMaster/Slaveビットが立ってないパケットが、LSAヘッダ付きで。この中身はというと、


 Router-LSAな内容らしい。もちろん、サッパリわかっちゃいないので、ここでパケット追っかけを一時中断。


で、先生のところの説明&イラストを読んでみると、どうもこのテスト環境で起こっていることとビミョーに違うような!?

これがまた、3 or 30分な先生のところでも、この部分について言及していない。となればも致し方ない。


7.2 The Synchronization of Databases

In an SPF-based routing algorithm, it is very important for all routers' topological databases to stay synchronized.
OSPF simplifies this by requiring only adjacent routers to remain synchronized.
The synchronization process begins as soon as the routers attempt to bring up the adjacency.

Each router describes its database by sending a sequence of Database Description packets to its neighbor.

Each Database Description Packet describes a set of link state advertisements belonging to the database.

When the neighbor sees a link state advertisement that is more recent than its own database copy, it makes a note that this newer advertisement should be requested.

ここまではまだ、パケットの中身については触れていないようで。


This sending and receiving of Database Description packets is called the "Database Exchange Process".

DB ですくりぷしょんのやり取りは、データベースえくすちぇいんじぷろせす、な段階らしい。
 
During this process, the two routers form a master/slave relationship. Each Database Description Packet has a sequence number. Database Description Packets sent by the master (polls) are acknowledged by the slave through echoing of the sequence number.

Both polls and their responses contain summaries of link state data.

The master is the only one allowed to retransmit Database Description Packets.
It does so only at fixed intervals, the length of which is the configured constant RxmtInterval.


Each Database Description contains an indication that there are more packets to follow --- the M-bit. The Database Exchange Process is over when a router has received and sent Database Description Packets with the M-bit off.

MビットがオフでDBデすくりぷしょんプロセス終了、とな。

During and after the Database Exchange Process, each router has a list of those link state advertisements for which the neighbor has more up-to-date instances.  These advertisements are requested in Link State Request Packets.  Link State Request packets that are not satisfied are retransmitted at fixed intervals of time RxmtInterval.  When the Database Description Process has completed and all Link State Requests have been satisfied, the databases are deemed synchronized and the routers are marked fully adjacent.  At this time the adjacency is fully functional and is advertised in the two routers' link state advertisements.

The adjacency is used by the flooding procedure as soon as the Database Exchange Process begins.  This simplifies database synchronization, and guarantees that it finishes in a predictable period of time.

ここには、ウチでの今回の?に関する部分の記述がございませんでしたねというオチ。


ま、とりあえず先に進んでみよう。後から、マイドのごとくジブンの誤3に気づくかも。























2015年12月14日月曜日

OSPF序二段

前置き:

blogエントリのタイトルこそ序二段などと書いてはいるものの、脂肪と既得権益のカタマリな相撲ビジネスは全く支持しないことをここに。

ただ、いくら相撲を支持しないとはいっても、相撲以下に既得権益傲慢のさらに世襲で日本文化の代表的ナー気取り歌舞伎ビジネス、ほどではない。

また、歌舞伎利権ビジネスもさることながら、歌舞伎をありがたがってしまうBBA連中の短絡信仰は、きゃりーぱみゅぱみゅカワイーなDQN女と大差なく。

前置きここまで。


OSPFの続き。先生によるパケットフォーマット解説を、ここのテスト環境のパケットにあてはめると、

(次に前回も引用したパケットの中身)

OSPF Hello Packet

 Network Mask: 255.255.255.0 (255.255.255.0) 
   <---Helloを発送しているインターフェースのマスク

 Hello Interval [sec]: 10
   <---見たまんま

 Options: 0x12 (L, E)
  0... .... = DN: Not set
  .0.. .... = o: Not set
  ..0. .... = DC: Demand Circuits are NOT supported
  ...1 .... = L: The packet contains LLS data block
  .... 0... = NP: NSSA is NOT supported
  .... .0.. = MC: NOT Multicast Capable
  .... ..1. = E: External Routing Capability
  .... ...0 = MT: NO Multi-Topology Routing

   <---先生によれば「Op8つのうちスタブを意味する…」とのことだが、今の私はまだ理解できず。徐々に読み解くしかない。

 Router Priority: 1
   <---DR/BDRの選出に使う。DR/BDRにしないルータはこれをゼロにしなくてはならない。

 Router Dead Interval: 172.19.19.254 (172.19.19.254)
   <---手習い写しのミス、つまり誤記。正しくは以下、

 Router Dead Interval(sec): 40
    <---Hello間隔の4倍。


 Designated Router: 172.19.19.2 (172.19.19.254)
 Backup Designated Router: 172.19.19.2 (172.19.19.2)
 Active Neighbor: 172.19.19.2(172.19.19.2)
   <---見たまんま。



ご近所さんとお付き合いが始まる過程について

・伏してる状態
・初期状態
・双方向状態

すてーたすは3つ。これらの推移はHelloパケットがどのように行き交っているか(まだ行き交っていないか)ということ。

・起きたばっかりは当然Down
・起きて挨拶を言ったが返事がない状態もまだDown
・誰かから挨拶をされればそこでInit
・自分が挨拶を送った相手から挨拶が返ってくれば2way



 ウチのルータIDをどうやって決めるか!?

・そもそもルータID設定してもらったけ?
 --->設定してもらってたら、そのまんまルータID。

・ルータIDを設定してもらってなければ、ループバック。
・ループバックが複数あればいちばんデカいループバック。
・ループバックがなければ アクティブな インターフェースで最もデカいやつ。

途中でループバックが追加になったり、よりでかいインターフェースがupしても、OSPFのプロセスがリセットされなければルータIDは変わらず。

# clear ip ospf process


で、つながっている相手とあいさつを交わしたら(2wayステート)、Helloの中身によって

 「序列を決めようじゃないか、犬のようにな。」(医龍国立笙一郎ふう)

・・・ではなくて、必然的にDR/BDR/DROTHERが決まる。で、この後にあーじゃせんしのステップ。なお、個人的に発音をイメージするときは、a-djencen-cy な感じだが、これが世間さまで通じるかどうかは定かでない。


次にあぁじゃせんしぃな関係に至るまでの詳細。まず、Exstart。ホントかどうかわからんが、覚えるなら

 Exchange の start

挨拶行き来で2wayになって犬序列でDRかBDRかその他大勢かが決まってから

 LSA の Exchange の start

この時に主導権があるのはDRから。もしDR以外が主導権を握るなら、私はいったい何のために医龍・国立笙一郎を引用したか!? というものだが。


ここで、OSPFルータ間のパケットを全部キャプチャするために、すいっちどぽーとあならいざ、略してスパムもといSPANの設定


SPAN-Switch#conf t
SPAN-Switch(config)#monitor session 1 source interface fastethernet 0/7
SPAN-Switch(config)#monitor session 1 destination interface fastethernet 0/1
SPAN-Switch(config)#end
SPAN-Switch#
SPAN-Switch#show monitor session 1
Session 1
---------
Type              : Local Session
Source Ports      :
    Both          : Fa0/7
Destination Ports : Fa0/1
    Encapsulation : Native
          Ingress : Disabled


SPAN-Switch#

 * 機種によってゼンゼンお作法が違うので、ツド検索。


SPNA-SwitchにとあるOSPFをしゃべるルータをつないで電源をONすると

・とあるルータの設定状況においてはCDPを約1秒毎に9発
 (厳密には見ていないが中身は同じっぽい/OPSFと離れるので今回は無視)

・ディスティネーションが自インターフェースなぐらちゅーたすARPを一発
・syslogサーバのARPを一発
・OSPF Hellloの一発目
・9発目のCDPから約18秒後にCDPの続き

とりあえずそんな動きから。で、OPSF仲間とのadjecencyなやりとりはざっくりとこんな感じ。


続きはすーん。




















OSPFなエントリ序の口

OSPFの話の前に、起動時にdebugを走らせる方法。しかしJapan TACのサポート外。
https://supportforums.cisco.com/ja/document/103001


ともあれOSPF、エリア概説のあたりから。

・LSAはふらッでぃんぐされるもの。

・ふらッでぃんぐは、ある程度の範囲に制限されなくてはならない。
 (そんなん規模次第)

・だからエリアの概念

・ネットわーく情報をダダ漏れにするのではなく集約するからこそエリア(ABR/ASBR)

・ちっちゃくするもの3つ
 1. りんくすてーとでーたべーす(LSDB)
 2. しょーてすとぱすふぁすと計算頻度
 3. ルーティングテーブルサイズ

CPU使用率やメモリ使用率についての言及があってごもっともではあるが、根本はやはり2.。ちゅーか、キャリアじゃあるまいし、そうそうルーティングに影響与えるような変更は "起こらないように最初から" 設計する。もちろん、仕事にありがちなのは既にメチャクチャな設計を後からどうにかする、だが。

・ご推奨はエリア0バックボーン&各エリアは/24&ABRで/16集約


・OSPFはろー

OSPFヘッダ以下の中身はこんな。

OSPF Header
 Version: 2
 Message Type: Hello Packet (1)
 Packet Length: 48
 Source OSPF Router: 192.168.235.169 (192.168.235.169)
 Area ID: 0.0.1.21 (0.0.1.21)
 Checksum: 0x00f6 [correct]
 Auth Type: Null (0)
 Auth Data (none): 0000000000000000

OSPF Hello Packet
 Network Mask: 255.255.255.0 (255.255.255.0)
 Hello Interval [sec]: 10
 Options: 0x12 (L, E)
  0... .... = DN: Not set
  .0.. .... = o: Not set
  ..0. .... = DC: Demand Circuits are NOT supported
  ...1 .... = L: The packet contains LLS data block
  .... 0... = NP: NSSA is NOT supported
  .... .0.. = MC: NOT Multicast Capable
  .... ..1. = E: External Routing Capability
  .... ...0 = MT: NO Multi-Topology Routing
 Router Priority: 1
 Router Dead Interval: 172.19.19.254 (172.19.19.254)
 Backup Designated Router: 172.19.19.2 (172.19.19.2)
 Active Neighbor: 172.19.19.2(172.19.19.2)

OSPF LLS Data Block
 Checsum: xfff6
 LLS Data Length: 12 bytes
 Extended options TLV
  Type: 1
  Length: 4
  Options: 0x00000000 (LR)
    .... .... .... .... .... .... .... ..0. = RS: Restart Signal (RS-bit) is NOT set
    .... .... .... .... .... .... .... ...1 = LR: LSTB Resynchronization  (LR-bit) is SET



OSPFが稼働しているルータ(172.19.19.2)に新たに1台OPSFルータ(172.19.19.254)があがってくるとこのように。タイプ4アップデートと、タイプ5アックナレッジがとぶ。


No.     Time           Source                Destination           Protocol Length Info
    125 118.799626000  172.19.19.2           224.0.0.5             OSPF     94     Hello Packet

Frame 125: 94 bytes on wire (752 bits), 94 bytes captured (752 bits) on interface 0
Ethernet II, Src: CiscoInc_c8:28:7c (00:26:99:c8:28:7c), Dst: IPv4mcast_05 (01:00:5e:00:00:05)
Internet Protocol Version 4, Src: 172.19.19.2 (172.19.19.2), Dst: 224.0.0.5 (224.0.0.5)
Open Shortest Path First

No.     Time           Source                Destination           Protocol Length Info
    126 119.299539000  172.19.19.2           224.0.0.5             OSPF     122    LS Update

Frame 126: 122 bytes on wire (976 bits), 122 bytes captured (976 bits) on interface 0
Ethernet II, Src: CiscoInc_c8:28:7c (00:26:99:c8:28:7c), Dst: IPv4mcast_05 (01:00:5e:00:00:05)
Internet Protocol Version 4, Src: 172.19.19.2 (172.19.19.2), Dst: 224.0.0.5 (224.0.0.5)
Open Shortest Path First

No.     Time           Source                Destination           Protocol Length Info
    127 119.301449000  172.19.19.254         224.0.0.5             OSPF     98     LS Update

Frame 127: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on interface 0
Ethernet II, Src: CiscoInc_99:b8:15 (2c:54:2d:99:b8:15), Dst: IPv4mcast_05 (01:00:5e:00:00:05)
Internet Protocol Version 4, Src: 172.19.19.254 (172.19.19.254), Dst: 224.0.0.5 (224.0.0.5)
Open Shortest Path First






No.     Time           Source                Destination           Protocol Length Info
    128 119.331618000  172.19.19.2           224.0.0.5             OSPF     94     LS Update

Frame 128: 94 bytes on wire (752 bits), 94 bytes captured (752 bits) on interface 0
Ethernet II, Src: CiscoInc_c8:28:7c (00:26:99:c8:28:7c), Dst: IPv4mcast_05 (01:00:5e:00:00:05)
Internet Protocol Version 4, Src: 172.19.19.2 (172.19.19.2), Dst: 224.0.0.5 (224.0.0.5)
Open Shortest Path First


No.     Time           Source                Destination           Protocol Length Info
    132 121.303699000  172.19.19.2           224.0.0.5             OSPF     98     LS Acknowledge

Frame 132: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on interface 0
Ethernet II, Src: CiscoInc_c8:28:7c (00:26:99:c8:28:7c), Dst: IPv4mcast_05 (01:00:5e:00:00:05)
Internet Protocol Version 4, Src: 172.19.19.2 (172.19.19.2), Dst: 224.0.0.5 (224.0.0.5)
Open Shortest Path First



No.     Time           Source                Destination           Protocol Length Info
    133 121.305369000  172.19.19.254         224.0.0.5             OSPF     198    LS Acknowledge

Frame 133: 198 bytes on wire (1584 bits), 198 bytes captured (1584 bits) on interface 0
Ethernet II, Src: CiscoInc_99:b8:15 (2c:54:2d:99:b8:15), Dst: IPv4mcast_05 (01:00:5e:00:00:05)
Internet Protocol Version 4, Src: 172.19.19.254 (172.19.19.254), Dst: 224.0.0.5 (224.0.0.5)
Open Shortest Path First



No.     Time           Source                Destination           Protocol Length Info
    134 121.361454000  172.19.19.254         224.0.0.5             OSPF     94     Hello Packet

Frame 134: 94 bytes on wire (752 bits), 94 bytes captured (752 bits) on interface 0
Ethernet II, Src: CiscoInc_99:b8:15 (2c:54:2d:99:b8:15), Dst: IPv4mcast_05 (01:00:5e:00:00:05)
Internet Protocol Version 4, Src: 172.19.19.254 (172.19.19.254), Dst: 224.0.0.5 (224.0.0.5)
Open Shortest Path First




OSPFなエントリはまだまだ続く。