pchol

Попробовать побить на /24 ? Простейшее что можно сделать, на нейбора повесить route-map на out, а в нём уже сделать match ip address 11 set as-path prepend 11111 на каждую сеть /24 индивидуально, и попробовать разбалансировать трафик между линками.

Перехали с фрирадиуса на радиус биллинга (ланбиллинг), лог засыпало ошибками. Jan 28 05:24:31 shaper ISG[6915]: No more servers to retry for 'x.x.246.107', give up Jan 28 05:24:31 shaper ISG[6915]: No more servers to retry for 'x.x.238.88', give up Jan 28 05:24:31 shaper ISG[6915]: No more servers to retry for 'x.x.237.214', give up Jan 28 05:24:31 shaper ISG[6915]: No more servers to retry for 'x.x.247.69', give up Jan 28 05:24:32 shaper ISG[6915]: No more servers to retry for 'x.x.233.21', give up Jan 28 05:24:32 shaper ISG[6915]: No more servers to retry for 'x.x.232.214', give up Непонимаю в чём дело. Радиус по этим клиентам нормально отдаёт информацию. shaper:/var/log#radtest х.х.237.214 х.х.237.214 192.168.90.200 1812 blscrns Sending Access-Request of id 149 to 192.168.90.200 port 1812 User-Name = "х.х.237.214" User-Password = "х.х.237.214" NAS-IP-Address = х.х.226.11 NAS-Port = 1812 rad_recv: Access-Accept packet from host 192.168.90.200 port 1812, id=149, length=65 Session-Timeout = 86400 Service-Type = Framed-User Framed-Protocol = PPP Class = 0x3030303734303031 Acct-Interim-Interval = 60 Class = 0x343030302f34303030

Вы бы ребята усилия объединили и выложили это в каком то "официальном виде". Чтобы не приходилось нам делать diffы и собирать всё это по кусочкам =)

По поводу реализации http://forum.nag.ru/forum/index.php?showto...mp;#entry456177

Так как коммутатор L3 на ум приходит только то, что стоит вспомнить принципы работы pppoe, сервер и клиент должны быть в одном вилане (грубо говоря).

Да ладно Вам, вполне себе выбор. Шасси + сап2 + 2 бп + вентиляторы обойдётся порядка 75к. Далее модуль 6516 забитый ГБИКами будет выходить в 35к. Если считать что dlink dgs-3627 стоит 70к + 18к модули в него, то путём не сложных подсчётов можно выяснить что 2 длинка выходят выходят по стоимости примерно столько же сколько и цыска с 3мя модулями Если рассчитывать по максимуму тоесть 8 модулей + сап, то получаем 128 портов за 315к. С длинком же получаем за 400 с гаком. Экономия может быть и посредственная, однако можно учитывать "плавность" роста (модули по 16 портов) + потенциал роста мозгов (смена сапа)

Бред какой то. Судя по инфе на сайте самой цыски... Всё это storm control Только в древних релизах он Broadcast Suppression Вобщем просто обновить IOS =)И не попасть модулями в список

Ну если верить тому что она сама пишет то:

На форме можно не ждать ответа. Пишите в HelpDesc на их сайте.

А почему 2 потеряется ?

Вот плохому учить не нужно.Скорее всего там блоки PI. А их райп бить совсем не рекомендует. Нужно создавать объекты route, этого обычно достаточно. А описанная задача по-моему решается установкой iBGP между бордерами, на НАСах только defaul gw , а вот какой НАС на сколько загрузить решает уже агрегация ниже.

Забыл, там ещё iptables -A FORWARD -j NETFLOW Но эта штука при 700мбитах вызывает скачкообразную загрузку cpu. Тоесть загрузка прыгает до 70% и потом обратно (если глядеть через htop) Пытаюсь подобрать подобающие значения параметров модуля netflow. На данный момент такие. net.netflow.hashsize=262144 net.netflow.sndbuf=499712 Кстати. Смена сетевух на ЕТ даст прирост производительности в данной схеме ? Или же всё таки упёрлись в кеши/частоту cpu и всё ?

Интересный совет. Но на мой взгляд как то сложно. А если на вилан интерфейсах повесить дополнительно адреса шлюзов, и модифицировать определенным скриптом резервации в dhcp (менять шлюзы). Можно ли каким то образом далее разруливать трафик с этих адресов ? Тоесть если трафик идёт через ип х.х.х.1 то next-hop 1, а если через х.х.х.2 то next-hop 2. Предполагается что оба адреса висят на одном вилан интерфейсе.

Да, на доступе не везде стоит управляемое оборудование, поэтому нет возможности "высадить" в отдельный вилан всех "избранных". Sergey_Taurus, не обижайтесь, я без намека на претензии задавал вопрос.

А как это поможет ? Я так понимаю что помогло, если бы мне нужно было пользователей из одного вилана, направить на один шлюз, а пользователей из другого на другой. У меня же задача другая. Есть вилан Х, 5 пользователей из него направить на шлюз А, 5 на шлюз B Или я что то упустил ?

