JamesMoon Tech Note

● BGP (Border Gateway Protocol) Neighbor 관계 수립 과정

자동으로 Neighbor 관계를 맺는 IGP와 달리 BGP Neighbor는 관리자가 Neighbor 설정을 해야 Neighbor 관계를 맺습니다. Neighbor 관계 맺기 위해 TCP Port 179번을 사용하며, BGP는 finite-state machine (FSM)을 이용하여 BGP PEER와 운영 상태를 관리 합니다.

  ○ IDLE State

BGP FSM의 첫 단계 입니다. 해당 상태에는 BGP Peer 연결을 위해 모든 자원을 초기화하고 외부 BGP 연결을 대기하는 상태 입니다. 해당 과정에서 문제가 발생하면 ConnectRetryTimer를 60초로 설정하고 0으로 감소 할때 까지 대기 하고 다시 연결을 시도 합니다. 이 상태에서 다시 문제가 발생하게 된다면 ConnectRetryTimer의 시간을 이전 값의 2배로 설정하고 0으로 감소 할 때 까지 대기 합니다. 

IDLE 상태 진입은 인터페이스에 IP 할당 후 Router BGP 명령어를 통해 활성화 하면 IDLE 상태로 진입 합니다.  해당 상태를 확인할 수 있는 방법은 Debugging을 통해서만 확인 가능합니다. 

  ○ Connect State

BGP가 Neighbor IP 주소로 TCP 연결을 시도하는 단계 입니다. 만약 3-Handshake가 완료된다면 ConnectRetryTImer를 초기화 하고 Open 메시지를 Neighbor에게 전송합니다. Open 메시지를 전송하면 OpenSent State로 변경 됩니다. 

Connect 단계에서 RID를 비교하여 더 높은 RID를 가진 장비가 TCP Session을 관리하게 됩니다.  해당 장비가 TCP Source Port 179번을 사용 합니다.

만약, TCP 연결에 실패하게 된다면 Active 상태로 전환 되고, 다른 입력값을 받게 된다면 상태는 IDLE로 변경 됩니다. 

  ○ Active State

Connect 단계에서 실패 후 Active 단계에서 BGP는 새로운 TCP 연결을 시도 합니다.  연결이 성공하면 Open 메시지를 전송하고 OpenSent 단계로 상태를 변경 합니다. 연결에 실패하면 Connect 단계로 변경되며 ConnectRetryTimer가 초기화 됩니다. 

  ○ OPEN Sent State

TCP 연결이 정상적으로 수립되었고 BGP Peer 라우터가 OPEN Message를 정상적으로 전송한 경우 입니다. BGP OPEN Message는 BGP Session 맺기 위한 협상정보를 가지고 있고 포함되는 정보는 아래와 같습니다.

