멀티호밍

Multihoming

멀티호밍은 호스트 또는 컴퓨터 네트워크를 여러 네트워크에 연결하는 작업입니다.이는 신뢰성 또는 성능을 높이기 위해 수행할 수 있습니다.

일반적인 호스트 또는 최종 사용자 네트워크는 하나의 네트워크에만 연결됩니다.복수의 네트워크에 접속하면, 1개의 접속에 장해가 발생해도, 나머지 접속을 개입시켜 패킷을 라우팅 할 수 있기 때문에, 신뢰성이 향상됩니다.또, 복수의 네트워크에 접속하면, 스루풋을 곱한 복수의 접속을 개입시켜 데이터를 송수신 할 수 있어 행선지에 따라서는, 어느쪽의 네트워크를 경유해 라우팅 하는 것이 효율적이 되기 때문에, 퍼포먼스를 향상시킬 수도 있습니다.

변종

멀티호밍을 실행하는 방법은 여러 가지가 있습니다.

호스트 멀티호밍

단일 호스트를 여러 네트워크에 연결할 수 있습니다.예를 들어 휴대 전화가 WiFi 네트워크와 3G 네트워크에 동시에 연결되어 데스크톱 컴퓨터가 홈 네트워크와 VPN 모두에 연결되어 있을 수 있습니다.멀티홈 호스트에는 일반적으로 연결된 네트워크마다 하나씩 여러 개의 주소가 할당됩니다.

클래식 멀티호밍

기존의 멀티호밍에서는 네트워크는 복수의 프로바이더에 접속되어 독자적인 주소 범위(통상은 Provider Independent(PI; 프로바이더 독립)[1][2] 범위)를 사용합니다.네트워크의 엣지 라우터는 동적 라우팅 프로토콜(일반적으로 BGP)을 사용하여 공급자와 통신합니다. 이 프로토콜은 네트워크의 주소 범위를 모든 공급자에게 알립니다.링크 중 하나에 장애가 발생하면 동적 라우팅 프로토콜은 몇 초 또는 몇 분 내에 장애를 인식하고 나머지 링크를 호스트에 투과적으로 사용하도록 라우팅 테이블을 재구성합니다.

기존의 멀티호밍은 모든 프로바이더에 의해 수용되는 주소 공간, 퍼블릭 Autonomous System(AS; 자율 시스템) 번호 및 다이내믹라우팅 프로토콜을 사용해야 하기 때문에 비용이 많이 듭니다.멀티홈 주소 공간은 집약할 수 없기 때문에 글로벌라우팅 테이블이 [3]증가합니다.

여러 주소에 의한 멀티호밍

이 접근법에서는 네트워크는 여러 공급자에 연결되어 각 공급자에 대해 하나씩 여러 주소 범위가 할당됩니다.호스트에는,[4] 각 프로바이더에 1개씩, 복수의 주소가 할당됩니다.

복수의 주소를 가진 멀티호밍은 기존의 멀티호밍보다 저렴하며 프로바이더(홈네트워크 등)의 협조 없이 사용할 수 있지만 [5]루팅을 실행하려면 추가 기술이 필요합니다.

  • 착신 트래픽의 경우 호스트는 모든 프로바이더를 통해 도달할 수 있도록 여러 A 또는 AAAA DNS 레코드에 관련지을 필요가 있습니다.
  • 발신 트래픽의 경우는, 송신원 고유의 라우팅등의 기술을 사용해 올바른 프로바이더를 개입시켜 패킷을 라우팅 할 필요가 있습니다.또, 호스트에 의해서 적절한 송신원주소 선택 정책을 실장할 필요가 있습니다.

주의사항

신뢰성을 향상시키기 위해 멀티호밍을 사용하는 경우 Single Point of Failure(SPOF; 단일 장애점)를 제거하기 위해 주의해야 합니다.

  • 업스트림 연결:특정 네트워크 운영센터에는 독립 프로바이더에 대한 여러 업스트림링크가 필요합니다.또한 모든 업스트림링크가 동시에 파손될 가능성을 줄이기 위해 이들 업스트림링크의 물리적인 위치는 물리적으로 다양해야 합니다.즉, 기계(백호 등)가 실수로 모든 접속을 동시에 절단하지 않도록 충분히 떨어져 있어야 합니다.
  • 라우터: 라우터와 스위치는 특정 호스트에 대한 모든 네트워크 액세스를 네트워크 하드웨어 중 하나로 제어하지 않도록 배치해야 합니다.특히 여러 인터넷업링크가 모두1개의 엣지 라우터로 수렴되는 것은 드문 일이 아닙니다.이러한 설정에서는, 그 1대의 라우터가 상실되면, 그 이외의 방법으로 복수의 ISP가 사용되고 있어도, 인터넷업링크가 절단됩니다.
  • 호스트 접속: 「신뢰성이 높은」호스트는, 각각 다른 라우터 또는 스위치에 접속하는 복수의 네트워크 인터페이스를 개입시켜 네트워크에 접속할 필요가 있습니다.또는, 바람직하게는, 소정의 호스트의 기능을, 각각 다른 라우터 또는 스위치에 접속되어 있는 복수의 컴퓨터간에 복제할 수 있습니다.
  • 참조 엔티티:호스트에 액세스 할 수 있을 뿐만 아니라, 많은 경우, 호스트를 「참조」할 필요가 있습니다.대부분의 서버에서는 특히 해당 서버에 대한 이름 해결이 기능함을 의미합니다.예를 들어, 단일 요소의 장애로 인해 사용자가 해당 서버의 DNS 이름을 올바르게 해결할 수 없는 경우, 다른 연결 상태에도 불구하고 서버에 액세스할 수 없게 됩니다.

