LANE을 통한 HSRP 구현

다운로드 옵션

PDF (261.0 KB)
다양한 디바이스에서 Adobe Reader로 보기
ePub (101.5 KB)
iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
Mobi (Kindle) (156.5 KB)
Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기

업데이트:2005년 6월 5일

문서 ID:10446

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

소개

이 문서의 목적은 LANE(LAN Emulation) 환경에서 HSRP(Hot Standby Router Protocol)를 구현할 때 발생할 수 있는 문제를 개략적으로 설명하는 것입니다. LANE을 통한 HSRP의 많은 세부 사항을 설명하고 다양한 시나리오에 대한 문제 해결 팁을 제공합니다.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.

배경 정보

요약하자면, HSRP의 목적은 서브넷의 호스트가 단일 "가상" 라우터를 기본 게이트웨이로 사용하도록 허용하는 것입니다. 다중 라우터는 HSRP 프로토콜에 참여하여 활성 라우터를 선택할 수 있습니다. 이는 활성 라우터가 실패할 경우 기본 게이트웨이 및 백업 라우터의 역할을 수행합니다. 그 결과 물리적 첫 번째 hop 라우터가 변경되더라도 기본 게이트웨이가 항상 작동 중인 것으로 나타납니다. HSRP에 대한 전체 설명은 RFC 2281에서 확인할 수 있습니다 .

HSRP는 다중 액세스, 멀티캐스트 또는 브로드캐스트 지원 LAN을 통해 사용하도록 설계되었습니다(일반적으로 이더넷, 토큰 링 또는 FDDI[Fiber Distributed Data Interface]). 따라서 HSRP는 ATM LANE에서 잘 작동해야 합니다.

HSRP 및 LANE 상호 작용과 관련된 몇 가지 상황이 발생할 수 있습니다.

Cisco IOS® Software 릴리스 11.2부터 HSRP는 LANE을 통해 "기본적으로"실행될 수 있습니다. 이 경우 standby 명령은 LEC(LAN Emulation Client)가 상주하는 ATM 하위 인터페이스에 직접 구성됩니다. 다음 그림을 참조하십시오.
또한 LAN 인터페이스에 HSRP가 구성되었지만 서브넷의 일부가 LANE 클라우드에 걸쳐 있는 인스턴스가 있습니다. 이 작업은 ATM 인터페이스를 사용하는 LAN 스위치(예: LANE 모듈이 있는 Cisco Catalyst 5000)의 중간에서 수행합니다. 다음 그림을 참조하십시오.
마지막으로, 일부 HSRP 라우터가 LANE에 연결되어 있고 다른 라우터는 LAN 스위치 뒤의 LAN에 있는 "하이브리드" 상황이 있습니다.

사례 연구

1) LANE을 넘는 네이티브 HSRP

HSRP에 참여하는 라우터는 서로 자세히 알아보고 액티브 및 스탠바이 라우터를 선택하기 위해 브로드캐스트 매체를 통해 "hello" 패킷을 전송합니다. 이러한 패킷은 TTL(Time to Live)이 1이고 멀티캐스트 목적지 MAC 주소가 0100 5E00 0002인 멀티캐스트 주소 224.0.0.2으로 전송됩니다.

LANE에는 새로운 문제가 없으므로 RFC 2281 에 설명된 세부 사항은 hello, quota 및 resign 패킷의 교환을 통해 계속 적용되며 활성 및 대기 라우터가 선택됩니다.

hello 패킷은 브로드캐스트 및 알 수 없는 서버(BUS)를 통해 전송되며, 다음은 debug atm 패킷(VC[Multicast Forward Virtual Circuit])과 디버그 대기가 나타내는 것입니다.

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

LEC(LAN Emulation Client)가 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

이 16진수 덤프는 다음과 같이 변환됩니다.

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

주목해야 할 점은 VMAC(Virtual MAC Address)가 있는 활성 라우터에서 hello 패킷을 소스 MAC 주소로 제공한다는 것입니다. 이러한 패킷을 전달하는 브리지(스위치)를 학습하면 CAM(Content-Addressable Memory) 테이블이 VMAC의 적절한 위치로 업데이트되기 때문입니다.

HSRP의 키는 IP 주소와 MAC 주소 간의 매핑에 있습니다.

