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.

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:

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:

Co robi każdy z tych adresów w praktyce:

• 192.168.12.1 i 192.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 komendach tunnel source (skąd) i tunnel destination (dokąd).
• 10.10.10.1 i 10.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.1 i 20.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.10 i 20.0.0.10 – adresy samych komputerów. To między nimi ostatecznie musi zostać dostarczony pakiet.

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.

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)#

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

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

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

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

7. MTU i clamp TCP MSS (kluczowa gotcha!)

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

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

9. Diagnostyka najczęstszych problemów

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

10. Podsumowanie

Z łączem GRE między dwoma routerami Cisco (z PC za każdym routerem) mamy:

1. Adresy fizyczne obu routerów (underlay) – rozdział 3.
2. Wirtualny tunel GRE tunnel0 z adresami overlay 10.10.10.1/30 i 10.10.10.2/30 – rozdział 4.
3. Trasy statyczne do LAN: ip route 20.0.0.0/24 via 10.10.10.2 i odwrotnie (albo OSPF przez tunel – rozdział 8).
4. Zweryfikowany ping/traceroute PC-A ↔ PC-B przez tunel – rozdział 6.
5. Poprawny MTU (1476) i clamp MSS (1360), by nie zawieszać TCP – rozdział 7.

Źródła: dokumentacja Cisco IOS „Configuring GRE Tunnels”, RFC 2784 (Generic Routing Encapsulation), RFC 1701, know-how GNS3/IPv4lab.

1. Wstęp – protokoły tunelowe w RouterOS

RouterOS udostępnia trzy główne protokoły tunelowe do łączenia dwóch routerów przez sieć IP (transport):

• GRE(Generic Routing Encapsulation, RFC 2784) – tunel warstwy 3, przekazuje pakiety IP i IPv6
• IPIP(IP-in-IP, RFC 2003) – tunel warstwy 3, przekazuje tylko pakiety IPv4
• EoIP (Ethernet over IP) – tunel warstwy 2, oparty na RFC 1701 (GRE), przekazuje ramki Ethernet wraz z broadcastami, multicastami i całym ruchem L2. Protokół własnościowy MikroTik (działa między routerami RouterOS)

Ważne różnice w skrócie:

2. GRE vs EoIP – kiedy co wybrać

Kiedy używać GRE (warstwa 3)

• Potrzebujesz routingu między sieciami (site-to-site VPN na warstwie IP)
• Chcesz uruchomić dynamiczne protokoły routingu przez tunel – GRE przekazuje multicasty IP, których wymagają OSPF (224.0.0.5) i RIPv2 (224.0.0.9). Uwaga: BGP NIE używa multicastów (działa na TCP/unicast), więc dla samego BGP wystarczy dowolny tunel IP
• Jeden lub oba końce tunelu to routery nie-MikroTik (Cisco, Juniper, Linux) – GRE jest standardowym protokołem
• Zależy Ci na niskim overheadzie (24 bajty vs 42+ bajty w EoIP)
• Potrzebujesz keepalive do wykrywania przerw w połączeniu

Kiedy używać EoIP (warstwa 2)

• Potrzebujesz rozszerzyć sieć LAN między dwoma lokalizacjami (ten sam broadcast domain, ta sama podsieć)
• Potrzebujesz przekazywać broadcasty (np. DHCP, ARP)
• Potrzebujesz przekazywać ruch nie-IP (IPX, AppleTalk, legacy)
• Chcesz bridgować porty switcha między dwoma routerami jakby były połączone kablem
• Oba routery to MikroTik RouterOS (EoIP jest protokołem własnościowym MikroTik)
• Potrzebujesz przenosić VLANy między lokalizacjami (EoIP przekazuje ramki 802.1Q)

3. Topologia testowa i środowisko

W tym przewodniku konfigurujemy dwa routery MikroTik CHR (Cloud Hosted Router) z RouterOS w wersji 7.16.1 (stable) działające w środowisku wirtualnym (VirtualBox):

Środowisko testowe

Używamy dwóch routerów z dostępem przez SSH. Konfiguracja była weryfikowana na routerze A (192.168.53.83):

# Wersja RouterOS i sprzęt (Router A):
/system resource print


name: MikroTik
uptime: 3m32s
version: 7.16.1 (stable)
build-time: 2024-10-10 14:03:32
free-memory: 20.3MiB
total-memory: 64.0MiB
cpu: Intel(R)
cpu-count: 1
cpu-frequency: 2591MHz
cpu-load: 3%
free-hdd-space: 71.1MiB
total-hdd-space: 89.2MiB
architecture-name: x86_64
board-name: CHR innotek GmbH VirtualBox

# Interfejsy na routerze A:
/interface print

Flags: R - RUNNING
#   NAME    TYPE      ACTUAL-MTU  MAC-ADDRESS
0 R ether1  ether           1500  08:00:27:E8:30:07
1 R lo      loopback       65536  00:00:00:00:00:00

# Adres IP routera A:
/ip address print

  ADDRESS           NETWORK       INTERFACE
  192.168.53.83/24  192.168.53.0  ether1

4. Scenariusz 1: Tunel GRE (warstwa 3 – routing)

W tym scenariuszu tworzymy tunel GRE między dwoma routerami, który przekazuje pakiety IP. Tunel działa jak wirtualny kabel punkt-do-punkt. Przez tunel GRE można przekazywać multicasty IP (niezbędne dla OSPF/RIPv2), ale NIE można przekazywać broadcastów L2 (ARP, DHCP).

