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

rdc

VIP
  • Публикации

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

  • Посещение

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


  1. При помощи Nanostation M2 в качестве базовых станций, ибо денег на оборудование немного, так что для клиентов не нужно будет закупать даже наностейшн локо
    Для клиентов в ЛЮБОМ случае нужно ставить приёмные точки.

     

    Приём "с ноутбуков", если речь шла про него, невозможен по трём причинам:

    - у них галимые антенны

    - мешают стены

    - клиенты не слышат друг друга, а протокол предотвращения коллизий не поддерживают

    - клиенты будут тырить интернет друг у друга.

     

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

    Соответственно - нужно высунуть на мачте, и у клиентов располагать на крышах.

    Важно понимать, что дерево или окно по дороге даже до одного абонента ухудшает связь ВСЕМ на этом секторе, поскольку передача данному абоненту той же полосы занимает многократно бОльшую долю канала, нежели без препятствий.

     

    Вариант по оборудованию:

    В центре несколько Nanostation M5 - это готовые сектора 15x40º.

    Клиентам - Nanostation Loco M5.

     

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

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

     

    И с приёмом платежей не всё так просто.

  2. теоретически - да, на практике же я ни разу не слышал о таком.
    Любопытно, что будут делать пострадавшие, когда это случится практически. Ведь выявить хулигана, не размыкая сеть, по сути нереально.
  3. Интересует опыт распространения информации о vlan`ах на большое кол-во коммутаторов.
    Варианты:

     

    1) включить vlan_trunk на нужные порты.

    по сути это автоматически создаёт 4095 статических вланов с tagged на этих портах.

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

     

    2) использовать QinQ на агрегации.

    вланы доступа при этом будут свёрнуты в один жирный влан.

     

    3) комбинация этих двух вариантов.

    например - на доступе стоят три 3200 друг за дружкой, на них включён vlan_trunk, и вланы этого объекта распространяются между ними.

    на агрегации стоит 3612G, эти 3200 смотрят на его порт в режиме QinQ UNI, и все вланы сворачиваются в указанный на 3612G влан.

  4. Пишется скрипт который пробрасывает влан до каждого клиента
    Кстати, есть более простое решение.

    На агрегации QinQ - соответственно, влан нужен только на самом доступе.

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

    Результат - никакое управление свичами не требуется вовсе.

  5. Интересно как вы "порт" прописали в договор :) Покажите ваше определение "порта".
    А что ему там делать? В договоре указана точка разграничения ответственности - кабель на входе в помещение абонента.
  6. Пример - у абонентов совпали маки.
    Билинг не пропустит.
    Речь про привязку маков?

    Если да - то такого провайдера надо расстреливать через повешение.

    Первое - вы учет трафика в сети IPoE, по каким критериям будете осуществлять, если не по IP-адресу?
    По порту. Снимаю счётчики по snmp.

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

     

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

    На старой пппое сети я с этим сталивался неоднократно, причём причины были в основном две:

    1) абонент сделал mac clone на роутере, а потом роутер после апгрейда был подарен соседям;

    2) несколько абонентов залили какую-то альтернативную прошивку, игнорирующую mac роутера и ставящую некий дефолтный.

    Сейчас, используя dhcp и vlan per customer, я не обращаю внимания на подобные проблемы.

    а посмотреть маки соседей абонент не сможет.
    При использовании wifi точки доступа (роутера в режиме моста) соседские маки видны в эфире.
  7. А в чем палево, если у меня мощность стоит до 50 мВт?

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

    А если в пределах - пока ты совсем не положишь кому-нибудь вайфай, всем на это плевать. Мощность можно задирать спокойно.

    Частота бытового wi-fi это сколько?
    У нас в России - 2400—2483,5 МГц

    В настройках ubnt это 2412—2472, если используется 20 МГц полоса, и 2422—2462, если используется 40 МГц полоса.

    И 40 мГц все говорят что не устойчиво
    Врут. При наличии прямой видимости всё это пофигу.

    Уменьшение частотной полосы может потребоваться лишь в специфических случаях - когда перекрыта часть зоны Френеля, когда по пути луча есть провода или ветки деревьев, когда устройств много и плотно занят эфир, и т.д.

    Но всё это - явно не тот случай.

  8. я думаю здесь лучше пара NanoStation Loco M2 справится
    Нифига. Диапазон 2.4 сильно загажен, они мого левого наловят. Nanobridge M5 же и лишнего не наловит, и сам никому не помешает - и луч более узкий, и диапазон 5.
  9. между двумя домами в селе в не очень прямой видимости
    Насколько "не очень прямая" видимость?

    Если прямую видимость всё-таки можно обеспечить, лучшее решение "из коробки" - пара Nanobridge M5.

  10. и поставить их по 3 штуки для охвата 360 градусов
    Лучше четыре сектора по 90 градусов.

    Во-первых, ёмкость сети на треть больше.

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

     

    А ещё есть бюджетное решение - "батарея" из десятка Nanostation M5.

    Они представляют собой секторы на 40 градусов.

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

    И, как подметили выше, можно начинать с постепенного монтажа базы.

     

    можно начать вообще с пары Ubiquiti NanoStation M2
    Только M5.

    M2 словит помехи от бытовых вайфаев, мегайоты и прочих, там всё загажено. А если ещё и будете мешать "гадам" - то вдобавок ждите гостей.

    А клиенту обязательно надо ставить нанобридж - цена та же, а антенна лучше.

     

     

    p.s. но всё же, потом тащите оптику. радио хорошо мгновенным разворачиванием, но вечно на нём сидеть не получится: интернет всё жирнее и жирнее, а помех в эфире всё больше и больше.

  11. По географии баз, мощностям, частотам надо обращаться во ФГУП "Главный радиочастотный центр"

    они сами дадут образцы документов

     

    Сдача сети уже обычным порядом в связьнадзоре.

  12. Поставьте частоту бытового вайфая (чтобы не палиться) и вжарьте мощность по максимуму. Скорее всего, разгонится до 300/300.

    Далее снижайте мощность, пока скорость не начнёт падать.

  13. rdc вы VLANы на чем терминируете?
    Штатными средствами Nanostation начиная с версии 5.3

    До версии 5.3 делали это наколенным скриптом.

    И как девайсы авторизуете?
    Номером влана, очевидно :D
  14. planet gsw-2416sf к примеру при вклюении порта на 100 мбит не пропускают пинги более 20-30к; на гигабите - при пингах по линку с нагрузкой в несколько сот мбит пакетами по 50к
    Вообще-то у свичей jumbo frame 10-15 килобайт максимум.

    На сотке jumbo frame и вовсе нестандартно, и в общем случае не стоит рассчитывать более чем на типичные 1472 байта.

  15. Задержки будут измеряться сотнями миллисекунд, а это уже много для IPTV.
    Если на приёмной стороне сделать большой буфер, сглаживающий джиттер, то это уже не имеет значения. Можно хоть на минуту задерживать.

    Заметят это разве что в новый год, когда куранты опоздают :D

  16. Изоляция портов сделает ровным счетом то-же самое, только "щелчком двух пальцев".
    Нет, не то же самое.

    При изоляции портов всё равно можно огрести массу проблем.

    Пример - у абонентов совпали маки.

    Другой пример - абонент поставил себе ip-адрес соседа.

    Друг друга не видят, а проблемы всё равно есть.

    В случае же vlan per customer у абонента нет никакой возможности напакостить соседям. Ни сознательно, ни сдуру.

     

    Тут больше организационный аопрос - ip-адреса прописаны у абонентов в договорах
    Ооооооочень плохая практика.

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

    Адрес в договоре (кстати, а зачем он там?) может быть только в одном случае - если абонент в явном виде запросил фиксированный адрес. В том случае, если это платная услуга, ею пользуется менее 10% абонентов.

    А ренамберинг может приспичить в любой момент…

  17. В сети почитал что есть Asterisk очень классная вещь, из обычной двух ядерки делает нормальную телефонную станцию,
    Для небольшого офиса даже "двух ядерка" не нужна, хватит даже роутера с openwrt.

     

    Сертификатов нет, использовать для оказания услуг нельзя.
    Да чушь это всё.

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

  18. Вланы используют в проводных сетях, пихать их в беспроводку не правильно.

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

    - если клиенту подан телефон - нет nat, который для voip явно лишний.

    - я гибко управляю адресацией - большинству клиентов подаю серые v4 подсети + dhcp, а отдельным клиентам выдаю 1-2-3…N внешних v4 адресов по их запросу, причём и серые, и внешние работают одновременно.

    - без проблем работает ipv6, его поддержка от CPE вообще не требуется.

    - отдельным клиентам даются арендованные каналы - например, для банкоматов.

    В общем, сплошные плюсы, при отсутствии минусов.

    Если вы будете подключать всех на вланы - то замучаетесь все перенастраивать и отслеживать, если одна база отключится, то придется опять перенастраивать вланы на оставшихся, для обеспечения временной работы клиентов.
    Этой проблемы нет. В пределах объекта вланы общие.
    Если влан на клиента, то нужно как-то управлять и CPE, тут либо отдельный влан для управления,
    Помимо отдельного влана, у ubnt есть ещё два варианта - управление по самому вайфаю (untagged) либо в клиентском влане.
    Сетью на PPPoE и OSPF может один человек рулить без проблем, все проблемы сразу видны, никаких коллизий маков, глюков с ARP, флудящих коммутаторов.
    Опять ужасы рассказываете.

    Коллизий маков (то бишь два клиента с одним маком) во vlan per customer не может быть, поскольку в каждом влане маки свои и совпадение маков клиентов ни на что не повлияет.

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

    Флуд, инициированный клиентом, срезается защитным шейпом на CPE. Без этого никак - иначе любую беспроводку можно свалить флудом.

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

    Повторюсь - я успешно эксплуатирую радиосети, самый крупный объект - 12 баз, везде vlan per customer.

     

    а по делу если это коттеджный посёлок с людьми с деньгами то стройте PON

    Тогда уж лучше строить волокно до абонента.

    Меньше гемора с децибелами, бюджетами, затуханиями…

    и абонентское устройство, то бишь конвертер, стоит менее 1тыр.

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

    А ресурсы без медиаконтента в сотку не упираются.

     

    Легальные исключения (типа трансляций видео из игр) очень редки, всё-таки обычно это делается через облака.

    DVD есть в ноутбуке.
    Зачем таскать с собой лишнюю тяжесть?

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