Jump to content
Калькуляторы

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

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

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

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

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

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

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

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

 

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

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

 

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

 

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

Edited by adron2

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

 

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

 

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

Share this post


Link to post
Share on other sites

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

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

 

 

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

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

 

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

 

 

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

Share this post


Link to post
Share on other sites

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

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

 

 

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

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

 

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

 

 

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

 

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

Share this post


Link to post
Share on other sites

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

 

 

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

Share this post


Link to post
Share on other sites

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

 

 

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

 

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

Share this post


Link to post
Share on other sites

adron2

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

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

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

Share this post


Link to post
Share on other sites

adron2

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

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

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

 

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

 

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

Edited by adron2

Share this post


Link to post
Share on other sites

adron2

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

 

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

Edited by kayot

Share this post


Link to post
Share on other sites

adron2

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

 

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

 

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

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

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

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

Edited by adron2

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Поковырял сегодня немного кваговский 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 не всегда начинает анонсироваться пирам. помогает только рестарт кваги.

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

Share this post


Link to post
Share on other sites

подсеть 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 потенциальных плавающих бага (неинициализированная переменная)

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Выход за пределы массива - похоже вполне реальный. Иначе бы куча не портилась и 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);

Share this post


Link to post
Share on other sites

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

 

 

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this