Border Gateway Protocol

фильтрация исходящего трафика

tupoy — Wed, 08 Sep 2010 11:47:24 GMT

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

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

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

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

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

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

--
crossposted to ru_cisco

Разный origin

gul_kiev — Wed, 17 Feb 2010 20:00:33 GMT

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

sha90w — Tue, 17 Nov 2009 09:14:27 GMT

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

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

baspr — Fri, 04 Sep 2009 05:58:39 GMT

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

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

ovcehuev — Sat, 25 Jul 2009 14:12:06 GMT

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

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

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

dei_os — Mon, 15 Jun 2009 12:24:31 GMT

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

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

l2tp — Wed, 13 May 2009 08:19:17 GMT

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


*>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-овского диапазона, и вообще для всех?

ARIN search result:


ReferralServer: rwhois://rwhois.gin.ntt.net:4321/

ASNumber:   97  
ASName:     NTTA-97 
ASHandle:   AS97 
Comment:     
RegDate:    1999-12-06
Updated:    2005-12-30

RIPE search result:


% Information related to '195.88.112.0/23AS196705'

route:          195.88.112.0/23
descr:          Ardinvest
origin:         AS196705
mnt-by:         ARDINVEST-MNT
source:         RIPE # Filtered
remarks:        asdot to asplain conversion

route deaggregation

azerole — Wed, 22 Apr 2009 10:12:17 GMT

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

azerole — Tue, 17 Mar 2009 20:40:47 GMT

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

azerole — Tue, 03 Mar 2009 09:08:25 GMT

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

azerole — Thu, 15 Jan 2009 15:17:56 GMT

Добрый день,

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

azerole — Mon, 22 Dec 2008 19:43:45 GMT

Добрый день,

Несколько немного очевидных, наверное, вопросов про функционирование 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?

kaa — Fri, 14 Nov 2008 17:38:33 GMT

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

Маршрутизация в Интернет. "Разорванная" AS.

lesnix — Mon, 23 Jun 2008 19:30:21 GMT

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

Допустим, есть блок ALLOCATED PA 80.0.48.0/20. Почему нельзя разместить "две части одной AS" в разных точках и анонсировать отдельные префиксы соответствующим апстримам ? А может, всё-таки можно ?

crosspost cisco_ru

Mikrotik rb-1000, routeros 3.3 / BGP / AS / 2 ISP

mikhajjlovskijj — Tue, 27 May 2008 11:24:38 GMT

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

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

Спасибо.

lesnix — Tue, 22 Apr 2008 21:56:49 GMT

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

foundry bgp

trias — Sun, 02 Dec 2007 10:20:57 GMT

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

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

ex_callmepli228 — Tue, 20 Nov 2007 10:24:36 GMT

Добрый день.

