Sync with the English version.

Changes between 1.1 and 1.4 of the English version have been merged.
Submitted by: Mitsuharu ARIMURA <arimura@sr3.t.u-tokyo.ac.jp>
This commit is contained in:
Hiroyuki Hanai 1997-12-26 01:49:23 +00:00
parent e6e7d3ac07
commit eb284c0b3e
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=2294
3 changed files with 393 additions and 15 deletions

View file

@ -1,11 +1,11 @@
<!-- $Id: network.sgml,v 1.1.1.1 1997-11-17 15:48:59 max Exp $ -->
<!-- $Id: network.sgml,v 1.2 1997-12-26 01:49:23 hanai Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.1 -->
<!-- Original revision: 1.4 -->
<sect>
<heading>ネットワーキング<label id="networking"></heading>
<p><em>訳: &a.arimura; <newline>&a.shou; <newline>&a.nishika; .
<newline>13 November 1997.</em>
<newline>24 December 1997.</em>
<sect1>
<heading>``diskless boot'' に関する情報はどこで得られますか?</heading>
@ -462,8 +462,21 @@ default 10.0.0.2 UGSc 0 0 tun0
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?sendmail"
name="sendmail"> が犯人です. 設定ファイルで sendmail に
DNS に問い合わせないようになっているか確認すべきです.
詳しくは <ref id="ispmail" name="メールの設定"> の節を
ご覧ください.
自分用の設定ファイルを作成するための詳しい方法は
<ref id="ispmail" name="メールの設定"> の節をご覧ください.
または, <bf/.mc/ファイルに次のような行を追加してもよいでしょう.
<verb>
define(`confDELIVERY_MODE', `d')dnl
</verb>
<p>この行を追加すると, sendmailはメールキューを処理する
(通常sendmailは30分ごとにキューを処理するよう, ``-bd -q30m''
というオプションを付けて起動されます)
か, または
(多分ppp.linkupというファイルの中で)
``sendmail -q''というコマンドが送られるまで, 全てのメールを
送信しないようになります.
<sect2>
<heading>CCP エラーとはどういう意味ですか</heading>
@ -532,6 +545,51 @@ default 10.0.0.2 UGSc 0 0 tun0
待っています, <bf/ppp/ に CONNECT の応答全てを読み込ませている
わけです.
<sect2>
<heading>私のchatスクリプトでは`\'という文字をPPPが解釈して
くれません</heading>
<p>PPPは設定ファイルを読み込むときに, <tt/set phone "123 456 789"/
のような文字列を正しく解釈し, 番号が実際に<bf/1つの/引数であると
理解します. ``"''という文字を指定するには, backslash (``\'')で
エスケープしなければなりません.
<p>chatの各引数が解釈されるときには, ``\P''や``\T''のような
特別なescape sequence (man pageを見てください)を見付けるために
もう1回parseを行います. このようにparseは2回繰り返されま
すので, 正しい回数だけescapeを行わないといけません.
<p>モデムにたとえば``\''のような文字を送りたい場合には, 次のように
する必要があります:
<verb>
set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"
</verb>
<p>実際にモデムに送られる文字列は次のようになります:
<verb>
ATZ
OK
AT\X
OK
</verb>
<p>他の例ですと
<verb>
set phone 1234567
set dial "\"\" ATZ OK ATDT\\T"
</verb>
<p>は次のようになります:
<verb>
ATZ
OK
ATDT1234567
</verb>
<sect2>
<heading>どれにも当てはまらない! どうしたらいいの?</heading>
@ -743,5 +801,73 @@ vat_nv_record vat
<url url="../handbook/firewalls.html" name="FreeBSD ハンドブック">
にあります.
<sect1>
<heading>IPFWのオーバーヘッドはどのくらいでしょうか?</heading>
<p>この答えはあなたのrule setとprocessorのスピードによって
ほとんど決まります. Ethernetに対して少しのrule setだけを使っ
ているほどんどの場合には, その影響は無視できる程度です. 実
際の測定値を見ないと満足できない方々のために, 実際の測定結
果をお見せしましょう.
<p>次の測定は486-66上で2.2.5-STABLEを使用しておこなわれました.
IPFWは変更が加えられて, <tt/ip_fw_chk/ルーチン内でかかる時間を
測定して1000パケット毎に結果をconsoleに表示するようになっています.
<p>それぞれ1000ずつのruleが入っている2つのrule setでテストが
おこなわれました. ひとつ目のsetは最悪のケースを見るために
<verb>
ipfw add deny tcp from any to any 55555
</verb>
というruleを繰り返したものです.
<p>このsetを用いますと, (port番号によって) packetが全てのruleにマッチ
しない事が最終的に決まるまでに, IPFWのpacketをチェックするルーチン
のほとんど全てが実行されますので, 最悪のケースとなります. この
ruleを999個繰り返した後に<tt>allow ip from any to any</tt>が
書かれています.
<p>2つ目のsetは, なるべく早くチェックが終了するように書かれたものです:
<verb>
ipfw add deny ip from 1.2.3.4 to 1.2.3.4
</verb>
<p>このruleではsource側のIPアドレスがマッチしないのでチェックは
すぐに終了します. 上のsetとおなじように, 1000個目のruleは
<tt>allow ip from any to any</tt>です.
<p>1つ目のsetでは, packetあたりのoverheadはだいたい2.703ms/packet,
言いかえると1つのruleあたり2.7マイクロ秒です. したがってこのruleに
おけるpacketを処理する時間の理論的な限界は1秒あたり約370 packetです.
10MbpsのEthernetで1500 byte以下のpacketサイズを仮定すると, 55.5%の
バンド幅までしか使えない事になります.
<p>2つ目のsetでは, それぞれのpacketはだいたい1.172msで処理されて
いますので1つのruleあたり1.2マイクロ秒となります. packetの
処理時間の理論的な限界はだいたい1秒あたり853 packetとなりますので
10Mbps Ethernetのバンド幅を使い切ることができます.
<p>このテストでのruleの数は多過ぎますので, 実際に使用している際の
結果を反映している訳ではありません. これらは上に示した数値を出す
ためだけに用いられたものです. 実際に効率の良いrule setを作るために
は, 次のような事を考えておけばよいでしょう.
<itemize>
<item>`確定している' ruleは, TCPのtrafficの多数を処理するために
前の方に持ってきてください. そしてこのruleの前には<tt>allow tcp</tt>
という記述をしないでください.
<item>良く使われるruleを, あまり良く使われないruleよりも
前の方に(もちろん<bf>firewallの許可の設定を変えない範囲で</bf>)
持ってきてください.
<tt>ipfw -a l</tt>のようにしてpacket数の統計を取ることによって
どのruleが最もよく使われているかが分かります.
</itemize>
</sect>

View file

@ -1,11 +1,11 @@
<!-- $Id: network.sgml,v 1.1.1.1 1997-11-17 15:48:59 max Exp $ -->
<!-- $Id: network.sgml,v 1.2 1997-12-26 01:49:23 hanai Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.1 -->
<!-- Original revision: 1.4 -->
<sect>
<heading>ネットワーキング<label id="networking"></heading>
<p><em>訳: &a.arimura; <newline>&a.shou; <newline>&a.nishika; .
<newline>13 November 1997.</em>
<newline>24 December 1997.</em>
<sect1>
<heading>``diskless boot'' に関する情報はどこで得られますか?</heading>
@ -462,8 +462,21 @@ default 10.0.0.2 UGSc 0 0 tun0
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?sendmail"
name="sendmail"> が犯人です. 設定ファイルで sendmail に
DNS に問い合わせないようになっているか確認すべきです.
詳しくは <ref id="ispmail" name="メールの設定"> の節を
ご覧ください.
自分用の設定ファイルを作成するための詳しい方法は
<ref id="ispmail" name="メールの設定"> の節をご覧ください.
または, <bf/.mc/ファイルに次のような行を追加してもよいでしょう.
<verb>
define(`confDELIVERY_MODE', `d')dnl
</verb>
<p>この行を追加すると, sendmailはメールキューを処理する
(通常sendmailは30分ごとにキューを処理するよう, ``-bd -q30m''
というオプションを付けて起動されます)
か, または
(多分ppp.linkupというファイルの中で)
``sendmail -q''というコマンドが送られるまで, 全てのメールを
送信しないようになります.
<sect2>
<heading>CCP エラーとはどういう意味ですか</heading>
@ -532,6 +545,51 @@ default 10.0.0.2 UGSc 0 0 tun0
待っています, <bf/ppp/ に CONNECT の応答全てを読み込ませている
わけです.
<sect2>
<heading>私のchatスクリプトでは`\'という文字をPPPが解釈して
くれません</heading>
<p>PPPは設定ファイルを読み込むときに, <tt/set phone "123 456 789"/
のような文字列を正しく解釈し, 番号が実際に<bf/1つの/引数であると
理解します. ``"''という文字を指定するには, backslash (``\'')で
エスケープしなければなりません.
<p>chatの各引数が解釈されるときには, ``\P''や``\T''のような
特別なescape sequence (man pageを見てください)を見付けるために
もう1回parseを行います. このようにparseは2回繰り返されま
すので, 正しい回数だけescapeを行わないといけません.
<p>モデムにたとえば``\''のような文字を送りたい場合には, 次のように
する必要があります:
<verb>
set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"
</verb>
<p>実際にモデムに送られる文字列は次のようになります:
<verb>
ATZ
OK
AT\X
OK
</verb>
<p>他の例ですと
<verb>
set phone 1234567
set dial "\"\" ATZ OK ATDT\\T"
</verb>
<p>は次のようになります:
<verb>
ATZ
OK
ATDT1234567
</verb>
<sect2>
<heading>どれにも当てはまらない! どうしたらいいの?</heading>
@ -743,5 +801,73 @@ vat_nv_record vat
<url url="../handbook/firewalls.html" name="FreeBSD ハンドブック">
にあります.
<sect1>
<heading>IPFWのオーバーヘッドはどのくらいでしょうか?</heading>
<p>この答えはあなたのrule setとprocessorのスピードによって
ほとんど決まります. Ethernetに対して少しのrule setだけを使っ
ているほどんどの場合には, その影響は無視できる程度です. 実
際の測定値を見ないと満足できない方々のために, 実際の測定結
果をお見せしましょう.
<p>次の測定は486-66上で2.2.5-STABLEを使用しておこなわれました.
IPFWは変更が加えられて, <tt/ip_fw_chk/ルーチン内でかかる時間を
測定して1000パケット毎に結果をconsoleに表示するようになっています.
<p>それぞれ1000ずつのruleが入っている2つのrule setでテストが
おこなわれました. ひとつ目のsetは最悪のケースを見るために
<verb>
ipfw add deny tcp from any to any 55555
</verb>
というruleを繰り返したものです.
<p>このsetを用いますと, (port番号によって) packetが全てのruleにマッチ
しない事が最終的に決まるまでに, IPFWのpacketをチェックするルーチン
のほとんど全てが実行されますので, 最悪のケースとなります. この
ruleを999個繰り返した後に<tt>allow ip from any to any</tt>が
書かれています.
<p>2つ目のsetは, なるべく早くチェックが終了するように書かれたものです:
<verb>
ipfw add deny ip from 1.2.3.4 to 1.2.3.4
</verb>
<p>このruleではsource側のIPアドレスがマッチしないのでチェックは
すぐに終了します. 上のsetとおなじように, 1000個目のruleは
<tt>allow ip from any to any</tt>です.
<p>1つ目のsetでは, packetあたりのoverheadはだいたい2.703ms/packet,
言いかえると1つのruleあたり2.7マイクロ秒です. したがってこのruleに
おけるpacketを処理する時間の理論的な限界は1秒あたり約370 packetです.
10MbpsのEthernetで1500 byte以下のpacketサイズを仮定すると, 55.5%の
バンド幅までしか使えない事になります.
<p>2つ目のsetでは, それぞれのpacketはだいたい1.172msで処理されて
いますので1つのruleあたり1.2マイクロ秒となります. packetの
処理時間の理論的な限界はだいたい1秒あたり853 packetとなりますので
10Mbps Ethernetのバンド幅を使い切ることができます.
<p>このテストでのruleの数は多過ぎますので, 実際に使用している際の
結果を反映している訳ではありません. これらは上に示した数値を出す
ためだけに用いられたものです. 実際に効率の良いrule setを作るために
は, 次のような事を考えておけばよいでしょう.
<itemize>
<item>`確定している' ruleは, TCPのtrafficの多数を処理するために
前の方に持ってきてください. そしてこのruleの前には<tt>allow tcp</tt>
という記述をしないでください.
<item>良く使われるruleを, あまり良く使われないruleよりも
前の方に(もちろん<bf>firewallの許可の設定を変えない範囲で</bf>)
持ってきてください.
<tt>ipfw -a l</tt>のようにしてpacket数の統計を取ることによって
どのruleが最もよく使われているかが分かります.
</itemize>
</sect>

View file

@ -1,11 +1,11 @@
<!-- $Id: network.sgml,v 1.1.1.1 1997-11-17 15:48:59 max Exp $ -->
<!-- $Id: network.sgml,v 1.2 1997-12-26 01:49:23 hanai Exp $ -->
<!-- The FreeBSD Japanese Documentation Project -->
<!-- Original revision: 1.1 -->
<!-- Original revision: 1.4 -->
<sect>
<heading>ネットワーキング<label id="networking"></heading>
<p><em>訳: &a.arimura; <newline>&a.shou; <newline>&a.nishika; .
<newline>13 November 1997.</em>
<newline>24 December 1997.</em>
<sect1>
<heading>``diskless boot'' に関する情報はどこで得られますか?</heading>
@ -462,8 +462,21 @@ default 10.0.0.2 UGSc 0 0 tun0
<htmlurl url="http://www.freebsd.org/cgi/man.cgi?sendmail"
name="sendmail"> が犯人です. 設定ファイルで sendmail に
DNS に問い合わせないようになっているか確認すべきです.
詳しくは <ref id="ispmail" name="メールの設定"> の節を
ご覧ください.
自分用の設定ファイルを作成するための詳しい方法は
<ref id="ispmail" name="メールの設定"> の節をご覧ください.
または, <bf/.mc/ファイルに次のような行を追加してもよいでしょう.
<verb>
define(`confDELIVERY_MODE', `d')dnl
</verb>
<p>この行を追加すると, sendmailはメールキューを処理する
(通常sendmailは30分ごとにキューを処理するよう, ``-bd -q30m''
というオプションを付けて起動されます)
か, または
(多分ppp.linkupというファイルの中で)
``sendmail -q''というコマンドが送られるまで, 全てのメールを
送信しないようになります.
<sect2>
<heading>CCP エラーとはどういう意味ですか</heading>
@ -532,6 +545,51 @@ default 10.0.0.2 UGSc 0 0 tun0
待っています, <bf/ppp/ に CONNECT の応答全てを読み込ませている
わけです.
<sect2>
<heading>私のchatスクリプトでは`\'という文字をPPPが解釈して
くれません</heading>
<p>PPPは設定ファイルを読み込むときに, <tt/set phone "123 456 789"/
のような文字列を正しく解釈し, 番号が実際に<bf/1つの/引数であると
理解します. ``"''という文字を指定するには, backslash (``\'')で
エスケープしなければなりません.
<p>chatの各引数が解釈されるときには, ``\P''や``\T''のような
特別なescape sequence (man pageを見てください)を見付けるために
もう1回parseを行います. このようにparseは2回繰り返されま
すので, 正しい回数だけescapeを行わないといけません.
<p>モデムにたとえば``\''のような文字を送りたい場合には, 次のように
する必要があります:
<verb>
set dial "\"\" ATZ OK-ATZ-OK AT\\\\X OK"
</verb>
<p>実際にモデムに送られる文字列は次のようになります:
<verb>
ATZ
OK
AT\X
OK
</verb>
<p>他の例ですと
<verb>
set phone 1234567
set dial "\"\" ATZ OK ATDT\\T"
</verb>
<p>は次のようになります:
<verb>
ATZ
OK
ATDT1234567
</verb>
<sect2>
<heading>どれにも当てはまらない! どうしたらいいの?</heading>
@ -743,5 +801,73 @@ vat_nv_record vat
<url url="../handbook/firewalls.html" name="FreeBSD ハンドブック">
にあります.
<sect1>
<heading>IPFWのオーバーヘッドはどのくらいでしょうか?</heading>
<p>この答えはあなたのrule setとprocessorのスピードによって
ほとんど決まります. Ethernetに対して少しのrule setだけを使っ
ているほどんどの場合には, その影響は無視できる程度です. 実
際の測定値を見ないと満足できない方々のために, 実際の測定結
果をお見せしましょう.
<p>次の測定は486-66上で2.2.5-STABLEを使用しておこなわれました.
IPFWは変更が加えられて, <tt/ip_fw_chk/ルーチン内でかかる時間を
測定して1000パケット毎に結果をconsoleに表示するようになっています.
<p>それぞれ1000ずつのruleが入っている2つのrule setでテストが
おこなわれました. ひとつ目のsetは最悪のケースを見るために
<verb>
ipfw add deny tcp from any to any 55555
</verb>
というruleを繰り返したものです.
<p>このsetを用いますと, (port番号によって) packetが全てのruleにマッチ
しない事が最終的に決まるまでに, IPFWのpacketをチェックするルーチン
のほとんど全てが実行されますので, 最悪のケースとなります. この
ruleを999個繰り返した後に<tt>allow ip from any to any</tt>が
書かれています.
<p>2つ目のsetは, なるべく早くチェックが終了するように書かれたものです:
<verb>
ipfw add deny ip from 1.2.3.4 to 1.2.3.4
</verb>
<p>このruleではsource側のIPアドレスがマッチしないのでチェックは
すぐに終了します. 上のsetとおなじように, 1000個目のruleは
<tt>allow ip from any to any</tt>です.
<p>1つ目のsetでは, packetあたりのoverheadはだいたい2.703ms/packet,
言いかえると1つのruleあたり2.7マイクロ秒です. したがってこのruleに
おけるpacketを処理する時間の理論的な限界は1秒あたり約370 packetです.
10MbpsのEthernetで1500 byte以下のpacketサイズを仮定すると, 55.5%の
バンド幅までしか使えない事になります.
<p>2つ目のsetでは, それぞれのpacketはだいたい1.172msで処理されて
いますので1つのruleあたり1.2マイクロ秒となります. packetの
処理時間の理論的な限界はだいたい1秒あたり853 packetとなりますので
10Mbps Ethernetのバンド幅を使い切ることができます.
<p>このテストでのruleの数は多過ぎますので, 実際に使用している際の
結果を反映している訳ではありません. これらは上に示した数値を出す
ためだけに用いられたものです. 実際に効率の良いrule setを作るために
は, 次のような事を考えておけばよいでしょう.
<itemize>
<item>`確定している' ruleは, TCPのtrafficの多数を処理するために
前の方に持ってきてください. そしてこのruleの前には<tt>allow tcp</tt>
という記述をしないでください.
<item>良く使われるruleを, あまり良く使われないruleよりも
前の方に(もちろん<bf>firewallの許可の設定を変えない範囲で</bf>)
持ってきてください.
<tt>ipfw -a l</tt>のようにしてpacket数の統計を取ることによって
どのruleが最もよく使われているかが分かります.
</itemize>
</sect>