VRF Leaking with MP-BGP between Router Sample Configuration(Cisco IOL)

1. VRF Leaking with MP-BGP between Router Sample Configuration 구성도

• 테스트 장비
  
  • 에뮬레이터 : EVE-NG
  • 라우터 : Cisco IOL I86BI_LINUX-ADVENTERPRISEK9-M, Version 15.5(2)T
  • 스위치 : Cisco IOL I86BI_LINUXL2-ADVENTERPRISEK9-M, Version 15.1
• VRF Leaking을 보다 정확히 이해하기 위해 BGP에 대한 기본적인 이해가 필요
• 테스트를 위해 R1 및 R2에 Loopback Interface를 생성
• R1 및 R2는 OSPF를 사용하여 Global Network Address 정보를 교환
• BGP 설정 전(VRF 설정)까지 R2는 R1과 비슷하게 설정
• 두 라우터 간에 MP-BGP를 사용하여 VRF Leaking 하는 것이 목표
  • ① : R1 VRF10 → R2 VRF10으로 BGP를 사용하여 Leaking 하는 것이 목표
  • ② : R2 VRF10 → R1 VRF10으로 BGP를 사용하여 Leaking 하는 것이 목표
  • ③ : R1 VRF20 → R2 VRF20으로 BGP를 사용하여 Leaking 하는 것이 목표
  • ④ : R2 VRF20 → R1 VRF20으로 BGP를 사용하여 Leaking 하는 것이 목표
  • ⑤ : R1 VRF10 → R2 VRF20으로 BGP를 사용하여 Leaking 하는 것이 목표

 

 

2. VRF Leaking with MP-BGP between Router Sample Configuration

1) Global Interface Configuration

• R1 및 R2에 Global Interface에 해당하는 IP Address를 설정

 

• SW 인터페이스에 IP Address를 설정하며 테스트를 위해 Default-Route를 설정
• 모든 SW는 SW1의 구성과 비슷하게 설정

 

• OSPF Configuration은 생략하며 OSPF Neighbor State만 확인

 

• R1 및 R2는 OSPF를 사용하여 Global Network Address 정보를 교환했으므로 SW1↔SW2 간에 통신 가능

 

2) VRF Interface Configuration

• ‘vrf definition [vrf-name]’을 지정하여 VRF를 생성
• 해당 VRF에 대한 RD(Route Distinguisher)를 지정
• 'address-family ipv4'를 설정하여 VRF IPv4를 적용할 것임을 선언
  
  • 'address-family ipv4' 설정이 없을 경우 VRF를 사용할 인터페이스에 IPv4 Address 설정 불가

 

• R1에서 VRF로 사용할 인터페이스 설정
• 'vrf forwarding [vrf-name]'을 설정하여 해당 인터페이스가 설정한 VRF에 소속되겠다고 선언
  
  • 현재 VRF는 IPv4 VRF를 의미
• 'vrf forwarding [vrf-name]' 설정 시, 기존에 입력되어 있던 IP Address가 제거되므로 주의

 

• 생성한 VRF Name, RD, Protocol, 할당한 Interface에 대한 정보 확인 가능

 

3) Global and VRF Interface Configuration Verification

• 인터페이스 Status 및 IP Address 확인이 가능하지만 VRF 별로 확인이 불가능

 

• R1에서 설정한 Global, VRF10, VRF20에 대한 설정이 라우팅 테이블에 정상적으로 올라온 것을 확인

 

• R1 및 R2에서 인접 장비까지 Ping Test 진행
• 'ping vrf [vrf-name] [destination-ip]'를 입력하여 VRF에 해당하는 장비로 Ping Test 가능

 

4) BGP Configuration

• 'address-family vpnv4'를 입력하여 MP-BGP를 구성
• 'neighbor x.x.x.x activate'를 입력하여 해당 BGP Peer에 대해 MP-BGP를 동작
  • Peer 장비에도 'activate'가 설정되어 있어야 동작
• Cisco BGP 장비는 기본적으로 Community Attribute를 전송하지 않으므로 'neighbor x.x.x.x send-community'를 설정하여 Community Attribute를 전송하도록 설정
  • both 옵션 : Standard 및 Extended Community Attribute를 전송

 

• R1↔R2 BGP Peer 상태 정상 확인

 

5) ① R1 VRF10 → R2 VRF10 Leaking with MP-BGP

• VRF10에서 Connect로 설치된 Route를 BGP로 재분배
• 당연한 말이지만 BGP로 재분배하지 않으면 BGP Peer에게 Network 정보 광고 불가능

 

• VRF10에서 Connect로 설치된 Route가 BGP Table에 Origin-Code가 '?'로 설치되어 재분배되었음을 확인

 

• R1은 BGP Table에서 Best-Path로 선출된 Route를 BGP Peer에게 광고
• Route Target Export는 BGP Peer로 광고되는 BGP Route에 Community Attribute를 추가하는 것뿐, BGP Route를 Peer에 광고하는 것 자체에 아무런 관련이 없음
• 일반 BGP Update Message에 존재하는 'Next-Hop' Attribute 및 'NLRI' Field가 없으며 'MP_REACH_NLRI' Attribute Field가 존재함을 확인

 

