仮題

学習用

tera termマクロ　基本

logdir = 'C:\Users\ｘｘｘｘｘ\Desktop\'
logfile = logdir
scenario = '3-7_'
strconcat logfile scenario
strconcat logfile 'commands'
strconcat logfile '.log'
logopen logfile 0 1

sendln '######## hogehoge 1 ########'
wait '[root@localhost ~]#'

sendln 'ifconfig | grep -A 4 eno'
wait '[root@localhost ~]#'

sendln '######## packet count start ########'
wait '[root@localhost ~]#'


sendln '######## ping test ########'
wait '[root@localhost ~]#'

sendln 'ping -c 5 8.8.8.8'
wait '[root@localhost ~]#'

sendln '######## Tracert test ########'
wait '[root@localhost ~]#'

sendln 'traceroute 8.8.8.8
wait '[root@localhost ~]#'

調べもの4/8

 

https://pastebin.com/8P3kURB0

 

★bitbucketとは：githubの類似サービス。プロジェクト管理に重きを置いている。

★パケットキャプチャの概要
wireshark とSPANつかいかた
http://www.infraexpert.com/study/span.htm
http://www.infraexpert.com/info/wiresharkindex.html
・アナライザPCをつなぐポートはそれ専用にする必要がある。
　アナライザPCにIPアドレスは別に振らなくてもよい。
・wiresharkには表示ディスプレイに選択構文をぶっこむ仕様。
　キャプチャしたパケットの解析にはTCP/IPの知識要(当然か。）

 

ローカルSPAN (fe0で送受信するパケットを
同じSWのfe24に繋いだアナライザPCでキャプチャ)
SW(config)#monitor session 1 source interface fe0
SW(config)#monitor session 1 destination interface fe24

※　source interfaceの部分は、source VLAN idでもよい。
この場合vlanで送受信したパケットを飛ばす。
※ sourceの末尾には、{both |rx|tx}を指定できる。
デフォはboth。要はそのポートでの送信/受信トラフィック
　　どれをモニタしますか、ということ。

※※　受信側の末尾には、encapsulation replicateを付けることもできる。
　　　デフォルトでは無付加で、宛先ポートに飛ばされるパケットはタグなしとして扱う。
　　　encapsulation replicateを付けると、タグ付きパケットは宛先ポートでタグ付きとして扱える。

リモートSPAN(RSPAN：トランクで繋いだ異なるSWのifにキャプチャ用パケを飛ばす)
省略。上記リンクを見て。

注意点：SPANの設定はシンプルでありながら、実に多くの仕様があります。以下は個人的に特筆すべき仕様。

特筆すべきISOのローカルSPANセッションとRSPANセッションの仕様
　・　同じSPANのセッションにモニター対象ポートの「送信元ポート」と「送信元VLAN」を混在させられない。
　・　１つのSPANセッションに複数の宛先ポートを設定できるが、指定できる最大の宛先ポートは「 64 」個。
　・　Catalystスイッチは最大2つの送信元セッション（ ローカルSPANとRSPANの送信元セッションの2つ ）
　　　をサポートする。従って、同じスイッチ内でローカルSPANの実行とRSPANの実行が1つずつ可能である。

　・　SPANでキャプチャされる受信トラフィックは、スイッチが変更または処理を行う前のパケット
　・　SPANでキャプチャされる送信トラフィックは、スイッチが変更または処理を行った後のパケット

※alaxala L3SWを使う場合はこれ。
https://www.alaxala.com/jp/techinfo/archive/manual/AX2400S/HTML/11_7/CFGUIDE2/0445.HTM

※D-linkを使う場合は
　Monitoring>Mirror>Port Mirror settingsからGUIで設定可能。
　https://dlink-jp.com/wp-content/uploads/files/DGS-3120_MAN_R06_A2_B1-v3.00.pdf　これなど参考に。
　※高速ポートから低速ポートへパケット飛ばすのは不可能なので注意。


★ファイルにスクリプトを記載し、CentOs起動時に実行する方法

https://eng-entrance.com/linux_startup
ここに動作原理の概要がまとまっている。
systemd(CentOS7)かsysVinit(以前)かで起動プロセスが違うので
必要なコマンドも違ってくる。

Systemd系なら細かいコマンドはこっちを見るとよい
https://qiita.com/tkato/items/6a227e7c2c2bde19521c
http://tire-retire.blogspot.jp/2014/12/centos7rclocal.html

要はこういうこと。
プログラムの自動起動には/etc/systemd/system/　ディレクトリに(なんか).service
というファイル(ユニットファイル)が必要なので入れる。

(なんか).service
[Unit]
Description = 説明文（好きに入れて良い）
After=local-fs.target
ConditionPathExists=自動起動するプログラムが配置されているディレクトリ(/opt/パッケージ名/bin)

[Service]
ExecStart=自動起動するプログラムへのフルパス(/opt/パッケージ名/bin/YYYY.sh)
Restart=no
Type=simple

[Install]
WantedBy=multi-user.target

------------
※ほんとうは自動起動するプログラムをwrapperシェルで包んで２重化した方がよいとか書いてるけど
今回は飛ばしてみる。
------------

ユニットファイルと
自動起動するプログラムとその格納ディレクトリは、chmod chownでroot権限をつけておく。

$ sudo chown root:root /etc/systemd/system/nanka.service
$ sudo chmod 644 /etc/systemd/system/nankasys.service

$ sudo mkdir -p /opt/なんか/bin
$ sudo chmod 755 /opt/なんか/bin
$ sudo cp 自動起動.sh /opt/なんか/bin
$ sudo chown root:root /opt/なんか/bin/自動起動.sh
$ sudo chmod 755 /opt/なんか/bin/自動起動.sh

んで、上記のあとsystemctlにserviceを追加したことを教えてあげる。
$ sudo systemctl daemon-reload

systemctlがserviceを認識してるか確認。
$ sudo systemctl status なんか.service

自動起動するように設定
$ sudo systemctl enable なんか.service

 

 

(参考)SysVinit系の場合

-https://qiita.com/bonkeenu/items/721cf9ea633edfd1c532

　インスタンスの起動時、自動起動させたいシェルスクリプトの実行権限はrootで良い？
　YES ⇒　/etc/rc.localに実行シェルを

　NO　⇒　crontabの@rebootを使用する。
　@reboot /bin/sh /home/ec2-user/bin/shell.sh
　この一行を追加するだけ！！
　http://nort-wmli.blogspot.jp/2016/02/cron-osreboot-shellsh.html


-https://qiita.com/hnishi/items/6a5b8b67d807f8dfe44e
これも/etc/rc.localを使っている。

 

 

★openv switchの導入方法と挙動


★ネームスペースに分割した仮想クライアントの挙動

→多分 ip netns execでiperf鯖　iperf蔵で

分けて実行する事は出来るのでは。


★RFC 2544ベンチマーク


★eBGP VRRP VPNあたりの基礎知識

vSphere　仮想マシンのクローン

vSphere documentation center: 仮想マシーンのクローン

 

vSphere Client での、テンプレートおよびクローンの操作

 

 

元を削除するのだとこんなの↓

qiita.co

仮想マシンをコピーした時にUUIDが被ってしまったら

https://kb.vmware.com/s/article/2078903

 

コンピュータ名と IP アドレスを生成する vCenter Server アプリケーションの作成

こんなのもあるけどperl必須だし高難度。

要注意ポイント

 

 

・EIGRP -k値とか、

設定したnetworkを表示させたい

show ip protocols

 

・OSPF 設定したnetworkを表示させたい

- show ip protocols

・OSPF hello/deadを表示させたい

- show ip ospf database

 

・OSPFの認証設定？

 

・ppp chapのpwやホスト名のトラシュー方法

→show interfaces ･･･ インタフェースの状態

→debug ppp authentication ･･･PPPの認証状態

 

・単方向認証？双方向認証？

 

・PPPoEでアドレスを割り振るサーバの設定？

→

 

・GREトンネルの設定を確認したい

 

・HSPRのhello/hold→3秒と10秒

 

・SDNのコンポーネント種別

 

・

 

 

 

■

https://pastebin.com/CgdNBZpn

 11. インフラストラクチャの運用

 

要するに、NWや流れるデータを監視したり統計したり認証したり効率化したり検証したりする機能がある。
SNMP然りIP SLA然りNetFlow然りRADIUS　TACACS然りSPAN然りスイッチスタック然りDHCPスヌーピング然り。

1. SNMP： Simple Network Management Protocol
「IP」ネットワーク上の機器の一元管理のためのプロトコル。
・ネットワーク上のホストに「SNMPマネージャ」or Network Management STationという監視役のプログラムが動いており、そいつがNWを構成する機器群：SNMPエージェントを管理する。
・SNMPエージェントの機器は、自身の設定や統計情報をMIB: Management Information Baseというデータベース(ノードとオブジェクトで構成)にまとめており、MIBをもとにマネージャとエージェントがやり取りを行うことで管理が成立している。
・やり取りには、マネージャからエージェントへ定期的に情報を掘りに行くポーリングと、IFダウンやCPU使用率閾値超過、機器再起動、リンクダウン/アップ、認証失敗、ネイバー関係喪失など何らかの状態変化があった時にエージェントから自発的にマネージャへ通知するトラップの２種類がある。
・やり取りに使うのはポート161のUDPパケットだが、Trapのみポート162を使用する。
・個別のエージェントとしかやりとり出来ないと面倒なので、　コミュニティと呼ばれるグループ名を機器群に付けて　マネージャ・エージェントで共有し、機器群をコミュニティ単位で一括管理する。
結局のところ、SNMPはsyslogとよく似ている。でも目的がちょっと違う。syslogはsyslogサーバに情報を飛ばしたりもするが、どちらかというとログの集積に重点を置いている。それに対してSNMPは、変化があったら即通報！を重視している。
あとSNMPの拡張機能でトラフィックやエラーなどの通信状況を遠隔でネットワークセグメント単位で管理できるRMONという機能もあるけどCCNAの範囲じゃないので認識だけしておくがよい。
★ICND2では、SNMPエージェントの設定を深堀するよ。
一番シンプルなケースとしてSNMPv1をまず考える。要するに、こんなコマンドを把握すればよい。RT(config)#snmp-server community ICND2 rw 151RT(config)#access-list 151 permit 10.1.1.0 0.0.0.7RT(config)#snmp-server host 10.1.1.3 ICND2RT(config)#snmp-server enable trapsRT(config)#snmp-sever contact admin@hoge.comRT(config)#snmp-server locaion HogeLab
snmp-server community ICND2 rw 151 1.コミュニティ名：ICND2を設定。 2.オプションとして、MIBオブジェクトを読み書き可能な設定にしている。　 ※rwオプションを指定しないと、デフォルトではro(read only)になる。　　rwからroに属性を変えたいときはroを明示的に指定する。 3.さらにオプションとしてACL番号151を指定している。ACLの内容は下記で設定。
access-list 151 permit 10.1.1.0 0.0.0.7　・要するに、エージェントにアクセス可能なマネージャのあるNWを指定している。　　実質的に10.1.1.1～6までのホストがOKになる。
snmp-server host 10.1.1.3 ICND2　・よくわからんコマンドに見える。が、　　これこそがエージェントからマネージャにTrapを送信するための設定。　　マネージャは10.1.1.3にあるホスト。ICND2というコミュニティ名を指定してやる。
snmp-server enable traps　・snmp-server hostだけでもtrapの設定は可能なのだが、　　このコマンドで送信するtrapのタイプを明示的に指定できる。　　何も指定しないデフォルトではすべてのTrapタイプを送信する。
snmp-sever contact admin@hoge.comsnmp-server locaion HogeLab　　・管理者の連絡先と、システムのある場所を指定。　　　こうした基本情報がトラシューに役立つ。
-----------------------------------------------------
・SNMPv1とSNMPv2とSNMPv2cとSNMPv3について 　要するに、機能の改良とセキュリティレベルの向上で数段階バージョンアップした。   現在はv2だけはobsoleteでv3,v2cが主に使われている。 v1⇒v2cの進化　そもそもマネージャとエージェントの通信は、コマンドを介して行われる。　・GetRequest: マネージャ「この値をよこせ」　・GetNextRequest：マネージャ「この次の値をよこせ」　・SetRequest：マネージャ「この値を変更してくれ」　・GetResponse：エージェント「この値をあげます。次の値をあげます。変更しますた」　・Trap：エージェント「てーへんだ！IFがリンクダウンした！」　　v2cになって、新たに２つコマンドが追加された。　・GetBulkRequest：マネージャ「あれとこれとそれと一気に値をよこせ」　・InformRquest：エージェント「認証応答おねがいします」   v2cのcとは、コミュニティストリング(コミュニティ名の文字列のこと)   を使った認証をするということ。
v2c⇒v3の進化　v2cまではコミュニティ名を含むコマンドがプレーンテキストで送信されていたため、　認証を行うとはいえセキュリティ的にはよろしくない状態だった。　これを、コミュニティ名による認証から、ユーザ・グループ名による認証に変え、なおかつ　暗号化機能を追加することで改善したのがSNMPv3。　つまりは　メッセージは改ざんされないし(完全性)   メッセージの送信元が信頼されるし(認証)   メッセージの盗聴も防げる(機密性)　　ようになった。　　この認証や暗号化されたメッセージの送受信や、MIBオブジェクトへのアクセス制御を　やっているシステムのことをSNMPエンジンといい、何もしなくてもエンジンIDが　振られる。もちろん下記コマンドで明示的にエンジンIDを指定することもできる。  snmp-server engineID local 文字列   snmp-server engineID remote 192.168.1.2 文字列
要するに、SNMPv3は下記のようなコマンドで設定する。RT(config)#access-list 16 permit 10.1.1.0 0.0.0.255RT(config)#snmp-server enable trapsRT(config)#snmp-server contact hogadmin@hoge.comRT(config)#snmp-sderver location hogehogeLabRT(config)#snmp-server view ViewHoge sysUpTime includedRT(config)#snmp-server view ViewHoge ifAdminStatus includedRT(config)#snmp-server view viewHoge ifOperStatus includedRT(config)#snmp-server group groupA v3 priv access 16RT(config)#snmp-server user userA groupA v3 auth md5 Cisc0 priv aes 256 CCN@RT(config)#snmp-server host 10.1.1.3 version 3 priv userA
access-list 16 permit 10.1.1.0 0.0.0.255 ACL16を使って、10.1.1.0のNWにあるマネージャの接続を許可
snmp-server enable traps　トラップのオプションは指定せず、とりあえず全部マネージャに伝える
snmp-server contact hogadmin@hoge.comsnmp-sderver location hogehogeLab　管理者情報とシステムの所在地を指定。トラシューに役立つぞ。
snmp-server view ViewHoge sysUpTime includedsnmp-server view ViewHoge ifAdminStatus includedsnmp-server view viewHoge ifOperStatus included
　MIBのオブジェクトのサブセットを、SNMPビューとして定義している。　上記例ではシステムの稼働時間、i/fの設定状態、i/fの動作状態の各オブジェクトを　追加している。
snmp-server group groupA v3 priv access 16   snmp(v3)のグループを、groupAとして指定。snmpv3ユーザを指定する前に作成しておく必要がある。　priv・・・auth(認証あり、暗号化なし) / noauth(認証も暗号化もなし) / priv(認証も暗号化もあり)から選択。　access 16 上記で作ったACL16を適用。ようするにマネージャのあるNWからしかアクセスを受け付けない。
snmp-server user userA groupA v3 auth md5 Cisc0 priv aes 256 CCN@　user userA：エージェントに接続するホスト上のユーザー名を指定する。userA。　groupA：対応するグループ名も指定。　v3の位置はグループ名のあと。　auth md5 Cisco0…認証方法をmd5/shaから選択して、認証PWをCisc0と設定。　priv aes 256 CCN@…　暗号化アルゴリズムをaes 256に指定。                                    そして暗号化パスワード文字列をCCN@に指定。
RT(config)#snmp-server host 10.1.1.3 version 3 priv userA　TRAPの送付先マネージャとして10.1.1.3を指定。セキュリティレベルはpriv、ユーザ名はuserA。
--------------------------------------------------SNMPの検証
・コミュニティストリング(v1,v2)をみたい　#sh snmp community・基本情報をみたい　#sh snmp location   #sh snmp contact・トラップの送り先を確認したい　#sh snmp host・snmpv3の認証ユーザーを確認したい　#sh snmp user
・設定全般を確認したい　#sh snmp
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝－ここで説明しちゃう：IP SLA要は、テストパケットを生成して指定先(レスポンダ)に送ってみて遅延とかジッタとか諸々のサービスレベルを満たしているかを確認する機能。実行結果は送った側のIP SLA用のMIBに格納され、SNMPマネージャで監視できる。
こんなコマンドでテストを予約するよ。RT(config)#ip sla 3RT(config-ip-sla)#icmp-echo 172.16.2.2RT(config-ip-sla)#frequency 120RT(config-ip-sla)#exitRT(config)#ip sla schedule 3 life forever start-time now recurring
(config)#ip sla 3 ⇒3とは、オペレーション番号。
(config-ip-sla)#icmp-echo 172.16.2.2(config-ip-sla)#frequency 120(config-ip-sla)#exit ⇒レスポンダを172.16.2.2に指定。実行感覚を120秒とする。　※icmp-echo 172.16.2.2のあとに、source-interface (名前)　source-ip (アドレス)    を指定して送信元を設定する事もできる。が、　 何も指定しなくてもレスポンダに最も近いI/Fから送信してくれるので　 なくてもよい。
#ip sla schedule 3 life forever start-time now recurring⇒scheduleで実行するオペレーション番号を指定。　life foreverで無期限設定。 life 4800だと4800秒間実行。⇒start-timeで開始時間を指定可能。 month/dayでも指定できるし hh:mm:ssという形でも可能。   pendingとかnowでも可能。⇒recurringで毎日動作を自動的に実行するように設定可能。
あと、recurringの前にageout (秒数)を指定すると情報収集してないときのメモリ動作を保存する秒数を指定できる。デフォルトは0秒。


・IP SLAの設定を確認　#sh ip sla configuration・IP SLAの結果として統計情報を表示したい　#sh ip sla statistics aggregated   #sh ip sla statistics details
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

2. NetFlow　ある送付元から送付先までを１単位として、パケットの流れを集計するプロトコル。　集計した情報はNetFlowコレクタという別デバイスに送り、管理する。　ただしメモリとCPUをやたら食うので注意。
　パケットのフロー：パケットストリームの１単位は次の情報(key)で決まる。　要はレイヤ３とレイヤ４の情報。
　・送信元IPアドレス　・宛先IPアドレス　・送信元ポート番号　・宛先ポート番号　・レイヤ３プロトコル　・ToS (type of service)   ・「入力」インターフェース
　あるフローに対して、パケット数とか何バイトあったかというエントリを記録し、コレクタに送り付ける。　 フロー　パケット数　バイト数/パケット　★　　　　2110         104   ●　　　　 693         181　
※なお、上記keyを拡張して,L2ヘッダのVLAN情報とか送信元/先MACアドレスなど　さらに細かくフローを分類できるようにしたプロトコルをFlexible NetFlowという。 　Netflowより概念が拡張されて、次の４つの構成要素に分かれる。　・Flow Record: keyフィールドとNonkey(フローごとに計測する)フィールドの組み合わせ　・Flow Exporter:収集したトラフィック情報の出力先を決める。(これは前と変わらんね)   ・Flow Monitor：トラフィックの収集を実行。インターフェイスに適用。　・Flow Sampler：CPU使用率軽減のため、Flexible Netflowの分析対象のパケット数を制限。

要するに、こんな設定例になる。
RT(config)#ip CEFRT(config)#interface fastethernet 0RT(config-if)#ip flow egressRT(config-if)#ip flow ingressRT(config-if)#exitRT(config)#ip flow-export destination 10.1.1.100 9996RT(config)#ip flow-export version 9

(config)#ip CEF※ふつうIPv4でははデフォで有効なので要らない。　でもNetFlowはCEFが有効になってないと動作しない。
(config)#interface fastethernet 0(config-if)#ip flow egress(config-if)#ip flow ingress(config-if)#exit⇒インターフェースに対して送信、受信パケットそれぞれの収集を有効化する。
(config)#ip flow-export destination 10.1.1.100 9996NetFlowコレクタのホストを指定する。9996はポート番号。
(config)#ip flow-export version 9使用するバージョン名を指定する。大抵１、５、９から選ぶ。ver1はほとんど使われない。ver5はver9の下記新機能を使わない場合に指定。集約キャッシュはサポートしてない。ver9はIPv6やDoSに対応。マルチキャスト対応。メインキャッシュと集約キャッシュ両方サポート。
----------------検証確認！
・インターフェースにingress/egress設定したっけか　#sh ip flow interface・どこのコレクタに何をどんだけエクスポートしてるんだっけか　#sh ip flow export・パケットストリームの統計情報を見たいわ　#sh ip cache flow・CLIでは使わないけど統計情報のさらなる詳細を見たいわ　#sh ip cache verbose flow
-----------------------------------------------------------------------11-4  AAA
要するに、クラッカーとかいるのでNWへ接続するユーザの選別がしたいのである。
AAAとは、下記３つのセキュリティ機能のアクロニムである。Authentication：このユーザは正当なやつですか(認証)Authorization：このユーザーは何までやってもいいですか(認可)Accounting：このユーザーはいつ何をしましたか(記録)
・選別をするだけなら、各Cisco機器のローカル認証：enable passwordとか enable secretとか使えばいいじゃん⇒それはそうなんだけど、機器が１００台とか大規模ネットワークになると辛み溢れるやん…⇒AAAの機能は認証用サーバで一元管理させればいいじゃない！
という事で認証用プロトコルRADIUS(ベンダフリー)やTACACS+(Cisco)を使ってサーバに認証機能を一元で押し付ける仕組みができた。
具体的には。ルータのコンソールポートやvtyポートに管理アクセスをするときに、外部サーバに接続を飛ばして認証させるようにして、下記３つの要素で構成可能。
１．ユーザ：接続する人。２．NAS：ストレージのNASじゃない。Network Access Server。　　サーバ機器に限らず、ルータやスイッチ、アクセスポイントなど　　要はAAAのサーバ・クライアントモデルでクライアントに位置するものがNASである。３．認証サーバ：クライアントのNASからRADIUSやTACACS+で接続して認証してもらう機能。マシン。
[ユーザ]⇒接続許可要求⇒[NAS]⇒接続許可要求⇒[認証サーバ]  ⇒認証結果⇒[NAS]⇒認証結果⇒[ユーザ]

・RADIUSとTACACS+とは認証用のプロトコルである。 RADIUS: Remote Authentication Dial-In User Service TACACS+: Terminal Access controller Access-Control System Plus　何が違うのかをよく問われるのでまとめておく。 RADIUS　　    　TACACS+　標準：RFC2865,2866       シスコ独自データ： UDP TCPポート：1812,1813 49暗号化：パスワードだけ パケット全体　構成：認証と認可が一体 認証認可アカウンティング全部独立
※あと、RADIUSはPPP CHAP/PAP、新しいものではEAPを認証方式として使用。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーさて、設定例はこんな感じ。コンソールもvtyもRADIUSでいったん認証し、認証に失敗するとローカル認証を採用するのがポイント。
★RADIUSの場合RT(config)#username admin1 password ciscoRT(config)#aaa new-modelRT(config)#radius server Radius1RT(config-radius-server)#address ipv4 192.168.1.100 auth-port 1812RT(config-radius-server)#key ICND2RT(config-radius-server)#exitRT(config)#aaa group server radius RadiusGroupRT(config-sg-radius)#server name Radius1RT(config-sg-radius)#exitRT(config)#aaa authentication login default group RadiusGroup local       
(config)#username admin1 password cisco   RADIUSの認証が完了する前にtelnetセッションが切れることがある。　そういうときはNASの設定ファイル内のユーザアカウントを使って再接続をするので　ローカルユーザーを予め作成しておくのが賢い。
(config)#aaa new-model　これがAAA有効化のコマンドとなる。　
(config)#radius server Radius1　NASが接続するradiusサーバの設定情報を紐づける名前をまず作成 
(config-radius-server)#address ipv4 192.168.1.100 auth-port 1812(config-radius-server)#key ICND2(config-radius-server)#exit　radiusサーバのアドレスと、接続ポートを指定　次いでradiusサーバとの通信で使う共有キーを指定。　　※このキーはサーバ側で指定するキーと一致させる必要あり。　(config)#aaa group server radius RadiusGroup(config-sg-radius)#server name Radius1(config-sg-radius)#exit　サーバが冗長化されている場合などに備え、指定したradiusサーバ(radius1)を　今回は"RadiusGroup"という名前のグループに登録。
(config)#aaa authentication login default group RadiusGroup local     　ログイン認証リスト：ログイン認証方法の順番を記したリスト。を作成。　今回はdefaultという名前のリストで、　まずRadiusサーバのグループを使って、ダメならlocal認証で、　という内容。

★一方TACACS+の場合こんな感じになる。ほぼRADIUSと一緒。ただし、下記例では、コンソールとvtyの挙動をちょっと変えている。コンソールの場合は認証しないようにしたくて、何も認証を使わないログイン認証リストを作ってコンソール用ifに適用している。
RT(config)#username admin2 password ciscoRT(config)#aaa new-modelRT(config)#tacacs server Tacacs1RT(config-server-tacacs)#address ipv4 192.168.1.101RT(config-server-tacacs)#key CCNART(config-server-tacacs)#exitRT(config)#aaa group server tacacs+ TacacsGroupRT(config-sg-radius)#server name Tacacs1RT(config-sg-radius)#exit
RT(config)#aaa authentication login default group TacacsGroup local       RT(config)#aaa authentication login NOAUTH none
RT(config)#line console 0RT(config-line)#login authentication NOAUTH
**ユーザがLANにつなごうとした時点(スイッチポートに接続するか無線LANに接続しようとするか)  で、IDベースでユーザを認証する仕組みがある　⇒IEEE 802.1xを使う。LANへのアクセス可否を決める前に端末やユーザを認証するのがポイント。　これもRadiusサーバを使ったりするが、NASを介するモデルとは構成要素がちょっと違う。
　１．サプリカント：ユーザの使う端末にインストールし、IEEE802.1x認証システム        (スイッチサービスやLAN)に接続を求めるための「ソフトウェア」である。　２．オーセンティケータ：IEEE 802.1xに対応したスイッチや、無線LANのアクセスポイント。　　　サプリカントと認証サーバのトラフィックを中継する。そして認証成功まではLANへのアクセスを認めない。　　　中継：すなわちプロキシとしての仲介の仕事は、サプリカントにID情報を要求して、　　　その情報をサーバへ伝達し、結果をサプリカントに送り返すこと。　３．認証サーバ：RADIUSサーバ。サプリカントのIDで認証し、LANへのアクセスを認可する。　　　ただし、RADIUSサーバといっても、EAP(PPPの拡張版)の機能を備えたものに限るよ。]
-------------------------------------------------------------------------
11-5 SPAN
Switched Port Analyzer。パケットキャプチャによりネットワークトラフィックを監視する機能。指定したポートやVLANから送受信されるトラフィックを「コピー」して、別ポートに繋いだ監視機器：スニファやアナライザに転送するのが特徴。
※HUBならフラッディングするので無条件に監視機器に転送してくれるが、　スイッチだとそうも行かないのでわざわざ転送させる機能を考案した、という経緯。
HOSTA――SW1――HOSTB                  ↓　　　　　Sniffer
SW1のFa0にHOSTA、Fa1にHOSTB、Fa8にSnifferが繋がってるとする。Fa0への入力と、Fa1への出力を監視するとした場合SPANの送信元ポートはFa0、Fa1、宛先SPANポートがFa8になる。この送信元と宛先の組み合わせを、SPANセッションという。上図のように１台のスイッチにSPANセッションが完結しているものをローカルSPAN、たくさんのスイッチに送信元、宛先が分散し、１台でまとめてパケットキャプチャしてるものをリモートSPANという。
要するにこんな設定をするがよい。
RT(config)#monitor session 81 source interface fa0 rxRT(config)#monitor session 81 source interface fa1 txRT(config)#monitor session 81 destination interface fa8
※81はセッション番号。 souceのrx、txは送信か受信かを選択している。　rx txの代わりにbothを入力すると送受信両方のトラフィックを送信でき、　また何も入力しないとデフォルトでboth扱いになる、
・なお、#sh monitorで検証可能。
注意！！宛先ポートは通常のスイッチポートではなくなる、　　　　送信元ポートに宛先ポートを選べないし、逆も然り。　　　　Etherchannelのポートは送信元ポートにはできるけど宛先ポートにはできない。　　　　プラットフォームによっては宛先ポートを複数指定できるものもある。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー11-6 スイッチスタック
冗長化の手段としてSTPとかあるけどこれ設定が面倒だし、STPとか常に経路の１つをオフにしてるから生きてる経路に負荷が掛かりすぎる(オーバーヘッド)なんて事態に陥りがちである。
そこで、物理スイッチをまとめて論理的に１つのスイッチ扱いにしちゃうという力技が開発された。これをCisco StackWise(スイッチスタック)という。
-Cisco StackWiseのポイント・デフォルト設定のスイッチでも、すぐスタックに使用できる。・スイッチ同士はスタックケーブルという専用の相互接続ケーブルで繋ぐ。・繋がったスイッチ群は１つの論理スイッチとして稼働し、振られる管理IPアドレスも１つ。　統合管理が楽だし、設定も台数分しなくてよろしい。・ただしスイッチ群の中で１つマスタースイッチが選択される。　マスターのrunning configが残りのスイッチにコピーされる。　ネットワークトポロジやルーティングの情報も、継続的に更新・共有する。・スタック内の複数のスイッチを横断してEtherChannelが作成できる。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
11-7 DHCPスヌーピングとDAI
★DHCPスヌーピングについてそもそもスヌーピング(snooping)とは、 詮索すること。そもそもスプーフィング(spoofing)とは、騙ること。間違えないように。
●DHCPのDiscoverメッセージはブロードキャストなので、　同一サブネットに接続していた不正なユーザがDHCPサーバやクライアントに成り済まされちゃう　恐れがある。　DHCPサーバに成りすます場合はクライアントに不正なDGWやIPアドレスを振っちゃうし、　クライアントに成りすます場合はDHCPサーバに大量のメッセージを送信してDoSっちゃう。　⇒こうした事に対処するため、DHCPメッセージの検証を行うレイヤ２のセキュリティ機能が　DHCPスヌーピング。早い話が、DHCP要求と応答をのぞき見する。
　DHCPスヌーピングで、どうやって攻撃を防ぐ？　　・クライアント成りすましへの対処機能：全部のポートでDHCP要求のレート制限をしてDoSられないようにする。
　・サーバ成りすましへの対処機能：ポートをTrusted/Untrustedに分ける。　　正規のDHCPサーバや上位スイッチに繋がってるポートをTrustedにする。　　　-Trustedポートでは、すべてのDHCPメッセージを普通に受信できるようにする。　　そのほかのポートをすべてUntrustedにする。　　　-Untrustedポートでは、クライアント接続、DHCP要求のみを受信し、応答パケなどは破棄するようにする。　　　そしてUntrustedポートをDHCP Snooping Binding Databaseの情報収集対象にする。　　　上記バインディングデータベースには、これまでDHCPが割り当てたIPアドレス、関連付けられたクライアントの　　　MACアドレス、リース期間、ポート情報、VLAN情報が記録されており、　　　もしUntrustedポートでパケットを受信したとするとデータベースと送信元情報を照らし合わせて、　　　合致しなければ破棄しちゃうようにする。　　ここまでやれば、攻撃者がサブネットに偽DHCPサーバとして繋いで、DHCP応答を返そうとしても　　untrustedポートになるのでパケットが破棄されるので安全、というわけ。
★DAIについて　Dynamic ARP Inspection：ARPパケットを監視するセキュリティ機能のこと。　要は、DHCPスヌーピングと同様にポートをTrusted/Untrustedに分ける。
　DAIでのTrustedポートは、要は攻撃者からの接続が難しいバックボーン側、　Untrustedポートはユーザー側のアクセスポートに設定し、DAIでの監視を行う。　　そいでDHCPバインディングデータベースを拝借して、正規のARP応答のみを　ポートが転送するようにする。　DHCPと同様に、偽の応答者がARP応答メッセージを返しても、ポートが破棄してくれるし、　またARP要求送信のレートも制限することで、DoSられる心配も低減させてくれる。

