Free NetFlow Resources

我々ほとんどが気付いているようにネットフローの主な使用目的はネットワークトラフィック請求のためでした。広くネットワークトラフィック分析やベースラインに使われていますが、ネットフロー請求モジュールに興味を持っているサービスプロバイダがどのようにそれを使用するか指摘する機会があると思いました。まず第一にburstable billingの95パーセンタイルはどの様に測定するのか理解するのは重要です。最初に“95パーセンタイル”と聞いたとき、すぐに学校でとっていた統計と確立の授業を思い出しました。しかし、confidence intervals と normal curves は異なるアプリケーションを持っていて帯域幅請求には理想的ではないでしょう。

サービスプロバイダと帯域幅の歴史
なぜサービスプロバイダは彼らが発売したより多くの帯域幅を再販しているのでしょう。 この質問に答えるには、サービスプロバイダは他のサービスプロバイダからWAN帯域幅を購入していることを知る必要があります。そして彼らは一部の帯域幅を他のお客様に再販します。もしサービスプロバイダが3GB帯域幅を発売したらそれぞれのお客様はインターネットに１MG接続できます。お客様3000人だけしか？と思うかもしれませんが。もうお気付きの様にそうではありません。サービスプロバイダには同じパイプを使っている1万人のお客様がいるのです。どうやってでしょう。

サービスプロバイダはほとんどのお客様が購入した帯域幅の全部を使っていないことを知っています。例えば私達にとって、仕事をしているのでビジネスアワーには家の接続は広く使われなくなってきています。このため、サービスプロバイダは夜よりも日中に使うビジネス向けに同じ帯域幅を再販するのです。夜でさえオンラインでつなげている際、私たちの多くはたくさんのデータをダウンロードしていません（10代の子がいなければ）。 帯域幅の拡大で、サービスプロバイダはパイプを共有するお客様をどんどん増やそうとしています。

新規顧客が連れて来られると、サービスプロバイダは全部でどのくらいの帯域幅が顧客ベースによって使われているか注意深く監視します。

Denika Performance Trenderからの上記のようなトレンドを使用すると、サービスプロバイダは帯域幅を購入する前により多くのお客様に紹介するかどうかみることができます。

このブログのパート2でサービスプロバイダがなぜ95パーセンタイルを必要とするのか書きたいと思います。

あなたの組織のネットワーク監視に値札をつけるとしたらいくらにしますか。$10,000? $100,000? $1,000,000?

その値段には何が含まれていますか。ネットワークをサポートするスタッフ？ネットワーク監視ハードウェアやソフトウェア？スタッフや備品のためのオフィススペース？
ネットワーク監視は安価ではありません。しかしさらなる毎日のネットワーク資源の需要に対して、ネットワーク監視をしなかったり、節約することもできません。

あなたの地理的な場所によって、ネットワーク管理チームを構成するコストは異なり、フレキシブルになったりならなかったりします。スタッフをコンパクトに、入門レベルの人を雇うのはオプションです。

ネットワーク監視のためのハードウェアとソフトウェア要求はあなたのネットワーク環境により異なります。

ルータとスイッチがネットフローをサポートしていれば、フローanalyzerにネットフローをエクスポートすることで、あなたのネットワーク操作やトラフィックに以前よりもたくさんの情報を提供してくれます。ネットフローanalyzerアプリケーションはとてもお手頃です。 価格も無料のものから$10,000、それ以上と様々です。

他ものものことは分かりませんが私達が提供している無料ネットフローAnalyzerはScrutinizerインストールと設定を手助けする初めての無料テクニカルサポートだということを知っています。フローデータは24時間保持されほとんどの機能は無料の製品で使用可能です。購入前にScrutinizer昨日のアンロックを要求すると評価キーが使えるようになります。

具体的な価格のことはなしで購入の話をすると…私達の価格はもっと安値にできるとお客様より何度も言われています。んーー。おそらく調べる必要があるでしょう。全ては安値になりつつあるネットフローとSフローに特徴付けられました。全員がこの値下げに関心を向けていないことがあるでしょうか。

初年度購入には無償テクニカルサポートが付いているのをあなたは知っていましたか。もう一度言います。無料です。

あなたの組織のコストを減らす別の方法、それはテクニカルサポートです。無料のテクニカルサポートでは、スタッフはネットワーク管理ソフトウェアとネットワークトラフィック分析へ費やす時間を減らすことができます。

