Konfiguracja bloku Additional IPv6 w sieci vRack

Cel

Sieć vRack stanowi globalną sieć prywatną łączącą różne produkty OVHcloud, umożliwiając tworzenie zaawansowanych rozwiązań sieciowych. Poza ułatwianiem połączeń prywatnych obsługuje również routing publicznych adresów IP.

Niniejszy przewodnik skupia się na konfiguracji dodatkowego bloku IPv6 w sieci vRack.

Wprowadzenie

IPv6 rewolucjonizuje sieciowanie w ramach sieci vRack OVHcloud, rozwiązując ograniczenia IPv4 i wprowadzając funkcje dla nowoczesnego Internetu. Jego wdrożenie jest bezpośrednią odpowiedzią na potrzebę bardziej rozbudowanych, bezpiecznych i zaawansowanych architektur internetowych. Oto kluczowe korzyści z integracji IPv6 z vRack:

• Elastyczność dla zaawansowanych sieci: IPv6 znacząco zwiększa przestrzeń adresową, zapewniając elastyczność niezbędną do skalowania infrastruktury, zarządzania scenariuszami failover i obsługi większych rozwiązań. Dzięki temu sieci mogą rosnąć i dostosowywać się bez ograniczeń przestrzeni IPv4.

• Hierarchiczny routing i segmentacja: IPv6 umożliwia wydajny hierarchiczny routing i logiczną segmentację infrastruktury. Poprawia to zarządzalność sieci i bezpieczeństwo, idealne do odsprzedaży maszyn wirtualnych z dedykowanymi podsieciami lub organizowania infrastruktury w odrębne segmenty.

• Niska latencja: Natywna, end-to-end łączność IPv6 może być czynnikiem sprzyjającym dla usług wrażliwych na opóźnienia, takich jak strumieniowanie multimediów, ponieważ wiele nowoczesnych sieci dostawców jest zbudowanych natywnie w IPv6. W takich sieciach korzystanie z usług IPv4 powoduje dodatkowe opóźnienia (i koszty).

Dzięki wykorzystaniu IPv6 w sieci vRack użytkownicy OVHcloud mogą cieszyć się bezpieczniejszym, wydajniejszym i bardziej skalowalnym środowiskiem sieciowym, gotowym na wymagania nowoczesnego użytkowania Internetu.

Wymagania wstępne

• Usługa vRack aktywowana na Twoim koncie
• Serwer kompatybilny z vRack podłączony do sieci vRack

Dostęp do Panelu klienta OVHcloud

• Link bezpośredni: vRack
• Ścieżka nawigacji: Network > Prywatna sieć vRack

W praktyce

Uzyskanie nowego dodatkowego bloku IPv6

Podczas zamawiania nowego dodatkowego bloku IPv6 należy pamiętać, że przydział jest regionalny. Oznacza to, że otrzymany blok IPv6 będzie powiązany z konkretnym regionem, określającym miejsce, w którym ruch publiczny wchodzi do sieci vRack (a zatem gdzie znajduje się brama sieciowa).

Zamów nowy dodatkowy blok IPv6

Nowy dodatkowy blok IPv6 możesz zamówić tutaj.

Następnie postępuj zgodnie z instrukcjami krok po kroku.

Nowy dodatkowy blok IPv6 będzie dostępny na stronie konfiguracji sieci vRack.

Konfiguracja IPv6 w sieci vRack (tryb podstawowy)

W tej sekcji przedstawiamy podstawową konfigurację IPv6 dla hostów podłączonych do sieci vRack.

Powyższy przykład przedstawia dwa hosty z interfejsami po stronie vRack skonfigurowanymi z publicznymi adresami IPv6. Jeden host jest skonfigurowany ręcznie, a drugi ma adres IP przypisany automatycznie przy użyciu SLAAC. Wszystkie adresy IP należą do pierwszej podsieci /64 z podanego publicznego bloku Additional IPv6 /56. Oba wykorzystują interfejs vRack do publicznej łączności IPv6.

