Исходное сообщение
"tc filter ... u32 match ip ..." Отправлено IVB, 01-Окт-08 18:38
>исходящие пакеты классифицируются уже после всех преобразований, т.е. >непосредственно перед диспетчеризацией. Т.е. после NAT. К сожалению, я не ошибался :( >если fwmark не нравится по каким-либо идеологическим причинам, Никакой идеологи - простая арифметика. Сейчас пакеты маркируются так: (последний байт из ip адреса) + 256 * (порядковый номер подсети в БД). Если учесть, что два старших бита в марке заняты под тип трафика (локальный/мировой) и направление (входящий/исходящий), то подсетей может быть всего 63. А мы хотим в ближайшем будущем подробить существующие сети, и их станет существенно больше 63 (и даже 255). Поэтому я и смотрю в сторону маркировки через u32 по ip адресу (источника или приемника в зависимости от направления трафика). >то можно >попробовать зацепится за другие метаданные пакета - например за tcindex, >т.е. маркировать их на входе при помощи dsmark & u32, а на >выходе размещать >по очередям в зависимости от tcindex. Т.е. маркировать посредством "tc qdisc ... dsmark ..." и набора "tc filter ... u32 ..." на входе (пока доступен src ip), а шейпить на выходе по этим маркам? ОК, нужно будет почитать подробнее про этот механизм... Не помнишь, случайно - какой длины (в байтах) может быть эта марка? Если всего 1 байт - то мне не хватит. Мне нужно, чтобы количество классов (т.е. уникальных марок) соответствовало количеству уникальных src ip - а их намного больше 255 (но меньше 65535, т.е. 2х байт будет достаточно).