ネットワーク備忘録

アラフォーエンジニアのネットワーク系の備忘録。twitter:@deigo25374582

ACL編集

cisco

最近知ってビックリしたこと。

名前付きACLなら、ACEの編集はできたのは知ってたけど、番号のACLはACEの編集はできなかった記憶があった

 

Router(config)#access-list 1 permit any   
Router(config)#
Router(config)#access-list 1 deny any
Router(config)#
Router(config)#access-list 1 192.168.1.0 0.0.0.255

 

・・・と、ここまで打って、確認

Router#sho access-lists
Standard IP access list 1
    10 permit any
    20 deny   any
    30 permit 192.168.1.0, wildcard bits 0.0.0.255

ここで、20と30の間にACEを入れる場合は・・・

 

Router(config)#ip access-list standard 1
Router(config-std-nacl)#25 permit 10.0.0.0 0.255.255.255
Router(config-std-nacl)#
Router(config-std-nacl)#exit
Router(config)#ip access-list resequence 1 10 10

そして、確認


Router#sho access-lists
Standard IP access list 1
    10 permit any
    20 deny   any
    30 permit 10.0.0.0, wildcard bits 0.255.255.255
    40 permit 192.168.1.0, wildcard bits 0.0.0.255

ちゃんとエントリが挿入されている！！

今まで思い切り勘違いしてました

編集の場合は名前付きACLの構文使えばいけるなんて

数回前の備忘で書いてた内容を消したい位恥ずかしい・・・OTL

BFD（双方向フォワーディング）

cisco

以前、ネットワーク設計でこの機能を使いそうになるものの結局は使わずじまいになってしまい、最近まで忘れていたので整理。

BGPとか動いている現場だと、割と使われているっぽいんで備忘も兼ねて・・・

 

BFDは簡単に言うと、「障害検知に特化したプロトコル」

 

例えば、以下の構成でルータがOSPFを喋っていると想定。

f:id:klock_3rd:20140403202046p:plain

↑の場合は、OSPFのHello、Deadをいじらなければリンクダウンの場所によっては、経路切り替わりまでに時間が掛かる。

　試しに、ルータのOSPFのhelloを5,Deadを20にてした状態でL2SW間を抜線すると、両方のルータ共にしばらくはリンクダウンを検知できないはず。

 

Router#sho clock
*11:33:46.955 UTC Thu Apr 3 2014

↑が抜線直後で約16秒後にネイバーダウンを検知

*Apr  3 11:34:02.567: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on FastEthernet0 from FULL to DOWN, Neighbor Down: Dead timer expired

そこで今度はHello＆Deadインターバルは変えず、両方のルータに以下を投入

 

Router(config-if)# bfd interval 100 min_rx 500 multiplier 3

Router(config-router)#bfd all-interfaces

 

投入後のBFD状態は・・・

Router#sho bfd nei

NeighAddr                         LD/RD    RH/RS     State     Int
192.168.1.1                        1/1     Up        Up        Fa0
→相手を認識してる

 

この状態で抜線する

Router#sho clo
*12:07:31.683 UTC Thu Apr 3 2014
↑が抜線直後で、今度は数秒以内にネイバーダウン
*Apr  3 12:07:33.155: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.1.1 on FastEthernet0 from FULL to DOWN, Neighbor Down: BFD node down

BFDの状態は・・・

Router#sho bfd nei
Router#
→表示されない

 

そんなわけで、BFDを使うとタイマーを変えずに検知が可能。

ACL編集

cisco

自分は割と当たり前だと思ってたけど、一緒に働いていて知らなかった人もいたのでメモ代わり

 

ACLは特に要件なければ名前付きIP アクセスリストが無難な気がします。

理由はACLの編集が出来るから。

 

例えば、10.1.1.1から192.168.1.1〜192.168.1.3への通信を許可する場合は・・・

100〜199の番号付きACLだと流し込んだ後は・・

Router(config)#do sho ip access-lists
Extended IP access list 100
    10 permit ip host 10.1.1.1 host 192.168.1.1
    20 permit ip host 10.1.1.1 host 192.168.1.2
    30 permit ip host 10.1.1.1 host 192.168.1.3

