Кстати, да :-) Еще больше интересует вопрос, когда бордеры у апстримов живы, а вот за ними сети сдохли... Сам на такое нарывался. то-есть вот такая ситуация: MB-my border, UBM-upstream border, который смотрит на меня, UC- upstream's core router, UN - upstream's network, UB - border, смотрящий на backbone MB - UBM - UC - UN - UB и между UC и UB исчезает UN :-) .... есть способ отследить такое на автомате? В такой ситуации мне помогло ручное переключение на резерв, но это не выход, мне кажется -- With best regards, Gregory Edigarov Vladimir Melnik wrote:

Всем привет.

Прошу подсказки, а то в голову ничего не приходит. :-(

Вот, предположим, есть у меня BGP-роутер, который держит пару сессий с апстримами и получает от них full view. В какой-то момент основной апстрим начинает "колбасить" и BGP-сессия рвётся. Вот в этот самый момент все мои анонсы через этого апстрима исчезают из объективной реальности, но в том-то и дело, что происходит это далеко не мгновенно. Это значит, что где-то с минуту, а то и с полторы, если не повезёт, я "отдыхаю".

Вопрос в том, как избежать этого?

Ещё вопрос, кстати. На закуску, так сказать. Хорошо если апстрим "порвало" и BGP-сессия упала. А ведь часто бывает так, что этого не происходит: канал живёт, анонсы ходят, но трафик ходит плохо (например, с 90% потерь). Как кто отлавливает "в автомате" такие ситуации, кто что предпринимает?

Заранее благодарен.

=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

On Thu, Jan 11, 2007 at 02:16:54PM +0200, Pavel Gulchouck wrote:

Если имеется ввиду время bgp timeout, то варианта два: 1. Уменьшить этот самый timeout. 2. Контролировать канал на L2, чтобы BGP падала сразу, как только падает канал, а не после таймаута.

Практика показывает, что второй вариант имеет свои недостатки. Скажем, в случае protected SDH, когда канал падает, в течение 50 ms происходит переключение на protection path, но BGP успевает флапнуть, и дальше отсчет идет уже на не миллисекунды, а в лучшем случае на десятки секунд.

no ip bgp fast-external-failover или как-то так ? От кратковременных флапов защищает довольно хорошо, но "долговременные" падения детектируются гораздо хуже... PS: а вообще странный у вас protected sdh. Наши protected-sdh'и вообще никак нам переключение не индицируют.

Если же имеется ввиду время распространения изменений в мире после падения bgp, то тут хороший результат дает схема подключения к апстриму двумя независимыми каналами, от разных роутеров, к разным роутерам апстрима. В этом случае, если что-то случается с одним из каналов или с одним из роутеров, перестроение bgp происходит только внутри одной AS, в мире ничего не меняется, и потому время перехода на бэкап получается хорошим. Это, конечно, не защищает от падения всего апстрима целиком, но этого у нормального апстрима случаться не должно. :)

