ALU Interop tunel GRE

Próbowałem wymyślić, jak skonfigurować tunel GRE między ALU 7750SR a zewnętrznym sprzedawcą. Myślę, że to przeszkadza w VC-ID w SDP, ale mam nadzieję, że ktoś ma doświadczenie w uzyskiwaniu tunelu GRE w środowisku wielu dostawców z ALU.

Oto żądana składnia:

sdp 9999 create
far-end 1.1.1.1 
path-mtu 1500 
keep-alive 
exit

ies 9998 customer 1 create 
 interface "PACKET_DESIGN" create 
 address 10.128.105.6/30 
 spoke-sdp 9999:1 create 
 no shutdown 
 exit 
no shutdown

gre alcatel-lucent-7750 Błoto
źródło

Czy możesz podać trochę więcej informacji? Czego próbowałeś, dlaczego według Ciebie VC-ID może być przyczyną, którą sprzedawca zewnętrzny, ...

Gerben

Jaka jest konfiguracja sieci? Czy to przechodzi przez zaporę ogniową, czy też jest skonfigurowana na zaporze ogniowej? Czy w przypadku zapory zezwalasz na ruch portów GRE i TCP? Podaj taki schemat sieci: LAN1 => Firewall1 == GRE Tunnel == Firewall2 <= LAN2

Bulki

Czy możesz opublikować przykład konfiguracji, aby podać kontekst?

jwbensley

@javano Dodałem składnię do głównego postu.

Błoto

@Bulki W grę nie wchodzą zapory ogniowe. Próbuję to zrobić, aby tunelować sąsiedztwo ISIS L1 z serwerem Route Explorer / Packet Design, ale dla wszystkich celów i celów możesz sobie wyobrazić, że próbuję zrobić tunel do routera Cisco (ponieważ mogę uzyskać tunel GRE pracować z Cisco do projektowania pakietów bez specjalnej składni po stronie Cisco). Schemat sieci jest tak prosty, jak się wydaje: LAN1 - tunel GRE - LAN2. Standardowy rdzeń MPLS, nie ma TE, ponieważ SDP jest ustawiany jako GRE.

Błoto

Odpowiedzi:

Obsługa AFAIK GRE jest ograniczona do usług VPN lub jako pseudołącze dostępu. Przynajmniej według ALU nie ma możliwości wykorzystania GRE jako logicznego tunelu po stronie „sieci”. Wymagałoby to bloku serwisowego. Jednak nie testowałem tego, ale wydaje się, że jest to oficjalna historia.

aakso
źródło

Podczas gry zdecydowanie byłem w stanie sprawić, że tunele GRE będą działać po stronie ALU do ALU po stronie sieci, a przylegają do nich ISIS. To kiedy ALU do czegokolwiek innego nie działa. Jestem pewien, że problem polega na tym, że etykieta SVC-ID trafia na urządzenie nie-ALU (i urządzenie nie-ALU nie odsyła go z powrotem do ALU), ale nie mogę znaleźć sposobu, aby to naprawić. Wydaje się po prostu zadziwiające, że nie ma łatwego sposobu na przekazanie standardowego tunelu GRE RFC w ALU innemu dostawcy.

Błoto

Twoja konfiguracja wymaga sygnalizacji tldp, ponieważ jest domyślnie włączona. Można go wyłączyć „wyłączając sygnalizację”. Testowałem tę konfigurację - jednak nadal wydaje się, że użycie „speak-sdp” w kontekście IES / VPRN wywołuje etykietę usługi do użycia w płaszczyźnie danych. Muszę to jednak zweryfikować za pomocą przechwytywania pakietów. „Prawdziwy” interfejs tunelowy wymaga ostrza MS-ISA. Następnie możesz pozdrowić logiczne sapsy tunelowe, które mają miejsce docelowe GRE.

aakso

Próbowałem już tego wcześniej. Pozwól, że pokażę ci, co zrobiłeś.

Najpierw stworzyłem SDP jako GRE.

far-end 10.1.0.6
signaling off
keep-alive
 shutdown
exit
no shutdown

Następnie utwórz usługę IES. Teraz, podczas tworzenia szprychy-spd i gdy sygnalizacja jest wyłączona (ponieważ używasz GRE), musisz ręcznie ustalić etykiety wejściowe i wyjściowe vc.

ies 100 customer 1 create
 interface "to_SARA_2" create
  address 192.168.0.1/30
  spoke-sdp 12:100 create
   ingress
    vc-label 2048
   exit
   egress
    vc-label 2048
   exit
  exit
 exit
 no shutdown
exit

Ta ostatnia rzecz ma sens i możesz następnie przekazywać ruch za pomocą GRE zamiast MPLS ...

Lucas
źródło

Często musisz ustawić MTU na 1440 lub mniej z pamięci, aby umożliwić przejście nagłówka GRE do drugiej strony> bardzo przydatne i łatwe do zrozumienia (nie jest to 100-stronicowy oficjalny dokument)

Obliczanie trybu tunelu GRE IPSec narzut z punktu do punktu GRE IPSEC

Powiedziałbym, że zapoznaj się z tym artykułem, aby uzyskać więcej informacji: ustawiłem jeden z 2 ciscos - po prostu usuwam elementy IPSec z konfiguracji, ale jak powiedziałem> obniż MTU po obu stronach, aby dopasować (i powinieneś naprawdę implement IPSEC)

alex_da_gr8
źródło

Interfejs MTU typu end-to-end jest standaryzowany na 9212 (liczba ta obejmuje narzut L2). Używanie polecenia „path-mtu” było bardziej „Zdrowaś Mario”, kiedy próbowałem to zrobić. W przypadku rzutów zmodyfikowałem instrukcję path-mtu do 1400, 1300, 1200 i 1100 i pozostała ona operacyjna w dół. Twój link nie uwzględnia różnicy w dostawie między ALU a Cisco, a konfiguracja tunelu GRE między dwoma Cisco nie jest problemem. Również IPSEC nie jest potrzebny, ponieważ ten tunel nie opuszcza własnego AS.

Błoto