10.インフラストラクチャサービス

インフラストラクチャサービス

10-1★クラウドコンピューティング


　・NIST national institute of standards technology
　　がクラウドコンピューティングの特徴を定義。
　　⇒On-demand/アクセス幅広し/リソース共用/拡張早し/サービス計測可

　・Saas Paas Iaasの違いとは要するに

 

　アプリ
　データ
　ランタイム
　ミドルウェア
　OS
　仮想化
　サーバ
　ストレージ
　NWデバイス

 

　の層があるとして、

　Gmail,Salesforceなど、全部プロバイダが管理するのがSaaS(ユーザは利用のみ)


　上からアプリ、データまでユーザが管理し、

    ランタイム以下をプロバイダが管理するのがPaaS


　上からアプリ～OSまでユーザが管理し、

    土台の仮想化～NWデバイスのみプロバイダが管理するのがIaaS

 

 

10-2 ★SDN

 

要するに：
　機器ごとにバラバラな設定を一元管理したり、

    機器や通信経路の設定を自動化したい！！
　⇒SDNを考えよう。

 

　SDN:Software-Defined Networking
　※ソフトウェアでNWを一元管理することを目的とした技術および設計思想。
　コントロールプレーンとデータプレーン(後述)を分離させる発想で生まれた
　プロトコル「OpenFlow」を発展させた考え方である。

 