新規で作る分には問題ないけど、↑の状況で「192.168.1.2は削除したい」ってなったら・・・

「ACL100を削除してもっかい入れなおし」が発生。

　まぁ、「もっかい入れなおし」がアリならそれはそれでいいんですが、これが名前付きACLだと、編集が楽

Router(config)#do sho ip acce
Extended IP access list test
    10 permit ip host 10.1.1.1 host 192.168.1.1
    20 permit ip host 10.1.1.1 host 192.168.1.2
    30 permit ip host 10.1.1.1 host 192.168.1.3

 

この状態から・・・

Router(config)#ip access-list extended test
Router(config-ext-nacl)#no 20
Router(config-ext-nacl)#exi
Router(config)#ip access-list resequence test 10 10

Router(config)#do sho ip acce
Extended IP access list test
    10 permit ip host 10.1.1.1 host 192.168.1.1
    20 permit ip host 10.1.1.1 host 192.168.1.3
こっちだとACLの追加と削除は行番号指定でできるから便利

 

例えば帯域制御でclass-mapでmatchの指定がACLとかだと、削除してもっかい入れなおしは不便に思います・・・というか個人的にはあり得ない気がします。

NAT

cisco

今更ながらNATの整理

 

f:id:klock_3rd:20140314000753p:plain

 

↑の環境で,NATのパターンは大まかに３つ

PC1→PC2でのNAT、PC2→PC1でのNAT、PC1→PC2での双方向NAT

  • PC1→PC2でのNAT
    Configは
    　ip nat inside source static 192.168.11.2 192.168.20.200
    PC1での送信パケットは　送信元：192.168.11.2　宛先：192.168.20.1
    PC2での受信パケットは　送信元：192.168.20.200　宛先：192.168.20.1
    #do sho ip nat trans
    Pro Inside global      Inside local       Outside local      Outside global
    icmp 192.168.20.200:16057 192.168.11.2:16057 192.168.20.1:16057 192.168.20.1:16057
    --- 192.168.20.200     192.168.11.2       ---                ---
    PC2→PC１の通信は
    PC2での送信パケットは　送信元：192.168.20.1　宛先：192.168.20.200
    PC1での受信パケットは　送信元：192.168.20.1　宛先：192.168.11.2


  • PC2→PC１でのNAT
    Configは
    　ip nat outside source static 192.168.20.1 10.1.1.100
    　ip route 10.1.1.100 255.255.255.255 FastEthernet0
    PC2での送信パケットは　送信元：192.168.20.1　宛先：192.168.11.2
    PC1での受信パケットは　送信元：10.1.1.100　宛先：192.168.11.2
    #sho ip nat trans
    Pro Inside global      Inside local       Outside local      Outside global
    --- ---                        ---                    10.1.1.100         192.168.20.1
    icmp 192.168.11.2:1    192.168.11.2:1     10.1.1.100:1       192.168.20.1:1
    PC1→PC2の通信は
    PC1での送信パケットは　送信元：192.168.11.2　宛先：10.1.1.100
    PC1での受信パケットは　送信元：192.168.11.2　宛先：192.168.20.1


  • PC1→PC2での双方向NAT
    Configは
    　ip nat inside source static 192.168.11.2 192.168.20.200
    　ip nat outside source static 192.168.20.1 10.1.1.100
    　ip route 10.1.1.100 255.255.255.255 FastEthernet0　（fa0はOutside IF）
    PC１での送信パケットは　送信元：192.168.１１.２　宛先：10.1.1.100
    PC1での受信パケットは　送信元：192.168.200.200　宛先：192.168.20.1
    #sho ip nat trans
    Pro Inside global      Inside local       Outside local      Outside global
    --- ---                ---                10.1.1.100         192.168.20.1
    icmp 192.168.20.200:16439 192.168.11.2:16439 10.1.1.100:16439 192.168.20.1:16439
    --- 192.168.20.200     192.168.11.2       ---                ---

