Точно не по портам. Даже по нестандартным портам TCP соединение устанавливалось, а как до какого-нить TLS-хэндшейка доходило — сразу всё заканчивалось. https, ssh — вот это всё.
Но: не всегда. Иногда устанавливалось и даже какое-то время работало.
Опять-таки, MaxMind не разглашает алгоритм, но выглядит так, что персональные VPN они не маркируют. У меня вот на домашнем адресе есть VPN, но в чёрные списки не попал.
Два способа.
1) Ленивый. Ничего не делать. MaxMind периодически сканирует все хосты интернета (ха!). Скорость не раскрывается, но она в целом приемлема. Как только повторно просканируют — удалят метку из своей базы, а далее все клиенты MaxMind (включая ivi) получат обновление, и — вуаля!
2) Активный. Как уже было замечено в комментах — написать в поддержку MaxMind «Я устранил анонимный прокси, сделайте на мой IP (X.X.X.X) ускоренное сканирование». Они на такие просьбы обычно положительно реагируют. Дальше механика та же — скан, обновление БД.
Да, с таблицами коммутации не многие IX умеют работать, к сожалению.
Из-за этого ещё unknown unicast штормы периодически прилетают. А IX потом такой «broadcast'а не было!». И не сознаются, что почистили FDB. Либо таймеры меньше протухания ARP-кэша.
Некоторые команды дважды, т.к. они на разных IOS немного разный синтаксис имеют или нужного параметра нет, поэтому выбираем другой. no cluster run
no cdp enable
no cdp run
no vstack
no setup express
vtp mode transparent
vtp mode off
no ip http server
no ip http secure-server
no service pad
no logging console
no ip source-route
no ipv6 source-route
no ip forward-protocol nd
no ipv6 pim rp embedded
ip ssh version 2
interface Null0
no ip unreachables
no ipv6 unreachables
Ну и, конечно же, не забываем думать, что эти команды делают, вместо тупого применения. ;)
Фишка в том, что у нас вот, к примеру, уже отдельная страница в wiki «Что надо отключить на циске сразу после распаковки». Кстати, выключить — в соответствии с вашими руководствами.
Так какого ж чорта ваши дефолты не соответствуют вашим руководствам?
Это я прочитал, что вы с Эппл работаете. Поддержка ваших (МТС) абонентов (и соцсетей) не умеет говорит «на iOS услуга Ipv6 сейчас недоступна». Я их с апреля терзал — ничего конкретного мне ответить не могли.
Если им приходит чужая работа, они перенаправляют клиента на нужный адрес.
Я называю это балансировкой на уровне приложения. Такой метод следует применять очень осторожно: сервер может быть перегружен настолько, что redirect отправить клиенту не сможет.
приведены несколько роутеров марки Cisco — для первых двух одновременно поддерживается восемь одинаковых маршрутов, а для последнего поддерживается до 32-х одинаковых маршрутов.
Сразу видно, что человек темой не занимался. Пусть на Sup2T попробует сделать больше 16 ECMP, а я буду ржать в сторонке.
Если через балансер / offload проходит только половина трафика (от клиента к серверу), то такое устройство не может знать о состоянии TCP-соединения. Вдруг сервер уже давно RST послал? А ACK вообще был? Соответственно, это остаётся простой, тупой L3 балансер. Чем он лучше роутера? Без стейтов — ничем.
Польза была бы, если такое устройство могло «подсасывать» состояния TCP-соединений из серверов, из ядра ОС. Но я про такие устройства не слышал.
Почитал, кстати, про Yahoo и l3dsr. Бедняжки. Им бы MPLS на серверах…
ИМХО, в наш век мифа о мобильном интернете, если приложение не обрабатывает разрыв какой-либо HTTP-сессии, я бы сказал, что автор приложения не прав.
А если приложение разумно такую ситуацию обрабатывает, то anycast в общем смысле не страшен. Кроме приложений, которые вот совсем никак не могут быть stateless (имею в виду — неотрывными от конкретного сервера, который обрабатывает запросы). Грубо говоря: статику с anycast качать — без проблем, а вот свою почту прочитать — наверное, на anycast никак не сделать. NTP сделать на anycast — да, а вот SIP — вряд ли.
Спасибо, уже копаем в этом направлении. :) Но чуть-чуть по-другому. По результатам беру на себя обязательство написать статью.
Насчет flow-spec — ждём обновления от циски. Обещали добавить в этом году.
1) Ну, соотношение не 1 к 1000, но да, исходящего сильно больше. Так вот если балансер в режиме полного проксирования, то он всю эту полосу должен через себя пропустить. Поэтому 20Гбит на балансер — не смешно.
Перенаправление — это редиректор. Это совсем другая история… С ним, конечно, по полосе уже не такие ограничения. Но по-прежнему остаётся проблема единой точки отказа.
Думаю, следующую статью напишу про внутренности кластера — там станет понятно, на чём мы остановились.
2) нет, ни в коем случае. В кэширующем кластере узлы неравноценны по контенту. Но количество узлов кластера увеличивает суммарную нагрузочную способность. Опять же, это внутренности кластера.
/ip route add type=blackhole
Как-то так
Но: не всегда. Иногда устанавливалось и даже какое-то время работало.
Два способа.
1) Ленивый. Ничего не делать. MaxMind периодически сканирует все хосты интернета (ха!). Скорость не раскрывается, но она в целом приемлема. Как только повторно просканируют — удалят метку из своей базы, а далее все клиенты MaxMind (включая ivi) получат обновление, и — вуаля!
2) Активный. Как уже было замечено в комментах — написать в поддержку MaxMind «Я устранил анонимный прокси, сделайте на мой IP (X.X.X.X) ускоренное сканирование». Они на такие просьбы обычно положительно реагируют. Дальше механика та же — скан, обновление БД.
И есть ещё одна проблема: MaxMind бесплатно не показывает статус IP адреса. Но можно воспользоваться чем-то другим. Например, www.ipqualityscore.com/free-ip-lookup-proxy-vpn-test/lookup
Из-за этого ещё unknown unicast штормы периодически прилетают. А IX потом такой «broadcast'а не было!». И не сознаются, что почистили FDB. Либо таймеры меньше протухания ARP-кэша.
no cluster run
no cdp enable
no cdp run
no vstack
no setup express
vtp mode transparent
vtp mode off
no ip http server
no ip http secure-server
no service pad
no logging console
no ip source-route
no ipv6 source-route
no ip forward-protocol nd
no ipv6 pim rp embedded
ip ssh version 2
interface Null0
no ip unreachables
no ipv6 unreachables
Ну и, конечно же, не забываем думать, что эти команды делают, вместо тупого применения. ;)
Так какого ж чорта ваши дефолты не соответствуют вашим руководствам?
Это скорее всего, ошибка при расшифровке. Думаю, имелся в виду CDN.
Я называю это балансировкой на уровне приложения. Такой метод следует применять очень осторожно: сервер может быть перегружен настолько, что redirect отправить клиенту не сможет.
Сразу видно, что человек темой не занимался. Пусть на Sup2T попробует сделать больше 16 ECMP, а я буду ржать в сторонке.
Польза была бы, если такое устройство могло «подсасывать» состояния TCP-соединений из серверов, из ядра ОС. Но я про такие устройства не слышал.
Почитал, кстати, про Yahoo и l3dsr. Бедняжки. Им бы MPLS на серверах…
А если приложение разумно такую ситуацию обрабатывает, то anycast в общем смысле не страшен. Кроме приложений, которые вот совсем никак не могут быть stateless (имею в виду — неотрывными от конкретного сервера, который обрабатывает запросы). Грубо говоря: статику с anycast качать — без проблем, а вот свою почту прочитать — наверное, на anycast никак не сделать. NTP сделать на anycast — да, а вот SIP — вряд ли.
Насчет flow-spec — ждём обновления от циски. Обещали добавить в этом году.
Перенаправление — это редиректор. Это совсем другая история… С ним, конечно, по полосе уже не такие ограничения. Но по-прежнему остаётся проблема единой точки отказа.
Думаю, следующую статью напишу про внутренности кластера — там станет понятно, на чём мы остановились.
2) нет, ни в коем случае. В кэширующем кластере узлы неравноценны по контенту. Но количество узлов кластера увеличивает суммарную нагрузочную способность. Опять же, это внутренности кластера.