Comments 64
Предлагаю устроить холивар в комментариях на тему IOU vs GNS.

Было бы о чем спорить… Конечно IOU с нормальным фронтендом!
чем лучше-то? за iou я пока видел только один плюс — оно работает быстрее чем dynamips. но на современном железе это неактуально. динамипс же детально описан, особых шаманств чтоб его запустить не надо, гуёв для него навалом. опять же, динамипс можно под виндой запустить
Слабо средствами GNS3 на односокетной системе поднять топологию на 30 устройств так, чтобы протоколы с таймерами 1/3 периодически не теряли соседства? :) А RSTP? А многое другое?
динамипс же детально описан, особых шаманств чтоб его запустить не надо

А (пере)настройка idle уже не считается шаманством?
Под IOU есть готовый виртуальный аплайанс под VMWare. Включить — появится вебинтерфейс. В нем выбрать раздобытый где-либо образ L2 либо L3 IOU, и готово. Топологию рисовать в том же интерфейсе мышкой, без ручного заполнения NETMAP.
14 железок запущал на c2q-2.4 16gb под виндой. даже pdf попутно читал и видео смотрел ) stp прекрасно эмулируется на модулях nm-esw.
а что, 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 есть…
если был зацеплен за те самые железки с большими таблицами bgp.

Насколько большие? 15-20 префиксов?
10 железок на одной машине, а 10 на другой

Теперь такое зовется «без шаманств»? :)
Прелесть IOU именно в том, что устройства там можно добавлять пока память не кончится, при этом влияния на производительность нет, всё летает.
Насколько большие? 15-20 префиксов?
единицы тысяч префиксов.

ок, пойду приглянусь к iou повнимательнее )
kiss — добавил лишний роутер в топологию на самый край, в нем много статиков и redistribute static )
Это ни черта не KISS…
Хотя да, сети можно генерить скриптом. Но все равно тыща статиков…
а idle надо как-то специально настраивать? ) в gns-е ios подпихнул, кнопку «посчитать idle» нажал и готово )
Всегда нужно по несколько раз выбирать значения из списка. И потом повторять процедуру, когда железки обрастают сервисами.
Для подготовки к 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, и ни в чем неповинная сеть за R2.
Поясните тупому, я все не могу понять — OSPF это транспортный или сетевой уровень?
Данный протокол работает сразу поверх 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)
А на самом деле вопрос сильно философский.
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. Транспорт функционала — 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
Да хотя бы 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
А у OSPF, не смотря на то, что свой транспорт, данные свои

Снова: протокол транспортного уровня существует. Дык какая разница, кто поверх него катается?
А вообще оси — костыль. Недаром не прижилось и идеологически чистых реализаций, используемых на практике нет.

IS-IS хорош, как и CLNS, поверх которого он работает. И если бы TCP/IP проиграл — мы бы еще лет 100 не задумывались о смене протокола в связи с нехваткой адресов.
Модель TCP/IP мне нравится меньше, чем OSI, потому что там L1 и L2 сплюснуты в один — ну это уже ни в какие ворота…
Одесситы действительно забавные ребята :)
Но про «Модель TCP/IP мне нравится меньше, чем OSI» — речь конкретно про референсную модель, а не про задействованные технологии.
А вообще… В OSI ведь действительно есть четко выделенный L5, чего не скажешь про TCP/IP. Тоже неплохо.
По чуть было не начавшемуся холивару по поводу этого протокола я только больше запутался, спасибо пацаны за ваши рассуждения ниже.
Да это так, не холивар, а прополка темы :) Зато вы можете теперь при желании суметь аргументировать принадлежность протокола практчески к любому уровню оси :)
Википедия английская и русская дают слегка противоречивую информацию.
Я поискал инфу в своем учебнике Таненбаума, там тоже не совсем точно объяснено.
Вкратце получается так: OSPF может относится к любым уровням модели OSI, так как модель это символическая.
Как-то так :)
Великолепнейше написано, моё почтение! Это я вполне с админской точки зрения провайдера говорю.
Ваше нет-фу сильно :) Прекрасная статья, будет полезна как начинающим, так и опытным сетевикам/администраторам.
Доступно и понятно. В закладки. Оформите цикл статей в PDF\FB2. Тогда и в метро\пробке можно будет освежать или осваивать знания.
Книга будет по окончанию цикла. Хотя, учитывая промежутки между статьями, возможно, стоит по ходу обновлять просто.
Из OSPF в EIGRP:
klgr-gw1(config)#router ospf 1
klgr-gw1(config-router)#redistribute eigrp 1 subnets

Разве не Из EIGRP в OSPF?
> Теперь смотрим на R2- он анонсирует свою сеть 192.168.1.0/24 соседу R1,
Здесь тоже баг — подсеть R2 это 192.168.2.0/24
Да и вообще имхо эта часть статьи мутновато написана.
> R3 передает информацию о том, что он имеет доступ через R4 к подсети 192.168.1.0/24 дальше
тоже самое :)
my bad… перепутались местами названия роутеров, не подсети. Вы очень молодец, что внимательно читаете, отдельное спасибо))
Мне примерно тогда же)) Всё пришлось по раздробленным мануалам ковырять)
Имеется вопрос.
Ситуация следующая: существуют некие каналы между роутерами. За роутерами соответственно подсети с клиентами. Всё вместе находится в одной /16 подсети.
Варианты:
1. В network пишется /16 подсеть, интерфейсы к клиентам — passive.
2. Роутерная подсеть /19 прописывается в network для area, а остальное через route-map в redistribute connected.
Что по идее красивее, идеологически правильнее?
За серию статей огромнейшее спасибо! Интересно посмотреть/почитать/подумать :)
Перераспределение маршрутов в принципе не очень приятная вещь, и я бы советовал пользоваться ею в крайнем случае. Дело в том, что приоритет редистрибьютед маршрутов ниже.

В общем, 1-й вариант — самое оно.
Ну если мы говорим о сети с клиентами, то external она или нет скорее всего неважно. Не должно существовать LSA 2 или 3 на тот же префикс, который перебьет E1/E2…
Лупов тоже быть не может, так как редистрибутится оно на самой границе сети, и только в одну сторону.

По каким-то причинам может потребоваться перестать анонсировать префикс в OSPF. С редистрибьютом это проще, всего-то запись из роут-мапа удалить.

Еще можно делать по network на каждый интерфейс и обозначать их как passive. В данной топологии особой разницы в результате по сравнению с редистрибьютом не будет.
Ну в данном случае единственный юскейс — не анонсировать сеть какого-то интерфейса. При этом конфигурации больше. Мне кажется в рядовой ситуации лучше общий network, а, если уж, есть такая специфическая необходимость, то, да, редистрибьюция.
Дык и в роут-мапе можно сослаться на префикс-лист с одной большой суперсетью. А при необходимости легко сделать исключения из редистрибута. Разница в длине конфигурации — строк 5 вне зависимости от числа VLANов.

И кстати, «интерфейсы к клиентам — passive» — немного нефеншуй. Феншуй — passive default с исключениями там, где надо.
Если это статья для самых маленьких, то я еще не родился =) Спасибо, очень сильно!
В тексте ошибка
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
Only those users with full accounts are able to leave comments. Log in, please.