Апстримов все равно должно быть не менее двух :) =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Hi! On Thu, Jan 11, 2007 at 02:42:44PM +0200, Vladimir Litovka writes: VL> >Скажем, в случае protected SDH, когда канал падает, в течение VL> >50 ms происходит переключение на protection path, но BGP успевает VL> >флапнуть VL> не может такого быть... Довольно долго разбирались с ситуацией с транспортным оператором, в итоге решили прописать "neighbor ... disable-connected-check" и на том успокоиться. Как именно там был организован protection, что при переключении пути канал на ~50ms переходил в даун, я не знаю. Я, собственно, вообще про SDH мало знаю. Но вот такой факт был. -- Lucky carrier, Паша. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Если вкраце и по русски, если раутер молча умер, то (при дефолтных настройках) сосед об этом узнает через 2-3 минуты Если же из первоисточников, то RFC 4217 4.2. OPEN Message Format After a TCP connection is established, the first message sent by each side is an OPEN message. If the OPEN message is acceptable, a KEEPALIVE message confirming the OPEN is sent back. In addition to the fixed-size BGP header, the OPEN message contains the following fields: ... Hold Time: This 2-octet unsigned integer indicates the number of seconds the sender proposes for the value of the Hold Timer. Upon receipt of an OPEN message, a BGP speaker MUST calculate the value of the Hold Timer by using the smaller of its configured Hold Time and the Hold Time received in the OPEN message. The Hold Time MUST be either zero or at least three seconds. An implementation MAY reject connections on the basis of the Hold Time. The calculated value indicates the maximum number of seconds that may elapse between the receipt of successive KEEPALIVE and/or UPDATE messages from the sender. Cisco's default hold time = 180 sec 4.4. KEEPALIVE Message Format BGP does not use any TCP-based, keep-alive mechanism to determine if peers are reachable. Instead, KEEPALIVE messages are exchanged between peers often enough not to cause the Hold Timer to expire. A reasonable maximum time between KEEPALIVE messages would be one third of the Hold Time interval. KEEPALIVE messages MUST NOT be sent more frequently than one per second. An implementation MAY adjust the rate at which it sends KEEPALIVE messages as a function of the Hold Time interval. If the negotiated Hold Time interval is zero, then periodic KEEPALIVE messages MUST NOT be sent. On 11/01/07, Vladimir Melnik wrote:

Всем привет.

Прошу подсказки, а то в голову ничего не приходит. :-(

Вот, предположим, есть у меня BGP-роутер, который держит пару сессий с апстримами и получает от них full view. В какой-то момент основной апстрим начинает "колбасить" и BGP-сессия рвётся. Вот в этот самый момент все мои анонсы через этого апстрима исчезают из объективной реальности, но в том-то и дело, что происходит это далеко не мгновенно. Это значит, что где-то с минуту, а то и с полторы, если не повезёт, я "отдыхаю".

Вопрос в том, как избежать этого?

Ещё вопрос, кстати. На закуску, так сказать. Хорошо если апстрим "порвало" и BGP-сессия упала. А ведь часто бывает так, что этого не происходит: канал живёт, анонсы ходят, но трафик ходит плохо (например, с 90% потерь). Как кто отлавливает "в автомате" такие ситуации, кто что предпринимает?

Заранее благодарен.

-- V.Melnik

=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

только нужно помнить, что BFD - это протокол, который должен поддерживаться обоими сторонами линка On 1/12/07, Dmitry Kiselev wrote:

On Fri, Jan 12, 2007 at 02:23:43AM +0200, Maxim Tuliuk wrote:

...

Если вкраце и по русски, если раутер молча умер, то (при дефолтных настройках) сосед об этом узнает через 2-3 минуты

А кто заставляет дефолтные настройки использовать? ;-) Договаривайтесь с аплинками о тюнинге.

Если просто нужно сессию быстро уложить когда connectivity lost BFD еще может помочь. http://tinyurl.com/yyralo

-- Dmitry Kiselev =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

-- /doka Vision without Execution is Hallucination. -- Thomas Edison. =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

RFC утверджает, что можно "затюнится" самому :) Кстати, а Best Practice по изменению параметров BGP timers есть? On 12/01/07, Dmitry Kiselev wrote:

On Fri, Jan 12, 2007 at 02:23:43AM +0200, Maxim Tuliuk wrote:

...

Если вкраце и по русски, если раутер молча умер, то (при дефолтных настройках) сосед об этом узнает через 2-3 минуты

А кто заставляет дефолтные настройки использовать? ;-) Договаривайтесь с аплинками о тюнинге.

Если просто нужно сессию быстро уложить когда connectivity lost BFD еще может помочь. http://tinyurl.com/yyralo

-- Dmitry Kiselev

=================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message

Vladimir Litovka пишет:

только нужно помнить, что BFD - это протокол, который должен поддерживаться обоими сторонами линка

А еще надо к BFD относиться без фанатизма и не пытаться утюнить его до нереально низких значений. :) Ну и понятно, process-max-time подстраивать обязательно, если речь про циску. Опять же с обеих сторон. Плюс, если речь про интерконнект с промежуточными свитчами, как в соседнем полутреде, то пролетающий через эти свитчи BFD должен попадать на них в priority queue. -- dg =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message