Комментарии 10
Коллеги из Зухеля, которого я нежно люблю со времен модемов! Спасибо за страничку юмора! В наше трудное время это ой как нужно! ;-)
Ну как же так, 4 x 10Gbit порта, остальные гигабитные? Ну какое же это ядро? Я уже 40 Gbit в ядре не представляю, а вы предлагаете по 32 ГИГАБИТНЫХ порта на кор свиче? Что будем к ним подключать? Гигабитные аплинки свичей уровня агрегации 20-ти летней давности? :-D
И что это за пицца-боксы? Где модульные шасси? Нет, ну вы серьезно считаете, что стекингом можно заменить шасси с CLOS фабрикой? :)))
Про VRRP и RIPng даже говорить не хочу, скупая слеза прокатилась по небритой щеке, как будто вернулся на 20 лет назад обратно в молодость... Давайте начистоту - вот эти вот поделки на протухших броадком чипсетах 8-ми летней давности уже даже на уровень доступа не лезут по причине отсутствия хотя бы нескольких десятков 10Gbit портов для серверов и нормальных рабочих станций, куда их чумазых в кору???
Про VRRP и RIPng даже говорить не хочу
А что сейчас актуально?
VRRP - конечно же к кору это вообще никак не относится, FHRP протоколы это удел аксеса, ну или на крайний случай дистрибюшен уровней, в коре все должно уже идти через IP routing. Это если мы не адепты секты "Свидетели stretched VLANs седьмого дня", хотя в кампус сетях такое часто встречается. Плачут, колятся, но продолжают тянуть виланы через кор. А так, если уж заговорили о VRRP я бы строил сеть, где вообще не нужен FHRP, а уже конкретная технология зависит от вендора. Хотя Сиски со своим vPC вполне допускают и даже советуют VRRP (или HSRP) на SVI интерфейсах vPC мемберов, но не нужно забывать, что в отличие от всяких горе-вендоров в Cisco vPC этот самый VRRP реализован как Active/Active без нужды проводить пляски с бубном и вручную распределять по группам какие SVI на каком мембере будут Active, а какие наоборот. Лично я чаще работаю с IRF фабриками HPE/H3C, иногда с CSS от Huawei, там FHRP вообще не нужен по определению. А так личные предпочитания и сеть моей мечты - all-routed underlay, VXLAN overlay, Distributed L3 Gateway на VXLAN VTEP'ах. И никаких тебе STP, VRRP и прочей заплесневелой чепухи. Но это пока нечасто встретишь вне датацентров.
RIPng - конечно же OSPFv3 или IS-IS. Для любителей Сиски и дистанс-векторных протоколов - EIGRP, но это вендор-лок, нафиг нужно. Да и не в вендор-локе дело, просто зачем distance-vector в наше время? При наличии вменяемого железа SPT просчитывается быстро, не вижу смысла в distance-vector протоколах. Но это вкусовщина, в любом случае что бы не выбрали, все будет лучше RIPng.
Хаха, да, конечно это оверкилл, даже и спорить не буду. Особенно в ветке Zyxel. Но я же поэтому и написал - сеть моей мечты.
А так, если все же спора ради - а что мешает? Ну кроме бюджета? Зато представте - Leaf and Spine, стабильная топология в андерлее, полный ECMP (прощайте LAG'и), никаких TRILL, FabricPath и прочих "интересных" L2 роутинг протоколов. А уж в оверлее так вообще сказка - нет нужды в STP, броадкасты на минимуме, так как ARP никуда за VTEP не уходит, конечно если EVPN прикрутить как control plane...
Вобщем что не так-то?
DHCP - легко, VTEP обычно может работать как DHCP Relay для VXLAN. Про всех вендоров не скажу, но в HPE/H3C Comware 7 это делается запросто - на VSI-Interface конфигурируем:interface Vsi-interface<number>
dhcp select relay
dhcp relay server-address <dhcp_server_ip_address>
и вуаля. Поясню - 'vsi' это то же, что и 'bridge-domain' на Хуавее, 'interface VSI-interface' это как 'interface nve' на том же Хуавее, фактически это SVI для VXLAN.
dot1x - это тоже возможно, но вижу для тех же HPE фичу "802.1X support for VXLANs" со следующим замечанием:
when the device acts as both a VXLAN VTEP and a NAS, users' service information cannot be identified by VLANs. To resolve this issue, you must configure the RADIUS server to assign VSIs to authenticated 802.1X users. The NAS will map a user's traffic to the VXLAN that is associated with the user's authorization VSI. The mapping criteria include the user's access VLAN, access port, and MAC address.
Сам, однако же, в живую такого деплоймента не видел, врать не буду, но раз фича есть, значит не у одного меня такие странные устремления и даже если что-то где-то как-то не так работает, со временем допилят. А может и уже все ок работает, не копался в этом пока что.
Тоже за это сразу глаз уцепился.
Если свич поддерживает стэкирование - это нисколько не делает его коммутатором ядра. Тем более когда 2 из 4 10Ge портов заняты стэком.
Уже более 10 лет на уровне доступа, по крайней мере на десктопных сетевых картах, правит гигабит, лет пять как на серьезных серверах чуть ли не в базовых комплектациях наличевствуют 2,5-10Ge порты.
А тут предлагают гигабитный свич на ядро, пишут про Active-Standby БП без возможности горячей замены, и незначительную плюшку в виде фторой флешки с конфой.
Да 48 юзеров при 20Мб от каждого забьют в полку гигабитный аплинк доступа, если 24 таких объединить в агрегацию, то гарантированный аплинк от каждого юзера на ядро уже меньше двух. И тут упоминают примечание про "Учитывая массовый характер закупок", да я при переходе на трехуровневую архитектуру на агрегацию буду 10Ge ставить, не то что на ядро.
Коммутаторы ядра сети — что это такое, для чего нужны и как выглядят