troyand

если не садить клиента в отдельный VLAN, подвержено spoofing-атакам (так же, как и Hotspot), инструкции прилагаются.

Я не про сдачу в органы (как раз на Ubiquiti, в отличие от MikroTik, есть сертификаты), а про сдачу своим коллегам, которым с этим счастьем жить потом.

А так, то, конечно, подпилить можно, но только не совсем понятно, как такое сдавать в эксплуатацию: подобная схема слишком подвержена "эффекту грузовика".

С этим прояснилось. Wi-Fi CPE с management vlan - это, пожалуй, из распространенного только MikroTik, а как быть с клиентскими Nanostation?

Логика всё равно не до конца ясна: макс. означает, что если в линейке тарифов самый дорогой имеет ограничение в, например, 5 МБит/с, то на всех CPE при инсталляции прописывается лимит в 5 МБит/с, и эта цифра будет корректной для любого тарифа? И второй вопрос состоял в следующем: может ли пара умников зайти на свою CPE и отключить у себя ограничение полосы (на рейт-лимит PPPoE-соединения это не повлияет никак, естественно), получив себе "безлимитную локалку"?

А если клиент меняет тариф, какая процедура обновления параметров на CPE (особенно если учесть, что клиент может не работать в данный момент)? И что будет, если пользователь снимет со своей CPE ограничения (или у клиентов нет доступа на CPE)?

А в контексте точек доступа - еще и создаст массу новых. Часто ли вы видели КПК/планшеты/коммуникаторы/консоли/etc с PPPoE клиентом? :) Такой способ аутентификации даже китайцам, которые специалисты рвать гланды через анус, в голову еще не приходил... Тут вроде бы говорили о 5 ГГц, по-этому модель CPE в любом случае форсируется провайдером, в Nanostation с PPPoE на WLAN есть некоторые нюансы, но в целом схема работает. Из того, что не нравится: При отбое от RADIUS NS M5 практически без задержки отсылает следующий запрос на поднятие PPPoE-сессии: в начале месяца RADIUS зафлуживается логами, проблему можно лечить чем-то вроде sessions per-mac throttle Нельзя форсировать MS-CHAPv2, если клиент зацепится на левую станцию, с него можно выцепить пароль по PAP

Многие Wi-Fi базовые станции (например, тот же Rocket) не умеют делать per-user нарезку скорости (по RADIUS-атрибуту), а это часто надо.

Netinstall В моем случае роутер перешивался, но после перезагрузки всё равно входил в ступор.

Все-таки есть подозрение, что на 750 производители где-то сэкономили, иначе откуда там взялась весьма интересная цена. На конденсаторы немало жалоб на форуме Микротика (в основном 750 и 450): http://forum.mikrotik.com/search.php?keywords=capacitor&terms=all&author=&sc=1&sf=all&sk=t&sd=d&sr=posts&st=0&ch=300&t=0&submit=Search

Если ехать далеко, то, может, стоит. Но, похоже, у 750 есть разные ревизии, и более ранние имеют подобную проблему, сейчас, может, пофиксили, надо разбираться.

Было такое, поменяли по гарантии. Похоже, проблема с конденсаторами фикс - перепаять конденсаторы: http://forum.mikrotik.com/viewtopic.php?f=3&t=45610 симптомы: http://forum.mikrotik.com/viewtopic.php?f=3&t=51086 http://forum.mikrotik.com/viewtopic.php?f=3&t=44581