おそらく全ての帯域幅は結局は何なのか、さらに帯域幅を追加する必要がないことに気付くはずです。会社にとってコスト削減となります。

この景気で、私達費用を節約できると関心を寄せています。もっと効率的に作動させることができれば、双方にとってとても有益です。Scrutinizerについて、質問があれば私達に連絡して下さい。どうすればあなたの組織に利益をもたらすことができるか議論できれば嬉しいです。

私たちのネットフローとsフロー分析ツール（http://www.plixer.com/products/netflow-sflow/scrutinizer-netflow-sflow.php）の最新バージョンがリリースされてから、新しい機能についてブログを書いています。

新しいレポート機能の一つは、通信においてフィルターにかけるができ、ユーザがそれらの通信内で関連している定義されたアプリケーションを確認することが可能となりました。

ユーザがネームを定義するように、アプリケーショングループの定義されたアプリケーションによって、特定のIPアドレスとポート上でトラフィックを特定することができます。例えば、一般的なHTTP　(80番ポート)　トラフィック以外の何かとして、Facebook や YouTubeを明確にするのにこのツールを使用しています。 Scrutinizerの以前発売されたバージョンでは、アプリケーショングループを使用してユーザアプリケーションを定義することができましたが、よく知られたポートがどのように定義されていようと、カンバゼーションレポートは、このトラフィックを表示します。

v7.3以前のカンバゼーションレポートは、ソースと送信先を示しますが、いつもカンバゼーションが起こるポートのようにHTTP(80TCP)を示します。

Scrutinizer v7.3では、よく知られたポートよりはむしろ、ユーザに定義されたアプリケーションを示すカンバゼーションレポートフィルタである、カンバゼーションアプリと呼ばれる新しいレポートフィルタを紹介しました。

acmeapplication.com　のケースでは、特定のアプリケーションから来るトラフィックのようにHTTP(TCPポート80)を使用しているトラフィックをこのレポートで簡単に識別することが可能です。

v7.3アップデートでPlixer International（http://www.plixer.com/）が紹介した多くの新しいレポートフィルタの一つに過ぎません。改良されたネットワークトラフィック分析とネットワーク監視で私たちのお客様を手助けします。        

-Scott

誰が帯域幅hogのトップ10なのか知らせてくれるネットフローレポートアプリケーションクレームはトップ10や送受信の全トラフィックを基本とした期間のホストを表示しています。これは役立つことですがネットワークトラフィック分析に入ってきた時に曲がった図を描くことができます。フローボリュームについてはどうでしょう。 
“海外顧客は帯域幅消費を制限することや一年間のサービス停止に直面することを警告したConcastからの手紙を受け取っています。情報源:  The New York Times

全てのSフローとネットフローアナライザーはトップホストレポートを表示するといってよいと思います。しかし、これは設定問題を診断しようとしたまさにその時に始まります。より正確な問題の図を手に入れるのにhog動作の詳細をさらに探る必要があります。 下記はタイムフレームの間、各ホストに送信される全バイトをトップホストが並べている様子です。しかしそれぞれがいくつのフローを作り出したのかは分かりません。気にする必要がありますか。

Yankee グループのBenoit Feltonは「帯域幅Hogをtelcosが認識する方法は他のユーザーに不正なトラフィック設定が起こったかどうか監視することではない、ユーザーごとにダウンロードされた全データを測定し、上位5％をhogsと呼んでいます」と言いました。

Benoit Felton

いくつかのアプリケーションBitTorrentはダウンロードファイルに入ってくるとFTPのような伝統的な習慣よりも活動的です。ITのRichard Bennett in Washington, DCのInnovation Foundation がうまく説明していたと思います。

“TCPが全てのTCPバーチャル回路で正しい間、ネットワークユーザーに公正さを保障しません。この理由は他のものよりTCPバーチャル回路を採用しているユーザーとアプリケーションがあるからです。ユーザーがBitTorrentのようなアプリケーションを実行しているとき特にややこしくなります。普通は、BitTorrentはダウンロード過程の間、20から40の TCP バーチャル回路を使用しています。 TCP公正は20から40のバーチャル回路は大量の帯域幅”fair”があることを保障します。 しかし、１VCにダウンロードしているFTPユーザーとしての帯域幅をBitTorrent ユーザーは20から40回手に入れているという事実はありません。 
Richard Bennett

