nerik

Да, вот не похоже. Судя по отчетам за прошлые дни проскакивали только эти ресурсы несколько раз, главное только http (https нет в отчете), блокировка по домену. Снял дамп-трафика с сервера 104.207.144.62, запрашивает мелкие пакеты, но эти сайты блокируются исправно, смотрел в течении дня. Во вчерашнем отчете их нет, зато полный треш по адресации гугла и фэйсбука)) @max1976, может есть проблема такая же при сборке http, как было при https с navalniy.com? Снять дамп пропуска не удается, т.к. на ПК блокируется исправно, ревизор пока по ним молчит. Кстати в радиочастотном говорят нет скринов, что заставляет еще больше задуматься.

Добрый день. Ни у кого не проскакивают пропуски по ресурсам hello.opentg.us и 12345.***rkn.us? Используем extfilter, но не из ветки exp. Вчера в отчете появились.

Используем zapretservice уже полгода, аптайм сервера тот же) Стоит ревизор и вручную делаем проверку для РКН, претензий со стороны них не получали. Единственное, что маловато функционала пока, например нет черного списка, но обещают в скором времени сделать. А так отвечают оперативно. Сами нас нашли, т.к. подключались к нам, ибо местные ребята)

Эх, прокси не вариант, 2,5G трафика)) Поэтому и смотрю, чем можно на MX редиректить или подсунуть трафик) Это конечно же временное решение, т.к. в планах покупать оборудование DPI. MX используется в качестве бордера. Абоненты мягко говоря задолбали, когда блочится youtube или жж.

Добрый день. Обращаюсь за помощью к гуру juniper :) С железкой еще разбираюсь, поэтому все ньюансы ее пока не понятны. Так как денег на оборудование DPI пока нет, нам приходится блокировать запрещенные сайты жестко на данной железке - с помощью списков filter. Возможно ли на mx80 делать перехват http-траффика на запрещенный сайт (используя данный список)? После делать какой-нибудь редирект на страницу, где будет написано, что сайт был заблокирован по требованию Роскомнадзора. Наткнулся на ссылку http://www.juniper.net/techpubs/en_US/junos12.3/topics/example/http-redirect-service-static-interface-example.html Поможет ли оно? Спасибо))

Всем доброго дня. Тема актуальна. Столкнулись с этой проблемой при настройке lacp между cisco asr1002 и juniper mx80. На циске автоматом работает per-flow, а на juniper как выяснилось per-packet. Пакеты которые уходят с cisco идут в нормальном порядке, а вот с juniper уже нет. В доках у juniper не нашли возможность настроить per-flow, может кто знает как это сделать? А то клиент есть один и сильно жалуется, что большие пакеты у него дропаются в 30-40%, мотивируя что у другого провайдера все хорошо) Заранее спасибо.

Отходим от темы, я не писал что у меня проблема с перегрузкой трафика, шлюз выдерживает 700 Мегабит. Меня уже как год устраивают эти драйвера. Как только будет больше трафика и не будет резервов (новых шлюзов), вот тогда потестим стандартные драйвера. За информацию спасибо. А по факту сегодня 3 день как аномалий не было.

С ними шлюзы очень хорошо трафик жуют. Тем более стандартные не разбрасывают по ядрам нагрузку.

А смысл менять если с ним проблем не было, тем более асинхронный нат очень даже устраивает нас. При pf первый шлюз у нас прогоняет 700 Мегабит. Просто при использовании второго шлюза, мы сейчас через первый гоняем не более 300Мегабит. Проблема то заключается при входе трафика, так как взлетают input errs на сетевой, значит до pf не доходит. Если количество пакетов (с малым размером) будет больше, чем шлюз может прожевать, то он будет загибаться. через команду sysctl сначало добавляли. Да и перезагружали шлюз недавно (в sysctl.conf прописано). нет, взлетают все rx_kthread, от 90 до 100%. Стоит 4 так как у нас 8 ядер на шлюзе. По 4 отдаем на каждую сетевую. нет, сетевые две, внешние, двухпортовые, но используется только по одному порту, на вход и выход. Сейчас мы ожидаем когда проблема появится снова, чтобы точно сказать, что из-за количество пакетов становиться шлюзу плохо (поставили на мониторинг все магистрали на pps). Тогда будет все ясно.

