FreeBSD 日本語マニュアル検索 (jman/japropos/jwhatis)


日本語 man コマンド類 (ja-man-1.1j_5) と日本語 man ドキュメント (ja-man-doc-5.4 (5.4-RELEASE 用) など) をインストールすると、以下のような man コマンド閲覧、キーワード検索が コンソールからできるようになります。

4.11-RELEASE-K, 5.4-RELEASE-K, 5.5-RELEASE-K, 6.0-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K, 12.1-RELEASE-K は、 プライベート版 (小金丸が編集してまとめたもの) ですが、 より多くの翻訳したファイルが含まれています。 (5.4-RELEASE-K から 6.4-RELEASE-K, 7.0-RELEASE-K から 7.4-RELEASE-K, 8.0-RELEASE-K から 8.4-RELEASE-K, 9.0-RELEASE-K から 9.3-RELEASE-K, 10.0-RELEASE-K から 10.3-RELEASE-K, 11.0-RELEASE-K から 11.4-RELEASE-K, 12.0-RELEASE-K から 12.3-RELEASE-K, 13.0-RELEASE-K から 13.2-RELEASE-K は、全翻訳済み)

13.3-STABLE-K, 15.0-CURRENT-K は現在、作成中で日々更新されています。



検索コマンド: man apropos whatis
コマンド/キーワード:
日本語マニュアル RELEASE :
セクション:
Table of Contents
名称 | 書式 | 解説 | IPV6 サポート | スパニングツリー | パケットフィルタリング | 使用例 | 関連項目 | 歴史 | 作者 | バグ
IF_BRIDGE(4)       FreeBSD カーネルインタフェースマニュアル       IF_BRIDGE(4)

名称
     if_bridge -- ネットワークブリッジデバイス

書式
     このドライバをカーネルにコンパイルするためには、次の行を利用者のカーネル
     設定ファイルに置きます:

           device if_bridge

     もう一つの方法として、ブート時にモジュールとしてドライバをロードするため
     には、次の行を loader.conf(5) に置きます:

           if_bridge_load="YES"
           bridgestp_load="YES"

解説
     if_bridge ドライバは同じ (または ``十分似ている'') フレーミング形式を使用
     する 2 以上の IEEE 802 ネットワークの間の論理的なリンクを作成します。例え
     ば、イーサネットと 802.11 ネットワークを共にブリッジすることは可能です
     が、イーサネットと Token Ring を共にブリッジすることはできません。

     各 if_bridge インタフェースは、インタフェースクローニングを使用して実行時
     に作成されます。これは、ifconfig(8) create コマンドまたは、rc.conf(5)cloned_interfaces 変数を使用して最も簡単に行えます。

     if_bridge インタフェースは、それが作成されるとき、局所的に管理されたアド
     レスのために予約された範囲内でランダムにリンク (MAC) アドレスを選択しま
     す。このアドレスは、ローカルマシンのすべての if_bridge インタフェースだけ
     でユニークになることが保証されています。したがって、利用者は、同じリンク
     アドレスがある異なったマシンで 2 つのブリッジを理論的に持つことができま
     す。ifconfig(8) を使用して必要なリンクアドレスを割り当てることによって、
     アドレスを変更することができます。

     sysctl(8) ノード net.link.bridge.inherit_mac に 0 でない値があるなら、新
     たに作成されたブリッジは、ランダムリンクレベルアドレスを選択する代わりに
     最初のメンバから MAC アドレスを引き継ぎます。これは、少しの追加の設定なし
     で、より予測できるブリッジ MAC を提供しますが、現在、この機能は、いくつか
     の L2 プロトコル、例えば、ng_pppoe(4)ppp(8) によって提供される
     PPPoE、に違反することが知られています。今、この機能は、実験的であるとみな
     されて、デフォルトでオフにされています。

     ブリッジは、ワイヤレスのホストとトラフィック分離のための簡単な 802.11 か
     らイーサネットへのブリッジのような、いくつかのサービスを提供するために使
     用することができます。

     ブリッジは、1 つのインタフェースから別のインタフェースまでトラフィックを
     転送する、スイッチのように動作します。マルチキャストとブロードキャスト
     (同報通信) パケットは、常にブリッジの一部であるすべてのインタフェースに転
     送します。ユニキャストトラフィックのために、ブリッジは、どの MAC アドレス
     がどのインタフェースに関連しているかを学習して、選択的にトラフィックを転
     送します。

     すべてのブリッジメンバのインタフェースは、ネットワークトラフィックを渡す
     ために作動している必要があります。これらは、ifconfig(8) を使用するか、ま
     たは rc.conf(5)ifconfig_<interface>="up" を設定することによって有効に
     することができます。

     追加される最初のメンバインタフェースの MTU は、ブリッジ MTU として使用さ
     れます。すべての追加メンバは、正確に同じ値を持つためにに必要です。

     ブリッジに追加されたすべてのインタフェースの TOE, TSO, TXCSUM と TXCSUM6
     ケーパビリティは、インタフェースのいずれかがそれらをサポートしない/有効に
     しないなら、無効にされます。LRO ケーパビリティは、常に無効にされます。す
     べてのケーパビリティは、インタフェースがブリッジから削除されるとき、復旧
     されます。実行時にケーパビリティを変更することは、NIC reinit とリンクフ
     ラップを起こすかもしれません。

     bridge (ブリッジ) は ``monitor mode'' (モニタモード) をサポートします。そ
     のモードでは、パケットは、bpf(4) 処理の後に捨てられ、処理されず、さらに転
     送されません。これは、2 つ以上のインタフェースの入力を単一の bpf(4) スト
     リームにマルチプレックス (多重送信) するために使用することができます。こ
     れは、2 つの別々のインタフェースを通る RX/TX シグナル出力を転送するネット
     ワークタップのためのトラフィックを再構築するために役に立ちます。