Очень дельный совет, лаконичный, бестолковый. PBR временное решение, связанное со сменой биллинга, есть необходимость "избранных" пользователей гонять через старый биллинг, который не умеет netflow и статистику можно получить лишь "пройдя" через него. Если Вы можете предложить иные варианты, как пользователей из разных виланов, гонять через разные шлюзы, то я был бы очень признателен.

Текущие показателе на NAS'е (ЧНН) total: 1240.72 Mb/s In 1145.28 Mb/s Out - 215184.3 p/s In 200529.8 p/s Out eth0: 681.13 Mb/s In 539.52 Mb/s Out - 107060.2 p/s In 105470.7 p/s Out eth1: 559.59 Mb/s In 605.75 Mb/s Out - 108123.2 p/s In 95058.4 p/s Out # /usr/local/ISG/bin/ISG.pl show_count Approved sessions count: 2017 Unapproved sessions count: 49 # w 19:52:32 up 57 days, 9:47, 3 users, load average: 0,19, 0,16, 0,10 # mpstat -P ALL Linux 2.6.32-5-amd64 (shaper) 03.12.2010 _x86_64_ (8 CPU) 19:53:21 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 19:53:21 all 1,55 0,08 0,36 0,01 0,00 11,54 0,00 0,00 86,44 19:53:21 0 2,37 0,07 0,38 0,02 0,00 12,53 0,00 0,00 84,63 19:53:21 1 3,26 0,08 0,47 0,02 0,00 11,70 0,00 0,00 84,47 19:53:21 2 3,16 0,08 0,44 0,02 0,00 11,67 0,00 0,00 84,62 19:53:21 3 2,96 0,06 0,38 0,02 0,00 11,36 0,00 0,00 85,21 19:53:21 4 0,15 0,09 0,41 0,01 0,00 11,69 0,00 0,00 87,65 19:53:21 5 0,16 0,09 0,30 0,01 0,00 11,36 0,00 0,00 88,09 19:53:21 6 0,16 0,08 0,28 0,01 0,00 11,23 0,00 0,00 88,23 19:53:21 7 0,16 0,08 0,26 0,01 0,00 10,80 0,00 0,00 88,70 тут же ещё присутсвует чуть чуть НАТа # conntrack -S | grep ent entries 122667 CPU 2 х E5410 (2,33 GHz) Сетевухи intel pt1000 (82571EB)

Добрый день. Имеется агрегация в виде cat 6509 / sup 2 / IOS 12.2(18)SXF17. Применяется PBR, route-map висят на vlan интерфейсах. Столкнулся со следующей проблемой. В route-map в качестве match условия указан extended access list. Если в access list'е более 255 правил то свитч уходит в 99% загрузки cpu. Делаем 254 правила и видим стандартную нагрузку (7-10% в моём случае). Если указать в match 2 access-list'a и в каждый внести по 200 правил получаем ту же самую картину. В чём же дело ? И как это победить ? Есть серьёзная необходимость матчить по списку состоящему более чем из 250 правил.

Можно использовать -j NETMAP, там с алгоритмом всё предельно ясно.

Я слабо знаком с нашими кодексами поэтому задам вопросы. 1) Существует ли в нашем ГК статья указывающая на то, в течении какого времени после оплаты, услуга должна быть оказана ? 2) Если в Договоре между Абонентом и Оператором не указано SLA (а с физиками обычно не указывают), то может ли Оператор предоставлять услугу в течении одного часа в сутки, будет ли это нарушением Договора или ГК ? По идее если никаких SLA нет, то нельзя подать в суд на тему "упущенной прибыли", и можно на час в сутки включать интернет и "предоставлять оплаченную услугу". Чем регламентируется обязанность Оператора оказывать услугу 24/7 ?

Что за глюки ? Что за софт использовали ?

Последнее время часто встречаю в спецификациях свитчей (в основном китай) поддержку данного протокола. Если поглядеть вроде бы всё довольно красиво, примитивные трапы, не требующие наличия ip сети. Вопрос в том, использовал ли кто данный протокол в продакшене, для примитивного мониторинга состояния свитчей (своего рода пинговалка). Есть ли какой либо софт для сбора статистики с помощью этого протокола. Какие проблемы испытывали при использовании ? Что являлось причиной такой не популярности данной технологии мониторинга ?

Очень очень очень ждём. От него испытываешь зависимость, попробовал разок и возвращаться на старый шейпер с постоянной "вгрузкой" правил оч. не хочется.

Abram, ресурсоёмко с точки зрения загрузки на мой второй сап. Староват он для этих дел =)

А абонентские роутеры как жуют маршруты выдаваемые по dhcp ? На мой взгляд первое преимущество L3 это разделение абонентского локального трафика (в том числе и паразитного бродкастного), от "интернетовского",своего рода демилитаризация. На NAS идёт только то что должно идти через интернеты/пиринг, и там соответствующим образом пользователю отпускается заказанная услуга. Abram, кстати да, тоже таким образом рулим пользователей на 2 разных NAS'а. Только это немного ресурсоёмко, пытаемся отказаться от этой схемы.