survivor Опубликовано 24 марта, 2010 · Жалоба Добрый день! Поделитесь, пожалуйста, опытом - сколько прожует 3550 каталист на L3 на реальных IP и без acl? Спасибо заранее! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 24 марта, 2010 · Жалоба 3550 - это свитч, поэтому прожует на wirespeed. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
survivor Опубликовано 24 марта, 2010 · Жалоба 3550 - это свитч, поэтому прожует на wirespeed. :-) ну понятно - не вертолет. Суть вопроса вот в чем: на 3550 есть 2 гигабитных порта, что если каждый порт в своем влане и 3550 роутит трафик между ними - сколько вытянет железка? неужто целый гигабит?! P.S. вопрос не по схеме сети, а по производительности конкретного оборудования... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дятел Опубликовано 24 марта, 2010 · Жалоба когда 3550 с 12х1Г портами - всё равно на скорости порта.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 24 марта, 2010 · Жалоба Смотря что иметь в виду. В нем проц - 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 мегабит пингов он еще ответит. Потом загнется. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 25 марта, 2010 · Жалоба В конце концов, его можно тупо запинговать до смерти. На ~ 20-30 мегабит пингов он еще ответит. Потом загнется. От этого есть control-plane... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
md77 Опубликовано 25 марта, 2010 · Жалоба Если в аппаратном кеше свички нет конкретной пары 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 и более древних железках. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 25 марта, 2010 · Жалоба От этого есть 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 все печально. Как оно устроено у Ежиков и прочих алькателей - не понятно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 25 марта, 2010 · Жалоба От этого есть control-plane... Который ограничит так-же способность коммутатора принимать ARP и прочие _полезные_ вещи. Так что не совсем вариант.А это уж как напишете. От ARP-флуда процессору тоже может поплохеть конкретно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 25 марта, 2010 · Жалоба вот и я о том. Ограничивать pps к процессору - это тупиковый путь. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...