VRF Leaking with MP-BGP between Router Sample Configuration(Nokia 7750 SR)

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

• 테스트 장비
  
  • 에뮬레이터 : EVE-NG
  • 라우터 : Nokia 7750 SR-12 TiMOS-C-21.10.R1
  • 스위치 : Cisco IOL I86BI_LINUXL2-ADVENTERPRISEK9-M, Version 15.1
• MP-BGP를 이용한 VRF Leaking을 보다 정확히 이해하기 위해 BGP에 대한 기본적인 이해가 필요
• 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 하는 것이 목표
  • ④ : R1 VRF10 → R2 VRF20으로 BGP를 사용하여 Leaking 하는 것이 목표
  • 전부 자세히 설명하기에 내용이 너무 많으므로 ①, ②만 자세히 설명하고 ③, ④는 설정 및 결과 부분만 캡처
• 본 글에서는 VPRN Context에서 'vrf-target'만 이용하여 테스트를 진행
• 본 글에서 내용은 없지만 'vrf-export' 또는 'vrf-import'를 이용하여 Policy를 적용하여 VRF Target 사용 가능
  • 해당 방법은 'VRF Leaking with MP-BGP on one Router Sample Configuration'글을 참고

 

 

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

1) Global Interface Configuration

• Global에 해당하는 포트 및 인터페이스 설정
  • Nokia 7750 SR OS는 기본적으로 Ethernet Mode Network로 구성
• R2도 R1의 구성과 비슷하게 설정

 

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

 

• Global에서 OSPF Neighbor 확인 가능

 

• Global↔Global(SW1↔SW2) 간에 통신 확인

 

2) VRF Interface Configuration

• VPRN(VRF)에 설정할 포트에 'ethernet mode access'로 설정
• R2도 R1의 구성과 비슷하게 설정

 

• 'configure service vprn [service-id] name [service-name] customer [customer-id] create'를 지정하여 VPRN(VRF)를 생성
• 각 VPRN(VRF)에 RD(Route Distinguisher)를 지정
• R2도 R1의 구성과 비슷하게 설정

 

• 위에서 생성한 각 VPRN(VRF)의 Service-ID, Status, Customer-ID, Service-Name에 대한 정보 확인 가능

 

3) Global and VRF Interface Configuration Verification

• 각 라우터에서 Global 및 VPRN(VRF) 별로 인터페이스에 적용된 IP Address, Status, Binding된 Port 등 정보 확인 가능

 

• 위에서 설정한 Global, VRF10, VRF20에 대한 설정이 각 라우팅 테이블에 정상으로 올라온 것을 확인
• Global 및 VPRN(VRF)이 다르면 라우팅 테이블이 분리되어 있음을 확인

 

• 모든 장비에서 인접 장비까지 Ping Test 진행
• 'ping router [service-id] [destination-ip]'를 입력하여 각 VPRN(VRF)에 해당하는 장비로 Ping Test 가능

 

4) BGP Configuration

• 일반적으로 iBGP Peering 하는 과정과 비슷하게 설정
• 'family vpn-ipv4' 설정이 없을 경우, BGP Peer 간에 VPNv4 정보 교환 불가

 

• Address Family VPNv4를 사용하는 BGP Peering 정상 확인

 

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

• Nokia OS는 Cisco와 달리 VRF→Global(BGP)로 재분배하지 않아도 Leaking 가능
• R1 VRF10에 'vrf-terget export'를 12:100으로 설정
  • VRF IPv4 Prefix(VPNv4 Prefix) 정보가 Global인 BGP로 전달하기 위해 Route Target이 필요 
  • Route Target은 BGP Community라는 Attribute를 이용하여 전달
• VRF10에서 'route-target export target:12:100'을 입력하여 VRF10의 Route에 Community '12:100'을 달고 전달

 

• R1은 VPNv4 정보를 MP-BGP를 이용하여 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는 기존의 'Next-Hop' Attribute 및 NLRI Field의 역할을 수행
• R1 VRF10에서 Global로 Leaking된 BGP Route를 BGP Peer로 Update Message 전송

 

• 위 패킷에서 '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 정보를 전달

 

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

 

• '12:1:33.33.33.0/24'인 VPNv4 Prefix 정보가 R1 VRF10에서 Global로 Leaking 되었음을 확인

 

• 'route-target import target:12:100'을 입력하여 수신된 BGP Route에 Community 값이 12:100을 가진 Route를 허용
• 여기서 중요한 것은 VPNv4 Prefix 정보를 전달하려는 VRF에서 사용하는 'route-target export' 값과 VPNv4 Prefix 정보를 수신하려는 VRF에서 사용하는 'route-target import' 값이 동일해야 한다는 것
  
  • R1 VRF10의 Route Target Export = R2 VRF10의 Route Target Import
• VRF에 Route Target Import를 설정하지 않으면 R2 BGP Table에 해당 VPN-IPv4 정보 없음

 