Есть автономная система и блок провайдернонезависимых адресов (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

neighbor allow-as

shurskiy — Mon, 12 Nov 2007 10:30:26 GMT

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

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

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

Анонсирование куска AS

pfka_mu — Fri, 05 Oct 2007 06:02:09 GMT

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

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

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

Схема похожа вот на эту, только между роутерами B и D не EIGRP, а статика (через VPN MPLS).
Конфиг роутера B:
router bgp 45000
bgp log-neighbor-changes
timers bgp 20 60
neighbor 192.168.1.2 remote-as 40000
neighbor 192.168.1.2 update-source Loopback0
neighbor 172.22.1.2 remote-as 45000
neighbor 172.22.1.2 description iBGP Peer
neighbor 172.22.1.2 update-source Loopback0
!
address-family ipv4
neighbor 192.168.1.2 activate
neighbor 192.168.1.2 weight 10000
neighbor 172.22.1.2 activate
neighbor 172.22.1.2 weight 10000
default-information originate
distance bgp 20 150 200
no auto-summary
synchronization
network 172.16.0.0 mask 255.255.0.0
exit-address-family

Роутер D:

router bgp 45000
bgp log-neighbor-changes
timers bgp 20 60
neighbor 172.16.1.1 remote-as 45000
neighbor 172.16.1.1 description iBGP peer
!
address-family ipv4
neighbor 172.16.1.1 activate
distance bgp 20 150 200
no auto-summary
synchronization
network 172.18.0.0 mask 255.255.0.0
exit-address-family

Балансинг(Шаирнг)

shurskiy — Thu, 20 Sep 2007 11:57:01 GMT

День добрый!

Есть 2 провайдера. С каждым по 2 сессии. Одна - канал по трафику. Вторая - Безлимитный.
С каналами по трафику все здорово и понятно.
Там мне не надо балансировать ничего.
С безлимитными ситуация такая:
Канал А 10 мегабит, канал Б 50 мегабит. Очень хочется распределить между ними нагрузку. Чтобы небыло такого, что А - загружен на 100%, а Б - 1%.
Чтобы загрузка распределялась.
Нашел такое решение:
bgp dmzlink-bw
neighbor А dmzlink-bw
neighbor Б dmzlink-bw
maximum-path 2

Вводные: каналы А и Б - от разных провайдеров(разные автономные системы соответственно), при этом у всех(и каналов по трафику и безлимитных каналов) одинаковые парамерты: вес, стоимость, локалпреф, мед.
Если я так сделаю, как поведут себя каналы щпо трафику?
Какие могут возникнуть проблемы?
И если это решение не подходит(является в корне не верным) какие еще можно рассмотреть решения?
У меня все крутить на роутере цыска 7301.
Спасибо.

Вопрос про ip sla monitor

shurskiy — Fri, 24 Aug 2007 11:23:11 GMT

Пришлось отказаться от идеи VRF ввиду непрозрачности и некоторого гемора в обслуживании(потому что отдаем потом местным региональным парням).
Настраиваю ip sla monitor.
Вот, что получилось:
ip sla monitor 168
type tcpConnect dest-ipaddr x.x.x.x dest-port 179 source-ipaddr x.x.x.y control disable
timeout 2000
tag RT_LIMIT_OUT
ip sla monitor schedule 168 life forever start-time now
track 168 rtr 168
delay down 10 up 20

или

ip sla monitor 168
type echo protocol ipIcmpEcho x.x.x.x source-ipaddr x.x.x.y
timeout 2000
tag RT_LIMIT_OUT
ip sla monitor schedule 168 life forever start-time now
track 168 rtr 168
delay down 10 up 20

На мой взгляд, правильнее конечно мониторить 179 порт, потому как у нас есть BGP. Тут возникает вопрос, когда настраиваешь route-map.
Есть там такая строчка: set ip next-hop verify-availability x.x.x.x track 168
verify-availability - смотрит лишь изменения состояния в track и по стейту переключает на тот или иной хоп трафик?
Или эта фича работает только тогда, когда у нас в мониторе писано: type echo protocol ipIcmpEcho ?

Одна сеть два провайдера

shurskiy — Mon, 13 Aug 2007 11:57:59 GMT

Добрый день!
Есть задача реализовать следующую схему:
<ISP1>-----BGP-----<MY_BGW>-----BGP-----<ISP2>
С каждым ISP есть по два канала: Один безлимитный и один, который считается по трафику.
Есть два типа клиентов:
1)С тарифами, где считается трафик - отправляются в канал по трафику(там качество обслуживания лучше).
2)С безлимитными тарифами - отправляются в безлимитный канал.
Мне выделены сети x.y.z.0/22.
Сейчас разбито так:
x.y.1.0/24 - нат для клиентов по трафику
x.y.2.0/24 - нат для безлимитных клиентов.
Остальное под служебное пользование и резерв.

С такой схемой включения надо реализовать балансировку каналов: по трафику отдельно, безлимитных отдельно.
Как сделать?

path-mtu-discovery

vovka_on_ip — Tue, 12 Dec 2006 09:43:59 GMT

Всем привет!
Может кто-нибудь пояснить про path-mtu-discovery? На всех ibgp-х нейборах у меня в сети почему-то максимальный размер датаграмм 536 байт, хотя везде присутствует глобальная команда
ip tcp path-mtu-discovery. Маршрутизаторы воткнуты в каталисты, в одном влане. Не знаю, куда копать, потому как на стенде, где три рутера воткнуты в один каталист, для всех bgp- сессий максимальный размер 1460 байт.

BGP Community Question!

mrrr — Tue, 26 Sep 2006 17:53:09 GMT

Есть такая ситуация. Я - провайдер, имеющий автономную систему и двух аплинков, тоже с автономными системами. Так же, у меня есть клиент, тоже с автономной системой. Он просит предоствить ему bgp-coommunity, для балансировки _его_ трафика между двумя _моими_ аплинками, путем аннонсирования различным аплинкам своих различных префиксов, с различным числом препендов. Собственно вопрос - как это реализовать ? О всяких ip community-list и match community в route-map'ах я знаю, но как-то все это в голове не складывается вместе... По этому поводу - help\снимите_с_ручного_тормоза :)