Перейти к содержимому
Калькуляторы

динамическая маршрутизация(ospf, rip?)

Приветствую всех участников этого форума.

Вопрос по динамической маршрутизации.

Схема очень простая. Есть с десяток роутеров разбросанных по миру. Между роутерами туннели.

Сейчас все на статике сделано.

Пару лет назад пробовал запустить на кваге ospf. И все как бы работало но временами некоторые маршруты просто пропадали с таблицы роутинга. Причем перезапуск кваги руками помогал(маршрут исправно появлялся в таблице роутинга).

Проявлялось это эпизодически и не везде. Я для себя тогда решил что так как каналы между роутерами не идеальны и могут терять, бить, дупить пакеты ospf протокола то при определенных условиях пакет теряется и маршрут до кваги не доходит.

Конечно в самом ospf протоколе есть борьба с ошибками и потерями но видимо она как то не всегда отрабатывала.

 

Посему вопрос к уважаемому сообществу! Как сейчас обстоят дела с квагой и ospf-ом на ней?

Понятно что если два роутера объединены оптикой и на ней никогда не бывает потерь то вы можете такой проблемы и не поймать никогда. Меня интересует именно мнение людей которые гоняют ospf через интернет(туннели) или через каналы с потерями.

 

Так же интересно как обстоят дела у bird-а c ospf-ом и эпизодическими потерями маршрутов.

 

Жду ваших ответов. Спасибо!

Изменено пользователем adron2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Потери маршрутов в ospf обычно не связанны с кваггой или бёрдом, а с неверностью таймеров и/или очень плохими каналами/впн. (это не считая конечно тупо ошибок конфигурации) Но решения на оспф живут, вполне даже, хоть он и капризный.

Вообще можете попробовать bgp + bfd over vpn, такое тоже живет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Делайте более агрессивные настройки vpn туннелей, например тип тунелей tcp и тайминги-проверки пингом 10с

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так же интересно как обстоят дела у bird-а c ospf-ом и эпизодическими потерями маршрутов.

Жду ваших ответов. Спасибо!

bird, обменивается с парой dlink-ов парой сотен маршрутов уже с годик, глюков не замечено.

Другой вопрос, что у вас все это хозяйство в туннеле.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Присоединяюсь к предыдущему посту , потери не связаны с непосредственно квагой (хотя баги не исключаю), У нас работает ospf на нескольких туннелях , без каких либо замечаний за последние 2 года.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Потери маршрутов в ospf обычно не связанны с кваггой или бёрдом, а с неверностью таймеров и/или очень плохими каналами/впн. (это не считая конечно тупо ошибок конфигурации) Но решения на оспф живут, вполне даже, хоть он и капризный.

Вообще можете попробовать bgp + bfd over vpn, такое тоже живет.

 

То есть получается что ospf и каналы с потерями - гарантированные глюки?

Про бгп я думал...но как то не хочется из пушки по воробьям :-)

 

Делайте более агрессивные настройки vpn туннелей, например тип тунелей tcp и тайминги-проверки пингом 10с

 

Туннели ходят по udp и иногда по icmp. tcp в этом случае никак.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

То есть получается что ospf и каналы с потерями - гарантированные глюки?

Про бгп я думал...но как то не хочется из пушки по воробьям :-)

 

 

Не совсем, но плохие каналы конечно мешают оспф. Другое дело что стандартные таймеры в оспф не очень адекватны на длинных и болезных линках, это надо учитывать.

А бгп оно уникаст и точка-точка, я бы не стал считать его пушкой, вполне та же универсальная рогатка. В плане того что "писироутеру" пофигу, его цпу не заметит разницы.

 

Туннели ходят по udp и иногда по icmp. tcp в этом случае никак.

 

 

И зря, я бы на вашем месте задумался все же о tcp.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

То есть получается что ospf и каналы с потерями - гарантированные глюки?

Про бгп я думал...но как то не хочется из пушки по воробьям :-)

 

 

