- - PR -
Cisco系インターフェース情報のパケットINとOUT
| 投稿者 | 投稿内容 | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2007-01-04 14:55
こんにちは。
Cisco系のインターフェース情報についてお聞きしたい内容がございます。 今回はCatalyst4948が対象なのですが、 インターフェースのインとアウトのパケット量を監視しており、 実際にインパケットより、アウトパケットの方が量が２倍ほど多く、 これはおかしいのではないか？という指摘を受けています。 問題の監視している情報は、 show int vlan**で採取しているのですが、下記の部分を監視対象にしております。 L3 in Switched: ucast: 2909182772 pkt, 371626132942 bytes - mcast: 450 pkt, 252264 bytes L3 out Switched: ucast: 5468261249 pkt, 7781944938099 bytes - mcast: 0 pkt, 0 bytes ＃いづれも＊＊pktの部分。 この情報のOUTという情報は、VLAN**から出ているパケットで、 INという情報はVLAN**へ入ってくるパケットという解釈でしょうか？ 上記解釈ですと、OUTがそのネットワークから出ているパケットなので、 多くてなんの問題もないと思うのですが、アクセスリストの概念は反対になり、 このVLANにもアクセスリストがもちろんの事かかっているのですが、 INというアクセスリストはVLAN**から出ているパケットに対してのフィルタ、 OUTというアクセスリストはVLAN**へ入ってくるパケットに対してのフィルタに なるかと思います。 ですので、私の上記見解が間違っていなければ、 指摘されている者の解釈違いで、アクセスリストと同様に show int vlan**で得られる情報をみている可能性が高いと見られ、解決しそうです。 また、少し横道にそれますが、アクセスリストのパケット廃棄のタイミングは、 インターフェースに転送される前に廃棄されると解釈していますが、 廃棄される際にはこういったインターフェースのパケットがカウントアップした後に 廃棄されるのか、もしくはカウントアップされる前に廃棄されるのか、どちらでしょうか？ カウントアップした後に廃棄されるとすれば、行きと戻りの整合性の信頼度が 極端に落ちてしまうと思いまして。。 不足情報等あれば、追記致しますので、ご指摘下さい。 それではよろしくお願い致します。 | ||||||||||||||||
|
投稿日時: 2007-01-05 01:21
＞ drufyi さん
あけましておめでとうございます。
私も同じ認識でいます。ですが、以下は私の理解と異なります。
う〜ん、「アクセスリストの概念は反対に」なるんですか？？？ 時間を見つけて検証してみようとは思いますが後学の為、構成例や Config 例を教えて頂けないでしょうか？ # 普通に「IN で設定すれば、IN パケットに適当されるのでは？」と思うのですが... # 私の不勉強 or 理解力不足でしたら、申し訳ありません。
カウントアップしてから廃棄、だったと思います。(Catalyst ではありませんが) 手元の Cisco26xx で試した限りですと、パケットは廃棄するものの、カウントアップしています。以前に Cat6xxx で試したことがあるのですが、やはりカウントアップしていたような気がします (うろ覚え)。 O'Rreily の「Cisco IOS アクセスリスト」本をあたってみたのですが、良さげな情報には辿り着けませんでした... あまりお力になれなくてスイマセン (涙)。 ではでは、うえだ＠不勉強でした。 | ||||||||||||||||
|
投稿日時: 2007-01-05 11:45
こんにちは。
CISCOに限った話ではありませんが、ルータ、L3SWは単純な中継機ではありません。 設置された環境の情報を知るために自らARPテーブル更新用のポーリングパケットを 発信したり、設定によってはSNMP通信を行ないます。 従って「インパケット＜アウトパケット」となっても不思議は無いかと思います。 私は表面的な内容しか掌握しておりませんが、詳細に知りたければCISCO社または 販売代理店に問い合わせるとよろしいかと思われます。 | ||||||||||||||||
|
投稿日時: 2007-01-06 04:54
うえだ様、BackDoor様ありがとうございます。
まず、うえだ様のご指摘から返答させて頂きます。
遅くなりましたが、あけましておめでとうございますm(_ _)m IN・OUTの解釈はOKとしまして、
反対という私の言い方が悪かったのかもしれませんが、 インターフェースの情報の場合、誤認がなかったということで、 INはそのネットワークへの通信のカウント、 OUTはそのネットワークからの通信のカウント、になると思います。 フィルタの場合は、 INフィルタは、"そのネットワークからの通信のフィルタ"、 OUTフィルタは、"そのネットワークへの通信のフィルタ"、となります。 あえて、同じような言い回しで書きました。 ですので、 "インターフェース情報で表示される" INパケットを制御するフィルタはOUTフィルタ、 OUTパケットを制御するフィルタはINフィルタとなります。 よって、指摘者がACLの方向と同様にインターフェース情報を捉えて いた場合はこちらから少しはつっこめるかなといった感じです。 Catalyst ------ |****| |****|←OUT※show interfaceで表示されるパケット方向 |****|←IN※OUTパケットを制御するACL方向 |****|-------------------------・(192.168.1.0/24) |****|→IN※show interfaceで表示されるパケット方向 |****|→OUT※INパケットを制御するACL方向 |****| ------ カウントアップに関しては参考になりました。 ありがとうございました。 続きまして、BackDoor様に返答させて頂きます。
なるほどです。 非常に参考になります。
私もこの意見には同様の考えを持っていまして、 初め指摘された時に、仕様的な物があるので、CISCOに問い合わせた方が良いでしょうと、、。 しかし、調べろというニュアンスが強かったので、自分なりに調べた後、皆様のご意見を頂きたかった次第です。 ありがとうございました。 指摘・情報等ありましたら、引き続きよろしくお願いします。 [ メッセージ編集済み 編集者: drufyi 編集日時 2007-01-06 04:55 ] [ メッセージ編集済み 編集者: drufyi 編集日時 2007-01-06 04:56 ] | ||||||||||||||||
|
投稿日時: 2007-01-06 10:35
＞ drufyi さん
すごい時間ですね＞4:54 遅くまで？早くから？？お疲れさまです・・・
丁寧な説明、ありがとうございます。仰っている内容は理解しました。 ベンダー含め、私の周辺では「ingress に設定するなら IN フィルタ、egress に設定するなら OUT フィルタ」と呼んでいます。個人的には、こちらの方が直感的に感じます。どちらが正しいわけでもありませんし、文化の差なだけ (おおげさ？) かも知れませんが、なかなか面白いですねー（＾＾
元々の質問時点から疑問に思っていたのですが、指摘された方は何を「おかしい」と考えているのでしょうか？トポロジーや通信の種類によって IN / OUT のバランスが 1:1 にならないことは日常茶飯事だと思います。きっと何か理由があるのでしょうから、指摘された方が「IN:OUT / 1:2」を疑問に思った根拠を、もう少し知りたいですね。
例えば同じ Catalyst65xx プラットフォームでも Sup720-3BXL 以前と以後では ACL (ACE) ヒットカウンタの挙動が異なったり、一概に「こうです！こう動きます！！」とは言い辛いですよね。ハードウェア処理になるのか、ソフトウェア処理になるのか等々、効率やメカニズムを追求すると ACL も奥深いものがあります。。。 ではでは。うえだ＠朝はグレープフルーツサワーでした。 | ||||||||||||||||
|
投稿日時: 2007-01-06 16:55
こんにちは。
変な時間に寝てしまったため、夜中に寝れませんでした(笑) フィルタのIN、OUTのフィルタは我々では設定上での、 その機器のフィルタ方向のIN・OUTで会話をします。 Juniperなどはこの反対の概念になりますので、実際に設定したときに はまった経験があります。 [quota] 元々の質問時点から疑問に思っていたのですが、指摘された方は何を「おかしい」と考えているのでしょうか？ [/quota] 年末にの話だったので、私も来週あたりつっこんでみようと思います。 恐らく単純な考えだと思います。 私も言われて少し考えてしまい、このような質問になってしまいました。。 言い分が詳細になればまた投稿いたしますｗ うえだ様、ご丁寧にありがとうございましたm(_ _)m | ||||||||||||||||
|
投稿日時: 2007-01-07 21:20
＞ drufyi さん
わざわざご回答、ありがとうございます。
あー、その気持ちは私もわかります、わかります！ トラフィックの件だけなら兎も角、ACL とカウントアップの関連について言及されると、(自分の知識が十分に及ばないだけに) 私もちょっと弱いカンジです。。。指摘された方の根拠が十分でなければ、質問に対して「で、何？トラフィックが非対象だから、何？？」と業務回答し、クローズにしてしまうかも知れませんがｗｗ (で、カウントアップのメカニズムに関しては後で調べとく、と) 上記を踏まえ、質問された方の根拠・・・
Ex.2 - 「本来のトラフィック設計上、このトラフィック比率はありえない」 Ex.3 - 「Flow をモニタしていると、変なトラフィックが (略)」 以下、超蛇足ですが、なんとなく drufyi さんには「show ・・・ カウントアップのメカニズム」だけ明確になれば十分、トラフィック設計等については釈迦に説法かしらん？と思い、最初の回答では「カウントアップのメカニズム」についてのみ、回答させて頂きました。2 レス目で余計なこと（＝疑問の根拠が知りたい）を書いてしまったばかりに更にご回答頂き、余計なバイト数を使わせてしまったことを、ちょっぴり反省してます・・・こちらこそ「IN / OUT の表現にも、いろんな考え方がある」ことを教えて頂き、却って勉強になってしまいました・・・・・ ではでは。うえだ＠新年でもクリスマス・ビールでした。 | ||||||||||||||||
|
投稿日時: 2007-01-09 18:22
うえだ様、ありがとうございます。
うえだ様とですと、色々日々の話が出てきそうですね(笑) 本日初出し、確認してみましたが、 単純明快に書くと、インターフェース情報のＩＮとＯＵＴでの量が一致しないのはおかしい！ ということでした。 そのインターフェースでＩＮ・ＯＵＴが合わなくても、 作成しているインターフェース全てのＩＮとＯＵＴの和は等しいもしくは、 ニアになるのではないのか？という事でした。 BackDoor様にも言って頂いたように中継機ではない点と、 やはりINとOUTの情報を反対に(OUTを受信、INを送信)とACLと同じく思っていたらしく、 その点を伝えると納得されていました。 もうこの辺り厳密な部分はBackDoor様も仰っていましたが、 ベンダーに問い合わせ仕様を確認するしかないと言うしかありませんでした。 私もまだまだ勉強不足です。。。 | ||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。