Перейти к содержимому
Калькуляторы

rdc

VIP
 Просмотреть профиль  Активность

  • Публикации

    3021

  • Зарегистрирован

  • Посещение

 Тип публикации 

Сообщения, опубликованные пользователем rdc

  1. Опубликовано · Жалоба на ответ

    При включённом WPA невозможна WDS-ретрансляция. WPA работает только на p2p мостах.

    WPA шифрует пакет целиком, вместе с заголовком, и ретранслятору недоступны mac-адреса.

    WPA и WPA2 в этом контексте идентичны - они отличаются лишь алгоритмом шифрования.

     

    Эксгумировать труп WEP нет смысла, это неудобный аналог открытой сети.

  3. Опубликовано · Жалоба на ответ

    люди освоили торент и понеслось кол-во покетов от торента сумашедшее
    Есть две меры, которые здесь можно предпринять.

     

    Во-первых - надо полностью вырезать протокол µTP. Это исчадие работает на коротких пакетах. Торренты начнут литься по tcp, packet rate сразу многократно упадёт, а юзеры не заметят разницы.

    Возможно, это уже решит проблему.

     

    Во-вторых - если вырезание µTP не решит проблему, следующим шагом будет внедрение QoS.

    Не-торрентный трафик нужно сделать приоритетным. В этом случае всё уже точно нормализуется.

    Однако, первый пункт это не отменяет.

  8. Опубликовано · Изменено пользователем rdc · Жалоба на ответ

    Появился такой вопрос. Мы не используем в своей сети мультикаст в явном виде (для IPTV там или еще чего). Нужен ли на свичах доступа IGMP снупинг?
    Не нужен, конечно же.
    если только вы не хотите улучшить работу хомяковых мультикаст протоколов с igmp. (улучшить их распространение в сети)
    Не понял, а зачем вообще распространять мультикаст от юзера? Это же паразитный трафик!

     

    Делаем что-то типа (пример для D-Link):

    config traffic control 1-24 broadcast enable multicast enable threshold 5

    и всё, мусорный трафик от клиента никому не помешает.

    При этом работа ipv6 ndp (это единственное, ради чего нужен мультикаст "от юзера") не нарушается.

  9. Опубликовано · Жалоба на ответ

    Один клиент зафлудит, второй, третий - вот вся скорость на базе и закончилась.
    Кто мешает погасить им езернеты?
    Это уже от местоположения зависит. В многоэтажках сейчас делать нечего,
    Про проблемы пппое и неуправляемой сети - речь шла именно про многоэтажки.

    Насчёт "делать нечего" - странное утверждение. Я делаю. И абонентская база только растёт.

    Если будет не хватать производительности PC-роутера
    При поставленной задаче его не может не хватать.

    PC-роутер спокойно натит-шейпит несколько гигабит. Такой канал затянуть в посёлок по воздуху просто невозможно. Соответственно, пока нет наземного канала, PC-роутера хватит по определению.

    У таких продуктов есть недостаток - отсутствие сертификата. Будет какая-то проблема с недосдачей трафика или списания средств, сразу вспомнят про сертификат.
    Это имело значение только тогда, когда считались байтики. Впрочем, как показала практика многих лет предоставления тарифов "с учётом байтиков", это никак не помешало.

    Сейчас, когда байтики давно никто не биллингует, это не имеет никакого значения.

    Поэтому только своими руками, только харддкор! :)
    Разумеется. А если настраиваешь не сам, а ставишь чьё-то решение под ключ - обязательно потребуй обучить тебя в достаточной степени, чтобы всё работало без установщика.
    Ну то есть где-то в сети должен стоять управляемый свитч и что-то делать.
    Моя фраза про управляемый свич касалась сети в многоквартирном доме.
    А почему на клиентах нанобриджи? Чем это обусловлено?
    У нанобриджа направленная антенна. Он меньше ловит помех из эфира, и его самого база "слышит" гораздо лучше.

    Основная идея - выдержать ёмкость сети на 100%, чтобы у всех клиентов скорость была 300/300.

    Клиента, живущего напротив БС, можно повесить и на Loco M5, но вот живущего в нескольких километрах уже однозначно надо сажать на нанобридж.

    Вообще это экспериментально выявляется.

    я буду зависеть только от вас - автора биллинга и специалиста на рынке найти не смогу "в случае чего"?
    См.выше про обучение =)

    Написал в ЛС.

  10. Опубликовано · Жалоба на ответ

    Только если клиент будет слать флуд = скорости порта,
    На убике прописан защитный шейп. Полоса упрётся в этот шейп, выше не прыгнет.
    Только идет всем клиентам сразу. Вот скачивает он фильм на скорости 2 мегабита в секунду и раз у него связь оборвалась, куда трафик к нему отправленный пойдет? Правильно, всем клиентам, подключенным к той же базе. У них растут пинги и сами отваливаются.
    Эта проблема будет безотносительно метода доступа.

    На пппое ровно так же - пока не кончится lcp echo timeout, поток точно так же будет разливаться на всех клиентов БС.

    Но особых проблем это не доставляет - tcp, по которому он качает фильм, заткнётся гораздо раньше.

    Однако все же остается нужным прописывать цепочку вланов на коммутаторах?
    Нет. QinQ решает.
    Для сравнения - в сети, созданной в прошлом веке, постоянно бегают сотрудники и меняют свичи на управляемые, т.к. постоянно то тут то там криворукие клиенты создают проблемы своим соседям на неуправляемых свичах.
    Никогда с таким не сталкивался.
    А я в последние годы сталкиваюсь постоянно.

    Причём, в подавляющем большинстве случаев клиенты это делают не со зла.

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

    Ещё один прикол - клиент подсоединяет двух провайдеров "для надёжности". Когда у второго провайдера тоже пппое, юзеры этого дома, у которых по какой-то причине не указан service name, начинают рандомно присоединяться то туда, то сюда.

    И ещё один прикол - когда в этом доме находится ещё один такой же умник, а у второго провайдера тоже неуправляемый свич, штормом выносит всех =)

    Очевидно, что после замены свича на управляемый, всё это безобразие резко прекращается.

    Если понадобится провести обслуживание, как быть? И как создать резерв на случай проблем,
    Второй тазик, очевидно.
    или если производительности железа станет не хватать?
    Если станет не хватать производительности PC-роутера, то никакими роутербордами тут уже точно не будет пахнуть :D
    Как выглядит подключение клиента к радиосети (вариант 1):

    - залили типовой конфиг на устройство и положили на склад,

    Лишнее действие. В моём случае берётся устройство из коробки. Можно вообще купить его в магазине и прямо из магазина поехать на объект.

    Или снять со съехавшего клиента, сбросить кнопкой и подключать нового, как часто бывает.

    Единственная беда - съехавшие клиенты любят тырить с собой пое-инжекторы, недавно мы закупили ящик запасных =)

     

     

    Раскажите о своём решении попобробнее, какой биллинг используете и как у вас организована сеть, с какими настройками.
    Объектов, подключённых по радио, у меня много.

    Типичное решение выглядит так - Nanostation M5 в качестве секторов БС, и клиентские устройства Nanobridge M5. Но вообще есть вариации в зависимости от специфики объекта.

    Биллинг собственный, эксплуатируется лет десять, периодически дорабатывается под новые задачи и технологии.

    Что конкретно интересует по настройкам?

    Вообще см.личку =)

     

    Чтобы платежи можно было вносить

    Да это-то всё типовое. Только приём денег имеет ряд, кхм, юридических тонкостей.

     

    И ещё есть некоторые моменты.

    Например: абоненты любят звонить. По любой проблеме, причём проблемы будут в 95% со стороны абонента, но абонент-то знает, по чьей вине у него не работает интернет!

    Рекомендую сразу обзавестись отдельным номером для приёма звонков. Ни в коем случае никогда нельзя давать абонентам личный номер.

    Проще всего взять какую-нибудь "умную переадресацию", коих в инете полно - например, от МТТ. Впоследствии, если дело пойдёт и бизнес будет расширяться, это будет очень удобно - ибо номер поддержки в мозгах клиентов не перепрошивается, они будут звонить по первому известному им номеру даже спустя десяток лет.

  11. Опубликовано · Жалоба на ответ

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

    А от флуда со стороны клиента в любом случае стоит защитный шейп на клиентском убике.

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

    1. Ввод IP адресов вручную на клиентских точках или их роутерах - в случае расширения каналов, переезда и т.п. приходится все перенастраивать, если клиенты выключили свое оборудование, то либо выпадают из работы, либо нужно ждать их включения.

    И этой проблемы тоже нет. Адреса выданы через влан. Влан клиента при переезде в пределах населённого пункта остаётся неизменным - адреса тоже.

    2. Выдача адресов автоматически не защищает от установки адресов вручную.

    И тут нет никакой проблемы. Адресация-то статическая. Пусть ставят вручную.

    Соседям помешать не смогут, разные вланы же.

    3. Выдача белых адресов сопряжена с большими трудностями, если требуется их экономить.

    Опять же нет никакой проблемы. Unnumbered решает.

    У PPPoE несомненный плюс - все IP хранятся на сервере и их удобно менять, легко выдавать белые адреса, не требуется управляемое оборудование на сети.

    Я прекрасно представляю, как работает пппое - в числе прочих эксплуатирую сеть, созданную ещё в прошлом веке =)

    Но и её сейчас буду переводить на vlan per customer.

    Посмотрите на работу операторов, у которых адреса автоматом - сидит куча админов и прописывают вланы и т.п., всегда в работе.

    Этой проблемы тоже нет. Всё автоматизировано.

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

    Биллинг запускается на компе, а для авторизации на первое время RB2011LS

    Авторизация - лишнее звено. RB2011LS - тоже лишнее звено.

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

    Это само собой разумеется. И этому никак не мешает биллинг и роутер в одном флаконе.
    Появляется другой советчик и лоббирует свою устаревшую технологию
    Вот-вот. Не надо тут своё устаревшее пппое лоббировать. С прописыванием логинов, паролей и прочих лишних сущностей. А также с созданием дополнительных точек отказа типа радиуса.

     

    Как у меня выглядит подключение клиента на радиосети:

    - подключаем свежекупленный или сброшенный убик к выделенному под эту задачу порту.

    - в админке биллинга, в учётке клиента жмём кнопку "подготовка оборудования" и ждём сообщения "готово".

    - устанавливаем убик клиенту.

     

    Как у меня выглядит подключение клиента на проводной сети:

    - к клиенту дотягивается кабель (без разницы, медь или оптика)

    - монтажник присоединяет к кабелю говноут и активирует учётку клиента через вебморду.

     

    В любом случае, пппое уже давно мертво, неуправляемые сети - не более чем наследие минувших веков.

    Современный доступ делается по vlan per customer, все операторы рано или поздно перейдут на vlan per customer.

    Ну а кто хочет сидеть на устаревших технологиях, где mtu менее 1500, где абонент ограничен одним ip-адресом и т.д. - сам себе злобный буратина…

  12. Опубликовано · Жалоба на ответ

    выставить MCS13 - это я понял, жестко поставить. А вот как снизить?
    При включённой галке Automatic - получается максимальное значение скорости (может быть меньше. но не больше)

    При выключенной галке Automatic - фиксированная скорость (меньше быть не может, при ухудшении сигнала просто потеряется связь)

  15. Опубликовано · Жалоба на ответ

    То есть каналы с 15 задействовать для своих бс и клиентов и не бояться домашних роутеров? Или я что-то не правильно придумал?
    "Каналы" - это бытовое-вайфайное понятие, рекомендую про него более не вспоминать.

    А оперируя понятием частот - бытовой вайфай сидит в диапазоне 2.4, в 2.5 и выше сидит мегайота, посему хорошей идеей будет использование 2.3.

     

    Просто я тут подумал - получается вся затея с М5 и М6 как стрельба из пушки по воробьям.
    Затея с М6 - да. А вот M5 и M2 стоят примерно одинаково.

    Плюс M5 - огромный чистый диапазон 4.9-6.2, никому не помешаешь, и тебе никто не помешает.

     

    Надо будет предусмотреть возможность при подключении продавать/предоставлять простенький роутер для клиентов. Какой-нибудь ASUS WL520-GC
    Также рекомендую забыть про клиентские 802.11g устройства. Только 802.11n.

     

    То есть без опыта по мануалам RADIUS-сервер нормально не запустить?
    Радиус, логины и пароли в такой сети не нужны, здесь это лишние сущности.

     

    О настройке.

    Все устройства Ubiquiti умеют терминировать вланы. Каждому клиенту выделяется отдельный влан.

    Сеть на Ubuquiti при этом вообще не занимается маршрутизацией - она является просто транспортом, аналогом управляемого свича с вланами.

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

    При желании, можно даже поднять медиапомойку, и сделать приоритезацию трафика, чтобы закачки с неё занимали свободную полосу канала, никак не мешая интернету.

     

    Микротику в этой задаче не вижу места - без писюка всё равно не обойтись, биллинг на микротике не запустишь.

    А раз уж есть писюк - то с таким небольшим трафиком играючи справится даже бюджетный Core i3.

  17. Опубликовано · Жалоба на ответ

    Трубки выкидывать не надо. Шлюз решает.

    По моему опыту - использую исключительно SIP, при этом 95% абонентов пользуются обычными аналоговыми трубками и даже не подозревают, что их телефонные розетки в действительности идут на SIP-шлюз.

  22. Опубликовано · Жалоба на ответ

    Пока стандартный диапазон свободен, почему бы в нем не работать, тем более что есть возможность навести порядок в нем.
    Да потому что такой возможности просто нет!

    Полагаться на юзеров - это выглядит предельно странно. Учитывая то, что в технике они некомпетентны.

    Приехал внук к бабушке, привёз с собой другой вайфай и всё…

     

    Сейчас там порядок, а через полгода начнется веселуха. И придется менять все оборудование.
    Не придётся.

    M2 работают в диапазоне 2300-2700, а бытовой вайфай занимает от него только 20% - 2400-2480.

     

    вопрос с деревьями - в паре мест есть довольно раскидистые тополя - это для меня сильная проблема
    Да.
    Меня смущает что у линейки м2 (и в этом диапазоне) нет фишек айрмакса (или есть и я уже путаюсь от большого потока информации за последние 3 дня - есть ли там MIMO и прочее?).
    Всё есть. И airMax, и MIMO. Разница только в частоте.

  24. Опубликовано · Жалоба на ответ

    Ну а в GSM что делают в таком случае?
    В GSM мощность излучения падает пропорционально квадрату расстояния, что затрудняет возможность нарушить связь на большой площади "малой кровью". Китайские gsm jammer'ы глушат только в пределах жилища. Мощный узкополосный передатчик, реально способный помешать связи, стоит значительных денег. И есть возможность пеленгации, не прерывая сервис.

     

    В случае же PON можно положить весь посёлок копеечным устройством, а пеленгация без перерывов сервиса невозможна.

     

    Худший сценарий - эпизодическое включение "глушилки".

    В случае GSM засада с пеленгатором всё равно решит проблему.

    В случае PON нужно ещё застать гада.

     

    Возможно, я сгущаю краски, но опыт всегда подталкивает к тому, чтобы исходить из негативного сценария =)

    На неуправляемой медной Ethernet-сети я такого уже наелся…

  25. Опубликовано · Жалоба на ответ

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