• The BGP Version number 
  - Binary: 00000100, Decimal: 4) (IPv4 용도로 Version 4 사용 함
• The AS Number 
  - Open Message에 있는 AS Number와 수신한 라우터의 AS Number가 다를 경우 Neighbor가 수립되지 않습니다.
• The Hold Down Time value 
  - Hold Time은 기본적으로 KeepAlive값의 3배수의 TImer 값을 가집니다. BGP Peer 사이 Hold TIme이 서로 다를 경우 협상을 통해 값을 선택 합니다. 만약 Hold TIme값이 0일 경우 BGP Peer 사이에 KeepAlive메시지를 전송하지 않습니다. 
• The BGP Identifier (management IP address of the router) and Optional Parameters
  - BGP를 식별하기 위한 유일한 정보인 Router ID (RID)이 포함 됩니다. 

Open 메시지에서 오류가 없을 경우 OPEN Confirm 단계로 넘어가고, 오류가 발생할 경우 NOTIFICATION 메시지가 전송되며 IDLE 상태로 전환 됩니다.

  ○ OPEN Confirm State

BGP가 Keepalive 또는 NOTIFICATION 메시지를 기다리는 단계 입니다. Neighbor로 부터 Keepalive 메시지를 받으면 Established 단계로 넘어가게 되고, Hold TIme 이내 Keepalive 메시지를 받지 못한다면 IDLE 상태로 전환 됩니다. 

  ○ ESTABLISHED State

정상적으로 BGP Session 수립이 완료되어 Neighbor로 부터 라우팅 정보를 교환할 수 있는 상태 입니다. Neighbor로 부터 Keepalive나 Update 메시지를 받으면 Hold TIme을 초기화 시키고 Hold TIme 이내 받지 못한다면 IDLE 상태로 전환 됩니다. 

 show ip bgp summary 명령어를 통해 상태와 Neighbor 정보 및 교환된 라우팅 정보를 확인 할 수 있습니다. 

● BGP (Border Gateway Protocol) Path Attributes 소개

BGP 경로를 광고할 때 포함되는 정보들을 의미 합니다. 경로에 포함되는 정보를 이용하여 BGP는 최적경로 선출 기준으로 사용하고, 해당 경로가 어떤 AS 경로를 거쳐서 왔는지 축약 여부와 축약이 수행된 장비 정보를 확인 할 수 있습니다. 

경로 속성은 Well-Known 속성과 Optional 속성이 있으며 해당 속성은 각각 2개의 속성으로 분기 되어 총 4개의 속성이 존재 합니다. Well-Known 속성의 특징은 모든 장비가 해당 속성을 처리할 수 있으나, Optional 속성은 처리하지 못할 수도 있습니다.  하지만 BGP는 표준 프로토콜이기 때문에 현재 모든 벤더사에서 해당 속성들을 지원 합니다. 

● BGP (Border Gateway Protocol) Path Attributes 종류

  ○ Well-Known 속성

모든 장비가 지원해야 하며 Mandatory는 업데이트 메시지에 반드시 포함되어야 하지만 Discretionary는 업데이트 메시지에 없을 수 있습니다. 해당 속성은 Neighbor에게 반드시 전달 되어야 하는 항목 입니다.

 ○ Optional 속성

모든 장비가 지원하지 못할 수 있으나 사용에는 문제가 없습니다. Optional 속성을 처리하지 못하더라도 Neighbor에게 전달하며 BGP 라우터가 Optional 속성을 처리하지 못할 경우 Attribute Header앞에 bit를 추가하여 Optional 속성을 처리하지 못하는 라우터가 있음을 알립니다. 이때 추가되는 bit를 Partial bit라고 합니다. 

● BGP (Border Gateway Protocol) 란?

BGP는 소규모 네트워크 망을 위한 프로토콜이 아닌 대규모 네트워크 망에 적합한 라우팅 프로토콜 입니다. 그리고 OSPF, RIB, EIGRP 와 같은 IGP (Inter Gateway Protocol)는 Fast Convergence에 중점을 두지만 BGP는 Fast Convergence가 아닌 안정성에 더 중점을 두고 맞춰서 설계된 라우팅 프로토콜 입니다.

● BGP (Border Gateway Protocol) 특징

• TCP를 이용한 신뢰성 있는 라우팅 업데이트 수행
  - TCP Port 179을 사용하여 Neighbor 사이 신뢰 관계를 맺고, 업데이트가 누락되지 않도록 합니다. 
  
  
• KeepAlive를 이용한 Neighbor 상태 확인
  - KeepAlive를 이용하여 Neighbor의 상태를 확인 합니다. 기본적인 Timer는 Hello TIme 60초, Hold Time 180초 이며 Hold TIme 이내 Hello 메시지가 들어오지 않으면 Neighbor가 죽은 것으로 판단 합니다. 
  
  
• 주기적인 BGP 업데이트 수행
  - iBGP는 5초, eBGP는 30초 간격으로 BGP 업데이트가 수행 됩니다. 라우팅에 변화가 생길 때 마다 업데이트가 발생하게 되면 네트워크 자원소모가 많기 때문에 일정 주기로 업데이트가 수행 됩니다. 업데이트 간격 사이에 발생하는 변화는 반영하지 않고 최종 상태만 업데이트를 수행 합니다. 
  
  
• 최적 경로 선출을 위한 다양한 기준 
  - IGP와 달리 BGP는 최적 경로 선출을 위해 CISCO 기준 11개의 기준이 있으며 해당 값을 비교하여 최적 경로로 선출 된 항목만 라우팅 테이블에 내려 갑니다. 최적 경로로 선출되지 못하더라도 BGP Table에는 존재 합니다.
  
  
• 다양한 경로 속성 (Well-Known속성과 Optional 속성)
  - BGP는 경로 정보 전달 시 다양한 정보를 전달 합니다. 경로 정보에 포함되는 정보는 Well-Known 속성과 Optional 속성이 존재 합니다.  Well-Known 속성은 다시 Mandatory과 Discretionary로 분류 되며 모든 장비에서 지원 합니다. Optional 속성은 전달 가능한 속성 (Transitive Optional Attribute)와 전달 하지 못하는 속성 (Non-Transitive Optional Attribute)로 나뉘며 장비에 따라 지원여부를 확인해 보아야 합니다. 
  
  
• BGP 경로 속성을 이용한 트래픽 조절
  - Local AS에서 외부로 경로를 전송할 때는 다양한 방법(Weight, Local Preference, ETC...)으로 제어가 가능하지만 유입되는 트래픽을 조절 할 수 있는 방법이 AS Path를 추가하는 방법만 존재 합니다. 
  
  
• 인접하지 않아도 BGP Neighbor 관계 수립 가능
  - 다른 라우팅 프로토콜과 달리 BGP는 인접하지 않은 라우터와도 BGP Neighbor 관계를 맺을 수 있습니다. Neighbor를 맺기 위해 사용되는 IP까지 도달할 수 있다면 Neighbor 관계를 맺는데 문제가 없습니다. 
  
  
• 다양한 프로토콜 지원 (MP-BGP)
  - RFC 2858번이 추가 되면서 BGP는 IP 이외 다른 프로토콜들도 지원 할 수 있게 되면서 MP BGP라는 이름으로 얻게 되었습니다. address family identifier (AFI)는 IPv4, IPv6와 관련이 있고, subsequent addressfamily identifier (SAFI)를 이용하여 유니캐스트 또는 멀티캐스트 트래픽 전송이 가능해졌습니다. 
  
  원래 BGP는 IPv4만 수용 가능했기에 BGP Database Table을 하나만 관리 했으나 AFI 와 SAFI 기능이 추가 되면서 BGP Database는 address family와 sub-address family 기준으로 별도로 생성되고 관리 됩니다. 

BGP 동기화는 BGP에 의해 학습한 네트워크를 IGP에서도 학습되어져 BGP 와 IGP 가 서로 동기화 되어야 한다는 것

다시한번 정리해보면 다음과 같다.

"IBGP 로 광고받은 네트워크는 IGP가 확인해주어야 한다." 

(BGP 동기화는 ibgp 경로에 대해서만 동기화 규칙이 적용된다.)

BGP 동기화 문제는 AS내에 모든 라우터가 BGP를 수행할 경우 활용할 필요가 없다.

그러나 문제되는 경우를 살펴보면 AS내에 모든 라우터들이 BGP를 수행하지 않을 경우 블랙홀 현상이 발생 할 수도 있다.

이러한 문제에 따라 동기화 법칙을 만족 시켜 주어야 하는데 만족 시키기 위한 방법으로 3가지가 있다.

1. no synchronization
2. BGP를 IGP에서 재분배
3. Confederation

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

1. no synchronization

위에 설명과 같이 AS내의 모든 라우터가 BGP를 사용한다면 동기화 법칙을 사용하지 않아도 문제가 되지 않는다.

이에 no synchronization 명령어를 통해 BGP 동기화 법칙을 적용시키지 않을 수 있다.

최근 발표된 IOS들은 기본적으로 "no synchronization" 이다.

그렇다면 synchronization 을 켰을 때 문제가 되는 상황을 확인해보자.

# 이와 같이 AS 내에 모든 라우터가 BGP 를 사용할 시에 no synchronization 로 간단히 해결 할 수 있다.

2. BGP를 IGP에 재분배

IGP 에서 BGP정보를 재분해 해줌으로 IGP가 BGP정보를 알게 됨으로 IBGP 와 IGP 간 동기화를 이룰 수 있다.

Lab을 통해 블랙홀 현상이 일어날 시 재분배로 문제를 해결해 보자.

# 블랙홀 현상을 만들기 위해 AS 24 에서 BGP 를 R2 와 R4 만 설정하고 R3는 설정하지 않는다.

    참고로 라우터 밑에 IP 는 루프백 주소이자 Router ID 로 설정한다.

위와 같이 Topology를 설정했다면 위에 설명과 같이 R3가 블랙홀 상태가 될 것이다. 이에 따른 해결로 재분배를 통해 해결해 보자.

config 방법은 생략하고 모든 config가 이루어 졌을 때 BGP Table을 보자.

# 모두 문제 없이 Besth Path를 잡는다. 그러나 실제 Ping을 해 볼 때 제대로 가지 않는 현상을 보인다. 

# 왜 이런 현상이 일어날까? 이유는 R3 라우터에 있다.

예를 들어 , R1 에서 1.1.1.0/24 네트워크 정보를 전달 할 때 R2까지 잘 전달이 된다. 그런데 R2의 네이버인 R4는 직접적으로 연결된게 아니라 

R3를 통해 연결되기 때문에 , R3는 BGP가 설정되어 있지 않으므로 R4에게 네트워크 정보만 라우팅 시킨다. 

이로 인해 R4와 R5는 1.1.1.0/24 네트워크에 대해 BGP 테이블과 라우팅 테이블에 저장 시킨다. 

그런데 이 때 R5에서 1.1.1.0/24에 패킷을 보낸다면 패킷의 흐름을 보면 목적지를 1.1.1.0/24로 하여 송신을 하는데 , 

R4까지 거처 R3에 도달했을때 문제가 발견된다. R3입장에서는 BGP로 받은정보를 당연히 라우팅 테이블에 저장시키지 않으므로 

R3에서는 1.1.1.0/24 네트워크가 존재하지 않는다.  그러므로 Ping Test 시 도달하지 못한다. 

한마디로 블랙홀 상태!!

3. Confederation

Confederation은 하나의 AS에서 서브 AS를 생성하는 것이다.

이렇게 되면 하나의 AS에 라우터들이 서로 다른 AS갖게 되어 iBGP 가 아닌 ebgp 로 정보를 주고 받게 된다.

# 이렇게 되면 R2 ,R3, R4 간이 iBGP로 정보를 보내는 것이 아니라, eBGP 로 보냄으로 Synchronization 이 해결된다.

   맨 위에서 설명한대로 , 기본적으로 동기화는 iBGP 내에서만 적용하므로 eBGP로 정보를 보내니 동기화 문제는 해결된다.

  Confederation은 설정법은 다음과 같다.

# 이렇게 AS 내 라우터에 설정함으로 IBGP 가 아닌 eBGP 정보로 주고 받게 한다.

   여기서 ebgp-multihop은 Next-hop-address 가 Connect 가 아닌 네트워크를 함으로 설정해 주는데 뒤에 홉카운트는 

   시작 라우터와 도착지 라우터까지 포함한 Hop Count 로 한다. 초과해도 좋으나 보안상 문제로 알맞게 맞추어 주는것이 좋다.

# ex) 4대의 장비가 있으면 4대 모두 OSPF full
neighbor 가 되야하는 조건

1. 물리적으로 직접 연결된 네트워크 여야 함
2. 같은 Area 여야함

* Next hop Issue *

1) [ Next Hop Address ]

목적지 네트워크로 가기 위한 다음 라우터를 Next hop 이라 하고 이 IP 주소를 Next hop address 라고 한다. 

일반적으로 알고 있던 IGP에서 Next hop address 는 Connect된 인접 라우터 인터페이스 주소로 하나 

BGP에서 Connect 된 주소나 Connect 되지 않은 주소 모두 사용이 가능하다.

또 BGP Next hop 특징은 다른 AS로 넘어갈 때는 경계 라우터를 Next hop으로 하고 

같은 AS 내부 일 경우 꼭 인접라우터를 Next hop 으로 하여 거쳐갈 필요가 없다.

# R1 에서 R4 의 1.1.4.0 네트워크로 가기 위해 Next hop address 는 먼저 AS가 바뀌는 시점에 경계라우터 R2를 Next hop 으로 하고

   다음으로 같은 AS에서 직통으로 R4를 Next hop으로 한다.

   만약 모두가 같은 AS라면 한번에 R4로 Next hop으로 잡을 것이다. 

BGP에서 Next hop은 이정도로 설명하고 Next hop 문제에 대해 알아보자.

[이슈]

 : R3 , R4 에서 R1----R2 사이 연결된 네트워크 (1.1.1.0/24) 를 모른다면 R1 네트워크로 도달 할 수 가 없다. 

   일단 R1으로 가기위해 경계라우터인 R2로 도달해야되는데 라우팅 테이블에 업으니까 말이다. 

   (1.1.1.0/24 네트웍이 R3, R4 라우팅테이블에 업으니 R2로 갈수도 업는것)

