Что прочитать о внутреннем устройстве программных сетевых маршрутизаторов?

iptables

https://www.opennet.ru/docs/RUS/iptables/ - как работает файрвол в Linux. Перевод старый, но во многом актуальный
Ну и заглянцевать чтением LARTC для понимания роутинга/шейпинга.

Ну а дальше можно начать спускаться к низкоуровневой анальщине вида кручения буферов отправки/приема на сетевухах, perf и прочая-прочая, что нужно знать далеко не всегда(но иногда без этого никак)

iptables то каким местом к маршрутизации. ТС хочет что-нибудь про ″route cache″ (routing exception), поиск MAC-адресов и т.д.

NAT? А тс сам не знает, чего хочет.

Ну и заглянцевать чтением LARTC для понимания роутинга/шейпинга.

Судя по вопросу, ТC хочет с этого начать, а не «глянцевать».
Ну и дал бы уж сразу ссылку: http://lartc.org/

Соменваюсь, что найдёте какой-нибудь обзор/сравнение. Ищите описание конкретных решений, допустим Linux Kernel Networking: Implementation and Theory, Rami Rosen

tcp/ip illustrated?

Оказалось, что у freertos нет маршрутизатора

Оказалось, что есть. См. FreeRTOS_IPInit(). А дальше в eARPGetCacheEntry, где происходит проверка с arp таблицей и согласно проверок условий подставляется ip шлюза или просто хоста. А вызывается это из, например, vProcessGeneratedUDPPacket. То есть приложение формирует пакет, а маршрутизатор участвует в формировании заголовка.

А как будет выглядеть маршрутизатор для ситуации, когда на интерфейс приходит пакет, а маршрутизатор решает куда его послать. Хранить пакеты как/где лучше, если озу 16-32 килобайт?

NAT? А тс сам не знает, чего хочет.

С больной головы на здоровую. Вот вопрос в наипростейшей форме - «Хачу зделать, запрограмировать, кароч, маршрутизацию для embedded устройства. Чо читать?»

Вообще удивительно, столько книг по глубокому устройству планировщика, файловых систем и практически 0 по устройству маршрутизаторов.

Хачу зделать, запрограмировать, кароч, маршрутизацию для embedded устройства. Чо читать?

Про маршрутизацию (точнее, IP-маршрутизацию) пишут вроде в любой книжке о сетях? Там идея очень простая: получили пакет, посмотрели в таблицу, отправили куда надо. Если нет в таблице - в маршрут по умолчанию. Без NAT не надо даже менять IP-заголовки (ну, почти, TTL нужно уменьшить).

Плюс специальным образом нужно обрабатывать широковещательные и многоадресные пакеты (про это есть у Стивенса, его уже посоветовали).

Вот реализации бывают сложные, вроде lc-trie.

происходит проверка с arp таблицей

Это уже не IP, то есть не совсем маршрутизация. ARP - уровень Ethernet. Ну-у, теоретически можно «маршрутизировать», просто изменяя Ethernet-заголовок (и опционально уменьшая TTL), но это будет как-то совсем по-хакирски

UPD: коряво выразился. Можно «маршрутизировать» так: получить пакет на одном интерфейсе, изменить его ethernet-заголовок и отправить с другого интерфейса. Но лучше сделать по-нормальному

Ох, забыл еще про IP-фрагментацию. Чертов склероз. Ну, надеюсь, ТС-у для начала это не понадобится

Но лучше сделать по-нормальному

В любом случае ethernet-заголовок будет изменен. Так что я не понимаю, что такое «по-нормальному».

что такое «по-нормальному»

По-нормальному это собрать из ethenet IP-пакеты (для IPv4 пакет может быть размером где-то до 64К, ethrnet frame как правило меньше), найти в таблице маршрутизации куда его нужно послать, уменьшить TTL, опять разбить на ethernet-фреймы и отправить в другой интерфейс, например.

На другом интерфейсе может быть другой MTU (или это вообще может быть не-ethernet интерфейс)

и отправить в другой интерфейс, например.

С каким mac-адресом отправить? Все эти объяснения маршрутизации для сисадминов, а не для системного программирования.

это вообще может быть не-ethernet интерфейс

С каким mac-адресом отправить?

Сдаюсь

подставляется ip шлюза или просто хоста.