フローボリュームのレポートは各ホストに作成されるフローボリュームやフローを誰が一番作っているか確定する必要があります。

あなたはどうやって帯域幅hogを認識していますか。まだ確定していないなら、ホストごとのフローボリュームがあるbest at NetFlow reportingをScrutinizerで探して見て下さい。

バージョン7より以前のScrutinizerのパケットロスの共通すこととその原因はデータベーステーブルがクラッシュすることです。それは、テクニカルサポートチームへの電話の課題でもあります。ネットフローコレクターによって受信される大量のネットフローデータのために、破損したデータベーステーブルは短期間に大量のパケットロスを起こします。

データロスとサポートタイムを最小限にするには破損したデータベーステーブルの修復が必要です。ネットフローとSフローアナライザーバージョン7に, 自己回復データベースを紹介しています。

 MySQL データベースチェックと修復は定期的に計画された基盤で一時間ごとに実行されています。データベースチェックが破損したあらゆるデータベーステーブルを見つけたら、修復しようと試みます。修復が有効でないと、破損したテーブルに警告するためScrutinizerにアラームが作成されます。
また、the Server Health LED (画面右上の4システムLEDの中の一番右端)はデータベース破損が検出されると赤に変化します。 別のServer Health LEDに関する注意– サーバディスクスペースが2ギガバイト低下するか使用可能メモリーが128メガバイトより少なくなると、このLEDは黄色に変わります。

Server Health LEDが赤い時に、LEDをクリックすると、どのデータベー破損が存在しているか表示できます。例えば下のイメージで、plixer.fa_threats と plixer.task_results データベース修復が失敗しました。しかしplixer.fa_topdomainresolve データベーステーブルの修復は成功しました。

破損したデータベーステーブルの修復を無効にした時にも、アラームが発生します。そして、アラームタブに行き、ドロップダウンリストからDatabase Health selectionを選択し、サーチボタンをクリックすると見ることができます。Admin→Settings→Syslog サーバに設定されたSyslog サーバを持っていたら,データベース修復が失敗したときに警告を出すようSyslog サーバを設定することができます。このようにデータロースを最小化しています。

このブログにある例の中で, 自動修復が初めは失敗しました。 しかしながらマニュアルチェックと修復を実行できたときまでは、自動修復はデータベーステーブル修復を成功させました。言いかえれば, マニュアル介入を必要とするデータベース破損はいくつかのケースがあるということです。破損が続くようならtechnical supportに連絡して下さい。

Scrutinizerｖ７ネットフローとSフローAnalyzeへアップグレードしていないなら私たちがお助けしますのでご連絡下さい。ネットワーク分析ツールバージョン７に紹介している新しいたくさんの機能を役立たせることが可能です。

先日、私は、お客様から「Scrutinizerにネットフローを送るには、ルータをどのように設定すればいいですか」と質問を受けました。この質問が非常に定期的にあるので、私のルータにコンフィグを固定し、フローを動かしている典型的なIPコマンドを投げる準備をしていました。しかし、私がルータのモデルについて尋ねると、お客様は、「Cisco Nexus 7000」と答えました。私は、デバイスが私たちの良く知っている通常のIOSを機能させないことが分かりました。Cisco’s NX-OSを稼動させます。そして、Cisco’s NX-OS CLI は、全く異なります。

Cisco NX-OSは、ユーザがインタフェース毎異なるアプリケーションの異なるデータを集めることができるフレキシブル構造をサポートしています。所定フィールドの大群からの選択キーによって、一部のアプリケーションに最良のフロー記録を定義することができますが、それに対し、Cisco IOS ソフトウェアは、外枠全体のために一つのフローマスクとエクスポートをサポートします。

Cisco NX-OSの中で、使用されたフレキシブル構造は、フロー記録、フローエクスポートとフローモニターで構成されていいます。 ネットフローコマンドラインインタフェース設定と検証コマンドは、ネットフローコマンド機能でネットフロー機能を有効にするまで、使用できません。もし、ネットフローコマンド機能が削除されれば、関連する全てのネットフロー設定情報も同様に削除されます。

