Здравствуйте уважаемые!
Вопрос может и глупый. Ну тогда так и скажите. На циске делается НАТ. Примерный конфиг:
ip nat pool pool-1 xxx.xxx.xxx.1 xxx.xxx.xxx.1 prefix-length 30
ip nat pool pool-2 xxx.xxx.xxx.2 xxx.xxx.xxx.2 prefix-length 30
ip nat pool pool-3 xxx.xxx.xxx.3 xxx.xxx.xxx.3 prefix-length 30
ip nat pool pool-4 xxx.xxx.xxx.4 xxx.xxx.xxx.4 prefix-length 30
ip nat pool pool-5 xxx.xxx.xxx.5 xxx.xxx.xxx.5 prefix-length 30
!
ip nat inside source list 19 pool pool-1 overload
ip nat inside source list 20 pool pool-2 overload
ip nat inside source list 21 pool pool-3 overload
ip nat inside source list 22 pool pool-4 overload
ip nat inside source list 23 pool pool-5 overload
!
access-list 19 permit 10.1.2.0 0.0.0.255
access-list 20 permit 10.1.4.0 0.0.0.255
access-list 21 permit 10.1.6.0 0.0.0.255
access-list 22 permit 10.1.8.0 0.0.0.255
access-list 23 permit 10.1.10.0 0.0.0.255

Это только часть конфига. Дальше еще присутствует около 60 подобных строк.
Сразу говорю - все работает! Но хочется оптимизировать, т.к. не вижу больше необходимости в такой разбивке. Предполагаю сделать один пул внешних ip и сделать один acl. Но... В свое время, когда искал доку по циске, где-то наталкивался на то, что вроде бы держать много мелких acl выгоднее для работы железа. К сожалению, сейчас эту доку найти не могу. А в цисковских доступных мне доках этого не оговаривается.
Гуру! Поскажите, что на самом деле проще - держать один acl или много мелких? Как это сказывается на скорости обработки пакетов?
Гуру

• Опять списки доступа.,Andrew, 22:24 , 16-Дек-03

Похоже опять меня одного мучают эти идиотские вопросы... Печально... Может все-таки подскажет: что эффективней много маленьких списков или один большой? То что большой труднее сопровождать - это я знаю. И это мои проблемы. А вот скорость обработки???? Подскажите! Плиз!!