CCIE R&S 筆記１ smurf / DDoS

仕事柄保持している様々なCisco資格の再認定のため、筆記試験を受けようと考えている。

つれづれに学んだ内容の記録です。

--

Security

1. Access Lists
2. LAN security
3. Device Security/Access
4. Spoofing

Access Lists

1. スマーフ攻撃

http://www.cisco.com/support/ja/707/22.shtml#topic2 　参照。

UDP ベースのエコーサービス

　　エコーサービスは UDP に基づくアプリケーションのデータグラムによっ
　　て定義される。サーバは UDP データグラムのため UDP ポート 7 で接続待機
　　する。データグラムが受信されたら、送られたデータは応答のデータグラムと
　　して送り返される。

「smurf」攻撃の被害者: 1 つは「最終的なターゲット」で、もう 1 つは「リフレクタ」です。 この攻撃では、リフレクタ サブネットのブロードキャスト アドレスに ICMP エコー要求（「ping」）が大量に流されます。 これらのパケットの送信元アドレスは、最終的なターゲットのアドレスに偽装されています。 攻撃者によって送られる各パケットに関してはリフレクタサブネットの多くのホストは応答します。 これは最終ターゲットにあふれ、両方の犠牲者のための帯域幅を浪費します。

「fraggle」と呼ばれる類似の攻撃では、同様にダイレクト ブロードキャストが使用されますが、ICMP エコー要求の代わりに UDPエコー要求が使用されます。 通常 fraggle は smurf に比べて増幅要素が小さく、それほど一般的ではありません。

smurf 攻撃は、通常はネットワーク リンクが過負荷になることによって発見されます。

DoS 識別アクセス リスト

access-list 169 permit icmp any any echo
access-list 169 permit icmp any any echo-reply

# smurf check
access-list 169 permit udp any any eq echo
access-list 169 permit udp any eq echo any

#fragile check
access-list 169 permit tcp any any established
#SYN flood check

access-list 169 permit tcp any any
access-list 169 permit ip any any

interface serial 0
ip access-group 169 in

このリストはトラフィックを全然フィルタ・アウトしません; エントリはすべて許可されます。 しかし、このリストによるパケット識別は、攻撃が次に挙げる3つのタイプのいずれであるかを診断するための第一歩として役立ちます。 smurf、SYNによるフラッド攻撃およびfraggle。

smurf 攻撃

スマーフストリームをトレースするために、このようなアクセス・リストを使用

access-list 169 permit icmp any any echo log-input
access-list 169 permit ip any any

ICMP/Smurf のレート制限

次のアクセス リストを設定します。

access-list 102 permit icmp any any echo
  access-list 102 permit icmp any any echo-reply
  interface <interface> <interface #>
    rate-limit input access-group 102 256000 8000 8000 conform-action transmit 
    exceed-action drop

12.0(X)[S/T/M]

どのホストが攻撃を受けているかわかっている場合は、次のアクセス リストを設定します。

access-list 105 permit tcp any host 10.0.0.1 syn
  
  !--- Syn パケットだけを対象とします。
  
  interface <interface> <interface #>
    rate-limit input access-group 105 8000 8000 8000 conform-action transmit 
    exceed-action drop

注：ここでは、攻撃を受けているホストが 10.0.0.1 であることを前提としています。

どのホストが攻撃を受けているかわからず、ネットワークを保護する場合は、次のアクセス リストを設定します。

access-list 106 permit tcp any any syn
  
  !--- Syn パケットだけを対象とします。
  
  interface <interface> <interface #>
    rate-limit input access-group 106 64000 8000 8000 conform-action transmit 
    exceed-action drop

注：すべての TCP Syn パケットを、64000 bps にレート制限します。

防御策

分散サービス拒絶攻撃を防ぐ方法として、次の対策を推奨します。

1. 接続のアップストリーム端にあるルータの入力インターフェイスで、ip verify unicast reverse-path インターフェイス コマンドを使用します。

   この機能は、インターフェイスで受信された各パケットを検査します。 発信元 IP アドレスについて、パケットが受信したインターフェイスと同じインターフェイスに戻るルートが CEF テーブル内にない場合、ルータはそのパケットをドロップします。

   ユニキャスト RPF の機能は、SMURF 攻撃（および発信元 IP アドレスの偽装を用いる他の攻撃）を ISP の POP（リースとダイヤルアップ）で止めることです。 この機能により、ネットワークとカスタマー、および他のインターネットを保護できます。 ユニキャスト RPF を使用するには、ルータで「CEF スイッチング」または「CEF 分散型スイッチング」を有効にします。 CEF スイッチングの場合は、入力インターフェイスを設定する必要はありません。 CEF がルータで実行されている間は、個々のインターフェイスに他のスイッチング モードを設定できます。 RPF は入力側の機能であり、インターフェイスまたはサブインターフェイスを有効にし、ルータで受信されたパケットに対して動作します。

   ルータで CEF を動作することは非常に重要です。 RPF は CEF がないと動作しません。 ユニキャスト RPF は、11.2 または 11.3 のイメージではサポートされません。 ユニキャスト RPF は、AS5800 などの CEF をサポートするプラットフォームの 12.0 に含まれます。 したがって、AS5800 の PSTN/ISDN ダイヤルアップ インターフェイスでは、ユニキャスト RFP を設定できます。

2. アクセス制御リストを使用して、RFC1918 のアドレス空間すべてにフィルタを実行します。

   次の例を参照してください。

   interface xy
        ip access-group 101 in
        access-list 101 deny ip 10.0.0.0    0.255.255.255 any
        access-list 101 deny ip 192.168.0.0 0.0.255.255 any
        access-list 101 deny ip 172.16.0.0  0.15.255.255 any
        access-list 101 permit ip any any
     