Cisco NX-OS/IOS ネットフロー比較書類は、完全なNX-OS/IOS比較を提供しています。

ネットフローを設定する為に、以下のステップを踏んでください:

Step 1 ネットフロー機能を有効にする。　(いずれかのフローを設定する前にネットフローを全体的に有効にする必要があります。)

switch(config)#feature netflow

Step 2 適合するための特定のキーとフローを集めるためのフィールドによって、フロー記録を明確にします。

switch(config)#flow record internet
switch(config-flow-record)# description Ipv4 Flow
switch(config-flow-record)# match [command] [option]
switch(config-flow-record)# collect [command] [option]

フロー記録インターネットを表示してください (ネットフロー記録-インターネットについての情報をディスプレイ)

フロー記録の為に少なくとも一つ、以下の適合パラメータを設定する必要があります:

フロー記録適合パラメータオプション

フロー記録の為に少なくとも一つ、以下の集合パラメータを設定する必要があります:

フロー記録収集マラメータオプション

Step 3エクスポートフォーマット、プロトコル、宛先、そして他のパラメータを特定することによってオプショナルフローエクスポーターを定義します。

switch(config)#flow exporter scrutinizer
switch(config-flow-exporter)# destination 192.0.2.1
switch(config-flow-exporter)# source ethernet 2/1
switch(config-flow-exporter)# description ExportV9
switch(config-flow-exporter)# transport udp 2055
switch(config-flow-exporter)# version 9

