MPLS 초보탈출 7차

Export, Import RT

라우터가 있고, 라우터의 VRF가 있음.
vRF에 있는 정보를 BGP로 가지고 오면서 RT값이 붙음
- BGP에서 가지고 오면서 붙는 RT값이 export RT

• export RT : customer route 정보를 VPNv4로 바꾸는 것, VPN Membership ID로 사용됨

- 외부에서 BGP로 받는 네트웤에 RT값에 들어있는데, 어떤 RT값이 붙어있는 것을 VRF에 보내줄 것이냐가 import RT

• import RT : 외부에서 들어온 정보 중 어떤 것을 VRF 테이블에 넣어줄 것인지 골라주는 것

VPN 정의

- 하나의 VPN은 공통의 라우팅 정보를 share하는 site들의 집합
- 하나의 site는 여러 VPN의 파트가 될 수 있다
- VPN을 결정하는 것은 community 값을 보고 확인할 수 있다
- 복잡한 VPN 토폴로지는 전부 PE 라우터에서 구성할 수 있다.(import/export RT 등)
A site가 있는데, A', B'', C''' site와 통신하고 싶다는 이런 요구사항을 받아서 PE 장비가 해당 VRF에 넣어줄 수 있음
-> import RT로 조절할 수 있음
하나의 VRF가 여러 개의 VPN에 속할 수 있음.
RD는 MPLS VPN 고객이 많을텐데, 이 고객들을 unique하게 만들어주는 역할을 수행해야 함
Example

- 왼쪽 아래 라우터 : A, 위에 파란색 라우터 2개 각각 B, C
- A에서 로드밸런싱을 위해서 maximum-path가 걸려있음
- 근데 RR이 B, C 정보를 받은 다음에 best path 정보만 A한테 전달함
--> 왜냐면 둘 다 같은 RD값에 같은 ip 정보니까.
- 이런것을 해결하기 위해서 B, C한테 다른 RD값을 제공함. 그럼 RR에서 B, C 정보를 모두 A한테 전달할 듯
--> 즉, RD 값은 같은 site 내에서도 겹치지 않게 하는 것이 좋음
example2.

- 모든 site는 본사를 통하고 싶음
- 작은 동그라미는 vrf, 큰 동그라미는 site
- 왼쪽 위가 본사
- 왼쪽 위의 site에 본사가 연결되어있다면, 그 site에 고객 site들 마다 vrf를 만들어서, 각각 통신하게 할 수 있음.
example3.

- 왼쪽 위 site에 vrf가 계속 생기는 것이 부담이 된다면
- import VRF, Export VRF 2개만 만듦.
- import <-> export 간에 라우팅을 시켜주면 됨.
- 그럼 모두 본사와 통신 가능해짐.
- 이때, 모든 애들이 RD값이 모두 다름
- A가 빨간색한테 정보를 줄때는 1:1 10.0.0.0/8, 빨간색이 파란색한테 정보를 줄때는 A의 정보를 2:2 10.0.0.0/8로 정보를 전달함.
--> 가운데에 RR이 있기 때문에, RR이 같은 경로의 정보가 들어와도 best path만 전달을 해줌.
RD값은 unique하게 만들어야 함
- unique하게 만드는 방법

RD - 32bit:32bit --> 앞의 32bit은 고객의 ASN 또는 고객이 많다면 IP address로 사용

왜 export RD가 VPN ID인가?
1. import RT 기준

customer A : RT == 1:1
customer VoIP : RT == 2:2
customer B : RT == 3:3

- central site A는 1:1, 2:2 둘 다 있기 때문에, 1:1 인것도 받고, 2:2인것도 받음
- site B-2는 3:3만 있기 때문에, 3:3인것만 받음
--> 그런데 이렇게 되면, central site A가 30개의 vpn에 붙어있을 때 붙어야할 정보가 너무 많음
2. export RT 기준

- 공통의 네트워크 를 share하는 애들로 나누었더니, 5개의 종류가 나옴
--> 공통의 네트워크를 share하는 애들끼리 공통의 VPN ID(export RT)를 줌

- central A는 vpn id 1:1이라고 export rt를 하나만 세팅해서 전달함.
--> 그럼 1:1을 받겠다고 import하는 애들쪽으로 다 들어감
- 즉, export RT가 VPN ID가 되는 것이고 import RT는 얘가 누구랑 통신을 해야하는 가에 대한 connectivity를 제공해줌.
- 이런식으로 디자인해라....

