Здравствуйте, Serginio1, Вы писали:

S> Ты серьезно? Там поиск по хэштаблице.

Прекратите курить эти опилки, плохой дым получается. Никакие хэш-таблицы непригодны в принципе, потому, что поиск должен срабатывать по _неточному_ совпадению (базовый адрес плюс длина сети покрывает этот адрес) с наиболее длинным префиксом. Хэш-таблицы срабатывают только при полном совпадении.
Всякие AVL/RB/B-tree тоже не годятся, потому что может быть, что совпадает не тот, у кого ближайший базовый адрес, а тот, у кого сеть накрывает этот адрес.

Там Radix tree в бинарном варианте. При совпадении пары baseaddr+prefixlen у двух записей срабатывает метрика (меньше — важнее).
Бывает ещё больше параметров.

Поясняю на примере: пусть есть записи:

10.1.2.0/23 (то есть 10.1.2.0...10.1.3.255)
10.1.0.0/16 (то есть 10.1.0.0...10.1.255.255) с метрикой 10.
10.1.0.0/16 опять же, с метрикой 20.
10.0.0.0/8 (то есть 10.0.0.0...10.255.255.255)
10.1.3.0/27 (то есть 10.1.3.0...10.1.3.31)

Для 10.1.3.4 сработать должен 10.1.3.0/27, потому что у него самый длинный префикс.

Для 10.1.244.1 сработает 10.1.0.0/16 с метрикой 10, базовые адреса и длины префикса одинаковые, включается метрика.

(Метрика задаётся источником. Например 0 — directly connected, 1 — static, дальше идут в определённом порядке внутренние динамические протоколы, потом внешние.)