Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Ten artykuł ułatwia diagnozowanie i rozwiązywanie typowych problemów podczas pracy z usługą Azure Route Server. Skorzystaj ze wskazówek w tym artykule, aby rozwiązać problemy z łącznością, problemy z płaszczyzną sterowania i problemy operacyjne.
Problemy z połączeniem
Dlaczego moje wirtualne urządzenie sieciowe (WUS) traci łączność z internetem po ogłoszeniu trasy domyślnej (0.0.0.0/0) do serwera tras?
Gdy urządzenie WUS anonsuje trasę domyślną, usługa Route Server programuje ją dla wszystkich maszyn wirtualnych w sieci wirtualnej, w tym samego urządzenia WUS. Ta trasa domyślna ustawia urządzenie NVA jako następny przeskok dla całego ruchu przeznaczonego na internet. Jeśli urządzenie WUS wymaga łączności z Internetem, musisz skonfigurować trasę zdefiniowaną przez użytkownika (UDR), aby zastąpić tę trasę domyślną z urządzenia WUS i dołączyć trasę zdefiniowaną przez użytkownika do podsieci, w której jest hostowane urządzenie WUS. W przeciwnym razie maszyna hosta urządzenia WUS wysyła ruch związany z Internetem, w tym ruch wysyłany przez urządzenie WUS, z powrotem do samego urządzenia WUS.
Aby uzyskać więcej informacji, zobacz Trasy zdefiniowane przez użytkownika.
Wymagana konfiguracja UDR (trasy zdefiniowanej przez użytkownika):
| Marszruta | Następny skok |
|---|---|
| 0.0.0.0/0 | Internet |
Dlaczego NVA traci łączność z Route Server po wymuszeniu całego ruchu do zapory przy użyciu trasy zdefiniowanej przez użytkownika w podsieci GatewaySubnet?
Jeśli chcesz sprawdzić ruch lokalny przy użyciu firewalla, możesz przekierować cały ruch lokalny do firewalla przy użyciu trasy zdefiniowanej przez użytkownika w podsieci GatewaySubnet. Jednak definicja tras użytkownika (UDR) może spowodować przerwanie komunikacji między serwerem trasowania a bramą przez przekierowanie ruchu związanego z płaszczyzną sterowania (BGP) do zapory ogniowej. Ten problem występuje, jeśli sprawdzasz ruch kierowany do sieci wirtualnej z serwerem tras.
Aby uniknąć tego problemu, dodaj kolejną trasę zdefiniowaną przez użytkownika do tabeli tras GatewaySubnet, aby ruch płaszczyzny sterowania nie był przekierowywany do zapory (jeśli dodanie reguły BGP do zapory nie jest pożądane lub możliwe):
Przykładowa konfiguracja UDR:
| Marszruta | Następny skok |
|---|---|
| 10.0.0.0/16 | 10.0.2.1 |
| 10.0.1.0/27 | Sieć wirtualna |
W tym przykładzie:
- 10.0.0.0/16 to przestrzeń adresowa sieci wirtualnej
- 10.0.1.0/27 jest przestrzenią adresową RouteServerSubnet
- 10.0.2.1 jest adresem IP zapory
Dodano trasę zdefiniowaną przez użytkownika (UDR) z typem następnego przeskoku jako bramą sieci wirtualnej, ale ta trasa zdefiniowana przez użytkownika nie działa. Czy jest to oczekiwane?
Tak, jest to oczekiwane zachowanie. Trasy zdefiniowane przez użytkownika z typem następnego przeskoku Brama sieci wirtualnej nie są obsługiwane dla podsieci w wirtualnej sieci Route Servera oraz w równorzędnych sieciach wirtualnych. Jeśli jednak chcesz skonfigurować następny przeskok, aby był wirtualnym urządzeniem sieciowym (WUS) lub Internetem, możesz dodać trasę zdefiniowaną przez użytkownika z typem następnego przeskoku VirtualAppliance lub Internet.
Dlaczego w obowiązujących trasach interfejsu sieciowego maszyny wirtualnej mam trasę zdefiniowaną przez użytkownika (UDR) z typem następnego przeskoku ustawionym na Brak?
Jeśli anonsujesz trasę z urządzenia NVA do serwera Route Server, który dokładnie odpowiada prefiksowi innej trasy zdefiniowanej przez użytkownika, następny przeskok trasy anonsowanej musi być prawidłowy. Jeśli anonsowany następny przeskok jest modułem równoważenia obciążenia bez skonfigurowanej puli zaplecza, ta nieprawidłowa trasa ma pierwszeństwo przed trasą zdefiniowaną przez użytkownika. W obowiązujących trasach interfejsu sieciowego nieprawidłowa anonsowana trasa jest wyświetlana jako trasa zdefiniowana przez użytkownika z typem następnego przeskoku ustawionym na Brak.
Dlaczego napotykam problemy z łącznością po reklamowaniu tras Azure z powrotem do Azure?
Jeśli planujesz usunąć społeczności protokołu BGP platformy Azure z sieci wirtualnej i tras UDR (zdefiniowanych przez użytkownika), nie rozgłaszaj tych tras z powrotem na platformę Azure, ponieważ powoduje to problemy z routingiem. Nie zalecamy reklamowania tras Azure na powrót do Azure.
Dlaczego utracię łączność po skojarzeniu zasad punktu końcowego usługi z podsiecią RouteServerSubnet lub GatewaySubnet?
Jeśli połączysz politykę punktu końcowego usługi z podsiecią RouteServerSubnet lub GatewaySubnet, komunikacja między podstawową platformą zarządzającą Azure a odpowiednimi usługami Azure (Route Server i bramka VPN/ExpressRoute) może zostać zakłócona. Może to spowodować, że te zasoby Azure wchodzą w stan nieprawidłowego działania, co prowadzi do utraty łączności między obciążeniami lokalnymi i Azure.
Dlaczego utracię łączność po użyciu niestandardowego systemu DNS zamiast domyślnego (usługi DNS udostępnianego przez platformę Azure) dla sieci wirtualnej serwera Route Server?
W przypadku sieci wirtualnej, w której wdrożono usługę Route Server, jeśli nie używasz domyślnego systemu DNS (dostępnego na platformie Azure), upewnij się, że niestandardowa konfiguracja DNS może rozpoznawać nazwy domen publicznych. Dzięki temu usługi platformy Azure (route Server i VPN/brama usługi ExpressRoute) mogą komunikować się z podstawową płaszczyzną zarządzania platformy Azure.
Aby uzyskać więcej informacji, zobacz uwaga dotyczącą reguł symboli wieloznacznych w dokumentacji usługi Prywatne Rozpoznawanie Azure DNS.
Dlaczego nie mogę wykonać ping TCP z urządzenia NVA do adresu IP sąsiedniego BGP serwera routingu po nawiązaniu sesji BGP między nimi?
W niektórych NVA należy dodać trasę statyczną do podsieci Route Server, aby móc wysyłać polecenia TCP ping do Route Server z NVA i unikać flappingu sesji BGP. Jeśli na przykład serwer tras znajduje się w wersji 10.0.255.0/27, a urządzenie WUS znajduje się w wersji 10.0.1.0/24, należy dodać następującą trasę do tabeli routingu w urządzeniu WUS:
Wymagana trasa statyczna:
| Marszruta | Następny skok |
|---|---|
| 10.0.255.0/27 | 10.0.1.1 |
W tym przykładzie adres 10.0.1.1 to domyślny adres IP bramy w podsieci, w której jest hostowane urządzenie NVA (a dokładniej, jedna z kart sieciowych).
Dlaczego utracię łączność z siecią lokalną za pośrednictwem usługi ExpressRoute i/lub sieci VPN platformy Azure podczas wdrażania serwera Route Server w sieci wirtualnej, która ma już bramę usługi ExpressRoute i/lub bramę sieci VPN platformy Azure?
Podczas wdrażania Serwera Tras w sieci wirtualnej, musimy zaktualizować płaszczyznę sterowania między bramami a siecią wirtualną. Podczas tej aktualizacji występuje okres, kiedy maszyny wirtualne w sieci wirtualnej tracą łączność z siecią lokalną. Zdecydowanie zalecamy zaplanowanie konserwacji w celu wdrożenia serwera Route Server w środowisku produkcyjnym.
Problemy z płaszczyzną sterowania
Dlaczego moja sieć lokalna połączona z bramą sieci VPN platformy Azure nie odbiera trasy domyślnej anonsowanej przez serwer routingu?
Mimo że brama sieci VPN platformy Azure może odbierać trasę domyślną z elementów równorzędnych protokołu BGP, w tym z serwerem Route Server, nie anonsuje trasy domyślnej do innych elementów równorzędnych.
Dlaczego moje NVA nie otrzymuje tras z Route Servera, mimo że połączenie BGP jest aktywne?
Numer ASN, którego używa serwer tras, to 65515. Upewnij się, że skonfigurowano inny numer ASN dla urządzenia NVA, aby można było ustanowić sesję eBGP między urządzeniem NVA a serwerem tras, co pozwoli na automatyczną propagację tras. Upewnij się, że w konfiguracji protokołu BGP włączono wieloprzeskokowy, ponieważ urządzenie NVA i serwer trasowania znajdują się w różnych podsieciach w sieci wirtualnej.
Dlaczego łączność nie działa, gdy anonsuję trasy z ASN o wartości 0 w ścieżce AS?
Usługa Azure Route Server odrzuca trasy z ASN 0 w ścieżce AS-Path. Aby upewnić się, że te trasy zostały pomyślnie anonsowane na platformie Azure, ścieżka as-path nie powinna zawierać wartości 0.
Peering BGP między moją NVA a serwerem routującym jest aktywny. Widzę, że trasy są wymieniane poprawnie między nimi. Dlaczego trasy NVA nie są w efektywnej tabeli routingu mojej maszyny wirtualnej?
Jeśli maszyna wirtualna znajduje się w tej samej sieci wirtualnej co urządzenie NVA i serwer tras:
Usługa Route Server uwidacznia dwa adresy IP komunikacji równorzędnej BGP, które współdzielą odpowiedzialność za wysyłanie tras do wszystkich innych maszyn wirtualnych uruchomionych w sieci wirtualnej. Każda NVA musi skonfigurować dwie identyczne sesje BGP (na przykład używając tego samego numeru AS, tej samej ścieżki AS i anonsując ten sam zestaw tras) do dwóch równorzędnych adresów IP BGP, aby maszyny wirtualne w sieci wirtualnej mogły uzyskać spójne informacje o routingu z Azure Route Server.
Jeśli masz co najmniej dwa wystąpienia NVA, możesz ogłaszać różne ścieżki AS dla tej samej trasy z różnych wystąpień NVA, jeśli chcesz wyznaczyć jedno wystąpienie NVA jako aktywne, a drugie jako pasywne.
Jeśli maszyna wirtualna znajduje się w innej sieci wirtualnej niż ta, która hostuje urządzenie NVA i serwer tras:
Sprawdź, czy komunikacja równorzędna sieci wirtualnych jest włączona między dwiema sieciami wirtualnymi i czy opcja Użyj serwera routingu zdalnego jest włączona w sieci wirtualnej maszyny wirtualnej.
Dlaczego funkcja równokosztowej multiścieżki (ECMP) ExpressRoute jest wyłączona po wdrożeniu Route Server w sieci wirtualnej?
Gdy anonsujesz te same trasy z sieci lokalnej do platformy Azure za pośrednictwem wielu połączeń usługi ExpressRoute, zwykle usługa ECMP jest domyślnie włączona dla ruchu przeznaczonego dla tych tras z platformy Azure z powrotem do sieci lokalnej. Obecnie podczas wdrażania serwera Route Server informacje o wielu ścieżkach są tracone w ramach wymiany BGP między usługą ExpressRoute i serwerem Route Server, a w związku z tym ruch z platformy Azure przechodzi tylko na jednym z połączeń usługi ExpressRoute.
Problemy operacyjne
Dlaczego widzę błąd dotyczący nieprawidłowego zakresu i autoryzacji do wykonywania operacji serwera Route Server?
Jeśli zostanie wyświetlony błąd w następującym formacie, upewnij się, że masz skonfigurowane następujące uprawnienia: Role i uprawnienia serwera routingu.
Format komunikatu o błędzie: "Klient o identyfikatorze {} obiektu nie ma autoryzacji do wykonania akcji {} w zakresie {} lub zakres jest nieprawidłowy. Jeśli dostępu udzielono niedawno, odśwież swoje poświadczenia”.
Następny krok
Aby dowiedzieć się, jak utworzyć i skonfigurować usługę Azure Route Server, zobacz: