jffulcrum

На С-З снова учения походу.

Критическая масса - это Apple или Google. На примере VPN Apple уже знатно толкнула говно переход на IKEv2. Гугель беспощадно форсил HTTPS, HTTP/2, DKIM и много еще чего. Если сочтут, что клиенты созрели на IPv6-only - будет весело. А никакие убеждения энтузиазистов, что v6 - это круто, ничего не толкнут, как 90% RFC. Только насильничать, только хардкор!

Я вообще не пров. CT имеет достаточно серьезные ограничения. Например, у вас два аплинка, и сделан LB. Или есть L2 P2P, например юрик у вас VLAN между соседними точками заказал. Что происходит в режиме CT: прилетает пакет с аплинка, свитч его хоп - сделал wire на нисходящий интерфейс, а тот уже в этот момент что-то передает, полученное с другого линка. И происходит такое подзабытое явление как коллизия. В лучшем случае перенаправленный пакет просто пропадет. В худшем - клиент получит мусор, а участники безобразия получат штраф на inter-frame gap, причем, взят будет по самому низкоскоростному интерфейсу, то есть аплинк на ровном месте пролюбит большую часть своей полосы, еще и наверху создав проблему. Ну а посколько свитч с CT, скорее всего, дорогой и высокоинтеллектуальный, то после пары таких факапов его мозги решат, что кожаные ублюдки опять обосрались и переведет порты в режим S&F, а то и весь свитч целиком. И, поскольку ASICи нынче работают на гигагерцовых скоростях, буферов мегабайты, то никто этого и не заметит, особенно если нет Jumbo frames, нагрузка далека от предельной и нет протоколов, чувствительных к задержкам, в отличие от TCP/IP, у которого задержки в стеке ОС зачастую в разы больше канального времени.

Сиську 9000 за такие деньги разве что сильно Б/У найти можно, где-нить на Наибее

До ip у вас не доходит, у вас фаза 2 не начинается, либо клиент не смог проверить подлинность сервера, либо не совпадают алгоритмы шифрования сервера и клиента.

С докером хорошо отделяется php-fpm и другие модули, поддерживающие fcgi-proxy. А если такой поддержки нет и там файлы, то надо будет делать nfs или тащить файловую систему с хоста в контейнеры, и в итоге докер получается оверхед и оверинжениринг

Это прилетает с другого конца. Клиенту что-то не понравилось и он отправил роутеру сигнал на разъединение.

Это не только на стационарных номерах, и на мобильных тоже. В старину, телефонная линия была достаточно физической сущностью, и ширина интерконнектов определялась по-сути числом пар в проводе. Интерконнект обычно составлял лишь долю от числа клиентских линий, стоил дорого, потому оператор был заинтересован в отсеивании "зависших" вызовов, например когда абонент забывал положить трубку или занимал слишком много времени линии (модем, коммерческие службы на дому, etc). После цифровизации линия стала более виртуальным понятием (хотя вопросы цены и емкости никуда не делись, просто сильно сдвинулись вдаль) и на первый план вышла борьба с телефонным мошенничеством, когда к линии жертвы несанкционированно подключались, или обманом заставляли куда-то позвонить и удерживали на линии, при этом получатель звонка обычно находился в какой-то дорогой зоне, вроде островов Океании. Жертвы, таким образом, попадали на крупные деньги, и лимит длительности звонка хоть как-то ограждал от ухода в глубокие минуса. Лимиты есть и сейчас. В Штатах во времена At&T был лимит в три часа, которого многие операторы придерживаются до сих пор (в том числе вследствие предустановок на оборудовании для телефонии). На мобильных лимиты обычно 59 минут или 31 минута, уточнять у оператора.

Это стандартная болячка CCR на TILE архитектуре - при массовых операциях с VLAN не все операции проходят корректно. Потому да, в скриптах стоит ставить disable/enable в конце

А что на телефоне, StrongSwan? Попробуйте с компа, чтобы логи клиента были

