Artyom Viklenko wrote: > 21.10.2011 22:03, Mykola Dzham пишет: > > Artyom Viklenko wrote: > >> 21.10.2011 19:29, Mykola Dzham пишет: > >>> Victor Sudakov wrote: > >>>> Понятно. Хотя странно при этом, что с неожиданным поведением в pf я пока > >>>> не столкнулся, а в ipfw таки да. > >>> > >>> Это вдвойне странно: нарваться на неожиданное поведение pf элементарно. > >>> Достаточно чтобы конфиг перерос определенный уровень. > >> > >> А определенный уровень это что? Сколько строк? > >> Возможно мне ни как не удавалось этого достичь, > >> но во всех случаях поведение pf было адекватно тому, > >> что я от него ожидал при написании соответствующего > >> набора правил... > > > > Ну попробуйте нарисовать набор правил и добиться адекватного поведения > > для простой задачи: > > cbq 1Mbit для трафика, который пришел через ext1 и уходит в int1 > > cbq 1Mbit для трафика, который пришел через int1 и уходит в ext1 > > cdq 10Mbit для трафика, который пришел через ext2 и уходит в int1 > > cbq 10Mbit для трафика, который пришел через inet1 и уходит в ext2 > > > > "cbq 1Mbit" - сферический конь в вакууме, IMHO. > С моей точки зрения задача поставлена не совсем корректно.
С моей точки зрения это придирки чистой воды. Мне нужно сделать симметричный шейп для трафика через int1, причем ext1<->int1 1Mbit , ext2<->int1 10Mbit. Так лучше? > С другой стороны, не вижу большой проблемы создать > две очереди на внутреннем интерфейсе - на 1 мбит и на 10, > по одной очереди на внешних. повесить теги на весь входящий > трафик и с учетом этих меток раскидать исходящий трафик по очередям > и интерфейсам. > > > И какой адекватности не получается достичь? А Вы попробуйте. tag требует keep state. Поэтому по нему создастся state, под которое "вдруг" начнут попадать исходящие пакеты. А их нам надо вообще то завернуть в правильный queue. Тут и начнётся "если соединение устанавливалось со стороны int1, то всё будет так, если со стороны ext1, то так". Про ситуации когда трафик через некоторое время ввиду изменения роутинга развернется с ext1 в ext2 можно вообще молчать. -- LEFT-(UANIC|RIPE) JID: [email protected] PGP fingerprint: 1BCD 7C80 2E04 7282 C944 B0E0 7E67 619E 4E72 9280
