単に擬似ブリッジを実装したいだけでしたら、 数節飛ばして「実装する」まで進んでください。 しかし実際の動作に関して少々読んでおくのは、 賢いことだと思います。
「擬似ブリッジ」は異なる動作をし、 ブリッジというよりは見えないルータに近いのですが、 しかしブリッジと同様、ネットワークの設計にはほとんど影響を与えません。
実際にはブリッジではない、ということの利点は、 パケットが実際にカーネルを通り、 したがってフィルタ・修正・リダイレクト・経路変更などができる、 というところにあります。
実際のブリッジにもこれらの機能を持たせることはできますが、 イーサネットフレームダイバータのような特殊なコードが必要だったり、 あるいは前述したようなパッチが必要です。
また、ip_forwarding フラグを ON にするのも忘れないように! 本物のブリッジにはこのフラグは必要ないため、 移行してきたときにはこのフラグは OFF になっているかもしれません。
もうひとつ移行の際に注意しなければならないのは、 ネットワークの各コンピュータの ARP キャッシュをクリアしなければならない、 ということです。ARP キャッシュには、 前の古いブリッジのハードウェアアドレスが残っている (そしてそれはもう正しくない) でしょうから。
Cisco では、これは 'clear arp-cache' コマンドで実行できます。 Linux では 'arp -d ip.address' です。 キャッシュが期限切れになるのを待っていても良いですが、 これは比較的時間がかかります。
これを高速化するには、素晴らしいツール 'arping' が使えます。 これは多くのディストリビューションで 'iputils' パッケージに入っています。 arping を用いると、要求のなかった (unsolicited な) ARP メッセージを送りつけることができ、 リモートの ARP キャッシュを更新できます。
これは非常に強力なテクニックで、悪者がルーティングを崩壊させるのにも使えます!
Note: Linux 2.4 では、この「要求のなかった ARP メッセージ」を送信する前には、 'echo 1 > /proc/sys/net/ipv4/ip_nonlocal_bind' を実行する必要があるかもしれません。
また、ネットマスクを省略して経路を指定するクセのある (あった) 人は、 作業の結果ネットワーク設定が壊れてしまうかもしれません。 特定のバージョンの route はネットマスクを正しく推量していたかもしれませんし、 何も表示することなく間違っていたかもしれません。 前述したような外科手術的なルーティングをするときには、 ネットマスクをチェックするのは「生死」に関わります。