Border Gateway Protocol 기본 문제 해결
소개
이 문서에서는 BGP(Border Gateway Protocol)의 가장 일반적인 문제를 해결하는 방법을 설명하고 기본적인 솔루션과 지침을 제공합니다.
사전 요구 사항
요구 사항
이 문서에 대한 특정 요건이 없습니다. 기본 BGP 프로토콜 지식이 유용합니다. 자세한 내용은 BGP 컨피그레이션 가이드를 참조하십시오.
사용되는 구성 요소
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 제한되지 않지만, 명령은 Cisco IOS® 및 Cisco IOS® XE에 적용할 수 있습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
배경 정보
이 문서에서는 BGP(Border Gateway Protocol)의 가장 일반적인 문제를 해결하기 위한 기본 설명서와 수정 조치, 문제의 근본 원인을 탐지하는 데 유용한 명령/디버그 및 잠재적인 문제를 방지하는 모범 사례를 제공합니다. 모든 가능한 변수와 시나리오는 고려될 수 없으며 Cisco TAC에서 더 심층적인 분석을 요구할 수 있습니다.
토폴로지
이 토폴로지 다이어그램을 이 문서에서 제공하는 출력에 대한 참조로 사용합니다.
시나리오 및 문제
인접성 하향
BGP 세션이 다운되고 올라오지 않으면 show ip bgp all summary command. 여기서 세션의 현재 상태를 확인할 수 있습니다.
- 세션이 작동 상태가 아닌 경우 IDLE 및 ACTIVE 간에 변할 수 있습니다(유한 상태 머신 프로세스에 따라 다름).
- 세션이 실행 중이면 수신된 접두사 수가 표시됩니다.
R2#show ip bgp all summary For address family: IPv4 Unicast BGP router identifier 198.51.100.2, local AS number 65537 BGP table version is 19, main routing table version 19 18 network entries using 4464 bytes of memory 18 path entries using 2448 bytes of memory 1/1 BGP path/bestpath attribute entries using 296 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 7208 total bytes of memory BGP activity 18/0 prefixes, 18/0 paths, scan interval 60 secs 18 networks peaked at 11:21:00 Jun 30 2022 CST (00:01:35.450 ago) Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.0.23.3 4 65537 6 5 19 0 0 00:01:34 18 198.51.100.1 4 65536 0 0 1 0 0 never Idle
연결 없음
먼저 두 피어 간의 연결을 보장해야 합니다. 그러면 포트 179에서 TCP 세션을 설정할 수 있습니다. 직접 연결되어 있거나 연결되어 있지 않습니다. 간단한 ping은 이 문제에 유용합니다. 루프백 인터페이스 간에 피어링이 설정된 경우 루프백 핑에 대한 루프백을 수행해야 합니다. 소스 인터페이스로 특정 루프백 없이 ping 테스트가 수행되는 경우 발신 물리적 인터페이스 IP 주소가 라우터의 루프백 IP 주소 대신 패킷의 소스 IP 주소로 사용됩니다.
Ping에 성공하지 못한 경우 다음 원인을 고려하십시오.
- 연결된 경로 피어가 없거나 경로가 전혀 없습니다.
show ip route peer_IP_address사용할 수 있습니다. - 레이어 1 문제: 물리적 인터페이스, SFP(커넥터), 케이블 또는 외부 문제(해당되는 경우 전송 및 공급자)를 고려해야 합니다.
- 연결을 차단할 수 있는 방화벽 또는 액세스 목록을 확인합니다.
ping에 성공하면 다음 사항을 고려하십시오.
설정 문제
- 잘못된 IP 주소 또는 구성된 AS: 잘못된 IP address(주소), 이러한 메시지가 표시되지 않지만 올바른 컨피그레이션이 완료되었는지 확인합니다. 잘못된 AS의 경우 다음과 같은 메시지가 표시되어야 합니다.
show logging명령을 실행합니다.
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/2 (peer in wrong AS) 2 bytes 1B39
양쪽 끝에서 BGP 컨피그레이션을 확인하여 AS 번호 또는 피어 IP 주소를 수정합니다.
- 중복 라우터 ID:
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.1 passive 2/3 (BGP identifier wrong) 4 bytes 0A0A0A0A
다음을 통해 양쪽 끝에서 BGP 식별자 확인 show ip bgp all summary 문제를 해결합니다. 이는 global 명령을 사용하여 수동으로 수행할 수 있습니다 bgp router-id X.X.X.X bgp 라우터 컨피그레이션 아래에서 모범 사례로서, 라우터 ID를 수동으로 고유 번호로 설정해야 합니다.
- BGP 소스 및 TTL:
대부분의 iBGP 세션은 IGP를 통해 연결할 수 있는 루프백 인터페이스를 통해 구성됩니다. 이 루프백 인터페이스는 소스로 명시적으로 정의해야 합니다. 명령을 사용하여 이 작업을 수행하십시오 neighbor ip-address update-source interface-id .
eBGP 피어의 경우 일반적으로 직접 연결된 인터페이스가 피어링에 사용되며, 이 목적을 달성하기 위해 Cisco IOS/Cisco IOS XE를 확인하거나 세션을 설정하려고 시도조차 하지 않습니다. 직접 연결된 라우터에서 eBGP가 루프백에서 루프백으로 시도되는 경우 를 통해 양쪽의 특정 네이버에 대해 이 검사를 비활성화할 수 있습니다 neighbor ip-address disable-connected-check .
그러나 eBGP 피어 간에 여러 홉이 있는 경우 적절한 홉 수가 필요합니다. neighbor ip-address ebgp-multihop [hop-count]올바른 홉 수로 구성되므로 세션을 설정할 수 있습니다.
hop-count를 지정하지 않으면 iBGP 세션의 기본 TTL 값은 255이고 eBGP 세션의 기본 TTL 값은 1입니다.
TCP 세션 문제
포트 179를 테스트하는 데 유용한 작업은 한 피어에서 다른 피어로의 수동 텔넷입니다.
R1#telnet 198.51.100.2 179 Trying 198.51.100.2, 179 ... Open [Connection to 198.51.100.2 closed by foreign host]
열기/연결이 닫혔거나 원격 호스트에서 연결이 거부된 경우 패킷이 원격 끝에 도달했음을 나타내며, 그러면 먼 쪽 끝의 컨트롤 플레인에 문제가 없는지 확인합니다. 그렇지 않으면 Destination unreachable이 있는 경우 TCP 포트 179, BGP 패킷 또는 경로의 패킷 손실을 차단할 수 있는 방화벽 또는 액세스 목록을 확인합니다.
인증 문제의 경우, 볼 수 있는 메시지는 다음과 같습니다.
%TCP-6-BADAUTH: Invalid MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0 %TCP-6-BADAUTH: No MD5 digest from 198.51.100.1(179) to 198.51.100.2(20062) tableid - 0
인증 방법, 비밀번호 및 관련 컨피그레이션을 확인하고 추가 트러블슈팅을 하려면 BGP 피어 간 MD5 인증 컨피그레이션 예를 참조하십시오.
TCP 세션이 나타나지 않으면 다음 명령을 사용하여 격리할 수 있습니다.
show tcp brief all
show control-plane host open-ports
debug ip tcp transactions
인접성 반송
세션이 작동 및 중단되면 다음을 찾습니다. show log 몇 가지 시나리오를 볼 수 있습니다.
인터페이스 플랩
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 Down Interface flap
메시지가 나타내는 것처럼 이 오류의 원인은 인터페이스 중단 상황이며, 포트/SFP, 케이블 또는 연결 해제에 물리적 문제가 있는지 확인합니다.
보류 타이머 만료
%BGP-3-NOTIFICATION: sent to neighbor 198.51.100.2 4/0 (hold time expired) 0 bytes
이는 매우 일반적인 상황입니다. 보류 타이머가 만료되기 전에 라우터가 keepalive 메시지 또는 업데이트 메시지를 수신 또는 처리하지 않았다는 것을 의미합니다. 디바이스가 알림 메시지를 전송하고 세션을 닫습니다. 이 문제에 대한 가장 일반적인 이유는 다음과 같습니다.
- 인터페이스 문제: 두 피어의 연결된 인터페이스에서 입력 오류, 입력 대기열 삭제 또는 물리적 문제를 확인합니다.
show interface사용할 수 있습니다.
- CoPP 정책 문제: 트러블슈팅 방법론은 플랫폼마다 다르며 이 문서의 범위를 벗어납니다.
- MTU 불일치: 경로에 MTU 불일치가 있고, ICMP 메시지가 소스에서 대상으로의 경로에 차단된 경우, PMTUD가 작동하지 않으며 세션 플랩이 발생할 수 있습니다. 업데이트는 협상된 MSS 값 및 DF 비트 세트와 함께 전송됩니다. 경로에 있는 디바이스 또는 심지어 목적지에서도 MTU가 더 높은 패킷을 수락할 수 없는 경우 ICMP 오류 메시지를 BGP 스피커로 다시 전송합니다. 목적지 라우터는 BGP keepalive 또는 BGP 업데이트 패킷이 보류 타이머를 업데이트할 때까지 기다립니다.
- 협상된 MSS를
show ip bgp neighbors ip_address.
- 협상된 MSS를
df 세트가 있는 특정 네이버에 대한 Ping 테스트에서는 해당 MTU가 경로를 따라 유효한지 확인할 수 있습니다.
ping 198.51.100.2 size max_seg_size df
MTU 문제가 발견되면 컨피그레이션을 정확하게 검토하여 MTU 값이 네트워크 전체에서 일관되게 유지되도록 해야 합니다.
AFI/SAFI 문제
%BGP-5-ADJCHANGE: neighbor 198.51.100.2 passive Down AFI/SAFI not supported
%BGP-3-NOTIFICATION: received from neighbor 198.51.100.2 active 2/8 (no supported AFI/SAFI) 3 bytes 000000
AFI(Address-Family Identifier)는 MP-BGP(Multi-Protocol BGP)에서 추가하는 기능 확장입니다. 이는 IPv4, IPv6 등과 같은 특정 네트워크 프로토콜 및 유니캐스트, 멀티캐스트와 같은 후속 SAFI(Address-Family Identifier)를 통한 추가 세분화에 관한 것이다. MBGP는 BGP 경로 속성(PA) MP_REACH_NLRI 및 MP_UNREACH_NLRI에 의해 이러한 분리를 달성합니다. 이러한 특성은 BGP 업데이트 메시지 내에서 전달되며 서로 다른 주소 패밀리에 대한 네트워크 연결 정보를 전달하는 데 사용됩니다.
이 메시지는 IANA에서 등록한 다음 AFI/SAFI 번호를 제공합니다.
- 원하지 않는 주소 패밀리를 수정하려면 양쪽에서 의도한 주소 패밀리에 대한 BGP 컨피그레이션을 확인합니다.
- Use
neighbor ip-address dont-capability-negotiate있습니다. 자세한 내용은 Unsupported Capabilities Cause BGP Peer Om제대로 작동하지 않음을 참조하십시오.
경로 설치 및 선택
BGP의 작동 방식에 대한 자세한 설명과 최적 경로를 선택하려면 BGP 최적 경로 선택 알고리즘을 참조하십시오.
다음 홉
라우팅 테이블에 경로를 설치하려면 다음 홉에 연결할 수 있어야 합니다. 그렇지 않으면 접두사가 Loc-RIB BGP 테이블에 있더라도 RIB에 연결되지 않습니다. 루프 방지 규칙으로서 Cisco IOS/Cisco IOS XE에서 iBGP는 next hop 특성을 변경하지 않고 AS_PATH만 남겨 두고, eBGP는 next hop을 다시 쓰고 AS_PATH를 앞에 둡니다.
다음 홉을 확인할 수 있습니다 show ip bgp [prefix]. 그것은 당신에게 다음 홉과 접근 할 수없는 단어를 제공합니다. 이 예에서는 eBGP를 통해 R1에서 R2로 알리고 R2에서 iBGP 연결을 통해 R3에서 학습한 접두사입니다.
R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 0
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
65536
198.51.100.1 (inaccessible) from 10.0.23.2 (10.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal
rx pathid: 0, tx pathid: 0
Updated on Jul 1 2022 13:44:19 CST
출력에서 next hop은 R3에서 알 수 없는 R1의 발신 인터페이스입니다. 이 상황을 해결하려면 IGP, 고정 경로를 통해 next-hop을 알리거나 neighbor ip-address next-hop-self 명령을 실행하여 직접 연결된 next-hop IP를 수정합니다. 다이어그램 예에서는 이 컨피그레이션이 R2에 있어야 합니다. R3를 향하는 인접 디바이스(인접 디바이스 10.0.23.3 next-hop-self)입니다.
그 결과 다음 홉이 변경됩니다(다음 홉 이후) clear ip bgp 10.0.23.2 soft)에 직접 연결된 인터페이스(연결 가능) 및 접두사가 설치됩니다.
R3#show ip bgp 192.0.2.1
BGP routing table entry for 192.0.2.1/32, version 24
Paths: (1 available, best #1, table default)
Not advertised to any peer
Refresh Epoch 1
65536
10.0.23.2 from 10.0.23.2 (10.2.2.2)
Origin incomplete, metric 0, localpref 100, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Updated on Jul 1 2022 13:46:53 CST
RIB 장애
전역 RIB에 경로를 설치할 수 없어 RIB 장애가 발생하는 경우 이러한 문제가 발생합니다. 일반적인 이유는 동일한 접두사가 관리 거리가 더 낮은 다른 라우팅 프로토콜의 RIB에 이미 있지만 RIB 실패의 정확한 이유가 show ip bgp rib-failure 명령에 나타나는 경우입니다. 자세한 설명은 다음 링크를 참조하십시오.
경합 상태
가장 일반적인 문제는 상호 재배포 시나리오에서 IGP가 eBGP보다 선호될 때입니다. IGP 경로가 BGP로 재배포되는 경우 BGP에서 로컬로 생성된 것으로 간주되며 기본적으로 32768 가중치를 가져옵니다. BGP 피어에서 수신한 모든 접두사에는 기본적으로 로컬 가중치 0이 할당됩니다. 따라서 동일한 접두사를 비교해야 하는 경우 BGP 최적 경로 선택 프로세스를 기반으로 가중치가 높은 접두사를 라우팅 테이블에 설치하므로 RIB에 IGP 경로가 설치됩니다.
이 문제의 해결 방법은 라우터 bgp 컨피그레이션에서 BGP 피어에서 수신한 모든 경로에 더 높은 가중치를 설정하는 것입니다.
neighbor ip-address weight 40000
기타 문제
BGP 느린 피어
발신자가 업데이트 메시지를 생성하는 속도를 따라잡을 수 없는 피어입니다. 피어가 이 문제를 보이는 이유는 여러 가지가 있습니다. 피어 중 하나의 높은 CPU, 링크의 과도한 트래픽 또는 트래픽 손실, 대역폭 리소스 등이 그 중 하나입니다.
메모리 문제
BGP는 Cisco IOS 프로세스에 할당된 메모리를 사용하여 네트워크 접두사, 최상의 경로, 정책 및 모든 관련 컨피그레이션이 제대로 작동하도록 유지합니다. 전체 프로세스는 명령으로 표시됩니다. show processes memory sorted:
R1#show processes memory sorted
Processor Pool Total: 2121414332 Used: 255911152 Free: 1865503180 reserve P Pool Total: 102404 Used: 88 Free: 102316 lsmpi_io Pool Total: 3149400 Used: 3148568 Free: 832 PID TTY Allocated Freed Holding Getbufs Retbufs Process 0 0 266231616 81418808 160053760 0 0 *Init* 662 0 34427640 51720 34751920 0 0 SBC main process 85 0 9463568 0 8982224 0 0 IOSD ipc task 0 0 34864888 25213216 8513400 8616279 0 *Dead* 504 0 696632 0 738576 0 0 QOS_MODULE_MAIN 518 0 940000 8616 613760 0 0 BGP Router 228 0 856064 345488 510080 0 0 mDNS 82 0 547096 118360 417520 0 0 SAMsgThread 0 0 0 0 395408 0 0 *MallocLite*
프로세서 풀은 사용된 메모리이며 이 예에서는 약 2.1GB입니다. 다음으로 Holding 열을 확인하여 대부분의 하위 프로세스를 확인해야 합니다. 그런 다음 보유하고 있는 BGP 세션, 수신된 경로 수, 사용된 컨피그레이션을 확인해야 합니다.
BGP의 메모리 보유를 줄이기 위한 일반적인 단계:
- BGP 필터링: 전체 BGP 테이블을 수신할 필요가 없는 경우 정책을 사용하여 경로를 필터링하고 필요한 접두사만 설치합니다.
- 소프트 리컨피그레이션: BGP 컨피그레이션에서 인접 디바이스 ip_address 소프트 리컨피그레이션 인바운드를 찾습니다. 이 명령을 사용하면 인바운드 정책(Adj-RIB-in) 이전에 수신된 모든 접두사를 볼 수 있습니다. 그러나 이 테이블에서는 이 정보를 저장할 현재 BGP 로컬 RIB 테이블의 절반 정도가 필요하므로 반드시 필요하거나 현재 접두사가 적은 경우가 아니면 이 컨피그레이션을 피할 수 있습니다.
높은 CPU
라우터는 BGP가 작동하는 데 서로 다른 프로세스를 사용합니다. BGP 프로세스가 높은 CPU 사용률의 원인인지 확인하려면 show process cpu sorted 명령을 실행합니다.
R3#show processes cpu sorted CPU utilization for five seconds: 0%/0%; one minute: 0%; five minutes: 0% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 163 36 1463 24 0.07% 0.00% 0.00% 0 ADJ background 62 28 132 212 0.07% 0.00% 0.00% 0 Exec 2 39 294 132 0.00% 0.00% 0.00% 0 Load Meter 1 0 4 0 0.00% 0.00% 0.00% 0 Chunk Manager 3 27 1429 18 0.00% 0.00% 0.00% 0 BGP Scheduler 4 0 1 0 0.00% 0.00% 0.00% 0 RO Notify Timers 63 4 61 65 0.00% 0.00% 0.00% 0 BGP I/O 83 924 26 35538 0.00% 0.03% 0.04% 0 BGP Scanner 96 142 11651 12 0.00% 0.00% 0.00% 0 Tunnel BGP 7 0 1 0 0.00% 0.00% 0.00% 0 DiscardQ Backgro
다음은 BGP로 인한 높은 CPU 사용률을 극복하기 위한 일반적인 프로세스, 원인 및 일반적인 단계입니다.
- BGP 라우터: 더 빠른 통합을 보호하기 위해 초당 1회 실행됩니다. 그것은 가장 중요한 실마리 중 하나이다. bgp 업데이트 메시지를 읽고, 접두사/네트워크 및 특성을 검증하고, AFI/SAFI 네트워크/접두사 테이블 및 특성 테이블당 를 업데이트하고, 여러 다른 작업 중에서 최적 경로 계산을 수행합니다.
거대한 경로 이탈은 이러한 상황을 초래하는 매우 일반적인 시나리오이다. - BGP 스캐너: 기본적으로 60초마다 실행되는 낮은 우선순위 프로세스입니다. 이 프로세스에서는 전체 BGP 테이블을 검사하여 next-hop 연결성을 확인하고, 경로에 변경 사항이 있을 경우 그에 따라 BGP 테이블을 업데이트합니다. 재배포 목적으로 RIB(Routing Information Base)를 실행합니다.
더 많은 접두사와 경로가 설치되고 TCAM이 사용됨에 따라 더 많은 리소스가 필요하며 일반적으로 오버로드된 디바이스가 이러한 상황을 초래하는지 플랫폼 규모를 확인하십시오.
- BGP I/O: BGP 제어 패킷이 수신될 때 실행되며 BGP 패킷의 대기 및 처리를 관리합니다. BGP 대기열에서 오랫동안 과도한 패킷이 수신되거나 TCP에 문제가 있는 경우 라우터는 BGP I/O 프로세스로 인해 CPU가 높은 증상을 보입니다. (일반적으로 BGP 라우터도 이 상황에서 높습니다. 피어를 식별하기 위한 메시지 카운트와 이러한 메시지의 소스를 식별하기 위한 패킷을 확인합니다.)
- BGP Open: 세션 설정에 사용되는 프로세스입니다. 세션이 Open State(열기 상태)에서 중단되지 않는 한 일반적인 높은 CPU 문제는 아닙니다.
- BGP 이벤트: next-hop 처리를 담당합니다. 수신된 접두사에서 다음 홉 플랩을 찾습니다.
관련 정보
- 기술 지원 및 문서 − Cisco Systems
- BGP 컨피그레이션 가이드
- BGP 피어 간 MD5 인증 컨피그레이션 예
- 임베디드 패킷 캡처
- MTU 트러블슈팅이 포함된 BGP 인접 디바이스 플랩
- 지원되지 않는 기능으로 인해 BGP 피어 오작동
- BGP 최적 경로 선택 알고리즘
- BGP RIB-failure 및 명령 bgp suppress-inactive 이해
- 네트워크 페일오버 시나리오에서 BGP 가중치 경로 속성의 중요성 이해
- BGP "Slow Peer(느린 피어)" 기능을 사용하여 느린 피어 문제 해결
- 최적의 성능 및 메모리 소비 감소를 위해 BGP 라우터 구성
- BGP 스캐너 또는 라우터 프로세스로 인한 높은 CPU 문제 해결
개정 이력
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
3.0 |
25-Sep-2023 |
IOS XE(제거된 대시) 업데이트 및 상표, SEO 및 서식 추가. |
2.0 |
21-Feb-2023 |
재인증. |
1.0 |
04-Aug-2022 |
최초 릴리스 |
피드백