LANE 経由の HSRP の実装

概要

このドキュメントは、LAN エミュレーション（LANE）環境でホットスタンバイ ルータ プロトコル（HSRP）を実装している場合に発生する可能性のある問題の概要説明を目的としています。 LANE 上での HSRP の詳細について説明し、さまざまなシナリオでのトラブルシューティングのヒントを示します。

前提条件

要件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

背景説明

要約すると、HSRP の目的はアクティブな 1 つが失敗したデフォルト ゲートウェイとして単一「仮想 な」ルータを使用するようにサブネットのホストがすることですデフォルト ゲートウェイおよびバックアップルータのロールを担うアクティブルータを選ぶために–マルチプルルータは HSRP プロトコルに加わります。 結果は物理的 な最初ホップ ルータが変更してもデフォルト ゲートウェイが稼働するために常にようであることです。 HSRP の完全な記述は RFC 2281 で見つけることができます 。

HSRP はマルチアクセス上の使用のために設計されていますか、マルチキャストするか、または可能な LAN （一般的に イーサネット、トークン リング、またはファイバ分散データ インターフェイス[FDDI]）ブロードキャストしました。 従って、HSRP は ATM LANE をはるかに越えてはたらく必要があります。

HSRP および LANE 相互対話を含む複数の状況は起こるかもしれません:

1. Cisco IOS® ソフトウェア リリース 11.2 以来、HSRP は LANE に「ネイティブで」動作できます。 この場合、standby コマンドは LANエミュレーション クライアント（LEC）が常駐する ATM サブインターフェイスで直接設定されます。 次の実例を参照して下さい。

   

2. また HSRP が LAN インターフェイスで設定されるが、サブネットの一部は LANE クラウドに及びます例があります。 これは ATMインターフェイスの LANスイッチの中間物によって達成されます（LANE モジュールが付いている Cisco Catalyst 5000 のような）。 次の実例を参照して下さい。

   

3. 最終的には、何人かの HSRP ルータが LANE 接続の他が LANスイッチの背後にある LAN にある「ハイブリッド」状況があり。

   

ケース スタディ

1) ネイティブ HSRP over LANE

HSRP に加わっているルータは互いについて学習し、アクティブ および スタンバイのルータを選ぶためにブロードキャストメディア上の「HELLO」パケットを送信します。 これらのパケットは 1 の Time To Live （TTL）のマルチキャスト アドレス 224.0.0.2 および 0100 5E00 0002 のマルチキャスト目的地 MAC アドレスに送信されます。

LANE は新規発行をここにもたらしません従って RFC 2281 に説明がある詳細は まだ– HELLO の交換によって…、不意の一撃適用し、パケットを、アクティブ および スタンバイのルータ選ばれます辞職します。

helloパケットはブロードキャスト アンノウン サーバ（BUS）に送信され、以下はなんと debug atm packet かです（マルチキャスト前方バーチャル サーキット[VC]で）および debug standby は明らかにします:

Medina#show run
[snip]interface ATM3/0.1 multipoint
 ip address 1.1.1.3 255.255.255.0 
 no ip redirects 
 no ip directed-broadcast
 lane client ethernet HSRP
 standby 1 ip 1.1.1.1
[snip]

Medina#show lane client
LE Client ATM3/0.1  ELAN name: HSRP  Admin:
up  State: operational
Client ID: 2                
LEC up for 14 minutes 34 seconds
ELAN ID: 0
Join Attempt: 7
Last Fail Reason: Config VC being released
HW Address: 0050.a219.5c54   Type: ethernet            
Max Frame Size: 1516
ATM Address: 47.00918100000000604799FD01.0050A2195C54.01
VCD  rxFrames  txFrames  Type      ATM Address
  0        0         0  configure  47.00918100000000604799FD01.00604799FD05.00
 12        1         3  direct     47.00918100000000604799FD01.00604799FD03.01
 13        2         0  distribute 47.00918100000000604799FD01.00604799FD03.01
 14        0       439  send       47.00918100000000604799FD01.00604799FD04.01
 15       453        0  forward    47.00918100000000604799FD01.00604799FD04.01

