?

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

Впрочем, лично я не вижу в этом ничего страшного.
Зайнудда-апаl2tp on September 23rd, 2009 05:40 am (UTC)
За инструмент для проверки на роут-лики спасибо. Правда, очень хочется, чтобы показывало лики не только за текущий месяц. Если можно...
Pavel Gulchouck: gulgul_kiev on September 23rd, 2009 07:10 am (UTC)
Ушло в todo list.
Будет время - сделаю.
Pavel Gulchouck: gulgul_kiev on September 27th, 2009 09:31 am (UTC)
Сделал: http://asrank.happy.kiev.ua/cgi-bin/route-leaks.cgi
О том, что про каждый роут-лик хочется видеть время его существования - понимаю, когда-нибудь доделаю.
Pavel Gulchouck: gulgul_kiev on September 27th, 2009 12:36 pm (UTC)
Приделал в каком-то виде - показываются только даты (не показывается время) и только в пределах запрошенного интервала времени (т.е. если запрошено только за вчера, а лик появился неделю назад и до сих пор есть, то будет показано, что он появился вчера).
Интервал показывается от первого появления до последнего замеченного - на самом деле не обязательно он существовал всё указанное время.
Потом буду допиливать.
Cyrillcmhungry on November 17th, 2009 09:38 am (UTC)
а можно ликбез по тому, что показывает роут-лик инструмент?
Pavel Gulchouck: gulgul_kiev on November 17th, 2009 12:05 pm (UTC)
Не очень понял... Вопрос в том, что такое роут-лик, или в формате вывода?
Отвечу кратко на оба вопроса.

Роут-лик - это когда анонс (и, соответственно, маршрут) идёт не так, как предполагалось. Например, я получил ваш анонс от одного своего апстрима и в результате ошибки конфигурации отдал его другому своему апстриму. В результате роутинг на вашу сеть от этого моего второго апстрима пойдёт через меня. Что не лучшим образом скажется на качестве сервиса.

Скрипт поиска роут-ликов показывает все пути, содержащие указанную автономную систему, которые по его мнению не являются нормальными, т.е. роут-лики. Тот линк, по которому анонс прошёл ошибочно, покрашен красным. Стрелочки ">" и "<" оказывают на отношения client-upstream, отношение A>B означает, что A является апстримом для B.
Если отношения запутанные (например, A является апстримом для B по одним сетям и клиентом по другим), либо если роутлики длительные и массовые, отношения клиент-апстрим могут быть определены ошибочно, и тогда получатся ложные срабатывания скрипта (то есть, валидные пути будут показаны как роут-лики), с такими случаями я пытаюсь бороться при их обнаружении.
Cyrillcmhungry on November 17th, 2009 12:24 pm (UTC)
as39102

я правильно понимаю из вывода, что 20485 и 12389 меня транслируют дальше?
Pavel Gulchouck: gulgul_kiev on November 17th, 2009 12:43 pm (UTC)
Путь такой (в числе прочих):
3549>12389>41938<20485-8359>39102>13105
Это относится к префиксу 82.118.134.0/24. Этот анонс вашего клиента уходит через Comstar на TransTelecom, потом транстелекомовскому клиенту BashRTCommNet AS41938 (пока всё правильно), а вот потом уходит на Rostelecom (что уже неправильно) и далее его апстримам и пирингам, в т.ч. GlobalCrossing. И как результат, роутинг на эту сеть от GBLX и их клиентов идёт через Башкирию, что вряд ли было задумано. Судя по всему, это ошибка на BashRTCommNet.
Вот что видно на route-server.eu.gblx.net:

route-server.ams2>sh ip bgp 82.118.134.0/24
BGP routing table entry for 82.118.134.0/24, version 11043712
Bestpath Modifiers: always-compare-med, deterministic-med
Paths: (2 available, best #1)
Not advertised to any peer
12389 41938 20485 8359 39102 13105
67.17.64.73 from 67.17.80.155 (67.17.80.155)
Origin IGP, metric 0, localpref 350, valid, internal, best
Community: 3549:350 3549:4528 3549:31826 20485:40477
Originator: 67.17.82.187, Cluster list: 0.0.0.111
12389 41938 20485 8359 39102 13105
67.17.64.73 from 67.17.82.150 (67.17.82.150)
Origin IGP, metric 0, localpref 350, valid, internal
Community: 3549:350 3549:4528 3549:31826 20485:40477
Originator: 67.17.82.187, Cluster list: 0.0.0.111
route-server.ams2>traceroute 82.118.134.1

Type escape sequence to abort.
Tracing the route to 82.118.134.1

1 ge1-2-0-226-1000M.ar2.AMS2.gblx.net (67.17.64.73) 0 msec 0 msec 12 msec
2 te1-1-10G.ar8.LON3.gblx.net (67.16.137.105) 68 msec 208 msec 220 msec
3 64.211.193.30 216 msec 212 msec 200 msec
4 94.25.0.70 [AS 12389] 200 msec
so-0-0-0.ufa-rgr1.pv.ip.rostelecom.ru (87.226.138.174) [AS 12389] 200 msec
94.25.0.70 [AS 12389] 212 msec
5 92.50.194.78 [AS 12389] 216 msec 200 msec 156 msec
6 rtcomm-94-229-21-34.bashrtcomm.ru (94.229.21.34) [AS 41938] 152 msec 156 msec 156 msec
7 ufa01.transtelecom.net (217.150.54.138) [AS 20485] 124 msec 128 msec 124 msec
8 may-cr01-po3.spb.stream-internet.net (195.34.59.30) [AS 8359] 140 msec 132 msec 136 msec
9 212.188.18.94 [AS 8359] 136 msec 140 msec 136 msec
10 vlan797.mx240.nnz.ru (92.62.50.57) [AS 39102] 140 msec 140 msec 140 msec
11 42.49.62.92.nienschanz.ru (92.62.49.42) [AS 39102] 140 msec 144 msec 136 msec
12 * * *
[...]

В этой ситуации лучше написать админам BashRTCommNet и RolTelecom о том, чтобы они исправили ошибку и закрыли этот путь.
Либо же, если это путь валидный, я совсем не понимаю, как и что оно там устроено, а вслед за мной этого не понимает и скрипт. Выглядит очень странно, так что, наверное, это всё-таки ошибка, и через Уфу трасса идти не должна.
Cyrillcmhungry on November 17th, 2009 01:11 pm (UTC)
спасибо! посмотрю
Stranger in the Куorao on November 17th, 2009 03:46 pm (UTC)
когда вы в пятый раз смените апстрима, аккуратно перерисовать все фильтры вы, скорее всего, забудете.
bgpq/RtConfig делают это автоматом, и при правильном подходе, интегрировавшись в тривиальные скрипты, позволяют делать эту работу за считанные секунды.
Вообще, фильтры не надо недооценивать. Отсутствие роут-ликов они не гарантируют, но 90% всех роут-ликов - это косяки в фильтрах, в том числе в виде кривизны наполнения ас-сетов (такие фиг отследишь, надо глазами периодически поглядывать на изменения), косяки, которые никакие, самые правильные политики community предотвратить не смогут.
Про weight неочевидно, бывает очень удобно.
В целом, общий набор правил надо озвучить такой.
На вход: фильтруем листами, маркируем коммунити, транзитим проставляемый клиентом коммунити внутрь.
На выход: фильтруем по коммунити, проставляем необходимые пиру коммунити ("свои" - клиентам, "чужие"-апстримам), если возможно без осложнений - фильтруем листами.
Pavel Gulchouck: gulgul_kiev on November 17th, 2009 04:41 pm (UTC)
Нет, извините.
Фильтры, которые строит bgpq, не защищают от роут-ликов, независимо от того, это фильтры по префиксам или по as-path.
bgpq строит список клиентских автономок, но не строит список возможных путей. И если анонс клиентского префикса с клиентской автономкой получен от апстрима - он пройдёт через все построенные bgpq фильтры на другого апстрима. Про RtConfig - не знаю, не использовал.
Фильтры не надо переоценивать. Насчёт причин роутликов - вспоминается шутка об основной причине падения самолётов. Это сила тяжести. :)
Вообще говоря, вполне достаточно корректной работы с bgp community плюс ограничения на кол-во получаемых от клиента префиксов, и никаких роутликов не будет. Фильтрация по prefix-list и as-path с их автообновлением - лишь несколько смягчает последствия некорректной конфигурации (своей или клиентской), но не более того. Если клиент захочет злонамеренно проанонсировать префикс своего конкурента - у него не будет никаких сложностей предварительно добавить этот префикс в свой as-set. А никакой bgpq при построении фильтров не проверяет прописанный export на каждом хопе возможных путей получения каждого префикса.
По моим наблюдениям, чаще всего роутлики, как раз, возникают из-за переоценки роли фильтров. Когда строится список клиентских префиксов или автономок, на апстрима анонсируются только они, и админ считает, что всё красиво и корректно. Клиент полностью или временно переходит на другого своего апстрима - и опаньки, имеем лик, потому что настроили фильтрацию только по префиксам и клиентским автономкам, но не по community.