4.1. Tworzenie interfejsu GRE

Router A (192.168.53.83)

/interface gre add name=gre-tunnel-84 \
    remote-address=192.168.53.84 \
    local-address=192.168.53.83 \
    keepalive=10s,10 \
    comment="Tunel GRE do routera B"

Router B (192.168.53.84)

/interface gre add name=gre-tunnel-83 \
    remote-address=192.168.53.83 \
    local-address=192.168.53.84 \
    keepalive=10s,10 \
    comment="Tunel GRE do routera A"

Wyjaśnienie parametrów:

# Wynik po utworzeniu tunelu GRE na routerze A:
/interface gre print detail

Flags: X - disabled; R - running
0    name="gre-tunnel-84" mtu=auto actual-mtu=1476
     local-address=192.168.53.83
     remote-address=192.168.53.84
     keepalive=10s,10 dscp=inherit
     clamp-tcp-mss=yes dont-fragment=no allow-fast-path=yes

4.2. Adresowanie tunelu

Tunel GRE działa jak wirtualny interfejs punkt-do-punkt. Należy mu przypisać adresy IP z sieci punkt-do-punkt (najczęściej /30):

Router A (192.168.53.83)

/ip address add address=172.16.1.1/30 interface=gre-tunnel-84 \
    comment="Adres IP tunelu GRE - koniec A"

Router B (192.168.53.84)

/ip address add address=172.16.1.2/30 interface=gre-tunnel-83 \
    comment="Adres IP tunelu GRE - koniec B"

# Wynik na routerze A po dodaniu adresu IP:
/ip address print

  ADDRESS           NETWORK       INTERFACE
  192.168.53.83/24  192.168.53.0  ether1
  172.16.1.1/30     172.16.1.0    gre-tunnel-84

4.3. Trasy statyczne

Aby routery mogły przekazywać ruch między sieciami lokalnymi przez tunel, potrzebne są trasy statyczne wskazujące na koniec tunelu jako bramę:

Załóżmy, ze sieć lokalna routera A to 10.10.10.0/24, a sieć lokalna routera B to 10.20.20.0/24.

Router A (192.168.53.83)

# Trasa do sieci lokalnej routera B przez tunel GRE
/ip route add dst-address=10.20.20.0/24 gateway=172.16.1.2 \
    comment="Trasa do sieci B przez GRE"

Router B (192.168.53.84)

# Trasa do sieci lokalnej routera A przez tunel GRE
/ip route add dst-address=10.10.10.0/24 gateway=172.16.1.1 \
    comment="Trasa do sieci A przez GRE"

# Tabela routingu na routerze A:
/ip route print

Flags: D - DYNAMIC; I - INACTIVE, A - ACTIVE; c - CONNECT, s - STATIC; H - HW-OFFLOADED
#      DST-ADDRESS      GATEWAY        DISTANCE
  IsH 10.20.20.0/24    172.16.1.2            1     <--- trasa do sieci B (INACTIVE bo brak lacznosci z .84)
    DAc  10.10.10.0/24  lo                     0     <--- siec lokalna A
    DIcH 172.16.1.0/30  gre-tunnel-84          0     <--- siec tunelu GRE (connected)
    DAc  192.168.53.0/24 ether1                0     <--- siec transportowa (WAN)

4.4. Multicast przez GRE (OSPF, RIPv2 i inne)

Jedna z kluczowych zalet GRE nad IPIP jest możliwość przekazywania ruchu multicastowego IP. Jest to niezbędne dla dynamicznych protokołów routingu, które używają multicastów do wysyłania pakietów Hello i aktualizacji:

• OSPF – używa multicastów 224.0.0.5 i 224.0.0.6
• RIPv2 – używa multicastu 224.0.0.9
• PIM (Protocol Independent Multicast) – używa multicastu 224.0.0.13 (PIM Hello)
• IGMP – zarządzanie grupami multicastowymi (224.0.0.22)
• BGP – NIE używa multicastów. BGP wymienia trasy po TCP (unicast). Tzw. MP-BGP/MBGP może przenosić INFORMACJE o trasach multicastowych, ale sam działa unicastowo. Do uruchomienia BGP przez tunel nie jest potrzebny multicast

GRE przekazuje te pakiety ponieważ są to zwykle pakiety IP z adresem docelowym multicastowym. Router opakowuje je w nagłówek GRE i wysyła do zdalnego końca tunelu. Tam są rozpakowywane i dostarczane do lokalnej tablicy routingu.

Przykład: OSPF przez tunel GRE

Aby uruchomić OSPF przez tunel GRE, wystarczy dodać interfejs tunelu do processu OSPF. Multicastowe pakiety Hello będą automatycznie przekazywane przez tunel:

Router A

/routing ospf instance
add name=default router-id=10.10.10.1

/routing ospf network
add network=172.16.1.0/30 area=backbone
add network=10.10.10.0/24 area=backbone

Router B

/routing ospf instance
add name=default router-id=10.20.20.1

/routing ospf network
add network=172.16.1.0/30 area=backbone
add network=10.20.20.0/24 area=backbone

Pakiety OSPF Hello (do 224.0.0.5) będą przekazywane przez tunel GRE automatycznie. Zamiast ręcznych tras statycznych, routery naucza się siebie nawzajem przez OSPF:

# Po nawiązaniu OSPF - tablica routingu pokaże dynamiczne trasy:
/ip route print where dst-address~"10\."

#      DST-ADDRESS      GATEWAY        DISTANCE
    DAC  10.10.10.0/24   gre-tunnel-84         0
    DAo  10.20.20.0/24   172.16.1.2       110        <--- trasa dynamiczna OSPF

4.5. Weryfikacja tunelu GRE

Podstawowe komendy weryfikacyjne:

# Sprawdzenie stanu interfejsu tunelu GRE
/interface gre print

Flags: X - disabled; R - running
#   NAME             MTU   ACTUAL-MTU   LOCAL-ADDRESS     REMOTE-ADDRESS
0 R gre-tunnel-84    auto  1476         192.168.53.83     192.168.53.84

# Test łączności przez tunel (z routera A):
/ping 172.16.1.2

# Sprawdzenie ARP na interfejsie tunelu:
/ip arp print where interface=gre-tunnel-84

# Monitorowanie ruchu na interfejsie:
/interface monitor-traffic gre-tunnel-84 once

# Sprawdzenie keepalive:
/interface gre print stats

5. Scenariusz 2: Tunel EoIP (warstwa 2 – bridging, broadcasty, multicasty, L2)

EoIP (Ethernet over IP) to protokół MikroTik oparty na RFC 1701 (GRE), który tworzy tunel Ethernetowy między dwoma routerami. W przeciwieństwie do klasycznego GRE, EoIP przekazuje pełne ramki Ethernet, w tym:

• Broadcasty– ARP requests, DHCP discovery (0.0.0.0 -> 255.255.255.255)
• Multicasty L2 – IGMP, LLDP, STP BPDU, protokoły routingu multicastowego
• Ruch nie-IP – IPX, AppleTalk i inne protokoły warstwy 2
• VLANy– ramki 802.1Q przechodzą przez EoIP niezmiennie
• Wszystkie ramki Ethernet – cały ruch warstwy 2

5.1. Tworzenie interfejsu EoIP

Router A (192.168.53.83)

/interface eoip add name=eoip-to-84 \
    remote-address=192.168.53.84 \
    tunnel-id=100 \
    comment="Tunel EoIP L2 do routera B"

Router B (192.168.53.84)

/interface eoip add name=eoip-to-83 \
    remote-address=192.168.53.83 \
    tunnel-id=100 \
    comment="Tunel EoIP L2 do routera A"

Wyjaśnienie parametrów EoIP:

# Wynik po utworzeniu tunelu EoIP na routerze A:
/interface eoip print detail

Flags: X - disabled; R - running
0    ;;; Tunel EoIP L2 do routera B
     name="eoip-to-84" mtu=auto actual-mtu=1458 l2mtu=65535
     mac-address=FE:C6:96:AD:77:E6 arp=enabled arp-timeout=auto
     loop-protect=default loop-protect-status=off
     loop-protect-send-interval=5s loop-protect-disable-time=5m
     local-address=0.0.0.0 remote-address=192.168.53.84
     tunnel-id=100
     keepalive=10s,10 dscp=inherit clamp-tcp-mss=yes
     dont-fragment=no allow-fast-path=yes

Z powyższego wyniku widzimy:

• actual-mtu=1458 – pełna ramka Ethernet (1500) minus 42 bajty overhead EoIP (20 IP + 8 GRE + 14 Ethernet)
• l2mtu=65535 – MTU warstwy 2 (do użytku bridge)
• mac-address=FE:C6:96:AD:77:E6– automatycznie wygenerowany adres MAC
• tunnel-id=100– identyfikator tunelu

5.2. Bridge i porty

Aby EoIP działał jak wirtualny kabel Ethernet, interface tunelu EoIP musi zostać dodany do bridge (mostka) razem z lokalnymi portami Ethernet. Bridge łączy wszystkie porty w jeden broadcast domain:

Router A (192.168.53.83)

# Utwórz bridge (jeśli jeszcze nie istnieje)
/interface bridge add name=bridge1 protocol-mode=rstp \
    comment="Bridge z EoIP i portami LAN"

# Dodaj interfejs EoIP do bridge
/interface bridge port add bridge=bridge1 interface=eoip-to-84 \
    comment="EoIP tunel w bridge"

# Dodaj lokalny port LAN do bridge (NIE port transportowy/WAN!)
# UWAGA: w RouterOS 7 ether1 z adresem IP został już dodany automatycznie -
# sprawdź /interface bridge port print i usuń go jeśli nie chcesz bridge'owac
# sieci transportowej.
/interface bridge port add bridge=bridge1 interface=ether2 \
    comment="Port Ethernet LAN w bridge"

Router B (192.168.53.84)

# Utwórz bridge
/interface bridge add name=bridge1 protocol-mode=rstp \
    comment="Bridge z EoIP i portami LAN"

# Dodaj port EoIP do bridge
/interface bridge port add bridge=bridge1 interface=eoip-to-83 \
    comment="EoIP tunel w bridge"

# Dodaj lokalny port LAN do bridge (NIE port transportowy/WAN).
# Sprawdź też czy RouterOS nie dodał automatycznie ether1 (port z IP) do bridge.
/interface bridge port add bridge=bridge1 interface=ether2 \
    comment="Port Ethernet LAN w bridge"

# Bridge na routerze A:
/interface bridge print detail