[ Next-hop 문제 2가지 방법으로 해결 ]

1. DMZ구간(1.1.1.0/24)을 IGP에 포함시키기 ( R2 에서 OSPF에 1.1.1.0/24 설정)
2.  Next-hop-self 설정 (R2 에) 

위와 같게 Lab을 통해 알아보자.

* AS 234에 IGP를 OSPF로 사용하는데 R1과 R2 연결 네트워크는 제외한다.

R3에서 BGP Table 과 Routing Table 을 보면 다음과 같다.

이를 해결하기 위해 R3와 R4 라우팅 테이블에 1.1.12.1 네트워크 정보를 추가 시킨다.

R2에서 OSPF를 설정할 때 1.1.12.1 도 포함 시킨다. 그러고 난 후 R3 테이블 보자.

이로써 IGP에서 DMZ를 추가함으로 Next-hop 문제를 해결하였다.

2) Next-hop-self 명령어

이번에는 next-hop-self 명령어를 통해 Next-hop-self 문제를 해결해 보겠다.

좀 전에 IGP에서 DMZ 구간인 1.1.12.0 네트워크를 삭제하고 R3를 보면 아까 위에 테이블과 마찬가지로 나타날 것이다.

이 때 R2에서 Next-hop 을 자신으로 한다는 명령어인 Next-hop-self 를 사용한 후 R3를 보면 다음과 같다.

