evgeny
38c9f229bc
- u_async.c: process immediate_queue BEFORE epoll_wait in uasync_poll - stcp_link.c: defensive NULL etcp_conn/etcp_link in stcp_link_close - utun_instance.c: move stcp_server_list_destroy_all to Phase J (before ETCP), add deferred drain in both Phase J and L - stcp.h/c: STCP_HS_ENC_CLIENT 6→38, STCP_HS_ENC_SERVER 7→39, exchange ed25519_pubkey in both handshake directions - etcp_connections.c: copy peer_ed25519 from STCP to ETCP_CONN in etcp_link_enter_ready_tcp; guard link->etcp in tcp_link_close_cb - chat_sync.c: fix lk->conn NULL dereference for TCP links - test_stcp.c: update stcp_server_create/stcp_client_connect callsites - tools/chat_tcp_test: change transport udp→tcp
32 lines
3.0 KiB
Plaintext
32 lines
3.0 KiB
Plaintext
В таблице роутинга маршруты не пересекаются. Т.е. не может быть одновременно 192.168.1.1/24 и 192.168.1.100/30
|
|
|
|
Как работает роутинг:
|
|
1. типов маршрута бывает два: learned (роутятся в ETCP instance) и local (роутятся в TUN).
|
|
local - локальные маршруты из конфига (опция конфига my_subnet=IP/Mask)
|
|
при инициализации local сразу добавляются в роутинг таблицу (ипользуя запись BGP_NODEINFO_PACKET* my_nodeinfo).
|
|
|
|
BGP_NODEINFO собирается на узле владельце node, далее распространяется по остальным узлам.
|
|
|
|
2. При установке подключения к новому узлу мы отправляем этому узлу все nodeinfo. Если несколько доступных линков - отправляем только один - preferred_conn
|
|
3. При изменении preferred_conn рассылаем reroute (например старый preferred_conn удален)
|
|
3. При удалении всех подключений рассылаем withdraw.
|
|
|
|
3. При получении BGP_NODEINFO_PACKET мы смотрим есть ли такой узел уже в таблице. Если узла нет - добавляем, если есть - обновляем информацию о узле включая его маршруты и список next_hop через которые доступен узел (nb_routes).
|
|
Добавляем так:
|
|
инкрементируем hop_count
|
|
устанавливая etcp линк с которого приняли как next_hop, добавляем его в hop_list.
|
|
рассылаем по всем активным линкам кроме линка с которого получили (обязательно)
|
|
Обновление: обновляем hop_list если поменялся
|
|
|
|
4. При отключении от узла (если у node не осталось nb_routes) мы:
|
|
Удаляем node и вложенные структуры: все маршруты узла
|
|
Рассылаем withdraw для узла hop_id.
|
|
|
|
Логика рассылки withdraw:
|
|
Если получен withdraw - удаляем этот маршрут и распространяем withdraw или reroute по всем линкам кроме того с которого получили. В зависимости от изменений (остались ли резервные линки или изменился preferred_conn).
|
|
|
|
Метрик маршрута пока нет. используется первый доступный.
|
|
|
|
Как работаеут маршрутизация:
|
|
destination IP -> route table lookup -> route entry (ip/mask, node_info*) -> выбор лучшего next_hop -> отправка в next_hop
|