컴퓨터 네트워크 - Intra/Inter AS Routing and SDN, ICMP

6 분 소요


K-MOOC에서 부산대학교 유영환 교수님의 “컴퓨터 네트워킹” 강의를 수강하며 적은 노트


Intra AS Routing OSPF

Intra-AS Routing: 실제 인터넷은 모든 네트워크가 플랫한 환경이 아닌 어떤 중앙 집중에서 가지치기 형태로 나오는, 트리 형태의 하위 계층을 가짐

scalability issue: 모든 목적지에 대해서 어떤 정보를 라우팅 테이블이 담기는 힘듦. 참여자 수가 늘어남에 따라 급격하게 성능이 악화되어 어느 이상이 되면 전혀 동작하지 않게 됨

autonomous system(AS): 동일한 네트워크 ID를 갖는 집합들(도메인). 한 기관에서 관리하는 네트워크 라우터들의 집합, 호스트들의 집합

  • 각 네트워크들은 개별 관리자들이 관리하고 싶어함
  • Intra: AS 내부 라우팅. 대표적으로 distance vector와 link-state
    • 같은 AS에 속한 라우터들끼리의 라우팅 알고리즘
    • 한 AS 내에서 모든 라우터들은 동일한 인트라 도메인 프로토콜(OSPF, RIP 등)을 사용
  • Inter: AS 외부 라우팅
    • BGP(Border Gateway Protocol, Path vector protocol)
  • border router(gateway router, 경계 라우터): AS와 AS를 연결해주는 라우터
  • AS 간의 라우팅을 할 때는 gateway router가 inter-domain routing을 동작
  • 하나의 라우터는 intra-AS 라우팅 + inter-AS 라우팅으로 포워딩 테이블 구성: Intra-AS 라우팅 알고리즘만으로는 외부로 가는 경로를 알 수 없기 때문에, Inter-AS 라우팅 알고리즘의 도움이 필요

OSPF(Open Shortest Path First): 단거리를 우선시하는 프로토콜, 표준이 공개되어 이를 따르면 다른 라우터들과 문제없이 통신 가능

  • link-state 알고리즘의 대표
  • OSPF 메시지를 담은 IP 헤더가 이더넷과 같은 링크 앞에 붙음. IP 레이어 바로 위에 OSPF 메시지가 올라가서 전달됨, 그 자리에 TCP나 UDP가 대신 들어갈 수 있음
  • Link-state advertisement massage를 broadcast 방식으로 서로 주고받아 현재 AS의 topology map을 알게 되고, 다익스트라 수행
  • OSPF 메시지
    • authentication: 인증을 통과하지 못한 메시지가 전달되면 topology map을 구성할 때 사용하지 않음
      • blackhole attack 방지: 어느 링크가 많은 capacity를 가진다고 거짓 정보를 보내 모든 패킷을 그 쪽으로 보냄
  • hierarchical OSPF: 만약 AS가 너무 클 경우, broadcast 메시지가 부담이 되므로 하나의 AS를 여러 area로 나누어 각각 area에 OSPF가 동작하게 함
    • 라우팅 테이블을 업데이트 하기 위한 트래픽을 최소화
    • area 간을 이어주는 border gateway router들이 존재
      • area border router: 하나의 area를 summarize해 정보를 전달
      • backbone router: area들을 연결시켜주는 역할




Inter AS Routing BGP

BGP(Border Gate Protocol): 내부 AS에서 외부 AS로 가려면 어떻게 갈지 정함

  • 표준은 아니지만 거의 표준처럼 동작
  • 네트워크와 네트워크를 연결해 실제 인터넷이 가능하게 하는 프로토콜
  • eBGP(external BGP): 서로 다른 AS에 속하는 border router들이 주고받을 때 사용하는 프로토콜
  • iBGP(internal BGP): eBGP를 통해서 얻어 온 AS 정보를 자기 AS 내부 라우터들과 공유
  • reachability information와 policy를 고려하여 길 설정
    • reachability information: 해당 AS를 통해 전달할 수 있는 네트워크 목적지 정보

