При подключении одного устройства в разные коммутаторы (bonding=lag) поддержки LAG и LACP недостаточно. Тут требуется поддержка MC-LAG или EVPN (c ESI). Ну или стекирование… хотя, да простят меня адепты стека, весь смой скромный практический опыт говорит мне, что стекирование — зло. Во всём, кроме удобства управления. Но в эпоху ansible, chef и пр. это уже не актуально.
Странный у вас клиент… додумался выстрелить себе в ногу, но зарядил холостой патрон. Намекните ему, что бы в следующий раз было ещё интереснее добавить авторизацию вводимых команд.
None — аутентификация не требуется, доступ к устройству прдоставляется без ввода логина и пароля.
Это не совсем так и это же таит в себе ещё большую опасность, ибо позволяет зайти не только без логина и пароля, но и под любым логином. И у вас опечатка в слове предоставляется.
От asr1k дома я бы тоже не отказался, хотя хватило бы и 2951 + HWIC WIFI + SRE (для торрентов, сквида, файлохранилища и виртуалок), но вот цена… хм, хотя немного меньше чем asr1k :)
Собственно, конструктивный диалог, рискует перерасти в бессмысленный спор и каждый останется при своем мнении.
Уважаю ваше мнение.
Для этих целей, ни cisco, ни juniper не нужны
1) squid transparent сразу на шлюзе, если wccp не самоцель
2) tc (хоть с классовыми, хоть с без классовыми дисциплинами), altq и т.д. в любых позах и положениях
3) iproute2, pf и пр.
4) racoon, strongSwan, openvpn и иже с ними
5) Вот этот пункт, пожалуй, единственное, что может как-то оправдать необходимость
О да, особенно когда корбилайн решил терминировать l2tp на лупбеках и его адрес же выдавать в качестве шлюза по-умолчанию, вот тогда удобные дебаги очень пригодились. Хотя это я придираюсь.
Отлично, этого пункта не хватало для самоопределения.
Вопрос стоит скорее как ваши знакомые их используют? Если отвлечься от необходимости использовать какие-то проприетарные технологии (например, канал из дома на работу используя cisco dmvpn) или стенд отработки лаб на реальном железе (хотя есть отличные средства практиковаться в виртуальной среде IOU/IOL/Olive/GNS и тп.), то смысл использовать дорогое и инизкопроизводительное оборудование (относительно стоимости) для меня отсутствует.
А если у меня стоит «настоящий» маршрутизатор на базе x86 fanless-системы с FreeBSD на борту, то какой вариант мне выбрать?
Да и я за всю многолетнюю практику не видел людей добровольно согласившихся бы на установку настоящего маршрутизатора cisco/juniper etc дома.
Ну если в вашей сети ESXi стандарт, то посмотрите на cisco csr1000v и DMVPN со всеми его плюшками у вас в кармане (точнее full cisco routing portfolio solutions). Единственный вопрос лицензирования этого счастья для меня остался не ясен окончательно.
Увеличение пропускной способности агрегированного линка — это все лишь, побочный эффект работы алгоритма балансировки. И хочу предостеречь от громких фраз, ибо 8х10G ≠ 80G. Сравнимой полосы можно добиться только при выполений определенных условностей.
Своего случая или чего-либо похожего в хендбуке и других доках по мосту не нашел.
32.5.7.4 Sticky Interfaces — FreeBSD Handbook — не ваш случай?
Экспериментировать на живой сети — это я вам скажу, почти всегда не правильно. Увы, но за давностью лет, у меня не осталось конфигов, что бы показать как оно должно быть. Стенд самое правильное решение, ещё помнится, promiscuous mode на физ. интерфейсах был крайне полезен.
Вы поясните не очевидный мне момент: в качестве решения проблемы нехватки полосы на радио-линке, вы поделили абонентов на два влана? Если это так, то вот что я имею ввиду: FreeBSD Bridging
Как вариант.
Да даже перемычка на портах коммутатора, объединяющая ваши вланы мне видится менее «костыльным» вариантом, чем представленное решение.
Вы пожалуйста не обижайтесь на мою настойчивость, просто я так и не понял зачем ваш вариант нужен в данном случае. Если не прав, то с радостью в этом признаюсь.
Я допускаю, что прочитав пост по диагонали упустил тот, единственно важный момент, который все объяснит. Но прочитав его ещё раз, так и не смог понять почему, не создать bridge из этих интерфейсов и на него повесить l3?
А вы не озвучите нам причину побудившую создать такое дикое извращение? Почему не использовать множественные маршрутные таблицы? Ведь инструменты есть и есть давно, уж тем более во FreeBSD.
Конечно GNS3 проще визуально, но каждый раз натыкаешься на не поддерживаемые фитчи, которые просто не работают без объяснений. С IOU в этом плане все значительно прозрачнее, если фитча не поддерживается, то об этом будет наглядно сказано. Попробуйте сделать на GNS'е лабу с… например, bfd. Да и стабильность работы IOU позволяет спокойно его дергать не опасаясь, что свя топология «разъедется». Как-то ради спортивного интереса и паралельной провекри правил zbf ходил через IOU маршрутизатор в инет — работает.
Судя по описанию никакой statefull синхронизации у них нет (и позиционируется она как маршрутизатор), но есть vrrp, mpls, mpls-te, что само по себе довольно интересно. Единственное, не представляю себе ясно сферу его применения в реальности, а не в маркетинговых фантазиях, ака cloud core. Возможно в качестве CPE на крупный узел… Хм… В любом случае — железка интересная, а цена позволит купить на поиграться.
Я не оспариваю техническую сторону вопроса, ибо сам несколько лет назад расставлял списанные 3640 набитые асинхронными модулями и воткнутым в aux модемом именно для собирания консольных логов, выводов crashdump'ов и coredump'ов, исправления косяков потери управления и пр. Сам по себе метод универсален и применим в большинстве случаев. практически с любым железом.
Приветствую.
Познавательная статья.
Не рассматривали более, скажем так, специализированные решения? Например: Digi CM Всё же для большого количества устройств NM-16A маловато.
Спасибо за обзор, прям ностальгия одолела, пойду 1605R с uptime в 4,5 года тряпочкой пыль сотру…
Мельком глянув заголовок, решил прочитать хороший обзор cisco ASR 1000 (общую архитектуру, ios как виртуальная среда и пр.), но не разочаровался. Ещё раз спасибо!
Это не совсем так и это же таит в себе ещё большую опасность, ибо позволяет зайти не только без логина и пароля, но и под любым логином. И у вас опечатка в слове предоставляется.
Собственно, конструктивный диалог, рискует перерасти в бессмысленный спор и каждый останется при своем мнении.
Уважаю ваше мнение.
1) squid transparent сразу на шлюзе, если wccp не самоцель
2) tc (хоть с классовыми, хоть с без классовыми дисциплинами), altq и т.д. в любых позах и положениях
3) iproute2, pf и пр.
4) racoon, strongSwan, openvpn и иже с ними
5) Вот этот пункт, пожалуй, единственное, что может как-то оправдать необходимость
О да, особенно когда корбилайн решил терминировать l2tp на лупбеках и его адрес же выдавать в качестве шлюза по-умолчанию, вот тогда удобные дебаги очень пригодились. Хотя это я придираюсь.
Вопрос стоит скорее как ваши знакомые их используют? Если отвлечься от необходимости использовать какие-то проприетарные технологии (например, канал из дома на работу используя cisco dmvpn) или стенд отработки лаб на реальном железе (хотя есть отличные средства практиковаться в виртуальной среде IOU/IOL/Olive/GNS и тп.), то смысл использовать дорогое и инизкопроизводительное оборудование (относительно стоимости) для меня отсутствует.
Да и я за всю многолетнюю практику не видел людей добровольно согласившихся бы на установку настоящего маршрутизатора cisco/juniper etc дома.
32.5.7.4 Sticky Interfaces — FreeBSD Handbook — не ваш случай?
Экспериментировать на живой сети — это я вам скажу, почти всегда не правильно. Увы, но за давностью лет, у меня не осталось конфигов, что бы показать как оно должно быть. Стенд самое правильное решение, ещё помнится, promiscuous mode на физ. интерфейсах был крайне полезен.
FreeBSD Bridging
bridge0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether d2:41:75:d6:ff:0d inet 172.16.1.254 netmask 0xffffff00 broadcast 172.16.1.255 inet 172.16.52.254 netmask 0xffffff00 broadcast 172.16.52.255 inet 172.16.3.254 netmask 0xffffff00 broadcast 172.16.3.255 inet 10.55.1.1 netmask 0xffffff00 broadcast 10.55.1.255 id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: vlan2814 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 7 priority 128 path cost 55 member: vlan2819 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 6 priority 128 path cost 55 vlan2814: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 00:1b:b9:8b:ca:33 inet6 fe80::210:b5ff:fe0d:9c75%vlan103 prefixlen 64 scopeid 0x6 nd6 options=3<PERFORMNUD,ACCEPT_RTADV> media: Ethernet autoselect (100baseTX <full-duplex,flowcontrol,rxpause,txpause>) status: active vlan: 2814 parent interface: em0 vlan2819: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 00:1b:b9:8b:ca:33 inet6 fe80::210:b5ff:fe0d:9c75%vlan104 prefixlen 64 scopeid 0x7 nd6 options=3<PERFORMNUD,ACCEPT_RTADV> media: Ethernet autoselect (100baseTX <full-duplex,flowcontrol,rxpause,txpause>) status: active vlan: 2819 parent interface: em0Как вариант.
Да даже перемычка на портах коммутатора, объединяющая ваши вланы мне видится менее «костыльным» вариантом, чем представленное решение.
Вы пожалуйста не обижайтесь на мою настойчивость, просто я так и не понял зачем ваш вариант нужен в данном случае. Если не прав, то с радостью в этом признаюсь.
Познавательная статья.
Не рассматривали более, скажем так, специализированные решения? Например: Digi CM Всё же для большого количества устройств NM-16A маловато.
Мельком глянув заголовок, решил прочитать хороший обзор cisco ASR 1000 (общую архитектуру, ios как виртуальная среда и пр.), но не разочаровался. Ещё раз спасибо!