フローエクスポータ　Scrutinizer(ネットフローのフローエクスポータ－Scrutinizerについての情報を表示します。

 Step 4 フロー記録とフローエクスポータに基づいてフローモニターを定義します。

switch(config)#flow monitor MonitorTest
switch(config-flow-monitor)# description Ipv4Monitor
switch(config-flow-monitor)#exporter scrutinizer
switch(config-flow-monitor)#record internet

フローモニター　MonitorTest(ネットフローのフローモニター－Monitor　Testをディスプレイ)を表示します。　

Step 5 ソースインタフェース、サブインタフェース、VLANインタフェース、またはVLANにフローモニタを適合します。

switch(config)# interface Ethernet 2/1
switch(config-if)# ip flow monitor MonitorTest input
or
switch(config-if)# ipv6 flow monitor MonitorTest input

ipフローモニタ　MonitorTestインプット　(IPv4フローモニタをインプット、またはアウトプットパケットのためのインタフェースに結合させる)
ipv6フローモニタ MonitorTestインプット (IPv6フローモニタをインプット、またはアウトプットパケットのためのインタフェースに結合させる)

フローモニタとオプショナルサンプラーをVLANに適合可能です。

switch(config)# vlan 30
switch(config-vlan)# ip flow monitor MonitorTest input

フローインタフェースイーサネット2/1(インタフェース－イーサネット2/1のネットフローに関する情報をディスプレイ)を表示します。

ここにサンプルのコンフィグがあります。

flow exporter scrutinizer
destination 192.0.2.1
transport udp 2055
source loopback0
version 9
flow record internet
description internet traffic
match ipv4 source address
match ipv4 destination address
match transport source-port
match transport destination-port
collect counter bytes
collect counter packets
flow monitor MonitorTest
description Internet traffic sent to scrutinizer
record internet
exporter scrutinizer

interface Ethernet2/1
description Connected to d87-mdf-fw01
no switchport
ip flow monitor MonitorTest input
ip flow monitor MonitorTest output
ip address 10.1.1.3
no shutdown

2特質層、ネットフロータイムアウトとネットフローサンプラー上でのネットフローの設定に関する更なる情報は、『Cisco Nexus 7000 Series NX-OS System Management Configuration Guide』をご参照ください。

Cisco’のフレキシブルネットフローアーキテクチャは、トラフィック分析に対して必要とされる情報のスコープを拡張します。この情報がどれほどパワフルなのかを確認するために、Mike Pattersonのブログ『How-to Configure Cisco Flexible NetFlow for NBAR Exports』　をチェックすることをお勧めします。　そして、Plixer’sの最新ネットフローsフロー分析ツールで全てを処理することができます。

-Scott

数週間前Scrutinizerｖ7.3(Plixer Internationalの最新のネットフローとSフロー分析ツール)で使用できるフローAnalyticツールを紹介するブログを始めました。

今日はTopフローアルゴリズムがフローAnlyticsを利用するScrutinizerv7.3で使用できる新しい分析ツールの4つ目をみなさんにご紹介します。Topフローとはたくさんのフローに関係するホストが完了しないフローの割合を占めているかどうかチェックするものです。これは各フローレコードのTCPフラッグフィールドを見て決定します。

もしTCPフローレコードでFINフラッグセットを持っていなければ、ホストにフル接続できないホストがリサーチしようとしているのを表示します。これはポートスキャンやP2Pアプリケーションとしては典型的なことです。もう一つの可能性はホストが間違って設定された対処されるべきアプリケーションを持ってるかです。

警告はTheats Overview Windowの中にUnfinished Flows Violation として報告されます。

Top フローを有効にするためのフロー Analytics Overview gadgetを使うことに関連しているTopフローアルゴリズムのセットアップです。あなたがトップフローを監視したい機器をその後加えます。それはインターネットルータ同様中心のスイッチがこのアルゴリズムにあることを示しています。

使用できなboxをチェックせずに、デバイスを取り除いたり加えたりするためにルータアイコンをクリックします。

Admin タブから、セッティングの下のフロー Analytics リンクに、このアルゴリズムへの警報しきい値の設定に使われる二つのアイテムがあります。

1. 最小コネクション – 警報が確認される前の5分間にいくつのコネクションをホストは持っていなければならないかを設定できます。
2. 最小フロー – この和は終了していない全てのフローの最小のパーセンテージを表しています。終了しないフローを時として持つことはとても普通のことですが、パーセンテージが高くなればなるほど、あなたのネットワークに良くない影響をもたらします。

Scrutinizerｖ7.3で使用可能な新しい分析ツールへの導入を楽しんでほしいです。

全てのフロー分析アルゴリズムは改善したネットワークトラフィック分析とネットワークトラフィック監視でお客様を助けることを目的としています。

サーバでアプリケーションかプロセスが使っているのはどのポートか今まで考えたことがありますか。ここにはあなたのネットフロー　コレクターのアプリケーショングループをセットアップするために、同様に使うことができる便利な裏技があります。

サーバの特別なポートにどのアプリケーションが添付されているか知りたければ、netstat-nbt を実行します。

Netstat-nbt ファイルに繋ぐ必要がある場合があります。

The –n はipだけプリントするので、より速いです。nestat-btを使えば、IPsが決まります。

全てのオプションを見るためには[netstat?]と打ち込みます。

アプリケーショングループをセットアップする

アプリケーションが使用するIPやポートを搭載するには、Scrutinizerを見てアプリケーショングループを決定します。

レポートの確認

Scrutinizerを見てアプリケーションレポートを実行しましょう。それがそのためにできることです。

このレポートがネットワークトラフィック分析において大きな助けになるはずです。

これはToSフィールド（例：IPフレームのDifferentiated Servicesフィールド）の４パートからなるシリーズのパート5です。４パートのブログにパート５をつけるなんて冗談です。

パート１から４を読んでおいてください。

もう一度、わたしの最初のブログからWireShark キャプチャを書きます。

※    図

上の図のDifferentiated Servicesフィールドの一部である２つのECN (Explicit Congestion Notification) ビットに注意してください。それらはブログ３で1998年に書かれたRFC2474からの“現在は使われていない”ビットです。“現在は使われていない”（普通は:) 二つのビットはRFC3168で1998年に定義されました。

二つのECNビットは混雑状態を示すためにホストかルータに使われています。

• ECN-Capable Transport (ECT) = 10 or 01
• Not-ECN-Capable Transport (Not-ECT) = 00
• Congestion Experienced (CE) = 11NOTE: Routers treat the ECT(0) and ECT(1) codepoints as equivalent. Senders are free to use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a packet-by-packet basis.

TCPとECNの操作

Wikipediaには書いてないのでいくつかの文を貼り付けておきます。

＜貼り付け開始＞

IPヘッダーのECNビットによると、TCPはTCPヘッダーで送信者が送る情報を減らすために送信者に信号を送るTCPヘッダーで二つのフラッグを使用します。これはECNエコーと下記で説明するCongestion Window Reduced (CWR)です。