・SDNを理解するためにはまず従来の設計思想を知っておこう。

＜従来＞
　ルータやスイッチの内部で、2つの別個の機能を動作させる。


　1.コントロールプレーン：

     ルーティングテーブルやMACアドレステーブルを管理する制御機能。

 

    2.データプレーン：

     コントロールプレーンが構築した転送テーブルから、
　パケットやフレームの転送処理を行う機能。


  ※コントロールプレーンはソフトウェアとして組み込まれ、

   データプレーンはハードウェア(チップ)

 

 

＜SDN＞

要するに：新たにアプリケーションプレーンを一元管理用に作り、
　　　　　そこから下層のコントローラーに指示を送る。
　　　　　コントローラーが物理デバイスを制御する。

 

抽象的な設計思想としては ３層あって、


　<アプリケーション層>

        (ネットワーク全体を管理。コントローラに指示)


　<コントロール層>　

     (SDN制御ソフトウェアとしてコントローラが

      アプリ層から指示を受けてインフラ層を制御。)


　<インフラストラクチャ層> (機器の集合体。)
　　層と層をつなぐ仲立ち機能、仕様がAPI。
　　アプリ-コント間をノースバウンドAPI、

      コント-インフラ間をサウスバウンドAPIと呼ぶ。

 

具体的な実装としては上記を反映して３層あって


