Pull to refresh

Comments 42

Как всегда всё очень круто. Спасибо!
у вас тоже заняла полчаса только прокрутка статьи? :-)
Ну с учётом, того что 90% написанного мне знакомо то получаса хватило, ага
думаю, читать можно как раз до выхода следующи СДСМ. Респект!
Следующая будет исключительно про iBGP, поэтому, надеюсь, не с таким чудовищным перерывом. Впрочем, после такого маршброска хочется передохнуть.
отдельное спасибо за «route-server.ip.att.net»
вот еще удобный lg lg.he.net/
Предлагаю выписать автору медаль :)
Спасибо, очень неплохая суммаризация знаний в одной статье.

У меня только одно совсем маленькое замечание — BGP не является distance-vector протоколом, он является единственным протоколом семейства path-vector. Да, EIGRP тоже, казалось бы, является не совсем дубовым, однако, его всё же относят к distance-vector, в отличие от BGP. Мелочь, конечно, но тем не менее.
:) кроме вопросов на собеседовании это знание ( какой протокол к какому классу относится) вообще никак мне не помогло в жизни. Раньше циска нас вообще учила что EIGRP — это это такая гибридная няшка.

В копилку ссылок по BGP

bgplay.routeviews.org/ — кто, когда и что анонсировал

telnet route-views.routeviews.org — живая циска с живым BGP, а значит вся мощь регэкспов доступна для выборки анонсов ( sh ip bgp regexp ^123456$)

www.cidr-report.org — смотрим на графики и с ужасом ждем когда количество маршрутов достигнет заветной цифры в 1М

Проект RouterViews в статье упомянут. Ссылка на BGPlay на xgu.ru была, а вот за последнее спасибо.

Безусловно, потому я и сказал, что замечание это совсем маленькое и несущественное.
Спасибо, внесу правочку в статью. Но суть не значительно меняется. Тем более много где BGP называют DV-протоколом.
Виновата некоторая размытость самих терминов плюс появление множества гибридов, которые сложно отнести к тому или иному подтипу.
BGP ведет себя как DV протокол. Он знает лишь метрики до цели через каждое направление, и на основе метрик решает, в каком направлении слать пакеты. Он не в курсе внутренней структуры сети. Именно это и является определяющим критерием.
Правда, метрики BGP отличаются от таковых у любого IGP, да и понимание хопа специфическое. Поэтому кто-то придумал название «path-vector». Это все на самом деле скорее маркетинг.
Точно так же в EIGRP нет вообще ничего гибридного, у него сугубо DV идеология. Кто-то ляпнул «гибрид», потому что то, что раньше понималось под DV (RIP, IGRP) вообще не поддерживало активных соседств.
мы, кстати, писали про это в выпуске про динамическую маршрутизацию. Я там приводил перевод статьи Пепельняка про мифы о EIGRP.
Ну и на самом деле единственным гибридным DV-LS протоколом является… барабанная дробь… OSPF!
а в каком месте у OSPF возникает векторность?
Когда роутит между областями. Он LS только в пределах области.
оок. да. вы правы. не задумывался о том что можно строить цепочки областей.
UFO just landed and posted this here
«Два» — это тоже цепочка, и уже тогда OSPF становится фактически DV протоколом. А можно и «три» без костылей.
а isis? Всегда казался мне братом-близнецом OSPF, только более универсальным и сложным
ISIS — как минимум в меньшей степени. Там L2=>L1 суммаризируется в ноль, областей окромя totally stubby нету. Хотя, в принципе, L1=>L2 остается, но если мне память не изменяет, маршруты от L2 до L1/L2 в соответствующую зону будут просчитываться link-state'но.

А вот с OSPF всё просто. Работа с LSA 3 происходит в точности как у DV протоколов.
Согласен. PV является подмножеством DV, сохраняя его основные свойства. маркетинг чистой воды, согласен. Но, тем не менее:)
Чёрт, я впервые вижу _настолько_ длинную статью :)
Спасибо, как-нибудь надо будет найти время и почитать.
Спасибо! Впервые вижу так по делу и упорядоченно про BGP.
Торгану пожалуй нашим Мопедом.
А что будет если Ростелеком подклчится к RETN? ;)
Ответ на картинке ниже
image

Все проектирование убрано под авторизацию и зарегистрированных пользователей, поскольку задачка вычислительно емкая.
Если вы зарегистрируетесь с почтой своего tech-c, то все security issues будут с full disclosure.

Qrator Radar

IP SLA, конечно же, могучая штука но его работа похожа на фильтрацию входящих маршрутов. То есть вы можете при определённых условиях заставить пойти трафик от вашей сети через хороший маршрут, но в общем случае трафик от сети назначения к вам может точно так же идти через плохой маршрут.

Например. Вы подключены к пиринговой сети, в которой определённый ресурс, скажем, танчики, лучше, чем через имеющихся магистралов. НО! Беда этой пиринговой сети в том, что в ЧНН теряются пакеты и увеличивается пинг. В общем случае это не так заметно, но конкретно танчики начинают не ездить, а прыгать-телепортироваться по полю. Есть возможное решение: задавать comminity с препендом по условию SLA. Но это в том случае, если пиринговая сеть поддерживает comminity с препендом.
IP SLA — это такая универсальная опрашивалка чего угодно, не более того. На ней много чего базируется.

Скажем, с танчиками помог бы и PfR (которому, кстати, может хватить пассивного мониторинга качества транзитных TCP соединений по netflow, без всякого IP SLA). Но… В общем, странная технология. У меня не получилось заставить ее работать предсказуемо, даже на разных моделях одного поколения ISR с одной и той же версией IOS он как-то по-разному себя ведет (я про роль MC). У кого-то получилось с ней подружиться, где-то она работает в продакшне. Однако, мощь PfR колоссальна.
Под балансировкой обычно понимается распределение между несколькими линками трафика, направленного в одну сеть.