На шлюзе кроме ната ничего нет, BGP на другом бордере. Шлюзы нужны для экономии выделенных адресов (используется pf). Сейчас подозреваю, что кто-то генерирует большое количество пакетов, тем самым ложится софтовый шлюз. tcpdump уже поставлен на мониторинг, будем анализировать его уже позже. По rx_int_delay, я видел, но параметр установлен. Счел это на баг самой сетевой. Но врятли это мешает, т.к. уже год все было отлично с этими параметрами. Насчет top я же писал, что взлетает в момент проблемы процесс rx_kthread до 100%. Какие-то пакеты переполняют буфер сетевой, а вот какие пока ещё неизвестно. Скорее всего дело в их количестве и в меньшем размере. Сейчас будем мониторить их.

Всем доброго дня. Коллеги прошу помощи в советах. Не могу понять кто валит наш шлюз, либо физик какой-то, либо странность в сети. Имеются два шлюза IBM для ната, перед ними есть bras в роли циски ASR1002. Оба шлюза под управлением FreeBSD 7.3 с yandex драйверами 1.36.2.17 (сетевые Intel® PRO/1000, хорошие сетевые, с трафиком не подводили). Работают они отлично и уже очень длительное время. После bras default-маршрут идет на первый шлюз, а на второй мы скинули 16 сетей (Для балансировки входящего в нашу сеть трафика, знаю что криво, но работает). Оба шлюза физически подключены в разные места (в разные коммутаторы), поэтому проблема точно не в физике (т.к. при переносе всего трафика на один из шлюзов, проблема повторяется). Теперь о самой проблеме. Вчера первый шлюз стал загибаться, процессы rx_kthread стали взлетать до 100%, тем самым съедать весь процессор. При выводе команды netstat -hw 1 (данные пока не сохранил) увидел, что копятся errs на input, при этом количество пакетов начинает падать (например с 60K до 3-4K, а ошибки возрастают до 6-7K). Суть в том, что длится это не долго, было вчера 3 раза и каждый такой сбой был от 3 до 10 минут. Bras (ASR1002) не загибается. Колбасит при этом первый шлюз очень даже не дурно. А вот со вторым шлюзом все нормально. Я думал, что это сам шлюз глючит, но когда я весь трафик перекинул на второй, второй стал тоже загибаться с такими же симптомами. tcpdump не выявил ничего плохого. Посмотрел дебаг сетевух: sysctl dev.em.2.stats=1 sysctl dev.em.2.debug=1 Единственное что я крутил у сетевух так это Коллеги помогите, пожалуйста. Подскажите, что за трафик такой может спровоцировать ошибки на сетевой при входе? Спасибо. P.S. Раньше когда трафика было много и шлюз был один, то при перегрузке ошибки появлялись на интерфейсе, но количество пакетов так сильно не падало (ну может на 2-3K, но не на 40K же). Когда появляется вышеописанная проблема, взлет трафика нет, по количеству пакетов сказать пока сложно, но вроде тоже не возрастает.

Ставил ситуация не менялась. На мультикаст натолкнуло то, что когда я циску вырубил, то шлюзы не видели в нейборах друг друга, по tcpdump видно было что они просто отсылали мультикаст hello-пакетами. В итоге когда сделал non-broadcast то все заработало, так как шлюзы стали отсылать helo пакеты напрямую друг другу и они подключились. Не получится, так как в cisco asr с ним проблема при использовании pppoe. Может все таки есть выход (без pwr)?

Перевел интерфейсы на шлюзе и циске в режим non-broadcast и указал друг другу neighbor. Все поднялось и не сбрасывает теперь маршруты. Видимо точно проблема в прохождении мультикаста. Главное в коммутаторе, котором подключена вся схема нет ничего блокирующего по мультикасту. Пробовал заменить коммутатор на другой ситуация та же. Может проблема в кваге. Во-общем щас на режиме non-broadcast все работает. Если можно то ещё вопрос: Можно ли как-нибудь через ospf заставить принудительно отправить траффик на один из шлюзов? Например подключился абонент с айпи 10.10.10.10, а ospf его трафик шлет только на 1.1.1.2 (а так он шлет и на 1.1.1.2 и на 1.1.1.3). А все остальные работали бы так как было.

Положил квагу на обоих шлюзах и на циске сделал clear ip ospf process. Поднял квагу на одном шлюзе и все тоже самое, маршруты сбрасываются и заново поднимаются. В логах шлюза 1.1.1.2:

Ничего не изменилось

