Border Gateway Protocol

3:12PM - фильтрация исходящего трафика

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

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

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

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

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

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

--
crossposted to ru_cisco

8:34PM - Разный origin

Как может получиться, что у одного префикса, полученного разными путями, разные 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 ?

11:14AM - Борьба с route leak

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

9:56AM - Распределение входящего трафика по двум каналам

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

5:11PM - Вопрос по bgp (способы контроля входящего трафика)

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

У 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. Может быть, кто-нибудь может посоветовать, что почитать по теме?
П.С. Извиняюсь за кривой перевод вопроса... Я не силен в терминологии :)

4:23PM - автоматическая генерация префикс-листов

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

11:12AM - Неправильный какой-то роут пришел

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

*>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 )

2:07PM - route deaggregation

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

11:28PM

Такой вопрос. Допустим мы анонсируем некий маршрут для 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 - всегда старый.
Как же правильно?

12:08PM

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

6:17PM

Добрый день,

Вопрос в продолжение моих прошлогодних изысканий. Есть BGP peered роутеры A и B. В какой-то момент рвется BGP-соединение, и B пропадает из виду. A удаляет все его маршруты и перестает слать на него трафик. Через некоторое время роутер B поднимается, посылает OPEN, но не посылает UPDATE. Что произойдет в это случае? Будут ли все равно восстановлены маршруты на B в Loc-RIB? Или надо обязательно перепосылать их явно в UPDATE?

10:33PM

Добрый день,

Несколько немного очевидных, наверное, вопросов про функционирование BGP-роутеров. Представим себе два BGP-peered роутера. Как я понимаю, пиринговые отношения подразумевают постоянно открытое TCP-соединение между ними, и маршруты полученные от peer'а считаются валидными только пока это соединение установлено. Далее, в RFC 1771 написано, что BGP decision process функционирует таким образом, что на каждое направление в Loc-RIB должен включаться только один маршрут (хотя в Adj-RIB-In подходящих маршрутов может быть несколько). Теперь представим себе, что в какой-то момент один из роутеров становится недоступен, TCP-соединение рвется, и все маршруты, которые с него получены, помечаются как невалидные. В этой ситуации:
- можем ли мы считать, что в Loc-RIB не осталось маршрутов с next hop=упавшему роутеру? Разве не могли такие маршруты быть получены из других источников?
- раз для каждого направления в Loc-RIB возможен только один маршрут, и этот маршрут удален в результате потери пиринговых отношений, чем будет руководствоваться роутер при маршрутизации пакетов? Будет снова запущен decision process для нахождения другого маршрута на данное направление?
- допустим я route reflector в этой конфигурации. Получу ли я от оставшегося роутера BGP update, в котором все маршруты, удаленные из Loc-RIB в связи с недоступностью peer'а, будут помечены как withdrawn?

6:35PM

А вот скажите, правильно ли выпускать в IPv6 анонсы размером /44-/48?

11:13PM - Маршрутизация в Интернет. "Разорванная" AS.

Доброе время суток, уважаемые.
Вопрос чисто академический, интересно понять.
А возможно ли(и применяется ли ?) разбиение AS на две независимых части и анонсирование двум разным апстримам разных префиксов ?
У меня есть, пожалуй, мысли, почему так не делается, связано это наверняка с агрегацией маршрутов некоторыми апстримами, но полноценного ответа на вопрос "почему" у меня нет.
Иными словами, почему не делают так:
( Иллюстрация >> Collapse )

crosspost cisco_ru

3:19PM - Mikrotik rb-1000, routeros 3.3 / BGP / AS / 2 ISP

Есть микротик RB-1000,роутерос 3.3.
Столкнулся с проблемой:
Есть 2 провайдера, которые выделили свои реквизиты, ип,днс,шлюз, default bgp.
Есть своя автономная система.

Нужно: настроить так, что бы инет работал одновременно с балансировкой по двум каналам.
Тут http://www.mikrotik.com/testdocs/ros/2.9/routing/bgp.php нашёл, но не совсем понятно, может кто-то натолкнуть на путь?
Принцип заключается в том, что бы я на ether1 и ether2 прописал IPы уже из своей АС,прописал маршруты до провайдеров, затем попросил своих ISP, что бы те прописали мою АС на своём оборудовании? Я так мыслю?

Спасибо.