Flags: X - disabled; R - running
0 R ;;; Bridge z EoIP i portami LAN
     name="bridge1" mtu=auto actual-mtu=1458 l2mtu=65535
     arp=enabled arp-timeout=auto mac-address=FE:C6:96:AD:77:E6
     protocol-mode=rstp fast-forward=yes igmp-snooping=no
     auto-mac=yes ageing-time=5m priority=0x8000
     max-message-age=20s forward-delay=15s
     transmit-hold-count=6 vlan-filtering=no

# Porty bridge (po usunięciu automatycznie dodanego ether1):
# UWAGA: nie ma tu portu TRANSPORTOWEGO - ether1 pozostał poza bridge,
# a jako port LAN dodaliśmy ether2.
/interface bridge port print

INTERFACE   BRIDGE   HW   PVID  PRIORITY  HORIZON
eoip-to-84  bridge1          1  0x80      none
ether2      bridge1  yes     1  0x80      none

Widzimy, ze bridge1 ma porty LAN, a port transportowy (ether1) jest poza bridge:

• eoip-to-84– Port EoIP (bez HW offloading, ponieważ to interfejs wirtualny)
• ether2– Fizyczny port LAN z hardware offloading (HW=yes)

5.3. Adresowanie i mostkowanie

Adres IP przypisujemy do bridge, NIE DO poszczególnych portów. Mostkowany interfejs (bridge) jest JEDNYM PORTEM broadcastowym:

Router A (192.168.53.83)

/ip address add address=10.100.100.1/24 interface=bridge1 \
    comment="Adres IP sieci lokalnej A"

Router B (192.168.53.84)

/ip address add address=10.100.100.2/24 interface=bridge1 \
    comment="Adres IP sieci lokalnej B"

Uwaga: oba routery mają adresy z TEJ SAMEJ sieci (10.100.100.0/24). To działa ponieważ są w tym samym broadcast domain dzięki tunelowi EoIP. Broadcast ARP z routera A dotrze do routera B i odwrotnie, tak jakby były połączone fizycznym kablem Ethernet.

# Przypisanie IP do bridge na routerze A:
/ip address print

  ADDRESS           NETWORK       INTERFACE
  192.168.53.83/24  192.168.53.0  ether1
  10.100.100.1/24   10.100.100.0  bridge1

5.4. Ustawianie MAC address dla EoIP

Gdy tunele EoIP są dodawane do bridge, ważne jest, aby każdy tunel miał unikalny adres MAC. Dzięki temu algorytmy bridge (STP, learning) działają poprawnie.

IANA zarezerwowała zakres MAC dla tuneli: 00:00:5E:80:00:00 – 00:00:5E:FF:FF:FF

Router A

# Ustaw unikalny MAC na tunelu EoIP
/interface eoip set eoip-to-84 mac-address=00:00:5E:80:00:01

Router B

# Ustaw unikalny MAC na tunelu EoIP
/interface eoip set eoip-to-83 mac-address=00:00:5E:80:00:02

5.5. Weryfikacja ruchu L2 (broadcasty, multicasty)

Na tunelu EoIP przekazywane są:

Broadcasty (ARP, DHCP)

# Gdy urządzenie w sieci A szuka MAC dla 10.100.100.2:
# 1. Wysyła ARP Request broadcast na wszystkie porty bridge
# 2. Bridge przekazuje ramkę przez EoIP do routera B
# 3. Router B dostarcza ramkę na wszystkie porty swojego bridge
# 4. Urządzenie B odpowiada ARP Reply (unicast)
# 5. Odpowiedź wróci tunelem EoIP do routera A

# Komendy weryfikacyjne na routerze:

# Tablica ARP - pokazuje nauczonych sąsiadów L2
/ip arp print

# Tablica MAC bridge - pokazuje porty i przypisane MAC
/interface bridge host print

# Statystyki bridge
/interface bridge print stats

# Monitorowanie ruchu na tunelu EoIP
/interface monitor-traffic eoip-to-84 once

Multicasty (IGMP, LLDP, BPDU)

# Multicastowe ramki Ethernet są przekazywane przez EoIP tak samo jak broadcasty
# Np. pakiet OSPF Hello (224.0.0.5) jest ramka Ethernet z docelowym
# adresem MAC multicastowym 01:00:5E:00:00:05

# Bridge może opcjonalnie włączyć IGMP snooping (ogranicza rozgłaszanie multicastu):
/interface bridge set bridge1 igmp-snooping=yes

# Jeśli w sieci L2 nie ma zewnętrznego queriera (np. routera PIM/IGMP proxy),
# włącz querier na łącznie jednym bridge w broadcast domain, inaczej
# wpisy w tablicy multicastowej wygasną po kilku minutach:
/interface bridge set bridge1 multicast-querier=yes

# Sprawdź tablice multicast bridge (MDB - Multicast DataBase):
/interface bridge mdb print

VLANy przez EoIP

# EoIP przekazuje ramki 802.1Q niezmiennie - VLAN przechodzi "przezroczyście"
# bez dodatkowej konfiguracji. Jeśli chcesz zakończyć VLAN na routerze (dać mu IP):

# Na routerze A - interfejs VLAN na bazie tunelu EoIP:
/interface vlan add name=vlan10 vlan-id=10 interface=eoip-to-84

# Adres IP dla VLAN 10:
/ip address add address=10.10.10.1/24 interface=vlan10

6. Testy na żywo – weryfikacja end-to-end (RouterOS 7.16.1)

