> For the complete documentation index, see [llms.txt](https://netlabs.gitbook.io/juniper/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://netlabs.gitbook.io/juniper/13-tunneling-technologies-ipip-gre.md). # 13) Tunneling Technologies (IPIP/GRE) ## 1. Вводная часть По факту, IPIP и GRE предоставляют только туннелирование, но не шифрование. Для этого есть тот же IPSec. Тут речь пойдёт именно о том как нам гонять трафик между нашими серыми сетями, прибегая только к услуге "Интернет". {% hint style="warning" %} Использовать следует только новые прошивки vMX, так как на 14.1R4.8 версии развернуть OSPFv3 не удаётся. Те же настройки на 18.2R1.9 отлично работают. {% endhint %} ![Схема сети](/files/-M_puvQ5AUA1-BRGe5MX) Предварительные настройки: {% tabs %} {% tab title="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; } } } } ``` {% endtab %} {% tab title="Site-1" %} ``` system { root-authentication { encrypted-password "$1$PpJTV8Ab$qCsraT99bfEvcqaypRFFw."; ## SECRET-DATA } host-name Site-1; } interfaces { ge-0/0/0 { unit 0 { family inet { address 2.2.2.1/30; } } } ge-0/0/1 { unit 0 { family inet { address 172.16.1.1/31; } } } } routing-options { static { route 4.4.4.1/32 next-hop 2.2.2.2; } router-id 1.1.1.2; } protocols { ospf { area 0.0.0.0 { interface ge-0/0/1.0 { interface-type p2p; } interface ge-0/0/0.0 { passive; } } } } ``` {% endtab %} {% tab title="Internet" %} ``` hostname Internet interface Ethernet0/0 ip address 2.2.2.2 255.255.255.252 ! interface Ethernet0/1 ip address 4.4.4.2 255.255.255.252 ! ``` {% endtab %} {% tab title="Site-2" %} ``` system { root-authentication { encrypted-password "$1$PpJTV8Ab$qCsraT99bfEvcqaypRFFw."; ## SECRET-DATA } host-name Site-2; } interfaces { ge-0/0/0 { unit 0 { family inet { address 4.4.4.1/30; } } } ge-0/0/1 { unit 0 { family inet { address 172.16.2.1/31; } } } } routing-options { static { route 2.2.2.1/32 next-hop 4.4.4.2; } router-id 2.2.2.22; } protocols { ospf { area 0.0.0.0 { interface ge-0/0/1.0 { interface-type p2p; } interface ge-0/0/0.0 { passive; } } } } ``` {% endtab %} {% tab title="Router-2" %} ``` system { host-name Router-2; root-authentication { encrypted-password "$1$WWHrtbvC$LheWkevlddegEGfLxNNYi0"; ## SECRET-DATA } } interfaces { ge-0/0/0 { unit 0 { family inet { address 192.168.6.1/24; } } } ge-0/0/1 { unit 0 { family inet { address 172.16.2.0/31; } } } } routing-options { router-id 2.2.2.2; } protocols { ospf { area 0.0.0.0 { interface ge-0/0/0.0 { passive; } interface ge-0/0/1.0 { interface-type p2p; } } } } ``` {% endtab %} {% endtabs %} ## 2. Создание туннельных интерфейсов Виртуальные туннельные интерфейсы (Есть и хардварные) создаются отдельно для каждой PIC (Physical Interface Card). Делается это так: ``` root@Site-1# set chassis fpc 0 pic 0 tunnel-services bandwidth 1g ``` Единственная проблема - это то, что мы не можем на виртуальной машине нормально выделить полосу, да и виртуальный линк тут 1G, поэтому особого смыла в ограничении ширины канала для туннельного интерфейса нет. На нормальном же оборудовании делать это нужно, чтобы трафик от туннеля не забивал весь линк, например. {% code title="root\@Site-1#" %} ``` chassis { fpc 0 { pic 0 { tunnel-services; } } } ``` {% endcode %} Теперь мы увидим интерфейсы GRE и IPIP, которые нельзя сконфигурировать, но которые говорят о том, что туннельные сервисы работают: ``` root@Site-1# run show interfaces terse ... gre up up ipip up up ``` ## 3. Настройка IPIP ![](/files/-M_qKkyUXcghB-yh82dD) Всё довольно просто. Указываем в Source и Destination белые IP, которые смотрят в интернет. Также задаём туннельному интерфейсу какой-нибудь IP так, чтобы он был в одной подсети с туннельным интерфейсом другого устройства: {% tabs %} {% tab title="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; } } } } ``` {% endtab %} {% tab title="Site-2" %} ``` interfaces { ip-0/0/0 { unit 0 { tunnel { source 4.4.4.1; destination 2.2.2.1; } family inet { address 10.10.10.2/24; } } } } ``` {% endtab %} {% endtabs %} Адрес на интерфейсе нужен, чтобы мы могли строить маршрутизацию через туннельный интерфейс. Например, 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: {% code title="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; + } + } ``` {% endcode %} Результат: ``` 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) трафика. ![](/files/-M_rGxgL5zKAR8Cb1bYF) Вернёмся к изначальной конфигурации из первой главы и перенастроим туннелирование под 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: {% tabs %} {% tab title="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; + } + } + } ``` {% endtab %} {% tab title="Site-2" %} ``` root@Site-2# show | compare [edit interfaces] + lo0 { + unit 0 { + family inet6 { + address 2002::1/64; + } + } + } [edit protocols] + ospf3 { + area 0.0.0.0 { + interface gr-0/0/0.0 { + interface-type p2p; + } + interface lo0.0 { + passive; + } + } + } ``` {% endtab %} {% endtabs %} Результат: ``` 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 ![](/files/-Ma1CqOGG7-KccAbmzXk) В данном случае IP-адреса нужны только на стыке с Internet. Внутри сети с обеих сторон трафик будет идти по L2. Вообще, написано, что данный конфиг позволяет преодолеть только один L3-сегмент сети, но у меня получилось перекинуть L2 трафик через ещё один транзитный маршрутизатор. Сама [инструкция](https://www.juniper.net/documentation/us/en/software/junos/interfaces-encryption/topics/topic-map/configuring-layer2-ethernet-services-over-gre.html#id-example-configuring-layer-2-services-over-gre-logical-interfaces-in-bridge-domains). Предварительные настройки: {% tabs %} {% tab title="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; } } ``` {% endtab %} {% tab title="Site-1" %} ``` system { root-authentication { encrypted-password "$1$g0.ilY2l$BWxgrwnnTkf5/ZR3HZpVQ1"; ## SECRET-DATA } host-name Site-1; } chassis { fpc 0 { pic 0 { tunnel-services; } } } interfaces { ge-0/0/0 { unit 0 { family inet { address 2.2.2.1/30; } } } gr-0/0/0 { unit 0 { tunnel { source 2.2.2.1; destination 4.4.4.1; } } } } routing-options { static { route 4.4.4.1/32 next-hop 2.2.2.2; } } ``` {% endtab %} {% tab title="Internet" %} ``` hostname Internet interface Ethernet0/0 ip address 2.2.2.2 255.255.255.252 ! interface Ethernet0/1 ip address 4.4.4.2 255.255.255.252 ! ``` {% endtab %} {% tab title="Site-2" %} ``` system { root-authentication { encrypted-password "$1$g0.ilY2l$BWxgrwnnTkf5/ZR3HZpVQ1"; ## SECRET-DATA } host-name Site-2; } chassis { fpc 0 { pic 0 { tunnel-services; } } } interfaces { ge-0/0/0 { unit 0 { family inet { address 4.4.4.1/30; } } } gr-0/0/0 { unit 0 { tunnel { source 4.4.4.1; destination 2.2.2.1; } } } } routing-options { static { route 2.2.2.1/32 next-hop 4.4.4.2; } } ``` {% endtab %} {% tab title="Router-2" %} ``` system { host-name Router-2; 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; } } } } ``` {% endtab %} {% endtabs %} Как и всегда, настройка пойдёт на границе с интернетом. Вот так выглядит настройка 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: 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: ![](/files/-Ma5ETrzl_fDDUFn7V3F) Настройки для начальной конфигурации можно взять из подраздела этой главы "Конфигурация устройств", пункта "IGP Over GRE". А дальше всё просто. Включаем LDP на всех интерфейсах всех устройств. Только вместо интерфейса ge-0/0/0 включаем его на gr-0/0/0 и не забываем настраивать на MX Lo0-интерфейсы (можно взять такие же как и в router-id), так как LDP строится на них. Пример настройки: {% tabs %} {% tab title="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; + } ``` {% endtab %} {% tab title="Site-1" %} ``` root@Site-1# show | compare [edit interfaces gr-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.2/32; + } + family mpls; + } + } [edit protocols ospf area 0.0.0.0] interface gr-0/0/0.0 { ... } + interface lo0.0 { + passive; + } [edit protocols] + ldp { + interface all; + } ``` {% endtab %} {% endtabs %} Проверка: ``` 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-пакета: ![](/files/-Ma5PN6RhOiDq9ByrB4S) Тут видно, что GRE переносит информацию о протоколе, который он переносит. Судя по всему, за счёт этого нам удается запаковывать в него кадры, IP-заголовки и MPLS-заголовки.