IPV6 サポート
     if_bridge は、ブリッジインタフェースで AF_INET6 アドレスファミリをサポー
     トします。次の rc.conf(5) 変数は、bridge0 インタフェースで IPv6 リンク
     ローカルアドレスを設定します:

           ifconfig_bridge0_ipv6="up"

     または、より明示的な方法で:

           ifconfig_bridge0_ipv6="inet6 auto_linklocal"

     しかしながら、AF_INET6 アドレスファミリには、スコープゾーン (scope zone)
     の概念があります。複数のインタフェースにブリッジすることは、複数のリンク
     が互いにマージされ、メンバのインタフェースがまだ個別に動作する間に、新し
     い単一のリンクを形成するので、ゾーン設定を変更します。これは、各メンバの
     インタフェースが個別のリンクローカルなスコープゾーンがあり、if_bridge イ
     ンタフェースには、別の単一の同時に集められたリンクローカルなスコープゾー
     ンがあることを意味します。この状況は、RFC 4007 のセクション 5 の記述 "同
     じスコープのゾーンがオーバラップすることができません" に明らかに違反して
     います。ほとんどの場合に動作しますが、if_bridge インタフェースとメンバイ
     ンタフェースの 1 つの両方とも、IPv6 アドレスがあり、アプリケーションがそ
     れらを両方を使用するとき、それは、いくつかのエッジケース (値がぎりぎりの
     場合) で直観に反した不適当な振る舞いを引き起こす場合があります。

     この状況を防ぐために、if_bridge は、追加されるメンバのインタフェースと
     if_bridge インタフェースで、リンクローカルなスコープの IPv6 アドレスが設
     定されているかどうかをチェックします。if_bridge インタフェースに IPv6 ア
     ドレスがあるとき、メンバのインタフェースの IPv6 アドレスは、インタフェー
     スが追加される前に、自動的に削除されます。

     sysctl(8) 変数 net.link.bridge.allow_llz_overlap を 1 に設定することに
     よって、この振る舞いを無効にすることができます。

     ACCEPT_RTADV と AUTO_LINKLOCAL インタフェースフラグは、
     net.inet6.ip6.accept_rtadv および net.inet6.ip6.auto_linklocal が 1 に設
     定されるときでさえ、if_bridge インタフェースのデフォルトによって有効にさ
     れないことに注意してください。

スパニングツリー
     if_bridge ドライバは、古いスパニングツリープロトコル (Spanning Tree Pro
     tocol (STP)) との後方互換性がある Rapid スパニングツリープロトコル (Rapid
     Spanning Tree Protocol (RSTP または 802.1w)) を実装しています。スパニング
     ツリーは、ネットワークトポロジでループを検出して、取り除くために使用され
     ます。

     RSTP は、プロトコルが、ループを作成しないで転送のためにすばやく遷移するた
     めの隣接しているスイッチで情報交換する、古い STP より速いスパニングツリー
     の集合を提供します。

     コードは、RSTP モードをデフォルトとしていますが、完全に後方互換性があるの
     で、古い STP ネットワークに接続された任意のポートをダウングレードします。
     ブリッジは、ifconfig(8)proto コマンドを通して、すばやい状態遷移なしで
     STP モードで強制的に動作することができます。

     ブリッジは、sysctl(8) を使用して net.link.bridge.log_stp 変数を有効にする
     ことによって、syslog(3) への STP ポートの変更をログ登録することができま
     す。

