13) Tunneling Technologies (IPIP/GRE)

1. Вводная часть

По факту, IPIP и GRE предоставляют только туннелирование, но не шифрование. Для этого есть тот же IPSec. Тут речь пойдёт именно о том как нам гонять трафик между нашими серыми сетями, прибегая только к услуге "Интернет".

Использовать следует только новые прошивки vMX, так как на 14.1R4.8 версии развернуть OSPFv3 не удаётся. Те же настройки на 18.2R1.9 отлично работают.

Схема сети

Предварительные настройки:

Router-1

system {
    host-name Router-1;
    root-authentication {
        encrypted-password "$1$PpJTV8Ab$qCsraT99bfEvcqaypRFFw."; ## SECRET-DATA
    }
}
interfaces {
    ge-0/0/0 {
        unit 0 {
            family inet {
                address 192.168.5.1/24;
            }
        }
    }
    ge-0/0/1 {
        unit 0 {
            family inet {
                address 172.16.1.0/31;
            }
        }
    }
}                                       
routing-options {
    router-id 1.1.1.1;
}
protocols {
    ospf {
        area 0.0.0.0 {
            interface ge-0/0/0.0 {
                passive;
            }
            interface ge-0/0/1.0 {
                interface-type p2p;
            }
        }
    }
}

Site-1

Internet

Site-2

Router-2

2. Создание туннельных интерфейсов

Виртуальные туннельные интерфейсы (Есть и хардварные) создаются отдельно для каждой PIC (Physical Interface Card). Делается это так:

root@Site-1# set chassis fpc 0 pic 0 tunnel-services bandwidth 1g

Единственная проблема - это то, что мы не можем на виртуальной машине нормально выделить полосу, да и виртуальный линк тут 1G, поэтому особого смыла в ограничении ширины канала для туннельного интерфейса нет. На нормальном же оборудовании делать это нужно, чтобы трафик от туннеля не забивал весь линк, например.

root@Site-1#

chassis {
    fpc 0 {
        pic 0 {
            tunnel-services;
        }
    }
}

Теперь мы увидим интерфейсы GRE и IPIP, которые нельзя сконфигурировать, но которые говорят о том, что туннельные сервисы работают:

root@Site-1# run show interfaces terse 
...
gre                     up    up
ipip                    up    up

3. Настройка IPIP

Всё довольно просто. Указываем в Source и Destination белые IP, которые смотрят в интернет. Также задаём туннельному интерфейсу какой-нибудь IP так, чтобы он был в одной подсети с туннельным интерфейсом другого устройства:

Site-1

interfaces {
    ip-0/0/0 {
        unit 0 {
            tunnel {
                source 2.2.2.1;
                destination 4.4.4.1;
            }
            family inet {
                address 10.10.10.1/24;
            }
        }
    }
}

Site-2

Адрес на интерфейсе нужен, чтобы мы могли строить маршрутизацию через туннельный интерфейс. Например, Site1 сейчас ничего не знает о внутренних сетях Site-2. Мы можем настроить статический маршрут, в котором просто укажем все внутренние подсети противоположной площадки (Не трудно догадаться, что Next-Hop будет IP-адресом туннельного интерфейса противоположного устройства), но вот настроить OSPF не можем.

Причины:

1. IPIP не передаёт Multicast

2. При попытке настроить OSPF Unicast-ом мы получим такую картину:

root@Site-2# run show ospf neighbor           
Address          Interface              State     ID               Pri  Dead
172.16.2.0       ge-0/0/1.0             Full      2.2.2.2          128    38
10.10.10.1       ip-0/0/0.0             Down      0.0.0.0            0    93
10.10.10.1       ip-0/0/0.0             Down      0.0.0.0            0    93

При попытке же настроить всё как обычно, мы получим отключение ip-0/0/0, судя по информации выше, связано это с петлёй. В общем, IPIP подходит только для простого туннелирования (IPv6 через IPv4, например). Для остальных целей есть GRE. В случае с IP-IP для более быстрой настройки (нам тут не нужен выход в интернет) мы можем просто прописать Gateway статикой через ip-0/0/0 и произвести редистрибуцию этого маршрута в OSPF:

Site-2

[edit routing-options static route 0.0.0.0/0]
+    next-hop 10.0.0.1;
[edit protocols ospf]
+   export static-in-ospf;
[edit]
+  policy-options {
+      policy-statement static-in-ospf {
+          from {
+              protocol static;
+              route-filter 0.0.0.0/0 exact;
+          }
+          then accept;
+      }
+  }

Результат:

root@Server-1:~# ping -c 5 192.168.6.6
PING 192.168.6.6 (192.168.6.6) 56(84) bytes of data.
64 bytes from 192.168.6.6: icmp_seq=1 ttl=60 time=3.12 ms
64 bytes from 192.168.6.6: icmp_seq=2 ttl=60 time=2.54 ms
64 bytes from 192.168.6.6: icmp_seq=3 ttl=60 time=1.90 ms
64 bytes from 192.168.6.6: icmp_seq=4 ttl=60 time=2.05 ms
64 bytes from 192.168.6.6: icmp_seq=5 ttl=60 time=2.26 ms