멀티호밍은 사용하는 인터페이스와 링크의 수를 늘리고 루팅을 덜 확정적으로 함으로써 네트워크 관리를[citation needed] 복잡하게 합니다.

IPv4

IPv4 에서는, 종래의 멀티 호밍이 우세합니다.이를 위해서는 네트워크에 독자적인 퍼블릭 IP 주소 범위와 퍼블릭 AS 번호가 필요합니다.

IPv4 [6]에는 복수의 주소를 가지는 멀티호밍이 실장되어 있습니다만, 호스트 실장에서는 인터페이스 마다 복수의 주소를 적절히 처리할 수 없기 때문에, 통상은 사용되지 않습니다.따라서, 「가상 인터페이스」[7]를 사용할 필요가 있습니다.

또, [8]복수의 NAT 게이트웨이를 사용해 IPv4 의 멀티 호밍을 실장할 수도 있습니다.

IPv6

IPv6 에서는, 복수의 주소를 가지는 기존의 멀티 호밍과 멀티 호밍을 모두 사용할 수 있습니다.

클래식 멀티호밍

IPv6 [9]에서는, Provider Independent Address Space(PI; 프로바이더 독립 주소 공간)를 사용할 수 있습니다.이 테크놀로지에는, IPv4 와 같이 동작해, 복수의 프로바이더간에 트래픽밸런싱을 서포트해, 컷 오버에 의해서 기존의 TCP 및 UDP 세션을 유지할 수 있는 이점이 있습니다.이러한 방법으로 멀티호밍을 처리하기 위해 필요한 라우팅 테이블의 크기가 커지면 현재의 라우터 하드웨어가 과부하가 될 것이라는 비판도 있습니다.지지자들은 새로운 하드웨어가 무어의 법칙에 따라 가격이 떨어지는 더 저렴한 메모리 때문에 이러한 증가를 감당할 수 있을 것이라고 말한다.지지자들은 또한 이것이 현재 유일한 실행 가능한 해결책이며, 더 나쁜 것은 너무 늦은 후에 완벽한 솔루션을 도입하는 것보다 지금 불완전한 솔루션을 도입하는 것이 낫다는 생각을 뒷받침하는 것이라고 말한다.

많은 ISP가 작은 프리픽스로 루트 방송을 필터링하기 때문에 글로벌 도달 가능성을 확보하기 위해서는 일반적으로 /32 등의 대규모 "ISP 크기의" IP 할당이 필요합니다.이러한 큰 프레픽스를 사용하는 것은, IPv6 의 주소 공간을 비효율적으로 사용하는 것입니다.프레픽스는 약 40억/32 에 불과합니다.그러나 실용적인 관점에서 /32를 할당하는 것은 글로벌주소 공간 비용에서 단일 IPv4 주소를 할당하는 것과 동등합니다.또, 예측 가능한 장래에 있어서, 멀티홈이 없는 엔드 포인트의 수가, 수 십억이 넘는 것과 대조적으로, 멀티홈 사이트의 수를 수백만으로 한정할 수 있다면, 이것은 받아들여질 가능성이 있습니다.ch 는, IPv6 [citation needed]엔드 포인트의 대부분을 차지할 것으로 예상됩니다.RIPE 등의 일부 Regional Internet Registry(RIR; 지역 인터넷레지스트리)는 이 목적을 위해 특정 프레픽스에서 /48을 할당하기 시작했습니다.RIPE 는, 2001:0678:/29 로부터 IPv6 프로바이더에 의존하지 않는 주소 공간 /48 이하를 할당합니다.

여러 주소에 의한 멀티호밍

IPv6 [6][10]에 대해서, 복수의 주소를 가지는 멀티 호밍이 실장되어 있습니다.발신 트래픽의 경우는, 프로토콜에 의존하지 않는(Multipath TCP, SCTP, QUIC 등) 또는 IPv6 전용(예: SIM6)의 서포트가 필요합니다.

기타 솔루션

  • 자동 번호 [6][11]재지정1개의 업링크가 다운되면 네트워크 내의 모든 주소가 새로운 /48 서브넷으로 재번호화 됩니다.트래픽을 다른 /48 서브넷으로 리디렉션하려면 DNS 및 방화벽 레코드를 업데이트해야 합니다.이 번호 변경에 의해 라이브 TCP 세션과 UDP 세션이 중단됩니다.
  • Locator/Identifier Separation Protocol(LISP)

「 」를 참조해 주세요.

레퍼런스

  1. ^ Iljitsch van Beijnum, A look at multihoming and BGP
  2. ^ Sample Configuration for BGP with Two Different Service Providers (Multihoming)
  3. ^ http://bgp.potaroo.net/
  4. ^ Scalable Support for Multi-homed Multi-provider Connectivity. doi:10.17487/RFC2260. RFC 2260.
  5. ^ Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules. doi:10.17487/RFC5220. RFC 5220.
  6. ^ a b c Matthieu Boutier; Juliusz Chroboczek (2015), "Source-specific routing", Proc. IFIP Networking 2015, arXiv:1403.0445, Bibcode:2014arXiv1403.0445B
  7. ^ Winter, Rolf; Faath, Michael; Ripke, Aneas (21 March 2016). "Multipath TCP Support for Single-homed End-systems". {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  8. ^ Vector Routing (PDF)
  9. ^ "Provider Independent (PI) IPv6 Assignments for End User Organisations".
  10. ^ Lamparter, David; Smirnov, Anton. "Destination/Source Routing". {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  11. ^ Atkinson, Randall; Carpenter, Brian E.; Flinck, Hannu (May 2010). "Renumbering Still Needs Work". {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)

추가 정보