Про weight - случаи, когда его использование удобно и оправдано, экзотичны. Тут, на самом деле, Cisco подложила свинью, дав возможность прописать weight в строке neighbor и не дав там же прописать local-preference. Как результат - многие только по этой причине используют weight вместо local-pref (лень создавать route-map), и имеют потом из-за этого всякие грабли.

> На выход: фильтруем по коммунити, проставляем необходимые пиру коммунити ("свои" - клиентам, "чужие"-апстримам)

Не понял, как на выход проставляем чужие коммьюнити апстримам? Где мы их берём?
Чужие коммьюнити просто не трогаем. Ну или есть другой подход: все неизвестные коммьюнити (в т.ч. чужие) от клиентов удаляем на входе. Мне как клиенту удобнее, чтобы мой апстрим не срезал чужие коммьюнити в моих анонсах. Как апстриму - удобнее срезать чужие коммьюнити от клиентов. Тут каждый выбирает сам.
Stranger in the Куorao on November 17th, 2009 05:14 pm (UTC)
И если анонс клиентского префикса с клиентской автономкой получен от апстрима - он пройдёт через все построенные bgpq фильтры на другого апстрима
Вообще, клиентский анонс от клиента должен иметь приоритеты повыше, и перебивать все анонсы от апстрима... Естественно, если нет фильтра по коммунити, не позволяющего ходить анонсам из апстрима (или равнозначного пира) в апстрим - то админ - плохой, никуда не годный дятел.
Про фильтры.
Клиент, на маршруты от которого не построен фильтр, влил случайно какой-то префикс, один префикс, скажем, какого-нибудь своего или вашего общего пира. Либо из апстрима. Неприятность... Его ошибка, а трафик криво у тебя ну хоть ходит, если, конечно, клиент предусмотрительно не поставил пакетный фильтр на подключение к тебе ;-)




Не понял, как на выход проставляем чужие коммьюнити апстримам? Где мы их берём?
Чужие, в смысле апстрима.
Про weight - случаи, когда его использование удобно и оправдано, экзотичны.
Что же в них экзотичного? Если что-то надо сделать не нетворк-вайд, а пир-вайд, и локально? При этом, то, что локалпреф используется через роут-мепы это тоже вполне понятно, так как очень часто приходится отделять более приоритетные требования от пира и менее приоритетные.
Pavel Gulchouck: gulgul_kiev on November 17th, 2009 06:54 pm (UTC)
> Естественно, если нет фильтра по коммунити, не позволяющего ходить анонсам из апстрима (или равнозначного пира) в апстрим - то админ - плохой, никуда не годный дятел.

Именно. (Единственное - я предпочитаю говорить "некорректная конфигурация", а не "админ дятел", потому что все когда-то были чайниками, и даже не чайники могут ошибаться. "Админ дятел" переводится как "я дартаньян"). ;-)
Я о том и говорил, что фильтрация (по адресам, префиксам, или as-path) от роут-ликов не защищает. Даже если фильтры строить и обновлять автоматически.

> Клиент, на маршруты от которого не построен фильтр, влил случайно какой-то префикс, один префикс