Medina#show atm vc 15
ATM3/0.1: VCD: 15, VPI: 0, VCI: 40
UBR, PeakRate: 149760
LANE-LEC, etype:0xE, Flags: 0x16C7, VCmode: 0x0
OAM frequency: 0 second(s)
InARP DISABLED
Transmit priority 4
InPkts: 601, OutPkts: 0, InBytes: 48212, OutBytes: 0
InPRoc: 0, OutPRoc: 0, Broadcasts: 0
InFast: 0, OutFast: 0, InAS: 0, OutAS: 0
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0
OAM cells received: 0
OAM cells sent: 0
Status: UP
TTL: 0
interface =  ATM3/0.1, call remotely initiated,
call reference = 8388610
vcnum = 15, vpi = 0, vci = 46, state = Active(U10)
 , multipoint call
Retry count: Current = 0
timer currently inactive, timer value = 00:00:00
Root Atm Nsap address: 47.00918100000000604799FD01.00604799FD04.01
, VC owner: ATM_OWNER_UNKNOWN

重要性の LANエミュレーション クライアント （LEC）が BUS に受け取る何を検知 して います（たとえば、順方向のマルチキャストを通って）:

Medina#debug atm packet 
interface atm 3/0.1 vcd 15
ATM packets debugging is on
Displaying packets on interface ATM3/0.2 VPI 0, VCI 46 only
Medina#debug standby
Hot standby protocol debugging is on
*Feb 18 06:36:05.443: SB1:ATM3/0.1 Hello in 1.1.1.2
Active pri 110 hel 3 hol 10 ip 1.1.1.1
*Feb 18 06:36:08.007: SB1:ATM3/0.1 Hello out 1.1.1.3
Standby pri 100 hel 3 hol 10 ip 1.1.1.1
*Feb 18 06:36:08.439: ATM3/0.1(I):
VCD:0xF VPI:0x0 VCI:0x40 Type:0xE, LANE, ETYPE:0x000E
LECID:0x0004 Length:0x4A
*Feb 18 06:36:08.439: 0004 0100 5E00 0002 0000 0C07
AC01 0800 45C0 0030 0000 0000 0111 D6F8 0101
*Feb 18 06:36:08.443: 0102 E000 0002 07C1 07C1 001C
AAEE 0000 1003 0A6E 0100 6369 7363 6F00 0000
*Feb 18 06:36:08.443: 0101 0101 0001 0001 000C

この HEX ダンプは次に変換します:

VCD:0xF VPI:0x0 VCI:0x28: VCD number 15, VPI=0 and VCI=400
004: LECID from the sender of the packet
0100 5E00 0002: Destination MAC address for HSRP hellos
0000 0C07 AC01: Virtual MAC address of HSRP (the last octet is actually the standby group number)
0800: Type = IP
45C0 0030 0000 0000 0111 D6F8: IP header - UDP packet
0101 0102: Source IP = 1.1.1.2
E000 0002: Destination IP = 224.0.0.2
07C1 07C1 001C AAEE: UDP header - Source & Destination ports = 1985
00: HSRP version 0
00: Hello packet (type 0)
10: State (of the sender) is Active (16)
03: Hellotime (3 sec)
0A: Holdtime (10 sec)
6E: Priority = 110
01: Group
00: Reserved
6369 7363 6F00 0000: Authentication Data
0101 0101: Virtual IP address = 1.1.1.1

顕著である何が helloパケットがバーチャルMACアドレス（VMAC）が付いているアクティブルータによって送信元MACアドレスとしてソースをたどられることです–転送するラーニング ブリッジ（スイッチ）がこれらのパケット VMAC の適切な場所を用いるコンテンツ アドレス可能メモリ（CAM）テーブルをアップデートしますのでこれは好ましいです。

HSRP へのキーは IP アドレスと MAC アドレス間のマッピングの内にあります。

