Contents
- Tunel GRE między dwoma routerami Cisco – od zera do działającego połączenia (podłączone PC)
- 2. Wstęp – co to jest tunel GRE i kiedy go uzywać
- 2. Topologia testowa i adresacja
- 2.1. Jak czytać podane adresy – wyjaśnienie od podstaw
- 3. Konfiguracja interfejsów fizycznych i PC
- 3.1. Router-A – adresy interfejsów
- 3.2. Router-B – adresy interfejsów
- 3.3. PC-A i PC-B
- 4. Konfiguracja tunelu GRE (Router A i B)
- 4.1. Router-A
- 4.2. Router-B
- 4.3. Weryfikacja tunelu
- 5. Routing statyczny do sieci lokalnych
- Weryfikacja tablic routingu
- 6. Weryfikacja połączenia – ping i traceroute z PC
- 6.1. Ping z PC-A do PC-B (przez tunel)
- 6.2. Dowód, że ruch rzeczywiście idzie przez tunel (na routerze)
- 7. MTU i clamp TCP MSS (kluczowa gotcha!)
- 8. (Opcjonalnie) OSPF przez tunel GRE
- 9. Diagnostyka najczęstszych problemów
- Komendy diagnostyczne w pigułce
- 10. Podsumowanie
Cisco GRE – tunel między dwoma routerami (z PC za każdym routerem)
Tunel GRE między dwoma routerami Cisco – od zera do działającego połączenia (podłączone PC)
W tym tutorialu krok po kroku zestawiamy tunel GRE (Generic Routing Encapsulation, warstwa 3) między dwoma routerami Cisco (IOS 15 / IOS-XE 16+. GNS3 lub fizycznie). Do drugiego interfejsu każdego routera (GigabitEthernet0/1) podpinamy PC, tak aby komputery w dwóch oddzielnych sieciach lokalnych komunikowały się ze sobą przez tunel, jakby były w jednej sieci.
GRE to prosty, tunelowany protokół działający w warstwie 3 (IP protocol 47). Enkapsułuje dowolny ruch IP (oraz multicast/broadcast IP – dlatego można przez niego prowadzić routing dynamiczny, np. OSPF) i przesyła go po „nagiej” sieci pomiędzy fizycznymi interfejsami routerów.
2. Wstęp – co to jest tunel GRE i kiedy go uzywać
GRE (RFC 2784, wcześniej opisany w RFC 1701) tworzy wirtualny interfejs tunnel, który zachowuje się jak punkt-punkt (point-to-point). Pakiety IP wchodzące do tunelu są opakowywane w nagłówek GRE + zewnętrzny nagłówek IP i wysyłane po fizycznej sieci transportowej do zdalnego końca tunelu, gdzie są rozpakowywane.
| Cecha | GRE (tunel warstwy 3) |
|---|---|
| Warstwa działania | L3 (przenosi głównie IP, ale też multicast/broadcast IP) |
| Protokół transportowy | IP protocol 47 (nie TCP, nie UDP) |
| Nagłówek GRE | 4+ bajty (opcje do 4 bajtów), potem zewnętrzny nagłówek IP (20 B) |
| Nadaje się do | routingu L3, protokołów dynamicznych (OSPF, EIGRP, BGP), failover |
| Nie nadaje się do | przenoszenia ramek Ethernet L2 (do tego EoIP/L2TPv3/VXLAN) |
| Szyfrowanie | brak wbudowanego – do zabezpieczenia używamy GRE over IPsec (patrz 9) |
Kiedy używać GRE: potrzebujesz łączyć L3 sieci lokalne przez dowolną sieć transportową (Internet, WAN, MPLS), chcesz uruchomić routing dynamiczny między routerami (GRE przenosi multicast OSPF – zwykły static route lub IPIP nie), albo chcesz wprowadzić politykę routingu (np. ruch z sieci lokalnej kierowany per-tunel).
Uwaga – model transport + payload: GRE rozdziela „nagą” sieć transportową (underlay, np.
192.168.12.0/30 między routerami) od wirtualnej sieci tunelu (overlay, np. 10.10.10.0/30). Adresy overlay NIE są widoczne poza tunelem – nie wolno ich ogłaszać w sieci fizycznej bez własnego tunelu.2. Topologia testowa i adresacja
Łączymy dwa routery (np. Cisco IOSv w GNS3 lub 2 Cisco 2911/4321). Za każdym routerem drugi port to podpięty PC (adres statyczny). Do testów używamy ping i traceroute.
Tabela adresacji – wszystko statycznie, zero DHCP, dla przejrzystości:
| Urządzenie | Interfejs | Adres / maska | Uwagi |
|---|---|---|---|
| Router–A (IOSv/GNS3) | GigabitEthernet0/0 | 192.168.12.1 / 30 | fizyczny link do Routera-B |
| GigabitEthernet0/1 | 10.0.0.1 / 24 | sieć lokalna A (PC-A) | |
| Tunnel0 | 10.10.10.1 / 30 | tunel GRE (overlay) | |
| Router–B (IOSv/GNS3) | GigabitEthernet0/0 | 192.168.12.2 / 30 | fizyczny link do Routera-A |
| GigabitEthernet0/1 | 20.0.0.1 / 24 | sieć lokalna B (PC-B) | |
| Tunnel0 | 10.10.10.2 / 30 | tunel GRE (overlay) | |
| PC-A | eth0 | 10.0.0.10/24, brama 10.0.0.1 | za Routerem-A (gi0/1) |
| PC-B | eth0 | 20.0.0.10/24, brama 20.0.0.1 | za Routerem-B (gi0/1) |
Adresowanie w pigułce: transport (underlay): 192.168.12.1 — 192.168.12.2 /30 tunel (overlay) : 10.10.10.1 — 10.10.10.2 /30 LAN-A : 10.0.0.0/24 (PC-A 10.0.0.10) LAN-B : 20.0.0.0/24 (PC-B 20.0.0.10)
Dlaczego /30 na tunelu? Tunel GRE jest łączem punkt-punkt, więc /30 (2 adresy hostów) w pełni wystarcza. Można też użyć /31 (RFC 3021) na nowszych IOS, ale /30 jest uniwersalne.
2.1. Jak czytać podane adresy – wyjaśnienie od podstaw
W tej konfiguracji są cztery osobne sieci IP, jak cztery osobne numeracje na czterech różnych „kablach”. Każda ma swój zakres adresów i każda służy do czegoś innego:
| Nazwa sieci | Zakres | Adresy w naszej topologii | Do czego służy | Kto jej używa |
|---|---|---|---|---|
| Underlay (transport) |
192.168.12.0/30 | 192.168.12.1 – Router-A (gi0/0) 192.168.12.2 – Router-B (gi0/0) |
fizyczny kabel łączący routery; po nim lecą pakiety zapakowane w GRE | tylko oba routery |
| Overlay (tunel) |
10.10.10.0/30 | 10.10.10.1 – Router-A (Tunnel0) 10.10.10.2 – Router-B (Tunnel0) |
wirtualne łącze punkt-punkt wewnątrz tunelu GRE | tylko oba routery |
| LAN-A | 10.0.0.0/24 | 10.0.0.1 – brama (Router-A, gi0/1) 10.0.0.10 – PC-A |
sieć lokalna za Routerem-A | Router-A i PC-A |
| LAN-B | 20.0.0.0/24 | 20.0.0.1 – brama (Router-B, gi0/1) 20.0.0.10 – PC-B |
sieć lokalna za Routerem-B | Router-B i PC-B |
Co znaczy „/30″ i „/24″? To maska podsieci, czyli informacja, ile urządzeń zmieści się w danej sieci.
/24 daje 254 wolne adresy dla urządzeń (u nas są tylko 2 – PC i router). /30 daje dokładnie 2 adresy – tyle, ile potrzebuje łącze „jeden router do jednego routera” (po jednym adresie na każdym końcu). Dlatego /30 idealnie pasuje do underlay i do tunelu GRE.Co robi każdy z tych adresów w praktyce:
192.168.12.1i192.168.12.2– adresy „kablowe” routerów (porty gi0/0). To po nich pakiety faktycznie płyną po fizycznym kablu. Używasz ich tylko w komendachtunnel source(skąd) itunnel destination(dokąd).10.10.10.1i10.10.10.2– adresy „wirtualnych końców” tunelu (Tunnel0). One istnieją tylko wewnątrz tunelu GRE i służą do trasowania pakietów, które już weszły do tunelu.10.0.0.1i20.0.0.1– bramy domyślne komputerów. PC wysyła do bramy wszystko, co nie należy do jego lokalnej sieci.10.0.0.10i20.0.0.10– adresy samych komputerów. To między nimi ostatecznie musi zostać dostarczony pakiet.
Jak pakiet pokonuje całą drogę (PC-A → PC-B): PC-A widzi, że
20.0.0.10 nie jest w jego sieci 10.0.0.0/24, więc wysyła pakiet do bramy 10.0.0.1 (Router-A). Router-A wie, że za tunelem jest sieć 20.0.0.0/24, więc opakowuje pakiet w GRE i wysyła go po kablu do 192.168.12.2 (Router-B). Router-B rozpakowuje pakiet z tunelu i doręcza go do 20.0.0.10 (PC-B). W drugą stronę działa to lustrzanie.Zapamiętaj: PC nigdy nie „widzi” ani adresów 192.168.x, ani 10.10.10.x. Dla PC-A cały świat za bramą 10.0.0.1 jest niewidoczny – łączność załatwiają routery i tunel GRE.
3. Konfiguracja interfejsów fizycznych i PC
3.1. Router-A – adresy interfejsów
! wejście do trybu uprzywilejowanego i konfiguracji Router> enable Router# configure terminal Router(config)# hostname Router-A Router-A(config)# ! fizyczny link do Routera-B (underlay) Router-A(config)# interface GigabitEthernet0/0 Router-A(config-if)# ip address 192.168.12.1 255.255.255.252 Router-A(config-if)# no shutdown ! sieć lokalna A – tutaj PC-A Router-A(config-if)# interface GigabitEthernet0/1 Router-A(config-if)# ip address 10.0.0.1 255.255.255.0 Router-A(config-if)# no shutdown Router-A(config-if)# exit Router-A(config)#
3.2. Router-B – adresy interfejsów
! analogicznie na Routerze-B Router> enable Router# configure terminal Router(config)# hostname Router-B Router-B(config)# ! fizyczny link do Routera-A (underlay) Router-B(config)# interface GigabitEthernet0/0 Router-B(config-if)# ip address 192.168.12.2 255.255.255.252 Router-B(config-if)# no shutdown ! sieć lokalna B – tutaj PC-B Router-B(config-if)# interface GigabitEthernet0/1 Router-B(config-if)# ip address 20.0.0.1 255.255.255.0 Router-B(config-if)# no shutdown Router-B(config-if)# exit Router-B(config)#
3.3. PC-A i PC-B
Na obu komputerach ustawiamy statycznie adres. Przykład (Windows 10/11):
# PC-A PS C:\> netsh interface ip set address name="Ethernet" static 10.0.0.10 255.255.255.0 10.0.0.1 PS C:\> ping 10.0.0.1 Odpowiedź z 10.0.0.1: bajtów=32 czas=1ms TTL=255 # PC-B PS C:\> netsh interface ip set address name="Ethernet" static 20.0.0.10 255.255.255.0 20.0.0.1 PS C:\> ping 20.0.0.1 Odpowiedź z 20.0.0.1: bajtów=32 czas=1ms TTL=255
W GNS3/Cisco IOSv PC najprościej zastąpić routerem z wyłączonym routingiem (no ip routing) lub maszyną wirtualną – zasada jest ta sama: adres + brama. Na tym etapie PC-A powinien osiągnąć tylko bramę 10.0.0.1, a PC-B – 20.0.0.1. Sieci są jeszcze izolowane – nie mają do siebie trasy.
Stan po kroku 3: łączność fizyczna między R-A a R-B działa (ustaw
ping 192.168.12.2 source 192.168.12.1 na Routerze-A). PC pingują tylko swoje bramy. Czas na tunel GRE.4. Konfiguracja tunelu GRE (Router A i B)
4.1. Router-A
Router-A(config)# interface Tunnel0 Router-A(config-if)# ip address 10.10.10.1 255.255.255.252 Router-A(config-if)# ip mtu 1476 ! źródło tunelu = interfejs, na którym siedzi adres sieci gołej (underlay) Router-A(config-if)# tunnel source GigabitEthernet0/0 ! cel tunelu = adres IP zdalnego końca (zawsze adres underlay, nie overlay) Router-A(config-if)# tunnel destination 192.168.12.2 ! tryb domyślny, można pominąć (i tak jest ustawiany) Router-A(config-if)# tunnel mode gre ip ! keepalive GRE (10 s / 3 próby) – wykryje przerwę w tunelu Router-A(config-if)# keepalive 10 3 Router-A(config-if)# exit Router-A(config)#
4.2. Router-B
Router-B(config)# interface Tunnel0 Router-B(config-if)# ip address 10.10.10.2 255.255.255.252 Router-B(config-if)# ip mtu 1476 ! źródło i cel – lustrzanie do Routera-A Router-B(config-if)# tunnel source GigabitEthernet0/0 Router-B(config-if)# tunnel destination 192.168.12.1 Router-B(config-if)# tunnel mode gre ip Router-B(config-if)# keepalive 10 3 Router-B(config-if)# exit Router-B(config)#
Gotcha:
tunnel source/tunnel destination działają w twojej „nagiej” sieci (underlay). Cel tunelu (192.168.12.x) MUSI być osiągalny w trasowaniu na obu końcach, a interfejs źródłowy MUSI być up. Jeśli użyjesz adresu overlay jako destination, tunel nigdy nie wstanie.4.3. Weryfikacja tunelu
Router-A# show ip interface brief | include Tunnel|GigabitEthernet Interface IP-Address OK? Method Status Protocol GigabitEthernet0/0 192.168.12.1 YES manual up up GigabitEthernet0/1 10.0.0.1 YES manual up up Tunnel0 10.10.10.1 YES manual up up Router-A# show interfaces tunnel 0 Tunnel0 is up, line protocol is up Hardware is Tunnel Internet address is 10.10.10.1/30 MTU 1476 bytes, BW 100 Kbit/sec, DLY 50000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive set (10 sec), retries 3 Tunnel source 192.168.12.1 (GigabitEthernet0/0), destination 192.168.12.2 Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled Checksumming of packets disabled, fast tunneling enabled 5 packets input, 0 bytes, 0 no buffer 5 packets output, 0 bytes, 1 underruns Router-A# ping 10.10.10.2 source 10.10.10.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.10.10.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms
!!! odpowiada: tunel GRE działa end-to-end w warstwie IP. Jeżeli stoi „Tunnel0 is up, line protocol is down” – patrz rozdział 9 (Diagnostyka).
5. Routing statyczny do sieci lokalnych
Tunel stoi, ale routery nie wiedzą jeszcze, jak dotrzeć do zdalnej sieci lokalnej. Dodajemy trasy statyczne przez interfejs tunelu (next-hop = zdalny koniec overlay):
! Router-A: jak dotrzeć do LAN-B (20.0.0.0/24)? Przez tunel, next-hop 10.10.10.2 Router-A(config)# ip route 20.0.0.0 255.255.255.0 10.10.10.2 Router-A(config)# end ! Router-B: jak dotrzeć do LAN-A (10.0.0.0/24)? Przez tunel, next-hop 10.10.10.1 Router-B(config)# ip route 10.0.0.0 255.255.255.0 10.10.10.1 Router-B(config)# end
Różne sposoby zapisu trasy:
ip route 20.0.0.0 255.255.255.0 10.10.10.2 (przez next-hop) lub ip route 20.0.0.0 255.255.255.0 Tunnel0 (przez łącze). Przy /30 obie działają; zapis przez next-hop jest czytelniejszy, a przy tunelach o wielu sieciach – bardziej przewidywalny.Weryfikacja tablic routingu
Router-A# show ip route Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks C 10.0.0.0/24 is directly connected, GigabitEthernet0/1 L 10.0.0.1/32 is directly connected, GigabitEthernet0/1 C 10.10.10.0/30 is directly connected, Tunnel0 L 10.10.10.1/32 is directly connected, Tunnel0 20.0.0.0/24 [1/0] via 10.10.10.2 S 20.0.0.0/24 [1/0] via 10.10.10.2 192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.12.0/30 is directly connected, GigabitEthernet0/0 L 192.168.12.1/32 is directly connected, GigabitEthernet0/0
Uwaga na
ip route 20.0.0.0 ... 10.10.10.2! Trasa jest w tablicy jako S (static). Gdyby tunel wstał z show ip interface brief na „up/up”, ale trasa nie działała – sprawdź, czy nie masz po drodze blokad (ACL/firewall) i czy keepalive tunelu przeszło (rozdział 9).6. Weryfikacja połączenia – ping i traceroute z PC
6.1. Ping z PC-A do PC-B (przez tunel)
PS C:\> ping 20.0.0.10 Pingowanie 20.0.0.10 z 32 bajtami danych: Odpowiedź z 20.0.0.10: bajtów=32 czas=2ms TTL=62 Odpowiedź z 20.0.0.10: bajtów=32 czas=2ms TTL=62 Odpowiedź z 20.0.0.10: bajtów=32 czas=2ms TTL=62 Odpowiedź z 20.0.0.10: bajtów=32 czas=2ms TTL=62 Statystyka pingowania dla 20.0.0.10: Pakiety: wysłane = 4, odebrane = 4, utracone = 0 (0% straty), Przybliżony czas podróży w milisekundach: Minimalny = 1ms, maksymalny = 2ms, średni = 1ms # traceroute pokazuje drogę przez tunel (overlay): brama LAN-A -> tun0 -> PC-B PS C:\> tracert -d 20.0.0.10 Śledzenie trasy do 20.0.0.10 na maksymalnie 30 przeskoków: 1 <1 ms <1 ms <1 ms 10.0.0.1 2 1 ms 1 ms 1 ms 10.10.10.2 3 1 ms 1 ms 1 ms 20.0.0.10 Ukończono śledzenie trasy.
Pierwszy przeskok to brama LAN-A (10.0.0.1, Router-A), drugi – zdalny koniec tunelu 10.10.10.2 (Router-B wysyła pakiet ICMP o przekroczonym TTL z interfejsu przychodzącego), trzeci – już sam PC-B. Adres 192.168.12.x nigdy nie pojawia się w śladzie, bo dla PC cała sieć fizyczna jest niewidoczna – to jest właśnie sens overlay.
6.2. Dowód, że ruch rzeczywiście idzie przez tunel (na routerze)
Router-A# show arp | include 10.10.10|192.168.12 Internet Address Physical Address Type 192.168.12.2 0050.7966.45bb ARPA (sasiad w underlay) ! licznik pakietów GRE (protokół 47) na interfejsie fizycznym: Router-A# show interfaces GigabitEthernet0/0 | include packets input|packets output 1234 packets input, 98674 bytes, 0 no buffer 1256 packets output, 100567 bytes, 0 underruns ! a tutaj ruch w overlay (przez tunel): Router-A# show interfaces tunnel 0 | include packets input|packets output 1234 packets input, 98794 bytes, 0 no buffer 1255 packets output, 100212 bytes, 0 underruns ! szybkie sprawdzenie bieżącego ruchu: Router-A# debug ip icmp Router-A# ping 20.0.0.10 repeat 1 *Jun 12 04:05:07.701: ICMP: echo reply sent, src 10.0.0.1, dst 20.0.0.10 ! – poszło z gi0/1 (src 10.0.0.1) do 20.0.0.10
BRAWO – routing przez GRE działa. PC-A i PC-B komunikują się przez tunel GRE, choć z punktu widzenia maszyn fizyczna sieć między routerami jest niewidoczna – całe łącze transportowe zostaje ukryte.
7. MTU i clamp TCP MSS (kluczowa gotcha!)
Typowy problem: „ping mały działa, duży nie” / strony ładują się, pobieranie staje. GRE dokłada nagłówek GRE (4–8 B) + zewnętrzny IP (20 B) = 24 bajty > MTU. Jeśli fizyczny MTU to 1500, efektywny MTU tunelu to 1476. Strony TCP wysyłają segmenty po ~1460 B, co po zapakowaniu przekracza 1500 i zostaje odrzucone/pofragmentowane.
Rozwiązania (na Routerze-A i Routerze-B):
! 1) mniejsze MTU na tunelu (patrz część 4 – ip mtu 1476 już ustawione) Router-A(config)# interface Tunnel0 Router-A(config-if)# ip mtu 1476 ! 2) clamp MSS dla TCP – ustawia max segment size w SYN na wejściu obu interfejsów fizycznych Router-A(config-if)# interface GigabitEthernet0/1 Router-A(config-if)# ip tcp adjust-mss 1360 Router-A(config-if)# exit ! analogicznie na Routerze-B: Router-B(config)# interface GigabitEthernet0/1 Router-B(config-if)# ip tcp adjust-mss 1360 Router-B(config-if)# exit
Dlaczego 1360, a nie 1476? 1476 to MTU tunelu (1500–24). MSS = MTU – 40 (nakładka TCP+IP) = 1436. Wartość 1360 zostawia margines na NAT/PPPoE/IPsec z boku i jest częstym, bezpiecznym wyborem Cisco w dokumentacji GRE-over-IPsec. Dla czystego GRE wystarczy 1436; 1360 zawsze zadziała.
Weryfikacja MTU:
# ping z opcją "don't fragment" i rosnącym rozmiarem pakietu C:\> ping -f -l 1472 20.0.0.10 Odpowiedź z 20.0.0.10: bajtów=1472 czas=2ms TTL=62 <-- OK, 1472+28=1500 C:\> ping -f -l 1473 20.0.0.10 Pakiet musi być pofragmentowany, ale został ustawiony flag DF. <-- MTU przeciazone # na routerze: Router-A# ping 20.0.0.10 size 1472 df-bit !!!!! (gratulacje - MTU 1500 przechodzi bez fragmentacji) Router-A# ping 20.0.0.10 size 1490 df-bit ..... Success rate is 0 percent (0/5) <-- efekt braku clampów? Sprawdź MSS!
8. (Opcjonalnie) OSPF przez tunel GRE
GRE przenosi pakiety multicast (np. adres 224.0.0.5 dla OSPF hello). Dzięki temu routery mogą tworzyć sąsiedztwo OSPF przez tunel i automatycznie wymieniać trasy do obu sieci lokalnych – bez tras statycznych z rozdziału 5.
! Router-A: usuwa trasy statyczne i uruchamia OSPF na interfejsach Router-A(config)# no ip route 20.0.0.0 255.255.255.0 10.10.10.2 Router-A(config)# router ospf 1 Router-A(config-router)# network 10.0.0.1 0.0.0.0 area 0 Router-A(config-router)# network 10.10.10.1 0.0.0.0 area 0 Router-A(config-router)# exit ! Router-B Router-B(config)# no ip route 10.0.0.0 255.255.255.0 10.10.10.1 Router-B(config)# router ospf 1 Router-B(config-router)# network 20.0.0.1 0.0.0.0 area 0 Router-B(config-router)# network 10.10.10.1 0.0.0.0 area 0 Router-B(config-router)# exit ! weryfikacja sąsiedztwa i tras Router-A# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 192.168.12.2 1 FULL/DR 00:00:36 10.10.10.2 Tunnel0 Router-A# show ip route ospf 20.0.0.0/24 [110/1001] via 10.10.10.2, Tunnel0
Błąd częsty: sieć
192.168.12.0/30 (underlay) NIE powinna być w OSPF w strefie overlay – jest to ruch transportowy i nie musimy go ogłaszać jako OSPF między tunelami (można, ale to zaciemnia). Ogłasza się tylko sieci lokalne + sieć tunelu.9. Diagnostyka najczęstszych problemów
| Symptom | Przyczyna / sprawdzenie | Rozwiązanie |
|---|---|---|
Tunnel0 is up, line protocol is down |
keepalive nie wraca od zdalnego końca (złe źródło / źle ustawione destination, ACL blokuje 47, drugi router wyłączony) | show interfaces tunnel 0 – sprawdź tunnel source/destination; ping 192.168.12.2 source 192.168.12.1; upewnij się, że cel to adres underlay, nie overlay |
Tunnel0 is administratively down |
shutdown na tunelu |
no shutdown na interfejsie Tunnel0 |
| Ping z PC do PC nie działa, choć tunel „up/up” | brak tras statycznych do sieci lokalnych zdalnego końca | show ip route – sprawdź trasę S 20.0.0.0/24 via 10.10.10.2 po obu stronach; dodaj ip route |
| Ping „mały” działa, „duży” nie (strony WWW zawieszają się) | MTU/MSS: GRE dodaje 24 B, TCP wysyła zbyt duże segmenty (rozdz. 7) | ip mtu 1476 na tunelu + ip tcp adjust-mss 1360 na interfejsach w stronę PC/LAN |
| PC nie ma bramy / nie widzi routera lokalnie | zły adres/maska/brama na PC albo no shutdown zapomniane na gi0/1 |
show ip interface brief – gi0/1 musi być up/up; popraw adresację (rozdz. 2–3) |
| OSPF nie tworzy sąsiedztwa | brak multicast (ACL na 224.0.0.5/6), tryb tunelu nie-multicast, źle zadeklarowane sieci | show ip ospf interface Tunnel0; sprawdź tunnel mode gre ip (multicast) i network 10.10.10.x area 0 |
| Podejrzenie ACL blokującej GRE | protokół 47 w ACL na torze (firewall) | tymczasowo debug ip packet 47 lub show access-lists liczniki; dodaj permit gre host 192.168.12.1 host 192.168.12.2 |
Komendy diagnostyczne w pigułce
show ip interface brief ! status wszystkich interfejsów show interfaces tunnel 0 ! szczegóły tunelu: source/dest, MTU, keepalive, liczniki show ip route ! tablica routingu (trasy C/S/O) show ip ospf neighbor ! sąsiedzi OSPF (gdy używasz rozdz. 8) ping 192.168.12.2 source 192.168.12.1 ! underlay działa? ping 10.10.10.2 source 10.10.10.1 ! overlay działa? debug tunnel ! włączenie podglądu pakietów tunelu (ostrożnie – log) debug ip icmp ! potwierdzenie odpowiedzi ICMP term monitor ! wyświetlanie komunikatów debug na konsoli
Keepalive GRE a „cisze”: domyślnie GRE nie ma żadnego keepalive – jeśli zdalny router zniknie, tunel zostaje „up/up” i ruch trafia w próżnię.
keepalive 10 3 (rozdz. 4) wysyła test pary co 10 s i po 3 nieodebranych oznacza tunel jako down – trasa statyczna automatycznie znika z tablicy. Konfiguruj to na OBU stronach.10. Podsumowanie
Z łączem GRE między dwoma routerami Cisco (z PC za każdym routerem) mamy:
- Adresy fizyczne obu routerów (underlay) – rozdział 3.
- Wirtualny tunel GRE
tunnel0z adresami overlay 10.10.10.1/30 i 10.10.10.2/30 – rozdział 4. - Trasy statyczne do LAN:
ip route 20.0.0.0/24 via 10.10.10.2i odwrotnie (albo OSPF przez tunel – rozdział 8). - Zweryfikowany ping/traceroute PC-A ↔ PC-B przez tunel – rozdział 6.
- Poprawny MTU (1476) i clamp MSS (1360), by nie zawieszać TCP – rozdział 7.
Test: ping z PC-A do PC-B = ciągłe !!!!! i wszystkie ścieżki w traceroute przez 10.10.10.2. Tunel GRE działa.
Źródła: dokumentacja Cisco IOS „Configuring GRE Tunnels”, RFC 2784 (Generic Routing Encapsulation), RFC 1701, know-how GNS3/IPv4lab.