　<アプリケーションプレーン＞
　(NBI)
　<コントロールプレーン＞
　(SBI)
　<データプレーン>
　となる。
　　　　　
※SBI
(ベンダフリー)

           Openflow(プロトコル) NETCONF(プロトコル)
(Cisco独自)  

   OpFlex(API)、onePK(API)、TelnetとかSSHとかSNMPもサウスバウンドのAPI
　
※NBIには標準インターフェースはなく、それぞれ特定分野のアプリでのみ動作。

 

★３層の中で最重要なのがコントロールプレーン。
次項でまとめるCisco APICもSDNコントローラにあたる。

 

 

★10-3 Cisco APIC-EM

 


Cisco　APIC-EMとはそもそも、

            Cisco ACI(application Centric Infrastructure)という製品の機能である。

 

Cisco ACIはNWの設定や機能を抽象化してプロファイルを作成、それを
コントローラであるAPIC( Application polycy infrastructure controller)へ渡し、
NW機器へ適用して制御。同じポリシーを別の機器に横展開できるので
データセンタやクラウドアプリケーションので超有用。

 

APIC-EMは、APICのが大規模DCやクラウドアプリを対象とするのに対して
中でキャンパスとかブランチとかWANのエンタープライズネットワークを
対象にしたCiscoのSDNコントローラになる。


