To be Networker.

Networkの便利さを手軽にみんなで享受できる世の中になるように。

IP Network全般で日々気になる技術情報を覚書。資格取得情報も。



テーマ:

仕事柄保持している様々な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 に必要最低限のレート リミットを与えて、再度実行することです。

AD
いいね!した人  |  リブログ(0)

テーマ:

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



AD
いいね!した人  |  リブログ(0)

テーマ:

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


CCIELab対策の4時間の模擬試験をUS$279, a discount of US$70 off the list price of US$349で受けられるそうです。

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


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

AD
いいね!した人  |  リブログ(0)

テーマ:

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

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


--

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


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

以上3つの技術について
IETF:標準化
ITU-T:国際標準として「勧告」

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

今回は、1.IP電話の発着信を制御する技術=シグナリング技術 から。


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

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

H.323と関連プロトコル

接続手順を決める;
H.225:通話する相手端末と接続するまでの手順を規定
H.225には、端末同士のコネクションを設定するQ.931、GKとの通信プロトコルであるRAS(RegistrationAdmissionandStatus:GKへの端末登録、端末の通信許可、通信状態の問い合わせなどを行う=ダイレクトシグナリングでは不要)、送受信時の時間的な同期をとるRTPも関係する。
・ダイレクトシグナリング:GKを経由せず端末同士が直接相手を呼び出す。小規模向け。
各GWに、通話相手先の電話番号とIPアドレスの対応を登録しておく。
・GKダイレクトシグナリング:相手の呼び出しはGK同士で行い、それ以降のネゴシエーションは端末同士で行う。現在の主流。
各GWはGKにアドレス情報を登録しておく。GKで、IPアドレスの集中管理が可能。電話番号の変更やネットワークの運用をGKで集中管理。
・GK経由シグナリング:呼び出し、ネゴシエーションともにGK経由で行う。課金情報や詳細な通信情報を管理できる。
接続を完了するためには、RASを利用したメッセージと、端末同士が呼び出しのために使用するシグナリングメッセージ(Q.931)が交わされる。この手順が問題なく行われると、初めて端末同士が通信できる状態になる。続いて、H.245を用いた端末同士のネゴシエーションが開始され、一般的なIP電話の通話が可能になる。

H.245:接続後、お互いの端末同士が通話する際、実際の音声や動画などのデータ形式、コントロールする権利をどちら側が受け持つか(どちらが主役で通話を行うかを決める作業=ネゴシエーション)などを規定。
ネゴシエーションを行うことで、二つの端末の機能を、受信機能と送信機能に区別。
端末同士が通信を行うためのネゴシエーションを開始。
<ネゴシエーションの完了から通話まで>
発信元---TerminalCapabilitySet(G.711?G.723?G.729?・・・)--->宛先
発信元<-ACK+TerminalCapabilitySet(G.711?G.723?G.729?・・・)-宛先
発信側端末が最終的にどのCODECを使うか決定
発信元-G.729に決定!--------------------->宛先
ネゴシエーション完了
(ここで3者通話のマスターを決めることもできる)
IPネットワークでデータを流すためのロジカルチャンネルを設定
リアルタイム音声通話開始

RTP(RealtimeTransportProtocol):音声データの送受信
パケット化された音声データを送信端末が送り出すときに、実際に送信された正確な時間を記録する:RTPタイムスタンプ
受信側端末は、パケットを受信しながらRTPタイムスタンプを参照し、そのパケットの受信がいつ予定されていたのか、パケットが時系列に沿って到着しているかを確認して再生。
再送での遅延を避けるため、UDPを併用。

CODEC:符号化・圧縮率を決定
現在は高圧縮率のG.729が主流

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

H.261/H263:映像データのCODEC。TV電話などで利用。
H.261が必須、H.263はオプション。


SIP:SessionInitiationProtocol
1999,IETFが規定。 RFC2543
通信相手の宛先IPアドレスなどテキスト形式で指定。
インターネット上のほかのプロトコルとの親和性が高い。
IMT-2000の3G携帯ではSIPを採用。
H.323と比べてシンプルで拡張性が高い。
H.323では利用できない転送電話サービス、「キャッチフォン(NTT)」相当の通話中にさらに着信があったときに通話を保留しもう一方と
通話する「コールウェイティングサービス」、3者通話、多地点を結んだTV会議システムなどを実現。
IP電話サービスは、SIPのコネクション型サービスの一例。
SIPはレイヤ5のセッション層プロトコル。

