“Down BGP”연결 문제 해결


21

어제 BGP 노선 중 하나가 잠깐 동안 중단되면서 네트워크의 중단이 발생했습니다. 고맙게도 몇 분 후 연결이 보조 BGP 경로로 장애 조치되었으며 ISP 측의 종료 / 종료 후에 기본 경로가 작동하게되었습니다.

iOS 12.2 58을 실행하는 2 개의 스택 형 (백플레인) Cisco 3750e 스위치를 실행하고 있습니다.

ISP와의 대화에서 그들은 원인에 대한 명확한 답변을 줄 수 없었습니다. 앞으로이 문제를 피하기 위해 원인을 정확히 찾아 낼 수있는 방법이 있습니까?

오류 발생시 로그

172258: May  6 14:43:06: %BGP-5-ADJCHANGE: neighbor xxx.xxx.12.34 Down BGP Notification sent
172259: May  6 14:43:06: %BGP-3-NOTIFICATION: sent to neighbor xxx.xxx.12.34 4/0 (hold time expired) 0 bytes
172260: May  6 14:43:06: %BGP_SESSION-5-ADJCHANGE: neighbor xxx.xxx.12.34 IPv4 Multicast topology base removed from session  BGP Notification sent
172261: May  6 14:43:06: %BGP_SESSION-5-ADJCHANGE: neighbor xxx.xxx.12.34 IPv4 Unicast topology base removed from session  BGP Notification sent

ISP가 측면에서 BGP를 재설정하기 위해 시스템 종료 / 종료시 기록

172542: May  6 15:04:15: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/49, changed state to down
172543: May  6 15:04:16: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/49, changed state to down
172544: May  6 15:04:16: %PIM-5-NBRCHG: neighbor xxx.xxx.12.34 DOWN on interface GigabitEthernet2/0/49 non DR
172545: May  6 15:04:16: %PIM-5-NBRCHG: neighbor xxx.xxx.12.34 UP on interface GigabitEthernet2/0/49 
172546: May  6 15:04:16: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to xxx.xxx.12.35 on interface GigabitEthernet2/0/49
172547: May  6 15:04:18: %LINK-3-UPDOWN: Interface GigabitEthernet2/0/49, changed state to up
172548: May  6 15:04:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet2/0/49, changed state to up

BGP 연결이 유휴 상태에서 Up 상태로 전환 된 시점을 기록

172828: May  6 15:27:33: %BGP-5-ADJCHANGE: neighbor xxx.xxx.12.34 Up

우리 쪽의 BGP 인터페이스 (참고 : CRC, 드랍, 충돌보고 없음)

GigabitEthernet2/0/49 is up, line protocol is up (connected)
Hardware is Gigabit Ethernet, address is xxxx.xxxx
Internet address is xxx.xxx.12.35/31
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 3/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseLX SFP
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:09, output 00:00:12, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/52/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 14536000 bits/sec, 1655 packets/sec
5 minute output rate 1010000 bits/sec, 640 packets/sec
413176726 packets input, 428902543141 bytes, 0 no buffer
Received 143495 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 139275 multicast, 0 pause input
0 input packets with dribble condition detected
125748632 packets output, 42915625632 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

메타 (이미!)에는 태그에 대한 토론이 있습니다. 귀하의 cisco 모델 번호 태그를 MANUFAC-MODELSERIES로 만드는 것을 고려하십시오 (또는 메타 및 차임으로 이동하십시오). 태그는 "cisco-3700"입니다. 그렇지 않으면 하드웨어 모델 수프가 될 것입니다. 사람들이 'cisco'를 검색 / 팔로우 / 구독 할 수 있도록 'cisco'태그도 보관하십시오.
크레이그 콘스탄틴

제안 된대로 완료하십시오.
John Lee

2 개의 BGP 피어가 직접 연결되어 있는지 여부는 언급되어 있지 않습니다. 그들 사이에 다른 장치가 있으면 다른 가능한 문제가 발생할 수 있습니다.
noaru

3700은 구형 라우터이므로 cisco-3750으로 다시 태그되었습니다. Catalyst 스위치는 3750입니다.
Dave Noonan

@noaru BGP 피어 2 개가 직접 연결되었습니다.
John Lee

답변:


19