Как правило, если так, тот этот префикс входит в его as-set, и фильтры не предотвратят его приём. Либо же клиент проанонсировал не один префикс, а сразу большую пачку, от этого защищает ограничение на кол-во анонсов.
Я не хочу сказать, что фильтры не нужны. Я хочу сказать, что их роль не следует переоценивать. Иногда они защищают, но не так уж часто. И только фильтры по префиксам и/или as-path без использования внутренних community от роут-ликов не защитят.

> Если что-то надо сделать не нетворк-вайд, а пир-вайд, и локально?

Для пир-вайд тоже с успехом применяется local-pref. А "локально" - это, в смысле, только для одного роутера, а на других в той же автономке приоритеты другие? Если так, то это уже экзотика, да и в этом случае совсем не факт, что применение weight правильнее, чем установка разных local-pref на разных роутерах.
Типичный пример: приоритет клиентских анонсов должен быть выше, чем паритетных, а паритетных - выше, чем апстримовых. Это разделение правильнее делать по local-pref, а не по weight, потому что эти приоритеты одинаковы для всех роутеров в пределах автономки. Использование weight приводит к тому, что на разных роутерах будет разный роутинг, а от этого один шаг до циклического роутинга.

> При этом, то, что локалпреф используется через роут-мепы это тоже вполне понятно, так как очень часто приходится отделять более приоритетные требования от пира и менее приоритетные.

Не очень понял, как это связано с тем, что weight можно устанавливать как через route-map, так и в строке neighbor, а local-pref - только в route-map, ну да ладно.
Stranger in the Куorao on November 17th, 2009 08:17 pm (UTC)
Именно. (Единственное - я предпочитаю говорить "некорректная конфигурация", а не "админ дятел", потому что все когда-то были чайниками, и даже не чайники могут ошибаться. "Админ дятел" переводится как "я дартаньян"). ;-)
Ну как бы я никогда не видел такого, чтобы не была настроена фильтрация из апстрима в апстрим, в нетранзитных случаях тем же local-AS'ом. А вот на листы, по моим наблюдениям, люди болт кладут очень часто. Это как бы и понятно, листы требуют каких-то дополнительных мозгоусилий, скриптописания, и прочего. Если учесть, что и хранение конфигов в цвс не все могут асилить...

Как правило, если так, тот этот префикс входит в его as-set, и фильтры не предотвратят его приём. Либо же клиент проанонсировал не один префикс, а сразу большую пачку, от этого защищает ограничение на кол-во анонсов.
От всех анонсов не защитит.
Pavel Gulchouck: gulgul_kiev on November 17th, 2009 08:40 pm (UTC)
> Ну как бы я никогда не видел такого, чтобы не была настроена фильтрация из апстрима в апстрим, в нетранзитных случаях тем же local-AS'ом.

Это практически единственный способ появления роутликов. Не видел роутликов - сходи по ссылке, набери номер своей автономки... ;-)

> А вот на листы, по моим наблюдениям, люди болт кладут очень часто.

Это как бы и нестрашно. Собственно, заморочки с префикслистами, насколько я знаю, есть только в Европе, где традиционно RIPE Db поддерживается в относительно актуальном состоянии. За пределами Европы строить фильтры просто не по чем. Крупные операторы и в Европе физически не имеют возможности прописать prefix-list на каждый пиринг - никакой памяти под фильтры не хватит. Да это и не является необходимым.
На всякий случай ещё раз повторюсь: я не говорю, что фильтры нужно убрать. Иногда они полезны. Но они не являются ключевым элементом конфигурации.

>> Либо же клиент проанонсировал не один префикс, а сразу большую пачку, от этого защищает ограничение на кол-во анонсов.
> От всех анонсов не защитит.
Я имею ввиду ограничение "neighbor ... maximum-prefix ..." на циске и "family inet unicast prefix-limit maximum ..." на джунипере. Защищает именно от вброса клиентом большой пачки префиксов - при превышении лимита BGP-сессия автоматически даунится (и через определённое время пробует опять подняться). Эту настройку для клиентов и пирингов применять необходимо.
Вот, кстати, забыл об этом упомянуть в постинге.
Stranger in the Куorao on November 17th, 2009 09:02 pm (UTC)
Это практически единственный способ
появления роутликов. Не видел роутликов
- сходи по ссылке, набери номер своей
автономки... ;-)