使用APIはプログラム可能でオープン。
サウスバウンドAPI：Openflow,onePK, SNMP, CLI(telnet/SSH)

 

 

APIC-EMの何がいいかって


・ネットワーク機器のデータベース(NIDB)を作ってくれる
・新しい機器を検出するとNIDBに対応する新しいエントリを作ったうえで
　勝手に設定してくれる
・ビジネスポリシーから設定のポリシーを作り、ユーザー、時間帯別で
　NW機器にポリシーを適用してくれる。
・ACLを分析し設定ミスに気づかせてくれる
・QoSも素早く実装可
・Cisco IWAN (intelligent wan)の管理が容易。
　　IWAN:WANを通じて使用するアプリケーションの

        優先順位をNW設定に反映させるなどパス選択の最適化、

        セキュリティ担保、可視化機能などを揃えた製品


・Path Trace Appで、特定パケットの流れを可視化
・Path Trace ACLで、どのACLでパケットが破棄されているかもわかる

 

 

★10-4 QoS


要するに：Quality of Service。

     トラフィックに優先順位を振って大事なデータは先に流すようにする。
音声とかビデオのリアルタイムトラフィックは遅延や損失があまり許されない。

 

例： 音声/ビデオ
delay: どっちも150ms以下
jitter.: どっちも30ms以下
loss..:　音声：1%以下　ビデオ：0.1～1%以
band.:　音声：30～128kbps　ビデオ：384kbps～20Mbps
特にビデオは一度に集中的に流れるバーストトラフィックなので注意。

 