Не совсем, но плохие каналы конечно мешают оспф. Другое дело что стандартные таймеры в оспф не очень адекватны на длинных и болезных линках, это надо учитывать.

А бгп оно уникаст и точка-точка, я бы не стал считать его пушкой, вполне та же универсальная рогатка. В плане того что "писироутеру" пофигу, его цпу не заметит разницы.

 

Туннели ходят по udp и иногда по icmp. tcp в этом случае никак.

 

 

И зря, я бы на вашем месте задумался все же о tcp.

 

Спасибо вам за ответ. Значит буду пробовать iBGP. как я понимаю оно tcp и потери ему не страшны.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо вам за ответ. Значит буду пробовать iBGP. как я понимаю оно tcp и потери ему не страшны.

 

 

Ну с одной стороны да, tcp овер udp немного живее будет чем ospf over udp. Но основная мысль была всё же в том чтобы делать сами тунели tcp, хоть через ssh, главное чтобы обеспечить прозрачные передачи/повторы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо вам за ответ. Значит буду пробовать iBGP. как я понимаю оно tcp и потери ему не страшны.

 

 

Ну с одной стороны да, tcp овер udp немного живее будет чем ospf over udp. Но основная мысль была всё же в том чтобы делать сами тунели tcp, хоть через ssh, главное чтобы обеспечить прозрачные передачи/повторы.

 

правильно ли я понимаю что вы предлагаете мне поднять скажем vtun tcp туннели и по ним гонять чисто служебный ospf трафик?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

adron2

А я не согласен с остальными.

Стабильные потери маршрутов(квагга тупо не анонсирует несколько штук и все, помогает только рестарт сервиса) это древний баг самой квагги, и эта баговая версия например в стандартной репе центоса 5 и 6 живет. По крайней мере год назад было так, долго отлавливал точно такие же чудеса. Причем поведение было точно таким же и для RIP.

Надо кваггу собирать руками свежую и все пройдет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

adron2

А я не согласен с остальными.

Стабильные потери маршрутов(квагга тупо не анонсирует несколько штук и все, помогает только рестарт сервиса) это древний баг самой квагги, и эта баговая версия например в стандартной репе центоса 5 и 6 живет. По крайней мере год назад было так, долго отлавливал точно такие же чудеса. Причем поведение было точно таким же и для RIP.

Надо кваггу собирать руками свежую и все пройдет.

 

Вы правы. Я ловил точно такой же глюк на ospf и на rip кваги! И в этой теме я как раз и пытаюсь выяснить полечился ли этот баг в последней версии кваги(0.99.23)? или все же делать маршрутизацию на iBGP?

 

Просто судя по гуглу этот баг тянется в кваге аж с 2002 года!

Изменено пользователем adron2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну дык попробуйте bird, в чем сложность-то?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

adron2

Где-то около 0.99.20 починили, не помню точно. Сборка свежей версии год назад у нас проблему вроде решила.

 

p.s. посмотрел по серверам - на центосе с родным 0.99.15 глючит, на федоре с 0.99.17 уже глюка нет.

Изменено пользователем kayot

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

adron2

Где-то около 0.99.20 починили, не помню точно. Сборка свежей версии год назад у нас проблему вроде решила.

 

p.s. посмотрел по серверам - на центосе с родным 0.99.15 глючит, на федоре с 0.99.17 уже глюка нет.

 

Странно. Но два года назад я как раз на 0.99.17 и ловил этот глюк.

Наверное в федоре уже патченая версия.

В любом случае буду на 0.99.23 пробовать и если что вылезет - отпишусь.

Всем спасибо.

Изменено пользователем adron2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати, о птицах... У кого-то живет bird с uClibc? Последнияя птичка при попытке скормить ей пару IX по бгп (по 15к маршрутов) + эдак пару тысяч маршрутов по оспф, с немного замысловатым конфигом (который в будущем разростется в vrf), падает... Хотя на тестовой машине по iBGP получает нормально маршруты (но изредка при реконфигурации тоже падает). Отключение потоков не помогло.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поковырял сегодня немного кваговский ospf. На стенде вроде работает.