Poniżej przedstawiam wyniki testów wykonanych na żywo na dwóch routerach MikroTik CHR z RouterOS 7.16.1 (stable):

6.1. Test tunelu GRE (warstwa 3)

Po skonfigurowaniu tunelu GRE na obu routerach sprawdzamy działanie przez ping końca tunelu:

# Z routera A - ping końca tunelu GRE (172.16.1.2 to tunel, nie fizyczne IP):
[admin@MikroTik] > /ping 172.16.1.2 count=5

  SEQ HOST        SIZE TTL TIME    STATUS
    0 172.16.1.2     56  64 267us
    1 172.16.1.2     56  64 575us
    2 172.16.1.2     56  64 743us
    3 172.16.1.2     56  64 736us
    4 172.16.1.2     56  64 853us
    sent=5 received=5 packet-loss=0% min-rtt=267us avg-rtt=634us max-rtt=853us

Dalej: routing między sieciami LAN obu routerów przez tunel GRE. Router A ma LAN 10.10.10.0/24 (na lo), router B ma LAN 10.20.20.0/24 (na lo). Trasy statyczne: na A dodajemy 10.20.20.0/24 przez bramę 172.16.1.2, na B dodajemy 10.10.10.0/24 przez bramę 172.16.1.1.

# Z routera A - ping sieci lokalnej B przez tunel GRE:
[admin@MikroTik] > /ping 10.20.20.1 count=5

  SEQ HOST        SIZE TTL TIME    STATUS
    0 10.20.20.1     56  64 534us
    1 10.20.20.1     56  64 898us
    2 10.20.20.1     56  64 873us
    3 10.20.20.1     56  64 771us
    4 10.20.20.1     56  64 715us
    sent=5 received=5 packet-loss=0% min-rtt=534us avg-rtt=758us max-rtt=898us

# Tablica routingu na routerze A (widać trasę aktywna):
[admin@MikroTik] > /ip route print
Flags: D - DYNAMIC; A - ACTIVE; c - CONNECT, s - STATIC
#     DST-ADDRESS      GATEWAY     DISTANCE
;;; Do sieci B przez GRE
0  As 10.20.20.0/24    172.16.1.2         1
    DAc 172.16.1.0/30    gre-test           0
    DAc 192.168.53.0/24  ether1             0

6.2 Test tunelu EoIP (warstwa 2)

Po skonfigurowaniu EoIP + bridge-lan na obu routerach (tunnel-id=200, adresy 10.100.100.1/24 na A i 10.100.100.2/24 na B) testujemy komunikację L2:

# Z routera A - ping po L2 do routera B (przez EoIP/bridge-lan):
[admin@MikroTik] > /ping 10.100.100.2 count=5

  SEQ HOST         SIZE TTL TIME    STATUS
    0 10.100.100.2    56  64 507us
    1 10.100.100.2    56  64 296us
    2 10.100.100.2    56  64 727us
    3 10.100.100.2    56  64 955us
    4 10.100.100.2    56  64 729us
    sent=5 received=5 packet-loss=0% min-rtt=296us avg-rtt=642us max-rtt=955us

6.3. Dowód przekazywania broadcastu i multicastu przez EoIP

Najlepszy dowód: sniffer pakietów na routerze B (przechwytujący na interfejsie eoip-test) i wygenerowanie broadcast/multicast z routera A. Poniżej wynik:

Cel testu

1. Uruchamiamy sniffer pakietów na routerze B na interfejsie eoip-test
2. Z routera A wysyłamy broadcast ICMP (ping 10.100.100.255) i multicast ICMP (ping 224.0.0.1) na bridge-lan
3. Zatrzymujemy sniffer i oglądamy przechwycone ramki

Komendy testu

# Krok 1: na routerze B uruchom sniffer na interfejsie EoIP
/tool sniffer set filter-interface=eoip-test
/tool sniffer start

# Krok 2: z routera A wyślij broadcasty i multicasty
/ping 10.100.100.255 count=4 interface=bridge-lan
/ping 224.0.0.1 count=2 interface=bridge-lan

# Krok 3: na routerze B zatrzymaj sniffer i pokaż przechwycone pakiety
/tool sniffer stop
/tool sniffer packet print detail

Wynik sniffera na routerze B – dowód przekazywania L2 przez EoIP

 0 time=0.306 num=1 direction=rx src-mac=FE:2D:B4:D3:8C:9E
   dst-mac=01:80:C2:00:00:00 interface=eoip-test protocol=802.2 size=53

 1 time=2.182 num=2 direction=tx src-mac=FE:44:3F:F2:73:4F
   dst-mac=FF:FF:FF:FF:FF:FF interface=eoip-test
   src-address=10.100.100.2:5678 (discovery)
   dst-address=255.255.255.255:5678 (discovery) protocol=ip ip-protocol=udp

 2 time=2.182 num=3 direction=tx src-mac=FE:44:3F:F2:73:4F
   dst-mac=01:00:0C:CC:CC:CC interface=eoip-test protocol=802.2

 3 time=2.182 num=4 direction=tx src-mac=FE:44:3F:F2:73:4F
   dst-mac=01:80:C2:00:00:0E interface=eoip-test protocol=lldp

 5 time=3.506 num=6 direction=rx src-mac=FE:2D:B4:D3:8C:9E
   dst-mac=FF:FF:FF:FF:FF:FF interface=eoip-test
   src-address=10.100.100.1 dst-address=10.100.100.255
   protocol=ip ip-protocol=icmp size=70 ttl=255

 7 time=4.508 num=8 direction=rx src-mac=FE:2D:B4:D3:8C:9E
   dst-mac=FF:FF:FF:FF:FF:FF interface=eoip-test
   src-address=10.100.100.1 dst-address=10.100.100.255
   protocol=ip ip-protocol=icmp size=70 ttl=255

