[SkyCaster]

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

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

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

Хочу натить их на 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-нуться и не хватит портов, а если натить мелкие - то вырастает и конфиг и кол-во аксесс-листов (что наверно не лучшим способом сказывается на производительности)

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

[terrible]

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

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

[XeonVs]

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 :(

 

[UglyAdmin]

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

[XeonVs]

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

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

[SokolovS]

Уберите 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 пока не довелось пообщаться.

Изменено 30 мая, 2010 пользователем SokolovS

[SkyCaster]

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

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

Тоже согласен, но на 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.

К сожалению у меня белых ип еще меньше :(

Изменено 1 июня, 2010 пользователем SkyCaster

[SokolovS]

А разве в этом случае не может быть такой ситуации когда один "серый" может транслироваться для одного интернетовского ресурса как один "белый", а для другого ресурса - вторым "белым" ?

Нет, в пределах таймаута это всегда будет один и тот же адрес, таймаут по дефолту 180 сек. А в общем случае при поддержании сетевой активности или при увеличенном таймауте, адрес всегда будет один и тот же.

 

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

К сожалению у меня белых ип еще меньше :(

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