Ну говорил я уже, что «распределение между несколькими линками трафика, направленного в одну сеть» — это значит опираться на механизмы CEF, а у CEF не существует понятия «балансировка» («load-balancing»), зато есть «распределение нагрузки» («load-sharing»). Балансировка обычно подразумевает наличие обратной связи, корректирующей поведение алгоритма, а не просто слепое раскидывание туда-сюда на основе четности или нечетности хеша по 5-tuple.

Но да, вопрос холиварный. Скажем, если искать BGP load balancing, то по первой ссылке попадем на cisco.com, где это дело называют load-sharing. Кто-то называет то же самое load-balancing. Мое мнение — в контексте BGP оба термина можно условно назвать взаимозаменяемыми, но не надо говорить «так правильно, а эдак неправильно» :)
Во-первых, замечание о том, что это не единственная точка зрения, я сверху сделал. Во-вторых, такой взгляд существует и имеет на то право. В общем-то вопрос терминологии, и не более.
С последним утверждением согласен.)
UFO just landed and posted this here
Спасибо за очень интересные статьи!

Возник вопрос по разделу 3) Анонс разных префиксов через разных ISP

Если я хочу, чтобы трафик к одним IP-адресам моей AS ходил через одного провайдера, а к другим — через другого (что и обсуждается в разделе), то подсети какого минимального размера я могу анонсировать через BGP, и, соответственно, какой минимальный размер должен быть у AS?

Заранее спасибо!
Сети /25 и меньше блокируют уже почти все крупные провайдеры.
/24 тоже некоторые блокируют, но их анонсируют довольно часто.
Начиная с /23 проблем уже возникнуть не должно.
Спасибо большое!
Не знал, что подсети /24 блокируют… Нашел на одном из форумов следующую реплику: «И вообще сети меньше /22 будут видны не везде. Люди память в руортерах экономят». Так ли это? Или все же с сетями /23, как вы сказали, на практике ни у кого проблем не наблюдается? Могут ли тут быть какие-то негативные тенденции в будущем?
И, я так понимаю, при скромных запросах к размеру AS задачу фиксированных маршрутов к некоторым IP-адресам через определенных провайдеров проще решить не регистрацией более крупной AS и аннонсом ее подсетей через разных провайдеров, а просто арендой пары провайдерозависимых подсетей в дополнение к PI?

И еще хотелось бы уточнить про «вы вполне можете использовать Default Route в дополнение к Full View или Default Route и часть каких-то других маршрутов»:
Если провайдер отдает мне Default Route и, допустим, пару десятков нужных мне маршрутов, то, я так полагаю, нагрузка на мой роутер будет мизерной. Однако, тут не очень нравится то, что если меня заинтересует новый маршрут, то, я так понимаю, мне нужно будет обращаться к провайдерам. Правильно ли я понимаю, что если провайдер будет отдавать мне Full View и Default Route, а я сам будут на входе фильтровать все маршруты кроме Default Route и этой пары десятков интересных мне маршрутов (к нашим удаленным офисам), то нагрузка на мой роутер тоже будет минимальной? Интересуюсь этим в плане проработки вопроса, нужно ли выделять под BGP отдельный маршрутизатор, или же вполне можно поднять BGP на маршрутизаторе, выполняющем роль VPN hub-а, если количество нужных мне маршрутов весьма ограниченно
Промахнулся. Ответил ниже.
UFO just landed and posted this here
Ну вообще, да, согласен, иногда практикуют это.
Я просто вспоминаю ситуацию с YouTube, когда их Пакистан заблокировал. /24 у них распространился гораздо меньше, чем /23.
22 наверняка, да. 23 ещё могут, но редко
Во-первых, да, чтобы не было слишком большой сегментации: 200 маршрутов вместо одного. Во-вторых, чтобы избежать повторения AS 7007 Incident/

По второму вопросу — это не совсем так. Ваш маршрутизатор также будет принимать все маршруты от провайдера, но потом будет фильтровать их.
Разница только в том, что их (ненужных маршрутов) не появится в таблице BGP.

Обычно для BGP всё же выбирается отдельное устройство. По крайней мере если речь о нескольких фул вью.
Спасибо за разъяснения! Подскажите, пожалуйста, а реально ли сейчас вообще получить Pi адреса? Столкнулся с тем, что провайдеры, имеющие статус LIR, либо говорят, что не могут предоставить блок Pi адресов, так как их раздача прекратилась год назад, либо предлагают выделить подсеть из своего блока PA адресов с возможностью создания соответствующего роут обжект в Ripe и анонсирования этой подсети из моей автономной системы.
Я так понимаю, что получить Pi сейчас невозможно? Или может быть вы можете посоветовать каких-либо подходящих LIR-ов? Собственно говоря, на самом деле, учитывая вышесказанное, мне на самом деле граница между Pi и PA видится весьма размытой.
Листал до комментариев и думал… «а они вообще тут есть?… а я точно ОДНУ статью листаю?...» наконец-то долистал. пишу :)
Спасибо, Вам, Уважаемые, за такой труд!

*вслух*только-бы все это жило! и к тому моменту, когда я дойду до этой статьи и весь материал будет валидным на ссылки
Денис, все выпуски СДСМ, а ещё подкасты доступны на сайте linkmeup.ru. В том числе и эта. Там они будут доступны всегда.

А 22-го декабря выйдет статья про MPLS.
Sign up to leave a comment.

Articles