ValentinProstin

cat /proc/interrupts и mpstatПоднял ip на интерфейсе и с двух машин сделал ping -f. Сверился: прерывания делятся.

Имеется 2 портовая карточка на чипсете 82576. На каждом порту организовано по две очереди rx. На одном из интерфейсов висит pppoe, соответственно, ip адресов на нем нет. Проблема в том, что не балансируются прерывания по очередям на pppoe интерфейсе. Но втором интерфейсе (он смотрит наружу) - все нормально. Я выяснил, что прерывания делятся на основании srcIP. Можно ли как-то заставить карточку load balancing отрабатывать по mac адресам?

Есть впечатление, что ты не то патчишь. Хотфиксом надо патчить основной патч imq для ядра (не iptables). И только потом накладывать его на исходники твоего ядра.Если поможет, проверь опцию -p. Возможно в товем случае (в зависмости от дерева каталогов) надо патчить с -p0

Сначала патч для ядра патчишь этим: http://www.mail-archive.com/pld-users-pl@l...27-hotfix.patch А потом уже накладываешь на исходники ядра.

Не получится никак. Есть физическая скорость интерфейса и системе пофиг, какие _программные_ дисциплины обработки или полисеры висят на нем и как режут скорость. Опять же, если организованы две, три и более очередей ограничения трафика (интернет, локалка, городской доступ) - что у клиента должно вырисовываться?

Отбой по вопросу. Аксес лист резал. fixed.

Здравствуйте! Столкнулся с такой проблемой. 7200, терминирует pppoe. Радиусом клиентам выдаются реальные адреса. Почему-то они не улетают в ospf домен, хотя делают вид, что редистрибютятся: Routing entry for x.x.87.247/32 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via ospf 1 Routing Descriptor Blocks: * directly connected, via Virtual-Access3 Route metric is 0, traffic share count is 1 При этом все /32 адреса на loopback'ах улетают в роутинг аж со свистом. Вот кусок конфига router ospf 1 router-id x.x.80.130 log-adjacency-changes redistribute connected subnets passive-interface default no passive-interface GigabitEthernet0/0 interface Virtual-Template1 mtu 1492 ip unnumbered GigabitEthernet0/0 ip nat inside autodetect encapsulation ppp peer default ip address pool PPPOE_POOL ppp mru match ppp authentication chap ms-chap ms-chap-v2 radius ppp authorization radius ppp accounting radius ppp eap refuse ppp direction callin ppp pap refuse В quagga с таким приколом не сталкивался, там работает. Наставьте на истинный путь, знатоки.

Хм, а ведь даже ручками подкрутить интерфейс не получится: (config)#int Virtual-Access3 % Please use virtual template to configure your virtual access Изменение на темплейте приводит к глобальным изменениям на всех Virtual-Access интерфейсах. Вот здесь и здесь тоже упоминаются эти проблемы. Неужели только через дроп сессии?

Приветствую. Стоит задача как можно более нативным и элегантным методом изменять параметры ограничения скорости для виртуального (читай ppp) интерфейса. Дано: BRAS, терминирующий pppoe на 7201 + внешний радиус (freeradius). Клиент подключается, с радиуса ему прилетает в access-requiest'e параметр lcp:interface-config и через него задается скорость через рейтлимиты (ну или через шейпинг, без разницы). Отлично! Но, к примеру, по определенному событию (наработка определенного порога трафика, либо в определенное время) нужно скорость изменить в ту или иную сторону. Можно ли как-то через interim-update пакеты или по другому реализовать онлайн схему? Скидывать клиента с линии нельзя (задача тогда смысла не имеет). Можно удаленно по ключам с радиуса идти на циску по ssh или rsh, но имхо, это костыли. Или через Net::Telnet... Можно ли как-то через snmp это проделать? Но в идеале хочется это через протокол радиуса все проворачивать. Подскажите, в какую сторону копать...