Pull to refresh

Comments 18

Сергей, добрый день.
Я правильно из всего этого понял, что по факту роутинг во всех Cisco роутерах до ISR 4300 (то есть вся линейка ISR G2) осуществлялся «софтварно»?
Да, всё верно. Он и на ISR 4000 выполняется, можно сказать, программно. Просто там появляются дополнительные выделенные ядра под эту задачу (передачу и обработку пакетов). Вообще с появлением многоядерных процессоров, как мне кажется, «софтварная» обработка может давать очень приличную производительность. Главное чтобы ОС была правильно написана, позволяя эффективно обрабатывать пакеты и делая это в много поточном режиме.
Забавный факт: 3925E/3945E построены на натуральном Intel Xeon :)
Хорошая статья, с удовольствием почитал.
А как происходит взаимодействие control и data plane? ASR 1000 может быстро гнать трафик, но в режиме NAT, QOS, PBR, ACL etc. его производительность падает. Насколько я понимаю функции ACL можно зашить в ASIC (и кто то так и делает). Что насчет других функций? Трафик тогда отправляется на обычный процессор и там обрабатывается?
На ASR 1000 функции control plane выполняются на плате Route Processor (RP), а функции data plane на Embedded Services Processor (ESP). На RP у нас находится процессор общего назначения, а на ESP находится сетевой процессор QFP.

Связь между RP и ESP осуществляется через внутренние каналы связи, в частности через Ethernet out-of-band Control (EOBC). После того как RP просчитал всю необходимую информацию для обеспечения передачи трафика, эти данные через канал EOBC попадают на ESP, программируя его работу. Далее функции обработки и передачи пакета (NAT, QoS, routing, ACL и пр.) выполняются уже непосредственно на сетевом процессоре (для каждого пакета выделяется одно из его ядер). Т.е. практически все функции data plane реализуются на сетевом процессоре (кроме шифрования). А так как там очень много ядер, мы получаем параллельную обработку большого количества пакетов. Грубо говоря, имеем обычный маршрутизатор, только с очень большим количеством ядер.

Производительность действительно зависит от набора включённых сервисов.

Более детально с архитектурой ASR 1000 Вы можете ознакомиться, например, здесь.
Ну то есть, как уже и было сказано, архитектура ASR похожа на свич. ИМХО чем выше рангом железка тем меньше разницы между свичом и роутером. Яркий пример — 6500/7600 серия.

Но мне все равно не до конца ясно почему происходит такое падение производительности, если все функции в итоге обрабатываются аппаратно специализованной платой.
Падение производительности, видимо, связано с тем, что используется всё-таки сетевой процессор, а не ASIC с жёсткой логикой. Т.е. имеем по большому счёту программную обработку. А значит, чем больше операций нужно произвести над одним пакетом, тем меньше общая производительность. А вот на сколько меньше, уже зависит от качества кода ОС.
Ну у свитчевых ASICов тоже есть пределы производительности, вообще говоря. Просто в большинстве случаев их подбирают так, чтобы они могли работать на полной скорости. А так как функциональности у них минимум, то и подобрать сравнительно легко.

А вот при малейшем усложнении задачи начинаются вопросы — сравните QoS на ASR1K и на 6500, и ужаснитесь :)

И вообще, большие модульные свитчи типа 6500/6800 частенько могут оказываться oversubscribed в зависимости от конфигурации, вполне может быть и 2:1, и 4:1, и никто не удивляется )

На ASR же на самом деле всё не так плохо, стандартные NAT, PBR и QoS практически не влияют на производительность, особенно если IMIXом мерять, а не 64byte. И ISR 4K тоже это касается. По сравнению c ISR G2, умирающими чуть более чем полностью от какого-нибудь NAT NVI — прогресс налицо, и прогресс в нужную сторону.
На ASA'х тоже же все на центральном процессоре крутиться? Или для встроенного коммутатора там ASIC есть?
Да, всё верно. Data-plane (кроме шифрования) выполняется на том же процессоре общего назначения, где и control plane. Архитектура работы сходна с обычным маршрутизатором. В зависимости от модели мы имеем разное количество ядер. Что касается встроенного коммутатора (речь, видимо, про 5505), думаю там стоит самый простой ASIC, который никакой существенной логики не выполняет. Но это моё предположение, так как документа по архитектуре 5505 я не нашёл. Возможно, меня кто-то поправит.
Спасибо, хорошая статья. Интересно, куда всё это придет с учетом развития Интеловских x86. Свежее поколение, ЕМНИП, уже 22-ядерное, и это со взрослыми частотами. Догонють ведь рано или поздно все эти модные QFP! Хотя, скорее всего, high-end уровня ASR9K/старших MX в любом случае останется за специальными чипами, там тоже технологии не стоят на месте.