가장 단순한 표현에서 가상 IP 주소는 가상 MAC 주소에 영구적으로 바인딩되며, 유일하게 걱정해야 할 점은 스위치가 항상 이 가상 MAC 주소가 어디에 있는지 알고 있다는 것입니다. 이는 헬로가 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 주소에 매핑된 번인된(대기 사용-bia) 주소를 사용한다는 것입니다. 이 경우, 가상 IP와 MAC 주소 간의 매핑은 시간이 지남에 따라 변경되며, 새로 활성화된 라우터는 새로운 가상 IP-MAC 주소 매핑을 알리기 위해 ARP(Address Resolution Protocol)를 전송합니다. 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을 도입하려면 Virtual IP-to-MAC 주소 매핑 외에도 VMAC-to-Network-Service-Access-Point(NSAP) 주소 매핑을 고려해야 합니다. 이 매핑은 LE-ARP(LAN Emulation-Address Resolution Protocol) 프로세스를 통해 간단하게 해결됩니다. 활성 게이트웨이로 트래픽을 전송하려는 LEC는 VMAC에 LE-ARP를 사용합니다(또는 번인된 MAC 주소 [BIA](BIA)를 사용하는 경우 물리적 MAC).

이제 새 라우터가 활성화될 때 발생하는 상황을 고려하십시오. LEC가 활성 게이트웨이의 새 위치(새 VMAC-NSAP 매핑)를 알려주기 위해서는 LE-ARP 테이블을 수정해야 합니다. 기본적으로 LE-ARP 항목은 5분마다 시간 초과되지만 대부분의 경우 이 시간 초과에 의존하는 것은 허용되지 않습니다. 컨버전스는 더 빨라야 합니다. 이 솔루션은 새 활성 상태가 LANE 버전 1 또는 버전 2를 실행 중이라고 가정할 때 LEC에 따라 달라집니다(LANE 사양은 ATM Forum.com 참조).

LANE 버전 1

라우터가 활성화되면 RFC 2281 에 설명된 단계 외에 새 VMAC-NSAP 주소 바인딩을 알려주기 위해 LE-NARP를 전송합니다. LANE 사양에 따르면 LE-NARP가 수신될 때 LEC는 MAC 주소에 해당하는 LE-ARP 항목을 지우거나 업데이트하도록 선택할 수 있습니다. Cisco의 경향 중 하나는 좀 더 보수적인 접근 방식을 채택하여 LE-ARP 항목을 지우는 것입니다. 그러면 LEC는 5분 시간 제한을 기다릴 필요 없이 즉시 LE-ARP를 재조정하게 됩니다.

참고: 이 솔루션으로 인해 아래 설명된 호환성 문제가 발생할 수 있습니다.
LANE 버전 2

LANE 버전 2에서 LANE 버전 1의 일부 단점은 다음과 같이 완화되었습니다. LE-NARP는 대상 없는 LE-ARP 및 비소스 LE-NARP로 대체되었습니다. 대상 없는 LE-ARP는 새 바인딩을 광고하는 수단으로 보일 수 있는 반면, 소스 없는 LE-NARP의 목적은 오래된 기존 MAC-to-NSAP 주소 바인딩을 렌더링하는 것입니다. 이렇게 구현되는 방법은 라우터가 Standby에서 Active로 변경되면 대상 없는 LE-ARP를 전송하고(MAC-to-NSAP 매핑을 광고하는 데 사용됨), Active에서 Standby로 변경되면 no-source LE-NARP를 전송합니다(MAC-to-NSAP 바인딩을 사용하지 않도록 설정하는 데 사용됨).

문제 - 상호 운용성

가끔 문제가 발생하여 더 심층적인 검사를 받을 만하다. LANE 버전 1 사양은 (이전) 대상 NSAP(T-NSAP) 주소를 지정하여 LE-NARP에서 폐기되는 "이전 바인딩"을 지정해야 한다고 설명합니다. 일반적으로 HSRP에 참여하는 라우터는 서로 데이터 전송을 유지하지 않습니다.

따라서 새로 활성화된 라우터는 이 정보를 알지 못하며 더 잘 알지 못하므로 이 필드를 완료하지 않도록 선택합니다. 이는 세부 항목의 경미한 위반이며 T-NSAP 주소 필드가 모두 0인 경우 일부 공급업체는 이러한 패킷을 무시합니다. 그러나 이 방법은 해결 방법이 없습니다. LE-NARP가 무시되면 올바른 바인딩을 학습하기 전에 LE-ARP 시간 초과(일반적으로 5분)를 사용합니다.

