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

sup2 и PBR максимум 255 правил на route-map ?

Добрый день.

Имеется агрегация в виде 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 правил.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Очень дельный совет, лаконичный, бестолковый.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

vrf-lite? Но это если только "разные шлюзы" доступны через разные интерфейсы.

Изменено пользователем Sergey_Taurus

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А как это поможет ?

Я так понимаю что помогло, если бы мне нужно было пользователей из одного вилана, направить на один шлюз, а пользователей из другого на другой.

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

Или я что то упустил ?

Изменено пользователем pchol

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну так переносите "избранных" пользователей в другой(ие) влан(ы) или у вас оборудование доступа тупое?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А как это поможет ?

Я так понимаю что помогло, если бы мне нужно было пользователей из одного вилана, направить на один шлюз, а пользователей из другого на другой.

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

Или я что то упустил ?

У меня телепатические способности плохо развиты.

Да, в этом случае (когда Вы нормально объяснили задачу) это не поможет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Sergey_Taurus, не обижайтесь, я без намека на претензии задавал вопрос.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

у определенных пользователей маки известны?

Сделайте так, чтоб циска от них не видела arp запросы. Одноко сервер висел напрямую в этих виланах и отвечал только необходимым клиентам своим маком.

 

Как вариант - на циске ип шлюза сменить с .1 на .2 а все arp запросы обрабатывать на сервере. Необходимым клиентам отдать мак сервера, остальным мак циски. Например через ebtables arpreply

Изменено пользователем Дегтярев Илья

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Интересный совет. Но на мой взгляд как то сложно.

А если на вилан интерфейсах повесить дополнительно адреса шлюзов, и модифицировать определенным скриптом резервации в dhcp (менять шлюзы). Можно ли каким то образом далее разруливать трафик с этих адресов ?

Тоесть если трафик идёт через ип х.х.х.1 то next-hop 1, а если через х.х.х.2 то next-hop 2. Предполагается что оба адреса висят на одном вилан интерфейсе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Столкнулся со следующей проблемой.

В route-map в качестве match условия указан extended access list.

Если в access list'е более 255 правил то свитч уходит в 99% загрузки cpu. Делаем 254 правила и видим стандартную нагрузку (7-10% в моём случае).

Если указать в match 2 access-list'a и в каждый внести по 200 правил получаем ту же самую картину.

В чём же дело ? И как это победить ? Есть серьёзная необходимость матчить по списку состоящему более чем из 250 правил.

Тоже используем пбр для примерно тех же целей )

До 255 правил в АЦЛ осталось всего ничего.

Вот такая бредовая идейка есть:

Попробуйте использовать не ДВА ацл в ОДНОМ матче, а сделать ДВА матча и в каждом по одному ацл )).

У нас на одном роут-мапе висит два матча с двумя ацл по 180/50 аце в каждом, правда некст-хопы разные.

Загрузка в норме.

п.с. ставить одинаковые некст-хопы не пробовал, но, имхо, должно работать.

п.п.с. с3750

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.