Domyślna brama dla pierwszej podsieci /64 (mostkowanej) to pierwszy adres bloku /56. W tym przykładzie jest to 2001:41d0:abcd:ef00::1. Jest ona dystrybuowana przez SLAAC, ale musi być skonfigurowana ręcznie (jako trasa domyślna), jeśli SLAAC jest wyłączone. Zobacz sekcję Statyczna konfiguracja IP poniżej.

Przez Panel klienta OVHcloud

Po lewej stronie wyświetlona jest lista możliwych opcji (usług kwalifikujących się do konfiguracji).

Po prawej stronie widoczne jest to, co jest już skonfigurowane w sieci vRack.

Wybierz nowy dodatkowy blok IPv6 i dodaj go do sieci vRack.

Nowy dodatkowy blok IPv6 jest teraz dodany do sieci vRack.

Statyczna konfiguracja IP

Po przypisaniu bloku Additional IPv6 /56 do sieci vRack pierwsza podsieć /64 jest z nią mostkowana.

Oznacza to, że możesz łatwo używać takich adresów IP na swoich hostach ze statyczną konfiguracją IP na interfejsach vRack (patrz następna sekcja, przykładowa konfiguracja po stronie hosta).

Automatyczna konfiguracja IP (SLAAC)

Aby uprościć adresowanie IP w sieci, możesz użyć SLAAC. Można ją włączyć tylko per-mostkowana-podsieć i można ją włączyć dla pierwszej podsieci /64 bloku (ta zawsze jest mostkowana) w dowolnym momencie, używając tego przycisku:

Nie zapomnij skonfigurować SLAAC na swoim hoście.

Przez APIv6 (metoda alternatywna)

Przypisanie dodatkowego bloku IPv6 do sieci vRack

Po zamówieniu dodatkowego bloku IPv6 jest on automatycznie przypisywany do sieci vRack.

Jeśli usunąłeś ten nowy dodatkowy blok IPv6 z sieci vRack, możesz go ponownie przypisać przy użyciu tej metody POST:

🇪🇺 EU🇨🇦 CA🇺🇸 USPOST/vrack/{serviceName}/ipv6

Jak w poniższym przykładzie:

Użyj następującego wywołania, aby zweryfikować, czy blok IPv6 został przypisany:

🇪🇺 EU🇨🇦 CA🇺🇸 USGET/vrack/{serviceName}/ipv6/{ipv6}

Jak w poniższym przykładzie:

Widzimy teraz nasz blok skonfigurowany w sieci vRack. Następnym krokiem jest konfiguracja hosta lub maszyn wirtualnych.

Statyczna konfiguracja IP

Po przypisaniu bloku Additional IPv6 /56 do sieci vRack pierwsza podsieć /64 jest z nią mostkowana. Oznacza to, że możesz łatwo używać takich adresów IP na swoich hostach.

Sprawdźmy dokładnie, która podsieć jest mostkowana:

🇪🇺 EU🇨🇦 CA🇺🇸 USGET/vrack/{serviceName}/ipv6/{ipv6}/bridgedSubrange

Jak w poniższym przykładzie:

Aby uzyskać więcej szczegółów, użyj tego wywołania:

🇪🇺 EU🇨🇦 CA🇺🇸 USGET/vrack/{serviceName}/ipv6/{ipv6}/bridgedSubrange/{bridgedSubrange}

Jak w poniższym przykładzie:

Należy pamiętać, że autokonfiguracja IP (SLAAC) jest domyślnie wyłączona.

Automatyczna konfiguracja IP (SLAAC)

Aby uprościć adresowanie IP w sieci, możesz użyć SLAAC. Można ją włączyć tylko per-mostkowana-podsieć przy użyciu tej metody PUT:

