ASA가 리부팅될 때 무선 모빌리티 연결이 실패하고 복구되지 않음

소개

이 문서에서는 ASA(Adaptive Security Appliance)를 통과하는 모빌리티 경로 연결(UDP(User Datagram Protocol) 및 IP 프로토콜 93 사용)이 다운되어 모바일 디바이스가 다시 로드될 때까지 계속 장애가 발생하거나 모빌리티 경로 트래픽이 잠시 중지되고 비활성 상태로 유지된 후 다시 시작되는 문제에 대해 설명합니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• Cisco ASA(Adaptive Security Appliance)
• WLC(Wireless LAN Controller)

사용되는 구성 요소

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

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.

표기 규칙

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

문제

이 경우 WLC(Wireless LAN Controller)는 10.10.9.3에서 WLC와 통신하려고 10.10.1.2에 있지만 통신이 실패합니다.

이 문제는 다음 이벤트 중 하나에 의해 트리거될 수 있습니다.

• ASA가 재부팅됩니다.
• 라우팅 테이블은 관리자 또는 라우팅 프로토콜에 의해 수정됩니다.
• 인터페이스가 종료되고 관리자가 다시 시작합니다.

모빌리티 트래픽 외에도 UDP 또는 비 TCP IP 프로토콜에 대해 이 문제가 발생할 수 있습니다. 

이 문제는 버그가 아니라 네트워크 토폴로지 및 ASA 컨피그레이션의 결과입니다. 이 문제의 원인과 해결 방법은 아래를 참조하십시오.

샘플 네트워크 토폴로지

ASA 라우팅 구성:

!
route outside 0.0.0.0 0.0.0.0 192.168.4.3 1
route inside 10.0.0.0 255.0.0.0 192.168.254.1 1
!
same-security-traffic permit intra-interface
!

ASA DMZ 인터페이스 구성:

!
interface Gigabit-Ethernet0/1.10
 vlan 10
 nameif dmz
 security-level 75
 ip address 10.10.9.1 255.255.255.240 standby 10.10.9.2 
!

문제 트리거

10.10.1.2의 WLC가 10.10.9.3에 있는 WLC로 향하는 트래픽을 전송할 때 문제가 트리거됩니다. 이러한 패킷으로 인해 ASA가 연결 테이블에서 모빌리티 트래픽을 잘못된 ASA 인터페이스(내부)로 보내는 연결을 구축하게 됩니다.

이 문제는 ASA의 목적지 인터페이스 "dmz"가 연결이 구축되었을 때 다운/다운 상태에 있기 때문에 연결이 다른 비최적 인터페이스를 구축하게 됩니다. 케이블 문제, 이더넷 또는 포트 채널 협상 문제 등으로 인해 DMZ 인터페이스가 다운되었거나 관리 목적으로 종료되었을 수 있습니다.

문제가 발생할 때 모빌리티 경로 연결은 ASA의 "intra-interface"로 생성될 수 있습니다. ASA는 패킷이 도착한 동일한 내부 인터페이스로 다시 라우팅됩니다.

ASA# show conn address 10.10.1.2
15579 in use, 133142 most used
97 inside 10.10.9.3 inside 10.10.1.2, idle 0:00:00, bytes 32210
UDP inside 10.10.9.3:16666 inside 10.10.1.2:16666, idle 0:00:00, bytes 4338, flags -
97 inside 10.10.9.3 inside 10.10.1.2, idle 0:00:00, bytes 157240
ASA#

10.10.1.2의 모빌리티 엔드포인트는 이러한 기존 연결과 일치하는 10.10.9.3으로 향하는 트래픽을 계속 전송합니다. DMZ 인터페이스가 up/up 상태로 진행되었더라도 10.10.1.2에서 제공하는 모빌리티 트래픽은 ASA에서 연결의 시간 제한을 재설정하는 대신 테이블의 기존 연결(dmz 인터페이스에 대한 새 연결을 구축하는 대신)과 매칭하여 문제가 길어집니다.

요약하면, 이러한 이벤트는 문제를 트리거할 수 있습니다.

1. 10.10.1.2의 디바이스는 프로토콜 97 또는 UDP 패킷을 10.10.9.3으로 전송합니다.
2. ASA는 내부 인터페이스에서 패킷을 수신하지만 DMZ 인터페이스가 다운되어 대상 네트워크에 대한 더 구체적인 경로가 라우팅 테이블에서 누락됩니다. ASA에서 same-security permit intra-interface 명령이 활성화되었으므로, 내부 인터페이스를 통해 10.0.0.0/8 네트워크에 대해 구성된 고정 경로를 따르고, 연결 테이블에서 연결을 구축한 다음, 패킷을 내부 네트워크로 다시 전송합니다.
3. 어느 시점에서는 DMZ 인터페이스가 다시 작동하여 경로가 테이블에 다시 추가될 수 있습니다. 그러나 프로토콜 97 트래픽에 대한 연결이 #2 단계에서 이미 구축되었으므로 후속 패킷은 연결과 일치하며 라우팅 테이블을 덮어쓰고 트래픽이 dmz의 서버에 도달하지 않습니다.

솔루션

솔루션 1

이 문제를 해결할 수 있는 한 가지 방법은 ASA에서 same-security permit intra-interface 명령을 제거하는 것입니다. 이 솔루션은 원래 패킷이 수신된 인터페이스와 동일한 인터페이스를 u-turn 연결이 다시 구축되지 않도록 합니다. 따라서 인터페이스가 작동될 때 올바른 연결을 구축할 수 있습니다. 그러나 ASA의 라우팅 테이블에 따라 이 솔루션이 작동하지 않을 수 있습니다(트래픽은 라우팅 테이블을 기반으로 의도된 대상 이외의 다른 인터페이스로 라우팅될 수 있음). ASA의 다른 연결에 대해 same-security permit intra-interface 명령이 필요할 수 있습니다.

솔루션 2 

이 특정 인스턴스의 경우 시간 초과 floating-conn 기능을 활성화하여 문제가 성공적으로 완화되었습니다. 기본적으로 활성화되지 않은 이 기능은 ASA가 엔드포인트 중 하나에 대한 더 선호되는 경로가 라우팅 테이블에 추가되고 1분 후에 DMZ 인터페이스가 작동될 때 발생하는 ASA의 새 인터페이스를 통해 이러한 연결을 해제하도록 만들었습니다. 그런 다음 다음 다음 패킷이 ASA에 도착하면 즉시 연결이 재구축되며, 10.10.9.3 호스트의 내부 대신 더 선호하는 인터페이스(dmz)를 사용합니다.

ASA(config)# timeout floating-conn 0:01:00

문제가 완화되면 ASA 연결 테이블에 올바른 연결이 구축되고 연결이 자동으로 복원됩니다.

ASA# show conn address 10.10.1.2
15329 in use, 133142 most used
97 dmz 10.10.9.3 inside10.10.1.2, idle 0:00:00, bytes 3175742510
UDP dmz 10.10.9.3:16666 inside 10.10.1.2:16666, idle 0:00:00, bytes 40651338, flags -
97 dmz 10.10.9.3 inside10.10.1.2, idle 0:00:00, bytes 1593457240
ASA#

관련 정보

• ASA 9.1 명령 참조 - timeout floating-conn 명령
• 기술 지원 및 문서 − Cisco Systems