Набрал номер нескольких "своих" и "бывших своих" автономок, ничего не обнаружил. Не туда набираю?
Я имею ввиду ограничение "neighbor ... maximum-prefix ..." на циске и "family inet unicast prefix-limit maximum ..." на джунипере. Защищает именно от вброса клиентом большой пачки
Ну да. Память маршрутизатора оно от "большой пачки" защитит, кривизну таблицы маршрутизации - не вполне, особенно в случае, если диапазон возможного количества префиксов от клиента в несколько раз разнится.
Pavel Gulchouck: gulgul_kiev on November 17th, 2009 09:15 pm (UTC)
> Набрал номер нескольких "своих" и "бывших своих" автономок, ничего не обнаружил. Не туда набираю?

Даже за продолжительный период времени? Что ж, не исключаю, что действительно бывают и благополучные ситуации. Или просто я больше смотрел на крупных ISP. А назови номер AS, если не секрет.
Можешь для сравнения набрать любого из крупных российских или украинских ISP и посмотреть ситуацию с ними.

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

Как же маршрутизацию не защитит, если BGP с таким клиентом просто будет в дауне до исправления? И пусть он анонсирует в разное время от 10 до 50 префиксов - если установить ему лимит 100, то от вброса префиксов от другого апстрима или от UA-IX это вполне защитит. От единичных префиксов, прошедших через его фильтры - нет, но тут и фильтры не защитят (разве что, ручные, например, не принимать от клиентов анонсы, в пути которых есть автономка UA-IX, но это защищает лишь от некоторых частных случаев).
Stranger in the Куorao on November 17th, 2009 09:28 pm (UTC)
А, пардон, однако ж, беру свои слова обратно. Посмотрел за бОльший период - есть.
Однако ж, как "основной" - не соглашусь. Самое красивое на моей памяти случалось таки с листами. Вернее, у инициатора оно да, из-за кривой фильтрации наружу. Но если бы апстримы инициатора фильтровали по листам, неправильные роуты бы и не распространились.
Pavel Gulchouck: gulgul_kiev on November 18th, 2009 08:57 am (UTC)
Ты изучал этот вопрос, и уверен в том, что убежавшие роуты не входили в as-set инициатора? И при этом убежавших роутов было немного, поэтому ограничение на кол-во префиксов у апстримов не сработало? Возможно, когда-то где-то такое и было, но вряд ли ты наблюдал именно этот редкий случай. И почему тот случай с твоей точки зрения был самым красивым, чем отличался от остальных банальных роут-ликов?