- 1, 3, 4는 자기자신과 본사와 통신하고 싶음
- 1, 3, 4의 share되는 네트워크는 다르지만 통신 방향이 같음
- 그래서 1, 3, 4의 RT는 1:1, 2의 RT는 2:2로 세팅함
--> 즉, 1, 3, 4가 가지고 있는 정보는 2번만 알면 되기때문에 이렇게 세팅하는 것
MPLS VPN의 장비들이 할일
PE장비가 할 일 이 많음
- 고객과 라우팅 프로토콜 돌림. 서비스 프로바이더의 IGP 돌려야 함. MPLS 돌려야 함. 고객 정보를 BGP로 전달해야하므로 MP-BGP돌림
- 모든 역할은 PE가 함.
P 장비
- 서비스 프로바이더의 IGP 돌려야 함. MPLS 돌려야 함
- 고객의 정보를 알지 못함. 레이블 기반으로 포워딩만 해주면 됨
CE 장비
- 일반 라우팅 프로토콜
MPLS VPN 장점
- 고객이 어디에 붙어있을 지 모르기 때문에 P장비들이 서로 간에 full mesh가 맺어져야 함.
- 고객의 정보가 너무 많으면 BGP만 돌리고 있는 P 장비여도 정보들이 너무 많아짐
- 그래서 MPLS VPN을 돌리게 되면 route-target-filtering이 자동으로 들어가있음.
import 시킬 RT가 아니면 다 필터링 해버림

• 중간에 다른 것도 import하겠다고 하면, 자동으로 route-refresh 명령어가 날라가서 정보를 받음.

full mesh는 어렵기 때문에, RR로 연결되어 있음.
RR은 모든 정보를 받아서 넘겨야 하기 때문에, Route-target-filtering이 자동으로 route-target-filtering이 disable됨.
- RR은 모든 정보를 받기 때문에, 리소스가 엄청 좋아야 함. 그래서 큰 장비를 사용함....

• RR은 네트워크 패킷을 포워딩 하지는 않는데, 저렇게 가운데에 있으면 포워딩을 함

- 그래서 이렇게 따로 빼놓고 라우팅 정보만 전달하는 역할을 함
mpls망에서는 P 라우터는 BGP를 돌리지 않아도 됨. 라벨로 통신하기 때문에...
고객 입장에서 ip v4를 업데이트 -> VRF가 받아서 mp bgp로 전달해줌 -> mp bgp로 넣어줄 때는 rd, export rd값이 추가가 됨 -> 이 정보를 mp bgp로 update를 함
--> mp bgp를 update를 할 때 들어가는 정보
- vpnv4
- export rt를 한 extended community가 들어감
- vpn 패킷을 포워딩하기 위한 레이블(customer network(vpnv4)에 대해 전달하면서 레이블 정보를 전달함)

여기서 잠깐!!! vrf, 글로벌 라우터 간에 mpls는 어떻게 통신이 될까?

우리가 외부에서 레이블 정보를 달고 들어옴
그때, 고객 레이블을 20번을 받는다면, 검정 인터페이스는 글로벌 라우터 인터페이스임.
172.16.1.1이 vrf와 fast 0/0 인터페이스에 연결되어 있음.
172.16.1.1의 A 고객이 네트워크 정보를 전달하면서 레이블 하나만 할당해달라고 함.
그러면 레이블 50번을 할당 받음.
그럼 글로벌 라우터의 LFIB 테이블에 50번 레이블을 달고 들어오면 untagged를 시켜서 fast 0/0으로 내보내라 next-hop은 172.16.1.1라고 저장됨.
근데 검정 인터페이스(20번이 들어오는 것)는 글로벌 인터페이스 이고, fast 0/0는 vrf의 인터페이스인데, 라우팅 테이블은 vrf, 글로벌이 서로 달라서 못보내는데, mpls는 어떻게 포워딩이 될까???

우리가 vrf를 만들때, config mode에서 ip vrf A로 만들게 됨

그리고 인터페이스에 들어가서 해당 인터페이스를 vrf A라고 주겠다고 할 때, ip vrf forwarding A라고 줌.

그 다음 인터페이스에 Ip address를 줌. ip address 10.1.1.1/24
이렇게 세팅 후 , show ip route하면 보이지 않음. show ip route vrf A라고 해야 connect로 10.1.1.0/24가 보임.
그런데 인터페이스에 추가적으로 ipv6 address 2001:41/64라고 하면,
show ip route에 보임.
--> 왜냐하면, ipv4에서 vrf를 만들고, 인터페이스의 ipv4에서 vrf A를 포워딩을 함. 즉, ipv6에 대한 vrf가 존재하지 않음.
--> 그래서 vrf를 프로토콜 가상화라고 함.
--> 그래서 mpls는 해당 인터페이스는 글로벌 라우터 꺼고 vrf라는 정보 자체도 모름. 그래서 포워딩이 가능해짐.

그래서 ip packet으로는 서로 통신할 수는 없지만, 레이블 packet으로는 vrf로 전송할 수 있음.

그럼 특정 A라는 네트워크가 direct connect된 네트워크는??

