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 151
RT(config)#access-list 151 permit 10.1.1.0 0.0.0.7
RT(config)#snmp-server host 10.1.1.3 ICND2
RT(config)#snmp-server enable traps
RT(config)#snmp-sever contact admin@hoge.com
RT(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.com
snmp-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.255
RT(config)#snmp-server enable traps
RT(config)#snmp-server contact hogadmin@hoge.com
RT(config)#snmp-sderver location hogehogeLab
RT(config)#snmp-server view ViewHoge sysUpTime included
RT(config)#snmp-server view ViewHoge ifAdminStatus included
RT(config)#snmp-server view viewHoge ifOperStatus included
RT(config)#snmp-server group groupA v3 priv access 16
RT(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.com
snmp-sderver location hogehogeLab
　管理者情報とシステムの所在地を指定。トラシューに役立つぞ。

snmp-server view ViewHoge sysUpTime included
snmp-server view ViewHoge ifAdminStatus included
snmp-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 3
RT(config-ip-sla)#icmp-echo 172.16.2.2
RT(config-ip-sla)#frequency 120
RT(config-ip-sla)#exit
RT(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 CEF
RT(config)#interface fastethernet 0
RT(config-if)#ip flow egress
RT(config-if)#ip flow ingress
RT(config-if)#exit
RT(config)#ip flow-export destination 10.1.1.100 9996
RT(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 9996
NetFlowコレクタのホストを指定する。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 cisco
RT(config)#aaa new-model
RT(config)#radius server Radius1
RT(config-radius-server)#address ipv4 192.168.1.100 auth-port 1812
RT(config-radius-server)#key ICND2
RT(config-radius-server)#exit
RT(config)#aaa group server radius RadiusGroup
RT(config-sg-radius)#server name Radius1
RT(config-sg-radius)#exit
RT(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 cisco
RT(config)#aaa new-model
RT(config)#tacacs server Tacacs1
RT(config-server-tacacs)#address ipv4 192.168.1.101
RT(config-server-tacacs)#key CCNA
RT(config-server-tacacs)#exit
RT(config)#aaa group server tacacs+ TacacsGroup
RT(config-sg-radius)#server name Tacacs1
RT(config-sg-radius)#exit

RT(config)#aaa authentication login default group TacacsGroup local
RT(config)#aaa authentication login NOAUTH none

RT(config)#line console 0
RT(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 rx
RT(config)#monitor session 81 source interface fa1 tx
RT(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られる心配も低減させてくれる。