- BGP와 OSPF는 어떻게 협력하여 다른 AS의 목적지를 위한 포워딩 테이블을 세팅할 수 있을까?
- 3개의 as가 연결된 예가 있다. as는 bgp 메세지로 루트 정보를 교환한다. 이 정보는 1) 목적지 서브넷의 프리픽스 2) 목적지 서브넷으로 가는 경로 정보인 attributes(as-path,next-hop) 이다. as path는 목적지 as로 가기 위해 거쳐야 하는 as의 리스트고, 넥스트 홉은 as path를 통해 지나가는 첫 번째 as를 의미한다.
- 하나의 라우터가 동일한 서브넷 프리픽스에 대해 여러 루트 정보를 받을 수 있다. 따라서 라우터는 그 중 하나를 선택해야 한다. 가장 먼저 고려하는 선택 정보는 policy다.
- 만약 정책이 같으면 as path가 짧은 것이 우선이다. 만약 이도 같으면 가장 가까운 홉이 있는 곳을 결정하는 hot potato 라우팅을 적용한다.
- 최단 as path를 결정하면, as path상의 첫 번째 as를 연결하는 라우터인 next hop attribute를 이용한다. 위 예시에서 첫 번째 as가 as2이므로 as2의 첫 라우터인 2a로 연결하는 것이다.
- 출발지에서 2a로 가는 최단 경로는 OSPF에 의해 발견하고 결정한다.
- 최종적으로 해당 프리픽스에 대한 포워딩 테이블이 작성 된다.
- 프리픽스에 대한 여러 경로가 있는데 만약 경로들끼리 정책이 같으면 as path가 짧은 것이 우선이다. 만약 이도 같으면 가장 가까운 홉이 있는 곳을 결정하는 hot potato 라우팅을 적용한다. 1c는 as3과 as2에서 정보를 받는데, as3으로 가는 넥스트 홉은 3a고 as2는 2a 인데, 3a가 더 가까우니 as3을 선택한다.
- 최종적으로 요약하면 라우터는 bgp를 주고받아 프리픽스를 발견하고, 역시 bpg를 통해 프리픽스로 가는 여러 inter(외부)루트 중 가장 좋은 경로로 as route를 결정하며, ospf를 통해 intra(내부) as-routing으로 inter(외부)-as-route next hop으로 가는 최단 경로를 알아내고 그 최단 경로로 가기 위해 라우터의 어떤 포트로 내보내야 하는지 판단한다.
- 최종적으로 프리픽스에 대한 라우터 포트가 결정되면 포워딩 테이블에 넣는다
- bgp에서 advertisement를 하기 위해 적용되는 policy를 알아보자. a,b,c 는 w,x,y에 대한 provider 네트워크인데, w,x,y는 customer이다. x는 두 개의 네트웤에 연결된 dual-homed이다(multi-homing). x는 본인이 알게 된 루트 정보를 b나 c에 제공하지 않는다. x는 B와 C에 대한 provider가 아니기 때문이다.
- A는 w가 본인에게 딸린 프리픽스를 알려주면 A에서 w로 가는as path를 B와 C에 알려준다. 이들에게 알려줘야 w로 가는 메세지가 왔을 때 A로 전해줘야, 본인의 커스터머로 가는 것들을 전해줄 수 있기 때문이다.
- B는 BAW 경로를 x에게 알려준다. 그래야 x가 w로 갈때 어디로 내보낼지 알기 때문이다. 그러나 B는 이 정보를 C에 알려주지 않는다. C나 w가 본인 커스터머가 아니라 의무가 없기 때문이다. 따라서 본인에게 revenue가 생기냐에 따라 알림 여부가 결정된다.
- intra의 경우 내부에서만 쓰므로 정책 결정이 필요하지 않고 빠른 결정만 필요하다. inter는 외부를 거쳐가므로 나의 트래픽이 어떤 경로로 가는지, 어떤 트래픽이 내 루트를 타는지 알아야 하므로 policy를 고려해서 경로를 결정해야 한다.
- inter 는 scale 측면에서도 중요한데, 이웃 as에 advertise할 때 계층적으로 라우팅하여 테이블 사이즈를 줄일 수 있다. 또 업데이트 트래픽도 줄일 수 있다. 광범위한 네트워크를 플랫하게 적용하면 패킷의 양이 너무 많아지므로, 네트워크 규모에 비례해서 적용하면 트래픽을 줄일 수 있기 때문이다.
- intra에 서는 퍼포먼스가 중요하지만 inter에서는 policy가 훨씬 우선순위다.
- bgp는 디스턴스 벡터 유형이다. 이웃 as에게 목적지 프리픽스로 가기 위한 정보를 듣는데, 단순 거리 정보만 받는 일반 디스턴스 벡터와 다르게, 이 정보는 어떤 as를 거쳐서 가야 하는지까지 들어있다. 그러나 라우팅 루프가 생기지 않는다. 이미 그 경로 정보는 본인을 거쳐 가서 다시 들어온 정보 이기 때문이다.
- 브로드캐스트는 한 소스가 말한 데이터를 네트워크 상의 모든 노드가 알아야 하는 것이고, 멀티 캐스트는 한 소스의 데이터를 네트 워크의 복수의 노드에서 받는 것이다.
- 그림에서 소스인 R1이 하나의 데이터에 대해 전체 노드에 대한 여러가지의 복사본을 내보내므로 소스와 가까운 노드, 그림에서는 R2의 부담이 심화된다. 따라서 매우 비효율적이 된다.
- 만약 네트워크 코어의 모든 라우터들이 브로드캐스트를 위한 루트 정보를 별도로 미리 알고 있다면, r1에서 복사를 하지 않고 가까운 라우터로 몇 개의 데이터만 내보내도 각 라우터가 그 정보를 통해 데이터를 복사해서 정해진 경로로 내보내면 되므로 훨씬 효율적이게 된다.
- 그러나 소스는 이 데이터를 받는 recipient의 주소를 일일이 파악해야 하는데 이 과정이 매우 어렵다.
- 그래서 멀티 혹은 브로드캐스팅을 위한 라우팅 프로토콜이 제안됐다.
- 만약 노드에 브로드캐스트 패킷이 들어오면, 노드의 아웃풋 포트로 그 패킷을 전부 내보내야 한다. 이를 flooding이라 한다. 그런데 똑같은 패킷이 다시 들어오면 다시 보내는 루프가 생기는 브로드캐스트 스톰이 일어난다.
- 따라서 특정한 규칙에 의해 flooding을 컨트를해야 한다.
- 그래프의 모든 노드를 지나면서 루프가 없는 트리인 spanning tree(신장 트리)를 따라 브로드캐스팅이 전달된다면, 링크에 중복된 패킷이 왔다갔다하는 일이 없다.
- 멀티캐스팅의 경우 라우터가 네트워크 topology를 알고, topology의 어느 곳에 목적지가 있는지 알아야 멀티캐스트 포워딩 테이블을 작성할 수 있다.
- 모든 그룹 멤버가 하나의 트리를 사용하는 것을 shared tree라 한다.
- 각 소스에서 각 멀티캐스트 그룹 멤버로 가는 최단 경로 트리를 만들어서 그 트리에 속하는 곳으로만 내보내야 한다. 이 트리를 source based tree라 한다.
- gruop shared tree는 복잡성이 너무 높은데, 이를 해결하기 위해 센터를 루트로 하는 최단 경로 트리를 그리고, 센터는 네트워크 전체에 알려져 있으므로 라우터들은 센터 루트로 가는 최단 경로만 알고 있으면 된다.
하마드