Добрый день. Вчера целый день гуглил так и не смог найти решение своей проблемы. Просил помощи на opennet - все глухо, поэтому обращаюсь тут. Может кто поможет. Во-общем дело такое: Есть два шлюза построенных на FreeBSD 7.2 (на них только нат на pf). Оба смотрят в сетку к циске (например 1.1.1.2 и 1.1.1.3, циска имеет 1.1.1.4) Хотел настроить ospf чтобы балансировать нагрузку трафика через два шлюза. На циске теминируются pppoe, а шлюзы указывают в инет. Сейчас схема такова - Абонент PPPoE (10.10.10.1) --> Cisco (1.1.1.4) --> Шлюз (1.1.1.2, pf из серого гонит в выделенный, у каждого шлюза своя сетка для ната) --> другая циска с bgp --> Интернет Такая схема работает. Поднимают ospf на шлюзах и циске На циске На шлюзе (1.1.1.2) стоит quagga (0.99.16) На шлюзе (1.1.1.3) стоит quagga (0.99.16) Сессии поднялись, все вроде работает, клиент видит инет. Но на циске почему-то меняются шлюзы В логах шлюзах такое: Соседи на циске отображаются вот так На первом шлюзе На втором шлюзе Странно, что шлюзы не отображают у себя в neighbor друг друга. Мож и не должны)) Сейчас отключил quagga на одном из шлюзов, такая же канитель. Понять не могу почему на cisco каждые 40-60 сек. стирается маршрут 0.0.0.0 и добавляется новый. Таймауты менял на одинаковые на обоих шлюзах и на cisco 7301. Стали быстрее меняться шлюзы. Вернул обратно таймауты. Голову уже сломал. С OSPF разбираюсь в первые. Помогите пожалуйста. Спасибо. P.S. Под балансировкой имеется ввиду, чтобы трафик равномерно распределялся между шлюзами сам. Потом будет задача регулирования, сейчас надо просто два шлюза объединить.