パケットフィルタリング
     パケットフィルタリングは、pfil(9) フレームワークを通してフックする任意の
     ファイアウォールパッケージと共に使用することができます。フィルタリングが
     有効にされるとき、ブリッジされているパケットは、発信インタフェースで内向
     き、ブリッジインタフェースで、と適切なインタフェースで外向きのフィルタを
     通過します。いずれのステージ (段階) も無効にすることができます。フィルタ
     リングの振る舞いは、sysctl(8) を使用して制御することができます:

     net.link.bridge.pfil_onlyip  pfil(9) に渡されない非 IP パケットの取り扱い
                                  を制御します。1 に設定すれば (ファイアウォー
                                  ル規則に従って) IP パケットが通過することの
                                  みを許可し、0 に設定すればすべての非 IP イー
                                  サネットフレームを無条件に通過することを許可
                                  します。

     net.link.bridge.pfil_member  1 に設定すれば着信と発信メンバインタフェース
                                  のフィルタリングを有効にして、0 に設定すれ
                                  ば、それを無効にします。

     net.link.bridge.pfil_bridge  1 に設定すればブリッジインタフェースのフィル
                                  タリングを有効にして、0 に設定すれば、それを
                                  無効にします。

     net.link.bridge.pfil_local_phys
                                  さらに、ローカルな行き先のパケットのために物
                                  理的なインタフェースでフィルタするためには 1
                                  に設定します。この機能を無効にするためには、
                                  0 に設定します。

     net.link.bridge.ipfw         1 に設定すれば ipfirewall(4) で layer2 フィ
                                  ルタリングを有効にして、0 に設定すれば、それ
                                  を無効にします。これは、dummynet(4) サポート
                                  を有効にする必要があります。ipfw が有効にさ
                                  れるとき、IPFW が二度実行されないように、
                                  pfil_bridgepfil_member は無効にされま
                                  す。これらは、必要なら、再び有効にすることが
                                  できます。

     net.link.bridge.ipfw_arp     ipfirewall(4) でレイヤ 2 ARP フィルタリング
                                  を有効にするためには 1 に設定し、それを無効
                                  にするためには 0 に設定します。ipfw が有効に
                                  されることが必要です。

     ARP と REVARP パケットは、pfil_onlyip が有効にされるとき、フィルタされる
     こと無しに転送され、他は、IP も IPv6 も転送されません。IPFW は mac-type
     を使用してイーサネットタイプをフィルタすることができるので、すべてのパ
     ケットは処理のためのフィルタに渡されます。

     ブリッジホストが起源であるパケットは、ルーティングテーブルで調べられるイ
     ンタフェースのフィルタによって見られます。

     ブリッジホスト行きのパケットは、パケットの宛先の MAC と等しい MAC アドレ
     スとのインタフェースのフィルタによって見られます。いくつかのブリッジメン
     バが同じ MAC アドレスを共有する状況があります (例えば、vlan(4) は、次のイ
     ンタフェースで接続します: それらは、現在親の物理的なインタフェースの MAC
     アドレスを共有します)。パケットの宛先 MAC アドレスが、パケットがシステム
     に入れられるインタフェースの MAC アドレスと等しい場合を除いて、それらの
     MAC アドレスを使用してこれらのインタフェースを区別することは不可能です。
     この場合は、フィルタは、このインタフェースの着信パケットを見ます。他のす
     べての場合では、パケットフィルタによって見られるインタフェースは、同じ
     MAC アドレスでブリッジメンバのリストから選択され、結果は、メンバの追加
     シーケンスと if_bridge の実際の実装に強く依存します。現在の if_bridge 実
     装によって選択された順序を当てにするのは勧められません: 将来、それは変更
     されるでしょう。

     以前のパラグラフは、次の図で最も良く例証されます。

     •   着信パケットの宛先の MAC アドレスは、nn:nn:nn:nn:nn:nn です。

     •   システムを入れたパケットのインタフェースは ifX です。

     •   ifX MAC アドレスは xx:xx:xx:xx:xx:xx, です。

     •   同じ MAC アドレス xx:xx:xx:xx:xx:xx がある他のブリッジメンバがあり得
         ます。

     •   ブリッジには、同じ MAC アドレス yy:yy:yy:yy:yy:yy を共有している 2 つ
         以上のインタフェースがあります。私たちは、それらを vlanY1, vlanY2 な
         どと呼びます。

     MAC アドレス nn:nn:nn:nn:nn:nnxx:xx:xx:xx:xx:xx と等しいなら、フィル
     タは、同じ MAC アドレスを運ぶ他のブリッジメンバがあっても、インタフェース
     ifX でパケットを見ます。しかし、MAC アドレス nn:nn:nn:nn:nn:nnyy:yy:yy:yy:yy:yy と等しいなら、フィルタによって見られるインタフェースは
     vlanYn の 1 つです。システム状態と if_bridge 実装の詳細に関する知識なしで
     実際のインタフェースの名前を予測することは不可能です。

     この問題は、単に vlan(4) のものでなく、同じ MAC アドレスを共有している任
     意のブリッジメンバのために生じます: それらは、ちょうどそのような状況の例
     として挙げます。したがって、利用者が、それらのインタフェース名に基づく
     ローカルに向けられたパケットのフィルタが欲しいなら、この意味を知っている
     いるべきです。説明した状況は、少なくとも IP 転送を行っているフィルタリン
     グブリッジで現れます。そのような場合のいくつかでは、ブリッジメンバではな
     く、if_bridge インタフェースだけに IP アドレスを割り当てるほうがより良い
     です。net.link.bridge.pfil_local_phys を有効にすることで、利用者は、物理
     的なインタフェースで追加のフィルタリングを行うことができます。