🇪🇺 EU🇨🇦 CA🇺🇸 USPUT/vrack/{serviceName}/ipv6/{ipv6}/bridgedSubrange/{bridgedSubrange}

Jak w poniższym przykładzie:

Nie zapomnij skonfigurować SLAAC na swoim hoście.

Zarządzanie przepustowością publiczną IP w sieci vRack

Domyślnie bloki Additional IP routowane przez sieć vRack korzystają ze standardowej publicznej przepustowości 5 Gbps w Europie/Kanadzie/USA i 100 Mbps w regionach APAC. Szczegółowy przegląd dostępności znajdziesz w opcjach routingu publicznego na naszej stronie produktu vRack.

W miarę skalowania wymagań infrastrukturalnych użytkownicy mogą potrzebować większej przepustowości do obsługi usług o dużym natężeniu ruchu publicznego, dla których OVHcloud udostępnia płatne opcje przepustowości. Należy pamiętać, że opcje przepustowości są stosowane per-vRack i per-region. Ponieważ adresy Additional IP są powiązane z regionem, każda modyfikacja przepustowości będzie dotyczyć wszystkich adresów IP (zarówno IPv4, jak i IPv6) routowanych do konkretnej sieci vRack w danym regionie.

Polecenia po stronie hosta

$ sudo ip address add 2001:41d0:abcd:ef00::2/64 dev eth1

$ sudo ip -6 route add default via 2001:41d0:abcd:ef00::1/64 dev eth1

$ sudo ip link set up dev eth1
$ ip -6 addr list dev eth1
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet6 2001:41d0:abcd:ef00::2/64 scope global static

$ sudo sysctl -w net.ipv6.conf.eth1.accept_ra=1

$ sudo ip link set up dev eth1
$ ip -6 addr list dev eth1
4: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    inet6 2001:41d0:abcd:ef00:fe34:97ff:feb0:c166/64 scope global dynamic mngtmpaddr
       valid_lft 2322122sec preferred_lft 334922sec

Weryfikacja konfiguracji

debian@host:~$ ping 2001:41d0:900:2100:fe34:97ff:feb0:c166
PING 2001:41d0:900:2100:fe34:97ff:feb0:c166(2001:41d0:900:2100:fe34:97ff:feb0:c166) 56 data bytes
64 bytes from 2001:41d0:900:2100:fe34:97ff:feb0:c166: icmp_seq=1 ttl=64 time=0.043 ms
64 bytes from 2001:41d0:900:2100:fe34:97ff:feb0:c166: icmp_seq=2 ttl=64 time=0.034 ms

ubuntu@remote-test:~$ ping 2001:41d0:900:2100:fe34:97ff:feb0:c166
PING 2001:41d0:900:2100:fe34:97ff:feb0:c166(2001:41d0:900:2100:fe34:97ff:feb0:c166) 56 data bytes
64 bytes from 2001:41d0:900:2100:fe34:97ff:feb0:c166: icmp_seq=1 ttl=55 time=7.23 ms
64 bytes from 2001:41d0:900:2100:fe34:97ff:feb0:c166: icmp_seq=2 ttl=55 time=6.90 ms
64 bytes from 2001:41d0:900:2100:fe34:97ff:feb0:c166: icmp_seq=3 ttl=55 time=6.92 ms

Konfiguracja IPv6 w sieci vRack dla trybu routowanego

W tej sekcji przedstawiamy bardziej zaawansowaną konfigurację IPv6, w której hosty podłączone do sieci vRack działają jako routery dla hostowanych maszyn wirtualnych. Takie maszyny wirtualne mają delegowane podsieci z głównego bloku IPv6 (przedstawione kolorem pomarańczowym na schemacie poniżej).