1:47AM

Добрый день, уважаемые.
Интересно было бы послушать Ваши мнения о причинах следующей ситуации.
Есть автономная система, два граничных маршрутизатора, соединенных напрямую. Каждый граничный маршрутизатор принимает fullview - первый от одного провайдера(AS100), второй - от другого(AS300).
Между бордерами поднята iBGP-сессия. Чтобы автономка не стала тразитной - исходящие к провайдерам анонсы ограничены соответствующими списками префиксов.
Ожидал, что в результате на каждом из бордеров будет два fullview, однако, получил какую-то не вполне понятную ситуацию, когда на один из бордеров приходит только часть префиксов из второго fullview.
Интересно было бы разобраться, в чем дело.
Топология и конфиги - ниже, ( Read more...Collapse )

1:14PM - foundry bgp

интересный факт что "Foundry Bundle Bigiron Fiber 100" не желает конектиться с кошками 65xx (остальные не проверял). Один уважаемый человек сказал поставить ebgp-multihop 2 дабы повысить ttl, и сие заводится.
с чем бы это молгло было быть связанно?

ps. прошивку менял на последнюю, до этого даже с juniper не хотел вникакую дружить.

1:22PM

Добрый день.

Есть автономная система и блок провайдернонезависимых адресов (2 сетки /24).
Есть Cisco 7206. Есть 2 провайдера, к которым подключена AS. От обоих
приходит FULL VIEW. Нужно сделать одного провайдера основным, а другого -
бакапным. Как назло без дополнительных настроек входящий трафик идёт не через
того провайдера, который нужен. Пытался делать препенды и аннонсировать сетки
с ними через бакапнгого провайдера, но они не помогают. Результат проверяю на
looking glass в Релкоме http://relcom.net/INFO/NOC-IP/lg/lg0.html.
Теперь хочу бакапному провыйдеру анонсировать одну более крупную сеть с
длиной префикса /23, а основному - две сети с префиксами по /24.
Предварительно в RIPE создали объект route на нашу сеть /23. Раньше были
только объекты route c префиксами /24.
Сделал
ip prefix-list backup-list seq 5 permit x.x.x.0/23
ip prefix-list backup-list seq 15 deny 0.0.0.0/0 le 32
!
ip prefix-list main-list seq 5 permit x.x.x.0/23 le 24
ip prefix-list main-list seq 15 deny 0.0.0.0/0 le 32

и применил эти prefix-list к соответствующим пирам в настройках bgp.

В результате получил то, что через основного прова отдаются в инет анонсы
сеток с more specific route, а через бакапного - менее specific. И весь
входящий трафик полился через основного. Смотрел на Looking glass - в
интернете появился анонс нашей сетки с сумарным адресом x.x.x.0/23 и он
анонсируется через бакапного провайдера. Фильтры у провайдеров на наши анонсы
настроены правильно - т.е. принимаются сети и с префиксом /24 и с /23.

Решил потом проделать эксперимент - в BGP положил основного провайдера, для
того, чтобы убедиться, что будет работать бакапный. Но он не работает.
Почему-то не всплывает в интернете адрес нашей сети с префиксом /23.
Может быть ещё какие-нибудь объекты в RIPE нужно создавать? Кто знает,
помогите...

Кросcпост ru_cisco

1:30PM - neighbor allow-as

Добрый день!
Есть несколько филиалов в различных городах России. Все они ходят в интернет, через локальных операторов.
У всех филиалов, один номер автономной системы.
Задача: обеспечить связность филиалов.
На ум приходят три варианта:
1) Фича neighbor allow-as
2) Тунели
3) Перевод каждого региона на собственную АС(это будет сделано несколько позже).

Кто-нить пользовал фичу neighbor allow-as?
Какие подводные камни тут могут быть?
Спасибо!

Кросспосты в ru_cisco, cisco_ru

9:48AM - Анонсирование куска AS

Доброго времени суток!

Возникла необходимость отделить часть автономной системы для использования в другом городе.
Вроде всё понятно, но что-то не заводится iBGP с полпинка. Сам neighbour (роутер D) поднимается, но анонсов от него никаких не приходит. Префикс-листов и as-path-фильтров никаких не настроено.

Заработало после доведения до ума роутера D. Всем спасибо, особенно анонимусам ))

( Схема и конфиги CiscoCollapse )