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

From

Petr Novopashenniy (2:5020/400)

To

Eugene Grosbein

Date

2009-10-02T15:46:12Z

Area

RU.CISCO

From: Petr Novopashenniy <pety@rusnet.ru>


On Thu, 1 Oct 2009, Eugene Grosbein wrote:

EG> 01 окт 2009, четверг, в 14:33 KRAT, Petr Novopashenniy написал(а):
EG> 
EG>  EG>>> И вовсе не дропом пакетов. Принцип
EG>  EG>>> "анонсировать только достижимое" должен быть непокоб^Нлебим.
EG>  PN>> "анонсировать только достижимое" - очень расплывчатая формулировка.
EG>  PN> Как 
EG>  PN>> это делать на деле?
EG>  EG>> А вот это уже проблема оператора. Всякие хитрые фильтры там,
EG>  EG>> пусть об этом голова болит у того, кто хочет себе канал сэкономить от IX.
EG>  PN> Э... Это Вы про себя? 
EG>  PN> :))
EG>  PN> Честно говоря не понял что Вы хотели сказать про экономию от IX.
EG> 
EG> Ну там же проблема в том, что жалко ширины "внешнего" канала/канала от IX,
EG> нет? Ладно, проехали с экономией.

Я ведь писал, там жалко халявного транзита. Который может быть коротким 
(как в Вашем случае Москва - Хельсинки(или Киев)), так и очень длинным.
Характерный пример по Москве:
В аплинках у AS xxx - Retn, туда анонсируется агрегат AS xxx.
В пирах у AS xxx - RS MSK-IX, туда анонсируются специфики AS xxx, которые 
также попадают в Retn, так как он тоже имеет пиринг с RS MSK-IX.
В результате AS xxx останется без транзита через Retn (входящий трафик 
будет дропаться). В примере вместо Retn можно поставить и Ростелеком.

EG> 
EG>  EG>> А кто тут приводил примеры с лупами и петлями? :-)
EG>  EG>> Вот чтобы их не было, потому и нет.
EG>  PN> Лупы (r/l) и петли - это когда тот самый PBR (из статьи) у 
EG>  PN> транзитных операторов будет криво настроен (или у одного настроен, а у 
EG>  PN> другого - нет). А так routing loops (r/l) не будет (так и есть сейчас), а 
EG>  PN> геграфические петли гоаздо меньше, чем могли бы быть при кривом PBR.
EG> 
EG> Вообще говоря, PBR там или не PBR внутри у операторской железки,
EG> это сугубо его интимное дело. Лишь бы циклов не устраивал
EG> и не дропал пакеты, пришедшие на пропущенный собственными
EG> BGP-роутерами анонсы. Всякие там статьи, как справедливо замечено,
EG> ему не указ, а максимум hint. Вот пусть обхинтуется и придумает.
EG> А routing loop или дропы ("как и есть сейчас"), для пинга-то всё едино.

Да, интимное дело. Они уже обхинтовались и придумали.

EG> 
EG>  PN> Что-то сложно уже получается. Нужно у операторов транзита вводить PBR, да 
EG>  PN> еще каким-то способом вырезать из анонсов к клиентам некотрые специфики.
EG> 
EG> А кто говорил, что хитрые политики будет легко реализовывать?
EG> Это только платежи принимать легко ;-)
Хитрые политики требуют хитрых платежей. ;)

EG> 
EG>  PN> Кстати, а кто из операторов обязан (ну если помечтать) у себя этот PBR 
EG>  PN> реализовывать? Мне думается тот, кто предоставляет IP транзит другим 
EG>  PN> операторам.
EG>  PN> Судя по объекту AS29072 из RIPE, Вы тоже предоставляете. Чем Ваши клиенты 
EG>  PN> хуже, если попадут в аналогичную ситуацию, только с Вами?
EG> 
EG> А уже приходилось разруливать ид^W неумные политики коммерсов,
EG> но мне PBR строить не страшно. Масштабы только не те, да :-)

В том то и дело - не те масштабы. А при большой сети и большом кол-ве 
клиентов все подключаются по готовым шаблонам. Индивидуальный подход - за 
отдельные, более другие деньги. Введение PBR на сети магистральных 
операторов поломает много годами работающих схем. Все-таки у нас 
глобальная маршрутизация в Inet делается посредством BGP. PBR же будет 
вести себя совсем несколько по другому. Да, при IPv6 с таким PBR там 
будет совсем весело.

Вот небольшой пример с уже упоминавшимся Релкомом и его старой доброй 
сетью 193.124.0.0/15 (ALLOCATED UNSPECIFIED). Там есть ~55 спецификов, как 
из России, так и из Украины. Relcom анонсирует в мир и на MSK-IX агрегат.
Большинство операторов, имеющих эти специфики, имеют собственные 
альтернативные каналы связи - пиринги и транзиты. В мире большинство этих 
спецификов видны напрямую, без транзита через Релком. Но на MSK-IX многих 
этих спецификов нет вообще. Нет, связность у таких как vesti.ru 
без full view останется, Релком предоставит транизт через себя. Т.е. 
трафик пойдет по агрегату через MSK-IX в Релком, а тот уже его отправит по 
специфику черз своих АПЛИНКОВ. Для примера брал 193.124.54.0/24


IIP-Net looking glass output 
Router: RMIX (as5429)
Query: traceroute 193.124.54.43

