?

Log in

 
 
22 September 2009 @ 11:00 pm
Ликбез  
Раньше я думал, что все, кто настраивает BGP или MTA, в общих чертах знают, как это делать. Сейчас вижу, что роут-лики - это не единичные случайные ошибки, а пугающе массовое явление. Поэтому думаю, что описание банальных и очевидных для многих вещей будет не лишним.

1. BGP-взаимодействия бывают с апстримами, с клиентами и пиринговые, т.е. паритетные (более сложные случаи не рассматриваем). Если автономка небольшая, пирингов нет. Если совсем небольшая, клиентов с BGP тоже нет, есть только апстримы. BGP должно быть настроено так, чтобы апстримам (и пирингам) уходили анонсы только от клиентов, но не от других апстримов. Фильтр по сетям (access-list или prefix-list) эту задачу не решает! Клиент может иметь альтернативного вам апстрима, и префикс вашего клиента, полученный не напрямую от него, а от апстрима, уйдёт другому апстриму. Сегодня может быть всё хорошо, а завтра у вашего клиента всё изменится. Мало того: фильтр по as-path эту задачу тоже, в общем, не решает: когда вы в пятый раз смените апстрима, аккуратно перерисовать все фильтры вы, скорее всего, забудете. Правильно эту задачу решает bgp community: на анонсы, полученные от апстримов, ставите какой-то специальный community attribute, и анонсы с этим атрибутом апстримам не отдаёте. Либо наоборот: специальный атрибут ставите на анонсы от клиентов, и апстримам отдаёте только их и ничего другого. Тогда анонсы вашего клиента уйдут апстриму, если вы их получили непосредственно от клиента, и не уйдут, если они получены другим путём (от апстрима).

2. Коммьюнити бывают внешние и внутренние. Внешние - те, которые вы отдаёте клиентам и которые принимаете от них. Внутренние - которые используете только внутри своей AS. Чтобы маршрутизация происходила корректно, клиент или апстрим не должен иметь возможность поставить коммьюнити, на основании которого изменится мнение о происхождении этого анонса. Например, неправильно допускать ситуацию, когда апстрим прислал анонс с вашим "клиентским" коммьюнити, и этот анонс ушёл другому апстриму. Чтобы этого избежать, внутренние коммьюнити нужно чистить на приёме анонсов как от клиентов, так и от апстримов. Например, внутренние коммьюнити могут быть двух- или трёхзначные, а внешние - четырёх- и пятизначные, и на приёме можно удалять все свои двух- и трёхзначные коммьюнити. "Свои" - это у которых из частей xxxx:yyyy часть xxxx - ваша автономка.

3. Правило хорошего тона: удаляйте все свои ненужные коммьюнити при экспорте анонсов. То есть, вообще все свои при экспорте апстримам, и все, кроме специальных информационных, при экспорте клиентам. Ваши ненужные коммьюнити засоряют память маршрутизаторов (во всём мире!) и увеличивают время сходимости bgp.

4. Думаете, что у вас с роутингом всё благополучно? Наберите номер вашей автономки вот тут и нажмите "show route-leaks". Скорее всего, узнаете много интересного. Если вдруг ничего не нашлось - не расслабляйтесь и посмотрите за более длительный промежуток времени, что было раньше.

5. Не используйте weight, если только вы не точно знаете, что и зачем вы делаете. Для разделения префиксов по приоритетам существует local-preference. Отличие в том, что localpref передаётся между вашими роутерами, его достаточно ставить на внешней bgp.

6. При конфигурировании BGP на Cisco и многих других платформах сначала нужно прописать номер автономки на том конце (remote-as). Сразу после этого BGP норовит подняться, до прописывания каких-либо фильтров. В результате апстрим получает от вас fullview, либо же вы получаете fullview от своего клиента. Чтобы этого не было, bgp не должна подниматься сразу, пока она не сконфигурирована полностью. В более-менее свежих версиях IOS специально для этого у команды "neighbor ... remote-as ..." в конце можно сказать "shutdown". Если такой возможности нет, сначала задауните сабинтерфейс, потом сконфигурируйте BGP со всеми фильтрами, и только потом скажите "no shutdown". Благо, у Juniper такой проблемы нет: там можно сначала всё прописать, а потом сделать commit.

7. А что, разве не все хранят конфиги роутеров в cvs или svn? И не отслеживают изменения по дифам? А как же без этого жить? ;-)

О более сложных вариантах появления роут-ликов напишу в следующий раз.

UPD: Совсем забыл упомянуть про столь необходимую для клиентских и пиринговых BGP настройку, как ограничение на кол-во префиксов. Очень помогает против роут-ликов и прочих неприятностей. Например, для Cisco IOS: "neighbor ... maximum-prefix 100 restart 10", для JunOS: "set protocols bgp group CLIENTS family inet unicast prefix-limit maximum 100 teardown idle-timeout 10". То есть, если клиент пришлёт более сотни анонсов, BGP с ним автоматически задаунится на 10 минут, после чего автоматически поднимется, и, если клиент к тому времени ошибку уже исправил, будет жить, а если нет - опять ляжет на 10 минут, и так далее. Разумеется, этот лимит может устанавливаться индивидуально для разных клиентов.
 
 
 