• R1 Global에서 Route('12:1:33.33.33.0/24'인 VPNv4 Prefix)가 R2 BGP Table로 광고가 되었음을 확인

 

• R2 BGP Route를 자세히 확인하면 VPNv4, RD, RT, Label, Next-Hop 등 정보는 있지만 어떤 VPRN에 Import 할지 정보가 없는 상태

 

• R2 BGP Table에 R1 VRF10에 대한 VPNv4 정보가 있지만 R2 VRF10 라우팅 테이블에 정보가 없는 상태
• R2에 Tunnel이 없어서 발생되는 문제

 

• R2 VRF10에 'auto-bind-tunnel'을 설정하여 MP-BGP Peer에 대한 Tunnel을 사용하며 VPRN Service의 Automatic Binding을 구성
• 'auto-bind-tunnel'의 Tunnel Type 중 하나인 MPLS Service Packet의 GRE는 RFC 2890에 정의되어 있으며 기본적으로 4byte의 Header를 사용

 

• VRF에 'auto-bind-tunnel' 구성 후, BGP Table Deatil 정보에 어떤 VPRN에 Import 할지 확인 가능

 

• R2 BGP Table에서 Valid 및 Best-Path Flag가 있으며 VPRN 'auto-bind-tunnel'을 구성하여 라우팅 테이블에 설치 

 

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

• Nokia OS는 Cisco와 달리 VRF→Global(BGP)로 재분배하지 않아도 Leaking 가능
• R2 VRF10에 'vrf-terget export'를 12:200으로 설정
  • VRF IPv4 Prefix(VPNv4 Prefix) 정보가 Global인 BGP로 전달하기 위해 Route Target이 필요 
  • Route Target은 BGP Community라는 Attribute를 이용하여 전달
• VRF10에서 'route-target export target:12:200'을 입력하여 VRF10의 Route에 Community '12:200'을 달고 전달
• 'vrf-target export'와 'vrf-target import'를 따로 설정하면 먼저 설정한 값이 자동으로 제거되므로 Export와 Import를 동시에 설정

 

• R2는 VPNv4 정보를 MP-BGP를 이용하여 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는 기존의 'Next-Hop' Attribute 및 NLRI Field의 역할을 수행
• R1 VRF10에서 Global로 Leaking된 BGP Route를 BGP Peer로 Update Message 전송

 

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

 

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

 

• '12:1:44.44.44.0/24'인 VPNv4 Prefix 정보가 R2 VRF10에서 Global로 Leaking 되었음을 확인

 

• 'route-target import target:12:200'을 입력하여 수신된 BGP Route에 Community 값이 12:200을 가진 Route를 허용
• VRF10에 'route-target import target:12:200'을 입력하여 Community '12:200'을 달고 온 Route들을 허용
• 여기서 중요한 것은 VPNv4 Prefix 정보를 전달하려는 VRF에서 사용하는 'route-target export' 값과 VPNv4 Prefix 정보를 수신하려는 VRF에서 사용하는 'route-target import' 값이 동일해야 한다는 것
  
  • R2 VRF10의 Route Target Export = R1 VRF10의 Route Target Import

 

• R2 Global에서 Route('12:1:44.44.44.0/24'인 VPNv4 Prefix)가 R1 BGP Table로 광고가 되었음을 확인

 

• R1 VRF10에 'auto-bind-tunnel'을 설정하여 MP-BGP Peer에 대한 Tunnel을 사용하며 VPRN Service의 Automatic binding을 구성
• 'auto-bind-tunnel'의 Tunnel Type 중 하나인 MPLS Service Packet의 GRE는 RFC 2890에 때라 기본적으로 4byte의 Header를 사용

 

• R1 BGP Route를 자세히 확인하면 VPNv4, RD, RT, Label, Next-Hop 등 정보 확인 가능
• VRF에 'auto-bind-tunnel' 구성 후, BGP Table Deatil 정보에 어떤 VPRN에 Import 할지 확인 가능

 

• R1 BGP Table에서 Valid 및 Best-Path Flag가 있으며 VPRN 'auto-bind-tunnel'을 구성하여 라우팅 테이블에 설치 

 

• R1 VRF10↔R2 VRF10(SW3↔SW4) 통신 확인

 

• 여기서 MPLS Header는 VRF 구분을 하기 위한 것이며 MP-BGP Update Message 전송 시 받은 값을 붙여서 전송
  
  • 해당 Label 값은 BGP Table에서 확인 가능

 

• ICMP Request 및 Reply Packet에 있는 GRE 및 MPLS Header 부분을 자세히 캡처한 내용

 

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

• 각 VRF에 여러 개의 Route Target을 사용할 때, Policy를 사용하여 Community 지정하면 편리

 

• R1 VRF10 Prefix ↔ R2 VRF10 Prefix와 Leaking 하도록 설정

 

