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

rdc

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

  • Публикации

    3021

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

  • Посещение

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

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

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

    Чтобы дать клиенту 120 Мег, нужно заменить все коммутаторы на гигабитные
    Все коммутаторы надо менять только в том случае, если нужно дать ВСЕМ клиентам по 120M.

    Если же это просто старший тариф, то на него подключатся далеко не все. Более того, ещё долгие годы значительная часть абонентов будет сидеть на тарифах <100M.

    Я по этому поводу уже ранее написал, что можно делать гибридные узлы - например, с одним FE и одним GE коммутатором.

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

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

    Доброго дня! Купили пару DES-3200-28F C1. По настройке после эджкора - полная ж. Может кто подскажет как настройки сделать PCF для пппое (разрешать только на аплинк).
    config traffic_segmentation 1-27 forward_list 28
    Вы о законе "о связи" вообще в курсе? Ваше "резать подчистую", боюсь, может закончится ровно до первой же жалобы абонента.
    Мультикаст через интернет всё равно не ходит.
    Всё же давайте ещё раз более предметно - чем вам мешает/может помешать "не ваш" мультикаст?
    А накой он мне нужен на входе?

     

    Я его срезаю почти под корень:

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

    Для функционирования ipv6 этой величины более чем достаточно. А больше его вдувать мне в сеть не нужно.

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

     

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

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

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

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

    А он умеет NAT, WiFi, стейтфул файрвол?
    Напоминаю, что мы рассматриваем ситуацию со стороны оператора, а не абонента.

    Мне как оператору проще сделать NAT со своей стороны, чем ставить и поддерживать (!) относительно дорогое управляемое железо у абонента. То же касается и базового файрвола - впрочем, NAT сам по себе уже обеспечивает невозможность присоединения извне.

     

    В случае, если нужен WiFi, можно воткнуть портом LAN любой роутер со встроенным гигабитным свичом, выключив ему dhcp. Это обеспечит GE wirespeed с вайфаем в одной коробке. А также даст возможность разворачивать ipv6 без необходимости в поддержке оного на старых роутерах.

     

    Не умеет снупинг, а это плохо. В некоторых случаях даже PC не переварит большой поток (хотя тут, возможно, виноваты говнофайрволлы у юзеров), а уж STB и так много не надо.
    Зато на нём НИКОГДА не будет квакать/квадратить ТВ из-за нагрузки на CPU мелкими торрентовыми пакетиками. Всегда честный wirespeed.

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

    Всё это костыли. Заткнуть все возможности хомячков нагадить друг другу не удастся.

    Правильное решение - изоляция прямого трафика. Либо traffic_segmentation в простейшем случае, либо по влану на клиента.

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

    Очевидно, что на данный момент >100M юзерам нафикненадо. Но надо быть готовым. Посему на всякий случай не допускаю распаривания кабелей.

     

    А на будущее - не могу определиться между двумя решениями для переходного периода: либо комбинировать FE и GE свичи в ящике, и переключать повышающих тариф в другой порт, либо обновлять весь доступ на GE.

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

    Теперь интересно если в DES-3200-28F вставить гигабитные sfp заведутся ли они?
    Заведутся при условии, если порт принудительно установлен в сотку.

     

    По моей статистике:

    DES-3026, DES-3526, DES-3828/3852, DGS-34xx, DGS-36xx, DGS/DXS-33xx - sfp не работают на сотке вообще.

    DES-1228/ME rev.A, DES-3028 - автодетект FE/GE

    DES-1228/ME rev.B, DES-3200 всех ревизий, DGS-1100-06/ME, DGS-3120-24SC - автодетекта нет, нужно принудительно ставить сотку.

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

    По-моему, вебморда тут излишняя, и противоречит unix-way.

     

    Лично я вижу эту софтину так:

    на входе - плейлист с перечнем каналов, который она время от времени перечитывает

    на выходе - что-то типа csv или по файлу на канал.

     

    Файл на входе должен быть отдельным от конфига, чтобы он мог генериться автоматически, не задевая конфиг.

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

    На выходе в явном виде, удобном для парсинга, выдаётся результат "жив/мёртв", который кушает мониторинг.

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

    Логика работы QinQ на новых (C1) железках следующая:

    На практике это значит, что на UNI портах надо ставить outer_tpid отличным от inner_tpid, иначе пакеты вторым тегом дополняться не будут.

    Нет.

    Приколы с отличием outer_tpid от inner_tpid - это баг в прошивке.

    В версии 4.34B008 отлично работают outer_tpid = inner_tpid = 0x8100.

    У них ещё и QinQ не той системы - нельзя для S-Vlan использовать тот же EtherType 0x8100, что и для C-Vlan.
    Эта проблема была только на DES-3028 (и DES-1228/ME rev.A соответственно).
    При включении QinQ все порты меняют свой tpid c 0x8100 на 0x88a8 и соответственно слетает управление (так как на него приходит стандартный пакет с тэгом)

    Короче такой вопрос, как включить QinQ через telnet и не потерять управление.

    Управление полезно держать без тегов. Решает много проблем, в том числе и эту.

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

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

    Ещё полезно автоотключение порта по петлям и штормам.

    mvr тоже не плохо бы иметь, но его можно сделать и на уровень выше.
    Вот-вот.

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

    Клиенту выдавать CPE.

    Так правильнее будет.

    Идея неправильная с точки зрения бизнеса.

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

    Поскольку эра ipv6 only ещё не наступила, то дешёвые CPE создадут узкое место на торрентах с кучей v4 коннектов и мелкими udp пакетиками, и тому подобных задачах.

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

     

    Далее - если выдавать за счёт оператора, то это зачем-то ещё и лишние затраты.

    А навязывать клиенту выкуп/аренду CPE в РФ запрещено законом.

     

    Самый лучший вариант - чтобы можно было воткнуть патчик в клиентский компьютер и всё работало само. А при необходимости включения более одного компьютера - чтобы по-минимуму хватало простейшего свича-мыльницы.

     

    Пример правильного подхода - известный в мск провайдер OnLime.

    (впрочем, как у них с v6 - не знаю…)

     

    Если у вас есть возможность засунуть каждого абонента в отдельный vlan, то с точки зрения безопасности это самое правильное решение. И самое главное, что это минимизирует кол-во софтфич на доступе
    Именно!

    И позволяет использовать самые дешёвые решения для доступа, типа DES-1228/ME, от которых ничего кроме dot1q и не требуется вовсе.

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

    А почему бы и не посадить каждого клиента в отдельный влан? QinQ решает вопрос количества вланов.

    Я реализовал дуалстек таким образом: vlan per customer, индивидуальные v6 и серые v4 подсети каждому клиенту, а также белые v4 адреса поштучно (rfc3069).