単純式では、仮想 IP アドレスはバーチャルMACアドレスに永久に結合 され、心配する唯一の側面はこのバーチャルMACアドレスがどこに見つけられるかスイッチが常に確認することです。 これは hellos が VMAC によってソースをたどられるので確認されます。

Medina#show standby
ATM3/0.1 - Group 1
  Local state is Standby, priority 100
  Hellotime 3 holdtime 10
  Next hello sent in 00:00:00.006
  Hot standby IP address is 1.1.1.1 configured
  Active router is 1.1.1.2 expires in 00:00:08
  Standby router is local
  Standby virtual mac address is 0000.0c07.ac01

もう一つのオプションはルータが仮想 IP アドレスにマッピング される 焼き付けられいた（standby use-bia）アドレスを使用することです。 この場合、一定時間にわたりバーチャルIP と MAC アドレス変更間のマッピング–新たにアクティブなルータは新しく仮想 な IP-to-MAC アドレス マッピングをアナウンスするためにアドレス解決プロトコル （ARP）を送信します。 ARP は非要請 ARP応答単にです。-

注: ある特定の（より古い） IP スタックは ARP を理解しないかもしれません。

Medina#show standby
ATM3/0.1 - Group 1
  Local state is Standby, priority 100, use bia
  Hellotime 3 holdtime 10
  Next hello sent in 00:00:02.130
  Hot standby IP address is 1.1.1.1 configured
  Active router is 1.1.1.2 expires in 00:00:09
  Standby router is local
  Standby virtual mac address is 0050.a219.5c54

注: LANE を導入するために、キーは VMAC にネットワーク サービス アクセス点の（NSAP）アドレス マッピングを仮想 な IP-to-MAC アドレス マッピングの上にそれ、そこにちがいありません説明したにです。 このマッピングは LAN Emulation-Address Resolution Protocol （LE-ARP） プロセスによって単に解決されます: アクティブなゲートウェイにトラフィックを送信 したい LEC は VMAC 使用します（または物理的 な MAC のために焼き付けられた MAC アドレス[BIA を使用している]場合） LE-ARP を。

新しいルータがアクティブになるとどうなるかこの場合考慮して下さい: アクティブなゲートウェイの新しい場所（新しい VMAC-to-NSAP マッピング）の知らせられるべき LEC のために LE-ARPテーブルは修正する必要があります。 デフォルトで、LE-ARP エントリは 5 分毎に時間を計りますが、このタイムアウトにほとんどの場合、依存は受け入れられないです–統合はファーストである必要があります。 ソリューションは新しい活動状況を仮定する LEC が LANE バージョン 1 かバージョン 2 を実行しているかどうかに左右されます（LANE 仕様については ATM Forum.com を参照して下さい）:

• LANE バージョン 1

  ルータは RFC 2281 に説明があるステップに加えてアクティブに、なるとき 新しく VMAC-to-NSAP な アドレスバインディングを知られているようにするために LE-NARP を送信します。 LANE 仕様に従って、LE-NARP を受け取り次第、LEC は MAC アドレスに相当して LE-ARP エントリを削除するか、またはアップデートすることを選択するかもしれません。 Cisco 内の傾向はより多くの保守的なアプローチを採用し、LE-ARP エントリを削除することを選択することです–これにより再 LE ARP に 5 分 タイムアウトを待たないで LEC をすぐに引き起こします。

  注: このソリューションは下記の互換性の問題を引き起こすかもしれません。

• LANE バージョン 2

  LANE バージョン 2 では、LANE バージョン 1 のある特定の欠点は軽減されました: LE-NARP はターゲットなしの LE-ARP およびソースなし LE-NARP によって置き換えられました。 ターゲットなしの LE-ARP は手段としてソースなし LE-NARP 目的が廃止既存の MAC-to-NSAP な アドレスバインディングをすることである一方新しいバインディングをアドバタイズするために見られるかもしれません。 これが設定されている方法は、そしてアクティブからスタンバイに変更すればルータがスタンバイからアクティブに変更すれば（MAC-to-NSAP マッピングをアドバタイズするのにこれが使用されています）、それ送信すればソースなし LE-NARP を、ターゲットなしの LE-ARP を送信することです（MAC-to-NSAP バインディングを廃止するのにこれが使用されています）。

