[adron2]

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

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

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

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

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

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

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

 

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

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

 

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

 

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

Edited December 9, 2014 by adron2

[DVM-Avgoor]

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

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

[vlad11]

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

[pppoetest]

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

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

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

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

[orlik]

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

[adron2]

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

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

 

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

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

 

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

 

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

[DVM-Avgoor]

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

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

 

 

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

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

 

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

 

 

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

[adron2]

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

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

 

 

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

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

 

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

 

 

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

 

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

[DVM-Avgoor]

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

 

 

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

[adron2]

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

 

 

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

 

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

[kayot]

adron2

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

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

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

[adron2]

adron2

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

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

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

 

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

 

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

Edited December 9, 2014 by adron2

[DVM-Avgoor]

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

[kayot]

adron2

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

 

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

Edited December 9, 2014 by kayot

[adron2]

adron2

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

 

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

 

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

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

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

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

Edited December 9, 2014 by adron2

[NiTr0]

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

[adron2]

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

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

[NiTr0]

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

 

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

[DVM-Avgoor]

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

[NiTr0]

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

[DVM-Avgoor]

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

 

 

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

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

[NiTr0]

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

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

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

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

[NiTr0]

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

[Saab95]

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

[adron2]

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

 

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