visirvisir on September 23rd, 2009 02:56 am (UTC)
6. Можно использовать такие локалпрефы, что с дефолтным локалпрефом (100) маршруты выбираются в последнюю очередь - вполне себе защита от преждевременного (до наложения фильтров-политик) установления сессии.

Есть еще засада с генераторами фильтров, типа bgpq/irrpt/... . У многих они обновляют фильтры по крону, без участия человека. Они как правильно генерируют нечто вроде:
no ip prefix-list tralala
ip prefix-list tralala ....
- то есть первой командой префикс-лист удаляют, при этом циска начинает принимать все маршруты.
Теперь внимание, вопрос: что произойдет если клиент скажем удалит свой as-macro из ripe db ?
А будет вот что, генератор сгенерирует только "no ip prefix-list tralala"! То есть отключит фильтрацию, по крону.


Ну и есть еще такой отдельный вид клиентов, которые абсолютно уверены, что для полноценной работы интернета аплинки должны от них принимать фулл-вью. И готовы добиваться этого всеми способами...
Pavel Gulchouck: gulgul_kiev on September 23rd, 2009 07:03 am (UTC)
> 6. Можно использовать такие локалпрефы, что с дефолтным локалпрефом (100) маршруты выбираются в последнюю очередь - вполне себе защита от преждевременного (до наложения фильтров-политик) установления сессии.

Нет, не нужно учить неправильным решениям. Это защитит в какой-то мере, но всё равно возможны нюансы. Во-первых, на экспортируемые анонсы это никак не повлияет, и удалённая сторона всё равно рискует получить от вас fullview. Во-вторых, примутся анонсы, которых у вас нет, это может быть 0.0.0.0/0, 10.0.0.0/8 или ещё что-нибудь. Да и fullview есть не у всех. Нужно именно сначала прописать все фильтры и прочие настройки, а только потом поднимать bgp.

> Теперь внимание, вопрос: что произойдет если клиент скажем удалит свой as-macro из ripe db?
> А будет вот что, генератор сгенерирует только "no ip prefix-list tralala"! То есть отключит фильтрацию, по крону.

Да, на нулевой результат лучше проверять, но это уже, в общем, мелочи. Если в такой ситуации снимется фильтр на клиента до ручного вмешательства (останется только ограничение на кол-во префиксов), IMHO это нестрашно, это не приведёт ни к каким неприятностям, если только не наложится на другие ошибки. Да и те, кто делает автоматическое обновление клиентских фильтров по крону, уже понимают, что к чему, и с мелкими недоделками вроде непроверки кода завершения bgpq, на пустой prefix-list, на коллизии объектов RIPE db и RADB и т.д. смогут справиться самостоятельно. :)

Да и не могу назвать эту ситуацию массовой. У нас чёрт знает сколько контролируется, чтобы при обновлении по крону результирующий фильтр был не пустым, и срабатываний этой проверки не было. Только для одного пиринга на DE-CIX, но там ситуация с отсутствием заявленного as-set была изначально.

> Ну и есть еще такой отдельный вид клиентов, которые абсолютно уверены, что для полноценной работы интернета аплинки должны от них принимать фулл-вью. И готовы добиваться этого всеми способами...

Интересно, не встречал. :)
Stranger in the Куorao on November 17th, 2009 03:51 pm (UTC)
А будет вот что, генератор сгенерирует только "no ip prefix-list tralala"! То есть отключит фильтрацию, по крону.
Плохой генератор?
> bgpq AS-VODKA
!generated by bgpq. http://www.lexa.ru/snar/bgpq/
no ip access-list extended UNKNOWN
ip access-list extended UNKNOWN
deny ip any any
> bgpq AS65300
!generated by bgpq. http://www.lexa.ru/snar/bgpq/
no ip access-list extended UNKNOWN
ip access-list extended UNKNOWN
deny ip any any
>


RtConfig, насколько помню, тоже работает правильно.
Pavel Gulchouck: gulgul_kiev on November 17th, 2009 04:54 pm (UTC)
Если генерировать prefix-list, получается вот что:
gul:~>bgpq3 AS-VODKA
no ip prefix-list NN
gul:~>bgpq3 | grep ver
bgpq3 version: 0.1.9
gul:~>bgpq -P AS-VODKA
!generated by bgpq. http://www.lexa.ru/snar/bgpq/
no ip prefix-list UNKNOWN
gul:~>pkg_info -W `which bgpq`
/usr/local/bin/bgpq was installed by package bgpq-1.0.9.7

Впрочем, лично я не вижу в этом ничего страшного.