Jump to content
Калькуляторы

Как правильно отнатить пул в пул на Cisco

Уважаемые гуру. Направьте на путь истинный.

Есть диапазон белых адресов

Есть диапазон серых адресов - гораздо меньший чем диапазон белых.

Хочу натить их на Cisco ASR1000 так чтобы белые адреса в течении сессии у юзеров не менялись (иначе начинаются вопли что скачать с депозитов летитбитов и вконтактов подобных невозможно)

сейчас делаю так

рисую аксесс-лист для сетки которую надо занатить

ip access-list standard ISG-NET

permit 10.21.80.0 0.0.0.255

 

говорю натить ее пулом

ip nat inside source list ISG-NET pool NAT-NET-ISG overload

 

и описываю этот пул состоящим из одного ип-шника

ip nat pool NAT-NET-ISG wh.ite.ip.1 wh.ite.ip.1 netmask 255.255.255.128 type match-host

 

Вроде все работает - но все-тки гложат сомнения как правильней, ведь если натить крупные локальные диапазоны - можно совсем overload-нуться и не хватит портов, а если натить мелкие - то вырастает и конфиг и кол-во аксесс-листов (что наверно не лучшим способом сказывается на производительности)

Может есть изящный какой-нить другой способ, который, мы деревенские, в первый раз сиску увидевшие, не знаем? (типа из радиуса навешивать каким адресом натить, а? о_О)

Share this post


Link to post
Share on other sites

а если натить мелкие - то вырастает и конфиг и кол-во аксесс-листов (что наверно не лучшим способом сказывается на производительности)

Почему вы так решили? Не, ну конечно если у вас конфиг мегов 100 будет, то да

Share this post


Link to post
Share on other sites

ip nat pool EXT1 prefix-length 21

address 1.2.0.1 1.2.7.254

address 1.3.0.1 1.3.7.254

ip nat inside source list 5 pool EXT1

 

и все, в пределах ip nat translation timeout ничего меняться не будет.

 

но учтите большое число сессий приводит к крешу ESP :(

 

Share this post


Link to post
Share on other sites

Правильно - это не НАТить на цисках...

Share this post


Link to post
Share on other sites

Правильно - это не НАТить на цисках...

Целиком и полностью согласен!

Share this post


Link to post
Share on other sites

Уберите overload, получите желаемый результат и ощутимо меньшую нагрузку. В случае c overload у вас будет Port Address Translation на 1 IP, второй из пула начнет задействоваться только когда все порты будут исчерпаны, т.е. после ~65 тыс. соединений. С отключенным будет вариант "1 в 1", т.е. один серый IP транслируется в один белый IP.

 

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

 

Кстати в этом случае диапазон белых IP может быть значительно до 2-3 раз меньше общего кол-ва юзеров с серыми IP.

 

Вот пример даже нашел в бэкапах:

access-list 2 permit 172.16.0.0 0.0.255.255
ip nat translation timeout 180
ip nat pool GRAY-TO-WHITE-STATIC xx.xx.125.1 xx.xx.125.127 prefix-length 22
ip nat inside source list 2 pool GRAY-TO-WHITE-STATIC

 

Ну а потом смотрим sh ip nat stat и видим заметное уменьше кол-ва записей в таблице.

P.S. Все указанное справедливо для каталисты 6500, с ASR пока не довелось пообщаться.

Edited by SokolovS

Share this post


Link to post
Share on other sites
Правильно - это не НАТить на цисках...
Целиком и полностью согласен!

Тоже согласен, но на 5-8Г трафика писюковых рутеров уже не напасешься и именно поэтому от них перетекли на сиски

 

ip nat pool EXT1 prefix-length 21

address 1.2.0.1 1.2.7.254

address 1.3.0.1 1.3.7.254

ip nat inside source list 5 pool EXT1

 

и все, в пределах ip nat translation timeout ничего меняться не будет.

 

но учтите большое число сессий приводит к крешу ESP :(

Вначале так и было

Но через некоторое время пользователи стали жаловаться что у них постоянно меняется внешний адрес :(

 

Уберите overload, получите желаемый результат и ощутимо меньшую нагрузку. В случае c overload у вас будет Port Address Translation на 1 IP, второй из пула начнет задействоваться только когда все порты будут исчерпаны, т.е. после ~65 тыс. соединений. С отключенным будет вариант "1 в 1", т.е. один серый IP транслируется в один белый IP.
А разве в этом случае не может быть такой ситуации когда один "серый" может транслироваться для одного интернетовского ресурса как один "белый", а для другого ресурса - вторым "белым" ?

 

Кстати в этом случае диапазон белых IP может быть значительно до 2-3 раз меньше общего кол-ва юзеров с серыми IP.
К сожалению у меня белых ип еще меньше :(
Edited by SkyCaster

Share this post


Link to post
Share on other sites
А разве в этом случае не может быть такой ситуации когда один "серый" может транслироваться для одного интернетовского ресурса как один "белый", а для другого ресурса - вторым "белым" ?
Нет, в пределах таймаута это всегда будет один и тот же адрес, таймаут по дефолту 180 сек. А в общем случае при поддержании сетевой активности или при увеличенном таймауте, адрес всегда будет один и тот же.

 

Кстати в этом случае диапазон белых IP может быть значительно до 2-3 раз меньше общего кол-ва юзеров с серыми IP.
К сожалению у меня белых ип еще меньше :(

Нужно хотя бы 1/3 от кол-ва натящихся юзеров. И это заметно увеличивает производительность, т.к. таблица в сотни раз меньше.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this