<SIPネットワークの基本構成>
1.UA(UserAgent):端末。Client/Server両方の機能を持ち、1つのセッションを処理するときに両方の機能を使う。(UAC/UAS)
リクエストを行うときはUAC、リクエストを受けて結果を返すときはUAS。
IP電話機、PCやPDA上のクライアントアプリケーション、GWも含む。
このほか、トランザクション(リクエストを受けてそれに対して結果を返す一連の通信処理:「通話相手を呼び出す」、「接続を行う」、「通話が終了したら回線を切断する」というのが電話での一連のトランザクション)を管理する役割もある。
端末によってインターフェイスが違う;
電話機:発信に関してはダイヤルというインターフェイス
PC:アプリケーションソフトでのクリック
家電製品ではまた違うインターフェイス
→しかしSIPの本質的な機能は共通。
2.SIPサーバ:UA同士で行われるさまざまな通信処理の仲介役
SIPサーバは次の3つ;
プロキシ(代理)サーバ:UAや他のプロキシサーバからのリクエストを受け取って、それを他のUASに転送したり、レスポンスを他のUACに送る。プロキシサーバはデータを生成しない。UAからのリクエストを解釈し、必要な処理を行って、次の宛先へ送るだけ。端末同士の接続要求を代行するサーバ。
リダイレクトサーバ:リクエストの転送や中継は行わず、SIPリクエストをUACやプロキシサーバから受け取って、レスポンスを返す。
レジストラサーバ:登録サーバ。UACから自分のアドレスなどの登録リクエストを受け付けるサーバ。
レジストラサーバは登録内容の変更や削除も行う。UACの認証も行う。→SIPネットワークの不正利用を防ぐ。
3.ロケーションサーバ:レジストラサーバに登録されている情報を蓄積し、データベースサービスを提供する役目。
クライアントのIPアドレス、URI、サポート機能、プロキシサーバの位置、GWの位置などのDBが蓄積されている。
SIPでは、ロケーションサーバへのアクセス方法は決められていない。

<SIPのメソッドとレスポンスコード>
SIPシグナリング:テキスト形式。
・メソッド:UAクライアントからUAサーバに対するリクエスト。
通信を制御するためクライアントからサーバへ送られるコマンド。RFCドラフトなどで決められたものを使用。
例.
セッション確立するには「INVITE」
INVITEの最終応答の受信を確認する「ACK」
セッションを終了する「BYE」
・レスポンス:それに対応して返ってくるレスポンス。
レスポンスコードとして3桁の数字がわりあてられている。
例.
100 「Trying」
200 「OK」

<SIPセッション確立の流れ>
すでにお互いのIPアドレスを知っている状態から開始(SIPサーバへの問い合わせは省略);
1.発信側が受話器を上げて相手先電話番号をダイヤル
→INVITEメッセージが相手にリクエストされる
2.リクエストを受けた着信側端末では、発信者へ向けて「呼び出し中」の意味の「180 Ringing」レスポンスが返される
→発信者側の端末にも呼び出し音が流れ、着信者を現在呼び出していることがわかる
3.着信者が受話器を取って応答
→発信者へリクエスト成功として、「200 OK」レスポンスが送られる
4.発信者から着信者へ受信確認しましたという「ACK」メソッドが送られる
→セッションが確立し、RTPによる通話ができるようになる
5.通話が完了し、発信者が受話器を置いて電話を切る
→着信側へ切断を意味する「BYE」メソッドが送られる
6.受信した着信側は「200 OK」のレスポンスを返す

IPアドレスが不明なとき;SIPプロキシサーバか仲介。
1.発信者がSIPプロキシサーバへ通信したい相手先情報を含めた「INVITE」メソッドを送る
2.SIPプロキシサーバが相手先に接続要求「INVITE」を送る
*SIPプロキシサーバが相手先アドレス情報を持ってないときは、知っているプロキシサーバの場所をリダイレクトサーバへ問い合わせる
3.接続相手が接続許可を出すと、はじめて端末同士の通話が開始


MGCP:GW同士の通信、一般公衆電話網との通信機能を規定。
1998,IETF. RFC2705
IP網と既存PSTNとの接続に利用。
2者での通信のみ。

MEGACO:SIP対応のため、テキスト形式をサポートした、MGCPの拡張版、
2000,IETF. RFC3015
3者以上の複数拠点通信可能。


--

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

続きはまた。













いいね!した人  |  リブログ(0)

テーマ:

範囲の広さに辟易です。

BOSONでは大量の問題をこなすのに精一杯。

BOSONも踏まえて、当面の課題をあげておきます;

・CCM--Unity--VoiceMailサーバ