TCPコネクションでのECNの使用はオプションです。ECNが使われるにはSYNとSYN－ACKセグメントの最適なオプションを取り入れることにより作られるコネクションで交する必要がある。ECNがTCPコネクションに関して取り決められると送信者はECN-capableコードポイントで全てのデータセグメントに印を付けます。これから起こる混在状態を検出するルータはECN-capableパケットに完全に落とすというよりもCongestion　Experienced コードポイントで印を付けることを選択します。

　Congestion　Experienced コードポイントでTCPセグメントを受信すると、TCPレシーバーがECNエコーフラッグセットでの確認を送信します。ECNエコービットはパッケトを落として混雑ウィンドウを減らす送信者へ混雑状況を提示します。Congestion Window Reduced コードポイントでセグメントを送ることで混雑表示を認識します。

＜貼り付けの終わり＞

写真を見ていると思います。もっと勉強したければ、ＲＦＣを読んで下さい。1981年まで保存されたビットを彼らが使っていて2001年にその使用方法を見つけたと想像してください。

それは先を読んでのことですか、それとも何？

よいビットは80年代初旬戻って保存されました。ＥＣＮエコーフラッグの設定をやめる時を決定するＴＣＰレシーバーを有効にするためにTCPヘッダー（ＣＷＲフラッグ）に二つ目の新しいフラッグを導入しました。

CWRフラッグはＴＣＰヘッダーのResearved フィールドのビット8に割り当てられます

上部はRFC793に定義されたTCPヘッダーのバイト14と13（ビットではない）の新しい定義です。2006年のRFC4774はECNに関して改善を試みていますが、このシリーズからの休暇が必要です。

最後に、ECNビットの表示をレポートしているScrutinizerｖ７のネットフローレポートはどのようにECNビットを表示するか下記を見てください。

ネットワークの混雑状況を示すためにネットフローのECNビットを使えないかなと考えています。　　　お読みいただきありがとうございました。

ネットフローを使用しているQoSのレポートは最も基本的なネットフローレポートツールにとってもとても基本のレポートです。レポートの名前はベンダーによって違いますが、IP図表の同一8ビットToSについて、私たちは話しています。時には誤ってDSCPとみなされることがあり、この1バイトの価値はQoSフローをセレクトビジネスアプリケーションにどうにか保証するために使われます。 

VoIPやビデオのようなアプリケーションのネットワークを通じて、QoSno優先順位を決めようと、多くの企業がDiffServ ドメインを設定しています。サービスが標準にならない時、この会社はよくトラブル解決ルーティーンの一つとしてネットフローAnalysisに転向します。もし これらの頭文字が分からなければ、Tos, DSCP やネットフロー…. 「What the DiffServ」  に関する私の5つのパートのブログがあなたの助けになってくれるでしょう。

QoSサービスを話している時多くの人はDSCPと呼ばれるToSフィールドの6ビットの一部について話しています。下がその例です。

赤い四角でECTという文字と囲ってある上記のものに注意して下さい。これはDSCPを使用している時、残り8ビットToSフィールドを作っているExplicit Congestion Notification 2ビットです。このフィールドはそれらを実行するビジネスアプリケーションスタートとしてとても重要になってきてきます。

Wikipedia: “TCPは送信する情報を減らすために送信者に信号を送るTCPヘッダーの中で二つのフラッグを使用しています。これは下記で説明するECN-echo (ECE) とCongestion Window Reduced (CWR) ビットです。 とにかく上のスクリーンキャプチャーのDSCPバリューの一つに関して掘り下げてみましょう。そして約2ダースレポートから選択しましょう。

  BTW: 各レポートは追加レポートコンビネーションを持っています。

DSCP 0 ECT (00000010) フィルターが通ったか分かる上の赤い枠を参照して下さい。さらに勧めていき、DSCPトラフィックのしきい値を設定するためにフローAnalyticsを使いましょう。しきい値が私たちに教えてくれます。

上記野しきい値に追加のフィルターを使うことができます。

•異なるルータ・スイッチでのインタフェース 

• 特定のIPアドレスかサブネット（それらを除外していても）

• TCP フラッグ
• 追加DSCPバリューをプラス
• など

かなりクールです。Scrutinizerがもう一つのレベルにToS レポートするのを考えるのが好きです。多くの企業が今日のネットワークメディアアプリケーショントラブル解決のためにレポートの精度を要求しています。