MPLS 초보탈출 6차

VPN의 종류
전용선은 비용이 너무 많이 들기 때문에, 구간을 다른 회사와 share 해서 사용하기 위해 VPN 개념이 나옴
- 즉 VPN 기술을 사용해서 public 망이지만 private처럼 사용을 함

VPN 용어 정리
1. provider network : 네트워크 제공자
2. customer network : 고객의 네트워크
3. customer site : 고객 하나하나 site
4. P : provider의 core 장비
5. PE : provider의 edge device
6. CE : Customer Edge, Customer Equipment라고 불림

VPN은 크게 두 개로 나뉨
1. overlay vpn : service provider 입장에서 packet이 들어오면, packet의 주소를 보고 포워딩만 시켜줌
- customer가 던져준 패킷을 그대로 전송하는 역할만 수행함
- 그래서 provider입장에서 end에 뭐가 있는지 알 필요가 없음
- 고객입장에서는 point to point처럼 서비스를 함
- 우리가 알고 있는 대부분이 overlay vpn임
- 인터넷이든 frame이든 ATM이든 상관이 없음. 고객 네트웤 정보에 대해서는 아무것도 모름
- service provider가 customer 끼리 point to point로 연결되어있는 것 처럼 통신을 시켜준다
- 라우팅 프로토콜 : 고객입장에서 중간에 라우터가 있다고 해서 걔랑 라우팅 프로토콜을 돌리는게 아니라, 끝과 끝에 달려있는 자신의 장비와 라우팅프로토콜을 돌리는 것
-> service provider와 연관 되어있는게 아니라 지들끼리 직접 라우팅 프로토콜을 돌림.
- service provider는 customer route에 관심이 없음. 데이터를 포워딩시켜줄 뿐임.
2. peer to peer VPN : customer routing을 service provider가 같이 돌림. 고객이 ospf를 돌리면 provider도 ospf를 돌림. 즉, A 고객이 있으면 A의 정보를 모두 라우팅 테이블을 가지고 있어서 포워딩을 시킴.(종류 2가지 있음)
2-1. 아래 사진처럼 중간에 provider network를 통해서 통신을 함. 단, A는 A끼리만 통신하고, B는 B끼리만 통신을 함.
- 다만, 라우팅 프로토콜을 공유하고 있기 때문에 A, B가 같은 ip를 가지고 있으면 안됨. 그래서 provider network에서 ip를 정해줘야 함.

2-2. shared pe
- 한 라우터에 고객이 여러 개가 붙을 수 있음.
- A, B고객이 붙어있다면 서로 통신 제한을 하기 위해 route filtering, packet filtering을 함.
--> 그래서 dedicate PE 가 나옴. 고객별로 PE를 가져다 둠.

- 이렇게되면, p에서 b로 들어오는게 있으면 b의 pe, a로 들어오는게 있으면 a의 pe로 던짐.
--> 단, 이것도 ip는 겹치면 안됨

그래서 MPLS VPN이 나옴
1. overlay vpn + peer to peer vpn의 좋은 점만 가지고 만들어짐
2. 이건 peer to peer 기반의 vpn이며, p to p의 단점은 극복함.
- PE라우터는 customer와 라우팅 프로토콜을 돌림 -> 그래서 최적의 경로로 packet을 포워딩할 수 있음. (이게 p to p의 최고 장점임)

