Комментарии 70
Переходить на IPv6 всё равно придётся, как ни крути и не тяни.
P.S. В качестве временного костыля можно выкроить память за счёт урезания таблиц для IPv6. Но это требует перезагрузки маршрутизатора.
То-то мой провайдер на прошлой неделе объяснял перерывы в обслуживании перезагрузками оборудования.
P.S. В качестве временного костыля можно выкроить память за счёт урезания таблиц для IPv6. Но это требует перезагрузки маршрутизатора.
То-то мой провайдер на прошлой неделе объяснял перерывы в обслуживании перезагрузками оборудования.
если вы не магистрал, то есть более простой «костыль», фильтровать все /24 сети, таблица full-view сразу похудеет на 30-40%. Если важна локальная связность, то оставить /24 анонсы от своих пиров, и от соседей своих пиров.
Почти уверен, что при таком сетапе все будет нормально работать. Я так делал несколько лет назад, когда в 256k пытался full-view поместить.
Почти уверен, что при таком сетапе все будет нормально работать. Я так делал несколько лет назад, когда в 256k пытался full-view поместить.
А зачем нужны FullView не-магистралям?
Full-view может быть нужен:
— владельцам AS;
— владельцам ДЦ;
— организаторам CDN;
— организаторам анти-DDOS систем;
По факту, каждый ДЦ крупной компании держит у себя шлюз с full-view.
— владельцам AS;
— владельцам ДЦ;
— организаторам CDN;
— организаторам анти-DDOS систем;
По факту, каждый ДЦ крупной компании держит у себя шлюз с full-view.
а вот расскажите, плиз, вот у меня AS обычная минимальная (/22), и небольшой парк аттракционов в 300 машин.
у меня есть 3 аплинка. вопрос — зачем мне может понадобиться full view?
я правда пытаюсь понять, немного незнакомая область.
у меня есть 3 аплинка. вопрос — зачем мне может понадобиться full view?
я правда пытаюсь понять, немного незнакомая область.
Для поиска лучшего, из ваших трёх, маршрута. При большой нагрузке каналов может быть полезно, если оборудование потянет.
Вот быстро-найденная в гугле ссылка по теме: link.
Вот быстро-найденная в гугле ссылка по теме: link.
Стоит уточнить, что «поиска лучшего» для исходящего трафика. Для входящего трафиком можно управлять лишь довольно ограниченно — препендами, BGP community или локальными preference, но это все уже часто идет как черная магия =)
А кто сказал, что он лучший?
Если у него самый короткий AS-PATH, то это далеко не означает, что связь по этому линку будет самой быстрой.
Это получается самый настоящий рандом. С тем же успехом можно принимать от всех дефолт и балансировать «как бог на душу положит», per-flow.
Если у него самый короткий AS-PATH, то это далеко не означает, что связь по этому линку будет самой быстрой.
Это получается самый настоящий рандом. С тем же успехом можно принимать от всех дефолт и балансировать «как бог на душу положит», per-flow.
Вы поднимаете вопрос «BGP не всегда выбирает лучший путь и не оценивает емкость каналов». Путь с более коротким as path может быть перегружен, поврежден или вообще быть неработоспособным. Да, это так, но все это можно реализовать поверх BGP кастомным софтом (Traffic Enginteering тулкиты) который будет делать препенды, выставлять коммунити и обдумывать, куда и как пустить трафик лучше. Но делать это без полных таблиц — задача мягко говоря нерешаемая.
Ну почему нерешаемая? Что мешает получить таблицу, например, с какого-нибудь постороннего looking glass? Ведь требуется знать лишь префиксы, даже AS PATH не особо нужен (если мы считаем, что он ничего не говорит о качестве пути). И даже это не особо важно. Можно по умолчанию считать, что все префиксы — скажем, /24. Или /16. Суть не меняется.
Дальше. Допустим, есть два канала, и поток рандомом попал на первый. Надо следить за его состоянием. Подобные механизмы уже есть в продвинутых роутерах — netflow следит за сиквенсами и может обнаруживать ретрансмиты. На всякий случай для проверки запускаем несколько быстрых пингов. Если и они теряются, то можно запустить их через второй канал. Если там потерь нет — инжектируем в FIB маршрут на longest match префикс, взятый с того looking glass.
И есть еще один момент. Вы можете брать у провайдера full view, держать его в таблице BGP и раздавать соседям. Но никто не заставляет программировать его себе в FIB :) А если не программировать — ускорение обработки получается многократное, особенно на аппаратных платформах, где TCAM чертовски тормозной на запись.
Дальше. Допустим, есть два канала, и поток рандомом попал на первый. Надо следить за его состоянием. Подобные механизмы уже есть в продвинутых роутерах — netflow следит за сиквенсами и может обнаруживать ретрансмиты. На всякий случай для проверки запускаем несколько быстрых пингов. Если и они теряются, то можно запустить их через второй канал. Если там потерь нет — инжектируем в FIB маршрут на longest match префикс, взятый с того looking glass.
И есть еще один момент. Вы можете брать у провайдера full view, держать его в таблице BGP и раздавать соседям. Но никто не заставляет программировать его себе в FIB :) А если не программировать — ускорение обработки получается многократное, особенно на аппаратных платформах, где TCAM чертовски тормозной на запись.
Ок, допустим, берем базу роутинга вообще с RIR, там все подсети, все ASN. Но пока система обучится на трафике и научится не посылать, скажем, трафик на Азию в Level3, может пройти очень много времени. А кастомеры будут страдать.
Да и как быть — если у трафика нет ретранзмитов в том же UDP? Никакой обратной связи кроме как явно проверять каждый канал. AS-PATH очень часто дает совершенно правильные рекомендации, зачем от него обдуманно отказываться и городить что-то явно менее надежное? BGP воткнул и забыл, все :)
Я бы работал все же поверх полной таблицы и уже строил эвристику поверх нее — слежение за ретранзмитами, контроль rtt по наиболее популярным целевым ASN, оценка уровня вернувшихся ретранзмитов и уровня потерь в канале. И на основании этих метрик уже подключал локальные предпочтения на определенные ASN.
Ну в FIB так или иначе хранится 1 таблица собранная из лучших маршрутов, будь Full Table даже сто штук =)
Да и как быть — если у трафика нет ретранзмитов в том же UDP? Никакой обратной связи кроме как явно проверять каждый канал. AS-PATH очень часто дает совершенно правильные рекомендации, зачем от него обдуманно отказываться и городить что-то явно менее надежное? BGP воткнул и забыл, все :)
Я бы работал все же поверх полной таблицы и уже строил эвристику поверх нее — слежение за ретранзмитами, контроль rtt по наиболее популярным целевым ASN, оценка уровня вернувшихся ретранзмитов и уровня потерь в канале. И на основании этих метрик уже подключал локальные предпочтения на определенные ASN.
Ну в FIB так или иначе хранится 1 таблица собранная из лучших маршрутов, будь Full Table даже сто штук =)
>Но пока система обучится на трафике и научится не посылать, скажем, трафик на Азию в Level3
Если у вас на одной площадке два провайдера, то можно предположить, что у них будет очень схожая связность. И вряд ли вы напрямую с Level3 стыкуетесь. И ваш провайдер вряд ли :) А что сделает с вашим пакетом провайдер — ему решать.
>Да и как быть — если у трафика нет ретранзмитов в том же UDP?
UDP трафика мало. И ESP мало. И GRE. Основной трафик интернета — TCP. То есть большинство случаев покрыто. Правда, остается вопрос с полным пропаданием связности с определенными AS через текущего провайдера. Это как раз где full view вообще незаменим. Ну или если через текущий канал нет отклика на SYN — умная система должна повторный SYN выплюнуть в другой канал.
>AS-PATH очень часто дает совершенно правильные рекомендации, зачем от него обдуманно отказываться
Но выше обсуждалось, что он ничего не говорит о реальном качестве трассы. И как только вы передали пакет провайдеру — вы полностью теряете над ним контроль. И вообще, мы тут фантазируем, изобретаем новые подходы… Или не такие уж новые, потому что большинство названного мной уже есть в продаваемом в данный момент железе.
>Ну в FIB так или иначе хранится 1 таблица собранная из лучших маршрутов
Ну пожалуй случаи разнесения таблиц по VRF рассматривать не будем, так что да. Но топик-то про то, что и 500к маршрутов для многих проблема.
Если у вас на одной площадке два провайдера, то можно предположить, что у них будет очень схожая связность. И вряд ли вы напрямую с Level3 стыкуетесь. И ваш провайдер вряд ли :) А что сделает с вашим пакетом провайдер — ему решать.
>Да и как быть — если у трафика нет ретранзмитов в том же UDP?
UDP трафика мало. И ESP мало. И GRE. Основной трафик интернета — TCP. То есть большинство случаев покрыто. Правда, остается вопрос с полным пропаданием связности с определенными AS через текущего провайдера. Это как раз где full view вообще незаменим. Ну или если через текущий канал нет отклика на SYN — умная система должна повторный SYN выплюнуть в другой канал.
>AS-PATH очень часто дает совершенно правильные рекомендации, зачем от него обдуманно отказываться
Но выше обсуждалось, что он ничего не говорит о реальном качестве трассы. И как только вы передали пакет провайдеру — вы полностью теряете над ним контроль. И вообще, мы тут фантазируем, изобретаем новые подходы… Или не такие уж новые, потому что большинство названного мной уже есть в продаваемом в данный момент железе.
>Ну в FIB так или иначе хранится 1 таблица собранная из лучших маршрутов
Ну пожалуй случаи разнесения таблиц по VRF рассматривать не будем, так что да. Но топик-то про то, что и 500к маршрутов для многих проблема.
> (Traffic Enginteering тулкиты)
Подскажите, пожалуйста, названия или ключевые слова по которым искать, а то «в лоб» не гуглится.
в опенсорсе есть что нибуть?
Подскажите, пожалуйста, названия или ключевые слова по которым искать, а то «в лоб» не гуглится.
в опенсорсе есть что нибуть?
Если у вас его нет, то вам в связности приходится полагаться на провайдеров. А они далеко не всегда говорят правду о качестве доступа. В случае full view можно крутить на своей стороне.
Если Вы хотите балансировать исходящий трафик равномерно по трем магистралям без костыльного/велосипедного огорода с маршрутами и распределенеим нагрузки, если Вы хотите получать быстрый и мягкий failover в случае отвала одного из аплинков, если Вы хотите управлять трафиком силами BGP препендов на уровне ASN, а не костылей с ручной обработкой префиксов — Full table BGP Ваш выбор :)
Но обращаю внимание, что Full Table/Full view нужен именно в случае когда много ИСХОДЯЩЕГО трафика. Для обычного провайдера (с 90% входящего трафика) это совершенно не нужно и можно обойтись костыльным скриптиком фейлавера.
Но обращаю внимание, что Full Table/Full view нужен именно в случае когда много ИСХОДЯЩЕГО трафика. Для обычного провайдера (с 90% входящего трафика) это совершенно не нужно и можно обойтись костыльным скриптиком фейлавера.
Вот я так себе и представлял это. Спасибо.
Это что за «обычный» провайдер где 90% входящего трафика? Уже давно у ФШПД-операторов связи исходящий трафик равен входящему, если не превышает его.
Исключениями могут являться только операторы связи с превалирующей долей B2B или B2G клиентов.
Исключениями могут являться только операторы связи с превалирующей долей B2B или B2G клиентов.
Ну хорошо, хорошо :) Но суть тут не столько в том, что трафика больше, а в том, что обычному клиенту провайдера исходящая скорость обычно пофигу. А вот входящая — ой как критична. У ДЦ — обычно наоборот, важна скорость отдачи. Отсюда и растет вся оптимизция и ее методы. В общем случае, разумеется, нужно оптимизировать и то и другое одновременно.
Если у вас от ваших аплинков приходит только default route, сделать нормальную балансировку исходящего трафика не получится, будет active/standby. Входящий будет балансирован в зависимости от связности самих аплинков с внешним миром.
В вашем случае фулл может и понадобится, если парк аттракционов имеет разнообразные корпоративные VPN с требованиями предпочтения маршрутов.
>Проблемы с доступом возникли, в частности, у Comcast, LastPass и eBay, местами недоступны российские ресурсы.
А кто-нибудь из них говорил, что проблема именно в этой идиотской ошибке? Неужели оставались люди хоть с теми же 6500 без XL, принимающие full view? И пару лет назад дураку было понятно, что это — бомба, которая неизбежно рванет в очень недалеком будущем, надо срочно что-то делать.
А кто-нибудь из них говорил, что проблема именно в этой идиотской ошибке? Неужели оставались люди хоть с теми же 6500 без XL, принимающие full view? И пару лет назад дураку было понятно, что это — бомба, которая неизбежно рванет в очень недалеком будущем, надо срочно что-то делать.
Добавил ссылки-источники в статью. Проблема именно в переполнении таблицы маршрутов. Но дело не в конкретной баге конкретного каталиста — большое количество старых моделей не держат full-view такого размера.
Без XL — это 256к маршрутов.
XL — это 1М. Но!!!
Этот 1М делится ресурсно на 512К по умолчанию для IPv4 и 256к для IPv6.
Есть процедура, которая меняет соотношение TCAM для IPv4/IPv6 — для 6500 платформы.
Результат работы процедуры пока не ясен.
XL — это 1М. Но!!!
Этот 1М делится ресурсно на 512К по умолчанию для IPv4 и 256к для IPv6.
Есть процедура, которая меняет соотношение TCAM для IPv4/IPv6 — для 6500 платформы.
Результат работы процедуры пока не ясен.
FV нужен только для транзита. Ну а те, кто бордеры строит на 7600 сами себе злые буратины.
У многих бордеры на ASR, а они держат 1М маршрутов только с 8Гб памяти
То-есть получается RP1 встроенный в ASR1002 можно выкинуть на помойку?
Он поддерживает только 4 GB
Он поддерживает только 4 GB
Вы говорите про 1002-F? Это единственная fixed-железка линейки ASR, которая имеет «настоящий» RP1 внутри. Соответственно, все нижесказанное, относится и к ней.
Классический RP1, вставляемый во взрослые железки, можно протюнить за счет IPv6:
● Scalability up to 1,000,000 IPv4 routes or 500,000 IPv6 routes
● BGP RR Scalability up to 5,000,000 IPv4 routes or 3,000,000 IPv6 routes
Cisco ASR 1001, хотя в нем и заявлен встроенный RP1, по факту поддерживает 8Gb памяти, и, соответственно, смотрит на проблему свысока.
Cisco ASR 1002-X имеет RP очень похожий на тот, что встроен в 1001й, соответственно тоже проблеме не подвержен при наличии денег на апгрейд памяти.
Классический RP1, вставляемый во взрослые железки, можно протюнить за счет IPv6:
● Scalability up to 1,000,000 IPv4 routes or 500,000 IPv6 routes
● BGP RR Scalability up to 5,000,000 IPv4 routes or 3,000,000 IPv6 routes
Cisco ASR 1001, хотя в нем и заявлен встроенный RP1, по факту поддерживает 8Gb памяти, и, соответственно, смотрит на проблему свысока.
Cisco ASR 1002-X имеет RP очень похожий на тот, что встроен в 1001й, соответственно тоже проблеме не подвержен при наличии денег на апгрейд памяти.
А чем плох 7600 для бордера? Мне вот мой еще год назад стал ругаться в логи, что емкость таблицы маршрутизации заполнена на 90% и желательно бы ее увеличить, что и было сделано. А вот те, кто логи не читает, те и есть ССЗБ.
Очень медленная работа с BGP. Никогда не пробовали использовать его с тремя-четырьмя FV? А если есть еще и iBGP пир которому надо FV транслировать, да если там еще и MP-BGP стык, то конвергенция может затянуться на пол-часа
Видимо что-то вы путаете. На RSP720-3CXL 4-5 FV пиров, 5 стыков с IX и пара MP-BGP стыков сходятся за пару минут, как раз такая конфигурация у меня сейчас.
Странно. У меня на RSP720-3CXL-GE проблемы вызывали два FV пира, два IX + MP-BGP до второго бордера. После банального switchover'а RSP, BGP в норму приходил очень долго. примерно по 3-4 минуты на подсос одного FV, потом еще минут 5 на подсчет best-routes и заполнение TCAM
Где-то я встречал описание подобной проблемы при использовании какой-то определенной версии прошивки. На c7600rsp72043-adventerprisek9-mz.152-4.S4a.bin у меня все работает так, как я описал выше.
#show ver | i image
System image file is «disk0:c7600rsp72043-advipservicesk9-mz.152-4.S4a.bin»
забавно.
System image file is «disk0:c7600rsp72043-advipservicesk9-mz.152-4.S4a.bin»
забавно.
Может быть тогда ваши пиры медленно вам отдают BGP?
Все сразу? маловероятно. да и конвергенция со вторым MP-BGP бордером (Juniper MX80) не быстрее, а он явно отдает маршруты быстро.
На сколько я знаю MX80 переваривает в пике 1.6М маршрутов всего на IPv4, после этого начинает страшно тормозить, так что если на нем 4FV я бы поспорил с тем, что он отдает их быстро.
Ну тогда мне остается развести руками, я вам говорю то, что у меня есть. Может быть вы сильно преувеличиваете, может быть я преуменьшаю. Т.е. в первом сообщении вы писали про полчаса конвергенции, а ниже уже про 3-4 минуты на два FV и 5 минут на заполнение TCAM, что вместе дает 11-13 минут. Я говорю про пару минут, но я никогда не замерял, и это легко может быть 4-5 минут. Соответственно истина где-то посередине. И я действительно замечал случаи, когда пиры отдавали медленно BGP анонсы, один отдавал за 10 минут, второй за 20-30 секунд. Может быть вам действительно не повезло с пирами FV, мои отдают в среднем за 30-40 секунд.
Что-то не нашел я где написано про проблемы с ASR9K… С какой стати они должны быть вообще?
У Вас используется т.н. default profile на картах A9K-8T-L и A9K-40GE-L (см. sh hw-module profile scale), и он поддерживает 512 K Layer 3 CEF маршрутов.
Его желательно поменять на L3 на всех Trident картах (как вышеизложенные):
www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.2/system_management/configuration/guide/b_sysman_cg42asr9k_chapter_01.html
Данное изменение требует перезагрузки модулей, поэтому после установки SMU, сделайте и это изменение в конфигурации.
PS конечно желательно подобное перепроверить для каждого узла и каждой карты — возможно где-то крайне важно количество ресурсов для L2.
Его желательно поменять на L3 на всех Trident картах (как вышеизложенные):
www.cisco.com/en/US/docs/routers/asr9000/software/asr9k_r4.2/system_management/configuration/guide/b_sysman_cg42asr9k_chapter_01.html
Данное изменение требует перезагрузки модулей, поэтому после установки SMU, сделайте и это изменение в конфигурации.
PS конечно желательно подобное перепроверить для каждого узла и каждой карты — возможно где-то крайне важно количество ресурсов для L2.
Ощутил сегодняшие сбои по полной программе, как раз решил на ночь остаться поработать в кой то веки и на тебе, думал интернет прикрыли и приехали =)
Половина ресурсов включая мой сервер не маршрутизировались, Google и Яндекс работали на ура.
Половина ресурсов включая мой сервер не маршрутизировались, Google и Яндекс работали на ура.
512К будет достаточно всем?
А если без шуток — можно для непосвященных, почему в наш век гигабайтов оперативной памяти на этих недешевых железках так мало памяти под FV? Там какая-то особая память, которая не может быть заменена DDR/GDDR?
Заменять старое оборудование никто не хочет. Серии 6500 уже 15 лет скоро. Работает — не трогай. Новость о том, что работать перестало.
Да, там именно что особенная память, TCAM. Она физически огромная, по объему мизерная, бешено дорогая, жрет кучу энергии, но есть причины, по которым в высокопроизводительных роутерах ее не заменишь на DDR.
1) DDR на вход получает адрес ячейки и на выходе выдает значение в этой ячейке. TCAM получает на вход строку, а на выходе результат поиска по маске по этой строке. Так как работает с подобной памятью ASIC — огромное благо, что в него не требуется закладывать сложные алгоритмы для быстрого поиска по RAM. Всего-то надо, грубо говоря, вытащить IP адрес из пакета по такому-то смещению, передать его в TCAM, получить ответ — что с пакетом делать, и готово.
2) TCAM выполняет этот поиск офигительно быстро. Благодаря этому еще во времена DDR2 уже можно было маршрутизировать сотни миллионов pps (что подразумевает сотни миллионов поисков в секунду и превращается в сотни гигабит трафика в секунду).
1) DDR на вход получает адрес ячейки и на выходе выдает значение в этой ячейке. TCAM получает на вход строку, а на выходе результат поиска по маске по этой строке. Так как работает с подобной памятью ASIC — огромное благо, что в него не требуется закладывать сложные алгоритмы для быстрого поиска по RAM. Всего-то надо, грубо говоря, вытащить IP адрес из пакета по такому-то смещению, передать его в TCAM, получить ответ — что с пакетом делать, и готово.
2) TCAM выполняет этот поиск офигительно быстро. Благодаря этому еще во времена DDR2 уже можно было маршрутизировать сотни миллионов pps (что подразумевает сотни миллионов поисков в секунду и превращается в сотни гигабит трафика в секунду).
Никак не укладывается в голове что Cisco ASR 9000 и Cisco ASR 1000 — это «старые маршрутизаторы».
У меня тоже не укладывается. Вот CRS1 меня недавно огорчил, потушил соседа при достижении дефолтного максимума потому, что не было настройки «maximum-prefix 524288 95 warning-only»
:) Продолжая цепочку скажу, что меня ASR1k удивил тем, что ему нужны просто «гиги» памяти чтобы fullview в себе держать. Как они умудрились?
Так он же на IOS-XE работает. Например: зависит от RP, но в среднем IOSd получает около половины от всей имеющейся в коробке памяти. Если включен software redundancy, то вообще четверть.
И уж если вас ASR1k удивлял только этим — люто завидую. Я сталкивался с кучей ограничений, которые даже TAC удивляли и продолжают удивлять. Например, нельзя снять capture с саба port-channel'а, но можно снять capture c GRE туннеля, опирающегося на тот саб port-channel'a, а также с саба физического интерфейса или с самого port-channel'а. Вот это я понимаю…
И уж если вас ASR1k удивлял только этим — люто завидую. Я сталкивался с кучей ограничений, которые даже TAC удивляли и продолжают удивлять. Например, нельзя снять capture с саба port-channel'а, но можно снять capture c GRE туннеля, опирающегося на тот саб port-channel'a, а также с саба физического интерфейса или с самого port-channel'а. Вот это я понимаю…
Ну ок. Два гига памяти. Этого мало на fullview? ;)
А что по другому — так это выглядит софтварными «фичами» для меня. Когда платформа будет такой же старой как 7200 — все там будет стабильно и понятно.
А что по другому — так это выглядит софтварными «фичами» для меня. Когда платформа будет такой же старой как 7200 — все там будет стабильно и понятно.
А причем тут full view? RP2 вообще из коробки идет с 2гб памяти. Да и что такое 2гб RAM? Сейчас в среднем мобильнике столько, а мы говорим про линейку маршрутизаторов, младшие из которых стоят как средний автомобиль :) RP2 расширяется до 16гб памяти, а 64-битный IOS-XE способен адресовать их все. И в роли RR, насколько я помню, ASR1k вполне уверенно пережевывал 30m маршрутов.
7200? Стабильно? Понятно? Это что, шутка? По сравнению с этой платформой даже ASR1k — эталон стабильности и предсказуемости. Мы когда-то отказались от 7200, когда надоело разбираться, почему он демонстрирует производительность в несколько раз ниже, чем должен был бы с задействованными на нем фичами, и TAC в результате не смог понять, почему это так (но наличие проблемы подтвердили, где-то 70мб/с трафика с примерно 70% утилизацией процессора прерываниями в роли DMVPN хаба с VSA — перебор). Хотя спору нет, в большинстве случаев траблшутить data plane (да и control plane) на софтверном роутере с IOS куда проще, чем на хардварном роутере с IOS-XE. Другой вопрос, что ресурсов форвардинга у ASR1000 хоть попой кушай, по этой части данная платформа никогда не выдавала сюрпризов
Когда платформа будет такой же старой как 7200 — все там будет стабильно и понятно.
7200? Стабильно? Понятно? Это что, шутка? По сравнению с этой платформой даже ASR1k — эталон стабильности и предсказуемости. Мы когда-то отказались от 7200, когда надоело разбираться, почему он демонстрирует производительность в несколько раз ниже, чем должен был бы с задействованными на нем фичами, и TAC в результате не смог понять, почему это так (но наличие проблемы подтвердили, где-то 70мб/с трафика с примерно 70% утилизацией процессора прерываниями в роли DMVPN хаба с VSA — перебор). Хотя спору нет, в большинстве случаев траблшутить data plane (да и control plane) на софтверном роутере с IOS куда проще, чем на хардварном роутере с IOS-XE. Другой вопрос, что ресурсов форвардинга у ASR1000 хоть попой кушай, по этой части данная платформа никогда не выдавала сюрпризов
Непонятных слов топик и комменты.
Отличный повод купить хорошую книгу по сетям и изучить, ибо это — основы!
нет, основы — это OSI. а тут — дебри.
Дебри — это OSI, где и поллитра не поможет разобраться, какой протокол какому уровню соответствует (нет, есть масса протоколов помимо ethernet, IP и TCP). То есть в подавляющем большинстве случаев назначение протокола определенному уровню (например, MPLS на уровень 2.5) носит сугубо умозрительный характер и ничем не обосновано.
Тут же основы. Общие принципы устройства всего хардварного оборудования. Упоминание одних из наиболее популярных моделей оборудования. Всё.
Тут же основы. Общие принципы устройства всего хардварного оборудования. Упоминание одних из наиболее популярных моделей оборудования. Всё.
Не соглашусь. BGP — довольно понятный в целом протокол, на базе которого работает Интернет. В той или иной его мере его должен понимать каждый. Даже не на уровне конкретного устройства протокола, а на уровне понятий — автономная система, соседи, as path. Без этого понять, как работает Интернет и поймать какой-нибудь хитрый баг затрагивающий, например, протоколы 7го уровня — задача крайне тяжелая.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Проблемы со связностью интернета из-за разрастания BGP full-view