pchol Опубликовано 3 декабря, 2010 · Жалоба Добрый день. Имеется агрегация в виде 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 правил. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pliskinsad Опубликовано 4 декабря, 2010 · Жалоба дизайнить правильно Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 4 декабря, 2010 · Жалоба Очень дельный совет, лаконичный, бестолковый. PBR временное решение, связанное со сменой биллинга, есть необходимость "избранных" пользователей гонять через старый биллинг, который не умеет netflow и статистику можно получить лишь "пройдя" через него. Если Вы можете предложить иные варианты, как пользователей из разных виланов, гонять через разные шлюзы, то я был бы очень признателен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey_Taurus Опубликовано 4 декабря, 2010 (изменено) · Жалоба Если Вы можете предложить иные варианты, как пользователей из разных виланов, гонять через разные шлюзы, то я был бы очень признателен. vrf-lite? Но это если только "разные шлюзы" доступны через разные интерфейсы. Изменено 4 декабря, 2010 пользователем Sergey_Taurus Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 4 декабря, 2010 (изменено) · Жалоба А как это поможет ? Я так понимаю что помогло, если бы мне нужно было пользователей из одного вилана, направить на один шлюз, а пользователей из другого на другой. У меня же задача другая. Есть вилан Х, 5 пользователей из него направить на шлюз А, 5 на шлюз B Или я что то упустил ? Изменено 4 декабря, 2010 пользователем pchol Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 4 декабря, 2010 · Жалоба Ну так переносите "избранных" пользователей в другой(ие) влан(ы) или у вас оборудование доступа тупое? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Sergey_Taurus Опубликовано 4 декабря, 2010 · Жалоба А как это поможет ?Я так понимаю что помогло, если бы мне нужно было пользователей из одного вилана, направить на один шлюз, а пользователей из другого на другой. У меня же задача другая. Есть вилан Х, 5 пользователей из него направить на шлюз А, 5 на шлюз B Или я что то упустил ? У меня телепатические способности плохо развиты. Да, в этом случае (когда Вы нормально объяснили задачу) это не поможет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 4 декабря, 2010 · Жалоба Да, на доступе не везде стоит управляемое оборудование, поэтому нет возможности "высадить" в отдельный вилан всех "избранных". Sergey_Taurus, не обижайтесь, я без намека на претензии задавал вопрос. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 4 декабря, 2010 (изменено) · Жалоба у определенных пользователей маки известны? Сделайте так, чтоб циска от них не видела arp запросы. Одноко сервер висел напрямую в этих виланах и отвечал только необходимым клиентам своим маком. Как вариант - на циске ип шлюза сменить с .1 на .2 а все arp запросы обрабатывать на сервере. Необходимым клиентам отдать мак сервера, остальным мак циски. Например через ebtables arpreply Изменено 4 декабря, 2010 пользователем Дегтярев Илья Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pchol Опубликовано 4 декабря, 2010 · Жалоба Интересный совет. Но на мой взгляд как то сложно. А если на вилан интерфейсах повесить дополнительно адреса шлюзов, и модифицировать определенным скриптом резервации в dhcp (менять шлюзы). Можно ли каким то образом далее разруливать трафик с этих адресов ? Тоесть если трафик идёт через ип х.х.х.1 то next-hop 1, а если через х.х.х.2 то next-hop 2. Предполагается что оба адреса висят на одном вилан интерфейсе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Elisium Опубликовано 8 декабря, 2010 · Жалоба Столкнулся со следующей проблемой.В 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...