sup 720 ( cisco 6500, cisco 7600 )

[Master239]

имеется сабж.

на нем есть ACL в нем те кто заплатил за интернет. как следствие количество записей там давно перевалило за 10 000, все отлично работает но когда нужно добавить ещё одну новую запись то сабж начинает чето там пересчитывать и задумывается при этом проц занят на 100% в течении примерно 8ми минут. что довольно напрягает так как новые абоненты появляются чаще чем раз в 8 минут и получается что днем у кошки почти все время 100% загружен проц.

 

как быть ? что читать ?

может это принципиально не правельный подход ?

[ingress]

0_0

 

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

Edited September 19, 2007 by ingress

[Master239]

ниже не получится...

предыжие железки: 3750 на которой такого не сделать.

на порту: потому что много не управляемого оборудования.

[Nailer]

имеется сабж.

на нем есть ACL в нем те кто заплатил за интернет. как следствие количество записей там давно перевалило за 10 000, все отлично работает но когда нужно добавить ещё одну новую запись то сабж начинает чето там пересчитывать и задумывается при этом проц занят на 100% в течении примерно 8ми минут. что довольно напрягает так как новые абоненты появляются чаще чем раз в 8 минут и получается что днем у кошки почти все время 100% загружен проц.

 

как быть ? что читать ?

может это принципиально не правельный подход ?

Скорее всего суп занят компиляцией ACL-ей, есть у 6500 такая фича. Курите доки на эту тему + оптимизация загрузки TCAM (возможно, ее стоит отключить).

 

Будет время - я сам гляну, интересно, но пока не разбирался в этом.

[Умник]

ACL в нем те кто заплатил за интернет.

Может быть лучше сделать наборот - ACL, с теми, кто _НЕ_ "заплатил за интернет"? В целях оптимизации количества записей - таких-то уж точно будет меньше.

[Master239]

Может быть лучше сделать наборот - ACL, с теми, кто _НЕ_ "заплатил за интернет"? В целях оптимизации количества записей - таких-то уж точно будет меньше.

временами их 50% так что не вариант...

 

+ это как то идейно не правельно я считаю что последняя строчка фраервола должна быть "deny ip any any" ;)

[Master239]

Скорее всего суп занят компиляцией ACL-ей, есть у 6500 такая фича. Курите доки на эту тему + оптимизация загрузки TCAM (возможно, ее стоит отключить).

я тоже так считаю но никаких настроек на эту тему я не нашол. + интересно что 720 суп начинает просчитавать ACL после любого изменения! а sup32 только после выхода из режима конфигурирования ACL - то есть применяет все сразу, а не по очереди каждое изменение.

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

 

 

 

ЗЫ я вообще не понимаю почему 720 и 32 супы настолько разные в мелачах. там даже команды многие отличаются как можно было такое допустить в одной платформе ? загадка...

[short]

если это qos ACL / qos tcam

 

то так и есть.

известная фича-бага.

даже в tac чего-то открыто на эту тему.

 

если это security acl / security tcam - то больше минуты максимум двух это не должно занимать..

 

к какой фиче acl прикручены?

[Master239]

это не qos это security.

просто банальный фильтр на физическом интерфейсе.

а там получается чем больше строчек в ACL тем дольше оно его пережовывает... при бальше 10 000 это уже явно не 1-2 минуты.

[ingress]

может при таком количестве попробовать саггрегировать в префиксы :)

[UglyAdmin]

Используйте

ip access-list extended 12345

1 permit ip host x.x.x.x1 any

2 permit ip host x.x.x.x2 any

...

10 permit ip host x.x.x.x10 any

.....

Для запрещения доступа:

ip access-list extended 12345

no 1

no 10

....

Т.е. у каждого клиента должна быть определённая строчка в ACL и передавайте только изменения, это несложно сделать.

Но вообще решение кривое, упрётесь в TCAM рано или поздно...

[short]

нормальное это решение.

 

в какой tcam он упрется? в 32k записей?

так больше на 720 терминировать - все равно самоубийство.

 

.е. у каждого клиента должна быть определённая строчка в ACL и передавайте только изменения, это несложно сделать.

ага. особенно определенная она будет после перезагрузки коробки.

все он правильно делает. это ему не поможет.

[random7]

А таблицей маршрутизации нельзя обойтись?

Кто не платил - того в Null0

[short]

типа можно вообщем..

 

но не очень кашерно, если клиенты - connected хосты

не смогут посетить персональный кабинет aka страницу статистики ))

[UglyAdmin]

ага. особенно определенная она будет после перезагрузки коробки.

Да, после перезагрузки придётся синхронизировать. Но снизить время обработки должно, т.к. компилится будут только изменения.

 

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

Соответственно имеем интерфейс на юзера с персональным ACL и service-policy. Правда, с неуправляемым железом облом, но это как-то совсем прикольный дизайн сети, если в центре шеститонник с SUP720, а на периферии китайские мыльницы.

[random7]

ну я бы посадил сервер статистики и прочие там днсы в клиентские вланы

[short]

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

нет.

никакой разницы по сравнению с

 

ip access-list ext ABC

permit ip host x.x.x.x any

 

ip access-list ext ABC

no permit ip host x.x.x.x any

 

не будет.

[UglyAdmin]

С этим не будет, а с

no ip access-list ext ABC

ip access-list ext ABC

permit ip host x.x.x.x1 any

permit ip host x.x.x.x2 any

permit ip host x.x.x.x3 any

permit ip host x.x.x.x4 any

permit ip host x.x.x.x5 any

будет :)

[short]

так автор вроде не упоминал, что он скидывает весь лист целиком, а затем целиком его составляет.

[dmnp]

имеется сабж.

....

были в точно такой же ситуации (только на sup2).

попробуйте разделить ACEs по нескольким ACLs на разные интерфейсы.

почитать можно "Understanding ACL Merge Algorithms and ACL Hardware Resources on Cisco Catalyst 6500 Switches" - http://www.cisco.com/warp/public/cc/pd/si/...ch/65acl_wp.pdf

Edited September 24, 2007 by dmnp