ネットワークの冗長化、個人ベースではまずやりませんので（といいつつも家の中の回線二重化しています、障害時は手動で切り替えですが）、いい勉強になります。
STP：Spanning Tree Protocol、新規ネットワーク構築ではあまり使われなくなってきているそうです。その辺りの解説も出てくるようです。こここではスパニングツリーの問題点として設定の面倒さ（たしかにハブに設定する項目多数ありますし）と、STPを使う場合にはループになっている経路が予備経路としてブロックされていて帯域的に損になっている（使われない）点の2点が挙げられています。確かに多重化の理想としては故障時の縮退運転ですから、そういう意味からは予備回線として普段使われない回線が出てくるのはいやな点ですね。記事には書かれていませんでしたが、後の解説読むと障害発生時の切り替えの遅さもSTPが使われなくなった理由のひとつのようです。
リングプロトコルはSWをリング上に接続して（リングトポロジ限定）2重経路を作って、経路の監視、切り替えを行なうもののようです。が、図をみてもこれが動作することが理解できません。SWの単一ポートダウンには対応できるのでしょうが、SW自体のダウンが起きると結局そのSWが落ちたままになって、そのSWに接続しているホストは通信不能になるように見えます。一応監視プロトコルはRFC3619 EAPS （Ethernet Automatic Protection System）、またはベンダーの独自プロトコルだそうで。
RFC3618見ると、末端のSWというより、基幹部分のネットワークの多重化を想定しているもののようですね。基幹部分をリングトポロジで構成してその先にサブネットワークが繋がるイメージのようです。このプロトコルで制御されるリングをEAPSドメインと呼んでいます。EAPSドメインを構成するSWは2ポートをリングの構築に使います（まあ当然ですね）。で、普段はその一方（プライマリ）だけを使い他方（セカンダリ）はブロックされていて、障害を検出（アラート＆ポーリング）するとプライマリからセカンダリへの切り替えが行なわれる、というもののようです。特徴はこの切替が極めて高速に行なわれる（最短で50ミリ秒とか）点ですね。STPは切り替えに時間がかかるのが難点でしたから、これは優位な点でしょう。
リンクアグリゲーションはもともとはSW間の通信帯域を稼ぐための技術でしたが、冗長化手法としても用いられるようです。これもポート、回線のダウンには対応できますがSWダウンには駄目ですね。しかし正常時には倍の帯域が使えて、故障時には縮退運転になるという、正しい冗長化の手法になっています。
他にもベンダ独自の冗長化技術があるようです。ここではCISCOの Flex Linkが紹介されていました。しかしこういうのはマルチベンダ化に耐えるかどうかも重要なポイントなんですがね。メーカ系の解説だとそういう都合の悪いことは書かない傾向があります。困ったものです。STPあたりであればどのベンダーでもサポートしているのでしょうが、こういう新プロトコルですとサポート状況はどのようなものなのでしょうね。それとも単一ベンダで揃える（結果特定ベンダ依存になる）のが最近のトレンドなのでしょうか？
RFC2338のVRRP（Virtual Router Redundancy Protocol）、およびスタック（というのは一般用語すぎるので不適切かと思いますが）の解説です。記事ではルータの冗長化の面から解説していますが、RFC2338では、エンドノードのデフォルトルータ設定を変更しないで冗長化ができる、すなわちデフォルトルータの冗長化、として解説されています。VRRPではデフォルトルータ相当のものを仮想ルータと呼び、フェイルオーバ検出によって複数のルータで仮想ルータの役割を引き継ぐためのプロトコルを提示しています。
ちなみにRFCでは似た目的を持ったプロトコルとしてCISCOのHot Standby Router Protocol [HSRP]、DECのIP Standby Protocol [IPSTB]を挙げています。
VRRPのキモは仮想ルータとして実在のルータとは異なったIPアドレス、MACアドレスを用意して、実在のルータに割り付けるところですね。障害等によって仮想ルータが切り替わった場合でもエンドノードからは同一のIP/MACアドレスでアクセスできるので遅滞なく通信を継続することが可能になっています（途中にSWHUBが入っているとMACアドレスを変えるとまずいので）。ルータがUNIXマシンあたりで構成されていたなら、このあたりの切替制御、スクリプトだけで実現できますしね。多分初期実装ではVRRPで通信しあうデーモンと切り替えのスクリプトの組み合わせで実装されていたのでしょう。
VRRPですが、マルチホームのUNIXマシンをルータにしている場合にはこれだけで特に問題は起きないのですが、ルータがSWHUBの機能を持っていると、ループが構成されてしまいます。このためSWHUB機能を持ったルータの場合にはSTP等と併用されるようです。
VRRPですが、これもマスタとバックアップ機の構成で、普段はマスタしか使われません。最近の発想ではこれはもったいない構成なので、通常時には２台ともが使用されてして、故障時に縮退モードとして、片肺動作になるような構成の方が資産的には好ましい構成になります。
記事では、このような構成の例としてCISCOのVSS（Virtual Switching System）が紹介されています。CISCOの製品紹介読むとクラスタ化されたルータ、といったイメージになっているようですね。ついでに前出のSWHUBのリンクアグリゲーションによる多重化構成と組み合わせて、無故障のネットワークを提供するようになっているようです。まあ、ベンダおまかせにはなりますが、たしかにこれは楽でよさそうです。
OSPFなどの動的経路構成のプロトコルを使うことによって、経路レベルでの冗長化を図ることができます。ただ、これは複数の機器群での管理になるため、設定が大変で、信頼性を上げるための工夫自体が（設定等の難しさによって）信頼性の低下をもたらす面もあるようです。
そこで出てくるのが機器自体を多重化して、単一の（固定の）経路で信頼性を担保しようという動きです。上の記事で出てきたCISCOのクラスタ化されたルータなんかもそういう方向の構成です。記事ではアラクサラのフォールト・トレラントSWが紹介されています（Alaxalaのフォールト・トレラント・スイッチ解説）。たしかにこの構成なら経路設定は静的なままでも多重化構成による高い信頼性が得られます。難点は、単一ベンダ依存になるあたりでしょうか。ネットワーク機器ではなくインフラを購入するのだと割り切れば、ユーザ企業レベルであれば単一ベンダ構成でも悪くないのかも知れません。
負荷分散装置の話とサーバ側のNICの多重化の話との二本立てになっています。
負荷分散装置（ロードバランサー）はアクセス数の多いサイトではもう標準的に使われているのではないでしょうか。この記事では個別の装置固有の話は無しで、負荷分散のためのアルゴリズム（というか分散のルール）の解説にとどまっています。
記事では負荷分散基本ルールとして (1) 順番、(2) 通信の状態、(3) サーバリソース、を挙げていますが通信の状態とサーバリソースは一部被っていそうです。初期のWEBベースの負荷分散では、DNSラウンドロビンによる分散なんかもありましたが、現在ではWEBアクセスでのセッション維持までを可能にした負荷分散になってきていると思います。
OSSでの負荷分散システムの例としてLinux Virtual Server Project （日本語翻訳サイト、日本語翻訳サイトはインフォサイエンス提供、ただ翻訳の質は微妙でところどころに変な訳が見受けられます。チュートリアル単独の日本語訳もあります。こちらはVA Linux の翻訳で質は高いですね。ただ最終更新が2004-03なのでどこまで up-to-date か微妙なところです）が挙げられていますが、このページ読むとTCPコネクションベースでの負荷分散、をうたっていますね（そのためカーネルレベルで弄っているようです）。
サーバサイドの通信多重化についてはNICの多重化の話が挙げられているのですが、これに関しては解説はほぼ皆無で、NICベンダ、サーバベンダが提供する、と書かれただけです。この部分は少々残念です。
