キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
348
閲覧回数
0
いいね!
2
コメント
tadnakam
Community Member

SCEにて通信を最初に検知した際に、SCE は Flow を作成 します。

このFlowは、下記の図の様に通信が開始より終了したと判断するまで継続して通信を管理します。

SCE Flow.png

① 最初に Packet を検出した際に、Flow を 開始する(Flow start)。 この際に Defult の Aging Time が設定される

② 通信に Signeture を検出すると、プロトコル別の Aging Time へと設定が変更される

③ 通信に FIN/RST packet を検出した際が検出されると⑤へと進む

④ 設定された Aging Time の間、Packet を受信しない場合は⑤へと進む

⑤ Flow 終了(Flow death)

コメント
Naoki Kai
Level 1
Level 1

こちらもどういったことを説明するドキュメントなのかを前提に作成したほうが良いと思います。

また、図をつけているのであれば、その図の中の言葉で説明してあげたほうが良い気がします。

例えば "End Of Flow" などは、よくわからない気がします。

また、ソフトウェアレベルで上書きされた Aging time と、その前の Aging time との差なども説明してあげる

たりした方がいい気がします。

甲斐

Naoki Kai
Level 1
Level 1

For Version 6

図の ④の RST の"T" がずれてしまっています。また、①、②、③などの機種依存文字は、文字化けする可能性があると以前誰かに指摘されなおした気がします。

①で説明したいのは"最初に Packet を検出した際に、Flow を 開始する" ことではなくて、最初の packet を受信した場合にそのパケットの type (TCP, UDP, etc)によって、決められた aging time がその flow に対して設定されることですよね?また、default の aging time といってもわかりづらい気がするので packet の type ごとに決められた timer が aging timer として設定される

といったニュアンスが伝わるようにしたほうが良いと思います。

また、この packet type ごとに決められた timer が設定した後 packet を受信できなかった場合は flow は終了(図で言えば⑤の flow death)しますよね。そういったこともわかる説明にした方が良いと思います。

②通信に signature を検出すると、というのは誤解を与える可能性があります。 signature で flow を分類するんですよね??

プレゼンの資料であれば、その後、口頭で説明することができるので、今回のような感じの説明で十分かと思いますが、このドキュメントのみで説明すると考えると、説明が足りないのかなと思います。

細かいですが、上記点を踏まえて編集頂けますでしょうか。お忙しい中、編集いただいており申し訳ありませんがよろしくお願いいたします。

Getting Started

検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう

シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします