anton-s

Добрый день! Продаю: Ericsson SmartEdge SE100 б/у В комплекте две линейные платы по интерфейса 1 Gbit/s и лицензия BRAS на 8000 подписчиков. Цена: 300000 руб. Cisco SCE 2020 б/у В комплекте два блока питания на 220 вольт, модуль вентиляторов, четыре SFP модуля GLC-SX-MM и комплект патчкордов. Цена: 200000 руб. Способ оплаты можно обсудить. Территориально железки в городе Ставрополе. Контакты: +7 928 820-94-52 или anton-stv собака mail.ru Антон.

Софтовый. Linux + Accel-pptp

Абоненты цепляются по PPTP. На текущий момент, по опыту могу сказать, что после отключения транзитных узлов и потухания сессий на роутерах, самостоятельно сессии они не восстанавливают. Это печалит. После каждого блэкаута имеем десятки звонков от абонентов с зависшими роутерами. А тут нам предлагают иметь эти звонки просто так каждый день. P.s. IP, опять же, динамически раздаются.

Сессии рубятся раз в месяц (в начале месяца). Учета трафика нет. Тарифы, в основном, со сменой скорости днем и ночью, которая регулируется самим BRASом, т.е. скорость в отрыве от биллинга будет соответствовать тарифу. IP-адреса выдает BRAS из своих пулов, т.е. проблем с задвоением IP не будет. Проверку на наличие "сиротских" сессий реализовать, в принципе, можно. Но рубить их просто так каждый день? Это выше моего понимания.

Добрый день! Во время стыковки нашего BRAS с биллингом, находящимся в другом городе, возникла проблема: случился обрыв канала (плановый!), по которому идет обмен radius-пакетами, который привел к аварийному завершению некоторого количества сессий в биллинге и бесконтрольно висящим сессиям на BRASе. Вышестоящая организация считает, что необходимо реализовать ежедневный (или, хотя бы, раз в три дня) принудительный обрыв ppp-сессий средствами BRAS. На аргументы типа: "я не считаю это нормальным подходом", "половина роутеров (особенно DIR-300) после обрыва требуют перезагрузку для поднятия сессии обратно" и "масштаб неприятностей, которые случатся из-за одной-двух зависших сессий существенно меньше тех неприятностей, которые доставит нам ежедневное отключение абонентов" следуют ответы: "я считаю что ты преувеличиваешь проблему с клиентами" и "90% этого просто не заметят". Техническая поддержка абонентов, которых собираются отключать раз в день, лежит на нашем отделе. Те, кто принимают решение, общением с абонентами не занимаются. Аргументы и рациональные обоснования у меня закончились. Как можно убедить оппонентов, что просто так, на ровном месте, абонентские сессии рубить нельзя? Или, может быть, я не прав?

А тем временем у нас тут чудеса продолжаются. 18 июня мы одно дело проиграли (постановления, правда, пока нет) а сегодня, такое же дело (иски написаны под копирку, возражения -- тоже под копирку), правда от лица другой компании и в соседнем кабинете у другого судьи -- выиграли!

Эх. А мы вот вчера проиграли подобное дело. После публикации решения суда, выложу тут ссылку.

А что было-то? Всем же интересно теперь :)

Целиком и полностью поддерживаю брата Jenx-a. Вот еще мерзкое, заимствованное слово, которому нужно подобрать исконно русскую замену: "тариф". Ибо нет больше никакой мочи это терпеть! А вообще, я предлагаю не ограничиваться сетевой терминологией и срочно искать замену таким гнусным тюркско-греко-англо-романским заимствованиям, как: боярин, шатёр, богатырь, жемчуг, кумыс, ватага, телега, орда, анафема, ангел, епископ, демон, икона, монах, монастырь, лампада, пономарь, математика, философия, история, грамматика, известь, сахар, скамья, тетрадь, фонарь, буйвол, фасоль, свекла, комедия, мантия, стих, логика, аналогия, библия, доктор, медицина, лилия, роза, алгебра, амуниция, ассамблея, оптика, глобус, апоплексия, лак, компас, крейсер, порт, корпус, армия, капитан, генерал, дезертир, кавалерия, контора, акт, аренда, сундук, сарай. Про пианино с гитарой и виолончелью не забывайте! И это только начало!!! Я, правда, затрудняюсь подобрать исконно русское слово на замену арабской "цифре", да и от самих-то цифр арабских надо отходить. Неужели мы глупее арабов? У нас ведь есть своя, старославянская система обозначения чисел. Буквы вот только из греческого сильно заимствованы. Но это ведь тоже не проблема, правда? :)

Я, чтобы зарезать p2p, создал глобальные upstream и downstream контроллеры, обозвал их p2p-global, поставил им лимиты по скорости и в Default package прикрутил к глобальным контролерам bandwith-котроллеры, к которым уже привязал типы трафика bittorrent и encrypted bittorrent. Написал в личку

Снимаю статистику с портов коммутатора , куда воткнута SCE

К сожалению :( Угу. Ищем оптимум. Ну почему же вообще ничего не дропать. Задача стоит с минимальными потерями дожить до расширения. Т.е. дропать надо. Вопрос только чего дропать и в каком количестве. В личку написал.

Ну, скажем так, SCE, будучи платформой управления услугами для подписчиков, похоже, не подходит для шейпинга трафика на межоператорском стыке. Жаль, конечно. Была надежда на наличие кнопки "сделать все хорошо" :)

Угу. Попробую раскидать по типам и посмотреть. Ну, в моем представлении это все выглядело "прекрасно и совсем не больно" (с). :) А на деле разница иногда достигает даже не 50 мегабит, как я написал в первом сообщении, а 100. Это несколько выходит за рамки ожидаемого результата. На переполнение не похоже, т.к. такие значения даже на тех OIDах, по которым дропов в принципе быть не могло. Но 64-битный вариант сейчас поищу.

Коллеги, здравствуйте! Мы установили SCE2020 перед нашим бордером на нагруженный канал, зарезали p2p-трафик до 120 Мбит/с в глобальном BWC и наблюдаем такое явление: из интернета в SCE прилетает 400 Мбит/с а в сторону пользователей уходит 350 Мбит/с Могут ли быть такие драматические дропы вызваны жестким лимитированием p2p-трафика? Если могут, то изменится ли ситуация, если вместо жесткого лимитирования ввести приоритезацию p2p с помощью выставления более низкого AL для p2p-трафика? Спасибо. P.s. Нашел вот OID для просмотра количества дропов по SNMP, но он почему-то не работает, где-то что-то крутить надо? anton@anton-desktop:/tmp$ snmpwalk -v2c -c public 192.168.0.1 .1.3.6.1.4.1.5655.4.2.2.1.1.9 iso.3.6.1.4.1.5655.4.2.2.1.1.9.1.1.1 = Counter32: 4294967295 iso.3.6.1.4.1.5655.4.2.2.1.1.9.1.1.2 = Counter32: 4294967295 iso.3.6.1.4.1.5655.4.2.2.1.1.9.1.1.3 = Counter32: 4294967295 iso.3.6.1.4.1.5655.4.2.2.1.1.9.1.1.4 = Counter32: 4294967295