• Route Target Export로 설정한 값을 Community에 추가하여 MP-BGP Update Message 전송
• Route Target Import로 설정한 Community를 달고 수신한 Route들만 BGP Table(Loc-RIB)에 설치
• R1 VRF20에 'auto-bind-tunnel'을 설정하여 MP-BGP Peer에 대한 Tunnel을 사용하며 VPRN Service의 Automatic binding을 구성

 

• Route Target Export는 BGP Peer로 광고되는 BGP Route에 Community Attribute를 추가하는 것뿐, BGP Route를 Peer에 광고하는 것 자체에 아무런 관련이 없음
• R1 VRF20에서 Global로 Leaking된 BGP Route를 BGP Peer로 Update Message 전송

 

• RD가 12:2이고 IPv4 Prefix가 55.55.55.0/24인 VPNv4 Prefix 정보를 전달

 

• R1 VRF20에서 'route-target export target:12:300'을 입력하여 BGP Update Message에 12:300의 값을 가진 Community Attribute를 추가

 

• Route Target Export로 설정한 값을 Community에 추가하여 MP-BGP Update Message 전송
• Route Target Import로 설정한 Community를 달고 수신한 Route들만 BGP Table(Loc-RIB)에 설치
• R2 VRF20에 'auto-bind-tunnel'을 설정하여 MP-BGP Peer에 대한 Tunnel을 사용하며 VPRN Service의 Automatic binding을 구성

 

• Route Target Export는 BGP Peer로 광고되는 BGP Route에 Community Attribute를 추가하는 것뿐, BGP Route를 Peer에 광고하는 것 자체에 아무런 관련이 없음
• R2 VRF20에서 Global로 Leaking된 BGP Route를 BGP Peer로 Update Message 전송

 

• RD가 12:2이고 IPv4 Prefix가 66.66.66.0/24인 VPNv4 Prefix 정보를 전달

 

• R2 VRF20에서 'route-target export target:12:400'을 입력하여 BGP Update Message에 12:400의 값을 가진 Community Attribute를 추가

 

• 'R1 VRF10↔R2 VRF10' 및 'R1 VRF20↔R2 VRF20' 간에 MP-BGP를 이용하여 VPNv4 정보를 교환하고 VRF에서 Import가 설정되어 있으므로 Loc-RIB에 설치되었음을 확인

 

• R1 Local-RIB에 VPNv4, RD, RT, Label, Next-Hop 등 정보 확인 가능
• VRF에 'auto-bind-tunnel' 구성 후, BGP Table Deatil 정보에 어떤 VPRN에 Import 할지 확인 가능

 

• R2 Local-RIB에 VPNv4, RD, RT, Label, Next-Hop 등 정보 확인 가능
• VRF에 'auto-bind-tunnel' 구성 후, BGP Table Deatil 정보에 어떤 VPRN에 Import 할지 확인 가능

 

• R1 VRF10↔R2 VRF10 간에 VRF IPv4 정보가 Leaking된 것을 확인

 

• R1 VRF20↔R2 VRF20 간에 VRF IPv4 정보가 Leaking된 것을 확인

 

• R1 VRF20↔R2 VRF20(SW5↔SW6) 통신 확인

 

• 여기서 MPLS Header는 VRF 구분을 하기 위한 것이며 MP-BGP Update Message 전송 시 받은 값을 붙여서 전송
  
  • 해당 Label 값은 BGP Table에서 확인 가능

 

• ICMP Request 및 Reply Packet에 있는 GRE 및 MPLS Header 부분을 자세히 캡처한 내용

 

8) ④ R1 VRF10 ↔ R2 VRF20 Leaking with MP-BGP

• ③ 항목 진행 시, 설정한 Policy에 이어서 설정하였으며 R1 VRF10 Import 및 R2 VRF 20 Import에 대한 정의만 추가

 

• ③ 항목 진행 시, 각 BGP 라우터의 BGP Table(Loc-RIB)에 이미 VPNv4 정보가 설치되어 있었으므로 현재 달라진 점 확인이 불가 

 

• 66.66.66.0/24에 해당하는 VPNv4 정보 중, 'VPRN Imported' 항목에 VPRN 10, VPRN 20으로 표시
  • VPRN 10, VPRN 20이 Import 한다는 의미

 

• 33.33.33.0/24에 해당하는 VPNv4 정보 중, 'VPRN Imported' 항목이 VPRN 10, VPRN 20으로 표시
  • VPRN 10, VPRN 20이 Import 한다는 의미

 

• R1 VRF10↔R2 VRF20 간에 VRF IPv4 정보가 Leaking된 것을 확인

 

• R1 VRF10↔R2 VRF20(SW3↔SW6) 통신 확인

 

• 여기서 MPLS Header는 VRF 구분을 하기 위한 것이며 MP-BGP Update Message 전송 시 받은 값을 붙여서 전송
  
  • 해당 Label 값은 BGP Table에서 확인 가능