要は・・・
ip nat inside 　　　　　　　　　　　　　ip nat outside
　Inside → Outside　では src-NAT 　　　　Inside → Outside　では dst-NAT

　Outside → inside　では dst-NAT　　　　Outside → inside　では src-NAT

 

後は、NATの処理順序に注意

 

CCNP復習

仕事で基本設計的なところばっかりしていたせいで、実際のコマンドをど忘れすることが多くなってきました。

最近だと、CISCOルータにDHCPサーバ設定を入れようとして「あれ？　どうやるんだっけ？」的など忘れが・・・OTL

　一応、CCNPを持っているとはいえ、元々そこまでNWの実務経験が豊富な人間でもないから短期間の試験勉強のようなやりかただとすぐに記憶から消されてしまいますねw

要反省です。

 

CISCOのPIM-SM備忘

cisco

 

 

 

 

自身がマルチキャストを仕事で経験していなかったため、概念的なものは大まかに理解しているるものの、仕組みが今ひとつピンとこなかったため、この休みはちょっとマルチキャストの勉強をしてました。

PIM-DMはとっつきやすかったんですが、PIM-SMはまだ全然理解できてないんでちょっとメモ

後で、復習する際の構成メモ代わりも兼ねて

＜構成＞

f:id:klock_3rd:20140302210513p:plain

（各ルータにてOSPFを動かして、送信元と受信元の経路は各ルータで知っている状態。）

　PIM-DMではRPFチェックにユニキャストのルーティングテーブルを使いディストリビューションツリーを作るのでいいんですが、PIM-SMの場合はディストリビューションツリーが下記の場合で異なる。

とりあえず、現状は↑の理解もあっているかどうかも怪しいレベルなので、混乱を招くおそれもあるから要点だけ記載。

  1. 各ルータは「ip multicast-routing」&各IFに「ip pim sparse-mode」
    (PIM-SMの設定)
  2. 各ルータに「ip pim autorp listener」の設定（PIM-SMの場合RPがどれか知らないとマルチキャストルーティングができない）
  3. RP候補のルータには「ip pim send-rp-announce interface scope ttl 」
  4. MAのルータには「ip pim send-rp-discovery scope ttl interval sec」
  5. ラストホップルータに「ip pim spt-threshold infinity」

スイッチオーバーをさせたくなかったので、SPTの閾値はinfinityに。

 

マルチキャストレシーバとルータの間にL2SWを突っ込んでIGMPもやりたかったけど、今回は時間的な都合もあり、動作が確認できる程度で終了。　次回はマルチキャストの確認コマンドやmtrace等も実際に打ってみたりしたいな～

 

Windows7&VLC Playerでのマルチキャスト検証の注意点

最近、マルチキャストを勉強で、Cisco 1812Jを使って検証しようとした際にハマったのでその記録

 

ネットで調べてみると、マルチキャストでの検証はVLC Playerを使うのが一般的みたいだったので自分もVLC Playerを入れることにしました。

 

まずはVLCの設定が正しいかを同一セグメント内で検証してみたところ問題なし。

 

そんなわけで、間にルータを数台置いてPIM-Denseモードを試したところ受信せず。

ユニキャストルーティングで経路が伝わってないのか？　とか思うも、ちゃんとマルチキャストレシーバまで経路は存在してる。

　マルチキャストの設定がおかしい？　と思いルータも確認してみるも問題なさげ・・・

VLCがおかしい？　と思いパケットキャプチャしてみるもののマルチキャストアドレスで送信してる。

 

なんだろ？？　ってことで色々調べてみたら送信されているパケットのTTLが1でした。

 

・・・そりゃ届きませんね。

 

けれど、Windows７のVLC PlayerではTTLを設定するような項目は見当たらない・・・

OSのレジストリをいじるのか？？

幸い、手元にはマルチキャストレシーバ用のOSがUbuntuだったため試しにそれの設定をみたところ、TTLは変更可能。

 

とりあえずはマルチキャストの勉強はできそう。

 

ただ、仕事だとWindows7だからこれはどうにかしないと不味いですな