Type escape sequence to abort.
Tracing the route to 193.124.54.43

  1 195.178.192.177 0 msec 4 msec 4 msec
  2 193.232.244.33 0 msec 0 msec 0 msec
  3 193.124.254.170 [AS 2118] 4 msec 0 msec 4 msec
  4 217.150.52.174 0 msec 4 msec 0 msec
  5 195.34.38.1 4 msec 0 msec 4 msec
  6 212.188.1.166 24 msec 24 msec 20 msec
  7 195.34.38.242 24 msec 24 msec 24 msec
  8 89.209.10.106 60 msec 56 msec 64 msec
  9 194.44.6.14 68 msec 68 msec 68 msec
 10 91.90.19.22 64 msec 64 msec 68 msec
 11 193.124.54.43 [AS 2118] 68 msec 68 msec * 


А теперь включим наш PBR у аплинков Релкома - Retn'а и ТТК, а может и еще 
где между ними (на их аплинках). Как это заработает? С учетом вырезания 
спецификов для предотвращения r/l? А ведь аналогичных схем в инете весьма 
много. Нет, говорить, что они все (Релком и те, кто пользует его 
специфики) хотят странного не надо, будем с коллегами солидарны. ;)

Иными словами, PBR требует индивидуальной настройки для каждого случая, 
для крупных сетей это может быть большая проблема, а за ее решение 
придется платить.

EG> 
EG>  EG>>> он его не должен анонсировать своим клиентам
EG>  EG>>> доступность специфика через этого пира. Анонсировать только
EG>  PN> доступное.
EG>  PN>> Почему? От своих клиентов, которым оператор дает транзит, он этот
EG>  PN> трафик 
EG>  PN>> вполне может отправить на специфик, для клиентов он вполне доступен.
EG>  EG>> Лупы неизбежны, а это не называется "вполне доступен".
EG>  PN> Почему?
EG> 
EG> Потому что дропать нельзя, роутить.
EG> 
EG>  PN> Вот если взять ситуацию как сейчас (нет никаких PBR).
EG> 
EG> PBR там как раз есть, в Null0.

Хм. Да? Мой firewall с правилами drop - тоже PBR?

Если серьезно, как мне кажется, дропы здесь это самое малое зло. Я же 
говорил, что универсального решения устраивающего всех - нет. С краю 
остаются малые и слабые, да.

EG> 
EG>  PN> Лупов ведь нет (я про r/l).
EG> 
EG> Дропы ничуть не лучше.

Зато они предсказуемей.

EG> 
EG>  PN> Я почти уверен, что если Вы снимите специфики с РТКом, то 
EG>  PN> связи с сетями самого Ростелекома (12389) и его клиентами Вы не 
EG>  PN> потеряете. Так что для клиентов вполне доступен. Но да, с большой 
EG>  PN> географической петлей видимо через зарубеж.
EG> 
EG> А в договоре не сказано, что доступен только 12389 и его клиенты,
EG> да и про недоступность vesti.ru тоже как-то забыли упомянуть, вот беда.

Ну так это нормално. ;)

EG> 
EG>  EG>>> routing loop не будет просто потому что 6684 не должен получить
EG>  EG>>> специфик от 12389, об этом выше написал.
EG>  PN>> Почему в данном случае 12389 не должен отдавать этот специфик своему 
EG>  PN>> клиенту?
EG>  EG>> Чтобы не было routing loop и петель.
EG>  PN> Боюсь в какой-то момент мы неправильно поняли друг друга. loop'ы и петли 
EG>  PN> будут тогда, когда такой PBR из статьи будет настроен не у всех операторов
EG>  PN> 
EG>  PN> транзита. А если такого PBR нет, то и r/l от спецификов не будет.
EG> 
EG> Пропуск трафика, пришедшего на анонсируемый маршрут,
EG> должен выполняться оператором безусловно, этот постулат обсуждению
EG> не подлежит. Из этого и нежелания маршрутизировать трафик пиру по специфику
EG> сразу следует обязанность маршрутизировать его по агрегату
EG> клиенту, пока такой агрегат от клиента принимается. Из этого и необходимости
EG> недопущения циклов сразу следует необходимость не анонсировать специфик
EG> клиенту, несмотря ни на какой full view. Либо игнорирование
EG> специфика от пира, либо самый фулл view клиенту, одно из двух.
EG> 

Тогда перепишите ядро (C).

EG>  EG>> Я говорил пока только о входящем. И кстати говоря, сегодня вот
EG>  EG>> трассировка от меня туда уже идет через 6684, на несколько хопов короче
EG>  EG>> и идет по прямому маршруту через 12389, MSK-IX и сразу к 25292
EG>  EG>> (vesti.ru).
EG>  PN> Как так, само?!! ;)))
EG> 
EG> Да, совершенно само. Это Internet, здесь могут посл^H^Нменяться маршруты.

Я к тому, что некотрые следят за связностью, и дают больший приоритет 
маршруту с меньшим rtt, и он случайно не перескочит, до тех пор пока жив. 
Да, это мешает балансировке, но она не всегда первостепенна.

EG>  EG>> Ну и будет пустой канал, ага. Я уж лучше спецификами...
EG>  PN> Вам еще повезло, а то бывают и такие реальные ситуации, когда у Вас два 
EG>  PN> аплинка, и один сразу же клиент второго. Вот и балансируйте тогда ;).
EG> 
EG> Было и такое. Условные анонсирования тогда же и выучил, ага.

Ну тогда зачем было задавать вторую часть Вашего изначального вопроса? ;)
Кстати, а как вышел баланс?

Вам действительно бажнее входящая балансировка, нежели rtt? Если да, может 
наоборот, возьмете через РТКомм часть зарубежа (без анонсов на MSK-IX, и 
тому подобное), а Москву и другую часть забугорья возьмете через TTK? Ведь 
если только один MSK-IX через РТКомм нарушает Вам баланс, а при его 
отсутствии канал пустой - спецификами один MSK-IX особо на части не 
поделишь...

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