Подскажите, пожалуйста, на каком этапе "tc filter" анализирует пакеты - до NAT'а, или после?Мне нужно шейпить трафик от клиентов, уходящий "в мир", на том же сервере, на котором пакеты NAT'ятся.
Сейчас это реализуется при помощи IPMARK: на файрволе пакеты маркируются, а затем "tc filter" направляет пакеты в соответствующие классы по этим маркам. Но меня перестает устраивать такой механизм - я хочу отказаться от IPMARK и использовать фильтр u32.
Но я почти уверен, что фильтр проверяет пакеты уже после NATа, и мне придется изобретать какой-нибудь геморрой, чтобы прошейпить исходящий "наружу" трафик...
>[оверквотинг удален]
>Мне нужно шейпить трафик от клиентов, уходящий "в мир", на том же
>сервере, на котором пакеты NAT'ятся.
>
>Сейчас это реализуется при помощи IPMARK: на файрволе пакеты маркируются, а затем
>"tc filter" направляет пакеты в соответствующие классы по этим маркам. Но
>меня перестает устраивать такой механизм - я хочу отказаться от IPMARK
>и использовать фильтр u32.
>
>Но я почти уверен, что фильтр проверяет пакеты уже после NATа, и
>мне придется изобретать какой-нибудь геморрой, чтобы прошейпить исходящий "наружу" трафик...исходящие пакеты классифицируются уже после всех преобразований, т.е.
непосредственно перед диспетчеризацией.
если fwmark не нравится по каким-либо идеологическим причинам, то можно
попробовать зацепится за другие метаданные пакета - например за tcindex,
т.е. маркировать их на входе при помощи dsmark & u32, а на выходе размещать
по очередям в зависимости от tcindex.
>исходящие пакеты классифицируются уже после всех преобразований, т.е.
>непосредственно перед диспетчеризацией.Т.е. после 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х байт будет достаточно).
>Не помнишь, случайно - какой длины (в байтах) может быть эта марка?Я уже нашел. 6 бит. Увы - мне мало :(
>>Не помнишь, случайно - какой длины (в байтах) может быть эта марка?
>
>Я уже нашел. 6 бит. Увы - мне мало :(ну я же не знал, что так много маркировок нужно.
- можно использовать tcindex (как раз 16бит)
- можно в конце-концов использовать комбинации маркеров, например dsmark+fwmark.
>>Не помнишь, случайно - какой длины (в байтах) может быть эта марка?
>
>Я уже нашел. 6 бит. Увы - мне мало :(есть способ зацепиться за tc_index, он как раз 32бита, я думаю, что должно хватить.
совершенно случайно его обнаружил, если интересно - пиши.
>>>Не помнишь, случайно - какой длины (в байтах) может быть эта марка?
>>
>>Я уже нашел. 6 бит. Увы - мне мало :(
>
>есть способ зацепиться за tc_index, он как раз 32бита, я думаю, что
>должно хватить.
>совершенно случайно его обнаружил, если интересно - пиши.Я сделал проще - вынес NAT на другую железку :)
Тем более, та железка была загружена максимум на 7-8%, и после добавления к ней NAT'а нагрузка практически не увеличилась...