--- 192.168.6.6 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 1.908/2.380/3.127/0.433 ms

Снимать дамп смыла нет, и так понятно, что добавится просто ещё один IP-заголовок, поверх нашей серой адресации. Выглядит это так:

                                         +---------------------------+
                                         |                           |
                                         |      Outer IP Header      |
                                         |                           |
     +---------------------------+       +---------------------------+
     |                           |       |                           |
     |         IP Header         |       |         IP Header         |
     |                           |       |                           |
     +---------------------------+ ====> +---------------------------+
     |                           |       |                           |
     |                           |       |                           |
     |         IP Payload        |       |         IP Payload        |
     |                           |       |                           |
     |                           |       |                           |
     +---------------------------+       +---------------------------+

4. Настройка GRE и IGP Over GRE

Если IPIP просто добавляет IP-заголовок, то GRE переносит в своём заголовке дополнительную информацию: "Protocol Type". Это позволяет интерпретировать содержимое, переносить Multicast, кадры и множество другого (Не только IP) трафика.

Вернёмся к изначальной конфигурации из первой главы и перенастроим туннелирование под GRE. Настройка тут такая же, отличается только имя интерфейса:

root@Site-2# show | compare 
[edit interfaces]
+   gr-0/0/0 {
+       unit 0 {
+           tunnel {
+               source 4.4.4.1;
+               destination 2.2.2.1;
+           }
+           family inet {
+               address 10.10.10.2/24;
+           }
+       }
+   }

А теперь можно настроить OSPF через GRE-туннель:

root@Site-1# set protocols ospf area 0.0.0.0 interface gr-0/0/0 interface-type p2p

Результат:

root@Site-1# run show ospf neighbor 
Address          Interface              State     ID               Pri  Dead
172.16.1.0       ge-0/0/1.0             Full      1.1.1.1          128    38
10.10.10.2       gr-0/0/0.0             Full      2.2.2.22         128    35

root@Server-1:~# ping -c 5 192.168.6.6
PING 192.168.6.6 (192.168.6.6) 56(84) bytes of data.
64 bytes from 192.168.6.6: icmp_seq=1 ttl=60 time=3.00 ms
64 bytes from 192.168.6.6: icmp_seq=2 ttl=60 time=2.26 ms
64 bytes from 192.168.6.6: icmp_seq=3 ttl=60 time=2.26 ms
64 bytes from 192.168.6.6: icmp_seq=4 ttl=60 time=2.34 ms
64 bytes from 192.168.6.6: icmp_seq=5 ttl=60 time=2.45 ms

--- 192.168.6.6 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4002ms
rtt min/avg/max/mdev = 2.261/2.465/3.006/0.279 ms

5. IPv6 Over IPv4

Предположим, что нам нужно прокинуть IPv6 через устаревший IPv4 (Наоборот, кстати, нельзя). Предварительно меняем адресацию на gr-интерфейсе:

root@Site-1# show | compare 
[edit interfaces gr-0/0/0 unit 0]
-      family inet {
-          address 10.10.10.1/24;
-      }
+      family inet6 {
+          address 2000::1/64;
+      }

root@Site-2# show | compare 
[edit interfaces gr-0/0/0 unit 0]
-      family inet {
-          address 10.10.10.2/24;
-      }
+      family inet6 {
+          address 2000::2/64;
+      }

Дополнительно навешаем IPv6 адреса на Lo0 интерфейсы и запустим OSPFv3:

Site-1

root@Site-1# show | compare                                                 
[edit interfaces]
+   lo0 {
+       unit 0 {
+           family inet6 {
+               address 2001::1/64;
+           }
+       }
+   }
[edit protocols]
+   ospf3 {
+       area 0.0.0.0 {
+           interface lo0.0 {
+               passive;
+           }
+           interface gr-0/0/0.0 {
+               interface-type p2p;
+           }
+       }
+   }

Site-2

Результат:

root@Site-2# run ping 2001::1 source 2002::1 count 5 rapid 
PING6(56=40+8+8 bytes) 2002::1 --> 2001::1
!!!!!
--- 2001::1 ping6 statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/std-dev = 0.755/0.996/1.129/0.127 ms

6. L2 Over GRE

В данном случае IP-адреса нужны только на стыке с Internet. Внутри сети с обеих сторон трафик будет идти по L2. Вообще, написано, что данный конфиг позволяет преодолеть только один L3-сегмент сети, но у меня получилось перекинуть L2 трафик через ещё один транзитный маршрутизатор. Сама инструкция.

Предварительные настройки:

Router-1

