Комментарии 64
Предлагаю устроить холивар в комментариях на тему IOU vs GNS.
Было бы о чем спорить… Конечно IOU с нормальным фронтендом!
чем лучше-то? за iou я пока видел только один плюс — оно работает быстрее чем dynamips. но на современном железе это неактуально. динамипс же детально описан, особых шаманств чтоб его запустить не надо, гуёв для него навалом. опять же, динамипс можно под виндой запустить
Слабо средствами GNS3 на односокетной системе поднять топологию на 30 устройств так, чтобы протоколы с таймерами 1/3 периодически не теряли соседства? :) А RSTP? А многое другое?
А (пере)настройка idle уже не считается шаманством?
Под IOU есть готовый виртуальный аплайанс под VMWare. Включить — появится вебинтерфейс. В нем выбрать раздобытый где-либо образ L2 либо L3 IOU, и готово. Топологию рисовать в том же интерфейсе мышкой, без ручного заполнения NETMAP.
динамипс же детально описан, особых шаманств чтоб его запустить не надо
А (пере)настройка idle уже не считается шаманством?
Под IOU есть готовый виртуальный аплайанс под VMWare. Включить — появится вебинтерфейс. В нем выбрать раздобытый где-либо образ L2 либо L3 IOU, и готово. Топологию рисовать в том же интерфейсе мышкой, без ручного заполнения NETMAP.
14 железок запущал на c2q-2.4 16gb под виндой. даже pdf попутно читал и видео смотрел ) stp прекрасно эмулируется на модулях nm-esw.
а что, IOU умеет эмулировать свитч? O_O даже метро-свитчи??
а что, IOU умеет эмулировать свитч? O_O даже метро-свитчи??
14 железок запущал на c2q-2.4 16gb под виндой
А какая была задержка при пинге между соседними устройствами? Как поживала к примеру targeted LDP сессия через 3-4 хопа?
stp прекрасно эмулируется на модулях nm-esw.
RSTP.
а что, IOU умеет эмулировать свитч? O_O даже метро-свитчи??
Разумеется. Ищите L2IOU. Он сравним по возможностям с cat6500. Например — там вроде нет VPLS…
rtt между железками в среднем был 50-70ms, но мог резко подскочить до 2-3с когда по bgp большие апдейты приходили. в целом — номрально.
направленый ldp отваливался, если был зацеплен за те самые железки с большими таблицами bgp.
на меньшей схеме или когда 10 железок на одной машине, а 10 на другой — совершенно все спокойно жило, без отваливаний.
о, спасибо, не знал что l2 есть…
направленый ldp отваливался, если был зацеплен за те самые железки с большими таблицами bgp.
на меньшей схеме или когда 10 железок на одной машине, а 10 на другой — совершенно все спокойно жило, без отваливаний.
о, спасибо, не знал что l2 есть…
если был зацеплен за те самые железки с большими таблицами bgp.
Насколько большие? 15-20 префиксов?
10 железок на одной машине, а 10 на другой
Теперь такое зовется «без шаманств»? :)
Прелесть IOU именно в том, что устройства там можно добавлять пока память не кончится, при этом влияния на производительность нет, всё летает.
НЛО прилетело и опубликовало эту надпись здесь
а idle надо как-то специально настраивать? ) в gns-е ios подпихнул, кнопку «посчитать idle» нажал и готово )
Наипреотличнейше!
Отличная статья. Спасибо. Как-раз сейчас к CCNA готовлюсь.
Тут много инфы выходящей за пределы CCNA, из CCNP routing курса даже
Для подготовки к CCNA я бы рекомендовал обратиться к специализированным источника (книги или CBT Nuggets). Мы просто пытаемся дать понимание, как это работает и настраивается, не придерживаясь каких-то рамок.
Еще бы посоветовал вам выполнить CCNA Skills Integration Challenge PT Activity. Уж очень помогает осознать практическую составляющею теоретической основы курса CCNA:)
Не до конца понятен момент с применением stub в описанной ситуации:
«А теперь “внимание, вопрос”: что будет, если R1 потеряет связь с R4, а R5 потеряет LAN? Трафик из подсети R1 в подсеть главного офиса будет идти по маршруту R1->R5->R2(или R3)->R4. Будет это эффективно? Нет. „
Тут вы предлагаете сконфигурить все branches как stub. А собственно связь-то от R1 до LAN-а головного офиса нужна, а её не будет с указанной схемой и конфигурацией.
Как быть? Понятно что тут дело в дизайне, и не плохо бы на текущей схеме иметь линк R4-R5.
Я к тому, что как раз на указанной схеме stub лучше не применять. Или я где-то не прав?
«А теперь “внимание, вопрос”: что будет, если R1 потеряет связь с R4, а R5 потеряет LAN? Трафик из подсети R1 в подсеть главного офиса будет идти по маршруту R1->R5->R2(или R3)->R4. Будет это эффективно? Нет. „
Тут вы предлагаете сконфигурить все branches как stub. А собственно связь-то от R1 до LAN-а головного офиса нужна, а её не будет с указанной схемой и конфигурацией.
Как быть? Понятно что тут дело в дизайне, и не плохо бы на текущей схеме иметь линк R4-R5.
Я к тому, что как раз на указанной схеме stub лучше не применять. Или я где-то не прав?
НЛО прилетело и опубликовало эту надпись здесь
Данный протокол работает сразу поверх IP, т.е. 4-й уровень (транспортный). Но используется для организации работы L3 (сетевого уровня).
Вот уж с 4 не торопитесь. Не все, что инкапсулируется в L3 будет автоматически L4. ICMP работает поверх IP, но это L3 по-любому и в любых доках.
ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%82%D0%B5%D0%B2%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_OSI
4 обеспечивает транспортные функции, доставку, а OSPF — решает конкретную системно-прикладную задачу — обмен маршрутной информацией, где тут транспорт? Это уж тогда L7 (что тоже иногда можно встретить, например learningnetwork.cisco.com/thread/14911)
ru.wikipedia.org/wiki/%D0%A1%D0%B5%D1%82%D0%B5%D0%B2%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_OSI
4 обеспечивает транспортные функции, доставку, а OSPF — решает конкретную системно-прикладную задачу — обмен маршрутной информацией, где тут транспорт? Это уж тогда L7 (что тоже иногда можно встретить, например learningnetwork.cisco.com/thread/14911)
А на самом деле вопрос сильно философский.
www.networksorcery.com/enp/protocol/ospf.htm
«Transport layer interior link state routing protocol.»
Неважно, что он решает. Его данные инкапсулированы в L3. Очевидно, уже это делает его L4 протоколом. Транспорт у него свой собственный, а вовсе не общестандартный вроде TCP и UDP. И?
Речь идет не про то, какие данные он обрабатывает, а строго про способ передачи пакетов.
www.networksorcery.com/enp/protocol/ospf.htm
«Transport layer interior link state routing protocol.»
4 обеспечивает транспортные функции, доставку, а OSPF — решает конкретную системно-прикладную задачу — обмен маршрутной информацией
Неважно, что он решает. Его данные инкапсулированы в L3. Очевидно, уже это делает его L4 протоколом. Транспорт у него свой собственный, а вовсе не общестандартный вроде TCP и UDP. И?
Речь идет не про то, какие данные он обрабатывает, а строго про способ передачи пакетов.
Да, философский. Но вполне себе разрешимый. Как раз какую задачу он решает — главное. Да, оси — это некая схема и каркас. Но ключевая фишка в ней не что во что, а функционал. Ненадежная доставка, но с транзитом через разные L2 — это L3. Где на L3 навешивается доп. функционал по доставке — это транспортный. Ключевое тут не цифры, а роли. А если цифры считать за главное и что — во что, то тунелирование тут вообще все карты мешает.
В L3, как вам хорошо известно и L2 может быть упакован, и в L4, и в L7. Он свою L2 роль от места в этой матрешке не меняет. Тем более, что есть протоколы маршрутизации, живущие через настоящий L4, например UDP. И тут понятней, что они L7, хотя задача с OSPF у них одна и та же совершенно, разница в продвинутости и алгоритмах.
В L3, как вам хорошо известно и L2 может быть упакован, и в L4, и в L7. Он свою L2 роль от места в этой матрешке не меняет. Тем более, что есть протоколы маршрутизации, живущие через настоящий L4, например UDP. И тут понятней, что они L7, хотя задача с OSPF у них одна и та же совершенно, разница в продвинутости и алгоритмах.
Но ключевая фишка в ней не что во что, а функционал.
Функционал — L3. Транспорт функционала — L4.
Hello protocol OSPF весьма похож на TCP :)
Ненадежная доставка, но с транзитом через разные L2 — это L3. Где на L3 навешивается доп. функционал по доставке — это транспортный
Да. См. протокол согласования OSPF.
В L3, как вам хорошо известно и L2 может быть упакован, и в L4, и в L7. Он свою L2 роль от места в этой матрешке не меняет.
Вообще-то радикально меняет. Пока L2 во что-то инкапсулирован (хоть в тот же самый L2), он не выполняет свою роль по направлению трафика.
есть протоколы маршрутизации, живущие через настоящий L4, например UDP
Вы хотели сказать «BGP»?
Да, он использует TCP в качестве протокола транспортного уровня. У OSPF собственный протокол транспортного уровня.
Да хотя бы RIP, помните еще такого зверя? UDP. И кто он после этого, L5? По мне, уж если философски, раз у RIP и OSPF одни и те же задачи, логично их отнести к одному L. А кроме L7 не получается.
Мое сугубое имхо — не важно. Важно что есть процессы на неких хостах, которые обмениваются СОБСТВЕННЫМИ данными. Поэтому они ближе к L7. Даже если у них есть свой L4. Вот когда они будут лошадкой для ЧУЖИХ данных, и только лошадкой, ничего своего и смодостаточного у них не будет — тогда пусть будут L4 :)
Да, эти данные потом влияют на L3.
А вообще вот, вспомнилось :)
net-geek.org/dbg/2007/08/osirm.html
Жаль, что линк из жж неработоспособен, но яндекс кое-что помнит, правда там эпического холивара не сохранилось похоже
www.ljpoisk.ru/archive/1766930.html
Мое сугубое имхо — не важно. Важно что есть процессы на неких хостах, которые обмениваются СОБСТВЕННЫМИ данными. Поэтому они ближе к L7. Даже если у них есть свой L4. Вот когда они будут лошадкой для ЧУЖИХ данных, и только лошадкой, ничего своего и смодостаточного у них не будет — тогда пусть будут L4 :)
Да, эти данные потом влияют на L3.
А вообще вот, вспомнилось :)
net-geek.org/dbg/2007/08/osirm.html
Жаль, что линк из жж неработоспособен, но яндекс кое-что помнит, правда там эпического холивара не сохранилось похоже
www.ljpoisk.ru/archive/1766930.html
Да хотя бы RIP, помните еще такого зверя? UDP.
Еще раз: RIP использует в качестве транспорта UDP. OSPF сам себе транспорт.
Вы считаете, что OSPF умеет общаться телекинетически, пересылая данные без всякого транспорта?
Вот когда они будут лошадкой для ЧУЖИХ данных
А какая разница, свои или чужие данные?
Транспорт есть? Есть. А что ходит поверх него, один протокол или миллион, не играет никакой роли.
Да никто не спорит, что модель OSI не идеальна. Однако, в данном случае всё вполне ясно.
Кстати, ICMP я бы тоже сходу запихал на L4. Совершенно обыкновенный транспортный протокол, способный нести в себе чужие данные. См. ICMP туннели. То, что конкретно echo пакет не для того предназначался — тоже так себе отговорка :)
Даже если посмотреть на то, что неоспоримо L4 — TCP, UDP, RTP, SCTP, SPX — разница с OSPF видна невооруженным глазом и даже интуитивно чувствуется.
С точки зрения функционала, OSPF не относится ни к сетевому уровню, ни к транспортному. Это действительно скорее уровень приложений. С точки зрения инкапсуляции — это 4-й уровень.
Но служит он целям сетевого уровня, очевидно, поэтому и считается формально сетевым.
Но служит он целям сетевого уровня, очевидно, поэтому и считается формально сетевым.
При нынешнем развитии туннелирования-инкапсуляции — это такая условность. Что только во что не помещается. Классический 4 — это все таки транспорт, причем чужих данных. У TCP есть свои (ну кроме служебных для рукопожатия и поддеркжи потока)? Нет, только данные наездников. А у OSPF, не смотря на то, что свой транспорт, данные свои. Отсюда и моя точка зрения на L7. А формально с точки зрения позиции в схеме — видно ж, что 4 и понятно, что обслуживает нужды L3.
А вообще оси — костыль. Недаром не прижилось и идеологически чистых реализаций, используемых на практике нет.
net-geek.org/dbg/2007/08/osirm.html
А вообще оси — костыль. Недаром не прижилось и идеологически чистых реализаций, используемых на практике нет.
net-geek.org/dbg/2007/08/osirm.html
А у OSPF, не смотря на то, что свой транспорт, данные свои
Снова: протокол транспортного уровня существует. Дык какая разница, кто поверх него катается?
А вообще оси — костыль. Недаром не прижилось и идеологически чистых реализаций, используемых на практике нет.
IS-IS хорош, как и CLNS, поверх которого он работает. И если бы TCP/IP проиграл — мы бы еще лет 100 не задумывались о смене протокола в связи с нехваткой адресов.
Модель TCP/IP мне нравится меньше, чем OSI, потому что там L1 и L2 сплюснуты в один — ну это уже ни в какие ворота…
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за статью, многое доступно разъяснено.
Великолепнейше написано, моё почтение! Это я вполне с админской точки зрения провайдера говорю.
Ваше нет-фу сильно :) Прекрасная статья, будет полезна как начинающим, так и опытным сетевикам/администраторам.
Доступно и понятно. В закладки. Оформите цикл статей в PDF\FB2. Тогда и в метро\пробке можно будет освежать или осваивать знания.
Из OSPF в EIGRP:
klgr-gw1(config)#router ospf 1
klgr-gw1(config-router)#redistribute eigrp 1 subnets
Разве не Из EIGRP в OSPF?
klgr-gw1(config)#router ospf 1
klgr-gw1(config-router)#redistribute eigrp 1 subnets
Разве не Из EIGRP в OSPF?
как же не хватало таких статей мне в 2007-м!!!
Имеется вопрос.
Ситуация следующая: существуют некие каналы между роутерами. За роутерами соответственно подсети с клиентами. Всё вместе находится в одной /16 подсети.
Варианты:
1. В network пишется /16 подсеть, интерфейсы к клиентам — passive.
2. Роутерная подсеть /19 прописывается в network для area, а остальное через route-map в redistribute connected.
Что по идее красивее, идеологически правильнее?
За серию статей огромнейшее спасибо! Интересно посмотреть/почитать/подумать :)
Ситуация следующая: существуют некие каналы между роутерами. За роутерами соответственно подсети с клиентами. Всё вместе находится в одной /16 подсети.
Варианты:
1. В network пишется /16 подсеть, интерфейсы к клиентам — passive.
2. Роутерная подсеть /19 прописывается в network для area, а остальное через route-map в redistribute connected.
Что по идее красивее, идеологически правильнее?
За серию статей огромнейшее спасибо! Интересно посмотреть/почитать/подумать :)
Перераспределение маршрутов в принципе не очень приятная вещь, и я бы советовал пользоваться ею в крайнем случае. Дело в том, что приоритет редистрибьютед маршрутов ниже.
В общем, 1-й вариант — самое оно.
В общем, 1-й вариант — самое оно.
Ну если мы говорим о сети с клиентами, то external она или нет скорее всего неважно. Не должно существовать LSA 2 или 3 на тот же префикс, который перебьет E1/E2…
Лупов тоже быть не может, так как редистрибутится оно на самой границе сети, и только в одну сторону.
По каким-то причинам может потребоваться перестать анонсировать префикс в OSPF. С редистрибьютом это проще, всего-то запись из роут-мапа удалить.
Еще можно делать по network на каждый интерфейс и обозначать их как passive. В данной топологии особой разницы в результате по сравнению с редистрибьютом не будет.
Лупов тоже быть не может, так как редистрибутится оно на самой границе сети, и только в одну сторону.
По каким-то причинам может потребоваться перестать анонсировать префикс в OSPF. С редистрибьютом это проще, всего-то запись из роут-мапа удалить.
Еще можно делать по network на каждый интерфейс и обозначать их как passive. В данной топологии особой разницы в результате по сравнению с редистрибьютом не будет.
Ну в данном случае единственный юскейс — не анонсировать сеть какого-то интерфейса. При этом конфигурации больше. Мне кажется в рядовой ситуации лучше общий network, а, если уж, есть такая специфическая необходимость, то, да, редистрибьюция.
Дык и в роут-мапе можно сослаться на префикс-лист с одной большой суперсетью. А при необходимости легко сделать исключения из редистрибута. Разница в длине конфигурации — строк 5 вне зависимости от числа VLANов.
И кстати, «интерфейсы к клиентам — passive» — немного нефеншуй. Феншуй — passive default с исключениями там, где надо.
И кстати, «интерфейсы к клиентам — passive» — немного нефеншуй. Феншуй — passive default с исключениями там, где надо.
Если это статья для самых маленьких, то я еще не родился =) Спасибо, очень сильно!
В тексте ошибка
фактически выдержка не корректно иллюстрирует то что хотел донести автор, первая строчка описывает более широкий диапазон сетей чем последующие, имелось ввиду
msk-arbat-gw1(config-router)#network 172.16.0.0 0.0.0.255 area 0
msk-arbat-gw1(config-router)#network 172.16.1.0 0.0.0.255 area 0
… etc
msk-arbat-gw1(config-router)#network 172.16.0.0 0.0.255.255 area 0
msk-arbat-gw1(config-router)#network 172.16.1.0 0.0.255.255 area 0
msk-arbat-gw1(config-router)#network 172.16.2.0 0.0.255.255 area 0
……
msk-arbat-gw1(config-router)#network 172.16.15.0 0.0.255.255 area 0
фактически выдержка не корректно иллюстрирует то что хотел донести автор, первая строчка описывает более широкий диапазон сетей чем последующие, имелось ввиду
msk-arbat-gw1(config-router)#network 172.16.0.0 0.0.0.255 area 0
msk-arbat-gw1(config-router)#network 172.16.1.0 0.0.0.255 area 0
… etc
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сети для самых маленьких. Часть шестая. Динамическая маршрутизация