ーーーーーーー


QoSを理解する前に、Catalystスイッチの基本的なデータ処理方法を確認する、
ハードウェア的にパケットを処理できるL3スイッチを例にとる。

 

そもそもCatalystのL3SW等にはデータ転送用の集積回路
ASIC(Application Specific Intefrated Circuit)が積まれており、こいつがキーになる。


ASICは下記２種のメモリへデータを読みに行く。
CAM( Content Addressable Memory) : MACアドレステーブルの高速検索用メモリ
TCAM(Ternary Content ADdressable Memory)：ルーティングテーブルやACL、QoSの検索用メモリ
※ASIC、CAM/TCAMはデータプレーンにある。


こいつらにより、CEF(Cisco Express Forwarding)等のデータプレーンオンリーでの
パケット処理が可能になる。

 

データプレーンオンリーでの処理方式がCEFというやつ。

CEFは下記２つのテーブルを、

コントロールプレーンからデータプレーンにロードする、

 

-FIB（forwarding information base)

　　　ルーティングテーブルをデータプレーンにDLったもの

-Adjacency Table: ARPテーブルをデータプレーンにDLったもの

 

※ルーティングテーブルやARPテーブルはコントロールプレーンにあるからね。

 

⇒L3パケット転送に必要なテーブルが全部データプレーンにロードされているので
スイッチは高速にパケットを転送できるというわけ。

 

