?

Log in

 
 
24 September 2009 @ 06:10 pm
Что делать с вредными more specific routes  
Есть такая старая проблема:
клиент анонсирует /23 апстриму и эту же сетку, как два /24, в IX (например, в UA-IX). В результате получается, что трафик из мира приходит апстриму по /23, а потом идёт клиенту уже по /24 (more specific) через IX. В итоге клиент получает внешний трафик через IX, без ограничений скорости, учёта и пр.

Проблема подробно исследована и описана Гинсбургом вот тут, и приведено решение для JunOS (за что ему большое спасибо). Поэтому мне остаётся лишь пересказать своими словами, привести конфигурацию для Cisco, и описать другие, менее правильные и более простые решения.

Во-первых, сразу хочу сказать, что административно бороться с проблемой бесперспективно. Клиент может такое делать без злого умысла. В конце концов, ничего противозаконного он не делает.

Первое, что приходит в голову для защиты от этой ситуации - вынесение IX на отдельный роутер. Клиенты, которые имеют собственное включение в IX, принимаются на "внешний" роутер, на котором анонсов от IX просто нет. Недостатки: во-первых, клиент может хотеть резервирование доступа к этому IX, во-вторых, клиента нужно переключать в другой роутер, если он подключился к IX, в-третьих, у самого клиента может не быть включения в IX, но у какого-то клиента этого клиента - быть, в-четвёртых, разных IX может быть несколько (KH-IX, UA-IX, DE-CIX и пр.), и непонятно, как их разделять по роутерам. Собственно, трафик с IX является "бонусом" для апстрима, лишаться которого, предоставляя клиенту исключительно оплачиваемый IPT-трафик, апстриму, очевидно, невыгодно. Вместо отдельных роутеров, разумеется, можно использовать разные vrf в пределах одного роутера. Ещё вариант - строить с клиентами две BGP-сессии, "мир" и "украину" (иными словами, IPT и IX). Если IX только один, решение вполне рабочее, хотя и создаёт некоторые неудобства для клиентов.

Второй вариант - фильтровать на роутере трафик, который идёт от апстрима на IX. Если точнее, то от апстримов и от пиринговых линков трафик должен идти только на клиентов, а всё, что идёт оттуда на апстримов или на пиринги, дропать. Недостаток в том, что у клиента в этом случае просто ничего не будет работать, что вызовет его неудовольствие. Кроме того, апстримы и пиринги могут быть включены в разные роутеры, и в этом случае фильтрация по интерфейсам получается затруднена.

Решение, предложенное Гинсбургом, наиболее правильно, хотя и не всегда просто в реализации. А именно: иметь две таблицы маршрутизации, в одной только клиенты, а в другой - fullview. Трафик от апстримов и пирингов роутится по первой таблице, от клиентов - по второй. В этом случае трафик от апстрима уйдёт на клиента, даже если от IX есть more specific route. Это не требует много памяти, потому что клиентских маршрутов относительно немного. Небольшая дополнительная модификация: сделать ещё одну таблицу роутинга, в которой есть только клиентские префиксы и fallback в полную таблицу, если маршрута не нашлось, и эту таблицу использовать для роутинга трафика от клиентов. В этом случае трафик от одного клиента уйдёт другому клиенту, даже если есть more specific от IX. Недостаток: в случае нескольких роутеров решение о том, куда роутить пакет, должно приниматься сразу на входе пакета в нашу сеть. То есть, это подходит для MPLS-сетей и для сетей с единственным "внешним" роутером, но не очень подходит для остальных. Впрочем, не всё безнадёжно: если внешние линки включены в разные роутеры, тогда можно либо маркировать трафик, либо строить внутренние линки таким образом, чтобы всегда было однозначно понятно, идёт ли трафик от апстрима клиенту или наоборот.

Пример конфигурации с разными таблицами роутинга для JunOS есть у Гинсбурга. Для Cisco получается примерно то же самое, с использованием vrf. Получаемый от апстрима трафик заруливается в vrf через PBR (более элегантных решений не придумалось). Проверено и на ISR (3825, 7200), и на 6500 (12.2(33)SXI) - работает. В некоторых случаях в NO-LOCAL необходимо добавить трафик на собственные IP, иначе поведение получается странное. Изменений в конфигурации BGP не требуется.

