Al_Pantone

Для агрегации ядра, естественно мало, поэтому я сразу предположил что речь идет про агрегацию трафика на районе - судя по 1U

Fourty-eight 10/100/1000Base-T ports and four 10GEBase-X SFP+ ports Вот такая спецификация S5352, пачка не пачка, но 4х10G должно хватить на любое резервирование. Больше 10-ток на подобного уровня свитчах и не должно быть, проц не переварит трафик.

Поддерживаю Возможно даже хватит S5300 серии, QinQ там точно есть, надежность и стабильность хорошая. 1U как и требуется + цена раза в 3 ниже S6700.

Да смотрим конечно) Будем свапать в этом году основные БРАСы и освободится ASR 1002, её то и поставим вместо архаичной 72-ой кошки. Ведь там и по трафику скоро до гигабита доберется, а это переход на 10G со всеми вытекающими

Cisco 7206VXR (NPE-G1) с PPPoE QinQ на борту (около 800 абонентов в пике), NAT, QOS и прочие прожорливые сервисы отсутствуют. Как только трафик вырос (вместе с абонентской базой с 250 до 800 упомянутых) до 700Mbps IN / 100Mbps OUT - CPU Браса стал захлебываться >80%. По таблице производительности до гигабита NPE-G1 и должен тянуть, NPE-G2 в два раза больше.

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

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

Был настроен туннель mpls l2 между указанными в заголовке устройствами и трафик спокойно ходил по нему. Вот конфигурация интерфейсов (IP придуманы) Huawei interface GigabitEthernet2/0/11 undo portswitch description ftp_Server mtu 1550 mpls l2vc 192.168.1.1 1243 и Cisco interface Vlan1243 description ftp_server mtu 1550 no ip address xconnect 192.168.1.2 1243 encapsulation mpls Все работало долгие годы, но в одночасье перестал ходить пинг между интерфейсами данного VLAN 1243. Сам VC поднят по прежнему *Client Interface : GigabitEthernet2/0/11 Administrator PW : no AC status : up VC State : up Label state : 0 Token state : 0 VC ID : 1243 VC Type : Ethernet session state : up Destination : 192.168.1.1 link state : up на другом край тоже все в порядке. Сами железки отлично видят loopback'и (по ним устанавливается соседство) Пробовал менять MTU на интерфейсах - не помогло. Другие vc между этими пирами так же в UP, но по ним тоже трафик не проходит. Что могло поменяться, что привело к такой аказии, конфигурации этих устройств ближайшее время точно не были изменены, может кто сталкивался с подобным?

Сессия дропается по COA от радиуса и рестартует. Однако для этих проблемных сессий, почему то этого не произошло (аптайм несколько недель), т.е. по ним никаких изменений не происходит. Но меня волнует вопрос - как можно на Брасе отловить пакеты COA от радиуса для конкретной сессии? Дебагом можно, но тогда есть риск загрузить циску. Выходит выход один - через сислог-сервер?

Сессия в authen и понятно, что Радиус ответил акцептом, но хочется посмотреть какие еще сообщения от него летели для этой сессии, почему когда случился event "блокировка по счету" от радиуса не пришел сервис на гостевой доступ? К радиусу я не имею доступа.

Добрый день. Как можно увидеть какие атрибуты отдаются абонентской сессии при её старте? Просто есть абоненты, которые должны получать access-reject (т.к. их баланс отрицателен) и соответственно навешиваться должны фичи OPENGARDEN и l4redirect, однако им по какой то ошибке выдаются атрибуты нормальной сессии и они продолжают гнать трафик. Как можно увидеть результат общения BRAS'а и Radius'а по конкретной сессии? Или дебаг выведется на все сессии, а потом уже фильтровать? Но как "дебажить" BRAS, находящийся в работе, ему плохо не станет от такого количества запросов и вывода в консоль этой инфы?

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

А с Radius'а отправить новый сервис можно принудительно? Тогда новые сессии будут получать новый сервис, а старые пока активны будут на старом, я правильно понимаю (Radius'ом я не рулю и даже не могу посмотреть настройки, только создать заявку и её исполнят, но надо четко поставить задачу)

Доброго всем времени суток. У меня возник такой вопрос к знающим - Есть BRAS на Cisco ASR-1004 с ISG на борту, соответственно IPOE. На пользовательские сессии навешиваются фичи, некоторые локально, а некоторые прилетают от Radius-сервера. Сервис L4Redirect навешивается на сессию именно RAdius'ом, ну т.е. BRAS единожды запросив у Radius'а данный сервис, кэширует его и потом приаттачивает куда нужно. Но возникла необходимость поменять IP-адрес из сервиса L4redirect (что бы клиенты при нулевом балансе форвардились на страницу-заглушку). И собственно вопрос - как это можно сделать безболезненно для пользователей, без перезагрузки BRAS'ов? Можно ли перезапросить у Radius'а сервисы и обновить тем самым его кэш, что бы на новые сессии применялся уже измененный L4Redirect?