Mnemoid

А что коллеги могут сказать про биллинг от Forward Telecom? Насколько гибок и надежен сам биллинг и насколько адекватен разработчик?

В каких случаях может потребоваться S-MX80-SSM-FP? Например, если я использую Dynamic Profiles, который получает параметры через RADIUS атрибуты, то нужна эта лицензия или она нужна только если я хочу "на ходу" менять параметры сессии?

А что плохого в этом варианте? Плохого ничего. Просто хотел выясниь общепринятые практики для этого оборудования и убедиться, что ход мыслей правильный.

Они давние фанаты Люцента.

Вобщем, судя по всему, при помощи динамических профилей автоматически создается demux интерфейс и к нему применяется обычный фильтр с полисером на входящий трафик. Есть какие-то другие варианты?

Да, абоненты к MX будут подключаться на L2, т.е. он и будет терминировать VLANы.

В MX для трафика в сторону абонента поддерживается иерархический CoS, в т.ч. и шейпинг. Входящий от абонента, вроде как только полисинг. Является ли это единственным способом ограничения скорост ивходящего от абонента трафика или все же вохсожен полноценный CoS на противоположном порту? IP unnumbered на EX нет. Используем EX3200 для терминации VLANов, DHCP relay и дополнительного причесывания трафика.

BRAS в данном случае достаточно условное понятие. У нас в сети используется на данный момент IPoE + DHCP и идеология subscriber management от Juniper хорошо ложится на существующую сеть. К тому же, в наших краях, легче достать MX чем SmartEdge. Ну и последний довод в том, что мы уже используем коммутаторы Juniper EX и они нам нравятся. Будем и дальше поддерживать данного производителя :-).

Планируем приобретать Juniper MX10/MX80 в качестве BRAS/Subscriber management на базе технологии DHCP + IPoE. В целом все понятно, но нигде не могу найти ясный пример того, как обеспечивается ограничение скорости трафика, идущего от абонента при использовани динамического профиля. Во всех примерах показана настройка исходящего трафика для интерфейса, который смотрит в сторону абонента. По идее, точно также должен настраиваться интерфейс, который смотрит в сторону Интернета, для нарезки исходящего от абонента трафика, но в документации этот вопрос изящно обошли. Поэтому возникает вопрос, как на MX80 реализовать ограничение трафика идущего не только к абоненту, но и от него с использованием динамических профилей?

А вы попробуйте сами сделать свой вариант, а мы, если что - поправим. Для начала сделайте queue tree для входящего трафика на внутреннем интерфейсе. Создайте корневую очередь с общим ограничением на канал, потом создайте для каждого абонента очередь, которая в качестве родительской будет использовать корневую очередь. В абонентской очереди режете нужную скорость в зависимости от пакета. Чтобы нужный пакет попал в нужную очередь, помечаете его в mangle. Это описывается в множестве мест в той же wiki это есть. Фишка заключается в том, что если клиентов много, в mangle приходится просматривать большое количество правил, прежде чем найдется подходящее. Так вот чтобы этого не делать, процесс просмотра разбивается на две части. Сначала просматриваются chain с правилами для определения подсети (например /24) в которой находится искомый IP. Когда нужное правило найдено, в нем выполняется действие jump на цепочку, соответствующую данной подсети. В этой цепочке уже находятся правила, которые проверяют IP только из выбранной подсети. Таким образом, этот алгоритм является модификацией стандартного способа работы с queue tree. Реализуйте сначала рабочий queue tree, а затем оптимизируйте по приведенной выше схеме.

Естественно, для маркировки первых пакетов надо использовать address-lists, для остальных - connection-marks. Вариант: 1. Использовать Queue Tree на входящем и исходящем интерфейсе. (не Simple Queue) 2. Пакеты маркировать в IP/Firewall/Mangle 3. Для уменьшения количества просматриваемых правил в Mangle, желательно сгруппировать подсети на несколько блоков. К примеру, сначала просматривается chain со списоком подсетей /24, а затем jump на chain соотвествующей подсети. Там уже просматривается каждый ip или подсеть соответствующей очереди.

никто про зарезание трекеров не говорит. речь о другом. весь p2p трафик, не классифицированный как "полезный" (пример полезного - skype), можно гонять в последнюю очередь, оставляя минимум полосы (например 10% от всего канала). кто-нибудь на микротике такое осуществлял? подскажите... сам пробовал блочить через маркировкку p2p-трафика....но чет как-то не удачные попытки были... Mikrotik плохо определяет p2p трафик, т.к. тот же torrent умеет хорошо шифроваться и скрывать свою деятельность. Надо постоянно сигнатуры обновлять, а MT нет отдельного механизма обновления сигнатур. Как вариант - ручное вбивание сигнатур в Layer 7 Protocol.

В принципе, так и есть. У одного из крупных операторов есть свой сервер замеров. И сети этот оператор строит в основном с использованием ethernet технологий. Но с другой стороны, та же самая ситуация может быть и в России и в других странах. Может быть многое зависит от пиринговых отношений? В той же Молдавии практически все операторы сидят на местном эксчейндже и предоставляют очень высокую скорость в пределах Молдавии.

Интересный факт в статье на ленте.ру. Вкратце - Молдавия обогнала Японию, и тем более Россию, в средней скорости доступа в Интернет. Что это, издержки способов измерения или последствия конкурентной борьбы? Статья целиком.

Мы тоже регистрировали AS+PI в ipaddr.ru. Отработали достаточно оперативно. Лишний раз звонить не приходилось.

Мне кажется, что это не самый лучший вариант решать поставленную задачу средствами DNS сервера. Если стоит задача показывать неплательщикам определенную страницу, то один из логичных методов будет следующее: - для всех пакетов, у которых порт в адресе назначения равен 80, применить DNAT, подставив в качестве нового адреса назначения, адрес веб-сервера где лежит эта страница; - на веб-сервере можно организовать пустой виртуальный хост, который настроен таким образом, что при ошибке 404 ,будет показывать нужную Вам страницу.

Соотвественно - set.

aln-tc-a (Aluminium), aln-tc-c (Copper). Алюминий и медь соответственно. По крайней мере когда мы делали срез на aln-tc-a, то было явно заметно что сердцевина значительно светлее чем покрытие. Да и сам кабель был более ломкий. Думаю, что на небольших расстояниях от коммутатора до квартиры такой кабель можно ложить, хотя сами стараемся от греха подальше класть только медь.

Про электросети и интернет. Мне кажется, что не совсем корректно сравнивать нынешние электросети и нынешний интернет. Электричество поставляют потребителям уже более ста лет, а интернет менее 20 лет. Очень сильно подозреваю что первые электропотребители таки имели безлимит без счетчика и мигающей лампочкой. Сейчас цена электричества намного ниже первоначальной, а возможности электрической сети значительно возрасли. Если провести обратную аналогию, то интернет должен был бы стоить копейки за гигабайт и к каждому пользователю подводился бы канал в 10 Гигабит (меньше физически невозможно подать). При этом устройство учета можно было бы заставлять покупать самого пользователя. Думаю что в таком случа бизнес модель продажи интернета стала бы близкой к тому, что сейчас представляет собой продажа электричества.

Необходимо прописывать как тэгированные все необходимые VLANы на портах, через которые эти VLANы будут проходить. Динамические VLANы этот коммутатор не поддерживает. GVRP земечен не был, в том числе и в документации.

Конечно есть!