Если ip адрес есть в arp таблице, то пакет посылается прямо ему, если нет, то посылается на ulGatewayAddress.

мак не меняется, вообще бросайте эту затею, у вас знаний ноль,и парой уроков гугления та не обойтись

Без конкретики это будет одна пустая болтовня и пересказы абзацев из книжек для сисадминов.

это вообще может быть не-ethernet интерфейс

mac есть не только в ethernet. hardware идентификаторы есть во множестве протоколов канального уровня, даже не скажу навскидку в каком их нет. Короче, я понял, вам просто поболтать захотелось.

мак не меняется

Ага, и пакет посылается на деревню дедушке. Еще один болтун.

исходники ядра Linux можно почитать

открывай ядро линукса или бсд или любой другой ОС, и читай, школьничек недоразвитый

пересказы абзацев из книжек для сисадминов.

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

Ага, и пакет посылается на деревню дедушке. Еще один болтун.

почитайте книжки для сисадминов) вообще говоря - да, теоретически пакет просто выплевывается в нужный интерфейс. Маки и прочие железные идентификаторы - это вообще не проблема маршрутизатора, он на сетевом уровне работает.

это вообще не проблема маршрутизатора, он на сетевом уровне работает.

Как все плохо

нет прям типовых реализаций

велосипеды

С каким mac-адресом отправить ?

При чём тут маршрутизация ? Пакет отправляется на следующий маршрутизатор, в соответствии с таблицей маршрутизации (IP-маршрутизации). А вот если так получается вдруг, что среда там ethernet, тогда начинает работать протокол arp, к маршрутизации отношения не имеющий, для определения соответствия MAC-IP и понимания, куда это послать.

А если там не ethernet, а 802.11, к примеру, то соответствие МАС-ІР не нужно или как?

Я о той штуке, например, правила для которой в linux устанавливаются программой route.

И да, как уже тут намекали, эта «штука» называется linux kernel. и ip (route и ifconfig давно устарели, сейчас используется iproute2), и iptables, и tc настраивают соответствующие подсистемы ядра linux.

А если там не ethernet, а 802.11, к примеру,

А если там Frame Relay ? Или PPP ? Так тоже бывает.

я имею ввиду, что не только для 802.3, но и для других стандартов, где arp используется. Мне для себя интересно тоже прояснить :)

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

Так я про другое. Исходный вопрос про маршрутизацию. И объяснение, как это работает, никак не связано с MAC-адресами. Эта часть задействуется только тогда, пакет уже отмаршрутизирован и попал на передачу в ту среду, где требуется работа с MAC-адресом.

И, в общем-то, в 802.11 не используется ARP - он выполняет роль транспорта для 802.3 и лежит, соответственно, под ним. 802.11 можно с проводом сравнить в какой-то мере, в данном случае.

И, в общем-то, в 802.11 не используется ARP - он транспорт для 802.3 и лежит, соответственно, под ним.

Спасибо, более углублённо посмотрю.

МАС появляется только в заголовке L2, маршрутизация происходит на L3, если я не путаю, поэтому, TC, логично:

Исходный вопрос про маршрутизацию. И объяснение, как это работает, никак не связано с MAC-адресами.

По-нормальному это собрать из ethenet IP-пакеты

Это имеет смысл, если маршрутизатор занимается фильтрацией. В ipv4 фрагментацию специально сделали так, чтобы любой фрагмент можно было, если нужно, фрагментировать и отправлять дальше не ожидая последующих. Чтобы маршрутизатор не требовал много памяти при дефрагментации большого потока данных.

никто так не делает. фрагментированные пакеты никто в здравом уме не будет собирать-разбирать - иначе роутер ложится от аналога slow lori (шлются 100500 начальных кусков пакетов, забивается вся память фрагментированными пакетами и роутер издыхает/начинает дропать валидные целые пакеты, которые не успели собраться).

и да, mtu - не проблема пока какой-то жопорук не зарезал icmp (см. path mtu discovery)

а с каким еще мак-адресом (источника) может уходить пакет, кроме адреса интерфейса? ессно, если не стоит цель сделать arp spoofing/arp poisoning?

мак-адрес получателя - он тоже однозначно определяется.

дополню - это имеет смысл только если маршрутизатор занимается DPI.

