коммутация vs маршрутизация на коммутаторах L3

[znick]

Интересно знать, во сколько маршрутизация в L3-коммутаторах медленнее коммутации. Почему-то прямой информации об этом нигде нет :( Значит ли это что скорость маршрутизации идентична коммутации ? Или дело настолько плохи что об этом специально не пишут ?

 

Конкретно интересует dlinkовский DXS-3326GSR, представители D-Link-а - ответьте, если не трудно. В частности, как соотносится нагрузка при коммутации двух портов в одном вилане с маршрутизацией в случае когда порты на разных виланах. Где узкое место ?

[puh]

на цискокоме в даташитах втречаются следущие фразы: "The Catalyst <модель> switch provides non-blocking routing and switching for IP, IPX, and IP multicast"

[SergeiK]

Иногда пишу wirespeed L3 switching, что означает, что она должна выполнять маршрутизацию на любой скорости, которую позволяют провода.

 

На деле все сложнее. Реальная производительность зависит от очень многих параметров. Поэтому и не пишут.

Например, просвичить FTP с хоста на хост 1000Мбит/сек для свича намного проще, чем раскидать 100Мбитный вирусный flood по 10 тыс. IP адресов.

 

Однако, для не чрезмерно бюджетных свичей, типа 3326, скорость L3 достаточна для большинства возникающих задач.

[Прохожий]

Ну, коммутация L3 и маршрутизация все-таки немного разные вещи... Чтобы понять разницу - надо довольно глубоко закапываться в архитектуру свичей, а она тоже разная бывает.

 

Общий принцип простой: при "честной" маршрутизации идет принятие решения на базе таблицы маршрутов, при коммутации - создается что-то вроде таблиц MAC-адресов, только IP, и решение принимается по ним. Это значит, что некая деградация производительности может случиться при ОЧЕНЬ БОЛЬШОМ КОЛИЧЕСТВЕ IP АДРЕСОВ, что в реальной жизни фактически не встречается. В то же время последнее поколение свичей фактически всех производителей использует "честные" таблицы маршрутов, просто все реализовано в силиконе, потому работает с той же скоростью.

 

В общем: не заморачивайтесь. В реальной жизни Вы не почуствуете большой разницы, если у Вас сравнительно свежее оборудование.

 

Конкретно для Сиско - смотрите соответствующие таблицы скорости форвардинга. Там - правда в PPS, остальное - брехня.

[Я_рядом]

Прохожий, как всегда прав.

Механизм IP коммутации прост и до безобразия похож на стандартную Ethernet коммутацию, за исключением того что в таблице , на основании которой принимается решение на какой интерфейс отправляется пакет, хранятся не абсолютные значения адреса сети и ее маски, а результат выполнения HASH функции по SRC IP и DST IP.

В большинстве случаев, падение производительсности при L3 коммутации по сравнению c L2 коммутацией характерно для модульных устройств с выделенным модулем арбитража. Связанно это с тем, что именно на модулях арбитража обычно храняться результаты выполнения HASH функции. Соотвественно как минимум заголовок пакета, должен быть отправлен по шине коммутатора от интерфейсного модуля , на модуль арбитража для принятия решения о интерфейсе назначения пакета.

С помощью различных "костылей", пути перемещения заголовков пакетов, различными производителями сокращаются вплоть до условий принятия решения о интерфейсе назначения пакета на той интерфейсной плате , на которой он был принят в обработку (в результате получаем самые дорогие в индустрии интерфейсные модули коммутации).

Тем не менее различие в производительности да же в наихудшем случае скажеться только на пакетах малой длины характерных для критичных к исполнению приложений (VoIP, TVoIP ...). Станет это критичным, пожалуй, только в случае если обработка такого рода данных на коммутаторе будет отнимать более 40-60% производительности устройства. В результате может возрасти время обработки всех пакетов.

 

В случае рассмотрения бюджетный устройств фиксированной емкости, величиной деградации производительности L3 по сравнению с L2 коммутации можно пренебречь по понятным причинам.

[Lin_]

А подскажите, вот ACL на catalyst'ах сильно производительность понижает?

Скажем, если смотреть модель 3650G, на ней делать server-farm и этими ACL её прикрывать

[Я_рядом]

Lin_,

Вот ссылочка для Вас специально

http://www.networkworld.com/reviews/2002/0325rev.html

С Cisco 3560 хуже не стало, хотя вопрос в том какого рода ACL применять...

[Lin_]

Хм, конкретных цифирь я там что-то не увидел. На графиках тока роутинг и QoS...

"In addition to our basic throughput tests, we set up several ACL entries to see how the switch reacted to heavy network traffic loads.<...>The Catalyst 3550-24 showed no signs of performance degradation with an ACL enabled."

3560G весь из себя гигабитный и EMI. Хотелось бы порядка 200 extended правил src ip, dst ip, dst port

На сколько всё это дело притормозится?

[SergeiK]

Касаемы ACL - числа я не знаю, но даже в эказменах по CIT (troubleshooting) был вопрос, что будет при чрезмерном ACL - ответ - резкое падение производительности, ибо ACL в ЧИП не помещается, а игнорировать лишнии строки в ACL не позволяет логика и все идет через процессор.

 

Но зачем так много правил на сервер?!

Ставьте ACL не на ВЛАН а на порт и сократите их число до 30-50.

[Lin_]

Серверов там много, так что правило на порт ставить логично. Правил всего около 200, на несольких L3 vlan, на нескольких портах.

Ну короче понятно, надо пробовать (:

Да, ещё вопрос: на интерфейсе правило как ставить, in или out? Если по логике PC-роутера, то это in, мне так вроде понятнее, а какие-нить камни подводные есть??

[SergeiK]

Ставь и те и другие :).

Думаешь как коммутатор, то есть если пакет уходит с коммутатора, то out,

если приходит к нему, то in.

[Lin_]

А фильтры на ASIC-модулях или в проце? Ну т.е. in будет до роутинга, а out после, да? У меня есть книга "Конфигурирование маршрутизаторов Cisco", насколько изложенная там информация применима к свичам, книга 2001 года

[Я_рядом]

"Я конечно, не такой умный как Ваши инженеры, я открыл документацию...."

(с) Коллега(Тема общения с рассерженным руководством Заказчика)

Радует меня компания Cisco Systems подробным описанием чего и как она делает:

http://www.cisco.com/en/US/products/hw/swi....html#wp1326364

 

Hardware and Software Treatment of IP ACLs 

ACL processing is primarily accomplished in hardware, but requires forwarding of some traffic flows to the CPU for software processing. If the hardware reaches its capacity to store ACL configurations, packets are sent to the CPU for forwarding. The forwarding rate for software-forwarded traffic is substantially less than for hardware-forwarded traffic. 







--------------------------------------------------------------------------------



Note If an ACL configuration cannot be implemented in hardware due to an out-of-resource condition on a switch, then only the traffic in that VLAN arriving on that switch is affected (forwarded in software). Software forwarding of packets might adversely impact the performance of the switch, depending on the number of CPU cycles that this consumes. 





--------------------------------------------------------------------------------



For router ACLs, other factors can cause packets to be sent to the CPU: 



•Using the log keyword 



•Generating ICMP unreachable messages 



When traffic flows are both logged and forwarded, forwarding is done by hardware, but logging must be done by software. Because of the difference in packet handling capacity between hardware and software, if the sum of all flows being logged (both permitted flows and denied flows) is of great enough bandwidth, not all of the packets that are forwarded can be logged. 



If router ACL configuration cannot be applied in hardware, packets arriving in a VLAN that must be routed are routed in software, but are bridged in hardware. If ACLs cause large numbers of packets to be sent to the CPU, the switch performance can be negatively affected. 



When you enter the show ip access-lists privileged EXEC command, the match count displayed does not account for packets that are access controlled in hardware. Use the show access-lists hardware counters privileged EXEC command to obtain some basic hardware ACL statistics for switched and routed packets. 



Router ACLs function as follows: 



•The hardware controls permit and deny actions of standard and extended ACLs (input and output) for security access control. 



•If log has not been specified, the flows that match a deny statement in a security ACL are dropped by the hardware if ip unreachables is disabled. The flows matching a permit statement are switched in hardware. 



•Adding the log keyword to an ACE in a router ACL causes a copy of the

[Дятел]

а вопрос немного вбок.

имеем 3550, на ней делаем SVI-интерфейсы, на них терминим VLANы абонентские.

По описанию - 16 SVI.

Живьём имеем около 400....И всё работает.

В чем подвох? когда всё сдохнет?

[smsm]

около сотен двух было, никаких проблем, трафик очень плотный, тоже опасался. так и не понял в чем подвох.

[olebedev]

Он у Вас используется как агрегатор с одним линком наверх + маршрутизация между агрегируемыми VLAN'ами? Вообще это мало отличается от коммутации...

[Дятел]

практически...

но тогда в каких режимах вылазит это ограничение (16) ?

[_Daemon_]

Стоит AT-8948 и 25 виланов в режиме маршрутизации, около 1000 клиентов - полёт нормальный :)

[olebedev]

практически...

но тогда в каких режимах вылазит это ограничение (16) ?

 

Это ограничение вылазит, как я понимаю, когда вы начинаете его запрягать по полной BGP + PBR + vlan maps + QoS, а в простых решениях если он делает все аппаратно, то почему бы не работать то..

[znick]

Раз L3 коммутация использует таблицу, как и при L2 коммутации, то получается при активном серфинге в инете (где много разных ипов) эта таблица будет часто перегружаться и использоваться неэффективно.

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

[Гoсть]

L3 будет всегда медленнее L2 по определению. Любая инкапсуляция требует жертв.