Приветствую! Коллеги, пробовал ли кто-то использовать роутинг-демон bird (http://bird.network.cz/)? Задача состоит в том, чтобы оставить в приезжающем префиксе только разрешенные community согласно списка. Поскольку bird не умеет инвертировать списки community (как делает нп. JunOS), то его приходится инвертировать вручную: function check_community () pair set wrong; { wrong = [ (0,0)..(0,25371), (0,25373)..(0,31209), (0,31211)..(31209,65535), (31210,0)..(31210,25371), (31210,25373)..(31210,65535), (31211,0)..(65535,65281), (65535,65283)..(65535,65535) ]; bgp_community.delete(wrong); print bgp_community; } filter flt_itcons_i prefix set plist; { check_community(); plist = [ 91.200.192.0/22, 109.68.40.0/21, ]; if net ~ plist then accept; else reject; } Такую конфигурацию bird принимает, но ругается на строку bgp_community.delete(wrong): Sep 7 13:45:58 crete bird: filters, line 37: Can't add/delete non-pair Кому-то удавалось сделать подобное? Спасибо. -- Kind Regards, Alexander Shikoff AMS1-UANIC
Вопросом на вопрос :)
а вот этот bird - он принципиально чем отличается от квагги?
Спасибо
2010/9/7 Alexander Shikoff
Приветствую!
Коллеги, пробовал ли кто-то использовать роутинг-демон bird ( http://bird.network.cz/)? Задача состоит в том, чтобы оставить в приезжающем префиксе только разрешенные community согласно списка.
Поскольку bird не умеет инвертировать списки community (как делает нп. JunOS), то его приходится инвертировать вручную: function check_community () pair set wrong; { wrong = [ (0,0)..(0,25371), (0,25373)..(0,31209), (0,31211)..(31209,65535), (31210,0)..(31210,25371), (31210,25373)..(31210,65535), (31211,0)..(65535,65281), (65535,65283)..(65535,65535) ]; bgp_community.delete(wrong); print bgp_community; }
filter flt_itcons_i prefix set plist; { check_community(); plist = [ 91.200.192.0/22, 109.68.40.0/21, ]; if net ~ plist then accept; else reject; }
Такую конфигурацию bird принимает, но ругается на строку bgp_community.delete(wrong):
Sep 7 13:45:58 crete bird: filters, line 37: Can't add/delete non-pair
Кому-то удавалось сделать подобное? Спасибо.
-- Kind Regards, Alexander Shikoff AMS1-UANIC
-- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/
Hi,
Инженер из LINX в феврале сделал доклад
http://www.uknof.org.uk/uknof15/Preston-Routeserver.pdf
Соответственно его доклад породил дискуссию в NANOG.
Также, на одной из последних RIPE-ок один из разработчиков сделал весьма
неплохой доклад
Личное: интерфейс Quagga напоминает Cisco, Bird - Juniper ;)
Best wishes,
Maxim
2010/9/27 Vladimir Litovka
Вопросом на вопрос :)
а вот этот bird - он принципиально чем отличается от квагги?
Спасибо
2010/9/7 Alexander Shikoff
Приветствую!
Коллеги, пробовал ли кто-то использовать роутинг-демон bird ( http://bird.network.cz/)? Задача состоит в том, чтобы оставить в приезжающем префиксе только разрешенные community согласно списка.
Поскольку bird не умеет инвертировать списки community (как делает нп. JunOS), то его приходится инвертировать вручную: function check_community () pair set wrong; { wrong = [ (0,0)..(0,25371), (0,25373)..(0,31209), (0,31211)..(31209,65535), (31210,0)..(31210,25371), (31210,25373)..(31210,65535), (31211,0)..(65535,65281), (65535,65283)..(65535,65535) ]; bgp_community.delete(wrong); print bgp_community; }
filter flt_itcons_i prefix set plist; { check_community(); plist = [ 91.200.192.0/22, 109.68.40.0/21, ]; if net ~ plist then accept; else reject; }
Такую конфигурацию bird принимает, но ругается на строку bgp_community.delete(wrong):
Sep 7 13:45:58 crete bird: filters, line 37: Can't add/delete non-pair
Кому-то удавалось сделать подобное? Спасибо.
-- Kind Regards, Alexander Shikoff AMS1-UANIC
-- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/
2010/9/27 Maxim Tuliuk
спс
Соответственно его доклад породил дискуссию в NANOG.
IMHO, дискуссию может породить вопрос о применимости технологий, но вопрос о применимости инструментария - он же сугубо прикладной, о чем спорить-то? :-) -- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/
Hello Maxim Tuliuk! Mon, Sep 27, 2010 at 10:24:21AM +0200, mt wrote about "Re: [uanog] BIRD":
Инженер из LINX в феврале сделал доклад http://www.uknof.org.uk/uknof15/Preston-Routeserver.pdf Соответственно его доклад породил дискуссию в NANOG. Также, на одной из последних RIPE-ок один из разработчиков сделал весьма неплохой доклад
Видимо, вот этот http://www.ripe.net/ripe/meetings/ripe-59/presentations/filip-bird.pdf
Личное: интерфейс Quagga напоминает Cisco, Bird - Juniper ;)
Да не, он только C-подобными блоками похож, а так в Juniper синтаксис удобнее будет IMO. P.S. а Juniper напоминает Gated, если мне склероз не изменяет. -- //ShaD0w
Когда Quagga принимает большое кол-во bgp updates и пересчитывает таблицы,
то она "иногда" не успевает обрабатывать keepavile и дропает bgp session; в
результате, опять пересчет таблиц, опять проигнорированный keepalive и
получился "эффект домино". Разработчики пытаются сейчас сделать отдельный
thread, который будет обрабатывать keep-alive, но похоже это требует
изменения архитектуры всего BGP daemon; поэтому все активно тестируют
альтернативы.
Best wishes,
Maxim
2010/9/27 Vladimir Litovka
2010/9/27 Maxim Tuliuk
Инженер из LINX в феврале сделал доклад
спс
Соответственно его доклад породил дискуссию в NANOG.
IMHO, дискуссию может породить вопрос о применимости технологий, но вопрос о применимости инструментария - он же сугубо прикладной, о чем спорить-то? :-)
-- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/
On Mon, Sep 27, 2010 at 01:17:03PM +0200, Maxim Tuliuk wrote:
Когда Quagga принимает большое кол-во bgp updates и пересчитывает таблицы, то она "иногда" не успевает обрабатывать keepavile и дропает bgp session; в результате, опять пересчет таблиц, опять проигнорированный keepalive и получился "эффект домино". Разработчики пытаются сейчас сделать отдельный thread, который будет обрабатывать keep-alive, но похоже это требует изменения архитектуры всего BGP daemon; поэтому все активно тестируют альтернативы. Best wishes, Maxim А еще у нас сейчас квагга на любой bgp-маршрут говорит "Not advertised to any peer". Я вообще не могу посмотреть, что адвертайзится определенному пиру.
Поэтому встал вопрос миграции route-serverа на что-то альтернативное. Выбор невелик: openbgpd, bird. bird понравился больше. Вот еще презенташка одного из разработчиков с NANOG48: http://www.nanog.org/meetings/nanog48/presentations/Monday/Filip_BIRD_final_... -- Kind Regards, Alexander Shikoff AMS1-UANIC
On 27.09.2010 14:17, Maxim Tuliuk wrote:
Когда Quagga принимает большое кол-во bgp updates и пересчитывает таблицы, то она "иногда" не успевает обрабатывать keepavile и дропает bgp session; в результате, опять пересчет таблиц, опять проигнорированный keepalive и получился "эффект домино". Разработчики пытаются сейчас сделать отдельный thread, который будет обрабатывать keep-alive, но похоже это требует изменения архитектуры всего BGP daemon; поэтому все активно тестируют альтернативы.
Офигеть, это столько лет прошло, а эта проблема всё не решена? Интересно, а bgpd в quagga сейчас все так же подвисает при случайно забытом недосмотренном "show ip bgp"? -- Vladimir N. Garnick [nic-hdl: VG-RIPE, VG-UANIC]
Hello!
В annual reports больших Европейский IX-ов (AMS-IX, DECIX,
LINX, etc) баги Quagga составляют значительную часть
от общего числа багов. Насколько я понимаю проблемы
Quagga в качестве кода, адекватности архитектуры и
наличии грамотных SWEs все это развивать.
Operations experience работы с BIRD гораздо более
положительный и в части архитектуры он выглядит
стройнее.
Ну и еще отдельная история как и кем Quagga и
BIRD финансируются.
2010/9/26 Vladimir Litovka
Вопросом на вопрос :)
а вот этот bird - он принципиально чем отличается от квагги?
Спасибо
2010/9/7 Alexander Shikoff
Приветствую!
Коллеги, пробовал ли кто-то использовать роутинг-демон bird (http://bird.network.cz/)? Задача состоит в том, чтобы оставить в приезжающем префиксе только разрешенные community согласно списка.
Поскольку bird не умеет инвертировать списки community (как делает нп. JunOS), то его приходится инвертировать вручную: function check_community () pair set wrong; { wrong = [ (0,0)..(0,25371), (0,25373)..(0,31209), (0,31211)..(31209,65535), (31210,0)..(31210,25371), (31210,25373)..(31210,65535), (31211,0)..(65535,65281), (65535,65283)..(65535,65535) ]; bgp_community.delete(wrong); print bgp_community; }
filter flt_itcons_i prefix set plist; { check_community(); plist = [ 91.200.192.0/22, 109.68.40.0/21, ]; if net ~ plist then accept; else reject; }
Такую конфигурацию bird принимает, но ругается на строку bgp_community.delete(wrong):
Sep 7 13:45:58 crete bird: filters, line 37: Can't add/delete non-pair
Кому-то удавалось сделать подобное? Спасибо.
-- Kind Regards, Alexander Shikoff AMS1-UANIC
-- /doka ------------------ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/
-- Regards, Volodymyr.
то, что лучше - финансируется Гуглем, шо не ясно? :)
2010/9/28 Andrew Stesin
Ну и еще отдельная история как и кем Quagga и BIRD финансируются.
Так а кем и как? чисто интересно...
-- /doka ~~~~~~~~ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/
Так а шо финансируется Гуглем? Шоб не дай бог не заюзать у себя очередную малварь имени его. Vladimir Litovka написав(ла):
то, что лучше - финансируется Гуглем, шо не ясно? :)
2010/9/28 Andrew Stesin
Ну и еще отдельная история как и кем Quagga и BIRD финансируются. Так а кем и как? чисто интересно...
-- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO)
2010/9/28 Vladimir Litovka
то, что лучше - финансируется Гуглем, шо не ясно? :)
Откуда данные? На развитие BIRD-а скидывались IX-ы.
2010/9/28 Andrew Stesin
Ну и еще отдельная история как и кем Quagga и BIRD финансируются.
Так а кем и как? чисто интересно...
-- /doka ~~~~~~~~ http://doka-ua.blogspot.com/ http://omar-ha-em.blogspot.com/
-- Regards, Volodymyr.
On Tue, Sep 28, 2010 at 11:40:49PM +0300, Vladimir Garnick wrote:
On 27.09.2010 14:17, Maxim Tuliuk wrote:
Когда Quagga принимает большое кол-во bgp updates и пересчитывает таблицы, то она "иногда" не успевает обрабатывать keepavile и дропает bgp session; в результате, опять пересчет таблиц, опять проигнорированный keepalive и получился "эффект домино". Разработчики пытаются сейчас сделать отдельный thread, который будет обрабатывать Подумалось: "ВО ТОРМОЗА. А низзя разбить операцию нехерового пересчёта на последовательность меньших операций фиксированной длины (может даже настраиваемой), с обработкой всякой мутотени в промежутках, а то и halt/sleep/etc (с целью уменьшить тепловыделение - иногда может не лишним оказаться... Ваще оно как начнёт впендюривать маршруты - то тоже нефигово нагружает проц...)?"
keep-alive, но похоже это требует изменения архитектуры всего BGP daemon; поэтому все активно тестируют альтернативы. Тогда и менять сильно ничего не нужно было бы.
Меня вот как-то запарило раз, когда вдруг что-то начало приползать такое в full view, что bgp-сессия резко отрывалась - хорошо, уже была доступна версия "более правильная". -- Best regards, Paul Arakelyan.
On Fri, Oct 01, 2010 at 09:41:30AM +0300, Paul Arakelyan writes: PA> On Tue, Sep 28, 2010 at 11:40:49PM +0300, Vladimir Garnick wrote:
On 27.09.2010 14:17, Maxim Tuliuk wrote:
Когда Quagga принимает большое кол-во bgp updates и пересчитывает таблицы, то она "иногда" не успевает обрабатывать keepavile и дропает bgp session; в результате, опять пересчет таблиц, опять проигнорированный keepalive и получился "эффект домино". Разработчики пытаются сейчас сделать отдельный thread, который будет обрабатывать
PA> Подумалось: PA> "ВО ТОРМОЗА. PA> А низзя разбить операцию нехерового пересчёта на последовательность PA> меньших операций фиксированной длины (может даже настраиваемой), с PA> обработкой всякой мутотени в промежутках, а то и halt/sleep/etc (с целью PA> уменьшить тепловыделение - иногда может не лишним оказаться... Ваще оно PA> как начнёт впендюривать маршруты - то тоже нефигово нагружает проц...)?" Эту функцию разумно реализовывать не самостоятельно, а поручить планировщику задач. То есть, пересчитывать fullview и отвечать на keepalive в разных threads. Хотя можно, конечно, и как singlethread сделать (на манер innd и squid), но это уже just for fun. :-) А если процессор, которому есть чем заняться, решил вместо этого отдохнуть и остыть, это странный планировщик задач. Зачем я покупал проц 4 GHz, если вижу скорость 2GHz, а остальное время он занимается уменьшением тепловыделения? ;-) -- Паша.
Fri, Oct 01, 2010 at 09:41:30, unisol wrote about "Re: [uanog] BIRD":
Когда Quagga принимает большое кол-во bgp updates и пересчитывает таблицы, то она "иногда" не успевает обрабатывать keepavile и дропает bgp session; в результате, опять пересчет таблиц, опять проигнорированный keepalive и получился "эффект домино". Разработчики пытаются сейчас сделать отдельный thread, который будет обрабатывать Подумалось: "ВО ТОРМОЗА. А низзя разбить операцию нехерового пересчёта на последовательность меньших операций фиксированной длины (может даже настраиваемой), с обработкой всякой мутотени в промежутках, а то и halt/sleep/etc (с целью уменьшить тепловыделение - иногда может не лишним оказаться... Ваще оно как начнёт впендюривать маршруты - то тоже нефигово нагружает проц...)?"
Видимо, что-то мешает. Вообще это стандартное изменение, но его надо качественно реализовать. Например, что делать, если придёт ещё группа апдейтов? Как остановить пересчёт, если что-то принципиально изменилось (порвался peer)? Всё это стандартные проблемы программирования, но для конкретной команды они могут оказаться новыми и неожиданными. У Cisco, кстати, это явно решено давным-давно (пересчёт сильно пригружает, но не парализует). -netch-
2010/10/2 Valentin Nechayev
Fri, Oct 01, 2010 at 09:41:30, unisol wrote about "Re: [uanog] BIRD":
Когда Quagga принимает большое кол-во bgp updates и пересчитывает таблицы, то она "иногда" не успевает обрабатывать keepavile и дропает bgp session; в результате, опять пересчет таблиц, опять проигнорированный keepalive и получился "эффект домино". Разработчики пытаются сейчас сделать отдельный thread, который будет обрабатывать Подумалось: "ВО ТОРМОЗА. А низзя разбить операцию нехерового пересчёта на последовательность меньших операций фиксированной длины (может даже настраиваемой), с обработкой всякой мутотени в промежутках, а то и halt/sleep/etc (с целью уменьшить тепловыделение - иногда может не лишним оказаться... Ваще оно как начнёт впендюривать маршруты - то тоже нефигово нагружает проц...)?"
Видимо, что-то мешает. Вообще это стандартное изменение, но его надо качественно реализовать. Например, что делать, если придёт ещё группа апдейтов? Как остановить пересчёт, если что-то принципиально изменилось (порвался peer)? Всё это стандартные проблемы программирования, но для конкретной команды они могут оказаться новыми и неожиданными.
Особенно если граждане сначала программируют а уже потом думают, что в результате получилось. Из хороших статей на тему как это все можно построить: http://www.usenix.org/event/nsdi05/tech/full_papers/handley/handley_html/
У Cisco, кстати, это явно решено давным-давно (пересчёт сильно пригружает, но не парализует).
http://www.ciscotechnologyinc.com/en/US/tech/tk365/technologies_tech_note091... У вендора ну букву J есть хороший курс, называется AJNR. Там неплохо рассказывают как их реализация роутинговых протоколов (того же BGP) отличается от вендора на букву C. Btw, раз пошли разговоры за протоколы - с OpenFlow на неньке ктото играет? А с поделками от http://netfpga.org/ ? -- Regards, Volodymyr.
On Fri, Oct 01, 2010 at 10:39:37AM +0300, Pavel Gulchouck wrote:
On Fri, Oct 01, 2010 at 09:41:30AM +0300, Paul Arakelyan writes: PA> А низзя разбить операцию нехерового пересчёта на последовательность PA> меньших операций фиксированной длины (может даже настраиваемой), с PA> обработкой всякой мутотени в промежутках, а то и halt/sleep/etc (с целью PA> уменьшить тепловыделение - иногда может не лишним оказаться... Ваще оно PA> как начнёт впендюривать маршруты - то тоже нефигово нагружает проц...)?"
Эту функцию разумно реализовывать не самостоятельно, а поручить планировщику задач. То есть, пересчитывать fullview и отвечать на keepalive в разных threads. Хотя можно, конечно, и как singlethread сделать (на манер innd и squid), но это уже just for fun. :-) Да, вот только "втулить" потоки в однопоточное приложение = переписать почти с нуля, как я понял (поглядев на эту тему и свой приложение).
А если процессор, которому есть чем заняться, решил вместо этого отдохнуть и остыть, это странный планировщик задач. Зачем я покупал проц 4 GHz, если вижу скорость 2GHz, а остальное время он занимается уменьшением тепловыделения? ;-) Дык иногда "других нет"/"зимой - разгоняем до 5! летом - тормозим до 2х" :), короче - доступность комплектующих и условия применения.
Я вот ищу безуспешно чем тормознуть шину у Lenovo Ideapad U150 (Celeron 1.2GHz dual-core ULV) - должно бы дать ещё часа 3-4 автоновной работы (8-9 с SSD под Win7 есть), а если б ещё напряжения уменьшались - то так и до 16ч дотянуть можно. -- Best regards, Paul Arakelyan.
participants (11)
-
Alexander Shikoff -
Andrew Stesin -
Max Tulyev -
Maxim Tuliuk -
Michail Litvak -
Paul Arakelyan -
Pavel Gulchouck -
Valentin Nechayev -
Vladimir Garnick -
Vladimir Litovka -
Volodymyr Yakovenko