?

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 минут, и так далее. Разумеется, этот лимит может устанавливаться индивидуально для разных клиентов.
 
 
 
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)
спасибо! посмотрю