Всем доброго дня. Столкнулся с такой же проблемой - описывал её здесь. Вечерами замечаю загрузку процесса dummynet от 80 до 100% Бывает только 100%. cpuset ничем не помог, так же 100%. 18 root 171 ki31 0K 8K RUN 0 575.3H 89.99% idle: cpu0 17 root 171 ki31 0K 8K CPU1 1 585.1H 88.38% idle: cpu1 11 root 171 ki31 0K 8K CPU7 7 534.3H 88.09% idle: cpu7 16 root 171 ki31 0K 8K CPU2 2 553.6H 87.50% idle: cpu2 13 root 171 ki31 0K 8K CPU5 5 535.6H 83.89% idle: cpu5 12 root 171 ki31 0K 8K RUN 6 549.3H 78.66% idle: cpu6 14 root 171 ki31 0K 8K RUN 4 549.1H 73.49% idle: cpu4 75 root -68 - 0K 8K - 2 383.9H 64.70% dummynet 15 root 171 ki31 0K 8K CPU3 3 537.3H 43.65% idle: cpu3 42 root 43 - 0K 8K WAIT 7 192.6H 23.78% em0_rx_kthread_1 1862 root 43 - 0K 8K WAIT 5 192.6H 23.39% em0_rx_kthread_2 41 root 43 - 0K 8K WAIT 1 192.4H 23.19% em0_rx_kthread_0 1867 root 43 - 0K 8K WAIT 4 159.2H 20.07% em2_rx_kthread_2 49 root 43 - 0K 8K WAIT 6 159.4H 19.19% em2_rx_kthread_0 50 root 43 - 0K 8K RUN 0 159.6H 18.99% em2_rx_kthread_1 Это утренняя загрузка. Использую яндекс драйвера. Помогли улучшить работу сетевух, ошибок на интерфейсах не наблюдаю. При netstat -hwd 1 вечером 104-107K пакетов и 72-80M трафика. net.inet.ip.dummynet.debug: 0 net.inet.ip.dummynet.pipe_byte_limit: 1048576 net.inet.ip.dummynet.pipe_slot_limit: 100 net.inet.ip.dummynet.io_pkt_drop: 2422386476 net.inet.ip.dummynet.io_pkt_fast: 4252339598 net.inet.ip.dummynet.io_pkt: 1426450516 net.inet.ip.dummynet.io_fast: 1 net.inet.ip.dummynet.tick_lost: 0 net.inet.ip.dummynet.tick_diff: 501370336 net.inet.ip.dummynet.tick_adjustment: 294038698 net.inet.ip.dummynet.tick_delta_sum: 227 net.inet.ip.dummynet.tick_delta: 5 net.inet.ip.dummynet.red_max_pkt_size: 1500 net.inet.ip.dummynet.red_avg_pkt_size: 512 net.inet.ip.dummynet.red_lookup_depth: 256 net.inet.ip.dummynet.max_chain_len: 16 net.inet.ip.dummynet.expire: 1 net.inet.ip.dummynet.search_steps: -255531639 net.inet.ip.dummynet.searches: 1426450315 net.inet.ip.dummynet.extract_heap: 0 net.inet.ip.dummynet.ready_heap: 848 net.inet.ip.dummynet.hash_size: 1024 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.6.Yandex[$Revision: 1.36.2.17 $] dev.em.0.%driver: em dev.em.0.%location: slot=0 function=0 dev.em.0.%pnpinfo: vendor=0x8086 device=0x105e subvendor=0x8086 subdevice=0x125e class=0x020000 dev.em.0.%parent: pci26 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_kthreads: 3 dev.em.0.max0_gprc: 4290722503 dev.em.0.max0_gptc: 4290718454 dev.em.0.max0_gorc: 4294905285 dev.em.0.max0_gotc: 4294724306 dev.em.0.max1_gprc: 4290722503 dev.em.0.max1_gptc: 4290718454 dev.em.0.max1_gorc: 4294905285 dev.em.0.max1_gotc: 4294724306 dev.em.0.max2_gprc: 4290722503 dev.em.0.max2_gptc: 4290718454 dev.em.0.max2_gorc: 4294905285 dev.em.0.max2_gotc: 4294724306 dev.em.0.max3_gprc: 4290722503 dev.em.0.max3_gptc: 4290718454 dev.em.0.max3_gorc: 4294905285 dev.em.0.max3_gotc: 4294724306 dev.em.0.max4_gprc: 4290722503 dev.em.0.max4_gptc: 4290718454 dev.em.0.max4_gorc: 4294905285 dev.em.0.max4_gotc: 4294724306 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 0 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_kthread_priority: 127 ipfw pipe list | grep buckets 00136: 3.072 Mbit/s 0 ms 50 sl. 9 queues (1024 buckets) droptail 00170: 5.120 Mbit/s 0 ms 50 sl. 32 queues (1024 buckets) droptail 00051: 2.048 Mbit/s 0 ms 50 sl. 39 queues (1024 buckets) droptail 00171: 5.120 Mbit/s 0 ms 50 sl. 2 queues (1024 buckets) droptail 00205: 3.072 Mbit/s 0 ms 50 sl. 3 queues (1024 buckets) droptail 00016: 128.000 Kbit/s 0 ms 50 sl. 14 queues (1024 buckets) droptail 00050: 9.216 Mbit/s 0 ms 50 sl. 20 queues (1024 buckets) droptail 00035: 3.072 Mbit/s 0 ms 50 sl. 276 queues (1024 buckets) droptail 00185: 10.240 Mbit/s 0 ms 50 sl. 6 queues (1024 buckets) droptail 00155: 2.048 Mbit/s 0 ms 50 sl. 56 queues (1024 buckets) droptail 00002: 20.480 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail 00116: 128.000 Kbit/s 0 ms 50 sl. 0 queues (1024 buckets) droptail 00003: 20.480 Mbit/s 0 ms 50 sl. 1 queues (1 buckets) droptail 00200: 3.072 Mbit/s 0 ms 50 sl. 2 queues (1024 buckets) droptail 00140: 1.024 Mbit/s 0 ms 50 sl. 23 queues (1024 buckets) droptail 00115: 128.000 Kbit/s 0 ms 50 sl. 1 queues (1024 buckets) droptail 00021: 256.000 Kbit/s 0 ms 50 sl. 22 queues (1024 buckets) droptail 00055: 9.216 Mbit/s 0 ms 50 sl. 15 queues (1024 buckets) droptail 00004: 5.120 Mbit/s 0 ms 50 sl. 132 queues (1024 buckets) droptail 00156: 9.216 Mbit/s 0 ms 50 sl. 2 queues (1024 buckets) droptail 00141: 5.120 Mbit/s 0 ms 50 sl. 4 queues (1024 buckets) droptail 00190: 6.144 Mbit/s 0 ms 50 sl. 4 queues (1024 buckets) droptail 00175: 5.120 Mbit/s 0 ms 50 sl. 27 queues (1024 buckets) droptail 00020: 1.536 Mbit/s 0 ms 50 sl. 931 queues (1024 buckets) droptail 00005: 5.120 Mbit/s 0 ms 50 sl. 97 queues (1024 buckets) droptail 00066: 4.096 Mbit/s 0 ms 50 sl. 3 queues (1024 buckets) droptail 00036: 512.000 Kbit/s 0 ms 50 sl. 58 queues (1024 buckets) droptail 00006: 2.048 Mbit/s 0 ms 50 sl. 209 queues (1024 buckets) droptail 00007: 2.048 Mbit/s 0 ms 50 sl. 188 queues (1024 buckets) droptail 00145: 1.024 Mbit/s 0 ms 50 sl. 20 queues (1024 buckets) droptail 00110: 128.000 Kbit/s 0 ms 50 sl. 5 queues (1024 buckets) droptail 00025: 1.536 Mbit/s 0 ms 50 sl. 508 queues (1024 buckets) droptail 00008: 256.000 Kbit/s 0 ms 50 sl. 38 queues (1024 buckets) droptail 00126: 1.536 Mbit/s 0 ms 50 sl. 10 queues (1024 buckets) droptail 00111: 128.000 Kbit/s 0 ms 50 sl. 0 queues (1024 buckets) droptail 00009: 256.000 Kbit/s 0 ms 50 sl. 34 queues (1024 buckets) droptail 00215: 8.192 Mbit/s 0 ms 50 sl. 1 queues (1024 buckets) droptail 00160: 4.096 Mbit/s 0 ms 50 sl. 12 queues (1024 buckets) droptail 00130: 512.000 Kbit/s 0 ms 50 sl. 14 queues (1024 buckets) droptail 00125: 256.000 Kbit/s 0 ms 50 sl. 8 queues (1024 buckets) droptail 00040: 5.120 Mbit/s 0 ms 50 sl. 121 queues (1024 buckets) droptail 00010: 128.000 Kbit/s 0 ms 50 sl. 74 queues (1024 buckets) droptail 00176: 5.120 Mbit/s 0 ms 50 sl. 0 queues (1024 buckets) droptail 00146: 5.120 Mbit/s 0 ms 50 sl. 3 queues (1024 buckets) droptail 00131: 3.072 Mbit/s 0 ms 50 sl. 16 queues (1024 buckets) droptail 00056: 2.048 Mbit/s 0 ms 50 sl. 38 queues (1024 buckets) droptail 00041: 1.024 Mbit/s 0 ms 50 sl. 39 queues (1024 buckets) droptail 00026: 256.000 Kbit/s 0 ms 50 sl. 20 queues (1024 buckets) droptail 00011: 128.000 Kbit/s 0 ms 50 sl. 15 queues (1024 buckets) droptail 00046: 1.024 Mbit/s 0 ms 50 sl. 36 queues (1024 buckets) droptail 00061: 4.096 Mbit/s 0 ms 50 sl. 4 queues (1024 buckets) droptail 00151: 9.216 Mbit/s 0 ms 50 sl. 2 queues (1024 buckets) droptail 00121: 1.536 Mbit/s 0 ms 50 sl. 10 queues (1024 buckets) droptail 00031: 512.000 Kbit/s 0 ms 50 sl. 59 queues (1024 buckets) droptail 00210: 8.192 Mbit/s 0 ms 50 sl. 1 queues (1024 buckets) droptail 00195: 6.144 Mbit/s 0 ms 50 sl. 4 queues (1024 buckets) droptail 00180: 10.240 Mbit/s 0 ms 50 sl. 7 queues (1024 buckets) droptail 00165: 4.096 Mbit/s 0 ms 50 sl. 12 queues (1024 buckets) droptail 00150: 2.048 Mbit/s 0 ms 50 sl. 57 queues (1024 buckets) droptail 00135: 512.000 Kbit/s 0 ms 50 sl. 10 queues (1024 buckets) droptail 00120: 256.000 Kbit/s 0 ms 50 sl. 12 queues (1024 buckets) droptail 00045: 5.120 Mbit/s 0 ms 50 sl. 94 queues (1024 buckets) droptail 00030: 3.072 Mbit/s 0 ms 50 sl. 328 queues (1024 buckets) droptail 00015: 128.000 Kbit/s 0 ms 50 sl. 70 queues (1024 buckets) droptail Вроде бы хомячки не возмущаются. Поэтому делаю вывод, что скорости даются. Тем более, что сам проверяю вечерами. Но вчера столкнулся с одним абонентом в сети, который сидит на высоком тарифе и у него 50-60% тока было скорости почему то. Начали проверять при заявленных 10 Мбитах выкачивало до 590кбайт/сек. Поставил себе такой тариф, вроде бы качало 1,2Мбайт/сек. Перегрузок в сети нет. Сошлись пока что на то, что торрент такой. Вообщем незнаю, мазолит этот dummynet со своими 90-100% и незнаю что ещё можно подкрутить. Вообщем посоветуйте пожалуйста. Спасибо. P.S. Включил сегодня net.inet.ip.dummynet.debug: 1 посмотрим что будет в логах писать. Показатели выложил утренние когда загрузка 57K пакетов и 41M трафика. Попробую выложить вечерние показатели. P.S. Вот сейчас сделал cpuset -l 0 -p 75 и dummynet упал в 0. Посмотрим в течении дня как он будет себя вести.