3. ACL を 使用して、入力フィルタリングと出力フィルタリングを適用する（RFC 2267 を参照）。

   次の例を参照してください。

        { ISP Core } -- ISP Edge Router -- Customer Edge Router -- { Customer network }

   ISP のエッジ ルータでは、カスタマーのネットワークに属する発信元アドレスを持つトラフィックだけを受け入れるようにします。 カスタマー側のネットワークでは、カスタマーのネットワーク ブロック以外の発信元アドレスを持つトラフィックだけを受け入れるようにします。 次に示す例は、ISP のエッジ ルータ用の ACL です。

   access-list 190 permit ip {customer network} {customer network mask} any 
          access-list 190 deny ip any any [log] 
          interface {ingress interface} {interface #} 
            ip access-group 190 in 
     

   次に示す例は、カスタマー側のエッジ ルータ用の ACL です。

   access-list 187 deny ip {customer network} {customer network mask} any 
          access-list 187 permit ip any any 
          access-list 188 permit ip {customer network} {customer network mask} any 
          access-list 188 deny ip any any 
          interface {egress interface} {interface #} 
            ip access-group 187 in 
            ip access-group 188 out 

   Cisco Express Forwarding（CEF）を実行できる場合は、ACL での長さをかなり短くできるため、ユニキャスト RPF を有効にすることで処理効率が上がります。 ユニキャスト RPF をサポートするには、ルータ上で CEF を有効にするだけです。この機能が有効にされているインターフェイスは、CEF スイッチ インターフェイスである必要はありません。

4. CAR を使用して、ICMP パケットにレート制限を適用します。

   次の例を参照してください。

   interface xy 
      rate-limit
    output access-group 2020 3000000 512000 786000 conform-action 
     transmit exceed-action drop 
     access-list 2020 permit icmp any any echo-reply 

5. SYN パケットにレート制限を設定します。

   次の例を参照してください。

   interface {int} 
     rate-limit
    output access-group 153 45000000 
     100000 100000 conform-action 
     transmit exceed-action drop 
      rate-limit output access-group 152 1000000 100000 
     100000 conform-action 
     transmit exceed-action drop 
     access-list 152 permit tcp any host eq www 
     access-list 153 permit tcp any host eq www 
     established 

   上記の例を次のように置き換えます。

   • リンクの帯域幅の最大値に 45000000

   • SYN フラッド レートの 50 ～ 30 % の間の値に 1000000

   • 通常のバースト レートと最大バースト レートを正確な値に置き換えます

   バースト レートを 30 % 以上の値に設定すると、正当な SYN がドロップされる場合があることに注意してください。 バースト レートをどこに設定するかの参考には、show interfaces rate-limit コマンドを使用して、インターフェイスの適合レートと超過レートを調べてください。 この操作の目的は、SYN に必要最低限のレート リミットを与えて、再度実行することです。
   

Aironet無線LAN

Cisco WLAN 中小企業向け　製品と価格
http://www.cisco.com/japanese/warp/public/3/jp/solution/small_medium_sized_business/related_product/lan.shtml
WLANテクニカルサポート－製品
http://www.cisco.com/support/ja/index/Products/Wireless_278875243.html
次世代WLANセキュリティ
http://www.cisco.com/japanese/warp/public/3/jp/service/tac/102/wlan/nextgen-j.html

IEEE 802.11 認証と結合
認証とは、WLAN への参加を望むクライアントの参加資格を検証するプロセスのことです。結合とは、クライアントを WLAN 内の特定の AP と関連付けるプロセスです。

802.11 仕様では、実際に次の 3 つの状態が定義されています。（8802-11-1999.pdf の 40 ページ）

非認証および非結合

認証済みおよび非結合

認証済みおよび結合済み

AironetAPのカテゴリわけ
http://www.cisco.com/japanese/warp/public/3/jp/product/hs/wireless/airo1230/prodlit/airoso_ds.shtml

Aironet TOPページ
http://www.cisco.com/japanese/warp/public/3/jp/product/hs/wireless/

Wireless　Solution
http://www.cisco.com/japanese/warp/public/3/jp/solution/mobility/technical/wireless_sol/

AP　１２．３．４JA　コンフィギュレーションガイド
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/wr/airo1k/caapciscg/chapter10/7092_01_10.shtml#13001
*　WEPキー番号の制限、ソフトウェアバージョンとセキュリティ機能、各種EAP実装時のクライアントとAPの制限

Cisco Offers Pre-Lab Assessment for CCIE Candida

これはけっこうニュースです。

ＣＣＩＥＬａｂ対策の４時間の模擬試験をUS$279, a discount of US$70 off the list price of US$349で受けられるそうです。

１２月１２日からで、いつまでかは不明。

準備がまにあえば、いいかも！

「IP電話の基本と仕組み」湯山尚之著 vol1

大連旅行をはさんで、少し間があいてしまいました。

今回は、「IP電話の基本と仕組み」湯山尚之著　から、ＳＩＰの基本など再確認。

--

コネクション型：通信に先立ち相手と接続を確認してから通信開始。
コネクションレス型：相手との接続を確認せずにデータ転送開始。

ＶｏＩＰ技術の構成要素
１．ＩＰ電話の発着信を制御する技術＝シグナリング技術
発信者からの要求に応じて着信先を決定し、音声通話を行うための回線を決めたり、切断したりする
リアルタイム通信にはコネクション型が必要。→コネクション型プロトコルがシグナリング技術の中心
；H.323, SIP, MGCP, MEGACO
２．音声をＩＰネットワークに流す技術=CODEC技術
アナログ音声信号を符号化し復元する方法とデータの圧縮・展開方法についての技術
データの符号化器・復元器（Coder/Decorder）->CODEC
３．ＩＰ電話の通話品質を高める技術=IPパケット技術
圧縮符号化したデータをどのようにＩＰパケットに分割して送受信するかを決定。
この処理によって音声の伝わりかたや聞こえ方が違う。→通話品質に大きく影響

以上3つの技術について
ＩＥＴＦ：標準化
ＩＴＵ－Ｔ：国際標準として「勧告」

以降、それぞれの技術についてまとめます。

今回は、１．ＩＰ電話の発着信を制御する技術＝シグナリング技術　から。

・ＶｏＩＰゲートウェイ：音声信号をデジタル化、発着信をシグナリング
接続される電話機の状態を監視しながら、電話機があがったら通話準備、ダイヤルされたら発信と判断し、相手先の電話機を呼び出す。
同時に音声信号をデジタル化し、パケットに分割し、宛先を指定してＩＰネットワークへ送り出す。
・ＶｏＩＰゲートキーパー：電話番号とＩＰアドレスを管理（対応データベースを維持）、ゲートウェイからの問い合わせに解答
小規模ＮＷでは、ＧＫ機能を内蔵したＧＷも使用される。

H.323：インターネット上でマルチメディア通信を行うための技術
1996年ＩＴＵ－Ｔ標準化。->2000, v4
通信端末機器の音声通話のシグナリングからマルチメディア通信まで対応するため、オーディオやビデオデータのシステム制御まで可能。
ベストエフォートがべースで、サービス品質に関する規格は含まれない。
通信相手のＩＰアドレスなどバイナリ形式で扱う。

H.323と関連プロトコル

接続手順を決める；
H.225:通話する相手端末と接続するまでの手順を規定
H.225には、端末同士のコネクションを設定するQ.931、ＧＫとの通信プロトコルであるＲＡＳ（ＲｅｇｉｓｔｒａｔｉｏｎＡｄｍｉｓｓｉｏｎａｎｄＳｔａｔｕｓ：ＧＫへの端末登録、端末の通信許可、通信状態の問い合わせなどを行う＝ダイレクトシグナリングでは不要）、送受信時の時間的な同期をとるＲＴＰも関係する。
・ダイレクトシグナリング：ＧＫを経由せず端末同士が直接相手を呼び出す。小規模向け。
各ＧＷに、通話相手先の電話番号とＩＰアドレスの対応を登録しておく。
・ＧＫダイレクトシグナリング：相手の呼び出しはＧＫ同士で行い、それ以降のネゴシエーションは端末同士で行う。現在の主流。
各ＧＷはＧＫにアドレス情報を登録しておく。ＧＫで、ＩＰアドレスの集中管理が可能。電話番号の変更やネットワークの運用をＧＫで集中管理。
・ＧＫ経由シグナリング：呼び出し、ネゴシエーションともにＧＫ経由で行う。課金情報や詳細な通信情報を管理できる。
接続を完了するためには、ＲＡＳを利用したメッセージと、端末同士が呼び出しのために使用するシグナリングメッセージ（Ｑ．９３１）が交わされる。この手順が問題なく行われると、初めて端末同士が通信できる状態になる。続いて、Ｈ．２４５を用いた端末同士のネゴシエーションが開始され、一般的なＩＰ電話の通話が可能になる。

H.245:接続後、お互いの端末同士が通話する際、実際の音声や動画などのデータ形式、コントロールする権利をどちら側が受け持つか（どちらが主役で通話を行うかを決める作業＝ネゴシエーション）などを規定。
ネゴシエーションを行うことで、二つの端末の機能を、受信機能と送信機能に区別。
端末同士が通信を行うためのネゴシエーションを開始。
＜ネゴシエーションの完了から通話まで＞
発信元－－－ＴｅｒｍｉｎａｌＣａｐａｂｉｌｉｔｙＳｅｔ（G.711?G.723?G.729?・・・）－－－＞宛先
発信元＜－ＡＣＫ＋ＴｅｒｍｉｎａｌＣａｐａｂｉｌｉｔｙＳｅｔ（G.711?G.723?G.729?・・・）－宛先
発信側端末が最終的にどのＣＯＤＥＣを使うか決定
発信元－Ｇ．７２９に決定！－－－－－－－－－－－－－－－－－－－－－＞宛先
ネゴシエーション完了
（ここで3者通話のマスターを決めることもできる）
ＩＰネットワークでデータを流すためのロジカルチャンネルを設定
リアルタイム音声通話開始

ＲＴＰ（ＲｅａｌｔｉｍｅＴｒａｎｓｐｏｒｔＰｒｏｔｏｃｏｌ）：音声データの送受信
パケット化された音声データを送信端末が送り出すときに、実際に送信された正確な時間を記録する：ＲＴＰタイムスタンプ
受信側端末は、パケットを受信しながらＲＴＰタイムスタンプを参照し、そのパケットの受信がいつ予定されていたのか、パケットが時系列に沿って到着しているかを確認して再生。
再送での遅延を避けるため、ＵＤＰを併用。

ＣＯＤＥＣ：符号化・圧縮率を決定
現在は高圧縮率のG.729が主流

H.248:GWのコントロール。ＧＷ同士の通信に利用。

H.261/H263：映像データのＣＯＤＥＣ。ＴＶ電話などで利用。
H.261が必須、H.263はオプション。

ＳＩＰ：ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ
1999,IＥＴＦが規定。 RFC2543
通信相手の宛先ＩＰアドレスなどテキスト形式で指定。
インターネット上のほかのプロトコルとの親和性が高い。
ＩＭＴ－２０００の３Ｇ携帯ではＳＩＰを採用。
Ｈ．３２３と比べてシンプルで拡張性が高い。
Ｈ．３２３では利用できない転送電話サービス、「キャッチフォン（ＮＴＴ）」相当の通話中にさらに着信があったときに通話を保留しもう一方と
通話する「コールウェイティングサービス」、3者通話、多地点を結んだＴＶ会議システムなどを実現。
ＩＰ電話サービスは、ＳＩＰのコネクション型サービスの一例。
ＳＩＰはレイヤ５のセッション層プロトコル。

<SIPネットワークの基本構成>
１．ＵＡ（ＵｓｅｒＡｇｅｎｔ）：端末。Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ両方の機能を持ち、1つのセッションを処理するときに両方の機能を使う。（ＵＡＣ／ＵＡＳ）
リクエストを行うときはＵＡＣ、リクエストを受けて結果を返すときはＵＡＳ。
ＩＰ電話機、ＰＣやＰＤＡ上のクライアントアプリケーション、ＧＷも含む。
このほか、トランザクション（リクエストを受けてそれに対して結果を返す一連の通信処理：「通話相手を呼び出す」、「接続を行う」、「通話が終了したら回線を切断する」というのが電話での一連のトランザクション）を管理する役割もある。
端末によってインターフェイスが違う；
電話機：発信に関してはダイヤルというインターフェイス
ＰＣ：アプリケーションソフトでのクリック
家電製品ではまた違うインターフェイス
→しかしＳＩＰの本質的な機能は共通。
２．ＳＩＰサーバ：ＵＡ同士で行われるさまざまな通信処理の仲介役
ＳＩＰサーバは次の3つ；
プロキシ（代理）サーバ：ＵＡや他のプロキシサーバからのリクエストを受け取って、それを他のＵＡＳに転送したり、レスポンスを他のＵＡＣに送る。プロキシサーバはデータを生成しない。ＵＡからのリクエストを解釈し、必要な処理を行って、次の宛先へ送るだけ。端末同士の接続要求を代行するサーバ。
リダイレクトサーバ：リクエストの転送や中継は行わず、ＳＩＰリクエストをＵＡＣやプロキシサーバから受け取って、レスポンスを返す。
レジストラサーバ：登録サーバ。ＵＡＣから自分のアドレスなどの登録リクエストを受け付けるサーバ。
レジストラサーバは登録内容の変更や削除も行う。ＵＡＣの認証も行う。→ＳＩＰネットワークの不正利用を防ぐ。
３．ロケーションサーバ：レジストラサーバに登録されている情報を蓄積し、データベースサービスを提供する役目。
クライアントのＩＰアドレス、ＵＲＩ、サポート機能、プロキシサーバの位置、ＧＷの位置などのＤＢが蓄積されている。
ＳＩＰでは、ロケーションサーバへのアクセス方法は決められていない。

＜ＳＩＰのメソッドとレスポンスコード＞
ＳＩＰシグナリング：テキスト形式。
・メソッド：ＵＡクライアントからＵＡサーバに対するリクエスト。
通信を制御するためクライアントからサーバへ送られるコマンド。ＲＦＣドラフトなどで決められたものを使用。
例．
セッション確立するには「ＩＮＶＩＴＥ」
ＩＮＶＩＴＥの最終応答の受信を確認する「ＡＣＫ」
セッションを終了する「ＢＹＥ」
・レスポンス：それに対応して返ってくるレスポンス。
レスポンスコードとして3桁の数字がわりあてられている。
例．
100　「Ｔｒｙｉｎｇ」
200　「ＯＫ」

＜ＳＩＰセッション確立の流れ＞
すでにお互いのＩＰアドレスを知っている状態から開始（ＳＩＰサーバへの問い合わせは省略）；
１．発信側が受話器を上げて相手先電話番号をダイヤル
→ＩＮＶＩＴＥメッセージが相手にリクエストされる
２．リクエストを受けた着信側端末では、発信者へ向けて「呼び出し中」の意味の「180　Ｒｉｎｇｉｎｇ」レスポンスが返される
→発信者側の端末にも呼び出し音が流れ、着信者を現在呼び出していることがわかる
３．着信者が受話器を取って応答
→発信者へリクエスト成功として、「200　ＯＫ」レスポンスが送られる
４．発信者から着信者へ受信確認しましたという「ＡＣＫ」メソッドが送られる
→セッションが確立し、ＲＴＰによる通話ができるようになる
５．通話が完了し、発信者が受話器を置いて電話を切る
→着信側へ切断を意味する「ＢＹＥ」メソッドが送られる
６．受信した着信側は「200　ＯＫ」のレスポンスを返す

ＩＰアドレスが不明なとき；ＳＩＰプロキシサーバか仲介。
１．発信者がＳＩＰプロキシサーバへ通信したい相手先情報を含めた「ＩＮＶＩＴＥ」メソッドを送る
２．ＳＩＰプロキシサーバが相手先に接続要求「ＩＮＶＩＴＥ」を送る
＊ＳＩＰプロキシサーバが相手先アドレス情報を持ってないときは、知っているプロキシサーバの場所をリダイレクトサーバへ問い合わせる
３．接続相手が接続許可を出すと、はじめて端末同士の通話が開始

ＭＧＣＰ：ＧＷ同士の通信、一般公衆電話網との通信機能を規定。
1998,IETF. RFC2705
IＰ網と既存ＰＳＴＮとの接続に利用。
2者での通信のみ。

ＭＥＧＡＣＯ：ＳＩＰ対応のため、テキスト形式をサポートした、ＭＧＣＰの拡張版、
2000,IETF. RFC3015
3者以上の複数拠点通信可能。

--

以上、既知のプロトコルや言葉の正確な定義や動作をわかりやすくまとめてあり、読みやすい本です。

続きはまた。

課題

範囲の広さに辟易です。

ＢＯＳＯＮでは大量の問題をこなすのに精一杯。

ＢＯＳＯＮも踏まえて、当面の課題をあげておきます；

・ＣＣＭ－－Ｕｎｉｔｙ－－ＶｏｉｃｅＭａｉｌサーバ

シリアルライン接続（ＣＣＭ冗長時のＳｐｌｉｔｔｅｒ接続）、インターフェイス、プロトコル、トラブルシュート

Ｌｏｔｕｓ、ＭＳ　ＡＤ、Ｗｉｎ２ｋ、Ｅｘｃｈａｎｇｅとの統合時の制約

・ＭＧＣＰ，ＳＩＰ、Ｈ．３２３、ＳＣＣＰ

接続条件、ＴＣＰ／ＵＤＰポート番号、マルチキャストアドレスなどを整理

・ＩｎＬｉｎｅＰｏｗｅｒ

Cat Native IOSでの制約、Ｃａｔ６ｋ、４ｋなど機種依存制約

ケーブリング、ピンアサイン、ＶＬＡＮとの関係

・ＰＢＸトランク接続

設定、トラブルシュート

・QoS

CBWFQ,LLQ,IP RTP Priority

デフォルト設定、ＰＱは１つ、％指定や帯域の設定

・ＳＲＳＴ

ＣＣＭ、ＣＭＥとの連携、トポロジ、設定コマンドとモード

・ＤｉａｌＰｌａｎ、ＲｏｕｔｅＬｉｓｔ、、、設定とそのモード

・connection plar

・ＩＰＰｈｏｎｅとアナログ電話機の間の呼の確立設定

。。。

あげるときりがないけど、ＣＣＯでトポロジを見ながら、一つ一つ確認しましょう。

ＣＣＩＥって設定ばっかりなイメージで、どちらかというとサポート部隊のための資格に思っていたのですが、結構設計にも役に立ちそうで、実務に直結しそうです。

がんばろう！

CCIE Voice 2.0 筆記対策 リンク vol2

4.Unity
Cisco Unity は、ボイスメールやユニファイド メッセージングといった先進的な統合型コミュニケーション サービスを実現するユニファイド コミュニケーション サーバです。単一ディレクトリをデータ ネットワークと共有することにより、Cisco Unity では、電子メールや音声メール システムなど、さまざまなアプリケーションが保持するユーザ アカウント情報の重複が解消されます。 Cisco Unity では、Microsoft Windows 2000 または Microsoft Exchange のアカウント ディレクトリをインポートして、加入者リストを自動作成する機能により、初期インストールの時間を短縮することもできます。 Cisco Unity のアプローチにより、すべてのメッセージは中央集中的に保存、管理、および制御が行われるため、サポートや保守に費やされる時間を大幅に削減することができ、LAN 上のトラフィックも最小限に抑えられます。

Integration
MWI, SMDI
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/uc/cu/tgld3/chapter08/7857_01_8.shtml
MWI は、ユーザの電話にあるランプ、点滅する LCD パネル、または特別なダイヤル トーンのことで、ユーザにボイス メッセージの着信を知らせます。インジケータの種類は、ユーザが使用している電話システムおよび電話によって異なります。

MWI は、電話やポケットベルを呼び出したり、電子メール メッセージを送信したりして、新規ボイス メッセージをユーザに通知するメッセージの到着通知とは異なります。

MWI がオン/オフになる場合

次の 2 つの主要イベントによって、Cisco Unity は MWI をアクティブまたは非アクティブにします。

･ 発信者がユーザにメッセージを残すと、Cisco Unity は、そのユーザの電話の MWI をアクティブにするよう電話システムに通知します。
･ ユーザがメッセージを聞くと、Cisco Unity は、その電話の MWI を非アクティブにするよう電話システムに通知します。
次の 2 つの追加イベントによって、Cisco Unity は MWI をアクティブまたは非アクティブにします。

･ ユーザが新規メッセージを聞かずに削除した場合や別のフォルダに移動した場合、Cisco Unity は、その電話の MWI を非アクティブにするよう電話システムに通知します。
･ Cisco Unity Telephony Integration Manager（UTIM）の［プロパティ］タブの［今再同期化を行う］をクリックするなど、MWI を手動で再同期化すると、Cisco Unity は、Data Object Hierarchy（DOH）に問い合せてすべての電話の MWI のステータスを判別し、すべての MWI をリセットします。
ただし、次の条件下では、ユーザが新規メッセージを聞いた後も MWI はアクティブのままになります。

･ 他にもまだ聞いていないメッセージがある場合。新規メッセージをすべて聞くと、MWI はオフになります。
･ ユーザが元のメッセージを聞いているときに新規メッセージが到着した場合。新規メッセージをすべて聞くと、MWI はオフになります。
･ ユーザが電話でメッセージの一部のみを聞き、そのメッセージを最後まで聞かないうちに電話を切るか次のメッセージへスキップした場合。
･ メッセージ ストアのあるサーバがオフラインで、メッセージが Unity Messaging Repository（UMR）に保存されている場合。
･ （ユニファイド メッセージのみ）Lotus Notes の Inbox で、ユーザが確認済みのメッセージに未読のマークを付けた場合。
･ （ユニファイド メッセージのみ）ユーザが電子メールの受信ボックスをオフライン モードで使用してメッセージを聞いた場合。
･ （ユニファイド メッセージのみ）ユーザが Lotus Notes の Inbox をオフライン モードで使用してメッセージを聞いた場合。Lotus Notes の Inbox が Domino サーバとの複製を実行すると、MWI はオフになります。
次の場合、MWI はアクティブになりません。

･ （ユニファイド メッセージのみ）電子メール メッセージが到着した場合。Cisco Unity はボイス メッセージのみを監視します。
･ ファックスが到着した場合。Cisco Unity はボイス メッセージのみを監視します。
･ （ユニファイド メッセージのみ）受信証明が到着した場合。Cisco Unity はボイス メッセージのみを監視します。
･ （ユニファイド メッセージのみ）インボックス ルールによってボイス メッセージが自動的に別のフォルダへ移動された場合。Cisco Unity はインボックスのみを監視します。
･ メッセージ ストアのあるサーバがオフラインで、メッセージが UMR に保存されている場合。
･ （メッセージ ストアの停止が発生した場合）オフラインのメッセージ ストアがオンラインに戻った後、停止中 UMR に保存されていたメッセージは、メッセージ ストアに移動されますが、MWI は手動でリフレッシュするまで、アクティブ化されません。
MWI がオン/オフになる仕組み

電話システムは、MWI をオンにするコードまたは内線と MWI をオフにする別のコードまたは内線でセットアップされています。Cisco Unity は、コードを送信するか内線をダイヤルすることによってユーザの MWI をオン/オフにします。

［プログラム］ >［Unity］ >［Unity Telephony Integration Manager］をクリックして、Cisco Unity Telephony Integration Manager（UTIM）の Cisco Unity にこれらのコードまたは内線を入力します。

4 つの Cisco Unity コンポーネント（Domino モニタ、Notifier キュー、Notifier、および Media Interface Unit（MIU））が相互作用して、MWI をオン/オフにします。
Cisco CallManager は、クラスタ内のサーバ（理想的には、パブリッシャ）で実行される Cisco Messaging Interface（CMI）サービスか、Cisco VG248 Analog Phone Gateway のどちらかを通じて、
BellCore/Telcordia Simplified Message Desk Interface（SMDI）プロトコルを完全にサポートします。VG248 を使用する場合、VG248 自体（Cisco CallManager サーバではなく）が、SMDI リンクを直接サポートします。

シリアル連動（SMDI 連動または MCI 連動とも呼ばれます）の場合、回線交換電話システムは、通話情報、および MWI アクティブ化要求の伝送に RS-232 シリアル ケーブルを使用します。シリアル ケーブルを使用して、電話システムのシリアル ポートを Cisco Unity サーバのシリアル ポートに接続します。電話システムによっては、シリアル ケーブルへの接続にモデムや PBXLink ボックスなどのハードウェアが必要になることがあります。

この連動では、ボイス接続の伝送にアナログ回線または T1 デジタル回線（電話システムによる）も使用します。これらの回線を使用して、電話システムのポートを Cisco Unity サーバに装着されているボイス カードのボイスメール ポートに接続します。

DPA
Cisco Digital PBX Adapter（DPA）は、両方のデジタル PBX ポートとデジタル電話機をエミュレートします。DPA には、次の 2 つの製品があります。

DPA 7630 for Lucent/Avaya G3：Lucent 7405 電話機をエミュレートします
DPA 7610 for Nortel Meridian 1：Nortel 2616 電話機をエミュレートします
どちらの製品も、Avaya/Octel 200/300 Serenade および 250/350 Aria 音声メール システム専用に設計され、単一または二重統合モードで配置できます。

DPA を使用する場合、Avaya/Octel 350 などの単一音声メール システムを、複数の Cisco CallManager クラスタ間で共用できます。その場合、メッセージ待機インジケータ（MWI）ポートは、基本的に、DPA 間でデイジーチェーン接続されます。

Call Handlers
コール ハンドラは、着信の応答、あらかじめ録音してあるガイダンスによる応答および情報とオプションの提供、電話の転送、およびメッセージの録音を行います。コール ハンドラは Cisco Unity の基本的なコンポーネントです。コール ハンドラのプランは簡単です。定義済みの Cisco Unity コール ハンドラを使用したり、新しいコール ハンドラをいくつでも作成したりできます。コール ハンドラは、次のように使用できます。

自動受付として：コール ハンドラを人間のオペレータの代わりに使用できます。グリーティングを再生したり発信者の入力に応答したりすることで、着信に応答したり直接通話したりできます。自動受付で、オプション メニュー（たとえば、「販売については 1 を、サービスについては 2 を、営業時間については 3 を押してください」）を提供できます。
録音済みのオーディオ テキストの提供：コール ハンドラを使用して、ユーザが頻繁に要求する情報（たとえば、「通常の営業時間は月曜日から金曜日の午前 8 時から午後 5 時までです」）を提供できます。
メッセージ受信者として：組織用のメッセージ（たとえば、「カスタマー サービス担当者は現在席を離れております。お名前、電話番号、アカウント番号をお知らせください。早急に当社から連絡いたします」）の受信にコール ハンドラを使用できます。
電話の転送：コール ハンドラを使用して、発信者をユーザに転送（たとえば、しばらくしてから、テクニカル サポート コール ハンドラにかかってきた電話を、通話が可能な担当者の携帯電話に直接転送できます）、別のコール ハンドラに転送できます。
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/uc/cu/sag3/chapter22/SAG_0200.shtml#83732

Unified Messaging
Lotus Domino 対応の Cisco Unity? Unified Messaging は Cisco IP 通信システムの不可欠なコンポーネントで、エンタープライズ規模の組織に対して最高クラスのユニファイド コミュニケーション ソリューションを提供します。パワフルなユニファイド メッセージング（電子メール、音声、および FAX メッセージがすべて 1 つのインボックスに送信される）とインテリジェントな音声メッセージング（高度な機能を提供するフル機能のボイスメール）を活用して、組織全体のコミュニケーションを改善し、生産性を向上させて、カスタマー サービス機能を強化します。

Cisco Unity Unified Messaging は、先進的な統合型コミュニケーション サービスを提供し、これらをユーザが毎日使用するデスクトップ アプリケーションと統合します。Lotus Domino 対応の Cisco Unity Unified Messaging は、シスコ システムズと IBM/Lotus のコラボレーションの成果であり、Lotus は Notes と iNotes Web Acess クライアントを一部変更し、Cisco Unity Unified Messaging とのスムーズな相互運用を可能にしました。

これまで、電子メール、音声、および FAX メッセージは、それぞれ異なるメディアを使用し、別々の場所に配信されていました。電話がボイス メッセージにアクセスするための唯一の手段であり、受信した順番でしかメッセージを再生できませんでした。また FAX は、最も近くの FAX 機から手作業で回収する必要がありました。

Cisco Unity Unified Messaging は Lotus Notes の電子メール クライアントとシームレスに統合し、電子メール、音声、および FAX の全メッセージを社内からも社外からも簡便に処理できます。

ユーザは、直感的に使用できるインターフェイスによって、電子メール、音声、および FAX のすべてのメッセージに、デスクトップの PC から簡単にアクセスできます。アイコンは、各メッセージのタイプをシンプルにビジュアル表示します。それぞれのメッセージが 1 つのインボックスに配信されるため、すべてのコミュニケーションの数、タイプ、およびステータスを一目で把握できます。マウスをクリックするだけで、メディア タイプに関係なく、メッセージへの返信や転送を行ったり、パブリックまたはパーソナルの Lotus Notes フォルダにメッセージを保存できます。

Cisco Unity Unified Messaging の text-to-speech 機能により、ユーザは電話を使って自分のメッセージに関する情報を取得できるだけでなく、電子メール メッセージのテキスト部分を聞くこともできます。そしてボイス メッセージを使って応答し、FAX サーバの機能によっては、電子メール、添付、および受信した FAX メッセージを近くの FAX 機で印刷できます。

VPIM
Cisco Unity は、Voice Profile for Internet Messaging（VPIM）プロトコルをサポートしています。これによって、異なるボイスメール システム間で、ボイスメール、ファックス メッセージ、およびテキスト メッセージをインターネット経由または任意の TCP/IP ネットワーク経由で送受信できます。VPIM は、シンプル メール転送プロトコル（SMTP）と Multi-Purpose Internet Mail Extension （MIME）プロトコルに基づいています。
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/cu/nwf/chapter06/NET_0550.html#65170

5.IOS IP Telephony Skills
SRST
http://www.cisco.com/japanese/warp/public/3/jp/product/hs/iptel/srstel/prodlit/srstd_ds.shtml
When a WAN link fails, the Cisco IP phones detect that they are no longer receiving keep-alive packets from the Cisco CallManager (Figure 4). The Cisco IP phones then register with the router, which queries the phone about its configuration and then autoconfigures itself. In this instance, the Cisco CallManager SRST software is automatically activated and builds a local database of all Cisco IP phones attached to it (up to its stated maximum). The Cisco IP phones are configured to query the router as a backup call processing source when the central Cisco CallManager does not acknowledge keep-alive packets. The Cisco CallManager SRST router now performs call setup and processing, call maintenance, and call termination. The Cisco IP phones indicate on their displays that they are in "CM Fallback Operating Mode" for the duration of the failure.
http://www.cisco.com/en/US/products/sw/voicesw/ps2169/products_white_paper09186a008009264e.shtml
When the WAN link is restored, the Cisco IP phones detect keep-alive packets from the central Cisco CallManager and revert to it for primary call setup and processing (Figure 5). As Cisco IP Phones re-home to the Cisco CallManager, the SRST router purges its call-processing database and reverts to standby mode. Calls in progress are not interrupted because they are managed by the router gateway function. Phones in use during WAN link recovery re-home to the Cisco CallManager after they return to idle state.

CME
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/cme/cmesag1/chapter02/cme32set.shtml
CUE
http://www.cisco.com/univercd/cc/td/doc/product/voice/unityexp/rel2_1/rncue21.htm

6.IP IVR/IPCC Express
http://www.cisco.com/warp/public/78/faq-ipcc-exp-ipivr.html
http://www.cisco.com/japanese/warp/public/3/jp/product/hs/iptel/ipccx/
http://www.cisco.com/japanese/warp/public/3/jp/product/hs/iptel/ipccx/prodlit/ccexp_ds.shtml

Speech Recognition 自動音声認識
ICD Functions
http://www.cisco.com/warp/public/788/AVVID/icd_cra.html
Database Lookups
VXML

7.Security
DHCP Snooping
DHCPスヌーピング
DHCPスヌーピングは、信頼できないDHCPメッセージのフィルタリングおよびDHCPスヌーピング バインディング テーブルの構築および維持により、ネットワーク セキュリティを提供するDHCPのセキュリティ機能です。信頼できないメッセージとは、ネットワークまたはファイアウォール外部から受信したメッセージで、ネットワーク内でのトラフィック攻撃の原因となるものを指します。

DHCPスヌーピング バインディング テーブルには、MAC（メディア アクセス制御）アドレス、IPアドレス、リース時間、バインディング タイプ、VLAN番号、およびスイッチ上の信頼できないローカル インターフェイスに対応するインターフェイス情報が格納されています。信頼できるインターフェイスに相互接続しているホストに関連する情報は格納されていません。信頼できないインターフェイスとは、ネットワークまたはファイアウォール外部からメッセージを受信するように設定されたインターフェイスを指します。信頼できるインターフェイスとは、ネットワーク内からのメッセージのみを受信するように設定されたインターフェイスです。

DHCPスヌーピングは、信頼できないホストとDHCPサーバ間でファイアウォールに似た機能を果たします。また、エンドユーザに接続する信頼できないインターフェイスと、DHCPサーバまたは他のスイッチに接続する信頼できるインターフェイスとを区別する方法も提供します。

http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/sw/cat37/3750sscg/chapter19/19_swdhcp82.shtml

MCS OS Hardening
Phone hardening options allow you to configure settings that restrict phone features and functionality for security purposes.

As part of phone hardening, you can disable user access to Cisco CallManager User Options and some phone settings (including those settings that are normally accessible via the Settings button). Because disabling access to these features will directly impact end users, you should advise affected users about the restrictions.

Phone Authentication and Encryption
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/ipp/7905ag/chapter06/7905SCH6.html#33518
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/cu/sagld1/chapter08/SAG_0055.html

TCP/UDP Port List

Firewalls and Application Layer Gateways (ALG)
http://www.cisco.com/warp/public/110/voippix.html
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719

!--- Fixup protocol required for H.323.

fixup protocol http 80
fixup protocol ils 389
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060

!--- Fixup protocol required for SIP.

fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
names
access-list 101 permit tcp host 100.1.1.2 host 100.1.1.5 eq h323

!--- Permitting inbound H.323 calls.

access-list 101 permit tcp host 100.1.1.2 host 100.1.1.5 eq 5060

!--- Permitting inbound SIP calls.

pager lines 24
mtu outside 1500
mtu inside 1500
ip address outside 100.1.1.1 255.255.255.0
ip address inside 192.168.0.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
pdm history enable
arp timeout 14400
static (inside,outside) 100.1.1.5 192.168.0.2 netmask 255.255.255.255 0 0

!--- Static used to demonstrate NAT.

access-group 101 in interface outside

NAT

8.Infrastructure Protocols
DNS
http://www.cisco.com/support/ja/788/AVVID/cm301_dns.shtml

TFTP
http://www.cisco.com/support/ja/788/AVVID/dhcp_tftp_problems.shtml
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/cm/sg1/chapter10/a02svcs.html#37503
デバイスのタイプに応じて、次のいずれかの方法で IP Phone とゲートウェイによる TFTP サーバ IP アドレスの取得を可能にします。

ゲートウェイおよび電話機の DHCP カスタム オプション 150 を使用する。
シスコはこの方式をお勧めします。この方式では、TFTP サーバの IP アドレスをオプション値として設定しています。

ゲートウェイおよび電話機の DHCP オプション 066 を使用する。
TFTP サーバの DNS ホスト名または IP アドレスをオプション値として設定できます。

ゲートウェイおよび電話機による CiscoCM1 の照会を行う。
DNS によって、この名前を TFTP サーバの IP アドレスに変換する必要があります。このオプションは拡張性がないため、お勧めしません。

NTP
http://www.cisco.com/japanese/warp/public/3/jp/service/tac/788/voip/cdr_logging-j.shtml

Inline Power: Cisco and 802.3af
http://www.cisco.com/japanese/warp/public/3/jp/product/hs/switches/cat6500/prodlit/poec6500_ds.shtml
シスコ先行標準インライン パワーの実装
PoEの実装には、2つの要素が密接に関連しています。スイッチのライン カードであるPower Sourcing Equipment（PSE）と、PSEから電源を受け取る受電装置です。受電装置には、IPフォン、ワイヤレス アクセス ポイント、IPカメラなどがあります。PSEには、必要な-48 Vの電力を生成できる電源装置が必要です。電力は、データと共通のツイストペア ケーブル（ピン1、2、3、および6）で供給されます。これは、PSEエンド スパンとも呼ばれます。このアプリケーション ノートでは取り上げていないもう1つの方法に、PSEミッドスパンと呼ばれるものもあります。PSEは、パッチ パネル タイプの装置で、スイッチと受電装置の間に設置します。PSEミッドスパンからの電力は、未使用のイーサネット ピン（4、5、7、および8）を使用して受電装置に送られます。

シスコでは、2000年からPoEソリューションを出荷しており、現在では1600万ポート以上のIP PoEポートが使用されています。現在出荷されているシスコ ソリューションでは、特殊なトーンを使用する差動検出方式が採用されています。PSEは、送信（TX）ペアを介してユニークなFast Link Pulse（FLP）を送信します。接続装置がPoEに対応している場合、このFLPがスイッチに返されます。この時点で、スイッチは、接続装置がPoEに対応していることを認識し、デフォルトの電源割り当てに基づいてこの装置に電源を供給します。Cisco IP Phoneおよびワイヤレス アクセス ポイントは、Cisco Discovery Protocol（CDP）を使用して、さらに特定の装置の電源要件を取得します。現在のデフォルト割り当ては6.3 Wです。シスコ先行標準の実装では、ポートの物理レイヤ（PHY）のリンク信号を使用して、ポートをシャットダウンします。リンクが失われると、ポートの電力が停止されます。

IEEE 802.3af規格では、スイッチベースのPSEは、10/100/1000BASE-Tの信号ペア、または10/100BASE-Tの予備のペアを使用するように指定されています。最大電力は、PSEポートあたり15.4 Wです。この規格では、電流が350 mAに制限されており、受電装置に供給される最大電力は、ケーブル距離が原因となる電力損失によって、12.95 Wになります。受電装置は、最大入力電源に基づいて任意で分類することもできます。Cisco PSEは、この任意の分類をサポートしています。

この仕様におけるPSEの主な機能として、受電装置の検出、受電装置の分類（任意）、リンクへの電力供給（受電装置が検出された場合のみ）、電力が不要になった場合の検出レベルへの変更があります。この仕様では、受電装置は1秒以内に通電する必要があります。これは、受電装置の検出用で500ミリ秒、受電装置の分類用で10～75ミリ秒、電源投入用で400ミリ秒に分割されます。

PSEは、ケーブルで－2.8～－10 Vの電圧を適用して受電装置を検出し、25 kオームのシグニチャ抵抗を探します。ツイストペア ケーブル間でこのレベルの抵抗を保持するには、仕様に準拠した受電装置が必要です。Cisco Catalyst 6500ハードウェアは、シスコ インライン パワーとIEEE 802.3af PoEの両方をサポートしており、両方のプロトコルの検出が並行して行われます。シスコ製の装置の検出が報告されると、IEEE検出の結果が出るまで待機します（約1秒）。1秒以内にIEEE装置の検出が報告されると、その装置はIEEE受電装置とみなされます。それ以外の場合は、シスコ製の受電装置とみなされます。

PSEは－15.5～20 Vの固定電圧で、受電装置への電源を100 mAに制限しているため、受電装置を分類します。これは、電流測定方式とも呼ばれます。受電装置のコントローラは、分類の際中に負荷電流を回線にアサートします。これをシグネチャといいます。次に、PSEは受電装置の負荷電流を測定して、適切な分類と受電装置の電力要件を決定します。

9.Application Protocols
IP Multicast
Video
Fax and Modem
http://www.cisco.com/support/ja/788/voip/T37-store-forward-fax.shtml
http://www.cisco.com/en/US/products/sw/iosswrel/ps1834/products_feature_guide09186a008008015d.html
http://www.cisco.com/en/US/products/sw/iosswrel/ps1834/products_feature_guide09186a0080080475.html
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t11/faxapp/

10.Operations and Network Management
http://www.cisco.com/japanese/warp/public/3/jp/service/tac/788/AVVID/csaaipm-j.html

CCIE Voice 2.0 筆記対策 リンク vol1

CCIE Voice 2.0

1.CallManager
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/cm/ag/
Codecs/Regions
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/cm/ag1/chapter07/07_b02regio.HTML

Redundancy (CM Groups/Device Pool)
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/cm/ag/chapter04/b02cmgrp.html
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/cm/ag/chapter08/b02devpl.html
Dial Plan: Gatekeeper, SIP Proxy, Route Patterns, Route Groups, Route Lists, Digit Manipulation and Digit Analysis
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/cm/cmidp/chapter01/dpdeploy.shtml

Music On Hold
http://www.cisco.com/support/ja/788/AVVID/moh_faq_5215.shtml
Conferencing (Audio and Video)
http://www.cisco.com/support/ja/788/AVVID/meetme.shtml
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/cm/sg5/chapter21/7135_01_21.shtml
Transcoding
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/cm/sg5/chapter22/7135_01_22.shtml
Media Termination Points
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/cm/sg5/chapter25/7135_01_25.shtml#15788
CM Features: Extension Mobility, IPMA, Attendant Console, Call Park, Pickup
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/cm/kosg4/chapter09/7209_01_9.shtml

Phone Settings

CTI, TAPI and JTAPI Interface
http://www.cisco.com/japanese/warp/public/3/jp/service/manual_j/ipt/ipts/rndg1/chapter12/12_333cti.html

2.QoS
Link Efficiency: LFI, MLPPP, FRF.12, cRTP, VAD
Multilink PPP (MLPPP) is a method of splitting, recombining, and sequencing datagrams across multiple logical data links.

http://www.cisco.com/en/US/tech/tk652/tk698/technologies_configuration_example09186a0080094af9.shtml
conf ex. frame-relay fragment 80

Classification and Marking
Congestion Management: Queuing

CAC: RSVP, GK http://www.cisco.com/en/US/products/ps6611/products_white_paper0900aecd8031daca.shtml
RSVP can now be used to implement Call Admission Control (CAC) and to signal a desired QoS that will provide good quality through WAN links, even in the presence of congestion.
The first problem was that CAC could not be implemented with RSVP because the reservation process was not synchronized with the voice-call signaling. RSVP was not supported on ATM and shaped Frame Relay PVCs.
H323 Slow Connect Synchronization with RSVP
12.1(1)T

H323 Slow and Fast Connect Synchronization with RSVP
12.1(5)T

RSVP Support for LLQ
12.1(3)T

RSVP for Frame Relay PVCs
12.1(5)T

RSVP for ATM PVCs
12.2(1)T

MGCP VoIP Call Admission Control
12.2(8)T

SIP Gateway Support of RSVP
12.2(8)T

Four mechanisms were introduced in Cisco IOS software to handle resource-based CAC. The first method (named Public Switched Telephone Network [PSTN] Fallback) relies on network probing to measure delay, jitter, and loss to estimate the potential voice impairment (Calculated Planning Impairment Factor [ICPIF], see ITU G.113) that the call will experience. Several thresholds can be defined to reject calls through an IP network that would be considered congested. A second approach allows users to define CAC based on local gateway resources (CPU, memory, and number of calls.) You can configure thresholds that will trigger different actions (for example, hairpin call, reject call, or play a message). The third mechanism requires an H.323 gatekeeper to do bandwidth management and to control the bandwidth that calls use (a maximum amount is configured). The fourth alternative is to use RSVP, which is discussed in more detail in the following sections. Table 2 shows the versions of Cisco IOS software that introduce or will introduce the different methods of CAC.
CAC Based on Network Probing (PSTN Fallback)
12.1(3)T

CAC Based on Local Resources (CPU/memory/number of calls)
12.2(2)T

CAC Based on Gatekeeper Bandwidth Management
12.0(3)T

CAC Based on RSVP
12.1(5)T

Using RSVP for VoIP CAC requires the synchronization of the call setup signaling and the RSVP signaling. This guarantees that the called-party phone rings only after the resources for the call have been reserved successfully. A voice call will trigger two RSVP reservations because the reservation and admission control mechanisms provided by RSVP are unidirectional. Each voice gateway is responsible for initiating and maintaining one reservation toward the other voice gateway. CAC for a VoIP call fails if at least one of the reservations fails.

the TGW lets the call setup continue and sends an H.323 ALERTING message to the OGW once it is notified that the called side is in alerting state. A normal disconnect is initiated by sending an H.323 RELEASE COMPLETE message after the call is connected. At that point, the gateways tear down their reservations by sending RSVP PATH TEAR and RESV TEAR messages.

A voice gateway can be configured to take different actions if at least one RSVP reservation fails. The voice gateway can report the call failure to the user or the switch that delivered the call, the call can be rerouted through another path, or the call can be connected with best-effort QoS. This last behavior is possible because the TGW knows what QoS is acceptable for the call from its own configuration and the value included by the OGW in the H.323 SETUP message. If the TGW and the OGW are requesting a non best-effort QoS and at least one reservation fails, the call will proceed as best-effort only if the OGW and the TGW are willing to accept best-effort service. Call release and call rerouting are possible if one of the two voice gateways will not accept best-effort service. If the gateway is configured to reject the call and report the failure, a fast busy tone is generated on Channel Associated Signaling (CAS) trunks and analog lines. On common channel signaling (CCS) (Primary Rate Interface [PRI]) trunks, a Q.931 DISCONNECT message with a cause "QoS unavailable" (49) is generated. Figure 2 shows the details of a call that is rejected because the reservation initiated from the TGW failed.

Three basic steps are needed to configure CAC for VoIP calls using RSVP. First, the voice gateway has to be configured to request a particular QoS via RSVP.
Second, RSVP should be enabled on all links that are traversed by voice packets and where congestion is likely to happen.
Third, synchronization between RSVP and the call signaling needs to be enabled.
The req-qos and acc-qos commands control whether an RSVP reservation is initiated for a call, the type of QoS requested, and how strict CAC should be.
The ip rsvp bandwidth command enables RSVP on an interface and defines RSVP parameters for admission control on that interface.
The call rsvp-sync command, which is enabled by default, instructs the router to synchronize the RSVP reservation with the call signaling.
The following sample configuration shows a complete voice gateway configuration that highlights the commands for configuring CAC using RSVP. The voice gateway can act as an OGW and TGW with this configuration. Voice signaling is not prioritized in this case.

hostname LongBay
!
isdn switch-type primary-ni
call rsvp-sync
!
controller T1 1/0
framing esf
linecode b8zs
pri-group timeslots 1-24
!
interface Ethernet0/0
ip address 10.0.152.254 255.255.255.0
!
interface Serial0/0
bandwidth 1536
ip address 10.10.1.1 255.255.255.0
encapsulation ppp
ip tcp header-compression iphc-format
ip rtp header-compression iphc-format
ip rsvp bandwidth 1152 24
!
interface Serial1/0:23
no ip address
no logging event link-status
isdn switch-type primary-ni
isdn incoming-voice voice
no cdp enable
!
ip route 0.0.0.0 0.0.0.0 10.10.1.2
!
voice-port 1/0:23
!
dial-peer voice 100 pots
destination-pattern 2......
no digit-strip
direct-inward-dial
port 1/0:23
!
dial-peer voice 300 voip
destination-pattern 3......
session target ipv4:10.77.39.129
req-qos guaranteed-delay
acc-qos guaranteed-delay
!
line con 0
line aux 0
line vty 0 4
!
end

Traffic Policing and Shaping

LAN QoS
Auto QoS:Cat2950EI/3550/4500/6500
Cisco26/36/37/7200 12.2.15
Cisco AutoQoS automates consistent deployment of QoS features across Cisco routers and switches.
--
Cisco AutoQoS performs the following functions:
WAN

? Automatically classify RTP payload and VoIP control packets (H.323, H.225 Unicast, Skinny, SIP, MGCP)

? Build service policies for VoIP traffic that are based on Cisco Modular QoS CLI (MQC)

? Provision Low Latency Queuing (LLQ)-Priority Queuing for VoIP bearer and bandwidth guarantees for control traffic

? Enable WAN traffic shaping that adheres to Cisco best practices, where required

? Enable link efficiency mechanisms, including such as Link Fragmentation and Interleaving (LFI) and RTP header compression (cRTP) where required

? Provide SNMP and SYSLOG alerts for VoIP packet drops

LAN

? Enforce the trust boundary on Cisco Catalyst switch access ports and uplinks/downlinks

? Enable Cisco Catalyst strict priority queuing (also known as expedite queuing) with weighted round robin (WRR) scheduling for voice and data traffic, where appropriate

? Configure queue admission criteria (Map CoS values in incoming packets to the appropriate queues)

? Modify queue sizes and weights where required
--

CM CAC and GK. Hub and Spoke/Fully Meshed MPLS

CiscoWorks QoS Policy Manager (QPM) is a key enabler of end-to-end QoS for IP networks. QPM 3.0 is a QoS management tool that combines centralized traffic monitoring with network-wide configuration of differentiated services for voice, video, and data applications by leveraging the intelligent Cisco infrastructure.

3.Telephony Protocols http://www.cisco.com/en/US/tech/tk1077/tech_tech_notes_list.html

SCCP
Cisco 7940/7960 IP phones can support either the Skinny Call Control Protocol (SCCP) to run with Cisco CallManager, the Session Initiation Protocol (SIP; refer to RFC2543 ), or the Media Gateway Control Protocol (MGCP), but not more than one simultaneously. This is possible because they load different firmware versions on bootup. This functionality is transparent to the end user, and you enable it through changes to the basic text-based configuration files that the phones download from a Trivial File Transfer Protocol (TFTP) server.

RTP & cRTP

MGCP
http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a00801da84e.shtml
Media Gateway Control Protocol (MGCP) is a plain-text protocol used by call-control devices to manage IP Telephony gateways.
MGCP (defined under RFC 2705 ) is a master/slave protocol that allows a call-control device (such as Cisco CallManager) to take control of a specific port on a gateway. This has the advantage of centralized gateway administration and provides for largely scalable IP Telephony solutions. With this protocol, the Cisco CallManager knows and controls the state of each individual port on the gateway. It allows complete control of the dial plan from Cisco CallManager, and gives CallManager per-port control of connections to the public switched telephone network (PSTN), legacy PBX, voice mail systems, plain old telephone service (POTS) phones, and so forth. This is implemented with use of a series of plain-text commands sent over User Datagram Protocol (UDP) port 2427 between the Cisco CallManager and the gateway.
The Cisco 7960 IP Phones in this example use the Skinny Call Control Protocol (SCCP) to communicate with the Cisco CallManager. The actual voice data is transferred through Real-time Transport Protocol (RTP) directly between the two devices. MGCP is used by the Cisco CallManager only to control the gateway.

SIP
http://ftp.isi.edu/in-notes/rfc2543.txt
The Session Initiation Protocol (SIP) is an application-layer control
protocol that can establish, modify and terminate multimedia sessions
or calls. These multimedia sessions include multimedia conferences,
distance learning, Internet telephony and similar applications. SIP
can invite both persons and "robots", such as a media storage
service. SIP can invite parties to both unicast and multicast
sessions; the initiator does not necessarily have to be a member of
the session to which it is inviting. Media and participants can be
added to an existing session.

H323
http://www.cisco.com/japanese/warp/public/3/jp/service/tac/788/voip/gk_bw_mgmt-j.html

Analog and TDM Signaling
http://www.cisco.com/support/ja/index/Technologies/Telephony_Signaling_268436023.html

インターネットQoS No.2

2．ネットワークへのポリシーの実装

トラフィック管理ポリシーの作成→ネットワークの安定性確保→サービス品質達成

Oversubscription=過剰収容：ネットワーク中のあるポイントで過剰収容しても、慢性的な輻輳は避けられる＝非常によく用いられる
ＶＳ
Ｏｖｅｒｅｎｇｉｎｅｅｒｉｎg=過剰設計：要求される帯域の総和が提供可能な帯域の総和をこえることがないようにネットワークを設計すること。
→常にネットワークの帯域に余裕があるので、ＱｏＳの差別化を検討する必要がない
　しかし、実用性・経済性を考えると、これはまれ。

ポリシーの階層的実装：Ｃｉｓｃｏ3階層モデルで考えて、大規模ネットワークのポリシー実装は可能な限り下位層で行うべき。（トラフィックやルートのフィルタリング、トラフィック課金、アクセス制御、帯域管理、優先度ルーティングなど）

トラフィック輻輳がディストリビューション、コア層での主要懸念事項なら、ＲＥＤやＷＲＥＤをディストリビューション、コア層で検討すべき

→コア層への実装と比べて全体の性能への影響が少ない＋コア層の安定性維持

ステートレスキューイング；
入力パケットレートが出回線の要領を超えた場合のみ実効が生じる。
→低負荷時は、トラフィック性能に影響なし
△非効率：全ルータにルールを定義、個々のパケットがルールに適合するかどうかをチェック。コアにも実装必要。もしルールがキューイング動作の多くの例外を含む場合、個々のパケットへのスイッチング動作の負荷は劇的に増加。
→コアに高価なスイッチングハードウェア必要、スイッチング時間（レイテンシ）増加。
→×大規模コアネットワークに適用できない
×運用管理のオーバヘッドが増大し、矛盾のあるルール設定につながりやすい

改良アプローチ；
アクセスルータがパケットに割り当てられたＱｏＳサービスレベルを反映するようパケットヘッダのフィールドを変更（マーキング）。ＮＷに流入する全パケットにヘッダのマッチングルールを適用する。
＝ルールに従い、ＩＰ優先制御ヘッダフィールドに要求されたＱｏＳレベルを設定。

第3のアプローチ；
パス上のルータ内部にデータフロー状態を定義し、定義されたデータフローの一部である各パケットにマーク付け。フローの特性を表示するディスカバリパケットが最初にネットワークを通過し、応答のＡＣＫが、パス上の全ルータがそのフローをサポートすることを確認する。

☆いずれにしても、効いてることを確認できないと意味がない。

ＢＧＰ；
ＡＳ間のルーティングポリシーの実装
ＢＧＰコミュニティ属性：ルート広告グループを、あるＡＳ特有の共通した属性でさらにグループ化する。コミュニティ属性は、バックアップまたは現用パスを定義する場合、パスの広告範囲を定義する場合、他のルータのアクションを起動する場合（ＩＰ　ＴｏＳフィールドや優先度フィールドを書き換えるためのエントリ条件としてコミュニティ属性を利用し、その結果ＱｏＳ機構の遠隔起動が行われる）に使
用。
ＢＧＰローカル優先度属性：ＡＳ内で有効。ＡＳ内に2つ以上の出口があるとき優先されるＧＷを指定。
MED属性：管理者が隣接ＡＳへ優先したいリンク（入力方向）を伝える。

非対称ルーティング：ＲＳＶＰでは正常動作に対称ルーティング必要

ＱｏＳの測定法：選択したＱｏＳの実効性の測定
・ＴＲＥＮＯ：www.psc.edu/~pscnoc/treno.html
プローブの送出制御でＴＣＰセッションをエミュレート、ある時点での有効パス容量の指標を得る
・ＴＲＡＣＥＲＯＵＴＥ
・ＰＡＴＣＨＥＲ
・ＳＮＭＰ

・非侵入測定法：エンドシステムでのパケット到着レートを推測し、ネットワークの状態に関してなにがしかの推論を行い、ＱｏＳの効果を測定する。

・侵入測定法：ネットワークへのパケットを意図的に送信し、その結果のパケットを収集する。到達性、伝送のラウンドトリップ時間、パケット損失の期待値などを測定できる。

いずれも適切な推測に基づいて分析される必要がある。

３．ＱｏＳとキューイング方式、トラフィックシェーピング、受付制御
キューイング：処理を後回しにするため、一時的にパケットを格納すること。

キュー管理；
・キュー長：長すぎるとレイテンシ・ＲＴＴが長くなり、短すぎると大量のパケットが破棄される
・キューが伸びるのはＴＣＰが送信レートを増加させるため、あるいは、フロー数が動的に変化するため

・ＷＦＱ：トラフィック量の少ないフローを優先、トラフィック量の多いフローに残りのキューイング容量を公平に分ける。応答時間が予測可能、パケットの送信タイミングに一貫性を持たせている。フローごとにパケットをソートし、フローのトラフィック量に応じてキューイング。（ＣｉｓｃｏＷＦＱ）
重み付け基準は、カクベンダに依存。ＣｉｓｃｏＷＦＱでは、4096/(1+IP優先度)で重み付け。優先度が高いほど、フローに対して与えられるキューリソースが増える。

トラフィックシェーピングと受付制御（ＡｄｍｉｓｓｉｏｎＣｏｎｔｒｏｌ）；
受付制御はトラフィックをネットワークへ侵入させるかどうかを制御し、シェーピングは侵入させるトラフィックのレートを制御する。
・トラフィックシェーピング：入口でトラフィックフローを識別。leaky bucket/token bucket方式がある。
-　leaky bucket方式：ネットワークに送るトラフィックのレートを制御。
　○トラフィックフローが予測可能、制御可能
　×トラフィックバーストがバケットサイズよりずっと大きい場合、バケットに入りきらないトラフィックは破棄される
ATMで利用。
　トラフィックはバケットを一定のレートで通過する。
－　token bucket方式:実パケットはバケットを通過しない。バケット中に存在するトークンに基づいてトラフィックを送信する時間を定める。
　　設定可能なバーストの閾値以下のバーストを許容。→リソースの効率化
　　トークンは一定のバイト数を表す。トークン数は管理者が決定。バケットに十分な量のトークンがあれば、そのトラフィックを送信し、トークンがなければ送信できない。トークンがある限り、バーストトラフィックも送信し続けられる。
　　複数のバケットと複数の閾値を持つ方式もある。この場合、異なるピークレート閾値を持った複数のバケットが連携することで、トラフィッククラスに応じたシェーピングができる。
－　二つの組み合わせ：トークンバケットでシェーピング後、リーキバゲットに入れることで、全てのトラフィックを一定レート以下に抑えられる。

ネットワーク受付ポリシー：アクセス制御と受付制御の違い。
・アクセス制御：誰が、何へのアクセスを許可される、と定義される。
・受付制御：ネットワークに進入できるトラフィックの種類を制御。

・受付ポリシー：進入するトラフィックを識別して制御し、輻輳などを制御。
　ＩｎｔＳｅｒｖにおける受付ポリシー：ネットワークノードが要求されたＱｏＳを提供するために必要なリソースを持っているかどうか判断すること。

４．ＱｏＳとＴＣＰ／ＩＰ
ＯＳＰＦとＩＳＩＳは、ＴｏＳ値に応じて別々のパスを計算できる。
ＲＥＤ／ＷＲＥＤ：ＴＣＰのグローバル同期を避ける
閾値を用いることで、同じトラフィックでも、閾値を超えるトラフィックをマークダウンしたりもできる

５．ＱｏＳとＦＲ
入り口のＤＣＥがＣＩＲを保証する責任を持つ。
情報転送レートがＣＩＲを超える場合、ＣＩＲを超えたフレームにの廃棄可能表示ビットを１に変更。（ＤＥ＝１）ＤＥビットは、ＦＲネットワーク内のスイッチに対して、スイッチ輻輳時にＤＥ＝１のフレームをＤＥ＝０のフレームより先に廃棄すべきだと指示している。
廃棄したことをＤＴＥには通知しない。

ＦＲの輻輳管理：輻輳回避と輻輳回復。
・輻輳回避：ＢＥＣＮ／ＦＥＣＮ。ＦＲスイッチは、出力キューに3段階の閾値を使用することで実装。キューが1段目を超えたら、ＢＥＣＮかＦＥＣＮかをセットする。2段目を超えたら、ＤＥビットがセットされた全てのフレームを破棄。3段目の閾値は、キュー長そのもの。それ以降の全てのフレームを破棄。

６．ＱｏＳとＡＴＭ
・受付制御：コネクション受付制御（ＣＡＣ）により、入口スイッチでＳＶＣ／ＰＶＣコネクション設定時に、その設定要求を受け付けるかどうかを判断。十分なリソースがエンドツーエンドで確保できるときのみ受け付ける。
・ＡＴＭポリシング：使用量パラメータ制御（ＵＰＣ）とよばれ、入口スイッチで実行。すでに設定されたコネクションのＱｏＳに悪影響を与える動作からネットワークを守るために使われる。ＶＰＩ・ＶＣＩ値の正当性を検査し、進入トラフィックに関し、成立したトラフィック契約に適合するか監視。具体的には、セルをそのまま通すか、ＣＬＰ（セル損失優先表示）＝１のタグ付けをするか、廃棄するか。

＋ＡＴＭとマルチキャスト：ＭＡＲＳサーバの利用

CCVP Voice Practice Simulation Lab

CCVP Voice Practice Simulation Labの案内が来たので、やってみた。

一般的なルータとかのコンソール画面だけでなく、ＣＣＭのリモートＰＣアクセス画面みたいなのもあり。当たり前だけど、たぶん、ＣＣＩＥVoiceの筆記の対象には含まれるはずのＣＣＭなので、復習にちょうどよさそう。

ＳＲＳＴ機能も概要だけでなく設定が確認できて良かった。

これをきっかけに、Ｖｏｉｃｅ範囲のコマンド、設定手順をまとめなければ・・・

http://www.cisco.com/japanese/warp/public/3/jp/product/hs/iptel/srstel/prodlit/srstd_ds.shtml

このへんから、設定を探ろう・・・

ＨＳＲＰとＶＲＲＰ

冗長構成用プロトコルとしてHSRPをCiscoが独自に開発したが、ベンダー独自規格であったため他社とは互換性なし。
そこで複数のベンダーがHSRPを発展させ、他メーカー間で相互運用可能なようにしたVRRPがつくられ、RFCで規格化。（RFC2338）

どちらのプロトコルも複数のルータ間でやり取りして仮想的なルータを作成。
つまり仮想MACアドレスと仮想IPアドレスを作り、各端末はこの仮想アドレスをＤＧＷとして通信確立。

仮想アドレス；
＜HSRP＞
　00-00-0C-07-AC-**
＜VRRP＞
　00-00-5E-00-01-**
　※"**"は変数（グループ番号）

複数のルータ間で情報をやり取りする方法も若干違う；

＜HSRP＞
ルータ/ＭＬＳ間でHelloパケットのやりとりを行う。
HelloパケットはUDPの1985番ポートが使われ、224.0.0.2（マルチキャストアドレス）をTTL=1にして送信。
※アプリケーション層で動作。

＜VRRP＞
ルータ/ＭＬＳ間でVRRPパケットのやりとりを行う。
VRRPパケットはIP上でプロトコル番号112で動き、224.0.0.18（マルチキャストアドレス）でTTL=255にしてやりとり。
※トランスポート層で動作。

実現される機能的にはほぼ同じ。

ここからＶＲＲＰについて詳しく↓

＜ＶＲＲＰって？＞
VRRPは、動的経路制御が利用できない環境で複数のルータのバックアップを行うためのプロトコル。

VRRPには仮想のIPアドレスとMACアドレスを持つ仮想ルータが存在。
VRRPが動作している複数のルータのうちマスターとなっている1台が仮想ルータのIPアドレス/MACアドレスを利用して動作。他のルータはバックアップとして動作し、マスターがダウンした場合には仮想IPアドレス/MAC アドレスを引き継いで仮想ルータが存在し続けているように動作。ホストは、仮想ルータをＤＧＷとして設定することでマスターがダウンしてもバックアップ経由で通信を続けることができる。

＜VRRP広告＞
マスタールータがLANに送信するVRRPデータ。バックアップルータはこれ を受信することでマスタールータが動作していることを知る。

＜仮想ルータ＞
仮想ルータのIPアドレスは自由に設定できる；

１．仮想ルータのIPアドレスとして、VRRPグループに所属するVRRPルータのうち の1台のIPアドレスを利用する。
→仮想ルータのIPアドレスを持つVRRPルータが必ずマスターとなり、 他のルータはバックアップになる。

２．仮想ルータのIPアドレスとして、まったく別のIPアドレスを利用する。
→マスタールータはあらかじめVRRPルータに設定された優先度に応 じて自動的に決定。優先度は1～254の整数で、大きい方が優先。 優先度が同じVRRPルータの間ではIPアドレスの大きい方が優先。

仮想ルータのMACアドレスは、VRRPグループ毎に決められたユニキャストアドレスを利用（上記アドレス）

＜優先度＞
VRRPルータはそれぞれ優先度を持ち、優先度の高いルータがマスタールータとなり、他のルータはバックアップ。優先度は1～255の数値で設定するが、スムーズなマスター/バックアップ切り替えのためにはできるだけ優先度は大きな差をつけておくのがいい。
優先度はまったく同じ値を設定してもよいが、その場合、各VRRPルータのLANインタフェースのIPアドレスの大小によって優先されるべきVRRPルータが決まる。複数のルータが同時にマスタールータになろうとするので、その間の調整でマスタールータがばたばたすることが起こりえる。やはり優先度はできるだけ大きな差をつけて設定すべき。

＜プリエンプトモード＞
VRRPの動作モードの一つ。プリエンプトモードか否かでマスタールータ選出の方法が変わる。（ＨＳＲＰと同じ）

非プリエンプトモードでは、先に優先度の低いVRRPルータがマスタールータとなっていた場合には、そこに後から優先度の高いVRRPルータが参加してもマスタールータの切り替わりは起こらず、従来からのマスタールータがマスターとして動作し続ける。一方、プリエンプトモードで動作している場合には、優先度の高いVRRPルータが加わると必ずそちらにマスタールータが切り替わる。

通常は、プリエンプトモードで運用。非プリエンプトモードは、マスタールータが頻繁にダウンする場合に利用。（プリエンプトにすることでよりおおくのダウンタイムが発生する可能性あり）

＜インターフェイス/イベントトラック＞

ＨＳＲＰではインターフェイストラッキングをサポート。

ＶＲＲＰでは、標準的な定義はされていないが、ベンダ独自実装で、インターフェイスだけでなく、さまざまなイベントをトラックし、トリガ条件の変化によって、マスタ権限を移動できる。

しかし、ベンダ独自実装の場合、当然、異なるベンダ機器同士では利用できない。