使用例
     次がファイル /etc/rc.conf に置かれるとき、``bridge0'' と呼ばれるブリッジ
     が作成され、ブリッジのためのインタフェース ``wlan0'' と ``fxp0'' が追加さ
     れ、次にパケット転送を有効にします。そのような設定は、(802.11 インタ
     フェースがアドホック (ad-hoc) モードであることを仮定して) 簡単な 802.11
     からイーサネットブリッジを実装するために使用されるかもしれません。

           cloned_interfaces="bridge0"
           ifconfig_bridge0="addm wlan0 addm fxp0 up"

     転送されるパケットへのブリッジのために、すべてのメンバインタフェースとブ
     リッジは、作動している必要があります。また、上記の例が必要でしょう:

           create_args_wlan0="wlanmode hostap"
           ifconfig_wlan0="up ssid my_ap mode 11g"
           ifconfig_fxp0="up"

     2 つの 4 ポートイーサネットボードがあるシステムを考えます。次によって、有
     効にされた Rapid Spanning Tree ですべての 8 つのポートから成るブリッジが
     作成されます:

           ifconfig bridge0 create
           ifconfig bridge0 \
               addm fxp0 stp fxp0 \
               addm fxp1 stp fxp1 \
               addm fxp2 stp fxp2 \
               addm fxp3 stp fxp3 \
               addm fxp4 stp fxp4 \
               addm fxp5 stp fxp5 \
               addm fxp6 stp fxp6 \
               addm fxp7 stp fxp7 \
               up

     メンバポートの間でブリッジすることと同時に通常のホストインタフェースとし
     て bridge (ブリッジ) を使用することができます。この例では、bridge (ブリッ
     ジ) は、em0 と em1 を接続して、DHCP を通して IP アドレスを受信します:

           cloned_interfaces="bridge0"
           ifconfig_bridge0="addm em0 addm em1 DHCP"
           ifconfig_em0="up"
           ifconfig_em1="up"

     ブリッジは、EtherIP プロトコルを使用して IP インターネットを超えてイーサ
     ネットにトンネル化することができます。これは、暗号化された接続を提供する
     ために ipsec(4) と組み合わせることができます。gif(4) インタフェースを作成
     し、トンネルのためのローカルとリモートの IP アドレスを設定します。これら
     はリモートブリッジでは逆となります。

           ifconfig gif0 create
           ifconfig gif0 tunnel 1.2.3.4 5.6.7.8 up
           ifconfig bridge0 create
           ifconfig bridge0 addm fxp0 addm gif0 up

     FreeBSD 6.1, 6.2, 6.3, 7.0, 7.1 と 7.2 には、EtherIP プロトコルでバグがあ
     ることに注意してください。その他の詳細と次善策については、gif(4) マニュア
     ルページを参照してください。

関連項目
     gif(4), ipf(4), ipfw(4), pf(4), ifconfig(8)

歴史
     if_bridge ドライバは FreeBSD 6.0 ではじめて登場しました。

作者
     bridge ドライバは、最初に、Greensboro の University of North Carolina で
     大学生の自主研究の一部として Jason L. Wright <jason@thought.net> によって
     書かれました。

     if_bridge ドライバのこのバージョンは、Jason R. Thorpe
     <thorpej@wasabisystems.com> によってオリジナルバージョンから大幅に変更さ
     れました。

     Rapid Spanning Tree Protocol (RSTP) のサポートは Andrew Thompson
     <thompsa@FreeBSD.org> によって追加されました。

バグ
     if_bridge ドライバは、ブリッジデバイスと正確に同じインタフェース MTU サイ
     ズで、現在イーサネットとイーサネット-類似 (例えば、802.11) ネットワークデ
     バイスのみをサポートします。

FreeBSD 12.2                   October 16, 2017                   FreeBSD 12.2

Table of Contents

FreeBSD マニュアル検索