シリアルライン接続(CCM冗長時のSplitter接続)、インターフェイス、プロトコル、トラブルシュート

Lotus、MS AD、Win2k、Exchangeとの統合時の制約

・MGCP,SIP、H.323、SCCP

接続条件、TCP/UDPポート番号、マルチキャストアドレスなどを整理

・InLinePower

Cat Native IOSでの制約、Cat6k、4kなど機種依存制約

ケーブリング、ピンアサイン、VLANとの関係

・PBXトランク接続

設定、トラブルシュート

・QoS

CBWFQ,LLQ,IP RTP Priority

デフォルト設定、PQは1つ、%指定や帯域の設定

・SRST

CCM、CMEとの連携、トポロジ、設定コマンドとモード

・DialPlan、RouteList、、、設定とそのモード

・connection plar

・IPPhoneとアナログ電話機の間の呼の確立設定

。。。


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


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

がんばろう!



いいね!した人  |  リブログ(0)

テーマ:

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


いいね!した人  |  リブログ(0)

テーマ:

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


いいね!した人  |  リブログ(0)

テーマ:

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

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

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

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

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

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

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

改良アプローチ;
アクセスルータがパケットに割り当てられたQoSサービスレベルを反映するようパケットヘッダのフィールドを変更(マーキング)。NWに流入する全パケットにヘッダのマッチングルールを適用する。
=ルールに従い、IP優先制御ヘッダフィールドに要求されたQoSレベルを設定。

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

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

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

非対称ルーティング:RSVPでは正常動作に対称ルーティング必要

QoSの測定法:選択したQoSの実効性の測定
・TRENO:www.psc.edu/~pscnoc/treno.html
プローブの送出制御でTCPセッションをエミュレート、ある時点での有効パス容量の指標を得る
・TRACEROUTE
・PATCHER
・SNMP

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

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

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

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

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

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

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

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

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


4.QoSとTCP/IP
OSPFとISISは、ToS値に応じて別々のパスを計算できる。
RED/WRED:TCPのグローバル同期を避ける
閾値を用いることで、同じトラフィックでも、閾値を超えるトラフィックをマークダウンしたりもできる

5.QoSとFR
入り口のDCEがCIRを保証する責任を持つ。
情報転送レートがCIRを超える場合、CIRを超えたフレームにの廃棄可能表示ビットを1に変更。(DE=1)DEビットは、FRネットワーク内のスイッチに対して、スイッチ輻輳時にDE=1のフレームをDE=0のフレームより先に廃棄すべきだと指示している。
廃棄したことをDTEには通知しない。

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

6.QoSとATM
・受付制御:コネクション受付制御(CAC)により、入口スイッチでSVC/PVCコネクション設定時に、その設定要求を受け付けるかどうかを判断。十分なリソースがエンドツーエンドで確保できるときのみ受け付ける。
・ATMポリシング:使用量パラメータ制御(UPC)とよばれ、入口スイッチで実行。すでに設定されたコネクションのQoSに悪影響を与える動作からネットワークを守るために使われる。VPI・VCI値の正当性を検査し、進入トラフィックに関し、成立したトラフィック契約に適合するか監視。具体的には、セルをそのまま通すか、CLP(セル損失優先表示)=1のタグ付けをするか、廃棄するか。

+ATMとマルチキャスト:MARSサーバの利用

いいね!した人  |  リブログ(0)

テーマ:

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

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

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

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

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


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



いいね!した人  |  リブログ(0)

テーマ:


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

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

仮想アドレス;
<HSRP>
 00-00-0C-07-AC-**
<VRRP>
 00-00-5E-00-01-**
 ※"**"は変数(グループ番号)

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

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

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

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


ここからVRRPについて詳しく↓

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

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


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


<仮想ルータ>
仮想ルータのIPアドレスは自由に設定できる;

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

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

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


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

<プリエンプトモード>
VRRPの動作モードの一つ。プリエンプトモードか否かでマスタールータ選出の方法が変わる。(HSRPと同じ)

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

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


<インターフェイス/イベントトラック>

HSRPではインターフェイストラッキングをサポート。

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

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

いいね!した人  |  リブログ(0)

AD

ブログをはじめる

たくさんの芸能人・有名人が
書いているAmebaブログを
無料で簡単にはじめることができます。

公式トップブロガーへ応募

多くの方にご紹介したいブログを
執筆する方を「公式トップブロガー」
として認定しております。

芸能人・有名人ブログを開設

Amebaブログでは、芸能人・有名人ブログを
ご希望される著名人の方/事務所様を
随時募集しております。