11 time=7.517 num=12 direction=rx src-mac=FE:2D:B4:D3:8C:9E
   dst-mac=01:00:5E:00:00:01 interface=eoip-test
   src-address=10.100.100.1 dst-address=224.0.0.1
   protocol=ip ip-protocol=icmp size=70 ttl=1

13 time=8.519 num=14 direction=rx src-mac=FE:2D:B4:D3:8C:9E
   dst-mac=01:00:5E:00:00:01 interface=eoip-test
   src-address=10.100.100.1 dst-address=224.0.0.1
   protocol=ip ip-protocol=icmp size=70 ttl=1

Interpretacja wyników – co pokazuje sniffer

Dowód na działanie bridge (tablica ARP)

# Tablica ARP na routerze A - widać MAC z drugiej strony tunelu:
/ip arp print where interface=bridge-lan
Flags: D - DYNAMIC; C - COMPLETE
#    ADDRESS         MAC-ADDRESS        INTERFACE   STATUS
0 DC 10.100.100.2    FE:44:3F:F2:73:4F  bridge-lan  reachable

# Z routera B:
/ip arp print where interface=bridge-lan
Flags: D - DYNAMIC; C - COMPLETE
#   ADDRESS       MAC-ADDRESS        INTERFACE   STATUS
0 DC 10.100.100.1  FE:2D:B4:D3:8C:9E  bridge-lan  reachable

7. Zasady zapory (firewall) dla tuneli

Tunele GRE i EoIP używają protokołu IP numer 47 (nie TCP, nie UDP). Aby tunele działały, firewall musi zezwalać na ten protokół.

Zezwolenie na ruch GRE/EoIP w firewallu

Router A (192.168.53.83)

# Zezwól na GRE/EoIP tylko od znanego routera
/ip firewall filter add chain=input \
    protocol=gre \
    src-address=192.168.53.84 \
    action=accept \
    comment="GRE/EoIP od routera B"

# Odrzuć GRE/EoIP z nieznanych źródeł
/ip firewall filter add chain=input \
    protocol=gre \
    action=drop \
    comment="Odrzucenie GRE z nieznanych zrodel"

Router B (192.168.53.84)

# Zezwól na GRE/EoIP tylko od znanego routera
/ip firewall filter add chain=input \
    protocol=gre \
    src-address=192.168.53.83 \
    action=accept \
    comment="GRE/EoIP od routera A"

# Odrzuć GRE/EoIP z nieznanych źródeł
/ip firewall filter add chain=input \
    protocol=gre \
    action=drop \
    comment="Odrzucenie GRE z nieznanych zrodel"

# Reguły firewall po dodaniu na routerze A:
/ip firewall filter print

#    CHAIN   ACTION   PROTOCOL   SRC-ADDRESS       COMMENT
0    input   accept   gre        192.168.53.84     GRE od routera B
1    input   drop     gre                             Odrzucenie GRE z nieznanych zrodel

Ochrona ruchu przepływającego przez tunel

Aby kontrolować jaki ruch może przepływać przez tunel (forward), dodaj reguły w chain forward:

# Zezwól na przepływ ruchu z sieci lokalnych przez tunel
/ip firewall filter add chain=forward \
    src-address=10.100.100.0/24 \
    out-interface=gre-tunnel-84 \
    action=accept \
    comment="Ruch z sieci A do B przez GRE"

/ip firewall filter add chain=forward \
    src-address=172.16.1.0/30 \
    dst-address=10.100.100.0/24 \
    in-interface=gre-tunnel-84 \
    action=accept \
    comment="Ruch z sieci B do A przez GRE"

8. Szyfrowanie – IPsec z tunelami

Oprócz prostej opcji ipsec-secret (pre-shared key), można skonfigurować pełne IPsec transport mode dla tuneli GRE lub EoIP. Jest to zalecane gdy tunele przechodzą przez sieci publiczne (internet).

Szyfrowanie automatyczne (ipsec-secret)

Można automatycznie zaszyfrować tunel GRE lub EoIP używając wbudowanej opcji IPsec. RouterOS sam utworzy peer, proposal i policy (tryb transport, protocol=gre):

# Dodanie klucza IPsec do tunelu GRE (szyfruje cały tunel)
/interface gre set gre-tunnel-84 ipsec-secret="moj-tajny-klucz-123"

# Lub dodanie klucza IPsec do tunelu EoIP
/interface eoip set eoip-to-84 ipsec-secret="moj-tajny-klucz-123"

IPsec transport mode dla GRE

## Router A ##

# Utwórz peer IPsec.
# UWAGA: "transport" nie jest wartością exchange-mode (są do wyboru
# aggressive|base|main|ike2). Tryb transportowy ustala się w policy
# parametrem tunnel=no (poniżej).
/ip ipsec peer add \
    name=peer-to-84 \
    address=192.168.53.84/32 \
    local-address=192.168.53.83 \
    exchange-mode=main \
    passive=no