Вылезла проблема с фильтрацией отдаваемых маршрутов.

если сделать вот так:

redistribute kernel route-map TO-OSPF
redistribute connected route-map TO-OSPF
redistribute static route-map TO-OSPF
...
ip prefix-list ospf-new seq 10 permit 192.168.77.0/24 le 32
ip prefix-list ospf-new seq 20 permit 192.168.90.0/23 le 32
ip prefix-list ospf-new seq 30 permit 10.80.0.0/16 le 32
ip prefix-list ospf-new seq 40 deny any

то оно работает. но например при добавлении в prefix-list ospf-new еще:

ip prefix-list ospf-new seq 35 permit 192.168.200.0/24 le 32

подсеть 192.168.200.0/24 не всегда начинает анонсироваться пирам. помогает только рестарт кваги.

это очередной баг или квагу можно как то пнуть чтобы она это поняла?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

подсеть 192.168.200.0/24 не всегда начинает анонсироваться пирам. помогает только рестарт кваги.

А софт реконфигурация не помогает?

 

Ну и да, о птицах: решил свою птичку пропустить через valgrind - итог несколько опечалил:

 

# valgrind --tool=memcheck --track-origins=yes ./bird -d
==12995== Memcheck, a memory error detector
==12995== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==12995== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==12995== Command: ./bird -d
==12995==
==12995== Syscall param socketcall.sendto(msg) points to uninitialised byte(s)
==12995==    at 0x402AA6B: __socketcall (in /lib/libuClibc-0.9.33.2.so)
==12995==    by 0x40864F4: sendto (socketcalls.c:520)
==12995==    by 0x8075539: nl_send (netlink.c:92)
==12995==    by 0x8075584: nl_request_dump (netlink.c:110)
==12995==    by 0x8076498: kif_do_scan (netlink.c:566)
==12995==    by 0x8072A3C: kif_start (krt.c:191)
==12995==    by 0x804F5DC: proto_rethink_goal (proto.c:641)
==12995==    by 0x804F8E6: protos_commit (proto.c:580)
==12995==    by 0x807003F: config_do_commit (conf.c:255)
==12995==    by 0x80701D9: config_commit (conf.c:348)
==12995==    by 0x8049DD7: main (main.c:814)
==12995==  Address 0xaebb8a4d is on thread 1's stack
==12995==  in frame #3, created by nl_request_dump (netlink.c:99)
==12995==  Uninitialised value was created by a stack allocation
==12995==    at 0x8075560: nl_request_dump (netlink.c:99)
==12995==
==12995== Syscall param socketcall.setsockopt(optval) points to uninitialised byte(s)
==12995==    at 0x402AA6B: __socketcall (in /lib/libuClibc-0.9.33.2.so)
==12995==    by 0x4086558: setsockopt (socketcalls.c:549)
==12995==    by 0x8070CCD: sk_setup (io.c:1156)
==12995==    by 0x8071B8F: sk_open (io.c:1358)
==12995==    by 0x806153F: ospf_sk_open (iface.c:111)
==12995==    by 0x806153F: ospf_iface_add (iface.c:470)
==12995==    by 0x8051A55: olock_run_event (locks.c:175)
==12995==    by 0x80708D1: ev_run_list (event.c:135)
==12995==    by 0x80722E6: io_loop (io.c:1848)
==12995==    by 0x8049DED: main (main.c:825)
==12995==  Address 0xaebb88f6 is on thread 1's stack
==12995==  in frame #2, created by sk_setup (io.c:1128)
==12995==  Uninitialised value was created by a stack allocation
==12995==    at 0x8070C58: sk_setup (io.c:1132)
==12995==
==12995== Syscall param sendmsg(msg.msg_name) points to uninitialised byte(s)
==12995==    at 0x402AA6B: __socketcall (in /lib/libuClibc-0.9.33.2.so)
==12995==    by 0x4086470: sendmsg (socketcalls.c:472)
==12995==    by 0x80713BF: sk_sendmsg (io.c:1523)
==12995==    by 0x80713BF: sk_maybe_write (io.c:1602)
==12995==    by 0x805FCF4: ospf_send_to (packet.c:565)
==12995==    by 0x805FFD9: ospf_hello_send (hello.c:364)
==12995==    by 0x80610E0: ospf_iface_sm (iface.c:385)
==12995==    by 0x80616A1: ospf_iface_add (iface.c:489)
==12995==    by 0x8051A55: olock_run_event (locks.c:175)
==12995==    by 0x80708D1: ev_run_list (event.c:135)
==12995==    by 0x80722E6: io_loop (io.c:1848)
==12995==    by 0x8049DED: main (main.c:825)
==12995==  Address 0xaebb8810 is on thread 1's stack
==12995==  in frame #2, created by sk_maybe_write (io.c:1568)
==12995==  Uninitialised value was created by a stack allocation
==12995==    at 0x8071280: sk_maybe_write (io.c:1568)
==12995==
==12995== Invalid write of size 1
==12995==    at 0x8059002: bgp_new_bucket (attrs.c:754)
==12995==    by 0x8059002: bgp_get_bucket (attrs.c:861)
==12995==    by 0x8059B0E: bgp_rt_notify (attrs.c:939)
==12995==    by 0x804A55E: do_rt_notify (rt-table.c:346)
==12995==    by 0x804AB62: rt_notify_basic (rt-table.c:393)
==12995==    by 0x804C53C: do_feed_baby (rt-table.c:1776)
==12995==    by 0x804C53C: rt_feed_baby (rt-table.c:1827)
==12995==    by 0x804E87B: proto_feed_more (proto.c:940)
==12995==    by 0x80708D1: ev_run_list (event.c:135)
==12995==    by 0x80722E6: io_loop (io.c:1848)
==12995==    by 0x8049DED: main (main.c:825)
==12995==  Address 0x419c530 is 0 bytes after a block of size 168 alloc'd
==12995==    at 0x400F14D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==12995==    by 0x80777F7: bird_xmalloc (xmalloc.c:29)
==12995==    by 0x807724E: mb_alloc (resource.c:339)
==12995==    by 0x8058F74: bgp_new_bucket (attrs.c:734)
==12995==    by 0x8058F74: bgp_get_bucket (attrs.c:861)
==12995==    by 0x8059B0E: bgp_rt_notify (attrs.c:939)
==12995==    by 0x804A55E: do_rt_notify (rt-table.c:346)
==12995==    by 0x804AB62: rt_notify_basic (rt-table.c:393)
==12995==    by 0x804C53C: do_feed_baby (rt-table.c:1776)
==12995==    by 0x804C53C: rt_feed_baby (rt-table.c:1827)
==12995==    by 0x804E87B: proto_feed_more (proto.c:940)
==12995==    by 0x80708D1: ev_run_list (event.c:135)
==12995==    by 0x80722E6: io_loop (io.c:1848)
==12995==    by 0x8049DED: main (main.c:825)
==12995==
==12995== Invalid read of size 1
==12995==    at 0x40135F7: bcmp (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==12995==    by 0x804D57A: adata_same (route.h:441)
==12995==    by 0x804D57A: ea_same (rt-attr.c:503)
==12995==    by 0x8058E6E: bgp_get_bucket (attrs.c:837)
==12995==    by 0x8059B0E: bgp_rt_notify (attrs.c:939)
==12995==    by 0x804A55E: do_rt_notify (rt-table.c:346)
==12995==    by 0x804AB62: rt_notify_basic (rt-table.c:393)
==12995==    by 0x804C53C: do_feed_baby (rt-table.c:1776)
==12995==    by 0x804C53C: rt_feed_baby (rt-table.c:1827)
==12995==    by 0x804E87B: proto_feed_more (proto.c:940)
==12995==    by 0x80708D1: ev_run_list (event.c:135)
==12995==    by 0x80722E6: io_loop (io.c:1848)
==12995==    by 0x8049DED: main (main.c:825)
==12995==  Address 0x419d638 is 0 bytes after a block of size 168 alloc'd
==12995==    at 0x400F14D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==12995==    by 0x80777F7: bird_xmalloc (xmalloc.c:29)
==12995==    by 0x807724E: mb_alloc (resource.c:339)
==12995==    by 0x8058F74: bgp_new_bucket (attrs.c:734)
==12995==    by 0x8058F74: bgp_get_bucket (attrs.c:861)
==12995==    by 0x8059B0E: bgp_rt_notify (attrs.c:939)
==12995==    by 0x804A55E: do_rt_notify (rt-table.c:346)
==12995==    by 0x804AB62: rt_notify_basic (rt-table.c:393)
==12995==    by 0x804C53C: do_feed_baby (rt-table.c:1776)
==12995==    by 0x804C53C: rt_feed_baby (rt-table.c:1827)
==12995==    by 0x804E87B: proto_feed_more (proto.c:940)
==12995==    by 0x80708D1: ev_run_list (event.c:135)
==12995==    by 0x80722E6: io_loop (io.c:1848)
==12995==    by 0x8049DED: main (main.c:825)
==12995==
==12995== Invalid read of size 4
==12995==    at 0x805993C: bgp_encode_attrs (attrs.c:607)
==12995==    by 0x805B28D: bgp_create_update (packets.c:356)
==12995==    by 0x805B28D: bgp_fire_tx (packets.c:671)
==12995==    by 0x805B4BB: bgp_kick_tx (packets.c:714)
==12995==    by 0x80708D1: ev_run_list (event.c:135)
==12995==    by 0x80722E6: io_loop (io.c:1848)
==12995==    by 0x8049DED: main (main.c:825)
==12995==  Address 0x419c530 is 0 bytes after a block of size 168 alloc'd
==12995==    at 0x400F14D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==12995==    by 0x80777F7: bird_xmalloc (xmalloc.c:29)
==12995==    by 0x807724E: mb_alloc (resource.c:339)
==12995==    by 0x8058F74: bgp_new_bucket (attrs.c:734)
==12995==    by 0x8058F74: bgp_get_bucket (attrs.c:861)
==12995==    by 0x8059B0E: bgp_rt_notify (attrs.c:939)
==12995==    by 0x804A55E: do_rt_notify (rt-table.c:346)
==12995==    by 0x804AB62: rt_notify_basic (rt-table.c:393)
==12995==    by 0x804C53C: do_feed_baby (rt-table.c:1776)
==12995==    by 0x804C53C: rt_feed_baby (rt-table.c:1827)
==12995==    by 0x804E87B: proto_feed_more (proto.c:940)
==12995==    by 0x80708D1: ev_run_list (event.c:135)
==12995==    by 0x80722E6: io_loop (io.c:1848)
==12995==    by 0x8049DED: main (main.c:825)
==12995==
^C./bird: can't resolve symbol '__libc_freeres' in lib '/usr/lib/valgrind/vgpreload_core-x86-linux.so'.
==12995==
==12995== HEAP SUMMARY:
==12995==     in use at exit: 5,819,481 bytes in 30,235 blocks
==12995==   total heap usage: 126,286 allocs, 96,051 frees, 22,617,323 bytes allocated
==12995==
==12995== LEAK SUMMARY:
==12995==    definitely lost: 0 bytes in 0 blocks
==12995==    indirectly lost: 0 bytes in 0 blocks
==12995==      possibly lost: 0 bytes in 0 blocks
==12995==    still reachable: 5,819,481 bytes in 30,235 blocks
==12995==         suppressed: 0 bytes in 0 blocks
==12995== Rerun with --leak-check=full to see details of leaked memory
==12995==
==12995== For counts of detected and suppressed errors, rerun with: -v
==12995== ERROR SUMMARY: 1007024 errors from 6 contexts (suppressed: 0 from 0) 

 

3 критичных бага (выход за рамки выделенной в malloc памяти), 3 потенциальных плавающих бага (неинициализированная переменная)

 

Попробовать попатчевать что ли...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Там всего две проблемы - bird сильно студенческая поделка и valgrind/memcheck не особо точный инструмент. В реальности он не показывает никаких достоверных ликов на демонах, ибо они изобилуют переменными не требующими free (т.к. должны жить "до конца"). И вот потом в куче этих пустых сообщений найти настоящий нереально. Выход за границы массива - это его профанация, он его видит даже там где его нет, так он ошибается на pointer ++ / -- операциях. А не инициализированная область где-то на стеке судя по трейсу льется из вашего uClibc? :D

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Выход за пределы массива - похоже вполне реальный. Иначе бы куча не портилась и malloc потом не валился.

 

А неинициализированные переменные - таки не uClibc. Как-то так (патч автора):

 

diff --git a/sysdep/linux/netlink.c b/sysdep/linux/netlink.c
index 132403a..93cbd1e 100644
--- a/sysdep/linux/netlink.c
+++ b/sysdep/linux/netlink.c
@@ -100,7 +100,7 @@ nl_request_dump(int cmd)
  struct {
    struct nlmsghdr nh;
    struct rtgenmsg g;
-  } req;
+  } req = {};
  req.nh.nlmsg_type = cmd;
  req.nh.nlmsg_len = sizeof(req);
  req.nh.nlmsg_flags = NLM_F_REQUEST | NLM_F_DUMP;