• 위 패킷에서 'MP_REACH_NLRI' Field를 자세히 캡처한 내용
• 'MP_REACH_NLRI' Field가 일반 BGP Update Message의 'Next-Hop' Attribute 및 'NLRI' Field에 해당하는 정보를 포함하고 있음을 확인
• RD가 12:1이고 IPv4 Prefix가 33.33.33.0/24인 VPNv4 Prefix 정보를 전달

 

• R1에서 VRF10에 'route-target export'를 12:100으로 설정

 

• '12:1:33.33.33.0/24'인 VPNv4 Prefix 정보가 R1 VRF10에서 Global로 Route Target 12:100을 달고 Leaking 되었음을 확인
• 해당 자료를 통해 Route Target을 설정하면 Community 값으로 구성된다는 것을 확인

 

• 'MP_REACH_NLRI' Field는 기존의 'Next-Hop' Attribute 및 NLRI Field의 역할을 수행
• R1 VRF10에서 Global로 Leaking된 BGP Route를 BGP Peer로 Update Message 전송

 

• 위 패킷에서 'MP_REACH_NLRI' Field를 자세히 캡처한 내용
• RD가 12:1이고 IPv4 Prefix가 33.33.33.0/24인 VPNv4 Prefix 정보를 전달

 

• 위 패킷에서 'EXTENDED_COMMUNITIES' Field를 자세히 캡처한 내용
• R1 VRF10에서 'route-target export 12:100'을 입력하여 BGP Update Message에 12:100의 값을 가진 Community Attribute를 추가

 

• 해당 명령어를 입력하여 IPv4 VRF와 BGP를 연결

 

• 현재 R2는 R1으로부터 BGP Update Message를 수신하고 있지만 Global에서 VRF10으로 Leaking이 안 되고 있는 상태

 

• 'route-target import 12:100'을 입력하여 수신된 BGP Route에 Community 값이 12:100을 가진 Route를 허용

 

• R1 Global에서 Community 12:100을 가지고 있는 Route('12:1:33.33.33.0/24'인 VPNv4 Prefix)가 VRF10으로 Leaking되었음을 확인

 

• R2 BGP Table에서 Valid 및 Best-Path Flag가 있으므로 라우팅 테이블에 설치 

 

6) ② R2 VRF10 → R1 VRF10 Leaking with MP-BGP

• VRF10에서 Connect로 설치된 Route를 BGP로 재분배
• 당연한 말이지만 BGP로 재분배하지 않으면 BGP Peer에게 Network 정보 광고 불가능

 

• VRF10에서 Connect로 설치된 Route가 BGP Table에 Origin-Code가 '?'로 설치되어 재분배되었음을 확인

 

• R2에서 VRF10에 'route-target export'를 12:100으로 설정

 

• '12:1:44.44.44.0/24'인 VPNv4 Prefix 정보가 R2 VRF10에서 Global로 Route Target 12:200을 달고 Leaking 되었음을 확인
• 해당 자료를 통해 Route Target을 설정하면 Community 값으로 구성된다는 것을 확인

 

• 'MP_REACH_NLRI' Field는 기존의 'Next-Hop' Attribute 및 NLRI Field의 역할을 수행
• R2 VRF10에서 Global로 Leaking된 BGP Route를 BGP Peer로 Update Message 전송

 

• 위 패킷에서 'MP_REACH_NLRI' Field를 자세히 캡처한 내용
• RD가 12:1이고 IPv4 Prefix가 44.44.44.0/24인 VPNv4 Prefix 정보를 전달

 

• 위 패킷에서 'EXTENDED_COMMUNITIES' Field를 자세히 캡처한 내용
• R2 VRF10에서 'route-target export 12:200'을 입력하여 BGP Update Message에 12:200의 값을 가진 Community Attribute를 추가

 

• 현재 R1은 R2로부터 BGP Update Message를 수신하고 있지만 Global에서 VRF10으로 Leaking이 안 되고 있는 상태

 

• 'route-target import 12:200'을 입력하여 수신된 BGP Route에 Community 값이 12:200을 가진 Route를 허용

 

• 'route-target import 12:200'을 입력하여 수신된 BGP Route에 Community 값이 12:200을 가진 Route를 허용

 

• R1 BGP Table에서 Valid 및 Best-Path Flag가 있으므로 라우팅 테이블에 설치 

 

• 현재 상태에서 SW3→SW4 Ping Test 정상적으로 되어야 하지만 불가한 상황
• 인터넷 및 해외 유튜버들도 동일하게 Ping Test가 불가한 상태이며 혹시 이유를 아시는 분은 댓글로 공유 부탁드립니다.

 

7) ③ R1 VRF20 → R2 VRF20 Leaking with MP-BGP

• VRF20에서 Connect로 설치된 Route를 BGP로 재분배
• 당연한 말이지만 BGP로 재분배하지 않으면 BGP Peer에게 Network 정보 광고 불가능

 