Это имеет смысл, если маршрутизатор занимается фильтрацией.

Да, вот щас внимательно перечитал ТС'а и увидел «16-32 килобайт». Согласен, с такими ограничениями лучше не усложнять.

Хотя, я в первом же ответе написал что можно просто менять Ethernet-заголовок (на самом деле придется менять еще и хвост c frame check sequence).

Ну, как только понадобится не только маршрутизировать, а хотя бы поддерживать UDP внутри железки, ему все равно придется собирать IP.

panzerito, вот тебе конкретная конкретика: получай mac-адрес следующего хопа по ARP (если адреса нет в кеше, посылай ARP-запрос и жди ответа, там будет mac-адрес), заменяй в ethernet-пакете который собираешься маршрутизировать mac-адреса источника и назначения, пересчитывай fcs и посылай то что получилось в другой интерфейс.

Это и будет что-то вроде маршрутизации. Если прочитать IP-заголовок, маршрутизировать по IP-адресам, игнорировать броадкасты и мультикасты, будет вообще серьезно, и без всяких сисадминских штучек

никто так не делает

Да-да, никто не делает, конечно

ps Оказалось, что у freertos нет маршрутизатора, tcpip стек есть, а маршрутизации нет. У contiki точно есть.

А где в uIP (contiki) маршрутизатор для IPv4?.. Ага, он там, похоже, называется forwarding: core/net/ipv4/uip-fw.c

примеры в студию маршрутизаторов, которые занимаются пересборкой пакетов из фрагментов.

примеры в студию маршрутизаторов, которые занимаются пересборкой пакетов из фрагментов.

Linux с conntrack? Ну, формально можно считать что это не совсем маршрутизация, но по факту практически все SOHO-маршрутизаторы с NAT на линуксе собирают пакеты из фрагментов.

А может быть и не только SOHO. И не только на линуксе. Некоторые Cisco тоже собирают фрагментированные пакеты (для NAT, IPSec и фильтрации): http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_frre/configuration/xe...

не собирают они ip пакеты :) попробуйте поматчить по строкам - будете сильно разочарованы.

и да, поставьте на одном интерфейсе мту 1000, на втором - 1500, к мту 1000 подключите клиента с мту 1000, мту 1500 выверните в мир и поднимите нат. и попробуйте куда-нибудь зайти :)

Покажите мне вывод ″iptables-save -c″, чтобы у правила:

iptables -I FORWARD -f 

и попробуйте куда-нибудь зайти :)

Попробуйте с клиента пингануть какой-нибудь сервер пакетами 1100 байт и посмотрите на сервере, какие туда приходят icmp-пакеты.

Что-то лень это пробовать. В NFLOG и NFQUEUE точно приходят целые собранные пакеты. Я пробовал разные размеры до 64К, пакет приходил не фрагментами а целиком.

Хотя, спорить тоже лень. Не собирают так не собирают. Получается, нагло врут что линуксоиды:

If you are doing connection tracking or NAT, then all fragments will get merged back together before they reach the packet filtering code, so you need never worry about fragments.

Что цисководы:

some features (such as NAT, Cisco IOS XE Firewall, IPSec) are unable to gather port information from the packet. These features may need to inspect the Layer 7 payload, for which the fragments need to be reassembled, and then refragmented later.

была целая книжка про ip стек в линукс, но там правда версия ядра в районе 2.2.

Попробуйте с клиента пингануть какой-нибудь сервер пакетами 1100 байт и посмотрите на сервере, какие туда приходят icmp-пакеты.

да никакие не придут. http://www.cisco.com/cisco/web/support/RU/9/92/92028_pmtud_ipfrag.html сценарий 3.

То есть вы не только iptables не знаете, но и tcp от icmp не отличаете?

cisco CEF

«Understanding Linux Network Internals» by Christian Benvenuti

насчет icmp не знаю, не интересовался как-то, но вот tcp - точно не пролазят. сталкивался с таким лично. да-да, именно для фикса этого используется --clamp-mss-to-pmtu в случае ната за туннелем с меньшим mtu. и нифига не пересобирается...

В случае tcp+pmtu у ip-пакетов выставлен флаг DF, их нельзя фрагментировать. Раз нет ip-фрагментации, то и пересобирать нечего.