Ścieżka ruchu jest następująca: ruch przychodzący do danej maszyny wirtualnej (z określoną podsiecią) jest routowany przez sieć vRack klienta, najpierw do określonego hosta (z adresem next-hop), a następnie przy użyciu łącza lokalnego (lub vSwitch - czarne łącze fd00::/64 na schemacie) do konkretnej maszyny wirtualnej. Ruch powrotny z takiej maszyny wirtualnej powinien używać trasy domyślnej przez pierwszą część lokalnego łącza (czarnego, fd00::1), a następnie (ewentualnie domyślnej) trasy z hosta do jego bramy sieciowej.

Dla definicji routowanej podsieci można użyć dowolnego rozmiaru prefiksu między /57 a /64.

Domyślna brama dla hosta to pierwszy adres z bloku /56, który w tym przykładzie wynosi: 2001:41d0:abcd:ef00::1. Domyślna brama używana przez maszyny wirtualne to adres ich hosta przez łącze lokalne, który w tym przykładzie wynosi fd00::1.

Definiowanie routowanej podsieci

Działania w Panelu klienta OVHcloud

Po dodaniu Additional IP do sieci vRack możesz zarządzać routowaną podsiecią, klikając przycisk Dodaj podsieć.

Aby utworzyć routowaną podsieć, musimy najpierw zdefiniować:

• podsieć w notacji CIDR (rozmiar między /57 a /64)
• adres next-hop (czyli adres IPv6 hosta)

Pamiętaj, że dana podsieć nie może pokrywać się z żadną inną zdefiniowaną podsiecią, a adres next-hop musi należeć do pierwszej części (mostkowanej podsieci /64) prefiksu Additional IPv6.

Utworzono routowaną podsieć 2001:41d0:abcd::ef10::/60 osiągalną przez next-hop 2001:41d0:abcd::ef00::2.

Polecenia APIv6

Aby utworzyć routowaną podsieć, musimy najpierw zdefiniować:

• podsieć w notacji CIDR (rozmiar między /57 a /64)
• adres next-hop (czyli adres IPv6 hosta)

Pamiętaj, że dana podsieć nie może pokrywać się z żadną inną zdefiniowaną podsiecią, a adres next-hop musi należeć do pierwszej części (mostkowanej podsieci /64) prefiksu Additional IPv6.

Poniższy przykład pokazuje, jak zdefiniować taką podsieć:

W tym przypadku zdefiniowaliśmy routowaną podsieć 2001:41d0:abcd:ef10::/60, która zostanie delegowana do maszyny wirtualnej hostowanej na: 2001:41d0:abcd:ef00::2.

Konfiguracja po stronie hosta

$ sudo ip addr add 2001:41d0:abcd:ef00::2/64 dev eth1
$ sudo ip link set dev eth1 up
$ sudo ip -6 route add default via 2001:41d0:abcd:ef00::1 dev eth1

$ sudo sysctl -w net.ipv6.conf.all.forwarding=1

$ sudo sysctl -w net.ipv6.conf.eth1.accept_ra=2

$ sudo ip -6 route add 2001:41d0:abcd:ef10::/60 via fd00::2

debian@vm-1:~$ sudo ip address add 2001:41d0:abcd:ef10::1/60 dev lo

debian@vm-1:~$ sudo ip -6 route add default via fd00::1

Weryfikacja konfiguracji

debian@host:~$ ping fd00::2
PING fd00::2(fd00::2) 56 data bytes
64 bytes from fd00::2: icmp_seq=1 ttl=64 time=0.053 ms
64 bytes from fd00::2: icmp_seq=2 ttl=64 time=0.071 ms

debian@host:~$ ping 2001:41d0:abcd:ef10::1
PING 2001:41d0:abcd:ef10::1(2001:41d0:abcd:ef10::1) 56 data bytes
64 bytes from 2001:41d0:abcd:ef10::1: icmp_seq=1 ttl=64 time=0.054 ms
64 bytes from 2001:41d0:abcd:ef10::1: icmp_seq=2 ttl=64 time=0.073 ms