LE-ARP 또는 LE-NARP가 모두 0인 T-NSAP 주소 필드와 함께 전송되면 이를 "targetless"라고 합니다. 위에서 볼 수 있듯이, LANE 버전 2(및 MPOA(Multiprotocol over ATM))가 등장함에 따라 이는 표준이 되었으며 문제가 더 이상 발생하지 않습니다.

문제가 발생할 수 있는 경우 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도 지원합니다.

문제 해결 정보

LANE을 통한 네이티브 HSRP는 T-NSAP가 없는 LE-NARP로 인해 잠재적인 상호 운용성 문제 이외의 다른 많은 문제를 발생시키지 않아야 합니다.

라우터가 액티브 또는 스탠바이 상태인지 확인하는 데 어려움이 있는 경우 debug standby 명령을 사용하여 양쪽 헬로가 표시되는지 확인합니다. 그렇지 않으면 BUS가 패킷을 올바르게 전달하지 못할 수 있습니다.

2) LANE 뒤에 있는 HSRP Over Routers

그림 2와 같이 LANE 클라우드 뒤에 있는 라우터의 LANE 인터페이스에 HSRP를 구성하면 상황이 더욱 복잡해집니다.

참고: 이 그림에는 라우터가 비 ATM에 연결되어 있음을 논리적으로 보여 줍니다. LAN 스위치와 별도의 디바이스에 있을 필요는 없습니다(Cisco Catalyst 5000의 RSM(Route Switch Module)은 이 경우에 해당됨).

LANE에서 지정한 MAC-address-to-NSAP-address 매핑으로 인해 문제가 다시 발생합니다. 위에서 언급한 대로, VMAC가 다른 NSAP 주소에 해당하는 디바이스로 전환될 경우(새 라우터가 활성화될 때) LANE 클라우드에 연결된 모든 디바이스에 정보를 제공해야 합니다. 이는 LE-NARP(또는 대상 없는 LE-ARP)를 사용하여 LANE을 통한 기본 HSRP 환경에서 쉽게 구현됩니다.

이 두 번째 사례에서 문제는 LEC가 레이어 3 정보(IP)를 인식하지 못하여 두 개의 서로 다른 미디어(LAN과 ATM) 간에 패킷을 연결하도록 설계되었습니다.

예를 들어 그림 2에서 라우터 2가 갑자기 액티브 상태가 되면 LAN 스위치 2가 ATM(LANE) 클라우드에 연결된 모든 디바이스에 새로운 VMAC-NSAP 매핑에 대해 알리는 것이 좋습니다. LAN 스위치 2의 LEC는 뒤에 있는 모든 MAC 주소에 대해 프록시되고 있다고 합니다. 이러한 MAC 주소로 트래픽을 전송하려는 LANE의 디바이스는 이 LEC에 대한 데이터 직접 설정을 통해 전송해야 합니다. 직관적으로, 라우터 2가 활성 상태로 간주하는 즉시 소스 MAC 주소로 VMAC를 소싱하기 시작할 것이기 때문에 이것이 큰 문제가 되지 않을 것이라고 생각할 수 있습니다. 그러면 모든 LAN 스위치에서 이 정보를 학습하고 모든 것이 빠르게 통합됩니다. LANE이 아닌 환경에서는 이 값이 적용됩니다. 그러나 LANE은 다음과 같은 이유로 특별합니다.

LANE에서 데이터 패킷은 일반적으로 두 경로를 통해 전송할 수 있습니다.

이 패킷이 알려진 NSAP에 대상이 매핑된 유니캐스트이고 data-direct가 이미 설정된 경우 data-direct입니다.
알 수 없는 유니캐스트 및 멀티캐스트에 대한 BUS입니다.

따라서 동일한 MAC 주소가 LAN 스위치에서 수신되는 패킷을 서로 다른 두 경로로 전송합니다. 데이터 디렉션을 통해 알려진 유니캐스가 도착하는 반면 멀티캐스트와 알려지지 않은 유니캐스트는 버스를 통해 도착할 것입니다. 특별한 노력이 이루어지지 않은 경우 LAN 스위치는 마지막으로 수신한 패킷에 따라 데이터 직접 또는 버스를 통해 이 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 스위치가 이 항목에 대해 "잊어버림"할 때까지 이 VMAC으로 전송되는 모든 패킷이 잘못 전달됩니다(기본 에이징은 5분).

