Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 42
Как всегда всё очень круто. Спасибо!
думаю, читать можно как раз до выхода следующи СДСМ. Респект!
отдельное спасибо за «route-server.ip.att.net»
вот еще удобный lg lg.he.net/
вот еще удобный lg lg.he.net/
Предлагаю выписать автору медаль :)
Спасибо, очень неплохая суммаризация знаний в одной статье.
У меня только одно совсем маленькое замечание — BGP не является distance-vector протоколом, он является единственным протоколом семейства path-vector. Да, EIGRP тоже, казалось бы, является не совсем дубовым, однако, его всё же относят к distance-vector, в отличие от BGP. Мелочь, конечно, но тем не менее.
У меня только одно совсем маленькое замечание — 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М
В копилку ссылок по BGP
bgplay.routeviews.org/ — кто, когда и что анонсировал
telnet route-views.routeviews.org — живая циска с живым BGP, а значит вся мощь регэкспов доступна для выборки анонсов ( sh ip bgp regexp ^123456$)
www.cidr-report.org — смотрим на графики и с ужасом ждем когда количество маршрутов достигнет заветной цифры в 1М
Спасибо, внесу правочку в статью. Но суть не значительно меняется. Тем более много где BGP называют DV-протоколом.
BGP ведет себя как DV протокол. Он знает лишь метрики до цели через каждое направление, и на основе метрик решает, в каком направлении слать пакеты. Он не в курсе внутренней структуры сети. Именно это и является определяющим критерием.
Правда, метрики BGP отличаются от таковых у любого IGP, да и понимание хопа специфическое. Поэтому кто-то придумал название «path-vector». Это все на самом деле скорее маркетинг.
Точно так же в EIGRP нет вообще ничего гибридного, у него сугубо DV идеология. Кто-то ляпнул «гибрид», потому что то, что раньше понималось под DV (RIP, IGRP) вообще не поддерживало активных соседств.
Правда, метрики BGP отличаются от таковых у любого IGP, да и понимание хопа специфическое. Поэтому кто-то придумал название «path-vector». Это все на самом деле скорее маркетинг.
Точно так же в EIGRP нет вообще ничего гибридного, у него сугубо DV идеология. Кто-то ляпнул «гибрид», потому что то, что раньше понималось под DV (RIP, IGRP) вообще не поддерживало активных соседств.
мы, кстати, писали про это в выпуске про динамическую маршрутизацию. Я там приводил перевод статьи Пепельняка про мифы о EIGRP.
Ну и на самом деле единственным гибридным DV-LS протоколом является… барабанная дробь… OSPF!
а в каком месте у OSPF возникает векторность?
а isis? Всегда казался мне братом-близнецом OSPF, только более универсальным и сложным
ISIS — как минимум в меньшей степени. Там L2=>L1 суммаризируется в ноль, областей окромя totally stubby нету. Хотя, в принципе, L1=>L2 остается, но если мне память не изменяет, маршруты от L2 до L1/L2 в соответствующую зону будут просчитываться link-state'но.
А вот с OSPF всё просто. Работа с LSA 3 происходит в точности как у DV протоколов.
А вот с OSPF всё просто. Работа с LSA 3 происходит в точности как у DV протоколов.
Согласен. PV является подмножеством DV, сохраняя его основные свойства. маркетинг чистой воды, согласен. Но, тем не менее:)
Чёрт, я впервые вижу _настолько_ длинную статью :)
Спасибо, как-нибудь надо будет найти время и почитать.
Спасибо, как-нибудь надо будет найти время и почитать.
Спасибо! Впервые вижу так по делу и упорядоченно про BGP.
Торгану пожалуй нашим Мопедом.
А что будет если Ростелеком подклчится к RETN? ;)
Ответ на картинке ниже
Все проектирование убрано под авторизацию и зарегистрированных пользователей, поскольку задачка вычислительно емкая.
Если вы зарегистрируетесь с почтой своего tech-c, то все security issues будут с full disclosure.
Qrator Radar
А что будет если Ростелеком подклчится к RETN? ;)
Ответ на картинке ниже
Все проектирование убрано под авторизацию и зарегистрированных пользователей, поскольку задачка вычислительно емкая.
Если вы зарегистрируетесь с почтой своего tech-c, то все security issues будут с full disclosure.
Qrator Radar
IP SLA, конечно же, могучая штука но его работа похожа на фильтрацию входящих маршрутов. То есть вы можете при определённых условиях заставить пойти трафик от вашей сети через хороший маршрут, но в общем случае трафик от сети назначения к вам может точно так же идти через плохой маршрут.
Например. Вы подключены к пиринговой сети, в которой определённый ресурс, скажем, танчики, лучше, чем через имеющихся магистралов. НО! Беда этой пиринговой сети в том, что в ЧНН теряются пакеты и увеличивается пинг. В общем случае это не так заметно, но конкретно танчики начинают не ездить, а прыгать-телепортироваться по полю. Есть возможное решение: задавать comminity с препендом по условию SLA. Но это в том случае, если пиринговая сеть поддерживает comminity с препендом.
Например. Вы подключены к пиринговой сети, в которой определённый ресурс, скажем, танчики, лучше, чем через имеющихся магистралов. НО! Беда этой пиринговой сети в том, что в ЧНН теряются пакеты и увеличивается пинг. В общем случае это не так заметно, но конкретно танчики начинают не ездить, а прыгать-телепортироваться по полю. Есть возможное решение: задавать comminity с препендом по условию SLA. Но это в том случае, если пиринговая сеть поддерживает comminity с препендом.
IP SLA — это такая универсальная опрашивалка чего угодно, не более того. На ней много чего базируется.
Скажем, с танчиками помог бы и PfR (которому, кстати, может хватить пассивного мониторинга качества транзитных TCP соединений по netflow, без всякого IP SLA). Но… В общем, странная технология. У меня не получилось заставить ее работать предсказуемо, даже на разных моделях одного поколения ISR с одной и той же версией IOS он как-то по-разному себя ведет (я про роль MC). У кого-то получилось с ней подружиться, где-то она работает в продакшне. Однако, мощь PfR колоссальна.
Скажем, с танчиками помог бы и 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 оба термина можно условно назвать взаимозаменяемыми, но не надо говорить «так правильно, а эдак неправильно» :)
Спасибо за очень интересные статьи!
Возник вопрос по разделу 3) Анонс разных префиксов через разных ISP
Если я хочу, чтобы трафик к одним IP-адресам моей AS ходил через одного провайдера, а к другим — через другого (что и обсуждается в разделе), то подсети какого минимального размера я могу анонсировать через BGP, и, соответственно, какой минимальный размер должен быть у AS?
Заранее спасибо!
Возник вопрос по разделу 3) Анонс разных префиксов через разных ISP
Если я хочу, чтобы трафик к одним IP-адресам моей AS ходил через одного провайдера, а к другим — через другого (что и обсуждается в разделе), то подсети какого минимального размера я могу анонсировать через BGP, и, соответственно, какой минимальный размер должен быть у AS?
Заранее спасибо!
Сети /25 и меньше блокируют уже почти все крупные провайдеры.
/24 тоже некоторые блокируют, но их анонсируют довольно часто.
Начиная с /23 проблем уже возникнуть не должно.
/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-а, если количество нужных мне маршрутов весьма ограниченно
Не знал, что подсети /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-а, если количество нужных мне маршрутов весьма ограниченно
22 наверняка, да. 23 ещё могут, но редко
Во-первых, да, чтобы не было слишком большой сегментации: 200 маршрутов вместо одного. Во-вторых, чтобы избежать повторения AS 7007 Incident/
По второму вопросу — это не совсем так. Ваш маршрутизатор также будет принимать все маршруты от провайдера, но потом будет фильтровать их.
Разница только в том, что их (ненужных маршрутов) не появится в таблице BGP.
Обычно для BGP всё же выбирается отдельное устройство. По крайней мере если речь о нескольких фул вью.
Во-первых, да, чтобы не было слишком большой сегментации: 200 маршрутов вместо одного. Во-вторых, чтобы избежать повторения AS 7007 Incident/
По второму вопросу — это не совсем так. Ваш маршрутизатор также будет принимать все маршруты от провайдера, но потом будет фильтровать их.
Разница только в том, что их (ненужных маршрутов) не появится в таблице BGP.
Обычно для BGP всё же выбирается отдельное устройство. По крайней мере если речь о нескольких фул вью.
Спасибо за разъяснения! Подскажите, пожалуйста, а реально ли сейчас вообще получить Pi адреса? Столкнулся с тем, что провайдеры, имеющие статус LIR, либо говорят, что не могут предоставить блок Pi адресов, так как их раздача прекратилась год назад, либо предлагают выделить подсеть из своего блока PA адресов с возможностью создания соответствующего роут обжект в Ripe и анонсирования этой подсети из моей автономной системы.
Я так понимаю, что получить Pi сейчас невозможно? Или может быть вы можете посоветовать каких-либо подходящих LIR-ов? Собственно говоря, на самом деле, учитывая вышесказанное, мне на самом деле граница между Pi и PA видится весьма размытой.
Я так понимаю, что получить Pi сейчас невозможно? Или может быть вы можете посоветовать каких-либо подходящих LIR-ов? Собственно говоря, на самом деле, учитывая вышесказанное, мне на самом деле граница между Pi и PA видится весьма размытой.
Листал до комментариев и думал… «а они вообще тут есть?… а я точно ОДНУ статью листаю?...» наконец-то долистал. пишу :)
Спасибо, Вам, Уважаемые, за такой труд!
*вслух*только-бы все это жило! и к тому моменту, когда я дойду до этой статьи и весь материал будет валидным на ссылки
Спасибо, Вам, Уважаемые, за такой труд!
*вслух*только-бы все это жило! и к тому моменту, когда я дойду до этой статьи и весь материал будет валидным на ссылки
Денис, все выпуски СДСМ, а ещё подкасты доступны на сайте linkmeup.ru. В том числе и эта. Там они будут доступны всегда.
А 22-го декабря выйдет статья про MPLS.
А 22-го декабря выйдет статья про MPLS.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сети для самых маленьких. Часть восьмая. BGP и IP SLA