* 1.1.1.0/24 에 대한 Next-hop 이 1.1.12.1 에서 R2 Router-id 인 1.1.2.2 로 변경됨으로 R3와 R4에서 도달이 가능해 졌다.

>> 이상으로 Next-hop 문제 해결 방법인 'DMZ 구간을 IGP에서 포함 시키기' 와 

     'Next-hop-self 명령어를 통한 해결' 를 알아보았다. 

1. 

https://blog.naver.com/PostView.nhn?isHttpsRedirect=true&blogId=kwi3094&logNo=120044167684 

2.

https://blog.naver.com/happy_jhyo/221287317330

3. 

https://peemangit.tistory.com/m/136

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

1. [ BGP Split Horizon 이슈 ]

보통 알고 있던 IGP 에서 Split-horizon과 BGP에서의 Split-horizon은 의미가 약간 다르다.

BGP에서 Split-horizon은 'iBGP로 광고받은 네트워크는 iBGP로 전달하지 못한다' 이다.

그림을 통해 알아보자. 

* 1.1.1.0 네트워크를 광고할 때 R3 입장에선 R2에게 iBGP로 광고를 받으나 R4에게 iBGP로 광고해야 하므로 Split horizon 규칙이 깨진다.

이런 Split horizon 문제가 발생하기 때문에 이를 해결해 주어야 하는데 3가지 방법으로 해결해 본다.

(1) Full Mesh 설정

(2) Route-Refelector 설정

(3) Confederation 설정

2. BGP Split horizon 해결 방법 

1. Full mesh 

full mesh 로 설정함이란 AS 내 모든 라우터 끼리 네이버를 맺는 것을 말한다.

위 Lab 에서 보면 R2가 R3 뿐 아니라 R4까지 네이버를 맺고 R4에서 R2까지 네이버를 맺는다.

그러면 어떻게 동작할 지 보자.

* R2에서 R4로 직통으로 iBGP로 전달해준다. 그러므로 Split horizon 문제는 해결된다.

config 후 라우팅 테이블을 보면 

* 모든 경로 가는 BGP Table이 완성 되었다.

2. Route-Reflector 

Route-reflector 는 split horizon 을 적용하지 않겠다고 선언하는 것이다.

즉 Router-reflector Client는 Split horizon 규칙을 적용하지 않는다.

* 이와 같이 R3를 RR로 하고 네이버 인 R2와 R3 를 RRC(Route-Reflector-Client)로 하면

   Split-horizon 규칙이 적용하지 않아 광고받은 iBGP 정보를 iBGP로 광고 할 수 있다.

명령어는 neighbor [Next hop] route-reflector-client 로 R3에서 R2와 R4를 RRC로 잡아주면 된다.

그러면 모든 BGP 정보가 전달되어 완벽한 BGP Table이 완성 된다.

>> RR에 대한 설명은 간단히 하고 넘어가고 추후에 BGP 속성을 알아볼때 자세히 하도록 한다.

3. Confederation 

Confederation은 앞 포스트인 동기화에서 설명하였듯이 주 AS를 서브 AS로 나누어 준다.

그러면 AS 내에서 iBGP로 정보를 보내는것이 아닌 eBGP로 보내므로 Split horizon 문제가 해결된다.

* Confederation 을 하여 BGP Split horizon 문제를 해결 하였다. 이로써 완벽한 BGP Table이 완성 된다.

>> 위 3가지 방법을 통해 BGP Split-horizon 문제를 해결 할 수 있다. 상황에 따라 다르지만 보통 RR을 사용하여 해결하는 경향이다.

https://totori.tistory.com/482

[ 해결방법 1 ]

1. Full-Mesh 설정

https://totori.tistory.com/483?category=660226 

[ 해결방법 2 ]

2. 루트 리플렉터 설정

https://totori.tistory.com/484?category=660226 

[ 해결방법 3 ]

3. Confederation (컨페더레이션) 설정

https://totori.tistory.com/485?category=660226 

4. 

https://peemangit.tistory.com/m/136