참고: LEC의 LE-ARP 에이징 타이머도 기본적으로 5분이므로 전체 연결이 최대 10분 동안 손실될 수 있습니다. MAC 주소의 에이징 타이머를 줄이면 도움이 되지만 실제로 문제를 해결하지는 않습니다.

이를 위한 두 가지 솔루션이 있습니다.

LAN 스위치가 Cisco가 아닌 경우 위에서 설명한 방법으로 돌아갑니다. 번인된 주소를 사용합니다. 라우터가 MAC 주소만 사용하여 hello 패킷을 소싱하고, 스위치오버가 발생할 때마다 가상-IP 주소가 매핑 매핑을 변경하는 경우 이러한 MAC 주소의 위치에 대한 혼동이 발생하지 않습니다.
LAN 스위치가 Cisco Catalyst인 경우 Cisco 버그 ID CSCdj58719(등록된 고객만 해당) 및 CSCdj60431(등록된 고객만 해당)에 포함된 DTS(Distributed Defect Tracking System)가 제공한 수정 사항으로 인해 VMAC를 계속 사용합니다.

기본적으로 라우터가 RFC 2281에 따라 전송하는 ARP(요청되지 않은 ARP 응답) 외에 활성 상태를 가정할 경우 라우터는 대상 MAC 주소 0100.0CCD.CDCD가 있는 두 번째 ARP를 전송합니다. Cisco Catalyst는 이 패킷을 받으면 다음 두 가지 작업을 수행합니다.
- VMAC에 대한 LE-ARP 항목을 지웁니다.
- 버스를 통해 VMAC를 학습합니다.

따라서 여러 LEC에 더 이상 오래된 LE-ARP 엔트리가 없으며 VMAC의 새 위치가 모든 스위치(예: LANE 클라우드 외부)에 전파됩니다. 이 작업이 올바르게 작동하려면 다음과 같은 최소 소프트웨어 요구 사항을 충족해야 합니다.

라우터에는 Cisco IOS Software 릴리스 11.1(24), 버전 11.2(13) 또는 모든 버전 12.0이 있어야 합니다.
LANE 모듈에는 버전 3.2(8) 이상이 있어야 합니다. 11.3W4 이상 버전을 사용할 수 있습니다.

Cisco는 최신 소프트웨어를 사용할 것을 권장합니다.

3) 혼합 환경

혼합된 환경에서 발생할 수 있는 마지막 문제가 있습니다. 위의 시나리오를 통해 직접 연결된 LANE 엔드디바이스(라우터 또는 워크스테이션)를 추가하면 시나리오 1과 동일한 방식으로 활성 게이트웨이의 위치 변경에 대해 최종 디바이스에 알려야 합니다. 새로 활성화된 라우터가 스위치 뒤에 연결되어 있는 경우, 유일한 솔루션은 스위치 자체에서 라우터를 대신하여 LE-NARP를 전송하는 것이며 이는 정확히 무엇을 해야 하는가입니다.

위에서 설명한 단계 외에 Cisco Catalyst가 0100 0CCD CDCD로 향하는 패킷을 선택한 경우 LE-NARP(LANE 버전 2를 실행하는 경우 소스 없음 LE-NARP)를 전송합니다. 이 패킷의 유일한 목적은 VMAC에 대한 LE-ARP 캐시를 지우는 것입니다.

결론

앞에서 설명한 것처럼, LANE을 통한 HSRP는 원칙적으로는 잘 작동하지만, 어떤 상황에서는 사용자가 위에 설명된 허점 중 하나에 빠지면 짧은 시간 동안 연결을 끊길 수 있습니다.

중요!: LANE을 통한 HSRP의 성공을 보장하려면 다음 두 가지 권장 사항을 따르십시오.

안전을 위해 최신 버전의 Cisco IOS Software 릴리스 12.0으로 업그레이드하십시오.
멀티벤더 환경에서는 문제를 방지하기 위해 LANE 버전 2 또는 번인된 주소를 사용하는 것이 가장 좋습니다.