172259 : 5 월 6 일 14:43:06 : % BGP-3-NOTIFICATION : 이웃에게 보냄 xxx.xxx.12.34 4/0 (보류 시간 만료) 0 바이트

이는 일반적으로 연결의 다른 쪽이 유지 타이머 (기본값 180 초) 내에있는 어떤 유지에도 응답하지 않았 음을 의미합니다. 이 문제를 일으킬 수있는 다양한 문제가 있습니다. 일반적으로 layer3 도달 가능성 문제입니다. 다시 발생하면 핑 및 텔넷 (포트 179에 대한 텔넷, 응답하는지 확인)을 통해 피어에 테스트하여 계층 3 문제를 배제해야합니다.

계층 3 도달 가능성 문제가 아닌 경우 이웃의 한쪽 끝에 문제가있는 것입니다 (이 경우에는 먼 쪽일 가능성이 높습니다).


4

단순히 '근본 원인'을 찾고 있다면이 문제를 해결하십시오.

이 문제가 발생하기 직전에 구성 변경이 있었는지 공급자에게 문의 할 수 있습니다. Cisco 라우터에는 한 쪽이 "mpls-ip"및 / 또는 "mtu"를 사용하여 "라우트 맵"을 제거하고 다시 추가 할 때 BGP 세션이 시작되는 순간 (100 % 확실하지 않은 코드)이 있습니다. "BGP 피어링에서 구성. 이러한 종류의 유지 관리로 인해 피어링 세션에 문제가 발생하지는 않지만 이런 일이 발생한다는 이야기를 들었습니다.

또한 인터페이스를 삭제하고 문제를 '수정'하기 위해 다시 가져와야 할 것이라고 확신하지 않습니다. 피어링 세션을 재설정하는 것만으로도 충분하다고 생각하지만, 실패 시점에 트래픽이 전달되지 않으면 인터페이스를 삭제하여 다시 롤링하는 것이 중요하지 않다고 주장 할 수 있습니다.


피어링 세션 재설정에 대해 들어 보지 못했습니다. 여기에 언급 된 것과 비슷합니까? 링크 또한, 내가 연결을 다시 우리의 말에 할 수있는 일입니까?
John Lee

1
'세션 지우기'라고도하는 단순한 'clear ip bgp nei xx.xx.xx.xx'입니다. BGP 이웃을 재설정하기 만하면됩니다 (단단히 클리어하면 세션이 중단되고 다시 설정됩니다).
Justin Seabrook-Rocha

빠른 질문 : 'clear ip bgp nei'는 ISP 쪽에서 수행해야합니까, 아니면 시작 했습니까?
John Lee

어느 쪽이든 세션 지우기를 시작할 수 있습니다. 때때로 "이상한"일이 발생하는 경우 (여기에서와 같이) 양쪽 끝에서 시도해 볼 가치가 있습니다. 문제 해결을 위해 한 번에 하나씩 끝낼 것입니다.
GoatAtWork

소프트 재설정 (명령 끝에 'soft'키워드 만 추가)을 수행 할 수 있다는 점은 언급 할 가치가 있습니다. 연결 및 인접 관계를 해체하지 않고 업데이트를 강제로 다시 보냅니다.
noaru

4

MTU 문제 일 수 있습니다. 얼마 전에 이걸 했어요 정상적으로 시작되지만 많은 경로를 가진 UPDATE가 수신되면 MTU 불일치로 인해 손실됩니다. 또한 두 라우터 사이에 L2 장치 (스위치? 미디어 변환기?)가있는 경우 인터페이스가 중단되지 않고 연결이 중단 될 수 있습니다.


0

내가보고있는 것이 아닙니다. ISP의 라우터가 라우터의 hello 메시지에 응답하지 않아 BGP 연결이 끊어졌습니다. 라우터가 ISP의 hello 메시지 수신을 중단했을 수도 있지만 메시지를 명확하게 파악하여 문제를 해결하는 데 도움이되지는 않습니다. ISP 트랙에 더 집중 한 사람이 의견을 밝히고 밝힐 수 있습니까?


Hello 메시지가 아닌 keepalives를 의미합니다. 이것은 OSPF가 아닌 BGP입니다.
Niels

고마워요 나는 때때로 약간 혼란스러워합니다.
에이버리 애보트
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.