Re: балансировка BGP

From

Petr Novopashenniy (2:5020/400)

To

Eugene Grosbein

Date

2009-10-01T11:03:38Z

Area

RU.CISCO

From: Petr Novopashenniy <pety@rusnet.ru>


On Wed, 30 Sep 2009, Eugene Grosbein wrote:

EG> 30 сен 2009, среда, в 14:04 KRAT, Petr Novopashenniy написал(а):
EG> 
EG>  PN>> Ростелеком или Ретн, получая такой трафик с MSK-IX, не хотят его
EG>  PN> отдавать 
EG>  PN>> на свои аплинки (Ростелеком) и на свои пиры (Ретн, имеющий пиринг с
EG>  PN> ТТК 
EG>  PN>> 20485).
EG>  EG>> Вот этого я не понимаю. Трафик с MSK-IX к ним приходит, видимо,
EG>  EG>> потому что они анонсируют доступность IP-адреса через себя?
EG>  PN> Да. А как же еще? ;)
EG>  EG>> И что они делают с пакетом, пришедшим к ним от MSK-IX и имеющим далее
EG>  EG>> более специфичный маршрут в ТТК AS20485?
EG>  PN> Дропают.
EG> 
EG> Это замечательная доступность. Просто великолепная.
EG> А какого, спрашивается, дропать?.. Если анонсируешь доступность через себя.
EG> Или не анонсируй, или пропускай. "По-моему, так."

А что Вы предлагаете сделать с таким пакетом?

Пускать по специфику?
Чтобы было понятней, попробую привести более глобальный пример.
Вы, например, устанавливаете на специфики (а может даже на агрегат), 
которые анонсируете в Транстелеком, community - не анонсировать зарубежным 
пирам/аплинкам или как-нибудь еще (у ТТК есть такая возможность). Вполне 
себе безобидное community, Вы хотите видеть от Транстелекома только 
российский трафик.
Спецификов в РТКомм (6684) не отдаете, только агрегат (без 
каких-либо community). Ваш агрегат через 6684 12389 9002 (Ретн - аплинк 
Ростелекома) попадает в остальной мир. Ваш основной мировой трафик пойдет 
к Ретн через его аплинков/пиров. Дойдя до Ретна, обнаруживается что один 
из его российских пиров (Транстелеком) отдает ему специфик. И вот трафик, 
прошедший всю европу а может и более по магистральным каналам Ретн за 
просто так сливается другому оператору, который за этот трафик получит 
от клиента деньги. Такой расклад магистралам как-то не очень интересен.

Пускать по агрегату, который смотрит на клиента (игнорировать 
его специфики, которые смотрят не на клиента)? Это в любом случае, или 
только тогда когда трафик на этот специфик получен от пиров/аплинков, а 
если от другого клиента, то по специфику, даже если он на клиента (для 
которого трафик) не смотрит?

В этом случае это уже маршрутизация не на основе BGP, а некий PBR 
основанный на данных, полученых в том числе и от BGP. Тут тоже есть 
проблемы. В Вашем случае, к примеру, все три AS 9002 12389 6684 должны 
иметь одинаковую политику в отношении таких случаев.
Иначе либо routing loop:
Например, 6684 видит лучший маршрут на Ваш специфик через 12389. 12389 
отдает Ваш трафик на агрегат в сторону 6684. А 6684 отдает его 
обратно по специфику 12389 (это если в 12389 не учитывается точка входа - 
клиент/не клиент).
Либо дополнительная петля:
12389 видит, что точка входа трафика на этот специфик его клиент 6684, и 
отправляет этот трафик уже по нему своим пирам/аплинкам. При этом трафик 
может пройти туда-обратно через всю страну.

Диагностика таких проблем будет еще более сложна. Когда получаешь full 
view несколько расчитываешь, что трафик на принятые префиксы пойдет 
именно по известному по BGP AS-PATH. А из последнего примера видно, что 
Ваши специфики по BGP будут отдаваться всем клиентам (РТКом'а, 
Ростелекома, Ретна), но трафик к ним пойдет совсем не по тому AS-PATH.

EG> 
EG>  PN> Вообще эта тема весьма старая, но не все о ней знают. Универсального 
EG>  PN> решения, которое бы удовлетворяло все стороны, пока нет. Также есть и 
EG>  PN> технические ограничения в софте оборудования.
EG> 
EG> То есть как нет? Не можешь гарантировать доступность через себя префикса,
EG> не анонсируй его.
EG> А то и рыбку съесть - получить плату за предоставление
EG> услуги, и не предоставить её, - как-то странно... За рубежом такой же
EG> подход к работе в телекомах?

Ну, от подобных утечек трафика там тоже защищаются, хотя тоже не все.

EG> 
EG>  PN> С more спецификами надо быть очень осторожным, в данном случае еще очень 
EG>  PN> повезло что проблема так близко, может быть видна на нескольких LG, и 
EG>  PN> затрагивает заметное количество ресурсов сети (и соответственно, быстро 
EG>  PN> опознается).
EG> 
EG>  PN> http://net-geek.org/dbg/2008/09/overcoming-peer-fraud.html
EG> 
EG> > Technical solution boils down to enforcing certain routing policies.
EG> > The rules are:
EG> > 1. Traffic ingressing from an upstream must flow only to a customer.
EG> 
EG> Тут не сказано "поэтому при наличии роута к пиру такой трафик
EG> надо дропать".

То что там написано не является стандартом и обязателным к исполнению 
всеми операторами. Я дал эту ссылку исключительно как материал для 
размышлений. А также там есть слова:

Another one is from Cisco-land: QPPB. There's a quite cool method 
described in details in another NANOG presentation: 
http://www.nanog.org/meetings/nanog42/presentations/DavidSmith-PeeringPolicyEnforcement.pdf.

These solutions can deal with the problem, but there's a catch. They are 
designed to drop traffic when a peer tries to defraud us. This is a 
problem, because even unintentional misconfiguration (say, a sloppy 
attempt at traffic engineering) will result in service disruption. It 
would be nice, if we could handle it better and somehow ignore 
fraudulent/erroneous routes.

Petr Novopashenniy
--- ifmail v.2.15dev5.4
 * Origin: NPO RUSnet InterNetNews site (2:5020/400)
SEEN-BY: 50/204 450/1024 461/43 640 465/11 469/142 999 4625/8 4641/444
SEEN-BY: 5000/5000 5006/1 5007/1 5010/70 5011/13 5012/46 5015/28 5019/26
SEEN-BY: 5020/175 400 545 982 1521 2238 4441 5021/29 5025/3 5026/14 5027/12
SEEN-BY: 5030/1080 5034/13 5035/38 5036/1 5037/28 5045/7 5049/1 5054/1 4 8 9
SEEN-BY: 5054/28 30 36 37 67 75 81 89 5060/88 5061/15 5062/10 5063/3 5066/18
SEEN-BY: 5075/35 5077/70 5080/68 5084/9 5085/13 5095/20 5096/18 6001/10 6004/3
SEEN-BY: 6009/3

PATH: 5020/400 545 5054/1 37