- p to p : A -> A'으로 통신을 할 때, provider network와 라우팅 프로토콜을 돌리기 때문에 최적 경로를 찾을 수 있음.
3. 쉽게 프로비져닝이 가능함.
- 복잡하게 네트웤이 구성되어있음.
--> frame relay 라면? DLCI 100번 달고 들어오면 101번 달고 보내고, 101번 달고 들어오면 102번 달고 들어오라는 설정이 되어있음. 이 상태에서 링크가 추가되면 스스로 best path를 찾지 못하고 위의 DLCI 값들을 모두 지우고 다시 101번 달고 들어온걸 111번 달고 보내 라는 것을 다시 잡아줘야 함. 링크가 삭제되도 다시 잡아줘야 함.... 만약 site가 생긴다면? 다시 dlci 를 다시 세팅해줘야함
--> 근데 point to point는? 하나의 라우팅 프로토콜이 돌고 있기 때문에 자동으로 라우팅 정보들이 업데이트 됨. 능동적인 대처가 쉬움.
4. peer to peer vpn이 물리적으로는 shared pe로 되어있지만, 논리적으로는 dedicate pe 모양이 되어있어서 packet filter가 필요하지 않음.
5. 고객 간 같은 ip를 사용할 수 있음.
--> 즉, p to p의 장점은 살리고, 단점은 없앰

어떻게 단점을 극복했을까?
ex. 하나의 pe 장비에 A, B site가 같이 연결되어있음. 하나의 라우터 안에 vrf라는 가상 라우터를 만듦. 고객 A와 연결된 인터페이스는 A VRF에 주고, B와 연결된 인터페이스는 B VRF에 줌.
- 가상 라우터가 있기 때문에 A, B는 같은 ip를 쓸 수 있음.
- service provider도 같은 ip 대역을 쓸 수 있음. service provider는 global 라우팅 테이블에 있는것
ex. VRF 로 A, B, C를 나눔. A는 A, B는 B로 넘겨줘야 함. 이걸 어떻게 하느냐?
- 첫번째 방법, 같은 고객끼리 IGP를 돌린다.

--> 장비는 3대지만, 각각 다 가상화해서 A 전용 장비 B 전용 장비가 있는 것처럼 만들 수 있음.
--> 근데, VRF의 단점은 VRF는 프로토콜 가상화임. management plan쪽이 가상화 되지 않아서 A Vrf로 telnet이 들어오면 전체 장비로 들어오는 것과 같음
- 단 방화벽은 management plan까지 가상화 되어있음. 방화벽은 A 고객은 A로 들어와서 설정하세요, B 고객은 B로 들어와서 설정하세요가 가능
- 스위치는 A가 telnet(ssh)로 들어와서 설정을 바꿔버리면 전체 장비에 영향을 받음.
-> 그래서 VDC를 만들어서 vrf를 같은 장비지만 완전히 다른 장비인것처럼 사용 가능. 다만 인터페이스는 따로 할당해줘야 함.
--> 또한, 라우팅 프로토콜의 한계가 있어서, 고객이 많아지면 안됨....
--> p장비는 모든 customer의 정보를 모두 가지고 있어야함. 고객이 많아지면 문제가 심각...
- 그래서 확장성에 문제가 있어서 이를 해결하기 위해, 라우팅 프로토콜을 하나만 돌리고 A고객의 데이터베이스,B고객의 데이터베이스로 db만 구분을 함. --> 근데, 이것도 모든 customer의 정보를 p가 알고 있어야 함
--> 그래서 customer의 네트웤이 너무 클테니까 p가 고객 정보를 모르게 해보자 함. p가 고객 정보를 모르게 하기 위해 BGP를 이용하게 됨.
--> BGP를 사용하고 나니까 생기는 문제...

- PE, P 네트웤을 아는 애들끼리 세션을 맺어야 하니까 글로벌라우터의 인터페이스와 세션을 맺어야 함.
- global 인터페이스로 iBGP를 맺어야 함.
-> A의 10.0.0.0/8, B의 10.0.0.0/8을 가지고 옴. ==> 근데 이 정보를 BGP 정보를 전달하려면 ip 가 충돌이 발생하게됨.
-> 충돌나게 하지 않기 위해, RD(route distinguisher)를 만듦(A, B 고객의 ip를 unique하게 만들어서 쫑나게 하지 않음. rd값을 붙임으로서 global하게 unique해짐. )
-> A의 RD를 1:1, B의 RD를 2:2로 설정하면 BGP 테이블에 1:1 10.0.0.0, 2:2 10.0.0.0로 저장되서 쫑나지 않음.
-> 이 주소 체계가 VPNv4임(96bit가 됨)
- 중간에 돌고 있는 iBGP는 ipv4뿐만 아니라, IPv6, VPNv4, VPNv6 등이 통신할 수 있기 때문에 이를 multi protocol BGP(MP-BGP)라고 함

