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