BGP 메시지: TCP를 기반(신뢰성 필요)

  • semi-permanent: 완벽하진 않지만 두 AS 간에 TCP 연결이 거의 항상 되어 있음
  • 특정한 destination network prefixes를 목적지로 가진 데이터그램을 전달하기 위한 path 정보
  • ex) AS 64520이 AS 64512와 BGP 메시지 주고받기
    • AS 64520 -> AS 64512 메시지: 192.168.24, 192.168.25 등을 AS 64600 등을 거쳐서 64700으로 내가 보낼 수 있다고 알림
  • path vector 프로토콜: 전달되는 정보가 패스를 말해주는 벡터 형태 ex) 642, 646, 647
    • 어느 AS가 다른 AS로 포워드해서 내가 데이터그램을 전해주겠다고 약속
  • 메시지에 담긴 정보
    • network prefix: 보낼 수 있는 목적지 네트워크 ID
    • attribute
      • AS-PATH: path vector
      • NEXT-HOP: 내가 그 AS로 전해주기 위해 다음으로 선택할 next hop router

ex) AS2(2a, 2b, 2c, 2d), AS3(3a, 3b, 3c, 3d, x)

  1. AS3의 border router인 3a가 AS3에 X 네트워크가 있음을 알아냄
  2. AS2의 border router인 2c에게 eBGP로 알려 줌
  3. 2c는 iBGP로 내부 다른 라우터들에게 전달 A. X가 가지고 있는 network prefix + path 정보(AS3, X) + NEXT-HOP(2c)
  4. 따라서 AS2 내부 라우터들은 X에 속한 네트워크 ID가 목적지인 데이터그램은 next-hop인 2c에게 전달하면 AS3와 X를 거쳐 도착 가능함을 알 수 있음

policy-based routing: intra와 달리 inter는 어떠한 path는 accept하고, 어떤 path는 decline하는 등 policy가 중요함

  • ex) ISP(Internet Service Provider)인 A, B, C 존재, 고객 w는 A, x는 B와 C, y는 C와 연결
    1. A는 B와 C에게 Aw로 가는 path vector를 담은 BGP 메시지 전송
    2. 따라서 B는 BAw라는 path vector를 가짐, 이를 x에 알려줌
    3. 그러나 B와 C는 경쟁 업체이므로 C에게는 이를 알리지 않음. C가 자신을 통해 보내면 자신의 bandwidth 등의 자원이 소모되므로

BGP를 통한 IP-Anycast

  • IP 주소 클래스: class D, E는 실제로 라우터에 할당하기 위한 주소가 아님. 특정한 호스트 하나가 목적지가 아닐 경우 사용
    • class D: multicast, multicast group 내의 모두에게 전송
      • 앞의 4 bit가 1110
      • 나머지 28 bit로 multicast group ID 부여
    • class E: Anycast, multicast와 달리 그냥 여러 애들 중 하나만 받아도 괜찮음
      • 앞의 4 bit가 1111
      • 설계가 어려워 효율적 작동이 되지 않음. 따라서 BGP로 anycast 가능
  • anycast가 사용되는 대표적인 예: Domain Name System
    • 루트 서버가 전 세계 13개인데, 그 중 어디로 갈 지 명확하지 않음
    • 가장 가까운 곳을 anycast로 찾아냄
      • 원래 호스트는 서로 유니크한 주소를 가져야 하지만, anycast를 위해 도메인 시스템 서버에 동일한 IP 주소 할당
      • BGP 기능을 통해 AS 정보가 전달됨, 라우터들은 실제로 DNS들이 다른 애들이지만 같은 곳으로 인식
      • 따라서 전달받은 path들은 다르지만 목적지는 같다고 생각하여 알아서 가장 짧은 곳으로 업데이트
      • 가장 가까운 DNS에게 쿼리 전달 가능

Hot potato routing: 실제 패스 길이를 따지지 않고, 더 가까운 border router에게 무조건 전달

  • 밖으로 보내야 하는 데이터그램을 내부에서 오래 잡고 있으면 내부의 자원을 많이 사용
  • 전체 네트워크 관점에서는 이기적이지만, AS의 관리자가 선택할 수 있는 policy 중 하나

Intra-AS routing과 Inter-AS routing 비교

  • 둘이 서로 달라야 하는 이유: scalability
    • 모든 라우터가 한 레벨에 놓여 있다면 라우팅 테이블 업데이트 트래픽 때문에 전체 네트워크가 마비될 수 있어 AS로 구분
    • AS 내에서 intra, AS끼리는 inter로 연결
  • intra는 policy 반영 X, inter는 policy 반영 O
  • intra는 퍼포먼스가 중요, inter는 policy가 중요