Кстати, не было ли у кого-нибудь опыта с CSR1000V/XRv9K/vRouter? Сколько Mpps ожидать можно? Обещают красиво, например Brocade заявляли line-rate 10G на одно x86 ядро. Звучит как-то слишком хорошо чтобы быть правдой :)
Согласен, современные процессоры (не только Intel) предоставляют очень серьёзные мощности. И для обычных устройств их достаточно. Более того прослеживается тенденция виртуализации всего и вся даже в рамках традиционных железок. Привязка к специализированному железу, видимо, останется только в high-end решениях и около них.

Есть опыт работы с CRS1000V и ASAv. Но по максимумам производительности дельного сказать ничего не смогу, так как нагрузка на них небольшая, а какое-то нагрузочное тестирование не проводили. Только цифры, которые предоставляет вендор.
Спасибо. Надеюсь, доберусь потестить производительность в обозримом будущем. Интересно, насколько будет влиять включение всяких манипуляций с траффиком. В производительность голой маршрутизации я вполне готов поверить, всё же Intel не зря наверное свой DPDK пилят который год уже. А вот что будет, если навесить хотя бы QoS с шейпером — вопрос, мне кажется, определяющий место этих решений среди железных собратьев )

Хотя, под облачные платформы без большой нагрузки в любом случае интересные штуки.
Ни куда не приведет. Текущих 2-4-х ядерный процессоров уже выше головы для контрол плейна. А от дата плейна любой проц довольно быстро умрет от прерываний даже с учетом пулинга. Без особых сервисов тестил csr1000v. Максимум что удалось выжать в качестве простой молотилки пакетов — 80 гигабит. Дальше все уперлось в процессор, а было всего-то 60 ядер… Но это мало кому нужно и будет дешевле купить железное решение в виде маршрутизатора для таких масштабов.
Спасибо за цифры, интересно. Но ведь не хай-эндом единым — 80G на краю энтерпрайзной сетки мало кому нужны, например. 10G и то далеко не всегда. И если искомые несколько Mpps укладываются в средней паршивости сервер, то почему бы и нет. А те, кому и этого не нужно, могли бы даже консолидировать с помощью виртуализации что-нибудь еще на то же железо.

Другое дело, что свитч не догнать в любом случае, а маршрутизатор хорош навороченным control-plane и сервисами. И если первое — скорее сильная сторона виртуализированных x86 решений, то второе может стать камнем преткновения. Так-то стареющий 3945Е на Xeone образца 2008 года тоже несколько Mpps может, только вот первый же ACL всё меняет радикально. А новые ISR4K даже придавили шейпером, чтобы этот эффект не был так заметен.
Действительно, влияние сервисов на производительность может быть неким «камнем предкновения» для CPU общего назначения.

Если я не ошибаюсь, в маршрутизаторах ISR G2 3900 для обработки трафика в работе используется только одно ядро. Хотя сам процессор является многоядерным. Обусловлено это тем, что обычный IOS может работать только в рамках одного потока. Видимо, из-за этого включение сервисов достаточно ощутимо влияет на производительность. Это справедливо для всей линейки ISR G2. Не уверен, что первый же ACL сильно сказывается на производительности (никогда не проверял), но то, что на неё хорошо влияет включение инспектирования трафика в рамках МСЭ или относительно хитрый QoS, это точно.

В ISR 4000 используется IOS XE, который позволяет обрабатывать трафик в много-поточном режиме. Плюс более современные процессоры. Плюс шейпер, который не даёт маршрутизатору захлёбываться по CPU. В итоге получается коробка с относительно прогнозируемой мощностью. Как мне кажется, достаточно правильный подход, чтобы нивелировать проблему с сервисами. Когда меняешь ISR G2 даже на стоимостный эквивалент ISR 4000, приятно удивляешься разнице в производительности.

Что касается «свитч не догнать в любом случае», тут вопрос спорный, так как производительность некоторых маршрутизаторов (можно посмотреть, например, на решение Cisco CRS) близка или даже превосходит производительность high-end коммутаторов. Правда, как было уже отмечено, грань между маршрутизатором и коммутатором в этих решениях стирается. Да и вообще, есть ли смысл сравнивать их производительности.

А для энтерпрайса, верно отмечено, далеко не всегда нужны какие-то огромные мощности. Да и консолидацию Cisco уже предлагает.
Полностью согласен, могу еще добавить, что про ACL на ISR G2 вот такое интересное исследование есть: https://supportforums.cisco.com/sites/default/files/cisco_1921_performance_test.pdf

Неофициальное, но выполнено на уровне.
Спасибо за документ. Интересные цифры. Я сам попробовал проверить влияние ACL на производительность. Однако у меня получилось не так драматично. Возможно сказался не самый лучший инструментарий, которым я это делал — iPerf.
Sign up to leave a comment.