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

ValentinProstin

Пользователи
  • Публикации

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

  • Посещение

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


  1. Имеется 2 портовая карточка на чипсете 82576. На каждом порту организовано по две очереди rx. На одном из интерфейсов висит pppoe, соответственно, ip адресов на нем нет.

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

     

  2. А у меня такая беда

     

    patch -p1 <imq-2.6.27-hotfix.patch

     

    can't find file to patch at input line 3

    Perhaps you used the wrong -p or --strip option?

    Есть впечатление, что ты не то патчишь. Хотфиксом надо патчить основной патч imq для ядра (не iptables). И только потом накладывать его на исходники твоего ядра.

    Если поможет, проверь опцию -p. Возможно в товем случае (в зависмости от дерева каталогов) надо патчить с -p0

     

  3. Добрый день.

    Что-то не могу понять как решить проблему.

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

     

  4. Здравствуйте!

    Столкнулся с такой проблемой. 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 с таким приколом не сталкивался, там работает. Наставьте на истинный путь, знатоки.

     

     

  5. Хм, а ведь даже ручками подкрутить интерфейс не получится:

    (config)#int Virtual-Access3

    % Please use virtual template to configure your virtual access

    Изменение на темплейте приводит к глобальным изменениям на всех Virtual-Access интерфейсах.

    Вот здесь и здесь тоже упоминаются эти проблемы.

    Неужели только через дроп сессии?

     

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