Народ, кто нибудь смог прикрепить policy на Virtual-Template1 на циске asr1002. У меня раньше на 7301 работала такая конструкция interface Virtual-Template1 ...... ip policy route-map gate ..... route-map gate permit 10 match ip address gate set ip next-hop 172.16.0.1 P.S. Я смотрю стали следующие команды не доступны на этой циске (asr1002) ntp update-calendar pppoe-forwarding ip cef virtual-template 1 pre-clone 600 Спасибо.

Добрый день. Обращаюсь к знатокам Нортела)) Заметили недавно такую фичу. Имеется сеть Коммутаторы (штук 10) - циска 3550 - месу (кольцо, в кольце 6 месу) - паспорт - месу (кольцо, в кольце 2 месу) - коммутаторы (штук 5) Когда я начинаю посылать с помощью циски пакеты размером 1500 байт (ICMP) в сети до Месу, то пакеты не теряются, из 5000 пролетают все. Но как тока я начинаю отправлять эти пинги через кольца месу, чтобы они дошли до клиента в другом кольце, из 5000 начинает вылетать пакетов 100 (может больше или меньше). Первое что пришло на ум, есть какой то полисер на паспорте или на месу. Потому что когда я начинаю отправлять пакеты (ICMP) размером меньше 1000 байт, то все 5000 пакетов пролетают) Хотя наша поддержка Нортела говорит, что никаких полисеров на пасспорте не могжет быть, что я глубоко ошибаюсь. Сами же пакеты не могут ведь пропадать. У нас бы потоки e1 колебались бы)) Дело в том что это настораживает новых клиентов, типа если так пинги не проходят, то и с данными может быть та же беда. Хотя сколько пользуются сейчас абонентов нашей сети, никто не предъявлял претензий. Помогите, пожалуйста, разобраться))

