EIGRP всё-таки обладает ещё рядом приятных плюшек:
1. Быстрая сходимость из коробки. Поэтому прост в использовании. В случае OSPF нужно тюнить (fast rerouting вообще отдельная тема).
2. Многоуровневая иерархичность. У OSPF всего два уровня. Если использовать area, то можно получить не оптимальную маршрутизацию. Именно по этому в hub and spoke топологиях рекомендованными являются EIGRP и BGP.
3. EIGRP векторный, а значит, в отличии от OSPF, микролупов там нет.
4. EIGRP очень неплохо масштабируется. А вот в OSPF могут быть заморочки с количеством маршрутизаторов в area, количеством area на ABR и пр.
В любом случае оба протоколы хороши. Просто каждый по своему.
Сейчас вообще в тренде IS-IS из-за поддержки tlv :)
Однозначного ответа нет. С одной стороны, обновление — шанс нарваться на новый баг. С другой, оставаясь на старой стабильной ветке, в один прекрасный момент получить отказ устройства из-за уязвимости.
Если нет каких-то требований со стороны внешних регулирующих органов(организаций), зачастую обновляют софт на устройствах внутри периметра сети только при острой необходимости (появившийся баг, требования новой функциональности). Тут стабильность в приоритете.
С устройствами на внешнем периметре ситуация чуточку другая. В этом случае вопрос безопасности становится острее.
Резанули цифры. Максимальное количество инстансов MSTP — 65. И это не аппаратное ограничение, какой либо платформы. Это ограничение самого стандарта. Информация обо всех инстансах должна умещаться в одном BPDU. Размер пакета — 1500 байт. И хоть получается максимум 88 инстансов, в стандарте в итоге прописали 65. Чего с лихвой хватает для любых сетей.
То что Вы привели — количество виртуальных портов на коммутаторе. Очень абстрактная сущность равная кол-ву VLAN * на кол-во портов.
Если стыковать Rapid PVST+ с MSTP, нужно, так как long path-cost в MST — единственный вариант.
Стоит отметить, что Long Path-Cost имеет отношение и к самому Rapid PVST+. Если у нас есть линки 40 Гбит/с и более, то его следует включить. И не важно, есть у нас в сети коммутаторы других вендоров или нет.
Безусловно для при взаимодействии коммутаторов разных вендоров рекомендуется использовать именно MSTP. Не призываю для этого использовать Rapid PVST+ :). Я лишь указал, что это работает, так как изначально задумано в самой реализации протокола.
RPVST+ и PVST+ есть только на оборудовании Cisco, а на Cisco нет классического STP и RSTP. Что нам делать, если в топологии участвуют другие вендоры?
Просто подключать это оборудование к Cisco :). В рамках Vlan 1 корректно построится loop-free топология. Для этого BPDU в рамках vlan 1 использует формат IEEE, а вот в рамках других vlan'ов — прориетарный. И даже если на транке убрать vlan 1, всё равно BPDU для него будет передаваться. Всё это обеспечивает совместимость при работе с оборудованием других вендоров.
У вас в тексте указан ASR9000v. Но в таблицах я его не увидел. Так задумано?
(*) – исходные данные по параметру MTBF являются оценочными, предоставленными по данным позициям оборудования производителя или их аналогам.
Вендор нечасто публикует значение MTBF в особенности для компонент сложных систем. Поэтому вопрос, откуда Вы взяли эти цифры, очень интересен. Фраза: «являются оценочными», к сожалению, на него в полной мере не отвечает. Хотелось бы увидеть выкладки (методику оценки, входные данные и пр.). А без этого трудно верить итоговым результатам.
Не совсем, понятно, почему Вы решили ещё ввести «Restart\Shutdown procedure». Ведь точкой отчёта является уже готовая, работающая система. Проектирование, настройка, ввод в эксплуатацию явно выходят за рамки.
Редакция legacy STP уже давно является архаизмом. Во многих современных книгах по сетям его даже не рассматривают. Если уж и браться за семейство протоколов STP, то стоит смотреть в сторону RSTP или же MSTP.
Небольшое замечание по статье: в состояние Blocking порт после включения переходит сразу же, как только получит superior BPDU (т.е. BPDU с лучшим Bridge ID).
Также интересен вопрос с таймером forward delay. Почему именно 15? Ответ: потому что 2*15 = 30 :). Именно 30 секунд нужно подождать, прежде чем перевести порт в состояние Forwarding, чтобы в сети не возникло временных петель. Это рекомендованное значение для сети диаметром семь хопов. Оно получается из суммирования времени распространения BPDU по сети, времени жизни BPDU в сети, времени перехода порта в состояние Blocking и пр.
Использовалась стандартная утилита ping в составе Windows 10 и на сетевом оборудовании Cisco. Для других версий Windows ситуация аналогичная. Примеры команд есть в статье. Возможно, вышестоящее оборудование «режет» пакеты с выставленными опциями.
Если не ошибаюсь, loopback-detect — это проприетарная штука. Т.е. она подойдёт только для коммутаторов определённого вендора.
А если я по ошибке соединю порты доступа двух соседних коммутаторов в стойке? Loopback-detect не позволит защититься от такой петли.
Полностью отказаться от STP крайне сложно. Даже если дизайн сети не предполагает петель, она может легко возникнуть в рамках всего лишь одного коммутатора (например, по ошибке соединили между собой два порта). Поэтому избежать STP не получится. Некоторые, правда, пытаются — просто его не настраивая, но в конце концов получают петлю. После чего вспоминают о его существовании и необходимости.
Добрый день! В итоге не совсем понятно, какое шифрование используется в вашем решении. В заголовке указано, что гостовое. Но в настройках я увидел только установку сертификатов на базе госта для аутентификации. Как задаётся гостовый алгоритм шифрования непосредственно для IPSec соединения?
Транспортный уровень OSI не обязательно должен быть надёжным. Но вот получить данные от верхнего уровня, упаковать их и обеспечить передачу в отрыве от сетевого уровня должен. TCP и UDP со 100% точностью не укладываются в определение транспортного уровня модели OSI, так как они разрабатывались в отрыве от неё. Но общепринято эти оба протокола относить именно к нему.
Протоколы динамической маршрутизации относят к протоколам, обеспечивающим работу других уровней, например, сетевого. Обычно их не пытаются уложить в какой-то уровень модели OSI. Даже в приведенной ссылке не присутствует такое заявление. Максимум указывают поверх какого уровня они работают (например: IS-IS — поверх канального, OSPF — сетевого, RIP или BGP — транспортного).
ARP явно протокол не канального уровня. И уж точно не сетевого, так как не обеспечивает передачу данных между сетями. Вот и получается подобие уровня 2.5.
На четвёртом уровне OSI слово «надёжность» может варьироваться в очень больших пределах. Во всяком случае, так обычно пишут. Может быть, все дружно врут. Лично сам стандарт не читал (ISO просят по-дружески 198 швейцарских франков в качестве дара на развитие новых стандартов, пока думаю :)).
Но допустим, что UDP отнесли к сетевому уровню. Разве он позволит нам определить кратчайший маршрут и дальше обеспечить передачу данных между сетями? Нет. Получается, что на сетевом уровне ему тоже не место. Бедный UDP.
То что реальные протоколы не соответствуют модели OSI и TCP/IP общее известный факт. Обе модели не идеальны. Из TCP/IP взяты стеки протоколов. Модель же OSI используется в основном в образовательных целях для описания работы сети.
Вы правильно заметили, не все протоколы укладываются в модель OSI. Но это и понятно, так как OSI сугубо образовательная вещь. По многим из них можно долго дискутировать, куда отнести. Например, для таких протоколов, как ARP, MPLS даже придуманы новые уровни — 2.5, так как их нельзя однозначно определить ни к канальному, ни к сетевому.
Если мы говорим про UDP, то он с натяжкой но всё-таки укладывается в описание транспортного уровня OSI. Именно поэтому, если мы посмотрим в книги Таненбаума, Олифера, различные вендорные материалы, данный протокол мы увидим именно на транспортном уровне. UDP обеспечивает связь между приложениями(программами) на хостах. Он является прослойкой между сетевым уровнем, отвечающим за маршрутизацию пакетов в сети, и приложением/сеансовым уровнем.
В Nexus 3172 префиксы IPv6 хранятся в FIB. Поэтому прочерк не очень понятен.
Если сравнивать Huawei с Cisco, стоит смотреть на линейку 9200 или 9300. По цене сравнимо с 3100, но будет поддержка бОльшего спектра технологий (в том числе VXLAN, FCoE (для 9300)) и лучшие цифры по производительности.
А что есть «GPL» в прайс-листе Huawei? Под этим Вы подразумеваете RPL?
1. Быстрая сходимость из коробки. Поэтому прост в использовании. В случае OSPF нужно тюнить (fast rerouting вообще отдельная тема).
2. Многоуровневая иерархичность. У OSPF всего два уровня. Если использовать area, то можно получить не оптимальную маршрутизацию. Именно по этому в hub and spoke топологиях рекомендованными являются EIGRP и BGP.
3. EIGRP векторный, а значит, в отличии от OSPF, микролупов там нет.
4. EIGRP очень неплохо масштабируется. А вот в OSPF могут быть заморочки с количеством маршрутизаторов в area, количеством area на ABR и пр.
В любом случае оба протоколы хороши. Просто каждый по своему.
Сейчас вообще в тренде IS-IS из-за поддержки tlv :)
Если нет каких-то требований со стороны внешних регулирующих органов(организаций), зачастую обновляют софт на устройствах внутри периметра сети только при острой необходимости (появившийся баг, требования новой функциональности). Тут стабильность в приоритете.
С устройствами на внешнем периметре ситуация чуточку другая. В этом случае вопрос безопасности становится острее.
Резанули цифры. Максимальное количество инстансов MSTP — 65. И это не аппаратное ограничение, какой либо платформы. Это ограничение самого стандарта. Информация обо всех инстансах должна умещаться в одном BPDU. Размер пакета — 1500 байт. И хоть получается максимум 88 инстансов, в стандарте в итоге прописали 65. Чего с лихвой хватает для любых сетей.
То что Вы привели — количество виртуальных портов на коммутаторе. Очень абстрактная сущность равная кол-ву VLAN * на кол-во портов.
Стоит отметить, что Long Path-Cost имеет отношение и к самому Rapid PVST+. Если у нас есть линки 40 Гбит/с и более, то его следует включить. И не важно, есть у нас в сети коммутаторы других вендоров или нет.
Безусловно для при взаимодействии коммутаторов разных вендоров рекомендуется использовать именно MSTP. Не призываю для этого использовать Rapid PVST+ :). Я лишь указал, что это работает, так как изначально задумано в самой реализации протокола.
Просто подключать это оборудование к Cisco :). В рамках Vlan 1 корректно построится loop-free топология. Для этого BPDU в рамках vlan 1 использует формат IEEE, а вот в рамках других vlan'ов — прориетарный. И даже если на транке убрать vlan 1, всё равно BPDU для него будет передаваться. Всё это обеспечивает совместимость при работе с оборудованием других вендоров.
Вендор нечасто публикует значение MTBF в особенности для компонент сложных систем. Поэтому вопрос, откуда Вы взяли эти цифры, очень интересен. Фраза: «являются оценочными», к сожалению, на него в полной мере не отвечает. Хотелось бы увидеть выкладки (методику оценки, входные данные и пр.). А без этого трудно верить итоговым результатам.
Не совсем, понятно, почему Вы решили ещё ввести «Restart\Shutdown procedure». Ведь точкой отчёта является уже готовая, работающая система. Проектирование, настройка, ввод в эксплуатацию явно выходят за рамки.
Небольшое замечание по статье: в состояние Blocking порт после включения переходит сразу же, как только получит superior BPDU (т.е. BPDU с лучшим Bridge ID).
Также интересен вопрос с таймером forward delay. Почему именно 15? Ответ: потому что 2*15 = 30 :). Именно 30 секунд нужно подождать, прежде чем перевести порт в состояние Forwarding, чтобы в сети не возникло временных петель. Это рекомендованное значение для сети диаметром семь хопов. Оно получается из суммирования времени распространения BPDU по сети, времени жизни BPDU в сети, времени перехода порта в состояние Blocking и пр.
А если я по ошибке соединю порты доступа двух соседних коммутаторов в стойке? Loopback-detect не позволит защититься от такой петли.
Протоколы динамической маршрутизации относят к протоколам, обеспечивающим работу других уровней, например, сетевого. Обычно их не пытаются уложить в какой-то уровень модели OSI. Даже в приведенной ссылке не присутствует такое заявление. Максимум указывают поверх какого уровня они работают (например: IS-IS — поверх канального, OSPF — сетевого, RIP или BGP — транспортного).
На четвёртом уровне OSI слово «надёжность» может варьироваться в очень больших пределах. Во всяком случае, так обычно пишут. Может быть, все дружно врут. Лично сам стандарт не читал (ISO просят по-дружески 198 швейцарских франков в качестве дара на развитие новых стандартов, пока думаю :)).
Но допустим, что UDP отнесли к сетевому уровню. Разве он позволит нам определить кратчайший маршрут и дальше обеспечить передачу данных между сетями? Нет. Получается, что на сетевом уровне ему тоже не место. Бедный UDP.
Вы правильно заметили, не все протоколы укладываются в модель OSI. Но это и понятно, так как OSI сугубо образовательная вещь. По многим из них можно долго дискутировать, куда отнести. Например, для таких протоколов, как ARP, MPLS даже придуманы новые уровни — 2.5, так как их нельзя однозначно определить ни к канальному, ни к сетевому.
Если мы говорим про UDP, то он с натяжкой но всё-таки укладывается в описание транспортного уровня OSI. Именно поэтому, если мы посмотрим в книги Таненбаума, Олифера, различные вендорные материалы, данный протокол мы увидим именно на транспортном уровне. UDP обеспечивает связь между приложениями(программами) на хостах. Он является прослойкой между сетевым уровнем, отвечающим за маршрутизацию пакетов в сети, и приложением/сеансовым уровнем.
Если сравнивать Huawei с Cisco, стоит смотреть на линейку 9200 или 9300. По цене сравнимо с 3100, но будет поддержка бОльшего спектра технологий (в том числе VXLAN, FCoE (для 9300)) и лучшие цифры по производительности.
А что есть «GPL» в прайс-листе Huawei? Под этим Вы подразумеваете RPL?