Zdefiniuj, jaką ramkę powinien otrzymać każdy brzeg klienta, zanim dotkniesz pseudowire. W prostym przypadku CE A wysyła jeden tag wyznaczający granicę usługi, a CE B oczekuje ramek bez tagu, i to brzeg dostawcy jest miejscem, w którym ta różnica jest rozstrzygana. Tag jest polityką lokalną, a nie częścią kontraktu Ethernet klienta, a pseudowire przenosi uzgodnioną ramkę, a nie oryginalną. Zapisz oba kierunki przed jakąkolwiek konfiguracją.

Najpierw zapisz kontrakt ramki

Kierunek w przód usuwa tag, a kierunek powrotny dodaje go z powrotem. Jeśli zapiszesz tylko jeden z nich, przetestujesz działającą ścieżkę w jednym kierunku i uznasz obwód za sprawny.

Trzymaj kontrakt na tyle krótki, aby wkleić go do zgłoszenia zmiany: który brzeg wysyła z tagiem, który oczekuje bez tagu i która wartość tagu wyznacza granicę usługi.

Uzgodnij tryb pseudowire

RFC 4448 rozróżnia tryby pseudowire raw i tagged i opisuje, jak traktowane są tagi wyznaczające granicę usługi. Tryb raw nadal może przenosić tagi należące do ramki klienta, więc rozróżnienie dotyczy roli usługowej tagu, a nie samej obecności nagłówka 802.1Q. Odczytanie trybu jako tagged kontra untagged to najczęstszy sposób błędnego określenia zakresu tej pracy. Uzgodnij tryb z pecrem, zanim zdecydujesz, których operacji potrzebujesz.

Następnie sprawdź rzeczywisty typ pseudowire i parametry peera. Lokalne przyłącze VLAN i zdalne przyłącze portu wymagają obsługiwanego uzgodnienia interworking, a dwie lokalne instrukcje przepisywania nie dowodzą, że ogłoszone typy obwodów są zgodne.

Jeśli oczekiwania dotyczące control word i MTU się różnią, masz problem negocjacji, którego żadne przepisanie nie naprawi. Potwierdź oba na podstawie bieżącej konfiguracji peera, a nie dokumentu projektowego.

Zastosuj lokalne operacje na tagach

przewodnik Juniper po przepisywaniu VLAN CCC dokumentuje operacje pop, push i swap z ograniczeniami specyficznymi dla platformy. Dla już skonfigurowanej zgodnej jednostki z tagiem kierunek ilustracyjny to input-vlan-map pop na wejściu i output-vlan-map push na wyjściu. Te wiersze ilustrują operacje, a nie kompletną konfigurację interfejsu lub obwodu. Potwierdź dokładną platformę i wydanie, zamiast stosować przykład jednej rodziny urządzeń wszędzie.

Obsługiwane ustawienia VLAN i enkapsulacji jednostki nadal muszą definiować zamierzony tag i klasyfikację. Instrukcja przepisywania na jednostce, która klasyfikuje niewłaściwe ramki, przenosi problem, zamiast go naprawiać.

Zachowaj wszelkie wewnętrzne tagi klienta wymagane przez usługę. W przypadku tagów piętrowych ustal, którym zewnętrznym tagiem manipulujesz, zanim cokolwiek usuniesz.

Zaplanuj rozmiar, nie tylko tagi

Uwzględnij zachowane tagi, rzeczywisty stos MPLS i control word w budżecie rozmiaru. RFC 8469 zaleca control word dla pseudowire Ethernet, a to zalecenie zmienia budżet ramki niezależnie od tego, czy Twoja platforma włącza go domyślnie. Uzgodnij niezgodność MTU, zamiast wyciszać jej ostrzeżenie jako naprawę. Wyciszone ostrzeżenie to zaplanowana awaria z zatartą datą.

Sprawdź ten sam budżet na obu brzegach dostawcy, ponieważ jedna strona dodająca tag i druga dodająca control word wystarczą, aby zepsuć ładunek, który wcześniej działał.

Jeśli liczby się nie zgadzają, zmień plan, a nie poziom logowania.

Odbieraj ramka po ramce

Przy odbiorze sprawdź oczekiwaną ramkę na każdym przyłączu klienta w obu kierunkach. Następnie wykonaj ruch aplikacji i sterowania, którego usługa naprawdę potrzebuje zgodnie z zatwierdzonym planem testów, ponieważ ping dowodzi znacznie mniej niż ramka z tagiem docierająca bez uszkodzeń. Zapisz kontrakt ramki dla wejścia i wyjścia razem z konfiguracją obwodu. To ten zapis sprawia, że następna zmiana jest weryfikowalna.

Trzymaj tryb, operacje na tagach, budżet MTU i wynik testu w jednym miejscu, ponieważ mają sens tylko razem. Rozdzielenie ich na trzy zgłoszenia gwarantuje, że następny inżynier odkryje to samo ograniczenie.

Obwód jest gotowy, gdy oba kierunki odpowiadają kontraktowi zapisanemu na początku, a nie gdy przechodzi pierwszy kierunek.

Powiązane artykuły