diff --git a/sysdep/unix/io.c b/sysdep/unix/io.c
index 164038e..69ac028 100644
--- a/sysdep/unix/io.c
+++ b/sysdep/unix/io.c
@@ -1151,7 +1151,7 @@ sk_setup(sock *s)
  if (s->iface)
  {
#ifdef SO_BINDTODEVICE
-    struct ifreq ifr;
+    struct ifreq ifr = {};
    strcpy(ifr.ifr_name, s->iface->name);
    if (setsockopt(s->fd, SOL_SOCKET, SO_BINDTODEVICE, &ifr, sizeof(ifr)) < 0)
      ERR("SO_BINDTODEVICE");
@@ -1494,7 +1494,7 @@ sk_sendmsg(sock *s)
{
  struct iovec iov = {s->tbuf, s->tpos - s->tbuf};
  byte cmsg_buf[CMSG_TX_SPACE];
-  sockaddr dst;
+  sockaddr dst = {};

  sockaddr_fill(&dst, s->af, s->daddr, s->iface, s->dport);

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Выход за пределы массива - похоже вполне реальный. Иначе бы куча не портилась и malloc потом не валился.

 

 

Ну у меня есть масса примеров, где оно годами работает. Думаю все же дело в uClibc, видимо его поведение не 100%-libc-compatible.

А патч этот из разряда let compiler/debugger be happy, никакой серьезной угрозы там не было, структуры заполнялись данными перед обращением к ним.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Думаю все же дело в uClibc, видимо его поведение не 100%-libc-compatible.

Ну если в glibc за концом лежит что-то не особо нужное, а в uClibc - указатель куда-то, то и получаются грабли...

Хотя тут всплыла грабля с alignment - автор с ним что-то намутил, когда на х86 выровняно по границе 16 байт а не 8 - начинаются внезапные краши.

Вроде как поправлено уже в мастере.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Еще в копилку: птичку таращит, если в качестве OSPF DR квагга 0.9.15 (CentOS 6) (чуть ли не ежеминутно перестраиваются маршруты). А вот с 0.9.22 - все ок.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Микротик с OSPF тоже отлично работает. Если правильно все настроить, то по любым типам туннелей потерь не будет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Микротик с OSPF тоже отлично работает. Если правильно все настроить, то по любым типам туннелей потерь не будет.

 

Микротик уже перестал в произвольные моменты времени терять часть маршрутов по OSPF?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.