MPLS 초보탈출 5차

Convergence

- 안정화된 상태에서 링크가 죽음. 라우팅 프로토콜에 의해 best path가 변경됨. mpls는 Neighbor 정보를 모두 가지고 있기 때문에, best path가 어떤 label을 가지고 있는지 다 알고있음.
- 즉, 라우팅프로토콜에 의해 best path가 바뀌면 mpls는 LIB를 보고 바로 LFIB테이블에 업데이트할 수 있음.
- 특정 장비나 링크가 죽었을 때 convergence time이 0임.
- mpls의 convergence는 전체 convergence 값에 영향을 주지 않음. 라우팅 프로토콜에 의해 ping이 빠지는 것 이외에 추가되는 convergence가 없음.

문제는 원복됐을 때...
- 링크나 장비가 다시 살아남.
- OSPF 같은 라우팅 프로토콜과 LDP는 별도로 동작함
- LDP는 router-id로 transport address랑 통신이 된 후, threeway handshake를 함
- 즉, 라우팅 프로토콜은 best path를 찾았는데, best path에서 받은 Label 정보가 없기 때문에 end-to-end 통신이 안되게 됨..

해결방안
A <-> B 간에 링크가 죽었고, A-C-B로 C라는 장비로 통신할 수 있다면 A, B는 C를 통해 targeted hello packet을 교환함으로서 세션을 맺고서 라벨 정보를 싱크를 맞출 수 있음.
- 즉, 죽은 링크에서 받은 레이블 정보를 삭제하지 않고 저장해둘 수 있음.

IGP sync 기능 사용
근데 세션을 유지하고 싶지 않을 때,
A <-> B 간에 링크가 죽었고, A-C-B로 C라는 장비로 통신할 수 있다면, OSPF 등 IGP의 host 값을 최대로 설정하면, best path가 A-C-B가 됨.
- LDP의 정보를 받기 전까지 다른 장비로 포워딩을 하게 됨
- 대부분 이 기능을 사용함.
- 즉, LDP, IGP와 싱크를 맺음.

Non Stop forwarding 기능
- sup, fib/lfib를 분리하여 재부팅을 하거나 업데이트를 하면 sup만 재부팅이 되고 fib, lfib는 그대로 동작
- 이때는 라벨이 바꼈을 때 문제가 생김.

위 해결법들의 문제점
나랑 neighbor였던 애의 label 정보를 계속 받는 것이 한계점임
neighbor가 죽었다면??
- TE 기능을 사용하면 됨. best path를 사용하다가, best path가 죽었다면 다른 경로로 가라고 TE 경로를 잡으면 됨.
- 다만, TE는 링크나 노드가 다시 살아나면 재계산을 통해 best path를 다시 잡으라고 해줘야 함.
- backup TE로 통신 중에 링크나 노드가 살아나면, 아까(위의 해결방법)는 바로 해당 노드나 링크로 패킷을 던질 수 있었는데, 이 방식은 LDP로 라벨 정보를 다시 교환이 일어나야 함.
- node protection은 re optimization에 대한 시간을 줘야 함.
- 장점 : MPLS TE는 어떤 상태에서도 연속성을 보장할 수 있음.
- 단점 : 어떤 노드가 죽을 지 모르기 때문에, 모든 가능성에 대해 TE를 만들어둬야 함.

---

switching
1. process switching : 모든 패킷을 lookup
2. fast switching : 첫 번째 패킷만 프로세스가 처리하고 미리 L2 header를 캐시에 저장한 후에 바로 붙여서 포워딩을 함.
- ex. 10.1.1.0/24, 10.1.2.0/24의 next-hop이 1.1.1.1일 때
- 처음 10.1.1.1이라는 packet이 들어오면 next-hop 1.1.1.1의 header를 만들어서 10.1.1.0/24와 header를 매핑해서 캐시 저장
- 처음 10.1.2.1이라는 packet이 들어오면 next-hop 1.1.1.1의 header를 만들어서 10.1.2.0/24와 header를 매핑해서 캐시 저장
==> 여기서 발전해서 optimal switching이 나옴.
-> 같은 next hop인 애는 따로 저장하지 않고, 묶어서 저장을 함.
3. CEF : 미리 header를 만들어두자
- next-hop에 대해 미리 ARP로 요청을 해서 header를 만들어두자

MPLS를 동작하기 위해서는 ip cef 가 enable이 되어야 함.
- cef, ldp는 별개의 프로토콜임
- ldp는 lib 테이블이 만들어지기 위해서임.

---

mpls mtu bytes
- label이 붙으면 그 사이즈만큼 header가 커짐
- maximum MTU size를 초과하면 fragment가 될 수 있음.
- 라우터 : serial / ethernet 인터페이스가 있을 때,
- serial : L3 header부터 MTU 계산됨 ==> 즉, label은 MTU에 포함되지 않음.
- ethernet : L2 header부터 MTU 계산됨
- interface MTU가 serial 인터페이스에서는 (WAN 인터페이스)는 MTU가 변형이 없고, ethernet 인터페이스는 LAN 인터페이스는 MTU가 줄어듦.
==> 그래서 MTU를 프로토콜 별로 각각 변경해줄 수 있음. (ip packet만 증가, vlan size만 증가.. 등등)
참고 : L3는 MTU size가 달라도 통신 가능, L2는 MTU size가 같아야 함.

TTL Propagation
- 전에 설명
- 추가로 내부에서는 traceroute할 때는 다 보이게 하고 싶으면, 이때는 propagate-ttl forwarded / local 명령어로 조절할 수 있음.

advertise-labels
라우팅 테이블 => Label 할당 => 서로 neighbor와 교환 => 이때 A 네트웤만 Label 통신하고 싶을 때 => ACL로 조절할 수 있음.
- 고객에 대해서만 라벨 통신을 하고 싶을 때.
- bgp로 고객 정보들의 라우팅 테이블을 만듦 => BGP이기 때문에 loopback으로 정보 전달 받음. => 그래서 loopback에 대해서만 label 정보를 교환

trouble shooting 명령어
1. show mpls ldp discovery
LIB 테이블 확인
1. show mpls ldp bindings
LFIB 테이블 확인
1. show mpls forwarding-table detail
FIB 테이블 확인
1. show ip cef 10.10.10.0 detail