問題-インターオペラビリティ

より詳細なチェックに値するには十分に頻繁に起こる問題があります。 LANE バージョン 1 仕様は LE-NARP が「古いバインディングを規定 する必要があることを示します」（古い）ターゲット NSAP （T-NSAP）アドレスの規定によって廃止されています。 通常、HSRP に加わっているルータは互い間のデータ ダイレクトを維持しません。

従って、新たにアクティブなルータはよりよく知らないのでこの情報およびこのフィールドに入力しないことを選択することを知りません。 これは仕様の穏やかな違反であり、T-NSAP address フィールドがすべてのゼロである場合何人かのベンダーはこれらのパケットを無視します。 残念ながら、これのための回避策がありません– LE-NARP が無視される場合、正しいバインディングが学習される前に LE-ARP タイムアウト（一般的に 5 分）に頼って下さい。

LE-ARP か LE-NARP はすべてのゼロの T-NSAP address フィールドと送信 されるとき、呼ばれます「targetless と」。 、LANE バージョン 2 （および Multiprotocol over ATM [MPOA]の出現で上で見られるように）、これになった規格があり、問題はあることを解決します。

これは問題が起こるかもしれないところにされることが LANE バージョン 1 でです:

• ルータが「古いバインディングを知っている場合」、同様に仕様に従うかもしれません。 これらのデバッグはコントロールディストリビュート VC で今行われます:

  ATM0/0.1(I):
  VCD:0xD Type:0x6, LANE, ETYPE:0x0006 LECID:0xFF00 Length:0x70
  FF00 0101 0008 0000 0000 0018 0003 0000 0000 0000 0000 0000 0001 0000 0C07
  AC01 4700 9181 0000 0000 101F 2D68 0100 50A2 195C 5401 0000 0000 4700 9181
  0000 0000 101F 2D68 0100 102F FBA4 0101 0000 0000 0000 0000 0000 0000 0000
  FF00: Marker = Control Frame
  0101: ATM LANE version 10
  008: Op-code = LE_NARP_REQUEST
  0000: Status
  0000 0018: Transaction ID0003: Requester LECID0000: Flags
  0000 0000 0000 0000: Source LAN destination 
  (not used for an LE-NARP)
  0001 0000 0C07 AC01: Target LAN destination
  (the 0001 indicates a MAC address as opposed to a route descriptor)
  4700 9181 0000 0000 101F 2D68 0100 50A2 195C 5401: Source NSAP address
  (new NSAP address to be bound)
  0000 0000: Reserved
  4700 9181 0000 0000 101F 2D68 0100 102F FBA4 0101: Target NSAP address
  (old NSAP address to be rendered obsolete)

• 「古いバインディングを知らない場合」、全力を尽くし、少なくとも新しいものをアドバタイズします:

  ATM0/0.1(I):
  VCD:0xD Type:0x6, LANE, ETYPE:0x0006 LECID:0xFF00 Length:0x70
  FF00 0101 0008 0000 0000 0014 0003 0000 0000 0000 0000 0000 0001 0000 0C07
  AC01 4700 9181 0000 0000 101F 2D68 0100 50A2 195C 5401 0000 0000 0000 0000
  0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

  注: 今回 T-NSAPアドレスはブランクです。

再度、動作は仕様の内に LANE バージョン 2 クライアントを使用するとき完全にあります。

注: ソフトウェアは MPOA をまたサポートする LANE バージョン 2.をサポートします。

トラブルシューティングのヒント

ネイティブ HSRP over LANE は T-NSAP に欠けている LE-NARP による潜在的な相互運用性 の 問題以外余りにも多くの問題を発生させるべきではありません。