なお、コントロールプレーンとデータプレーンを併用する方式として
・プロセススイッチング：パケットごとにCPU処理するので遅い
・ファストスイッチング：パケットをフロー毎にまとめて、

    フローの最初のパケはソフトウェアで
　残りはデータプレーンのキャッシュで処理するので

　プロセススイッチングよりはちょっと早い。

　でも全部データプレーンで処理するCEFよりは遅い。

※なおなお,L2SWはCAMテーブルでMACアドレス解決、

　TCAMテーブルでACLやQoSを検索できてやはり高速に転送処理できる。
ーーーーー

 

さて、QoSに戻ると…こいつはやはりデータプレーンで処理する代物である。
しかしルータやスイッチにQoSが実装されているとしても、

デフォルトでは
それを利用しないベストエフォート型のモデルがネットワークに適用される。
つまり優先制御処理は行わず、

到着準にパケットやフレームを処理するFIFO方式になる。

 

これを下記で言うIntServやDiffServというQoSモデルを適用する設定にすることで
初めて、優先制御処理が行える。

 

・IntServ:Integrated Servicesの略。
RSVP(resource ReserVation Protocol)を使って、
　フロー(フローとは、送信元/宛先のIPやポート番号が同じ一連のトラフィック)
　ごとに一定の帯域を予約する。※全部の危機でRSVPを実装する必要があるので
　大規模NWではそんなに使われない。

 

・DiffServ:Differentiated Servicesの略。
　フローという塊を相手にする不器用な処理ではなく
　各パケットのIPヘッダ内やdot.1Q（トランクのやつ)タグ内に設定した
　分類・優先情報をもとに各個撃破で優先処理を行う。QoSとしてはこれがメジャー。


●DiffServモデルに代表されるQoSのメカニズムをもう少し細かくみる。

 

⇒


１．分類：トラフィックを識別してクラスに分類し、扱い方を決定。
　　送信元/宛のIPアドレスとか、ポートとか、入力I/Fとか、パケサイズとか、
　　後述するDSCP/IPP/CoS値とか
　　MPLSラベルとか

 

マーキング：分類されたパケットのグループ化：

　　要は処理待ち行列(キュー)が複数ある。
　　どのキューにぶち込んであげるかがマーキングによって決まる。
　　

　　※L2:Ethernetフレームのマーキングは、

　　.　1qのVLANIDタグの３ビットのフィールドを使う。
　　　これをCoS値(class of service)と呼んでる。

　　　なお無線LANの場合はTID値という別モンを使う。
　　
　　※L3: IPv4パケットへのマーキングは

　　　　Tos(Type of Service)という１バイトのフィールドを使う。
　　　　IPv6パケットへのマーキングは

