![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
gul_techЕсть такая старая проблема:
клиент анонсирует /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 не требуется.
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 (в том числе в результате ошибочного вброса клиентом чего-то лишнего), лучше в строке
клиент анонсирует /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 явно указать заведомо достаточное количество импортируемых префиксов.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2012-01-30 11:49 pm (UTC)