名称

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 として使用されます。すべての追加メンバは、正確に同じ値を持つためにに必要です。

TXCSUM ケーパビリティは、ブリッジに追加された任意のインタフェースで無効にされ、インタフェースが再び取り除くとき、それは復旧します。

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 Protocol (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) を使用して制御することができます:

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:nn が xx:xx:xx:xx:xx:xx と等しいなら、フィルタは、同じ MAC アドレスを運ぶ他のブリッジメンバがあっても、インタフェース ifX でパケットを見ます。しかし、MAC アドレス nn:nn:nn:nn:nn:nn が yy: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) マニュアルページを参照してください。

歴史

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

作者

bridge ドライバは元々、Greensboro の 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) ネットワークデバイスのみをサポートします。

YOS OPENSONAR

名称

書式

解説

IPV6 サポート

スパニングツリー

パケットフィルタリング

使用例

関連項目

歴史

作者

バグ