Странные вещи тут звучат. В сетях все приставки Кило, Мега, Гига и т п всегда были нормальными, то есть Сишными. Никто не вспомнил, что в Ethernet есть такие вещи, как interframe gap (12 Bytes), преамбула (8 Bytes), которые не учитываются в счетчиках оборудования почти никогда (разве что в Ethernet-тестерах типа Sunraise, так как там можно видеть Line Rate и Data Rate), помимо этого есть еще trailer (4 Bytes), который тоже нечасто учитывают (во всяком случае на Cisco при нарезке трафика по rate-limit trailer, если память не изменяет, не учитывается). Озвученные вещи не проявляются на SNMP счетчиках, но они съедают полосу. Но ситуация может оказаться еще более плачевной: некоторое оборудование считает трафик как размер Ethernet-payload, или чего хуже IP-payload, или ещё страшнее IPv6-payload. Тогда на каждом фрейме мы будем терять еще 18 или 22 байта (в зависимости от использования dot1q) в первом случае плюс еще 20 или 40 байт для второго и третьего случаев соответственно. И чем выше PPS, тем большие накладные расходы. За дополнительными расчетами можно обратиться к http://sd.wareonearth.com/~phil/net/overhead/ Цифры, которые были получены на гигабитном порту 3750: 64-Byte frame Switch#sh int gigabitEthernet 1/0/2 | i rate 30 second input rate 776691000 bits/sec, 1427721 packets/sec 30 second output rate 776693000 bits/sec, 1427726 packets/sec 700-Byte frame Switch#sh int gigabitEthernet 1/0/2 | i rate 30 second input rate 977280000 bits/sec, 173525 packets/sec 30 second output rate 977284000 bits/sec, 173526 packets/sec 1518-Byte frame Switch#sh int gigabitEthernet 1/0/2 | i rate 30 second input rate 989741000 bits/sec, 81626 packets/sec 30 second output rate 989701000 bits/sec, 81623 packets/sec

Не много ли Вы хотите от такой маленькой бюджетной железки? Это я и пытаюсь выяснить. Просто хочется уйти от PPPoE, но оставаться с дурным бриджем желания нет особого.

Вопрос из той же оперы: может ли нанос делать per-user rate-limit по полученному атрибуту из RADIUS-сервера (à la lcp:interface-config=rate-limit input 64000 8000 8000 conform-action transmit exceed-action drop)?

free-vs-enterpriseЯ сомневаюсь, что у вас набегает более, чем полгига текста логов в день. Складывание логов в SQL-базу, как показывает моя практика, - довольно ущербная идея, уж лучше anyterm + grep.

splunk

Wiremaps + pygraphviz (правда по cdp, но идеологически это менять абсолютно ничего не должно).

Идея в том, что надо задавать вопрос не что за зверь SNR-R7204, а искать того кто щупал хоть какой-то IXP2400, так как в общем внутренности у SNR-R7204 сравнительно аскетичны. Иначе, возможно, овчинка на сегодня не стоит выделки, и обычный писюковый проц будет повыгоднее спецплатформ.

В статье NAT, который мы потеряли, вскользь упоминается данный маршрутизатор.

Там XR, она же QNX.

Managing Cisco programatically; Telnet vs SNMP? То есть, если для вытягивания информации из железа програмным способом SNMP подойдет практически в любом случае, то для конфигурирувания его не всегда достаточно, и приходится делать велосипеды с Telnet/Expect и аналогами. Однако последний вариант может таить за собой немало подводных камней: так я сравнительно долго вылавливал баг в expect'овом скрипте: при конфигурирувании вводилась строка со знаком "#", этот же символ ловился как признак введеной строки. Также часто может действовать правило: "Если у вас есть проблема, и вы решаете ее с помощью регекспов, то у вас появляется вторая проблема". Единственное, что могу посоветовать, это писать высокоуровневый код с помощью соответсвующих SNMP-библиотек. Так, для Python, мне больше всего импонирует snimpy, уверен для других языков есть аналоги.

Тут labi все обсасывает эту тему постоянно.

Вроде бы, уже прикрутили на все, даже на пасочки: http://www.cisco.com/en/US/docs/security/a....html#wp1117013 Правда, оно немного странноватое и v9. А по структуре статьи, в выводах не выводы, а разрыв пера академического письма.

А если на свиче включить rate limit, и пониже, то пропускная способность порта волшебным образом может превысить 400% на UDP! rate limit не было, не было и 400%, но почти 101% был