Software Defined Networking

Traffic Engineering: 데이터 트래픽을 분산시키거나, 보내는 사람이 의도하는 길로 가게 해 전체적으로 트래픽의 전달을 효율적으로 만듦

  • 기존 라우팅 프로토콜은 load balancing 불가능: 그냥 목적지만 보고 전송할 뿐, 어느 노드에서 온 데이터를 반은 u로, 반은 v로 분산해서 전송할 수 없음
    • 기존의 라우팅 프로토콜이 그렇게 동작하기 때문
    • 개별적 라우터마다 라우팅 알고리즘이 생산될 때 정해져서 관리자가 교체할 수 없음

SDN(Software Defined Networking)

  • programmable 라우터: 관리자가 원하는 우선순위에 따른 알고리즘을 심을 수 있음
  • 네트워크 전체 정보를 하나의 중앙 집중 시스템으로 모아 그 정보를 기반으로 remote controller가 결정, flow table을 각 라우터에게 전달하여 라우터들은 그것에 따름
  • 데이터 로드를 적당히 분산시킬 수 있어 더 효율적으로 데이터 전달
  • remote controller는 사용자가 프로그래밍 가능
  • control plane과 data plane을 구별
    • remote controller가 경로 결정, 하부 라우터들은 데이터 전달만 함
    • 과거에는 라우터, 스위치 생산자가 인증한 어떤 특정한 라우팅 알고리즘만이 시스템에 들어 갈 수 있었음
    • 다양한 라우팅 알고리즘을 실험하여 발전 속도도 빨라짐
    • 방화벽이나 로드 밸런싱 등 사용자의 각종 정책을 반영 가능
      • Firewall(방화벽): 어떤 특정한 fault에 접근하려는 데이터나 특정 source에서 온 데이터의 접근을 막는 접근 제어 정책
    • generalized forwarding
      • 기존의 포워딩: destination-based forwarding: 목적지를 보고 최적의 next hop을 찾아 포워딩, 트래픽 엔지니어링 불가능
      • 사용자가 선택한 필드의 set을 고려해 가장 적합한 경로를 찾음
      • flow table: 플로우(하나의 source process에서 하나의 destination process로 전달되는 일련의 데이터그램의 흐름)에 대한 entry를 만들어 어떤 경로로 내보낼지 결정하는 테이블

SDN 시스템의 구분

  • 네트워크 제어 애플리케이션: 라우팅, 방화벽, 로드 밸런싱을 AS 관리자가 결정
  • SDN 컨트롤러(중앙 집중 컨트롤러): 응용의 정책들이 반영되도록 만든 API들(northbound)과 하부 스위치들과 커뮤니케이션을 위한 API들(southbound) 정의
    • logically centralized: 물리적으로 집중되면 중앙이 무너져 전체가 망가질 수 있으므로, 실제 물리적인 시스템은 분산하고 서로 동기화를 통해 논리적으로 중앙 집중
  • 데이터 평면: 컨트롤러가 결정한 플로우 테이블에 따라 데이터를 전달만 하는 스위치들




Internet Control Message Protocol

ICMP(Internet Control Message Protocol): 에러 리포팅 메시지

  • IP 프로토콜은 신뢰성을 보장하지는 않지만, 데이터를 버릴 때 버린 이유를 호스트에게 알려 주어야 호스트가 수정해서 보낼 수 있음
  • IP 데이터그램 위에서 동작
  • IP 헤더가 앞에 붙고 ICMP 메시지가 뒤에 붙어서 IP 형식으로 전달
  • type + code + 에러를 겪은 IP 데이터그램의 첫 8 byte, checksum
    • type과 코드로 ICMP 메시지를 구별
      • ex) type-3, code-0: 해당 네트워크 ID를 가진 네트워크를 찾지 못함
      • ex) type-3, code-1: 네트워크는 찾았으나 그 안의 호스트 ID는 찾지 못함
      • ex) type-11, code-0: TTL이 다 되어 버려짐
  • IPv4에도 있었으나, IPv6에 맞게 ICMPv6가 새로 제작됨
    • Packet too big 추가: IPv6은 fragmentation & reassembly가 없음


댓글남기기