system {
    host-name Router-1;
    root-authentication {
        encrypted-password "$1$g0.ilY2l$BWxgrwnnTkf5/ZR3HZpVQ1"; ## SECRET-DATA
    }
}
interfaces {
    ge-0/0/0 {
        unit 0 {
            family bridge {
                interface-mode access;
                vlan-id 10;
            }
        }
    }
    ge-0/0/1 {
        unit 0 {
            family bridge {
                interface-mode trunk;
                vlan-id-list 10;
            }
        }                               
    }
}
bridge-domains {
    v10 {
        vlan-id 10;
    }
}

Site-1

Internet

Site-2

Router-2

Как и всегда, настройка пойдёт на границе с интернетом. Вот так выглядит настройка L2 Over GRE (применимо как для Site-1, так и для Site-2):

[edit chassis]                   ##Вроде как нужно для включения GR-интефейса в
+  network-services enhanced-ip; ##бридж, но на VM работает и без этого
[edit interfaces gr-0/0/0 unit 0]
+      family bridge {
+          interface-mode trunk;
+          vlan-id-list 10;
+      }
[edit interfaces]
+   ge-0/0/1 {
+       unit 0 {
+           family bridge {
+               interface-mode trunk;
+               vlan-id-list 10;
+           }
+       }
+   }
[edit]
+  routing-instances { ##Под отдельный L2-канал создаётся виртуальный свитч
+      v10 {
+          instance-type virtual-switch;
+          interface gr-0/0/0.0;        ##Включаем сюда наш GRE-интерфейс
+          interface ge-0/0/1.0;        ##и интерфейс в сторону нашей L2-сети
+          bridge-domains {
+              v10 {
+                  vlan-id 10;
+              }
+          }
+      }
+  }

Результат:

root@Server-1:~# ip address show dev ens3
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:50:00:00:08:00 brd ff:ff:ff:ff:ff:ff
    inet 12.12.12.12/24 brd 12.12.12.255 scope global ens3
       valid_lft forever preferred_lft forever
    inet6 fe80::250:ff:fe00:800/64 scope link 
       valid_lft forever preferred_lft forever
root@Server-1:~# ping 12.12.12.13 -c 3
PING 12.12.12.13 (12.12.12.13) 56(84) bytes of data.
64 bytes from 12.12.12.13: icmp_seq=1 ttl=64 time=7.51 ms
64 bytes from 12.12.12.13: icmp_seq=2 ttl=64 time=2.61 ms
64 bytes from 12.12.12.13: icmp_seq=3 ttl=64 time=3.63 ms

--- 12.12.12.13 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 2.613/4.586/7.516/2.114 ms

7. MPLS Over GRE

Для этого примера возьмём ту же адресацию, что в пункте 4:

Настройки для начальной конфигурации можно взять из подраздела этой главы "Конфигурация устройств", пункта "IGP Over GRE".

А дальше всё просто. Включаем LDP на всех интерфейсах всех устройств. Только вместо интерфейса ge-0/0/0 включаем его на gr-0/0/0 и не забываем настраивать на MX Lo0-интерфейсы (можно взять такие же как и в router-id), так как LDP строится на них. Пример настройки:

Router-1

root@Router-1# show | compare 
[edit interfaces ge-0/0/0 unit 0]
+      family mpls;
[edit interfaces ge-0/0/1 unit 0]
+      family mpls;
[edit interfaces]
+   lo0 {
+       unit 0 {
+           family inet {
+               address 1.1.1.1/32;
+           }
+           family mpls;
+       }
+   }
[edit protocols ospf area 0.0.0.0]
      interface ge-0/0/1.0 { ... }
+     interface lo0.0 {
+         passive;
+     }
[edit protocols]
+   ldp {
+       interface all;
+   }

Site-1

Проверка:

root@Router-2# run show route table inet.3  

inet.3: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

1.1.1.1/32         *[LDP/9] 00:00:06, metric 1
                    > to 172.16.2.1 via ge-0/0/1.0, Push 299792
1.1.1.2/32         *[LDP/9] 00:00:06, metric 1
                    > to 172.16.2.1 via ge-0/0/1.0, Push 299776
2.2.2.22/32        *[LDP/9] 00:00:06, metric 1
                    > to 172.16.2.1 via ge-0/0/1.0
root@Router-2# run traceroute mpls ldp 1.1.1.1 
  Probe options: ttl 64, retries 3, wait 10, paths 16, exp 7, fanout 16

  ttl    Label  Protocol    Address          Previous Hop     Probe Status
    1   299792  LDP         172.16.2.1       (null)           Success           
    2   299776  LDP         10.10.10.1       172.16.2.1       Success           
    3        3  LDP         172.16.1.0       10.10.10.1       Egress            

  Path 1 via ge-0/0/1.0 destination 127.0.0.64

Вот так выглядит дамп GRE-пакета:

Тут видно, что GRE переносит информацию о протоколе, который он переносит. Судя по всему, за счёт этого нам удается запаковывать в него кадры, IP-заголовки и MPLS-заголовки.