# Utwórz proposal
/ip ipsec proposal add name=prop-to-84 \
    auth-algorithms=sha256 \
    enc-algorithms=aes-256-cbc \
    pfs-group=modp2048

# Utwórz profil
/ip ipsec profile add name=prof-to-84 \
    hash-algorithm=sha256 \
    enc-algorithm=aes-256 \
    dh-group=modp2048 \
    lifetime=8h \
    dpd-interval=120s \
    dpd-maximum-failures=5

# Utwórz ID peer (local)
/ip ipsec identity add peer=peer-to-84 \
    auth-method=pre-shared-key \
    secret="moj-bardzo-tajny-klucz"

# Utwórz policy - co zaszyfrować.
# tunnel=no = tryb TRANSPORT (szyfrujemy ruch GRE/gre między adresami peerów).
# tunnel=yes = tryb TUNELOWY (dodaje dodatkowy nagłówek IP z adresami
# SĄ) - NIE tego chcemy dla GRE.
/ip ipsec policy add \
    src-address=192.168.53.83 \
    dst-address=192.168.53.84 \
    protocol=gre \
    action=encrypt \
    level=require \
    tunnel=no \
    sa-src-address=192.168.53.83 \
    sa-dst-address=192.168.53.84 \
    proposal=prop-to-84 \
    peer=peer-to-84

Na routerze B konfiguracja jest lustrzanym odbiciem (zamień src-address z dst-address).

9. MTU i problem fragmentacji

Odpowiednie ustawienie MTU jest krytyczne dla poprawnego działania tuneli. Każdy tunel dodaje overhead (dodatkowe bajty nagłówków), co zmniejsza dostępne MTU dla danych użytkownika.

Overhead tunelów

Zalecane ustawienia MTU

# Dla tunelu GRE - ustawienie explicit MTU
/interface gre set gre-tunnel-84 mtu=1476

# Dla tunelu EoIP - ustawienie explicit MTU
/interface eoip set eoip-to-84 mtu=1458

# Jeśli tunel przechodzi przez PPPoE lub inny tunel z mniejszym MTU:
# Np. PPPoE MTU = 1492, to MTU tunelu = 1492 - 24 (GRE) = 1468
/interface gre set gre-tunnel-84 mtu=1468

Testowanie MTU

# Test ping z dużym pakietem i bitem DF (Don't Fragment)
# Na routerze A - testowanie do końca tunelu:

# Test z pełnym pakietem (powinien przejść):
/ping 172.16.1.2 size=1448 do-not-fragment=yes

# Test z za dużym pakietem (powinien się nie powieść):
/ping 172.16.1.2 size=1449 do-not-fragment=yes

# Na Linux/Windows z testowaniem PMTUD (Path MTU Discovery):
# ping -M do -s 1448 172.16.1.2    (powinien przejść)
# ping -M do -s 1449 172.16.1.2    (powinien się nie powieść)

10. Diagnostyka i rozwiązywanie problemów

Częsty problem i rozwiązania

Narzędzia diagnostyczne

# Przegląd wszystkich interfejsów tunelowych:
/interface gre print stats
/interface eoip print stats

# Monitorowanie ruchu na interfejsie (jednorazowy odczyt):
/interface monitor-traffic gre-tunnel-84 once
/interface monitor-traffic eoip-to-84 once

# Sprawdzanie tablicy ARP (sąsiedzi L2):
/ip arp print

# Sprawdzanie tablicy MAC bridge:
/interface bridge host print

# Sprawdzanie logów (czy są błędy):
/log print where topics~"interface"

# Sprawdzanie stanu IPsec (jeśli szyfrowane):
/ip ipsec active-peers print
/ip ipsec installed-sa print

# Sprawdzanie tras (czy brama tunelu jest aktywna):
/ip route print stats

# Pełna diagnostyka interfejsu:
# UWAGA: nie istnieje komenda "gre monitor" ani "eoip monitor".
# Jednorazowy pomiar ruchu robi się tak jak wyżej (monitor-traffic ... once),
# a stan tunelu sprawdza się przez print + kept (+ keepalive) + counters.
/interface gre print stats
/interface eoip print stats

Kompletny zestaw komend do kopiowania – Scenariusz 1 (GRE L3)

Router A (192.168.53.83)

#### KONFIGURACJA TUNELU GRE L3 - ROUTER A ####

# 1. Utwórz interfejs GRE
/interface gre add name=gre-tunnel-84 remote-address=192.168.53.84 local-address=192.168.53.83 keepalive=10s,10 comment="Tunel GRE do routera B"

# 2. Przypisz adres IP tunelu
/ip address add address=172.16.1.1/30 interface=gre-tunnel-84 comment="Tunel GRE - koniec A"

# 3. Utwórz trasę do sieci zdalnej
/ip route add dst-address=10.20.20.0/24 gateway=172.16.1.2 comment="Trasa do sieci B przez GRE"

# 4. Firewall - zezwól na GRE
/ip firewall filter add chain=input protocol=gre src-address=192.168.53.84 action=accept comment="GRE od routera B" place-before=0

# 5. (Opcjonalnie) Szyfrowanie IPsec
/interface gre set gre-tunnel-84 ipsec-secret="moj-tajny-klucz" allow-fast-path=no

Router B (192.168.53.84)

#### KONFIGURACJA TUNELU GRE L3 - ROUTER B ####

