소개
이 문서에서는 내부 또는 외부 BGP(Border Gateway Protocol) 네이버 플랩이 MTU에 의해 유발되는 원인을 확인하는 방법에 대해 설명합니다.
사전 요구 사항
요구 사항
다음 주제에 대한 지식을 보유하고 있으면 유용합니다.
이 문서의 절차를 완료하기 전에 두 BGP 라우터에서 다음 작업을 완료해야 합니다.
- BGP 컨피그레이션을 확인합니다.
- ICMP(Internet Control Message Protocol)를 통해 BGP 인접 디바이스에 연결할 수 있으며 어떤 삭제도 관찰되지 않는지 확인합니다.
- 피어 BGP에 사용된 연결된 인터페이스가 오버서브스크립션되지 않았으며 입력/출력 삭제 또는 오류가 없는지 확인합니다.
- CPU 및 메모리 사용률을 확인합니다.
사용되는 구성 요소
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
문제
BGP 네이버 양식; 그러나 접두사 교환 시 BGP 상태는 삭제되고 로그는 누락된 BGP hello keepalive를 생성하거나 다른 피어가 세션을 종료합니다.
MTU로 인해 BGP 인접 디바이스가 플랩되는지 확인하려면 다음 단계를 완료하십시오.
- 두 BGP 라우터에서 어떤 인접 디바이스가 영향을 받는지, 그리고 연결된 인터페이스를 확인하려면 다음 명령을 사용합니다. 피어링 주소가 루프백 주소인 경우 루프백에 연결할 수 있는 연결된 인터페이스를 확인합니다. 또한 두 피어링 라우터에서 BGP OutQ를 확인합니다. 0이 아닌 일관된 OutQ는 경로의 MTU 문제로 인해 업데이트가 피어에 도달하지 않음을 나타내는 강력한 표시입니다.
Router#show ip bgp summ | in InQ|10.10.10.2
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.10.10.2 4 3 64 62 3 0 0 00:00:3 2
Router#show ip route 10.10.10.2
Routing entry for 10.10.10.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via GigabitEthernet1/0
Route metric is 0, traffic share count is 1
- 양쪽에서 인터페이스 MTU를 확인합니다.
Router#show ip int g1/0 | i MTU
MTU is 1500 bytes
Router#
- 두 BGP 스피커에 대해 TCP 동의 최대 데이터 세그먼트를 확인합니다.
Router#show ip bgp neigh 10.20.20.2 | inc segment
Datagrams (max data segment is 1460 bytes):
Router#
위의 예에서 1460은 TCP 헤더에 20바이트가 할당되고 IP 헤더에 20바이트가 할당되므로 정확합니다.
- BGP used path-mtu가 활성화되었는지 확인합니다.
Router#show ip bgp neigh 10.10.10.2 | in tcp
Transport(tcp) path-mtu-discovery is enabled
Router#
- 최대 인터페이스 MTU 및 DF(Do not Fragment) 비트가 설정된 BGP 피어를 ping합니다.
Router#ping 10.10.10.2 size 1500 df
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds:
Packet sent with the DF bit set
.....
Success rate is 0 percent (0/5)
- 사용할 수 있는 최대 MTU 크기를 결정하기 위해 ICMP 크기 값을 줄입니다.
ping 10.10.10.2 size 1300 df
솔루션
몇 가지 가능한 원인은 다음과 같습니다.
- 두 라우터의 인터페이스 MTU가 일치하지 않습니다.
- 두 라우터의 인터페이스 MTU는 일치하지만 BGP 세션이 형성된 레이어 2 도메인은 일치하지 않습니다.
- 경로 MTU 검색에서 TCP BGP 세션에 대한 최대 데이터 크기가 잘못된 것으로 확인되었습니다.
- PMTUD ICMP 패킷이 차단되어 BGP PMTUD(Path Maximum Transmission Unit Discovery)에 실패할 수 있습니다(방화벽 또는 ACL).
MTU 문제를 해결할 수 있는 방법은 다음과 같습니다.
- 두 라우터의 인터페이스 MTU는 동일해야 합니다. show ip int 실행 현재 MTU 설정을 확인하려면 MTU 명령에서 |을(를) 클릭합니다.
- 두 라우터의 인터페이스 MTU가 올바르지만(예: 1500) DF 비트가 설정된 ping 테스트가 1300을 초과하지 않는 경우, 영향을 받는 BGP 세션이 형성된 레이어 2 도메인에는 일관성 없는 MTU 컨피그레이션이 포함될 수 있습니다. 각 레이어 2 인터페이스 MTU를 확인합니다. 문제를 해결하려면 레이어 2 인터페이스 MTU를 수정합니다.
- 레이어 2 도메인을 확인/변경할 수 없는 경우 ip tcp mss global 명령을 1000과 같은 작은 값으로 설정할 수 있습니다. 그러면 로컬에서 시작된 모든 TCP 최대 데이터 세그먼트 세션(BGP 포함)이 1000으로 강제 설정될 수 있습니다. 이 명령에 대한 자세한 내용은 Cisco IOS® IP Application Services 명령 참조의 ip tcp mss 섹션을 참조하십시오.
또한 추가 문제 해결을 위해 ip tcp adjust-mss 명령을 사용할 수 있습니다. 이 명령은 인터페이스 레벨에서 구성되며 모든 TCP 세션에 영향을 줍니다. 이 명령에 대한 자세한 내용은 Cisco IOS IP Application Services 명령 참조의 ip tcp adjust-mss 섹션을 참조하십시오.
- (선택 사항) BGP PMTUD(Path Maximum Transmission Unit Discovery)에서 올바른 최대 데이터 크기를 생성할 수 없습니다. 이러한 원인이 있는지 확인하기 위해 전역적으로 또는 인접 디바이스별로 비활성화할 수 있습니다. BGP PMTUD가 비활성화되면 RFC 879에 정의된 대로 BGP MSS(Maximum Segment Size)는 536으로 기본 설정됩니다.
PMTUD를 비활성화하는 방법에 대한 자세한 내용은 Cisco IOS BGP 컨피그레이션 가이드의 Configuring BGP Support for TCP Path MTU Discovery per Session 섹션을 참조하십시오.
PMTUD에 대한 자세한 내용은 IPv4 프래그먼트화, MTU, MSS 및 GRE 및 IPsec의 PMTUD 문제 해결을 참조하십시오.
관련 정보
피드백