debian@host:~$ ip -6 route get 2001:41d0:abcd:ef10::1
2001:41d0:abcd:ef10::1 from :: via fd00::2 dev veth1a src fd00::1 metric 1024 pref medium

debian@vm-1:~$ ip -6 route show
2001:41d0:abcd:ef10::/60 dev lo proto kernel metric 256 pref medium
fd00::/64 dev veth1b proto kernel metric 256 pref medium
default via fd00::1 dev veth1b src 2001:41d0:abcd:ef10::1 metric 1024 pref medium

debian@vm-1:~$ ping fd00::1
PING fd00::1(fd00::1) 56 data bytes
64 bytes from fd00::1: icmp_seq=1 ttl=64 time=0.051 ms
64 bytes from fd00::1: icmp_seq=2 ttl=64 time=0.070 ms

debian@vm-1:~$ ping 2001:41d0:abcd:ef00::2
PING 2001:41d0:abcd:ef00::2(2001:41d0:abcd:ef00::2) 56 data bytes
64 bytes from 2001:41d0:abcd:ef00::2: icmp_seq=1 ttl=64 time=0.050 ms
64 bytes from 2001:41d0:abcd:ef00::2: icmp_seq=2 ttl=64 time=0.080 ms

debian@vm-1:~$ ping 2001:41d0:242:d300::
PING 2001:41d0:242:d300::(2001:41d0:242:d300::) 56 data bytes
64 bytes from 2001:41d0:242:d300::: icmp_seq=1 ttl=57 time=0.388 ms
64 bytes from 2001:41d0:242:d300::: icmp_seq=2 ttl=57 time=0.417 ms

debian@vm-1:~$ ping -6 proof.ovh.net
PING proof.ovh.net(2001:41d0:242:d300:: (2001:41d0:242:d300::)) 56 data bytes
64 bytes from 2001:41d0:242:d300:: (2001:41d0:242:d300::): icmp_seq=1 ttl=57 time=0.411 ms
64 bytes from 2001:41d0:242:d300:: (2001:41d0:242:d300::): icmp_seq=2 ttl=57 time=0.415 ms

ubuntu@remote-test:~$ ping 2001:41d0:abcd:ef10::1
PING 2001:41d0:abcd:ef10::1(2001:41d0:abcd:ef10::1) 56 data bytes
64 bytes from 2001:41d0:abcd:ef10::1: icmp_seq=1 ttl=55 time=5.84 ms
64 bytes from 2001:41d0:abcd:ef10::1: icmp_seq=2 ttl=55 time=2.98 ms

ubuntu@remote-test:~$ mtr -rc1 2001:41d0:abcd:ef10::1
Start: 2024-03-26T09:26:45+0000
HOST: remote-test                  				Loss%   Snt   Last   Avg  Best  Wrst StDev
...
...
  9.|-- 2001:41d0:abcd::2:5d        				0.0%     1    1.9   1.9   1.9   1.9   0.0
 10.|-- 2001:41d0:abcd:ef00::2      				0.0%     1    2.2   2.2   2.2   2.2   0.0
 11.|-- 2001:41d0:abcd:ef10::1      				0.0%     1    2.2   2.2   2.2   2.2   0.0

Wiele lokalizacji regionalnych a globalna sieć vRack

Technologia vRack OVHcloud umożliwia organizacjom łączenie serwerów w różnych lokalizacjach tak, jakby znajdowały się w tym samym centrum danych. Z drugiej strony usługi takie jak Additional IPv6 są regionalne, co oznacza, że ich funkcjonalność jest powiązana z konkretną lokalizacją.

Poniżej przedstawiono architekturę do celów edukacyjnych z dwoma różnymi regionami i różnymi blokami Additional IPv6 ogłaszanymi z każdego z nich. Przedstawiono również hosta z adresami IP z obu sieci oraz przykład nieoptymalne trasy - hosta w jednym regionie zaadresowanego adresem IPv6 ogłaszanym w innym regionie:

Należy pamiętać, że w takich konfiguracjach (z Additional IPv6 z więcej niż jednego regionu) SLAAC musi być wyłączone w całej sieci vRack (ponieważ może to prowadzić do nieprzewidywalnych wyników i losowej utraty łączności).

Korzyści

• Lepsza łączność: Dzięki wykorzystaniu sieci vRack wraz z blokami publicznych adresów IP routowanymi w wielu lokalizacjach, firmy mogą zapewnić bezproblemową komunikację na całym świecie, niezależnie od fizycznej lokalizacji serwerów zaplecza.
• Przejście do chmury: Technologia vRack może być doskonałym czynnikiem umożliwiającym pierwsze kroki w kierunku strategii organizacyjnej "move-to-cloud", odblokowując niektóre starsze aplikacje, które nadal wymagają lokalnej komunikacji sieciowej.

Ryzyka i uwagi

• Brak obsługi SLAAC w konfiguracjach wielolokalizacyjnych: Gdy istnieje więcej niż jedna lokalizacja obsługująca routing publicznego ruchu IP (zarówno IPv4, jak i IPv6) do tej samej sieci vRack, Stateless Address Autoconfiguration (SLAAC) nie powinno być używane. Jako przykład takiej sytuacji rozważmy istniejące hosty używające adresów IPv4. Takie hosty są automatycznie rekonfigurowane przez SLAAC z bramą IPv6 skonfigurowaną z innego regionu. Wraz z priorytetyzacją IPv6 nad IPv4 przez niektóre systemy operacyjne sytuacja ta może prowadzić do nieoptymalne routingu, a nawet całkowitej utraty łączności dla takich hostów.

Znane ograniczenia

Zrozumienie ograniczeń korzystania z Additional IPv6 w środowisku vRack jest kluczowe dla efektywnego planowania sieci. Oto kluczowe ograniczenia do uwzględnienia:

• Additional IPv6 działa tylko z vRack: Należy pamiętać, że adresy Additional IPv6 można konfigurować tylko z backendami podłączonymi do sieci vRack.
• Ograniczenia SLAAC w konfiguracjach wielolokalizacyjnych: Stateless Address Autoconfiguration (SLAAC) nie jest obsługiwane, gdy publiczny ruch IP (zarówno IPv6, jak i IPv4) jest routowany do sieci vRack w wielu lokalizacjach regionalnych.
• Do 128 hostów w mostkowanej podsieci: Można używać do 128 adresów IP bezpośrednio w sieci vRack.
• Do 128 tras next-hop: Można używać do 128 tras dla routowanych podsieci wewnątrz sieci vRack.
• Limit przepustowości publicznej: Ruch wychodzący z OVHcloud do Internetu jest ograniczony do 5 Gbps per lokalizacja regionalna.
• Limity przydziału bloków IPv6: Jeden dodatkowy blok IPv6 per sieć vRack w lokalizacji regionalnej. Maksymalnie 3 bloki (/56) per lokalizacja regionalna.
• Mobilność bloków Additional IPv6: Ze względu na hierarchiczny projekt przestrzeni adresowej IPv6, bloki Additional IPv6 są specyficzne dla regionu. Oznacza to, że bloków nie można przenosić między regionami, choć mogą być ponownie przypisywane do dowolnego backendu podłączonego do sieci vRack.
• Brak bezpośredniej obsługi VLAN 802.1Q w sieci vRack przez Additional IPv6: Konfiguracja może być wykonana tylko z natywnym VLANem sieci vRack. Do przekazywania pakietów wewnątrz konkretnego VLANu (sieci vRack) potrzebny będzie dedykowany host po stronie klienta.
• Obecnie routing Additional IPv6 do sieci vRack nie jest obsługiwany w regionach APAC (Azja-Pacyfik).

Sprawdź również

Dołącz do grona naszych użytkowników.