Приветствую всех. Может как то неправильно обозвал тему. Хотел бы получить советы если можно по такой штуке. Есть шлюз, который раздает инет. Как только с него начинаешь пользоваться интернетом, нужно чтобы тебя переносило на обычную html страницу с правилами. И там допустим будет кнопка - "согласиться с правилами", после нажатия которой можно было бы зайти в интернет. С помощью чего можно сделать такую штуку, посоветуйте пожалуйста. P.S. И да кстати если юзер на своей железке сделает себе нат, хотелось бы то же, чтобы конечным юзерам всем страница эта выводилась всегда при заходе в интернет. Спасибо. Надеюсь что доступно написал

Хм, хорошо, за это спасибо)) Но дело в том, что все комки у меня работают по радиусу. Тобишь после эмулирования клавиши Y, нотел требует ввод логина и пароля. Хотелось бы обойтись без ввода))) Некоторые комки вообще не имеют менюшек, сразу появляется командная строка. P.S. Вообщем хотелось бы разработать универсальный способ))

Вот и я так же считаю) Может кто поможет как это можно организовать. Где то слышал, что можно создать на комке параметр на snmp, при котором когда к нему обращаешься, комок начинает выполнять действия, соответствующие этому параметру. Ток вот незнаю как это можно реализовать.

Я захожу на них по telnet, поднят радиус. Можно и по телнету можно было бы сделать. Но при заходе на телнет у нортела есть своё меню, получается, что команды так просто не введешь))