Mikrotik аппаратное ускорение маршрутизации

Даже это будет совершенно не сопоставимо с "L3 маршрутизирующими коммутаторами" от других производителей! Они работают аналогично коммутированию, лишь с небольшой поддержкой от процессора. Шаблоны помещаются в TCAM, которые соответствуют полю IP-адреса назначения и отправляют пакет на правильный интерфейс, как это делает L2 коммутатор с MAC-адресом назначения и портом коммутатора. Обычно процессор выполняет один поиск в таблице маршрутизации, после чего вставляет нужный шаблон в TCAM, и другие пакеты к тому же назначению не затрагивают процессор. Это совершенно отличается от концепции CRS, которая фактически является просто коммутатором с поддержкой VLAN с прикрепленным к нему маршрутизатором. Медленный маршрутизатор, да, но замена его на более быстрый маршрутизатор все равно не делает его L3 коммутатором. Это потребовало бы вставки правил коммутирования в аппаратное обеспечение коммутатора в зависимости от реального трафика. Возможно, это осуществимо, учитывая, что можно вручную вставить правила коммутирования, которые совпадают с IP-адресом назначения, а затем перенаправить пакет на конкретный порт, но неясно, сможет ли аппаратное обеспечение также уменьшить TTL и пересчитать контрольную сумму заголовка после этого, и насколько это реально использовать в реальной ситуации маршрутизации L3. Ограниченное количество правил означало бы, что его можно использовать только для обработки пикового объема трафика в любом случае.

Что требует более дорогой кремний. MT не нужно разрабатывать его самостоятельно, есть коммерческий кремний, такой как Broadcom Qumran-UX, который прекрасно подошёл бы для полного L3 переключателя ‘CRS426’, но этот материал не из дешёвых. По крайней мере, не по сравнению с Marvell PresteraDX, которые они используют сейчас. Переключение на 10G L2 - это недорого. А вот настоящий маршрутизацию на 10G (читай 'проводная скорость или близко ко всем доступным портам') - это уже не так просто. Ещё.

Моя точка зрения (объясненная выше) заключается в том, что такие вещи не сводятся к "включению этой функциональности", что можно было бы интерпретировать как "установить какой-то бит во время инициализации, возможно, загрузить таблицу маршрутизации в чип". Скорее всего, это требует более сложного взаимодействия, при котором чип отправляет прерывание ЦП на первый пакет, который он получает для нового назначения, а затем ожидает, что ЦП запрограммирует какое-то правило сопоставления для обработки пакетов для этого назначения. После этого чип сможет самостоятельно маршрутизировать пакеты для этого назначения до тех пор, пока правило не будет удалено в рамках каких-то действий по обслуживанию. Но это означает, что вся функциональность маршрутизации, которая в настоящее время выполняется Linux, должна будет быть связана с этим взаимодействием чипа, и, конечно, это более сложно, чем просто поиск IP назначения в таблице маршрутизации, так как могут быть маршрутизация на основе политик с несколькими таблицами маршрутизации и правилами выбора. Так что это не то, что можно запрограммировать в дождливый день.

Я не прошу оRouting со скоростью проводов, просто хочу, чтобы они использовали то, что уже разработали.

CRS мог бы работать быстрее, просто имея такой же процессор, как у RB4011, как это уже делали раньше, вот в чем суть.