- BGP 테이블에서 ipv4, ipv6, vpnv4 각각 데이터베이스를 가지고 있으면, 같은 Neighbor랑 연결이 되어있을 때, 세션은 하나의 bgp 를 통해 전달을 하게됨
--> ipv4로 전달할 때 Policy, ipv6를 전달할때 policy, vpnv4 전달할때 Policy가 각각 다 다를텐데 어떻게 관리를 하느냐?
- neighbor를 맺기 위한건 global에 세팅하고, 나머지 정책은 각각 address-family version 4, address-family version 6, address-family vpnv4에서 정책을 주자. 즉, 정책을 주는건 address-family를 통해 정책을 주는 것.

Route Distinguishers
- 정책은 address family를 사용해서 관리를 함.
- vpnv6 : ipv6 + rd(총 24byte)
- RD값은 VRF에 들어가있는 것은 그냥 ipv4임. 이걸 BGP로 가지고 올 때, RD값이 prepending이 되서 vpnv4가 되는것. MP-BGP를 통해 96bit 정보를 광고를 함. VRF로 업데이트 할 때, RD값을 때고 32bit으로 광고가 됨.


RD는 special한 의미가 없음
- only 고객의 주소가 충돌나는 것을 막기 위해서 global 하게 unique하면 됨.
- RD 값은 vpn ID로 사용된다면, 그러나 cusmomer의 모든 topology 요건을 만족 할 수 없을 것이다.
--> 즉, RD는 VPN ID로 사용되지 않는다는 것임
--> 왜??

- A는 A랑 통신할 수 있어야하고, B는 B랑 통신할 수 있어야 함. A 본사와 B 본사는 service provider의 VoIP VPN을 통해 서로 간에 통신을 할 수 있음. 그 이외는 A-B가 통신하면 안됨.
- 만약 RD값이 VPN ID로 사용된다면, A 본사, A 일반 망이 서로 id가 다 같아야 함. 근데 A본사와 B본사도 통신을 해야하니까 결국 B도 RD값이 같아야 함. 그래서 A, B가 다른 ip를 쓰게 해야 함.(ip 중복이 안됨)
- vpn의 id는 A고객은 A VPN만 속해있고, A 본사는 A VPN에도 속해있고 VoIP VPN에도 속해있고, B고객은 B VPN만 속해있는게 가능해야 함.
- bgp로 업데이트를 할때, 내가 어느 vpn에 속해 있어라는 정보를 전달해야 함. 그때 여러개가 붙을 수 있어야 함. ( 내가 여러 곳에 속해 있으면 여러 곳에 속해 있다고 전달해야 함. )근데 rd는 여러 개를 붙일 수 없기 때문에 vpn id로 사용 불가능 함
--> 그래서 RT값을 만듦. 고객이 요구하는 복잡한 조건을 만족시키기 위해 RT값을 만듦.
BGP로 업데이트를 하는데, BGP의 attribute 중에서 multi로 다수로 붙일 수 있는 것 : AS-Path, route-reflactor(cluster-id), community가 있음.
RT라는 것은 VPN v4로 업데이트 하는 것의 추가적인 attribute임. 이 추가적인 attribute를 extended BGP community값으로 만듦.
- expended community값은 항상 어떤 의미를 가지고 있음. cost냐, bandwidth냐 등의 의미. 그래서 expended community로 만듦
- community는 여러개를 붙일 수 있음