ReD: Juniper QFX5100 с могучим Intel Xeon:
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=63 time=10.9 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=63 time=8.74 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=63 time=6.99 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=63 time=51.8 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=63 time=2.19 ms
64 bytes from 10.0.0.2: icmp_seq=6 ttl=63 time=0.795 ms
64 bytes from 10.0.0.2: icmp_seq=7 ttl=63 time=1.48 ms
64 bytes from 10.0.0.2: icmp_seq=8 ttl=63 time=10.3 ms
64 bytes from 10.0.0.2: icmp_seq=9 ttl=63 time=7.29 ms
64 bytes from 10.0.0.2: icmp_seq=10 ttl=63 time=10.5 ms
64 bytes from 10.0.0.2: icmp_seq=11 ttl=63 time=4.29 ms
64 bytes from 10.0.0.2: icmp_seq=12 ttl=63 time=2.89 ms
64 bytes from 10.0.0.2: icmp_seq=13 ttl=63 time=1.17 ms
64 bytes from 10.0.0.2: icmp_seq=14 ttl=63 time=10.1 ms
64 bytes from 10.0.0.2: icmp_seq=15 ttl=63 time=7.25 ms
64 bytes from 10.0.0.2: icmp_seq=16 ttl=63 time=5.81 ms
64 bytes from 10.0.0.2: icmp_seq=17 ttl=63 time=3.99 ms
64 bytes from 10.0.0.2: icmp_seq=18 ttl=63 time=10.5 ms
64 bytes from 10.0.0.2: icmp_seq=19 ttl=63 time=1.20 ms
64 bytes from 10.0.0.2: icmp_seq=20 ttl=63 time=2.54 ms
64 bytes from 10.0.0.2: icmp_seq=21 ttl=63 time=1.93 ms
64 bytes from 10.0.0.2: icmp_seq=22 ttl=63 time=4.25 ms
^C
--- 10.0.0.2 ping statistics ---
22 packets transmitted, 22 received, 0% packet loss, time 21019ms
rtt min/avg/max/mdev = 0.795/7.602/51.819/10.254 ms
Juniper EX3300 с каким-то ARM:
PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
64 bytes from 10.0.0.3: icmp_seq=1 ttl=63 time=1.22 ms
64 bytes from 10.0.0.3: icmp_seq=2 ttl=63 time=1.23 ms
64 bytes from 10.0.0.3: icmp_seq=3 ttl=63 time=1.54 ms
64 bytes from 10.0.0.3: icmp_seq=4 ttl=63 time=1.41 ms
64 bytes from 10.0.0.3: icmp_seq=5 ttl=63 time=1.31 ms
64 bytes from 10.0.0.3: icmp_seq=6 ttl=63 time=1.49 ms
64 bytes from 10.0.0.3: icmp_seq=7 ttl=63 time=1.20 ms
64 bytes from 10.0.0.3: icmp_seq=8 ttl=63 time=1.53 ms
64 bytes from 10.0.0.3: icmp_seq=9 ttl=63 time=1.83 ms
64 bytes from 10.0.0.3: icmp_seq=10 ttl=63 time=1.80 ms
64 bytes from 10.0.0.3: icmp_seq=11 ttl=63 time=1.46 ms
64 bytes from 10.0.0.3: icmp_seq=12 ttl=63 time=1.00 ms
64 bytes from 10.0.0.3: icmp_seq=13 ttl=63 time=1.65 ms
64 bytes from 10.0.0.3: icmp_seq=14 ttl=63 time=1.59 ms
64 bytes from 10.0.0.3: icmp_seq=15 ttl=63 time=10.9 ms
64 bytes from 10.0.0.3: icmp_seq=16 ttl=63 time=1.96 ms
64 bytes from 10.0.0.3: icmp_seq=17 ttl=63 time=1.41 ms
64 bytes from 10.0.0.3: icmp_seq=18 ttl=63 time=1.51 ms
64 bytes from 10.0.0.3: icmp_seq=19 ttl=63 time=1.53 ms
64 bytes from 10.0.0.3: icmp_seq=20 ttl=63 time=1.64 ms
64 bytes from 10.0.0.3: icmp_seq=21 ttl=63 time=2.28 ms
64 bytes from 10.0.0.3: icmp_seq=22 ttl=63 time=1.35 ms
^C
--- 10.0.0.3 ping statistics ---
22 packets transmitted, 22 received, 0% packet loss, time 21023ms
rtt min/avg/max/mdev = 1.009/1.950/10.904/1.973 ms
Хотя при этом время переброса транзитного фрейма сильно меньше мс. Просто такая архитектура, что на пинги отвечает совсем другой компонент.
>настроить файрвол так, что бы он пропускал только ping-запросы/ответы. Это пакеты с типом 0 и 8
А потом вылазят проблемы с MTU на ровном месте. Unreachable тоже надо пропускать, он не просто так придуман.
Сергей Якушев: Совершенно некорректная настройка со стороны провайдера, и тем более неадекватное поведение техподдержки. При такой настройке не будут работать большинство роутеров. Да и в целом это полное безумие - отдавать клиенту тегированный трафик без особых договоренностей.
Вероятнее всего, забыли сделать порт access в вашу сторону, а в винде работает лишь потому, что сама винда игнорирует вообще dot1q, а на вход на коммутаторе висит правильный PVID.
Техподдержке лучше напрямую сообщить номера тегов, который вы получаете, пожаловаться на некорректную настройку с их стороны, можно взять какой-нибудь linux-based роутер вроде tp-link или даже mikrotik и отплясывать от него при жалобе. А лучше сразу же добиваться до второй линии поддержки или до менеджеров.
P.S. Не удивлюсь, если в вашу сторону еще и Spanning Tree включен или в Edge-режиме без фильтров, тогда, при определенных условиях, можно нехило подгадить сети такого безответственного провайдера. Или выходить в сеть в разных вланах, дабы привлечь внимание понимающих.
Дмитрий: Если бы автор обсудил этот вопрос с провайдером, то самого вопроса бы не возникало, потому что все уже обсудили и решили.
Провайдер не может не знать или не озвучивать названий технологий, их принципов и требований к оборудованию (если это, конечно, не домосеть с одменом из 10-А класса).
SyavaSyava: control-plane его - да, где-то на уровне LLC. Но не все так просто. Нормальные коммутаторы знают и про положение IP-адресов в фрейме, и про tcp/udp порты и могут использовать эту информацию для выбора конкретного линка из группы. Некоторые даже можно настраивать, какие данные использовать. Но вот коммутаторы доступа, в большинстве случаев, ничего кроме source mac/dst mac и vlan не понимают, соответственно при подключении к провайдеру, где на layer2 весь трафик идет между 2 точками (роутером клиента и роутером провайдера) - никакой балансировки не будет, соответственно и прибавки скорости.
Алексей POS_troi: с того, что у него всего одна пара mac-src/mac-dst, и всего один ip-dst. Далеко не всякий коммутатор доступа сумеет разложить нормально трафик по ip-source или номеру портов.
И в целом к агрегации лучше прибегать только когда ну вообще никак не обойтись.
btpa: bgp не даст никакой анонимности, как раз наоборот: все провайдеры, при использовании bgp, строго настрого фильтруют получаемые префиксы (а кто не фильтрует - рано или поздно отхватывает проблемы), и никто ни с кем не поднимает BGP анонимно "просто так". К тому же BGP - это свой пул адресов, своя АС, своя запись в whois.
А вот "предоставление в аренду IP клиенту" нигде кроме договора и внутренних БД провайдера, как правило, не светится. И провадер не выдаст кому попало эту информацию.
btpa: нет, это как раз к провайдерам шпд интернета относится.
С серверами проще - как правило, все хостинговые конторы явно указывают адреса своих датацентов.
Chvalov: так вам дхцп-сервера искать и отстреливать надо, а не сканить что-то абстрактное. ДХЦП-сервера отлично отвечают на запросы. Найдите готовый софт или напишите свой скрипт на питоне, который это делать будет.
Вадим Егоров: Вот сейчас я понял ,чего вы хотите. HTTP-доступности снаружи на серый адрес?
Это можно решить обычным reverse-proxy типа nginx, который имеет доступ в серую сеть провайдера, и кнопкой в личном кабинете, которая заводит virtual host смотрящий на серый клиентский адрес. Но это уже, практически, пол-хостинга. И на уровень стандарта вряд ли выйдет. Юрлица и так, как правило, требуют белый адрес, а физикам оно особо и не нужно, в крайнем случае опять же купят адрес.
Покупка белого адреса намного проще для всех. По крайней мере пока.
Возможно даже придем к продаже не белых адресов, а белых портов для нуждающихся по дешевке.
Вадим Егоров: изначально вы говорили про анализ HOST из HTTP и прочих извратов. Просто IP.DOMAIN.com и так может смотреть сразу на клиентский адрес, более того, на белых адресах скорее всего оно уже так и есть и работает для нормальной работы PTR и связанных почтовых серверов.
Вадим Егоров: Посчитайте-ка, сколько стоит сервер, который сможет в принципе отмаршрутизировать хотя бы 20 гбит трафика. И увеличьте мощность (как минимум ЦПУ) раза в два, так как перехват соединений, отслеживание их состояний и прочее сопутствующее-- намного более тяжелые операции.
А теперь умножьте цену минимум на два, так как нужен резерв. А теперь добавьте стоимость соответствующих портов на коммутаторах, стоимость выворачивания трафика черезодноместо к этим серверам и т.д. Зачем? Тем более, что это неизбежно приведет к лишним милисекундам задержек, лишней точке возникновения проблем, лишнему куску железа, который нужно обслуживать.
Да и НАТ далеко не у всех есть.
P.S. практически всегда у провайдеров на белые адреса типа 185.64.X.Y смотрит DNS адрес вида y.x.provider.net или host-185-64-X-Y.provider.net (или как у админа фантазии хватит), при чем резольвится в обе стороны. Связано это с наличием у адресов PTR-записей. И не надо никаких L7-routing и прочих извратов.
P.P.S. А вообще любой клиент может взять себе халявный домен с халявным днс-сервером (или планые) и не гемороиться непонятными идеями.
Вадим Егоров:
>стоит полноценная ОСь или есть возможность поставить и в ней что угодно делайте, хоть HTTP заголовки проверяйте, хоть что ещё.
категорически нет. Мало того, что подавляющая часть трафика на производительных специализированных маршрутизаторах выполняется специализированными ПЛИСами с микроядром, о которых информацию имеет только производитель, так еще и значительная часть трафика вообще маршрутизируется на L3-коммутаторах аппаратно, где что-то добавить/поправить представляет из себя проблему даже для разработчиков устройства.
Вадим Егоров: зачем все это провайдеру?
Ломать OSI-стек, покупать дорогостоящее оборудование, умеющее в DPI, придумывать дикие схемы кривой маршрутизации по L7 ради полутора инвалидов, которым "хочется"? Это не станет массовым, никто не захочет видеть IP вместо нормальных DNS.
В принципе, в _некоторых странах_ провайдеров, по сути, обязали чем-то подобным заниматься (влезать в L7 протокол, парсить SNI из HTTPS и URL из GET/POST) но даже там есть заранее приготовленный четкий список хостов, в направлении которых надо это делать, а не вообще все подряд.
Kirill Kuznetsov: нету у него IPv6 и не выдает он ничего - он просто коммутатор, а не IPv6-роутер.
У него адрес по-умолчанию 10.90.90.90/8, ставите себе на сетевушку адрес 10.90.90.91/8 и заходите. Если не заходит - то ресетаете его кнопкой и заходите.
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=63 time=10.9 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=63 time=8.74 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=63 time=6.99 ms
64 bytes from 10.0.0.2: icmp_seq=4 ttl=63 time=51.8 ms
64 bytes from 10.0.0.2: icmp_seq=5 ttl=63 time=2.19 ms
64 bytes from 10.0.0.2: icmp_seq=6 ttl=63 time=0.795 ms
64 bytes from 10.0.0.2: icmp_seq=7 ttl=63 time=1.48 ms
64 bytes from 10.0.0.2: icmp_seq=8 ttl=63 time=10.3 ms
64 bytes from 10.0.0.2: icmp_seq=9 ttl=63 time=7.29 ms
64 bytes from 10.0.0.2: icmp_seq=10 ttl=63 time=10.5 ms
64 bytes from 10.0.0.2: icmp_seq=11 ttl=63 time=4.29 ms
64 bytes from 10.0.0.2: icmp_seq=12 ttl=63 time=2.89 ms
64 bytes from 10.0.0.2: icmp_seq=13 ttl=63 time=1.17 ms
64 bytes from 10.0.0.2: icmp_seq=14 ttl=63 time=10.1 ms
64 bytes from 10.0.0.2: icmp_seq=15 ttl=63 time=7.25 ms
64 bytes from 10.0.0.2: icmp_seq=16 ttl=63 time=5.81 ms
64 bytes from 10.0.0.2: icmp_seq=17 ttl=63 time=3.99 ms
64 bytes from 10.0.0.2: icmp_seq=18 ttl=63 time=10.5 ms
64 bytes from 10.0.0.2: icmp_seq=19 ttl=63 time=1.20 ms
64 bytes from 10.0.0.2: icmp_seq=20 ttl=63 time=2.54 ms
64 bytes from 10.0.0.2: icmp_seq=21 ttl=63 time=1.93 ms
64 bytes from 10.0.0.2: icmp_seq=22 ttl=63 time=4.25 ms
^C
--- 10.0.0.2 ping statistics ---
22 packets transmitted, 22 received, 0% packet loss, time 21019ms
rtt min/avg/max/mdev = 0.795/7.602/51.819/10.254 ms
Juniper EX3300 с каким-то ARM:
PING 10.0.0.3 (10.0.0.3) 56(84) bytes of data.
64 bytes from 10.0.0.3: icmp_seq=1 ttl=63 time=1.22 ms
64 bytes from 10.0.0.3: icmp_seq=2 ttl=63 time=1.23 ms
64 bytes from 10.0.0.3: icmp_seq=3 ttl=63 time=1.54 ms
64 bytes from 10.0.0.3: icmp_seq=4 ttl=63 time=1.41 ms
64 bytes from 10.0.0.3: icmp_seq=5 ttl=63 time=1.31 ms
64 bytes from 10.0.0.3: icmp_seq=6 ttl=63 time=1.49 ms
64 bytes from 10.0.0.3: icmp_seq=7 ttl=63 time=1.20 ms
64 bytes from 10.0.0.3: icmp_seq=8 ttl=63 time=1.53 ms
64 bytes from 10.0.0.3: icmp_seq=9 ttl=63 time=1.83 ms
64 bytes from 10.0.0.3: icmp_seq=10 ttl=63 time=1.80 ms
64 bytes from 10.0.0.3: icmp_seq=11 ttl=63 time=1.46 ms
64 bytes from 10.0.0.3: icmp_seq=12 ttl=63 time=1.00 ms
64 bytes from 10.0.0.3: icmp_seq=13 ttl=63 time=1.65 ms
64 bytes from 10.0.0.3: icmp_seq=14 ttl=63 time=1.59 ms
64 bytes from 10.0.0.3: icmp_seq=15 ttl=63 time=10.9 ms
64 bytes from 10.0.0.3: icmp_seq=16 ttl=63 time=1.96 ms
64 bytes from 10.0.0.3: icmp_seq=17 ttl=63 time=1.41 ms
64 bytes from 10.0.0.3: icmp_seq=18 ttl=63 time=1.51 ms
64 bytes from 10.0.0.3: icmp_seq=19 ttl=63 time=1.53 ms
64 bytes from 10.0.0.3: icmp_seq=20 ttl=63 time=1.64 ms
64 bytes from 10.0.0.3: icmp_seq=21 ttl=63 time=2.28 ms
64 bytes from 10.0.0.3: icmp_seq=22 ttl=63 time=1.35 ms
^C
--- 10.0.0.3 ping statistics ---
22 packets transmitted, 22 received, 0% packet loss, time 21023ms
rtt min/avg/max/mdev = 1.009/1.950/10.904/1.973 ms
Хотя при этом время переброса транзитного фрейма сильно меньше мс. Просто такая архитектура, что на пинги отвечает совсем другой компонент.