iValera

Подскажите плз при выключенном stp глобально - проходят ли bpdu? Можно ли посмотреть счетчики? В firewall правил нет

если схемы обобщить, то становится понятно что явно есть баги с мультикастом в VC с использованием LAG. Оба топика перекликаются. ps: ограничивать не хочу, но хотелось бы рекомендовать писать по делу, а флудить продолжайте в телеграме :)

Так и будете сидеть - это вы про кого? Тут мои последние 2 сообщения с багами, по первому я отписался по результату, где написал что рекомендация от jtac, по последнему тикет тоже создан и ожидает пока бангалоровцы соизволят вникнуть, обычно на это уходит 2-3 дня. ps: а все из-за банального нежелания писать по делу, неужели вам телеграмма нехватает.

Ох уж этот жунипер... Никто не сталкивался со след кейсом? QFX5110 добавляю в существующий LAG 1 или 2 порта (значение не имеет), порт в лаге виден все ок, трафик бегает, но есть проблема с мультикастом. Дизайн таков, что сначала в этом лаге бегут сырцы в сторону RP, а потом в этом же лаге возвращаются обратно уже по pim в другом влане. Так вот в новых портах лага трафик ходит только в одну сторону, в сторону RP, а по pim уже 0 kpps. В связи с этим наблюдаем потерю части мультикаст групп. Выключаешь эти новые 1 или 2 порта и всё нормализуется. 17.4R1.16

Если кому интересно, требовалось удалить полностью влан, поудалять с интерфейсов и затем создать заново. По рекомендации от jtac. Обычно ожиждаешь подобного на старых длинках, у которых аптайм по 2000 дней, но не на новом джуне..или я чего-то об этом новом для меня вендоре еще не знаю.

Коллеги вопрос. Есть обычный ae1 в транке, между двумя qfx, которые в свою очередь в стеке. прописаны вланы и все работает. Понадобилось пустить эти вланы в другом линке - ae2, собственно что сделано, на стороне А продублировали настройки ae, на стороне Б на ae1 удалили вле вланы, оставив один (заглушка), на ae2 добавили эти вланы. Применили все одним коммитом и все работает, кроме мультикаста от сырцов, который просто идет со стримеров во влане. Пока не вернули этот влан в старый ae1 - мультик не лился. QFX-5110-48s 17.4R1.16 Старый ae1 выключался вообще, сырцы не появилялись show route protocol pim terse было только то, что приходило не со стороны ae1/ae2, был правда одна группа, маршрут до которой пришел уже по L3 и канал работал.

smartedge 1200 это шасси, а софт стоит на всей линейке одинаковый http://rbman.ito.expert/

А кто говорил дерьмовый? Попробуем для начала rb2011iL-IN. Еще раз поясню, этот тик выписывается со склада и на след день на стенде. А искать сервер, неттоп и т.п. занимает куда больше времени с последующей возьней настройки. Клиенту может быть не понятен и iperf, он предложит запустить его у себя на vds хостинге и тютю, далее уже пошла юридичная возня и т.п. Вобщем никто не спорит что железный iperf лучше чем тик, но если тик покажет состоятельность, то практичнее использовать будет его. т.к. не нужны будут поголовные обновления ноутов у ремонтников

Да я понимаю, просто iperf это отдельные требования к серверу, ноуту с интеловой картой и т.п. Вот и думаю что быстрее и менее затратно. Так то стоит железный iperf сервер на сети, хз что за железо, но выдает максимум 500-600мбит/с. Может кто поделится своими ключами запуска сервер/клиент iperf.

А что если в ядре поставить микротик и к клиенту ходить с другим микротиком, и приходить запускать bandwidth test?

Однми мы используем как L2 DXS-3600-32S?)

Не думаю. Т.к. у всех магистралов есть ggc, зачем тогда провайдеру давать PNI. Я думаю Гугл заинтересован в как можно большем количестве PNI, при условии даже что клиенту доступен GGC. На случай аварий или там или там. Гига может быть мало, т.к. им попросту порой жалко портов, они у них периодически заканчиваются. Если вам прям капец как надо, можете попробовать проявить настойчивость и желание организовать протяжку за свой счет)

Актуально? Можем

Ничего нет, только BGP

Поднял сессии, трафик при падении с прямом стыке начал ходить через IX.

Мы как раз ощутили, такси пришлось ловить по-старинке)

У нас вот следующая картинка, есть аплинк, есть стык msk-ix и есть прямой стык с гуглом. Так вот при проблемах в стыке с Гуглом (а они каждые 2-3 месяца) трафик льется c аплинка, а не с ожидаемого msk-ix как хотелось бы. И так всегда( Или с гуглом на msk-ix надо прямую сессию поднимать? Дейв об этом что-то писал недавно в рассылке

1 портченел вниз к абонентам, 1 к аплинкам, 1 на вторую циску (в котором балансится трафик между цисками, тоесть там есть трафик обоих Po) Кому если интересно, аплинковский портченел разобрали, постарались по-другому раскидать порты (хотя и так они подключены более менее правильно), не помогло. Как начинает расти трафик - портченел, который вниз, просаживается, затем боковой Po, затем аплинковский. В итоге все перенесли на вторую циску.

1ый Po 3 порта, у него нагрузка меньше да, но если есть нагрузка на одном из 3ех Po, то абонентов так или иначе это затронет.

Да, спасибо. поправил

Графики портов из port-chan 3 (в котором 4 порта) ps: отредактировал 1 пост, распортовку уточнил.

Добрый день, данные ниже не ЧНН, есть 3 port-channel, подозрение что неправильный дизайн подключения портов 10G привел к упиранию в полку по утилизации фабрики. В частности ранее был 2 port-channel, проблема видимо была, но не замечалась так ярко, когда добавили третий port-channel, тут же начались проблемы. Трафик подобрался к началу ЧНН в 19-20 часов и перестал расти, более того начал падать. У абонентов возрастание пингов и медленная загрузка страниц. Для примера в аттаче 2 скрина. По науке "The port pairs are 1,4; 5,7; 2,3; and 6,8" дают по 16G Сейчас portchannel собраны: 1. 3:6, 3:7, 4:7 2. 3:3, 3:4, 4:3, 4:4 3. 3:1, 3:2, 4:1, 4:6 Прошу подсказать, на сколько верный данный дизайн составления port-chan и если в связи с этим вызваны проблемы, то как правильно? Составлять port-chan на одной карте? Например порты брать 1, 5, 2 ? m9-co-asbr2#show platform hardware capacity System Resources PFC operating mode: PFC3CXL Supervisor redundancy mode: administratively sso, operationally sso Switching resources: Module Part number Series CEF mode 1 WS-X6724-SFP CEF720 dCEF 2 WS-X6704-10GE CEF720 CEF 3 WS-X6708-10GE CEF720 dCEF 4 WS-X6708-10GE CEF720 dCEF 6 RSP720-3CXL-GE supervisor CEF Power Resources Power supply redundancy mode: administratively redundant operationally non-redundant (single power supply) System power: 2669W, 0W (0%) inline, 2296W (86%) total allocated Powered devices: 0 total, 0 Class3, 0 Class2, 0 Class1, 0 Class0, 0 Cisco Flash/NVRAM Resources Usage: Module Device Bytes: Total Used %Used 1 dfc#1-bootflash: 15990784 0 0% 2 dfc#2-bootflash: 15990784 0 0% 3 dfc#3-bootflash: 15990784 0 0% 4 dfc#4-bootflash: 15990784 0 0% 6 SP sup-bootdisk: 518799360 184254464 36% 6 SP const_nvram: 127212 556 1% 6 SP hidden-nvram: 4059328 59112 1% 6 RP nvram: 4059328 59112 1% 6 RP bootdisk: 518799360 150863872 29% CPU Resources CPU utilization: Module 5 seconds 1 minute 5 minutes 1 5% / 1% 5% 5% 2 0% / 0% 0% 0% 3 3% / 0% 5% 5% 4 5% / 1% 4% 5% 6 RP 26% / 1% 8% 8% 6 SP 14% / 0% 13% 14% Processor memory: Module Bytes: Total Used %Used 1 998252464 383355628 38% 2 192946224 53267148 28% 3 998252464 386993508 39% 4 998252464 386861032 39% 6 RP 1692217932 1112518116 66% 6 SP 719286476 378783840 53% I/O memory: Module Bytes: Total Used %Used 6 RP 134217728 50322424 37% 6 SP 67108864 43819112 65% EOBC Resources Module Packets/sec Total packets Dropped packets 1 Rx: 26 614046082 0 Tx: 19 86389991 0 2 Rx: 9 613936807 51 Tx: 3 18494162 0 3 Rx: 31 613605105 0 Tx: 25 95659511 0 4 Rx: 31 613518524 0 Tx: 24 99742985 0 6 RP Rx: 31 149075294 0 Tx: 33 154029051 0 6 SP Rx: 45 228362836 0 Tx: 49 246824341 0 VLAN Resources VLANs: 4094 total, 5 VTP, 0 extended, 44 internal, 4045 free L2 Forwarding Resources MAC Table usage: Module Collisions Total Used %Used 1 0 98304 22 1% 3 0 98304 22 1% 4 0 98304 22 1% 6 0 98304 22 1% VPN CAM usage: Total Used %Used 512 0 0% L3 Forwarding Resources Module FIB TCAM usage: Total Used %Used 1 72 bits (IPv4, MPLS, EoM) 835584 669790 80% 144 bits (IP mcast, IPv6) 106496 2647 2% detail: Protocol Used %Used IPv4 667737 80% MPLS 2053 1% EoM 0 0% IPv6 2331 2% IPv4 mcast 258 1% IPv6 mcast 58 1% Adjacency usage: Total Used %Used 1048576 909 1% L3 Forwarding Resources Module FIB TCAM usage: Total Used %Used 3 72 bits (IPv4, MPLS, EoM) 835584 669790 80% 144 bits (IP mcast, IPv6) 106496 2647 2% detail: Protocol Used %Used IPv4 667737 80% MPLS 2053 1% EoM 0 0% IPv6 2331 2% IPv4 mcast 258 1% IPv6 mcast 58 1% Adjacency usage: Total Used %Used 1048576 909 1% L3 Forwarding Resources Module FIB TCAM usage: Total Used %Used 4 72 bits (IPv4, MPLS, EoM) 835584 669790 80% 144 bits (IP mcast, IPv6) 106496 2647 2% detail: Protocol Used %Used IPv4 667737 80% MPLS 2053 1% EoM 0 0% IPv6 2331 2% IPv4 mcast 258 1% IPv6 mcast 58 1% Adjacency usage: Total Used %Used 1048576 909 1% L3 Forwarding Resources Module FIB TCAM usage: Total Used %Used 6 72 bits (IPv4, MPLS, EoM) 835584 669790 80% 144 bits (IP mcast, IPv6) 106496 2647 2% detail: Protocol Used %Used IPv4 667737 80% MPLS 2053 1% EoM 0 0% IPv6 2331 2% IPv4 mcast 258 1% IPv6 mcast 58 1% Adjacency usage: Total Used %Used 1048576 912 1% Forwarding engine load: Module pps peak-pps peak-time 1 0 8710 11:09:19 MSK Mon Oct 16 2017 3 1608918 4252040 14:47:46 MSK Wed Nov 1 2017 4 1170256 3509004 22:22:07 MSK Sun Oct 29 2017 6 88263 162224 13:20:47 MSK Thu Oct 26 2017 Netflow Resources TCAM utilization: Module Created Failed %Used 1 0 0 0% 3 3 0 0% 4 3 0 0% 6 1 0 0% ICAM utilization: Module Created Failed %Used 1 0 0 0% 3 0 0 0% 4 0 0 0% 6 0 0 0% Flowmasks: Mask# Type Features IPv4: 0 reserved none IPv4: 1 unused none IPv4: 2 unused none IPv4: 3 reserved none IPv6: 0 reserved none IPv6: 1 unused none IPv6: 2 unused none IPv6: 3 reserved none CPU Rate Limiters Resources Rate limiters: Total Used Reserved %Used Layer 3 9 6 1 67% Layer 2 4 2 2 50% ACL/QoS TCAM Resources Key: ACLent - ACL TCAM entries, ACLmsk - ACL TCAM masks, AND - ANDOR, QoSent - QoS TCAM entries, QOSmsk - QoS TCAM masks, OR - ORAND, Lbl-in - ingress label, Lbl-eg - egress label, LOUsrc - LOU source, LOUdst - LOU destination, ADJ - ACL adjacency Module ACLent ACLmsk QoSent QoSmsk Lbl-in Lbl-eg LOUsrc LOUdst AND OR ADJ 1 1% 1% 1% 1% 1% 1% 0% 3% 0% 0% 1% 3 1% 1% 1% 1% 1% 1% 0% 3% 0% 0% 1% 4 1% 1% 1% 1% 1% 1% 0% 3% 0% 0% 1% 6 1% 1% 1% 1% 1% 1% 0% 3% 0% 0% 1% L3 Multicast Resources Replication mode: Egress Replication capability: Module Mode 1 Egress 2 Egress 3 Egress 4 Egress 6 Egress MET table Entries: Module Total Used %Used 1 65526 8 1% 3 65526 12 1% 4 65526 12 1% 6 32752 10 1% QoS Policer Resources Aggregate policers: Module Total Used %Used 1 1024 1 1% 3 1024 1 1% 4 1024 1 1% 6 1024 1 1% Microflow policer configurations: Module Total Used %Used 1 64 1 1% 3 64 1 1% 4 64 1 1% 6 64 1 1% Switch Fabric Resources Bus utilization: current: 0%, peak was 0% at 08:53:09 MSK Thu Nov 2 2017 Fabric utilization: Ingress Egress Module Chanl Speed rate peak rate peak 1 0 20G 0% 1% @12:41 18Sep17 0% 1% @06:55 02Nov17 2 0 20G 0% 1% @14:24 18Oct17 0% 1% @02:14 02Nov17 2 1 20G 0% 1% @09:44 29Oct17 0% 1% @02:14 02Nov17 3 0 20G 21% 75% @23:49 01Nov17 25% 65% @23:42 01Nov17 3 1 20G 26% 70% @22:36 31Oct17 26% 69% @21:00 29Oct17 4 0 20G 11% 68% @22:17 18Oct17 21% 60% @23:37 30Oct17 4 1 20G 23% 71% @23:49 01Nov17 19% 66% @22:44 29Oct17 6 0 20G 2% 7% @13:20 26Oct17 0% 5% @13:20 26Oct17 Switching mode: Module Switching mode 1 compact 2 compact 3 compact 4 compact 6 compact Interface Resources Interface drops: Module Total drops: Tx Rx Highest drop port: Tx Rx 3 0 4945385 0 5 4 0 4474 0 5 6 0 3 0 1 Interface buffer sizes: Module Bytes: Tx buffer Rx buffer 1 1221120 174016 2 14622592 1914304 3 91889216 109296640 4 91889216 109296640 IBC Resources Module Packets/sec Total packets Dropped packets 6 RP Rx: 381 645164989 159 Tx: 62 98774646 0 6 SP Rx: 7 31573573 9 Tx: 51 80682253 0 SPAN Resources Source sessions: 18 maximum, 0 used Type Used Local 0 RSPAN source (max 2) 0 ERSPAN source 0 Service module 0 Destination sessions: 62 maximum, 0 used Type Used RSPAN destination 0 ERSPAN destination (max 24) 0 m9-co-asbr2#show fabric utilization all slot channel speed Ingress % Egress % 1 0 20G 0 0 2 0 20G 0 0 2 1 20G 0 0 3 0 20G 21 21 3 1 20G 21 21 4 0 20G 8 18 4 1 20G 20 20 6 0 20G 2 0 m9-co-asbr2#show fabric switching-mode Global switching mode is Compact dCEF mode is not enforced for system to operate Fabric module is not required for system to operate Modules are allowed to operate in bus mode Truncated mode is allowed, due to presence of DFC, CEF720 module Module Slot Switching Mode 1 dCEF 2 Crossbar 3 dCEF 4 dCEF 6 dCEF m9-co-asbr2#show fabric channel-counters all slot channel rxErrors txErrors txDrops lbusDrops 1 0 0 0 0 0 2 0 0 0 0 0 2 1 0 0 0 0 3 0 0 0 0 0 3 1 0 0 0 0 4 0 0 0 0 0 4 1 0 0 0 0 6 0 3 0 0 0 m9-co-asbr2#show inventory NAME: "CISCO7606", DESCR: "Cisco Systems Cisco 7600 6-slot Chassis System" PID: CISCO7606 , VID: , SN: FOX11100SP1 NAME: "CLK-7600 1", DESCR: "OSR-7600 Clock FRU 1" PID: CLK-7600 , VID: , SN: NWG110701EP NAME: "CLK-7600 2", DESCR: "OSR-7600 Clock FRU 2" PID: CLK-7600 , VID: , SN: NWG110701EP NAME: "module 1", DESCR: "WS-X6724-SFP CEF720 24 port 1000mb SFP Rev. 4.3" PID: WS-X6724-SFP , VID: V06, SN: SAL1406AFD4 NAME: "switching engine sub-module of 1", DESCR: "WS-F6700-DFC3CXL Distributed Forwarding Card 3 Rev. 1.6" PID: WS-F6700-DFC3CXL , VID: V03, SN: SAL1414EFLN NAME: "module 2", DESCR: "WS-X6704-10GE CEF720 4 port 10-Gigabit Ethernet Rev. 2.5" PID: WS-X6704-10GE , VID: V02, SN: SAL1109J94E NAME: "switching engine sub-module of 2", DESCR: "WS-F6700-CFC Centralized Forwarding Card Rev. 3.1" PID: WS-F6700-CFC , VID: V04, SN: SAL1109J8WE NAME: "module 3", DESCR: "WS-X6708-10GE CEF720 8 port 10GE with DFC Rev. 3.5" PID: WS-X6708-10GE , VID: V11, SN: SAL16084SPD NAME: "switching engine sub-module of 3", DESCR: "WS-F6700-DFC3CXL Distributed Forwarding Card 3 Rev. 1.1" PID: WS-F6700-DFC3CXL , VID: V01, SN: SAL12437BCP NAME: "Transceiver Te3/1", DESCR: "Transceiver 10Gbase-LR Te3/1" PID: X2 to SFP+ , VID: V02 , SN: X2C4Q550004 NAME: "Transceiver Te3/2", DESCR: "Transceiver 10Gbase-LR Te3/2" PID: X2-10GB-LR , VID: V02 , SN: X2FB4610039 NAME: "Transceiver Te3/3", DESCR: "Transceiver 10Gbase-LR Te3/3" PID: X2-10GB-LR , VID: V02 , SN: X2FB4610010 NAME: "Transceiver Te3/4", DESCR: "Transceiver 10Gbase-LR Te3/4" PID: X2-10GB-LR , VID: V02 , SN: X2FB4610002 NAME: "Transceiver Te3/5", DESCR: "Transceiver 10Gbase-LR Te3/5" PID: X2-10GB-LR , VID: V03 , SN: XX96L013 NAME: "Transceiver Te3/6", DESCR: "Transceiver 10Gbase-LR Te3/6" PID: MT-X2-31192-LRC , VID: V01 , SN: S1211280511 NAME: "Transceiver Te3/7", DESCR: "Transceiver 10Gbase-LR Te3/7" PID: MT-X2-31192-LRC , VID: V01 , SN: S1211280547 NAME: "module 4", DESCR: "WS-X6708-10GE CEF720 8 port 10GE with DFC Rev. 1.6" PID: WS-X6708-10GE , VID: V06, SN: SAL1310LEU0 NAME: "switching engine sub-module of 4", DESCR: "WS-F6700-DFC3CXL Distributed Forwarding Card 3 Rev. 1.3" PID: WS-F6700-DFC3CXL , VID: V02, SN: SAL1311LRK6 NAME: "Transceiver Te4/1", DESCR: "Transceiver 10Gbase-LR Te4/1" PID: MT-X2-31192-LRC , VID: V01 , SN: S1211280539 NAME: "Transceiver Te4/3", DESCR: "Transceiver 10Gbase-LR Te4/3" PID: X2-10GB-LR , VID: V03 , SN: XX96L006 NAME: "Transceiver Te4/4", DESCR: "Transceiver 10Gbase-LR Te4/4" PID: X2-10GB-LR , VID: V03 , SN: XX96L007 NAME: "Transceiver Te4/5", DESCR: "Transceiver 10Gbase-LR Te4/5" PID: X2-10GB-LR , VID: V03 , SN: XX96L012 NAME: "Transceiver Te4/6", DESCR: "Transceiver 10Gbase-LR Te4/6" PID: X2-10GB-LR , VID: V03 , SN: XX96L003 NAME: "Transceiver Te4/7", DESCR: "Transceiver 10Gbase-LR Te4/7" PID: MT-X2-31192-LRC , VID: V01 , SN: S1211280546 NAME: "module 6", DESCR: "RSP720-3CXL-GE 2 ports Route Switch Processor 720 Rev. 5.6" PID: RSP720-3CXL-GE , VID: V04, SN: JAE1232RB9D NAME: "msfc sub-module of 6", DESCR: "7600-MSFC4 C7600 MSFC4 Daughterboard Rev. 1.1" PID: 7600-MSFC4 , VID: 000, SN: JAE1232RBF8 NAME: "switching engine sub-module of 6", DESCR: "7600-PFC3CXL Policy Feature Card 3 Rev. 1.0" PID: 7600-PFC3CXL , VID: 000, SN: JAE1232R5MX NAME: "Transceiver Gi6/1", DESCR: "Transceiver 1000BaseBX10D Gi6/1" PID: , VID: A , SN: FP201301288002 NAME: "PS 2 PWR-2700-AC", DESCR: "AC power supply, 2700 watt 2" PID: PWR-2700-AC , VID: V02, SN: APQ10330015

А чем же пользуются все магистралы, которые видят куда льется трафик той или иной AS?

Установил leftsubnet ту сеть, которая connected на сервере IPSec. Заработало. Тоесть я пингую с локального адреса хост по ту сторону туннель и он доступен. Но теперь задача занатить входящий трафик с моей стороны в этот адрес. -A POSTROUTING -d 2.2.2.2/32 -o eth1 -j SNAT --to-source 1.1.1.1 Но трафик не натится, соответственно не попадает в туннель

Туннель поднимается, но трафик в него не уходит, прошу подтолкнуть в чем дело: Моя сеть 1.1.1.1/32, внешний сервер на котором ipsec 55.55.55.55. Сервер через свой шлюз имеет связность с моей сетью. Не понятно как дать маршрут, что б трафик начал ходить в тунель, он приходит на сервер и возвращается на свой шлюз по умолчанию. Centos 7 ip ro default via 55.55.55.1 dev eth1 proto static metric 100 55.55.55.1/25 dev eth1 proto kernel scope link src 55.55.55.55 metric 100 net.ipv4.ip_forward = 1 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.send_redirects = 0 net.ipv4.ip_no_pmtu_disc = 1 /etc/strongswan/ipsec.conf config setup charondebug="ike 4, knl 4, cfg 2" #useful debugs conn 111 authby=secret # # Auth with PSK ( preshared key ) left=55.55.55.55 leftsubnet=1.1.1.1/32 right=77.77.77.77 rightsubnet=2.2.2.2/32 auto=start ikelifetime=86400s lifetime=3600s leftauth=psk rightauth=psk keyexchange=ikev1 ike=aes256-sha1-modp1024! esp=aes256-sha1-modp1024! charon.conf charon { load = curl test-vectors aes des sha1 sha2 md5 pem pkcs1 gmp random x509 revocation hmac xcbc cmac ctr ccm gcm stroke kernel-netlink socket-default updown eap-identity crypto_test { } host_resolver { } leak_detective { } processor { priority_threads { } } start-scripts {} stop-scripts {} tls {} 509 {} } sudo strongswan statusall Status of IKE charon daemon (strongSwan 5.5.3, Linux 4.4.14, x86_64): uptime: 47 minutes, since Sep 28 14:35:25 2017 malloc: sbrk 1609728, mmap 0, used 514096, free 1095632 worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 2 loaded plugins: charon acert attr constraints curl curve25519 dhcp dnskey eap-gtc eap-md5 eap-mschapv2 eap-peap eap-tls eap-ttls farp fips-prf gcrypt md4 nonce openssl pgp pkcs12 pkcs8 pubkey rc2 resolve sshkey unity vici xauth-eap xauth-generic xauth-noauth xauth-pam aes des sha1 sha2 md5 pem pkcs1 gmp random x509 revocation hmac xcbc cmac ctr ccm gcm stroke kernel-netlink socket-default updown eap-identity Listening IP addresses: 55.55.55.55 Connections: tele2: 55.55.55.55...77.77.77.77 IKEv1 tele2: local: [55.55.55.55] uses pre-shared key authentication tele2: remote: [77.77.77.77] uses pre-shared key authentication tele2: child: 1.1.1.1/32 === 2.2.2.2/32 TUNNEL Security Associations (1 up, 0 connecting): tele2[1]: ESTABLISHED 47 minutes ago, 55.55.55.55[55.55.55.55]...77.77.77.77[77.77.77.77] tele2[1]: IKEv1 SPIs: 5682a023bef3ac6d_i* 6045e8c8a9beeeb8_r, pre-shared key reauthentication in 22 hours tele2[1]: IKE proposal: AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024 tele2{2}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: cc6da7f7_i 72113648_o tele2{2}: AES_CBC_256/HMAC_SHA1_96/MODP_1024, 3360 bytes_i (56 pkts, 3s ago), 3360 bytes_o (56 pkts, 3s ago), rekeying in 41 minutes tele2{2}: 1.1.1.1/32 === 2.2.2.2/32 sudo ip xfrm policy src 55.55.55.55/32 dst 2.2.2.2/32 dir out priority 367231 ptype main tmpl src 55.55.55.55 dst 194.176.96.4 proto esp reqid 1 mode tunnel src 2.2.2.2/32 dst 1.1.1.1/32 dir fwd priority 367231 ptype main tmpl src 77.77.77.77 dst 55.55.55.55 proto esp reqid 1 mode tunnel src 2.2.2.2/32 dst 1.1.1.1/32 dir in priority 367231 ptype main tmpl src 77.77.77.77 dst 55.55.55.55 proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket in priority 0 ptype main src 0.0.0.0/0 dst 0.0.0.0/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main src ::/0 dst ::/0 socket in priority 0 ptype main src ::/0 dst ::/0 socket out priority 0 ptype main ip route show table 220 ..