В 7 VRF улучшен, да. Вопросы остались только по его производительности.

@iraklizh Конечно, контроллер выполняет разные роли, но в целом его вообще можно включать раз в неделю. Так что отвалы самого контроллера на клиентов влиять не должны.

Спасибо что не обнулили удаленно через какую-нибудь телеметрию или автоапдейт, и то счастье.

У контроллера UniFi есть логи, не пробовали читать в этот момент? У точек доступа может скакать питание. У 1920 тоже есть логи, с ними тоже стоит ознакомиться.

А версия CHR и Dude какая? Были в прошлом году в изменениях фиксы на похожее.

Cut-through очень специфическая штука, призванная помочь ровно в одном случае: когда надо из высокоскоростных портов лить потоком в низкоскоростные с минимальной задержкой. То есть ситуация условного выделенного Гой-Пи-ТиВи, когда на узле 40G порт с ядра, а на выходе пара-тройка 10G портов на распределение пожиже. Очень уж специфическая ситуация. Гипотетически возможно лить между односкоростными портами для получения минимальных задержек, но для этого требуется императивная топология "порт к порту". Фактически это SAN, выделенный канал кластеризации (для синхронизации памяти), ну и может финтех. То есть источник и приемник имеют выделенные порты, никаких роутеров и фрагментации, и в один момент времени с вероятностью 99.99% отправляет только один из них. Иначе даже при включенном CT де-факто работать будет в режиме S&F, о чём, в лучшем случае, жаждущий zero latency узнает случайно на форуме вендора. У меня в хозяйстве несколько Nexus 9000 в таком режиме, и там именно SAN&кластеризация. Сейчас приехал НетЖыр M4500-32C, который умеет в CT, надо будет проверить всхожесть на обычной сети и вообще наличие эффекта от CT. А то когда ASIC пашут на гигагерцовых частотах, там задержки сложно будет отличить.

Очень общее определение. Это может быть старый Cisco VRF-Lite (тогда нужно оборудование Cisco), MPLS L3VPN (тут можно Mikrotik, есть примеры, но гарантий всё же никаких), или же новый Cisco Easy Virtual Network (EVN) - тут тоже только железо от Cisco, причем с IOS-XE.

С закрытием портов силами провайдера всякие интересности обнаруживаются при изучении документации, например: ACL6 правил поддерживается значительно меньше, чем ACL4

Откуда? Приземляется оно все равно на обычный Ethernet с его 1500 фреймом, в 99.99% случаев. Я прекрасно помню, как бомбануло, когда оказалось, что WebSocket и WebRTC позволяют прекрасно идентифицировать пользователей за NAT/VPN. При этом передаче аудио и видео оно не особо-то и помогло, и все, попытавшись поиграть с этими фантиками, быстро выяснили, что требуются серьезные серверные мощности и не менее серьезные навыки программистов, и один фиг плохой WiFi у клиента - и все нанотехнологии сливаются (а костыли поверх HTTP продолжают работать)

Кажется уже все для подобных целей завели Казбекистанские карточки

Очень оптимистично. Во-первых, требуется, чтобы не возникло капитальных проблем с минимальными благами - вода, еда, энергия, если возникнут - будет не до пост-индастриала, причём всем. Во-вторых, в "золотом миллиарде" явно наметились тенденции к окукливанию, типа, надоело всяких дикарей тащить в Свободу и Демократию. Тащем-то, в этот раз железный занавес растёт прежде всего с той стороны. Так что Счастье будет довольно строго географически локализовано, а по границам рая будут стены с дронами-убийцами и Либеральный Интернет-щит "ЭТО - ДРУГОЕ!", с цензурой, мыслепреступлениями и блокировками по площадям, собственно, Илоша Маск уже слил документацию на работу щита.

Netspot вроде все еще продают в РФ

И кстати да, ресурсы на FV по IPv6 на пограничных роутерах...у всех ведь памяти хватит, ведь правда?