76xx SUP720-3BXL NAT performance
Коллеги, добрый день, Не поделится ли кто собственным опытом на предмет того, сколько трафика (и какого характера) может от'NAT'ить 76xx с SUP720-3BXL ? С одной стороны оно вроде понятно, что NAT в этом случае получается hardware assisted (и, судя по цисковским докам, можно рассчитывать на up to 20Mpps), но с другой стороны сами цисковские инженеры пишут в cisco-nsp следующее : It depends on the exact configuration, but yes, we can do GRE encap/decap & NAT/PAT with hardware assist. For NAT, NAT xlation/session setup & teardown is done in software, the rest in hardware. Соответственно, насколько я понимаю, нагрузка на MSFC будет напрямую зависеть от того, сколько появляется новых и экспайрится старых трансляций в единицу времени (т.е. за 1 секунду). И в общем случае о 20Mpps мечтать не стоит :) Просто я сейчас смотрю на одну такую кошку, где поток трафика, проходящий через NAT - ~15Mbps, общее количество динамических трансляций - около 13k, в секунду появляется/экспайртися до 200-300 трансляций. При этом загрузка MSFC - в районе 45%. Соответственно, хочется понять - нормальный ли это cpu load для трафика такого характера или же что-то недотюнено. -- Andrey Elperin =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Sat, Feb 24, 2007 at 05:25:32PM +0200, Andrey Elperin wrote: Сударь, исходя из интуитивных предположений о задаче и примерной оценке траффика, могу сказать: на 80 мегабитах пролетающих сквозь пару PIX-525 в Active/Standby конфигурации, до критических значений еще _очень_ далеко. В конкретно Вашем случае может иметь смысл покрутить WS-SVC-FWM-1 для подобных целей. А по сути вопроса, очень похоже на правду. Можно попробовать собрать в лаборатории и проверить. SUP720-3BXL свободный есть, нужны более детальные данные по природе трафика дабы сконфигурировать тестер. p.s. Обсуждаемо в привате.
Коллеги, добрый день,
Не поделится ли кто собственным опытом на предмет того, сколько трафика (и какого характера) может от'NAT'ить 76xx с SUP720-3BXL ? С одной стороны оно вроде понятно, что NAT в этом случае получается hardware assisted (и, судя по цисковским докам, можно рассчитывать на up to 20Mpps), но с другой стороны сами цисковские инженеры пишут в cisco-nsp следующее :
It depends on the exact configuration, but yes, we can do GRE encap/decap & NAT/PAT with hardware assist. For NAT, NAT xlation/session setup & teardown is done in software, the rest in hardware.
Соответственно, насколько я понимаю, нагрузка на MSFC будет напрямую зависеть от того, сколько появляется новых и экспайрится старых трансляций в единицу времени (т.е. за 1 секунду). И в общем случае о 20Mpps мечтать не стоит :)
Просто я сейчас смотрю на одну такую кошку, где поток трафика, проходящий через NAT - ~15Mbps, общее количество динамических трансляций - около 13k, в секунду появляется/экспайртися до 200-300 трансляций. При этом загрузка MSFC - в районе 45%. Соответственно, хочется понять - нормальный ли это cpu load для трафика такого характера или же что-то недотюнено.
-- ZA-RIPE||ZA1-UANIC =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Добрый день! On Sat, Feb 24, 2007 at 05:25:32PM +0200, Andrey Elperin wrote:
Не поделится ли кто собственным опытом на предмет того, сколько трафика (и какого характера) может от'NAT'ить 76xx с SUP720-3BXL ? С одной стороны оно вроде понятно, что NAT в этом случае получается hardware assisted (и, судя по цисковским докам, можно рассчитывать на up to 20Mpps), но с другой стороны сами цисковские инженеры пишут в cisco-nsp следующее :
It depends on the exact configuration, but yes, we can do GRE encap/decap & NAT/PAT with hardware assist. For NAT, NAT xlation/session setup & teardown is done in software, the rest in hardware.
NAT на 6500/7600 в hardware делается средствами netflow cache со всеми вытекающими ограничениями: 256K TCAM entries и MSFC entry install. Само собой, при включенном "flow cache" netflow cache TCAM будет делится между nat и самим netflow. Тюнинг ageout для предотвращения переполнения netflow TCAM сильно ударит по CPU. Варианты разгрузки - DFC на линейных карточках каждая со своим netflow TCAM или FWSM с перспективой гонять весь трафик через shared bus. И то, и другое по своему плохо.
Соответственно, насколько я понимаю, нагрузка на MSFC будет напрямую зависеть от того, сколько появляется новых и экспайрится старых трансляций в единицу времени (т.е. за 1 секунду). И в общем случае о 20Mpps мечтать не стоит :)
Если все 20Mpps, да в одной сессии, да еще и в DFC - то без проблем. А для generic internet traffic в таких общемах и NAT нужно смотреть в более другую сторону. 7600/6500 совсем не для таких целей строились. P.S. А зачем, собственно, NAT? Не проще ли всем routable addresses раздать?
Просто я сейчас смотрю на одну такую кошку, где поток трафика, проходящий через NAT - ~15Mbps, общее количество динамических трансляций - около 13k, в секунду появляется/экспайртися до 200-300 трансляций. При этом загрузка MSFC - в районе 45%. Соответственно, хочется понять - нормальный ли это cpu load для трафика такого характера или же что-то недотюнено.
А SP CPU как поживает? -- Dmitry Kiselev =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hello Dmitry, Monday, February 26, 2007, 10:19:35 AM, you wrote:
Добрый день!
On Sat, Feb 24, 2007 at 05:25:32PM +0200, Andrey Elperin wrote:
Не поделится ли кто собственным опытом на предмет того, сколько трафика (и какого характера) может от'NAT'ить 76xx с SUP720-3BXL ? С одной стороны оно вроде понятно, что NAT в этом случае получается hardware assisted (и, судя по цисковским докам, можно рассчитывать на up to 20Mpps), но с другой стороны сами цисковские инженеры пишут в cisco-nsp следующее :
It depends on the exact configuration, but yes, we can do GRE encap/decap & NAT/PAT with hardware assist. For NAT, NAT xlation/session setup & teardown is done in software, the rest in hardware.
NAT на 6500/7600 в hardware делается средствами netflow cache со всеми вытекающими ограничениями: 256K TCAM entries и MSFC entry install. Само собой, при включенном "flow cache" netflow cache TCAM будет делится между nat и самим netflow. Тюнинг ageout для предотвращения переполнения netflow TCAM сильно ударит по CPU. а какая на сейчас утилизация TCAM?
Варианты разгрузки - DFC на линейных карточках каждая со своим netflow TCAM или FWSM с перспективой гонять весь трафик через shared bus. И то, и другое по своему плохо.
Соответственно, насколько я понимаю, нагрузка на MSFC будет напрямую зависеть от того, сколько появляется новых и экспайрится старых трансляций в единицу времени (т.е. за 1 секунду). И в общем случае о 20Mpps мечтать не стоит :)
Если все 20Mpps, да в одной сессии, да еще и в DFC - то без проблем. А для generic internet traffic в таких общемах и NAT нужно смотреть в более другую сторону. 7600/6500 совсем не для таких целей строились.
P.S. А зачем, собственно, NAT? Не проще ли всем routable addresses раздать?
Просто я сейчас смотрю на одну такую кошку, где поток трафика, проходящий через NAT - ~15Mbps, общее количество динамических трансляций - около 13k, в секунду появляется/экспайртися до 200-300 трансляций. При этом загрузка MSFC - в районе 45%. Соответственно, хочется понять - нормальный ли это cpu load для трафика такого характера или же что-то недотюнено.
А SP CPU как поживает?
-- Aikashev Evgeniy AEV-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Mon, Feb 26, 2007 at 10:19:35AM +0200, Dmitry Kiselev wrote: Добрый день,
It depends on the exact configuration, but yes, we can do GRE encap/decap & NAT/PAT with hardware assist. For NAT, NAT xlation/session setup & teardown is done in software, the rest in hardware.
NAT на 6500/7600 в hardware делается средствами netflow cache со всеми вытекающими ограничениями: 256K TCAM entries и MSFC entry install. Само собой, при включенном "flow cache" netflow cache TCAM будет делится между nat и самим netflow. Тюнинг ageout для предотвращения переполнения netflow TCAM сильно ударит по CPU.
В приницпе, я рассуждал аналогично, но до первого практического эксперимента мне все-таки казалось, что все будет выглядеть чуть оптимистичнее, чем оно выглядит на самом деле.
Варианты разгрузки - DFC на линейных карточках каждая со своим netflow TCAM или FWSM с перспективой гонять весь трафик через shared bus. И то, и другое по своему плохо.
Гм, ну сам FWSM - это CEF256-модуль, плюс циска утверждает, что в 12.2(18)SXF7 сняты все ограничения, которые раньше могли заставлять использовать fabric switching-mode force busmode. Так что на первый взгляд в случае FWSM все не так трагично.
Соответственно, насколько я понимаю, нагрузка на MSFC будет напрямую зависеть от того, сколько появляется новых и экспайрится старых трансляций в единицу времени (т.е. за 1 секунду). И в общем случае о 20Mpps мечтать не стоит :) Если все 20Mpps, да в одной сессии, да еще и в DFC - то без проблем. А для generic internet traffic в таких общемах и NAT нужно смотреть в более другую сторону. 7600/6500 совсем не для таких целей строились.
Это понятно, но отчего бы не попробовать, если железка есть ? :)
P.S. А зачем, собственно, NAT? Не проще ли всем routable addresses раздать?
Просто я сейчас смотрю на одну такую кошку, где поток трафика, проходящий через NAT - ~15Mbps, общее количество динамических трансляций - около 13k, в секунду появляется/экспайртися до 200-300 трансляций. При этом загрузка MSFC - в районе 45%. Соответственно, хочется понять - нормальный ли это cpu load для трафика такого характера или же что-то недотюнено. А SP CPU как поживает?
Ему гораздо проще - cpu load в районе 5%.
-- Dmitry Kiselev
-- Andrey Elperin =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Mon, Feb 26, 2007 at 11:00:16AM +0200, Evgeniy Aikashev wrote: Приветствую,
NAT на 6500/7600 в hardware делается средствами netflow cache со всеми вытекающими ограничениями: 256K TCAM entries и MSFC entry install. Само собой, при включенном "flow cache" netflow cache TCAM будет делится между nat и самим netflow. Тюнинг ageout для предотвращения переполнения netflow TCAM сильно ударит по CPU. а какая на сейчас утилизация TCAM?
На сейчас - 32%, но и трафик сейчас поменьше, чем был в момент написания первого письма. На тогда было где-то под 50%.
-- Aikashev Evgeniy AEV-RIPE
-- Andrey Elperin =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
On Mon, Feb 26, 2007 at 02:07:49AM +0200, Andrey Zarechansky wrote: День добрый,
исходя из интуитивных предположений о задаче и примерной оценке траффика, могу сказать: на 80 мегабитах пролетающих сквозь пару PIX-525 в Active/Standby
В случае пикса вопросов нет. Дикорастущий тазик с freebsd такой трафик тоже натит без особых проблем :)
конфигурации, до критических значений еще _очень_ далеко. В конкретно Вашем случае может иметь смысл покрутить WS-SVC-FWM-1 для подобных целей.
Да, именно в его сторону и думаем, спасибо.
А по сути вопроса, очень похоже на правду. Можно попробовать собрать в лаборатории и проверить. SUP720-3BXL свободный есть, нужны более детальные данные по природе трафика дабы сконфигурировать тестер.
Ухожу в приват :)
-- ZA-RIPE||ZA1-UANIC
-- Andrey Elperin =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
participants (4)
-
Andrey Elperin -
Andrey Zarechansky -
Dmitry Kiselev -
Evgeniy Aikashev