　　　　Tosが改名されて「トラフィッククラス」を使う。

　　

　　ToSへの書き方は２種類あって、相互互換性がある。
　　- DSCP (differentiated Services Code Point) :

　　　1バイトのフィールドのうち6ビットを使う。
　　　RFC2474で定義。
　　　2^6= 64通りの優先順位が表現でき、

　　　PHB(per hop behavior)という定義で動作を決定。


　　　PHB: デフォルト＝ベストエフォート
　　　　　　CS:Class Selector=前半３ビットのみ使用しIPPと同様の8段階分類とする
　　　　　　AF:Assured Forwarding=前半３ビットの大きさで優先度、

　　　　　　　　後半3ビットで廃棄優先度
　　　　　　EF:Expediated Forwarding=緊急転送用クラス。

　　　　　　　　最優先のパケットで廃棄なし。主に音声パケットで使う。

 

　　-IPP PO precedence: ToSフィールドの上位３ビットで8段階の優先順位をつける。　

 

2. 　polishing / shaping.

　　輻輳回避術。トラフィックレートが

　　閾値(CIR:commited information rate)認定情報速度
　　を超えた時にパケットを廃棄するのがポリッシング。
　　バッファに格納して下がった時点で出力キューに配置するのがシェーピング

 

3. 輻輳管理：キューイング

　　polishing shapingにも関連する。
　　出力I/Fのキューがパケットで満杯になった時の動作.
　⇒トラフィックを分類して、対応するキューを作成してトラフィックを格納し
　　　各キューからどの順番でどの量だけパケットを送信するかを決める。
　　　
　　　例：-FIFO
　　　　　-PQ(Priority Queuing :優先度最高/高/低/最低)、
　　　　　-WFQ(weighted fair queuing:
　　　　　　　　送信-宛先情報から自動的にキューを作成・トラフィックを分類)

　　　　　-CBWFQ(class based WFQ

　　　　　　　　:管理者が手動で作ったクラスごとにトラフィックを分類）
　　 　　　　　※CQを含む。

　　　　　　　(=Custom queuing:管理差が作成したキューをラウンドロビンで処理)
　
　　　　　-LLQ:Low latency Queuing
　　　　　　　CBWFQにPQを追加した。どういうことか？
　　　　　　→CBWFQには「絶対的に優先するキュー」というのがないので補った。
　

 

　　　
4.　リンク効率化：ヘッダ圧縮とフラグメンテーション

 

　　とくに後者はLFIが主要。Link Fragmentatio and Interleaving
　　例えば音声パケットは往々にして60バイトほどで細切れだが、
　　その処理の間に1500バイト近いデカいパケットの処理が挟まると
　　次の音声パケットの送信が遅れてしまう。
　　⇒大きいデータグラムは細切れにして小さいデータを差し込めるようにする。

 

 

 

●QoSは、どこからどこまで設定するかが意外と大事。

　だってQoS適用したNW機器は分類したりトラフィックを振り分けたりで

　負荷がかかるし、あと誰が管理してるのか分からない優先度情報を解釈しろと

　言われても困るよね。

 

　→信頼境界を設定しましょう。

　　だいたいベストプラクティスは、
　　アクセススイッチ(もしくはIP Phone)からコア機器までの間で、
　　エッジから先には適用しないのがいいよ。

　　※デフォルトだと、全部untrust。

　　Cos値だとかTIDだとかDSCPだとかすべて無視する。
　　信頼境界を設定したところで、分類やマーキングがなされる。

 

 

あと知らん用語

 

-NBAR
network basd application recognition


スケジューリングまではしてくれないけど、トラフィックのレイヤ４から７までの
情報を識別し、分類したりアプリを監視してくれるツール。
音声や動画で利用され、動的に使用ポートが変わっちゃう

RTP(real-time transport protocol)みたいなアプリケーションを

分類するのに優れている。

でもスケジューリングはしてくれないので、それはCBWFQやLLQに任せる。

 

-WRED

 

　こいつを理解するのにいくつか前提を理解しよう。

 

　1.　テールドロップ　キューが満杯で到着したパケが廃棄されてしまう
　2. TCP通信の再送処理　パケットの損失が起こると再送処理が発生する
　3. 　スロースタート　パケットの損失（廃棄）の頻度が増すと

　　　転送レートを自動で落とす


要はテールドロップのせいで

沢山のTCPコネクションで一斉にTCP再送処理が起こったり
スロースタートでリンクの使用率が低下しちゃったりするのだ。 　

 

　→なので、キューが満杯になる「前に」キューに溜まったパケットを

　　ランダムに廃棄しようとなる。なった。

　　CiscoだとREDというメカニズム(ツール)がそれにあたる。　　
　　
　　

　　ただし、完全にランダムだと都合が悪いということで
　　DSCP値を基準に優先度から捨てるパケットを判断する機能を追加させた。
　　

　これをWRED(weighted random early detection)という。

　※あくまでTCPを利用したトラフィックのみに有効。UDPは関係ない。

 

 

Extra.復習

routing review

 

スタティックルートの設定おさらい

 

※躓きポイント


・ip routeコマンド
　-送信元じゃなくて宛先NWを指定すること


-nexthopはシリアルのPtoP接続じゃない限り、送出i/fには指定しない。

 

・直接接続されていて、端末へ続くスタブNWに対しては
　スタティックルートを設定する必要ない。
　隣のルータへパケットを渡すときに設定が発生。

・端末にデフォルトゲートウェイの設定をし忘れるポカで30分悩む事象

 

★ダイナミックルートの設定おさらい。

今回はOSPF

 

※理解浅かったポイント

 

・そもそもの設定コマンドの記憶があやふや。　

(conf)#router ospf 1
(conf-router)#network 192.168.1.0 0.0.0.255 area 0

 

-プロセスidについてはわかっているが
-シングルエリアなら全部バックボーン扱いでエリア０に指定するのが理解浅し
-そのエリアに巻き込みたいi/fを含むネットワークアドレスで指定するのが理解浅し
-サブネットマスクでなくワイルドカードマスクを使うのは完全に失念