【本質をとらえるのは難しい】 CCNP TSHOOT v2.0 3日目
今日も新宿駅のカフェではちみつトーストとコーヒーで目覚まし。
カフェに外国人だらけでビックリ。店員さんも一生懸命、英語を話そうとしてたけど、相手も中国人でyes / noくらいしか話せなくて。その場合は日本語のほうがいいんだろうな笑
朝テストのポイント振り返り。
- OSPF隣接確立（ネイバー）
①シナリオ問題で問題被疑のあるルータ上でshow ip os neiで確立状況を確認
②はれていなければ、InterfaceとそのIF上でOSPFがnetworkコマンドで有効になっていることを確認してみる。あとはshow runで。ネイバー条件を再度おさらい。
OSPFの隣接条件
- Areaが同じ
- Hello/Deadが同じ
- Stab flagが同じ ABR（エリアを跨るABRにもstubを書く）
- 認証とクレデンシャル
- サブネット
[ネイバーが張れていた場合]
ルートテーブルの問題に発展するので、下記に着目してみる
ここで下記のようにACLが書かれていたとする
ip access-list 46 deny 6.0.0.0 0.255.255.255 ....(1)
ip access-list 46 permit 6.6.0.0 0.0.255.255 ....(2)
(1)が(2)より先に評価されるため、6.0.0.0/8はすべて拒否される（広報されない)
もう1つ、大切なHSRP系の問題。
まずは、#show standby (brief)ですべて解決できる。
trackの問題が好みみたいで、trackがかけられていると設定値のPriorityが書きかわる。わかりづらいのは対象のInterfaceをしっかり見る。
HSRPグループが組めていない理由はACLでHSRPv2マルチキャスト224.0.0.102が拒否されているとかがある。
とにかく trackとpriority値の比較をかける。
1つ良問。
Interface ACLとNATとBGP distribute-listが絡む問題。
被疑機器はすぐに特定できた。対象uplink/downのIF設定を見るとACLが見える。
そこを見るとbgpを張るためのpermit分があったり、icmpを通す分が見える。
NATも見えるので、クライアントからpingを打ってNATはできている模様。
しかしweb serverに到達できない。ルートテーブルを見るとルートは学習できている模様。
んー・・・なんだこれ！
すべてうまくいっているように見えるのに、End to EndのPingはだめ。
BGPコンフィグを見直すと…、distribute-listにこっそりdeny分で広報を止めてた。こんな簡単なことをスルーなんて。
仕事がらBGPのadvertising-routeを確認するなんて基本動作なのに本質を理解できていない証拠でした。ここをスマートに考えることができたら、研修も仕事もプライベートも体系立てて整理できるのに。
午後はeigrp系のトラブル演習
eigrpのネイバーが張れておらず、さらにegrp stub connected summaryがいる問題でした。
- EIGRPのstub
Hub-spokeの構成で活躍。本社NWがHubになって、たくさん小さなBranchがぶら下がるようなイメージ。stubはどん詰まりの意味で、Branch側で設定する。すると Connectedと集約ルートのみを広報する。
- EIGRPのネイバー系トラブル
AS番号、K値（帯域幅、遅延、帯域、信頼性など）、認証、
K値は デフォルトは帯域幅と遅延のみ。show ip protocolsでK値のbitを見る。
- BGP系の広報アドレストラブル
#show ip route 10.1.1.1 255.255.255.255のExactマッチをかけることを忘れずに、かつ広報アドレスを調べる
さてIPSECが出てきました。
データの暗号化、完全性（改ざんされていない）、送信元の認証
- PHASE 1 ：デバイス認証
Crypt isakmp keyで相手のアドレスと鍵を生成 - PHASE 2 ：データ暗号
暗号化する対象をACLで識別してIPsecっを適用
Crypto mapを作って、ルータの出力にそれをあてる。
さてIPsecはマルチキャストが使えないので、static routingしかできない。
Tunnel Interfaceを作り Tunnel用のIPヘッダとGREヘッダを追加することでいろんなものをカプセル化できるもの。つまりGRE Tunnel上だとOSPFなんかもまわすことができる。GRE自身にセキュリティ機能はない。なのでIPsecと併用する。
GREでTunnel Interface同士で通信して、OSPFの224.0.0.5なんかのマルチキャスト情報をカプセル化してあげて、次にIPSecで暗号化をする。
そのときにトランスポートモードでIPsecを動かすとヘッダを削減できる。
（通常だとIPSECはグローバルIPの2回ペイロードに貼っちゃうから）
- 再配送系の問題
ospf を再配送させるときはシードメトリックが必須になります。
再配送の先にいるインターフェース状態を見て、メトリックを入れる。
例
Router (config-router)# redistribute ospf 1 metric 10000 100 255 1 1500
- IPv6のおさらい
2001: DB8:C0A8: 340 （ここまでで64bit) :0000:0000:0000:0001
→(後半の64bitを省略式で） ::1
上記の頭にくるゼロは省略ができる。128bitで前後64ずつ分けて、前の部分をPrefix、後半をIF ID（ホスト部）として使うのが一般的。
- 先頭の数字が「2000 - 3FFF」がグローバルユニキャスト（まぁグローバルIP）
- 「FE80」から始まるのがリンクローカル（ルーティングしないのでnext hopと話すよう）
CCNP問題としての出方は
Loopback同士の不通が問題となり、OSPFv3のルートテーブルや再配送、GRE Tunnelを調べていく。
- #ipv6 unicast-routngで有効化
interface eth 0/0
ipv6 address 2001:db8:1:1:1::1/64
ipv6 address fe80::1 link-local
interface eth 0/1
ipv6 address autoconfig