アクティブまたはスタンバイであるかどうかルータに確かめることで難しさがあったら、hellos が両側で見られるかどうか見る debug standby コマンドを使用して下さい。 そうでなかったら、それから BUS はおそらく正しくパケットを転送していません。

2) LANE の後ろのルータ上の HSRP

状況は HSRP が LANE クラウドの後ろにあるルータの LANE インターフェイスで設定されるとき図 2.に示すようにより複雑になります。

注: この図は論理的に接続されるルータが非ATM であるというファクトを描写します。 それは LANスイッチに別途のデバイスに必ずしもあるなりません（Cisco Catalyst 5000 のルートスイッチモジュール[RSM は]このケースの下で落ちます）。

再度、問題は LANE によって課される MAC アドレスに NSAP アドレス マッピング することが原因で起こります。 （別の NSAP アドレスに対応する新しいルータがアクティブになるとき） VMAC がデバイスに切り替えるとき上で注意されるように、LANE クラウドに接続されるすべてのデバイスは知識のある必要があります。 これはネイティブ HSRP over LANE 環境で LE-NARP 設定されます（またはターゲットなしの LE-ARP の）使用によってかなり容易に。

この第 2 ケースの問題は、それらもっぱら設計されています LEC があらゆるレイヤ3 情報（IP）に気づいていないことです 2 つの異なるメディアの間のブリッジパケットに（LAN および ATM）。

たとえばルータ 2 が突然アクティブになったら、図 2、そして LANスイッチが 2 新しい VMAC-to-NSAP マッピングについての ATM （LANE）クラウドに接続されたすべてのデバイスを知らせることは好ましいです。 LANスイッチ 2 の LEC はそれの後ろにあるすべての MAC アドレスのために proxying 言われます。 これらの MAC アドレスにトラフィックを送信 したい LANE を渡るデバイスはこの LEC の方に設定される直接ダイヤルを通ってそうする必要があります。 直観的に、1 つはルータ 2 が ACTIVE 状態を仮定するとすぐ、送信元MACアドレスとして VMAC の hellos のソースをたどり始めるのでこれが大きい問題ではないと考える可能性があります。 この情報はすべての LANスイッチによってそれから学ばれ、すべては急速にコンバージします。 これは非 LANE 環境で本当ですが、LANE は次の理由により特別です:

LANE では、データパケットは通常 2 つのパスを通して送信することができます:

• このパケットが宛先が既知 NSAP にマッピング された、そして直接ダイヤルが既に確立されていたらユニキャストなら直接ダイヤル。

• 未知のユニキャストおよびマルチキャストのための BUS。

従って、同じ MAC アドレスは 2 つの異なるパス上の LANスイッチによって受信されるパケットの出所を特定します。 既知 ユニキャストが直接ダイヤルを通って着く一方マルチキャストおよび未知のユニキャストは BUS を通って着きます。 特定の努力がなされなかった場合、LANスイッチは受信された最後のパケットによって直接ダイヤルまたは BUS 上のこの MAC アドレスを学習し続けます。 これは BUS が未知のユニキャストまたはマルチキャストのためのパケットを送信するためにだけ使用する必要があるので望ましくないです。 この段階では、何も BUS に学習されませんが、現実には、次の作業を行うことを選択して下さい:

Packets received over the BUS are marked with the Conditional Learn (CL) 
bit set to 1(this bit is in a control overhead specific to Cisco LAN switches). The LAN switch 
will only update its CAM table with this entry if it does not already have an entry for this 
MAC address (in this VLAN). The idea is that if a switch receives a packet from a source 
that it does not know about, at least it will now know that it is located somewhere across 
the LANE cloud. Future packets for that MAC address will be forwarded to the BUS only as 
opposed to being flooded in the entire VLAN.