# 1. Utwórz interfejs GRE
/interface gre add name=gre-tunnel-83 remote-address=192.168.53.83 local-address=192.168.53.84 keepalive=10s,10 comment="Tunel GRE do routera A"

# 2. Przypisz adres IP tunelu
/ip address add address=172.16.1.2/30 interface=gre-tunnel-83 comment="Tunel GRE - koniec B"

# 3. Utwórz trasę do sieci zdalnej
/ip route add dst-address=10.10.10.0/24 gateway=172.16.1.1 comment="Trasa do sieci A przez GRE"

# 4. Firewall - zezwól na GRE
/ip firewall filter add chain=input protocol=gre src-address=192.168.53.83 action=accept comment="GRE od routera A" place-before=0

# 5. (Opcjonalnie) Szyfrowanie IPsec
/interface gre set gre-tunnel-83 ipsec-secret="moj-tajny-klucz" allow-fast-path=no

Kompletny zestaw komend do kopiowania – Scenariusz 2 (EoIP L2)

Router A (192.168.53.83)

#### KONFIGURACJA TUNELU EoIP L2 - ROUTER A ####

# 1. Utwórz interfejs EoIP
/interface eoip add name=eoip-to-84 remote-address=192.168.53.84 tunnel-id=100 comment="Tunel EoIP L2 do routera B"

# 2. Ustaw unikalny MAC (dla bridgowania)
/interface eoip set eoip-to-84 mac-address=00:00:5E:80:00:01

# 3. Utwórz bridge z RSTP
/interface bridge add name=bridge1 protocol-mode=rstp comment="Bridge L2 z EoIP"

# 4. Dodaj porty do bridge
/interface bridge port add bridge=bridge1 interface=eoip-to-84 comment="EoIP tunel L2"
/interface bridge port add bridge=bridge1 interface=ether2 comment="Port LAN (nie WAN/ether1!)"
# UWAGA: RouterOS 7 mógł automatycznie dodać do bridge ether1 (port z IP).
# Sprawdź i usuń: /interface bridge port remove [find where interface=ether1]

# 5. Przypisz IP do bridge (NIE do portów!)
/ip address add address=10.100.100.1/24 interface=bridge1 comment="Siec lokalna A"

# 6. Firewall - zezwól na EoIP/GRE
/ip firewall filter add chain=input protocol=gre src-address=192.168.53.84 action=accept comment="EoIP od routera B" place-before=0

# 7. (Opcjonalnie) Szyfrowanie IPsec
/interface eoip set eoip-to-84 ipsec-secret="moj-tajny-klucz" allow-fast-path=no

Router B (192.168.53.84)

#### KONFIGURACJA TUNELU EoIP L2 - ROUTER B ####

# 1. Utwórz interfejs EoIP
/interface eoip add name=eoip-to-83 remote-address=192.168.53.83 tunnel-id=100 comment="Tunel EoIP L2 do routera A"

# 2. Ustaw unikalny MAC (dla bridgowania)
/interface eoip set eoip-to-83 mac-address=00:00:5E:80:00:02

# 3. Utwórz bridge z RSTP
/interface bridge add name=bridge1 protocol-mode=rstp comment="Bridge L2 z EoIP"

# 4. Dodaj porty do bridge
/interface bridge port add bridge=bridge1 interface=eoip-to-83 comment="EoIP tunel L2"
/interface bridge port add bridge=bridge1 interface=ether2 comment="Port LAN (nie WAN/ether1!)"
# UWAGA: RouterOS 7 mógł automatycznie dodać do bridge ether1 (port z IP).
# Sprawdź i usuń: /interface bridge port remove [find where interface=ether1]

# 5. Przypisz IP do bridge (NIE do portów!)
/ip address add address=10.100.100.2/24 interface=bridge1 comment="Siec lokalna B"

# 6. Firewall - zezwól na EoIP/GRE
/ip firewall filter add chain=input protocol=gre src-address=192.168.53.83 action=accept comment="EoIP od routera A" place-before=0

# 7. (Opcjonalnie) Szyfrowanie IPsec
/interface eoip set eoip-to-83 ipsec-secret="moj-tajny-klucz" allow-fast-path=no

11. Podsumowanie i szybka ściąga

Co przekazuje każdy tunel?

Szybka Ściąga Komend

Zalecenia końcowe

1. Zawsze używaj keepalivena tunelach GRE i EoIP. Bez keepalive, interfejs tunelu pozostaje „running” nawet gdy zdalny koniec jest niedostępny, co prowadzi do blackholingu ruchu.
2. Włącz RSTP na wszystkich bridge, które mają więcej niż jeden port. Chroni przed pętlami L2 i broadcast storm.
3. Ustaw unikalne MAC na tunelach EoIP dodawanych do bridge, aby algorytmy MAC learning działały poprawnie.
4. Konfiguruj firewall aby zezwalać na GRE (protocol 47) tylko od znanych źródeł. Bez tego reguły tunele mogą nie działać.
5. Testuj MTUpingiem z bitem DF (Don’t Fragment), aby upewnić się, że pakiety nie są fragmentowane.
6. Nie mieszaj EoIP z GRE do tego samego celu. GRE służy do routingu L3, EoIP do bridgowania L2.
7. Szyfruj tunelegdy przechodzą przez sieci publiczne. Używaj IPsec transport mode lub przynajmniej ipsec-secret.
8. Włącz logowaniei monitorowanie: /log add topics=interface aby rejestrować zmiany stanu interfejsów.