bgp가 pop이라고 전달하면, 반대편의 PE장비가 고객네트워크에 대해서 pop이니까 next-hop에 대한 정보를 Pop해버리면 ip packet으로 전달해버림.
그래서 mpls vpn에서는 direct network에 대해 pop 개념이 없음..
대신 이 vrf에 여러 네트워크가 connect되어있으면 모두 같은 라벨이 달림--> 그래서 show mpls forwarding table해서 보면 하나의 레이블로 합쳐졌다고 해서 aggregate이라고 나옴.

받았을 때, rd, rt를 때로 ipv4로 보냄.
- 그래서 고객 입장에서는 rd, rt값을 아예 모르는 것.

VRF Lite(참고)

우리 회사가 PE 장비를 통해서 통신을 하는데, PE 장비에 연결된 하나의 인터페이스는 인터넷 용, 다른 하나의 인터페이스는 mpls용으로 연결이 되어있음.

- 이 상태에서 인터넷 망으로 나가는 트래픽이 나를 통해서 인터넷으로 갈 수 있음.
- 그럼 보안 관리가 힘들어짐.

그래서 내쪽에서 vrf를 인터넷용, mpls용으로 나눔.
- 이런 경우는 하나의 장비에서 네트워크를 구분해서 사용할 수 있음(단순히 트래픽을 분리하기 위해서)

CE 장비 쪽에서 서로 간의 트래픽을 분산시키고 싶을 때 VRF Lite를 사용함...
- 이런 경우, label도 필요 없고 RT도 필요 없음. RD값만 주면 됨.

---

VPN PHP

ingress PE에서 egress PE까지 포워딩을 할 때, bgp로 받았기 때문에 next-hop로 포워딩을 하는데 만약 next-hop에 대한 label정보만 있다면, egress PE로 들어올 때 untagged시키고 FIB테이블에 넘겨주는데 FIB테이블 입장에서는 고객 네트워크 정보가 없기 때문에 모두 drop 시킬 것이다.
그래서 next hop, 고객 label 두개를 붙이자. 그런데 모든 장비는 한 개의 레이블만 처리할 수 있음.
다행이도 php 기능이 있기 때문에, 마지막 engress PE에 대한 정보는 pop이라고 알려줘서 마지막에는 vpn 레이블만 받아서 처리할 수 있음.

​고객에 대한 레이블은 bgp로 전달

next-hop에 대한 정보는 LDP로 전달

즉, label이 두 개가 필요함 ==> 이 것을 LSP Tunnel이라고 함
- 터널이란, 기존에 있던 정보에서 새롭게 해더를 붙여서 사용하는 것 임
- 고객 A가 자신끼리 통신하기 위해서, 고객 A의 라벨 뿐만이 아니라 그 안의 mpls망을 통과하기 위해서 PE의 next hop 라벨을 달고 감
- 즉, p 장비들은 고객 네트워크에 대한 정보를 모르기 때문에 vpn 레이블은 bgp next hop에 대한 정보를 붙여서 가야함.
- 그러기 위해서는 bgp에서는 반드시 next-hop-self를 주어야 함. (현재는 default가 next-hop-self)
- 고객과 내가 bgp가 돌고 있음. ebgp로 받은 정보를 ibgp로 넘길 때, next-hop-self를 하지 않으면 고객과 연결된 인터페이스 정보가 next-hop이 됨.
- 근데, confederation을 사용할 때,
- 원래는 ebgp로 받은 정보만 next-hop-self가 동작함(RR이 설정되어있고, ibgp로 연결된 장비는 next-hop-self가 동작하지 않음)
- confederation : 하나의 AS에서 작은 AS로 나눔. 실제로는 같은 AS(ibgp)지만 confederation으로 나누어놨더니 ebgp로 받았다고 생각해서 next-hop-self를 주면 자신으로 바뀜. 그러면 best path로 가지 못하고 돌아서 가게 됨
- 그래서 confederation에서는 next-hop-self를 주지 마라. 만약, 중간에 바뀌게 되면 next hop까지 갔다가, 다시 다른 곳으로 찾아가서 거기서 새로 label을 달고 감


고객에 대한 레이블은 끝과 끝의 PE장비만 알고 있음.
- 그래서 end-to-end간에 LSP 터널이 깨지면 안됨.(터널 == next hop label)
- LDP에 의해 next-hop label정보를 전달하게 되기 때문에, 중간에 LDP가 끊기면 안됨.
- 그 때, next-hop에 대해서는 절대로 summary를 시키면 안됨. LSP 터널이 summary에 의해서 끊길 수 있음.
--> 레이블을 두 개를 달고 보냈는데, 중간에 있는 애가 summary를 하게 되면 중간에서 pop을 시키게 됨. 그럼 next-hop label이 중간에 사라짐.
--> 그래서 mpls vpn뿐만이 아니라 레이블이 두 개가 달려있는 애는 절대로 summary하면 안됨

---