例に戻るために、ルータ 2 がアクティブになるときこの ELAN のすべての LEC が既にルータ 1 のための VMAC-NSAP マッピングに前に気づいていると仮定することは安全です。 すべての LANスイッチはまた VMAC が LANスイッチ 1.の後ろにあることを確認します。 ルータ 2 がアクティブになり、helloパケットを出所を特定するとき、これらは BUS 上の LANE クラウドに転送されます。 従って、LANスイッチのどれもこの新しい情報の CAMテーブルをアップデートしないし、LANスイッチが「このエントリ（5 分であるデフォルト エージング）について忘れている」までこの VMAC に送信されたすべてのパケットは誤った方向に導かれます。

注: 全面的な接続は 10 分までの間 LEC の LE-ARP エージングタイマーがまたデフォルトで 5 分であるので実際に失われるかもしれません。 MAC アドレスのためのエージングタイマーの値を小さくすることは助けますが、実際に問題を解決しません。

これのための 2 つのソリューションがあります:

1. LANスイッチがシスコ以外である場合、上述されている方式に戻して下さい: 焼き付けられたアドレスの使用。 スイッチ オーバーが発生する時はいつでもだけ helloパケットの出所を特定すればのにルータが MAC アドレスを使用すればおよびそれ仮想 IP アドレスがマッピングを変更すれば、これらの MAC アドレスがどこにに関して見つけられるか可能な限り混合はありません。

2. LANスイッチが Cisco Catalyst である場合、カバーされる Distributed Defect Tracking System （DDTS）によって提供される修正による Cisco バグ ID CSCdj58719 （登録ユーザのみ）および CSCdj60431 （登録ユーザのみ）で VMAC を使用し続けて下さい。

   要するにルータは ACTIVE 状態を仮定するときその ARP （非要請 ARP応答）に加えて RFC 2281 に従って、 ルータ 送信 します 0100.0CCD.CDCD の宛先MAC アドレスとの第 2 ARP を送信 します。 Cisco Catalyst はこのパケットを受信するとき 2 つの事柄をします:

   • それは VMAC のために持っている LE-ARP エントリを削除します。

   • それは BUS 上の VMAC を学びます。

このような理由で、さまざまな LEC にこれ以上の古い LE-ARP エントリがあり、VMAC の新しい場所はすべてのスイッチに伝搬します（たとえば、LANE クラウドを越えて）。 正しくはたらくこれのために次の最小ソフトウェア要件は満たす必要があります:

• ルータはバージョン 12.0 少なくとも Cisco IOS ソフトウェア リリース 11.1(24)、バージョン 11.2(13)、またはすべてがなければなりません。

• LANE モジュールは少なくともバージョン 3.2(8)を備えなければなりません。 11.3W4 バージョン およびそれ以降は受諾可能です。

Cisco は最新のソフトウェアを使用することを推奨します。

3) 混在環境

混在環境で起こることができる 1 つの最終的な問題があります。 上でシナリオを奪取 し、直接接続された LANE エンド デバイスを追加して（ルータかワークステーション）、エンド デバイスは同じ方法次 シナリオ1 アクティブなゲートウェイの位置 の 変更について知らせられる必要があります。 新たにアクティブなルータがスイッチの後ろで接続される場合、唯一のソリューションはルータに代わって LE-NARP を送信するスイッチ自体のためであり、これは丁度するべきものです。

上述されているステップに加えて唯一の目的が VMAC のための LE-ARP キャッシュを消去するためにである LANE バージョンを 2）実行している場合 Cisco Catalyst が 0100 0CCD CDCD に向かうパケットを取れば LE-NARP （ソースなし LE-NARP を送信します。

結論

示されるように、HSRP over LANE は原則的にはうまく作動します上述されている拔け穴の 1 つに落ちている場合、特定の状況下で、ユーザは接続を短い間失う場合があります。

重要： HSRP over LANE の成功を確認するために、少なくともこれら二つの推奨事項に従って下さい:

• 安全であるために、少なくとも Cisco IOSソフトウェアリリースのバージョン 12.0 にアップグレードして下さい。

• mult ベンダー環境では、LANE バージョン 2 か問題を回避するために焼き付けられたアドレスを使用することが最善です。

関連情報

• ATM テクノロジーに関するサポート ページ
• テクニカルサポート - Cisco Systems