Border Gateway Protocol

подскажите каким способом лучше решить задачу.

имеется AS со своей сеткой /22

и есть 3 бгп пира со своими AS, с которых мы получаем дефолт c локальной фильтрацией сабнетов с префиксом больше /14. всем трем апстримам мы анонсим свою сеть.

теперь встала задача основной трафик отдавать только двум апстримам, а третьему отдавать только маленький /27 кусочек из нашей сети(за исключением 2х адресов из этой самой /27 сети).

причем, если вдруг оба основные апстрима упадут, то весь трафик заворачивался бы в третий, и наоборот.

каким образом построить такую фильтрацию?

--
crossposted to ru_cisco

Как может получиться, что у одного префикса, полученного разными путями, разные origin? Кто-то из Tier1 (Tata, Level3, Cogent, Savvis) может в каких-то случаях менять origin транзитных сетей?
Это я не словил момент, когда апдейт одним путём уже пришёл, а другим ещё нет, оно давно так висит, можно и через looking glass на эту сетку смотреть.

gul@quoll> show route protocol bgp 74.33.0.0/20 table inet terse 

inet.0: 311658 destinations, 1356659 routes (307693 active, 23 holddown, 602746 hidden)
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop        AS path
* 74.33.0.0/20       B 170        100        250 >195.219.188.57  6453 3356 5650 7011 I
                     B 170        100        210 >130.117.24.17   174 3561 5650 7011 ?

Полезный псто моего колеги о борьбе с route leak: http://gul-tech.livejournal.com/33…

Есть блок адресов с маской /23
Мне бы хотелось анонсировть для одного провайдера одну из подсетей /24 + весб блок, для другого, соответственно, вторую сеть /24 + весь блок.
Я правильно понимаю, что необходима регистрация route для каждой из сетей /24 в базе RIPE?

Добрый день! У меня чисто академический вопрос.

У AS-100 Есть два провайдера: основной AS-200 и запасной AS-300.
У AS-100 есть единственный пограничный маршрутизатор, и он осуществляет BGP маршутизацию для основного и запасного канала. Существуют 4 способа контроля входящего трафика таким образом, чтобы трафик проходил через AS-200:
1.AS-100 не анонсирует AS-300 информацию о его сетях пока не прервана связь с AS-200.
2.Манипуляции с AS Path
3.AS-300 знает, что резервный и не распространяет информацию, что у него есть путь к AS-100 кроме случая, когда мы анонсировали о пути в сеть, прошло n секунд и мы до сих пор не анонсировали другой путь, который не проходит через него
4.Изменение политики AS-300 таким образом, чтобы она поменяла Local_Pref канала, соединяющего его с AS-100 на более низкий по сравнению с другими

Собственно нужно узнать про каждый из способов поподробнее, а точнее их недостатки. Перерыл весь интернет, прочитал кучу английских и русских источников. Везде подробно описываются способы контроля исходящего трафика, а на счет входящего только пишут, что это сложнее и описывают способ манипуляции с AS Path. Может быть, кто-нибудь может посоветовать, что почитать по теме?
П.С. Извиняюсь за кривой перевод вопроса... Я не силен в терминологии :)

а подскажите чем нынче префикс-листы генерируют, скажем, по номеру AS?

Чем чревато наличие вот такого:

*>i195.88.112.0/23 [neighborIP] 110 0 [AS1] [AS2] [AS3] 196705 97 97 97 97 97 97 97 97 97 97 97 97 97 97 i


Для меня лично, для умельца, подсунувшего в препенды AS из ARIN-овского диапазона, и вообще для всех?

( Read more...Collapse )

Есть ли какой-то способ узнать, что присланный peer-ом маршрут получен в результате деагрегации? Я так понимаю, деагрегация может произойти только если администратором явным образом сконфигурированы условные инъекции?

Такой вопрос. Допустим мы анонсируем некий маршрут для CIDR-префикса, более специфичного, чем уже присутствующий в Loc-RIB (и с другим next hop'ом, конечно). Например уже есть маршрут для 192.168.17.0/24, а мы анонсируем для 192.168.17.0/25. Что при этом произойдет? С одной стороны, если читать секцию 9 RFC4271 с самого начала, то ответ вроде бы будет такой, что все будет как обычно - сначала weight, потом LOCAL_PREF, ну и т.п. Если что-то из этого у имеющегося маршрута лучше, то новый никуда не попадет. С другой стороны, есть секция 9.1.4, в которой сказано:

   If a BGP speaker receives overlapping routes, the Decision Process
   MUST consider both routes based on the configured acceptance policy.
   If both a less and a more specific route are accepted, then the
   Decision Process MUST install, in Loc-RIB, either both the less and
   the more specific routes or aggregate the two routes and install, in
   Loc-RIB, the aggregated route, provided that both routes have the
   same value of the NEXT_HOP attribute.

То есть это можно понять так, что в Loc-RIB попадут оба маршрута - как более, так и менее специфичный - что, видимо, означает, что для 192.168.17.0/25 будет всегда использоваться новый маршрут, а для 192.168.17.128/25 - всегда старый.
Как же правильно?

Вопрос про RFC-4760. Может ли такое продвинутое BGP-сообщение включать несколько MP_REACH_NLRI атрибутов? Я так понимаю, что обычный NLRI в UPDATE может быть только один (просто формат сообщения такой), но атрибутов вроде можно включить сколько угодно?
Поясню откуда вопрос: в BGP flowspec эта штука используется для передачи ACL, так вот в один атрибут MP_REACH_NLRI влезает только одно определение flow, а хотелось бы несколько.