ip vrf upstreams
 rd xx:yy
 import ipv4 unicast map IMPORT-UPSTREAMS
!
interface GigabitEthernet0/1.100
 description Upstream
 encapsulation dot1Q 100
 ip address 4.1.1.1 255.255.255.252
 ip policy route-map FROM-UPSTREAM
!
route-map FROM-UPSTREAM permit 10
 match ip address NO-LOCAL
 set vrf upstreams
!
route-map IMPORT-UPSTREAMS permit 10
 match community CLIENTS
!
route-map IMPORT-UPSTREAMS permit 20
 match community FROM-IGP
!
route-map IMPORT-UPSTREAMS deny 30
!
ip access-list extended NO-LOCAL
 deny   ospf any any
 permit ip any any
!

UPD: Возможные грабли. Up to a 1000 prefixes will be imported by default. The prefix-limit argument is used to specify a limit from 1 to 2,147,483,647 prefixes. То есть, если клиентских префиксов может оказаться больше 1000 (в том числе в результате ошибочного вброса клиентом чего-то лишнего), лучше в строке import ipv4 unicast явно указать заведомо достаточное количество импортируемых префиксов.
 
 
 
Daniel Ginsburgdbg on September 24th, 2009 03:33 pm (UTC)
s/Гинзбург/Гинсбург/g :)
Pavel Gulchouck: gulgul_kiev on September 24th, 2009 03:38 pm (UTC)
Fixed, sorry.
(Deleted comment)
Pavel Gulchouck: gulgul_kiev on September 25th, 2009 06:46 am (UTC)
Лично я бы в первую очередь написал его аптриму, принявшему от него анонсы моих сетей, плюс ему (попробовал бы пообщаться). Если появилась уверенность, что это таки со злым умыслом (подтверждённая его словами, например), и убирать анонсы он не хочет - максимальная огласка. Если его апстрим быстро не среагировал - делать нечего, нужно самому разбивать свои блоки на более специфичные объекты и следить, чтобы на основных крупных операторах твои собственные анонсы были более приоритетны.

А что, были прецеденты? Любопытно.
PakistanTelecom, насколько я знаю, проанонсил YouTube как /24 без злого умысла. Гугль для защиты от подобного сейчас анонсит свои блоки как /24 и создаёт максимальное количество пирингов (анонсы от которых получаются более приоритетны, чем от апстримов).
Freedomifreedom on September 26th, 2009 08:36 am (UTC)
мы первоначально пошли первым вариантом, но позже столкнулись со сложностью поддержания схемы, когда роутеров стало много.
вроде как Внет пошли сразу по-второму пути, чем вызвали очень много негатива ...
Егорlesnix on October 11th, 2009 07:59 pm (UTC)
Собрал на Dynamips схему, аналогичную той, что привел dbg.
import маршрутов в VRF restricted, PBR для заруливания трафика туда.
Маршруты импортируются, лукап по VRF происходит, однако, анонсированная по BGP(send-label) метка для префиксов, импортированных в VRF, не накладывается. В итоге, пакет едет до ПРАВИЛЬНОГО бордера с одной меткой, на бордере происходит IP lookup, после чего пакет матчится по неправильному специфику, разворачивается и едет на неправильный бордер.

Вы пишете, что проверили это на 7200. Если есть такая возможность, не поделитесь ли конфигами ?
Pavel Gulchouck: gulgul_kiev on October 13th, 2009 06:52 am (UTC)
К сожалению, я тестировал (и использую) эту схему без MPLS. У меня нет возможности собрать на стенде и оттестировать схему с MPLS. Если Вы найдёте, как правильно решить задачу в Вашем случае, буду благодарен за описание.
(Anonymous) on December 23rd, 2009 04:39 pm (UTC)
надо интернет убрать в врф. появится доп. метка.