• VRF20에서 Connect로 설치된 Route가 BGP Table에 Origin-Code가 '?'로 설치되어 재분배되었음을 확인

 

• R1에서 VRF10에 'route-target export'를 12:300으로 설정

 

• '12:2:55.55.55.0/24'인 VPNv4 Prefix 정보가 R1 VRF20에서 Global로 Route Target 12:300을 달고 Leaking 되었음을 확인
• 해당 자료를 통해 Route Target을 설정하면 Community 값으로 구성된다는 것을 확인

 

• 'MP_REACH_NLRI' Field는 기존의 'Next-Hop' Attribute 및 NLRI Field의 역할을 수행
• R1 VRF20에서 Global로 Leaking된 BGP Route를 BGP Peer로 Update Message 전송

 

• 위 패킷에서 'MP_REACH_NLRI' Field를 자세히 캡처한 내용
• RD가 12:2이고 IPv4 Prefix가 55.55.55.0/24인 VPNv4 Prefix 정보를 전달

 

• 위 패킷에서 'EXTENDED_COMMUNITIES' Field를 자세히 캡처한 내용
• R2 VRF10에서 'route-target export 12:300'을 입력하여 BGP Update Message에 12:300의 값을 가진 Community Attribute를 추가

 

• 해당 명령어를 입력하여 IPv4 VRF와 BGP를 연결

 

• 현재 R2는 R1으로부터 BGP Update Message를 수신하고 있지만 Global에서 VRF20으로 Leaking이 안 되고 있는 상태

 

• 'route-target import 12:300'을 입력하여 수신된 BGP Route에 Community 값이 12:300을 가진 Route를 허용

 

• 'route-target import 12:300'을 입력하여 수신된 BGP Route에 Community 값이 12:300을 가진 Route를 허용

 

• R2 BGP Table에서 Valid 및 Best-Path Flag가 있으므로 라우팅 테이블에 설치 

 

8) ④ R2 VRF20 → R1 VRF20 Leaking with MP-BGP

• VRF20에서 Connect로 설치된 Route를 BGP로 재분배
• 당연한 말이지만 BGP로 재분배하지 않으면 BGP Peer에게 Network 정보 광고 불가능

 

• VRF20에서 Connect로 설치된 Route가 BGP Table에 Origin-Code가 '?'로 설치되어 재분배되었음을 확인

 

• R2에서 VRF20에 'route-target export'를 12:400으로 설정

 

• '12:2:66.66.66.0/24'인 VPNv4 Prefix 정보가 R2 VRF20에서 Global로 Route Target 12:400을 달고 Leaking 되었음을 확인
• 해당 자료를 통해 Route Target을 설정하면 Community 값으로 구성된다는 것을 확인

 

• 'MP_REACH_NLRI' Field는 기존의 'Next-Hop' Attribute 및 NLRI Field의 역할을 수행
• R2 VRF20에서 Global로 Leaking된 BGP Route를 BGP Peer로 Update Message 전송

 

• 위 패킷에서 'MP_REACH_NLRI' Field를 자세히 캡처한 내용
• RD가 12:2이고 IPv4 Prefix가 66.66.66.0/24인 VPNv4 Prefix 정보를 전달

 

• 위 패킷에서 'EXTENDED_COMMUNITIES' Field를 자세히 캡처한 내용
• R2 VRF20에서 'route-target export 12:400'을 입력하여 BGP Update Message에 12:400의 값을 가진 Community Attribute를 추가

 

• 현재 R1은 R2로부터 BGP Update Message를 수신하고 있지만 Global에서 VRF20으로 Leaking이 안 되고 있는 상태

 

• 'route-target import 12:400'을 입력하여 수신된 BGP Route에 Community 값이 12:400을 가진 Route를 허용

 

• 'route-target import 12:400'을 입력하여 수신된 BGP Route에 Community 값이 12:400을 가진 Route를 허용

 

• R2 BGP Table에서 Valid 및 Best-Path Flag가 있으므로 라우팅 테이블에 설치 

 

• 현재까지 설정하였을 때, R1 및 R2 BGP VPNv4 정보

 

• 현재 상태에서 SW3→SW4 Ping Test 정상적으로 되어야 하지만 불가한 상황
• 인터넷 및 해외 유튜버들도 동일하게 Ping Test가 불가한 상태이며 혹시 이유를 아시는 분은 댓글로 공유 부탁드립니다.

 

9) ⑤ R1 VRF10 → R2 VRF20 Leaking with MP-BGP

• R1 VRF10에 있는 33.33.33.0/24 정보를 R2 VRF20에 설치하는 것이 목표
• 현재 R1은 33.33.33.0/24에 Community 값 12:100를 달고 BGP Peer로 Update Message 전송

 

• 'route-target import 12:100'을 입력하여 수신된 BGP Route에 Community 값이 12:100을 가진 Route를 허용

 

• R2 BGP Table에서 Valid 및 Best-Path Flag가 있으므로 라우팅 테이블에 설치