Скажите пожалуйста, а как по опыту использование LC? Насколько долговечны по сравнению с SC? Я слышал у них гораздо меньшее количество отключений-подключений до отказа. Мы используем LC в одф-ах, пока ещё ни один не сломался.
Интересно, Селектел здесь говорит что «используем оптические разъемы типа FC, обеспечивающие наиболее надежное соединение», но на фото видны «ненадежные» коннекторы SC на ODF-ах (как я вообще запомнил что они это когда-то говорили?).
Хочу добавить, что минус «отсутствие server-affinity при ECMP» применителен далеко не ко всем роутерам.
Juniper серии MX имеет опцию load-balance per-flow, которая как раз обеспечивает этот самый server-affinity:
Есть BGP extended community, обе части которых как раз-таки 32-битные (что позволяет закодировать в них новые номера AS). Ничего изобретать не надо, всё изобретено и внедрено во все сетевое железо.
>а другие операторы используют Extended BGP Communities не по назначению
Вообще-то у атрибута community нет специально выделенного назначения. То что extended community используются ещё и в mpls l3vpn, не значит что их можно использовать только для него и ни для чего более.
Вообще не понимаю в чем сложность написания looking glass «под себя» и не использовать не пойми что от других. Это пишется за один вечер, с учётом просмотра мануалов по html и php (сам так и написал). Главное не забывать валидировать пользовательский ввод регекспами.
Ну правильно, VZ7 же ещё в стадии technical preview. Я его тестировал — вроде как работает, но с нетерпением жду стейбла. Одно непонятно — зачем там подключается репозиторий cloudlinux, из-за которого в систему тянутся их версии вроде бы стандартных пакетов?
Пользуюсь nspawn-ом на личном сервере (Virtuozzo 7, когда же, когда?). Всё работает, кроме квот на диск — их нет. Для них сделал subvolume-ы на btrfs, хотя и тут всплыл недостаток: если на диске закончилась квота, нельзя удалить файлы, чтобы освободить место: disk quota exceeded. Разработчики btrfs знают про этот баг, однако фиксить его не торопятся.
Я только одно понять не могу: как злоумышленник вызовет DNAT портов на самом VPN-сервере, не будучи его владельцем? А если он владелец этого сервера — он и так знает адреса своих пользователей.
Я пользуюсь BIRD, как по мне это самый крутецкий демон роутинга: по удобству, гибкости и автоматизации в стороне стоят не то что циски — даже джуниперы. Разработчики, эти самые NIC.CZ, — замечательные отзывчивые ребята, так что с удовольствием поддержу их.
С микротиком, кстати, осторожнее: мне они очень нравились, пока я не начал ими пользоваться. Везде видны шероховатости и баги, особенно в CSR-серии.
Ну, возможно стоит написать и про остальные гадости в последующих постах.
Многие админы довольно крупных операторов связи, использующих Extreme, не знают про особенность с версией XOS (что баги фиксят патчи, а не новая версия прошивки). После того как узнали, открыли для себя что экстримы не такие уж и глючные какими их рисуют.
«с каким-то обновлением появилось crc32» — ну оно наверняка появилось только на некоторых моделях свитчей. Т.к. этот алгоритм должен уметь ASIC, аппаратная начинка свитча.
Самого главного в настройке LAG-а не указали — настройки хэширования при custom-алгоритме: configure sharing address-based custom hash-algorithm crc-16
Это сделает балансировку по нечётному количеству портов равномерной. В противном в случае на трёхпортовом LAG-е, к примеру, один порт будет загружен на 50% сильнее чем остальные.
И ещё важный ньюанс при использовании экстримов:
Если Вы столкнулись с багом и решили обновить прошивку на свитче — не обновляйте на новую версию. Новая версия может и решит ваш баг, но привнесёт новые. Нужно обновить на ту же версию, но с последним патчем: например была версия 15.3.1.4, стала 15.3.1.4-patch44. Патчи — это багфиксы, без изменения функционала.
Поддерживаю, незачем плодить туториалы на abandonware. Openswan, насколько мне известно, пилит один человек и делает это изредка (последний коммит в гитхабе — 13 марта).
Есть Strongswan, которым занимается профессор информационной безопасности: www.strongswan.org/about.html и который регулярно дорабатывается, судя по коммитам чуть ли не каждый день.
Есть Libreswan, разработка которого также ведётся довольно живо.
>Вы явно не знаете на сетевом превосходстве фряхи над всем остальным.
Таки не первый десяток лет (второй) админю/разрабатываю и под то и под то. Так что наверное всё таки знаю :)
>Но Juniper насколько я знаю, как и Netflix (точно знаю) таки возвращает часть кода в проект.
Часть, да. Джунипер возвращает наработки по поддержке MIPS (насколько мне известно основной вклад в развитие FreeBSD/MIPS сделал именно джунипер), но это можно вполне объяснить тем, что им не хочется тратить силы на поддержку своей ветки фри — пусть будет в мейнстриме. Что возвращает нетфликс не знаю, поэтому насчёт них ничего говорить не буду.
P.S. Мне тоже Зелгадис больше всех в Рубаках нравится :)
Не линуксом единым же. Вот juniper networks, да и Сони в своей PS4 используют фряху как раз потому, что можно не открывать наработки. Правда джуниперы говорили что-то вроде «мы выбирали-выбирали и выяснили что фряха это лучшая ось для сетевого железа» и всё в таком духе, но мне кажется что они взяли её как раз из-за лицензии.
Ага, и в juniper-ах тоже фряха.
Но и Sony и Juniper с гораздо большим удовольствием использовали бы линукс, да только вот его лицензия не позволяет брать, модифицировать под себя, и не открывать код :)
Вот и перебиваются фряхой, в которой так делать можно.
Не совсем строгие условия. Я так понимаю, что ключ для srand один, но последовательность числ rand1 и rand2 будет разной? Взять два (?) закриптованых эксземпляра. crypted1[0] xor crypted2[0] = body1[0] xor rand1 xor body2[0] xor rand2 = body1[0] xor body2[0] xor rand1[0] xor rand2[0] =|body1[0] == body2[0]|= 0 xor rand1[0] xor rand2[0] = | xor 0| = rand1[0] xor rand2[0]. таким образом получить rand1[1] xor rand2[1]. Так как не совсем понял про генератор и каким образом он инициализурется, вродебы двух значений должно быть достаточно, чтобы найти seed и раскодировать все.
Надмозг. Скорее всего речь идёт о терминации QUIC-соединения:
… и так далее
Juniper серии MX имеет опцию load-balance per-flow, которая как раз обеспечивает этот самый server-affinity:
https://www.juniper.net/techpubs/en_US/junos16.1/topics/concept/routing-policy-security-ecmp-flow-based-forwarding-understanding.html
>а другие операторы используют Extended BGP Communities не по назначению
Вообще-то у атрибута community нет специально выделенного назначения. То что extended community используются ещё и в mpls l3vpn, не значит что их можно использовать только для него и ни для чего более.
С микротиком, кстати, осторожнее: мне они очень нравились, пока я не начал ими пользоваться. Везде видны шероховатости и баги, особенно в CSR-серии.
Многие админы довольно крупных операторов связи, использующих Extreme, не знают про особенность с версией XOS (что баги фиксят патчи, а не новая версия прошивки). После того как узнали, открыли для себя что экстримы не такие уж и глючные какими их рисуют.
«с каким-то обновлением появилось crc32» — ну оно наверняка появилось только на некоторых моделях свитчей. Т.к. этот алгоритм должен уметь ASIC, аппаратная начинка свитча.
configure sharing address-based custom hash-algorithm crc-16Это сделает балансировку по нечётному количеству портов равномерной. В противном в случае на трёхпортовом LAG-е, к примеру, один порт будет загружен на 50% сильнее чем остальные.
И ещё важный ньюанс при использовании экстримов:
Если Вы столкнулись с багом и решили обновить прошивку на свитче — не обновляйте на новую версию. Новая версия может и решит ваш баг, но привнесёт новые. Нужно обновить на ту же версию, но с последним патчем: например была версия 15.3.1.4, стала 15.3.1.4-patch44. Патчи — это багфиксы, без изменения функционала.
Есть Strongswan, которым занимается профессор информационной безопасности: www.strongswan.org/about.html и который регулярно дорабатывается, судя по коммитам чуть ли не каждый день.
Есть Libreswan, разработка которого также ведётся довольно живо.
Таки не первый десяток лет (второй) админю/разрабатываю и под то и под то. Так что наверное всё таки знаю :)
>Но Juniper насколько я знаю, как и Netflix (точно знаю) таки возвращает часть кода в проект.
Часть, да. Джунипер возвращает наработки по поддержке MIPS (насколько мне известно основной вклад в развитие FreeBSD/MIPS сделал именно джунипер), но это можно вполне объяснить тем, что им не хочется тратить силы на поддержку своей ветки фри — пусть будет в мейнстриме. Что возвращает нетфликс не знаю, поэтому насчёт них ничего говорить не буду.
P.S. Мне тоже Зелгадис больше всех в Рубаках нравится :)
Но и Sony и Juniper с гораздо большим удовольствием использовали бы линукс, да только вот его лицензия не позволяет брать, модифицировать под себя, и не открывать код :)
Вот и перебиваются фряхой, в которой так делать можно.