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

сколько выдержит 3550 в режиме роутера? pps и трафик

Добрый день!

 

Поделитесь, пожалуйста, опытом - сколько прожует 3550 каталист на L3 на реальных IP и без acl?

 

Спасибо заранее!

Share this post


Link to post
Share on other sites

3550 - это свитч, поэтому прожует на wirespeed.

Share this post


Link to post
Share on other sites
3550 - это свитч, поэтому прожует на wirespeed.

 

:-) ну понятно - не вертолет. Суть вопроса вот в чем: на 3550 есть 2 гигабитных порта, что если каждый порт в своем влане и 3550 роутит трафик между ними - сколько вытянет железка? неужто целый гигабит?!

 

P.S.

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

Share this post


Link to post
Share on other sites

когда 3550 с 12х1Г портами - всё равно на скорости порта....

Share this post


Link to post
Share on other sites

Смотря что иметь в виду. В нем проц - 300 мгц. Если при роутинге он не затрагивается - все роутится на скорости порта. т.е. для 3550-24 роутится 24х100+2х1000 = 4400 мегабит. Для 3550-12G будет роутится 12 гигабит. Тонкость в том, что ИНОГДА для маршрутизации привлекается проц. Классика жанра - посылка ICPM Unreach. Происходит, когда маршрута к получателю нет в таблице роутинга или, что чаще, при посылке пакета в сегмент, непосредственно подключенный к этому свитчу на несуществующий ip. При это проц должен послать в этот сегмент ARP запрос, да не один раз, а три. И отработать таймауты. И послать ICMP Unreach отправителю. И вот когда некий козел или вирус начинает мощно сканировать все вркруг, то мы имеем 100% загрузку процессора на этой свичке. Есть лекарство no ip unreach, no ip redir на vlan интерфейсе. Есть другая проблема. Если в аппаратном кеше свички нет конкретной пары src ip - dst ip, то пакет уходит процессору, тот его роутит и добавляет запись в аппаратный кеш. И все аналогичные пакеты роутятся дальше аппаратно. при определенных условиях это может сильно напрячь проц свички. Бывают ситуации, когда аппаратный кеш переполняется. Это то-же сильно напрягает проц. А так, да. В установившемся режиме - роутит на скорости порта.

 

В конце концов, его можно тупо запинговать до смерти. На ~ 20-30 мегабит пингов он еще ответит. Потом загнется.

Share this post


Link to post
Share on other sites

В конце концов, его можно тупо запинговать до смерти. На ~ 20-30 мегабит пингов он еще ответит. Потом загнется.

От этого есть control-plane...

Share this post


Link to post
Share on other sites
Если в аппаратном кеше свички нет конкретной пары src ip - dst ip, то пакет уходит процессору

Нет в 3550 никакого аппаратного кеша src ip - dst-ip. Есть TCAM в который грузится FIB (таблица форвардинга). Размер места в TCAM под эту таблицу сильно ограничен, но может перераспределяться между unicast mac, igmp groups, qos, ACL,unicast routes, multicast routes с помощью sdp prefer.

И пока место под FIB в TCAM не кончилось, весь транзитный трафик будет роутится практически на wire-speed. А вот если кончится ( а по default там только 8K routes ) - тогда все сразу станет очень плохо.

 

А кеш src-dst ip - это было на cat6k sup1 и более древних железках.

 

Share this post


Link to post
Share on other sites
От этого есть control-plane...
Который ограничит так-же способность коммутатора принимать ARP и прочие _полезные_ вещи. Так что не совсем вариант.

 

Нет в 3550 никакого аппаратного кеша src ip - dst-ip. Есть TCAM в который
Да.да.да. Все так. Про кеш было написано для упрощения изложения. Никто в первом-втором классе не рассказывает про уравнения.

 

А кеш src-dst ip - это было на cat6k sup1 и более древних железках.
Зовется это On Demand Routing в том смысле, что первый пакет (on demand) роутится и в дельнейшем аппаратно кешируется. Сейчас у циски - да, все железо формирует FIB по типу CEFа и грузит его в TCAM, как всегда, сильно ограниченого объема в силу дороговизны. Не у Циски - http://forum.nag.ru/forum/index.php?showtopic=43517 все печально. Как оно устроено у Ежиков и прочих алькателей - не понятно.

Share this post


Link to post
Share on other sites
От этого есть control-plane...
Который ограничит так-же способность коммутатора принимать ARP и прочие _полезные_ вещи. Так что не совсем вариант.
А это уж как напишете. От ARP-флуда процессору тоже может поплохеть конкретно.

 

Share this post


Link to post
Share on other sites

вот и я о том. Ограничивать pps к процессору - это тупиковый путь.

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