Давай либо ты начнёшь говорить более конкретно (когда, какие префиксы, каким путём убежали, из-за какой ошибки), чтобы можно было разобрать конкретный случай, либо сворачивать этот разговор, потому что переливаем из пустого в порожнее.
Stranger in the Куorao on November 18th, 2009 10:36 am (UTC)
Не. Про префиксы я говорить не буду, по понятным причинам.
И почему тот случай с твоей точки зрения был самым красивым, чем отличался от остальных банальных роут-ликов?
Разрушительной силой, повезло просто так. Были случаи и с попаданием роутов в AS-SET инициатора, и без такового.
Для того, чтобы лик случился - достаточно пролить пира (мелкого какого-нибудь, запирились допустим два новичка на IX'е, начиная от мелочи, только получившей AS домонетов или торговцев ForexVoIP трафиком, они включаются у нас очень активно) на аплинк или на другого пира (что кстати вряд-ли, пиры между собой листы обычно строят). Единицы, а то и десятки префиксов. При этом, ясно, что тот, кто пролил - был неправ, и мог как раз описанные тобой ошибки с коммунити сделать (причём, случай "пир в аплинка" наиболее вероятен, так как для новичка идеологическая разница между клиентом и апстримом может быть понятна сразу же, а с третьим игроком - это уже куда как сложнее), но тот, кто принял, при отсутствии анонса в листах, был тоже неправ. Естественно, если при этом чуваг включил в свой AS-SET не того (такие случаи встречаются тоже часто), то он тоже совершил ошибку (тоже, причём, достаточно для новичка характерную. ).
И мало того, если аплинк, мониторя ситуацию в своих листах на свои не заметил криминала (скажем, внезапного резкого увеличения списка своих анонсов, попадания в свой список каких-то явно не нужных там AS других аплинков, и т.д. - это можно в какой-нибудь регулярный ежесуточный отчёт ввести, добавив в скрипты нескольких строчек, даже сделать греп по десятку "точно лишних" AS) и не взял ситуацию под контроль, связавшись с клиентом, клиентом клиента, и так далее - то он тоже неправ.

Объективности ради надо заметить, что всё это следствия протокольных недостатков BGP, как протокола крайне незащищённого и от ошибки, и от злого умысла, и слабо контролируемого, и в этом смысле вообще не соответствующего требованиям реальности сегодняшнего дня.
visirvisir on November 17th, 2009 07:41 pm (UTC)
>Вообще, клиентский анонс от клиента должен иметь приоритеты повыше, и перебивать все анонсы от апстрима...

Этого недостаточно. Если клиентский линк упадет, то его префикс примется от апстрима... И, если фильтрация на выход к апстримам по префиксам (а не по комьюнити), маршрут разойдется по другим апстримам. Фильтры на их стороне не помогут, надеюсь очевидно почему.
Stranger in the Куorao on November 17th, 2009 08:08 pm (UTC)
Следующее предложение читай, да?;)
arma35 on October 11th, 2010 09:53 am (UTC)
backup community
а подскажите по какому принципу работают (делают для клиентов) backup community??
Pavel Gulchouck: gulgul_kiev on October 12th, 2010 06:25 pm (UTC)
Re: backup community
Обычно примитивно - понижают local-pref анонсов с этим коммьюнити.

Тут нужно понимать и принимать во внимание вот что. Если понизить слишком сильно, то может сложиться ситуация, когда у клиента упал основной апстрим, но остался, например, MSK-IX. Он ожидает увидеть мир через резервный канал, через вас. Но вы видите его через MSK-IX с localpref 200 и как своего клиента с бэкапным коммьюнити и localpref 50. Лучший путь оказывается через msk-ix, этот анонс в мир не попадает, клиент остаётся без резерва. То есть, на роутере, который общается с IX, приоритет клиентских анонсов даже с бэкапным коммьюнити должен быть выше, чем приоритет анонсов от IX и от пирингов.

Следущий нюанс. Допустим, анонсы от IX и от пирингов имеют приоритет 200, от клиентов - 400, от апстримов - 100. Бэкапный local-pref - 250. Клиент использует вас как бэкап, при этом у вас его анонс best. Вы отдаёте его своим аплинкам (например, на Level3). Для Level3 это получается обычный анонс от клиента, и он оказывается лучшим. Хотя этот клиент предпочёл бы получать трафик по пути, например, Level3-Telia-UpLink-Client (UpLink - это основной аплинк клиента Client). Клиент получает заметный трафик через резервный канал, хотя он предпочёл бы этого трафика не иметь. И опять же: можно, используя коммьюнити Level3, понизить там приоритет этих анонсов ниже, чем пиринговые (от Telia). И, опять же, это рисковано отсутствием резервирования (особенно, если апстрим - не tier1).

Ещё вариант: триггер. Допустим, вы понижаете приоритет бэкапных анонсов до 50 (ниже, чем анонсы от апстримов), и на этом роутере (или в этом vrf / route-instance) пиринговых анонсов нет. Пока у клиента всё хорошо, вы видите его через своего апстрима. У клиента основной канал упал - анонс от апстрима пропал - лучшим стал его прямой анонс - он ушёл апстриму, клиент получил бэкап. Но что происходит, когда у клиента поднялся основной канал? Ваш аплинк по-прежнему получает этот анонс от вас, для него это лучший путь, вы от него этот анонс не получаете, и клиента через его основной линк не видите. Клиент имеет трафик через резервный канал, пока не флапнет им. Тоже не очень хорошо, и это тоже надо учитывать.

Из-за всех этих возможных проблем и неочевидности финансовой выгоды от предоставления резервного канала далеко не все предоставляют бэкапное коммьюнити. А при предоставлении нужно сначала хорошо подумать и желательно потестировать. :)