# 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-заголовки. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://netlabs.gitbook.io/juniper/13-tunneling-technologies-ipip-gre.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.