[adron2]

Здравствуйте. Вот стала задача создания такого сервера. Будет маршрутизировать 500 мегабит. В перспективе до 800-900 мегабит интернета. Это гдето 300-400 kpps.

Задачи перед этим сервером следующие:

quagga bgpd. Принимать fullview от одного из аплинков.

Шейпинг.

Конфигурация сервера это:

Процессор Intel® Core™2 Quad CPU Q6600 @ 2.40GHz

2 гигабайта оперативной памяти.

Материнская плата intel dq35joe.

00:00.0 Host bridge: Intel Corporation 82Q35 Express DRAM Controller (rev 02)

00:02.0 VGA compatible controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02)

00:02.1 Display controller: Intel Corporation 82Q35 Express Integrated Graphics Controller (rev 02)

00:03.0 Communication controller: Intel Corporation 82Q35 Express MEI Controller (rev 02)

00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network Connection (rev 02)

00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 02)

00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02)

00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 02)

00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02)

00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 02)

00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 02)

00:1c.2 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 3 (rev 02)

00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 02)

00:1c.4 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 5 (rev 02)

00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02)

00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02)

00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02)

00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02)

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)

00:1f.0 ISA bridge: Intel Corporation 82801IO (ICH9DO) LPC Interface Controller (rev 02)

00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller (rev 02)

00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)

03:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6101 single-port PATA133 interface (rev b2)

 

В нем будет всего две сетевые карты Intel Pro/1000PT Server Adapter EXPI9400PT

 

Одна сетевая подключается к гиговому медиа конвертору и по ней и получается эти 500 мегабит интернета.

Другая сетевая втыкается в свитч zyxel es-2024. В гиговый порт.

Клиентов будет у этого сервака гдето 20 штук. От 20 до 300 мегабит на клиента.

Каждый клиент будет заводиться со свитча отдельным vlan-ом.

 

Нужно шейпить клиентов. Отсюда и вопрос. Какой qdisc использовать. htb? Не уложит ли он сервер при таких потоках?

Нужно чтобы на каждый класс траффика реализовать rate И ceil. То есть если один из клиентов(классов траффика) не выбирает свою полосу то она перетекает на других клиентов(другие классы).

Отсюда и вопрос что лучше применять для этого дела(ifb или imq)?

Ну и вопрос по фаерволу. В нем будет около 50 правил в цепочке forward. conntrack и nat соответственно использоваться вообще не будут. Стоит ли ради этого ставить ipset и выносить часть правил в него?

 

И еще вопрос по ядру.

Вот что включено:

CONFIG_SMP=y

CONFIG_NR_CPUS=4

CONFIG_SCHED_MC=y

CONFIG_HIGHMEM4G=y

CONFIG_HZ_1000=y

CONFIG_HZ=1000

CONFIG_SLUB=y

 

Для задач данного сервера нормально CONFIG_HZ_1000=y?

 

Заранее спасибо за ответы.

Edited August 13, 2009 by adron2

[SmokerMan]

Шейпить на 300Мбит это наверное перебор... Полисинг не пойдет?..

[adron2]

Шейпить на 300Мбит это наверное перебор... Полисинг не пойдет?..

очень желательно именно шейпить как я написал выше. То есть чтобы при неиспользовании части полосы одним из классов траффика эта полоса использовалась другими.

 

[photon]

Здравствуйте. Вот стала задача создания такого сервера. Будет маршрутизировать 500 мегабит. В перспективе до 800-900 мегабит интернета. Это гдето 300-400 kpps.

Задачи перед этим сервером следующие:

quagga bgpd. Принимать fullview от одного из аплинков.

Шейпинг.

Конфигурация сервера это:

Процессор Intel® Core2 Quad CPU Q6600 @ 2.40GHz

2 гигабайта оперативной памяти.

 

В нем будет всего две сетевые карты Intel Pro/1000PT Server Adapter EXPI9400PT

В принципе, потянет, но если делать надежно, то лучше поднять 2 таких машины.

 

Одна сетевая подключается к гиговому медиа конвертору и по ней и получается эти 500 мегабит интернета.

Другая сетевая втыкается в свитч zyxel es-2024. В гиговый порт.

Клиентов будет у этого сервака гдето 20 штук. От 20 до 300 мегабит на клиента.

Каждый клиент будет заводиться со свитча отдельным vlan-ом.

 

Нужно шейпить клиентов. Отсюда и вопрос. Какой qdisc использовать. htb? Не уложит ли он сервер при таких потоках?

У вас выбора фактически нет. Только HTB, а в качестве краевых qdisc -- pfifo. Другие классовые дисциплины (CBQ, HFSC) более сложны и ресурсоемки. Основную нагрузку создает не qdisc, а последовательный проход пакета по большому числу фильтров tc, которые направляют трафик в классы. У вас где-то 20 клиентов, но большой пакетрейт, поэтому следует подумать об использовании flow или u32 с хэширующими фильтрами.

 

Нужно чтобы на каждый класс траффика реализовать rate И ceil. То есть если один из клиентов(классов траффика) не выбирает свою полосу то она перетекает на других клиентов(другие классы).

Не вопрос. Указываете в параметрах краевого qdisc rate X ceil Y, и все будет.

 

Отсюда и вопрос что лучше применять для этого дела(ifb или imq)?

Псевдоустройства в данном случае не нужны, по моим наблюдениям многие применяют их там, где без них вполне можно обойтись. Нужно просто создать аналогичный набор правил на втором физическом интерфейсе.

 

Ну и вопрос по фаерволу. В нем будет около 50 правил в цепочке forward. conntrack и nat соответственно использоваться вообще не будут. Стоит ли ради этого ставить ipset и выносить часть правил в него?

ipset по любому будет нужен, чтобы более эффективно блокировать/разрешать IP-адреса клиентов.

 

И еще вопрос по ядру.

Вот что включено:

CONFIG_SMP=y

CONFIG_NR_CPUS=4

CONFIG_SCHED_MC=y

CONFIG_HIGHMEM4G=y

CONFIG_HZ_1000=y

CONFIG_HZ=1000

CONFIG_SLUB=y

 

Для задач данного сервера нормально CONFIG_HZ_1000=y?

А зачем руками ограничивать максимальное число процессоров CONFIG_NR_CPUS до 4? Оставьте 64 как было, их число все равно определяется при загрузке.

Edited August 13, 2009 by photon

[adron2]

Здравствуйте. Вот стала задача создания такого сервера. Будет маршрутизировать 500 мегабит. В перспективе до 800-900 мегабит интернета. Это гдето 300-400 kpps.

Задачи перед этим сервером следующие:

quagga bgpd. Принимать fullview от одного из аплинков.

Шейпинг.

Конфигурация сервера это:

Процессор Intel® Core™2 Quad CPU Q6600 @ 2.40GHz

2 гигабайта оперативной памяти.

 

В нем будет всего две сетевые карты Intel Pro/1000PT Server Adapter EXPI9400PT

В принципе, потянет, но если делать надежно, то лучше поднять 2 таких машины.

 

Одна сетевая подключается к гиговому медиа конвертору и по ней и получается эти 500 мегабит интернета.

Другая сетевая втыкается в свитч zyxel es-2024. В гиговый порт.

Клиентов будет у этого сервака гдето 20 штук. От 20 до 300 мегабит на клиента.

Каждый клиент будет заводиться со свитча отдельным vlan-ом.

 

Нужно шейпить клиентов. Отсюда и вопрос. Какой qdisc использовать. htb? Не уложит ли он сервер при таких потоках?

У вас выбора фактически нет. Только HTB, а в качестве краевых qdisc -- pfifo. Другие классовые дисциплины (CBQ, HFSC) более сложны и ресурсоемки. Основную нагрузку создает не qdisc а большое число фильтров, которые направляют трафик в классы. Следует подумать об использовании фильтра flow.

 

Нужно чтобы на каждый класс траффика реализовать rate И ceil. То есть если один из клиентов(классов траффика) не выбирает свою полосу то она перетекает на других клиентов(другие классы).

Не вопрос. Указываете в параметрах краевого qdisc rate X ceil Y, и все будет.

 

Отсюда и вопрос что лучше применять для этого дела(ifb или imq)?

Псевдоустройства в данном случае не нужны, нужно просто создать аналогичный набор правил на втором физическом интерфейсе. По моим наблюдениям многие применяют их там, где без них вполне можно обойтись.

 

Ну и вопрос по фаерволу. В нем будет около 50 правил в цепочке forward. conntrack и nat соответственно использоваться вообще не будут. Стоит ли ради этого ставить ipset и выносить часть правил в него?

ipset по любому будет нужен, чтобы более эффективно блокировать/разрешать IP-адреса клиентов.

 

И еще вопрос по ядру.

Вот что включено:

CONFIG_SMP=y

CONFIG_NR_CPUS=4

CONFIG_SCHED_MC=y

CONFIG_HIGHMEM4G=y

CONFIG_HZ_1000=y

CONFIG_HZ=1000

CONFIG_SLUB=y

 

Для задач данного сервера нормально CONFIG_HZ_1000=y?

А зачем руками ограничивать максимальное число процессоров CONFIG_NR_CPUS до 4? Оставьте как есть, их число все равно определяется при загрузке?

Ну руками потому что на каждый процессор тратится еще немного места в ядре.

А как же без псевдоустройств?

Ведь у меня на каждого клиента vlan смотрит. Надо же чемто траффик со всех вланов объединять, чтобы управлять исходящим траффиком на клиентов. Или я не прав?

 

 

[photon]

Ну руками потому что на каждый процессор тратится еще немного места в ядре.

А как же без псевдоустройств?

Ведь у меня на каждого клиента vlan смотрит. Надо же чемто траффик со всех вланов объединять, чтобы управлять исходящим траффиком на клиентов. Или я не прав?

Ну не говорите, что вам жалко каких-то десятков или сотен килобайт kernel memory при 2 Гб оперативки. А если потом систему придется переносить на 8-процессорную машину? Объединять трафик руками не надо, т.к. управление исходящим трафиком можно делать уже после bridging и routing на физическом интерфейсе. У вас два интерфейса, так что любой трафик можно обрабатывать как исходящий.

Edited August 13, 2009 by photon

[nuclearcat]

В HTB максимум 550 Mbps, дальше дикая погрешность. Связано с переполнением счетчиков. Обещались починить в сл. версии ядра... незнаю, уже или еще нет...

[martin74]

http://www.wasm.ru/article.php?article=onebyte

 

Только не уверен, что это окажет какое то влияение на маршрутизацию 500 мбит....

[adron2]

Ну руками потому что на каждый процессор тратится еще немного места в ядре.

А как же без псевдоустройств?

Ведь у меня на каждого клиента vlan смотрит. Надо же чемто траффик со всех вланов объединять, чтобы управлять исходящим траффиком на клиентов. Или я не прав?

Ну не говорите, что вам жалко каких-то десятков или сотен килобайт kernel memory при 2 Гб оперативки. А если потом систему придется переносить на 8-процессорную машину? Объединять трафик руками не надо, т.к. управление исходящим трафиком можно делать уже после bridging и routing на физическом интерфейсе. У вас два интерфейса, так что любой трафик можно обрабатывать как исходящий.

что то я не совсем понимаю как построить фильтр скажем на eth1 для траффика если он(траффик) содержит различные тэги vlan. Он его просто не увидит.

[nuclearcat]

adron - в u32 запихать фильтр на vlan.... mac же можно отфильтровать, значит по идее и влан тоже

[adron2]

adron - в u32 запихать фильтр на vlan.... mac же можно отфильтровать, значит по идее и влан тоже

вы прям читаете мои мысли. Вот сейчас сижу читаю ваш пример http://www.nuclearcat.com/mediawiki/index....U32_tips_tricks

И как раз идея тоже появилась что просто брать и фильтровать по номеру vlan-а траффик.

[adron2]

Никак не могу u32 фильтр создать так чтобы хотябы хватать вланеный траффик не говоря уже о его разборе на vlan tag.

Если скажем я хочу фльтром схватить все что ethernet ipv4 то это

tc filter add dev eth0 protocol all parent 1:0 prio 1 u32 ht 800:: match u16 0x0800 0xffff at -2 flowid 1:1

Тут все ясно.

Но тогда для вланового траффика:

tc filter add dev eth0 protocol all parent 1:0 prio 1 u32 ht 800:: match u16 0x8100 0xffff at -6 flowid 1:1

Но не один пакет в такой фильтр не попадает хотя траффик идет. Tcpdump показывает

22:44:07.644796 00:19:d1:e6:89:b7 > 00:0c:42:2f:3b:56, ethertype 802.1Q (0x8100), length 1518: vlan 111, p 0, ethertype IPv4, (tos 0x0, ttl 127, id 10774, offset 0, flags [none], proto UDP (17), length 1500)

10.254.2.77.2260 > 1.1.1.1.2004: UDP, length 1472

В чем моя ошибка?

Edited August 13, 2009 by adron2

[vitalyb]

А зачем фильтровать по VLAN вообще?

 

Создайте vconfig'ом нужные виланы и воткните их в бридж - не бриджевом интерфейсе и шейпите. Это проще, понятнее, наверняка и быстрее чем через ifb и imq. Если хотите изолировать абонентов друг от друга - ebtables к Вашим услугам.

 

Касательно нагрузки, мегабит, думаю, 700 потянет, но "без запаса" - если кто-то надумает послать "много мелких пакетов" одному из клиентов, железке станет очень плохо, поэтому сразу подумайте как будете ограничивать мелкие pps с обоих краев маршрутизатора.

 

[adron2]

А зачем фильтровать по VLAN вообще?

 

Создайте vconfig'ом нужные виланы и воткните их в бридж - не бриджевом интерфейсе и шейпите. Это проще, понятнее, наверняка и быстрее чем через ifb и imq. Если хотите изолировать абонентов друг от друга - ebtables к Вашим услугам.

 

Касательно нагрузки, мегабит, думаю, 700 потянет, но "без запаса" - если кто-то надумает послать "много мелких пакетов" одному из клиентов, железке станет очень плохо, поэтому сразу подумайте как будете ограничивать мелкие pps с обоих краев маршрутизатора.

спасибо за ответы.

По вланам удобней шейпить так как неизвестно какие префиксы клиент может заанонсить на мой бгп. А так просто по тегу влана шейпер поставил и все. А бридж и ebtables это уже лишняя нагрузка на систему. Не хочется. Уж больно идея с фильтрами по тегу влана красивая.

[adron2]

Никак не могу u32 фильтр создать так чтобы хотябы хватать вланеный траффик не говоря уже о его разборе на vlan tag.

Если скажем я хочу фльтром схватить все что ethernet ipv4 то это

tc filter add dev eth0 protocol all parent 1:0 prio 1 u32 ht 800:: match u16 0x0800 0xffff at -2 flowid 1:1

Тут все ясно.

Но тогда для вланового траффика:

tc filter add dev eth0 protocol all parent 1:0 prio 1 u32 ht 800:: match u16 0x8100 0xffff at -6 flowid 1:1

Но не один пакет в такой фильтр не попадает хотя траффик идет. Tcpdump показывает

22:44:07.644796 00:19:d1:e6:89:b7 > 00:0c:42:2f:3b:56, ethertype 802.1Q (0x8100), length 1518: vlan 111, p 0, ethertype IPv4, (tos 0x0, ttl 127, id 10774, offset 0, flags [none], proto UDP (17), length 1500)

10.254.2.77.2260 > 1.1.1.1.2004: UDP, length 1472

В чем моя ошибка?

сам себе отвечаю.

Итак

ethernet пакет состоит из

Destination MAC address -- 6 байт

Source MAC address -- 6 байт

Type/Length -- 2 байта

 

Type/Length===0x0800 если это обычный не тегирированный ethernet пакет с данными

Type/Length===0x8100 если это тегирированный пакет. И если он тегирированный то после Type/Length добавляется еще 4 байта так называемый VLAN Tag

Так вот я сначала пытался зацепиться за Type/Length при помощи tc filter

Если пакет не тегирированный то

tc filter add dev eth0 protocol all parent 1:0 prio 1 u32 ht 800:: match u16 0x0800 0xffff at -2 flowid 1:1 видит пакеты

А если тегирированный то попытки зацепиться за 0x8100 чем то типа tc filter add dev eth0 protocol all parent 1:0 prio 1 u32 ht 800:: match u16 0x8100 0xffff at -6 flowid 1:1 не к чему не приводят.

Я начал копать дальше.

tcpdump -i eth0 -n 'ether[11:1]=0xb7 and ether [12:1]=0x08 and ether[13:1]=0x0

где 0xb7 это последний октет 00:19:d1:e6:89:b7

Пакеты видно. Причем если tcpdump попросить сделать дамп траффика в файл то там прекрасно видно наши 0x8100. Но вот если Этот 12 байт попытаться зацепить тем же tcpdumpОм

tcpdump -i eth0 -n 'ether[11:1]=0xb7 and ether [12:1]=0x81 and ether[13:1]=0x0 то ничего не происходит. Нету пакетов.

 

Я начал дальше искать.

Итак кусочек пакета:

00 19 d1 e6 89 b7 81 00 00 ef 08 00 45

|----мак---------|

6 Байт

 

И дальше получаем

tcpdump -i eth0 -n 'ether[11:1]=0xb7 and ether [12:1]=0x08 and ether[13:1]=0x0 and ether[14:1]=0x45

пакеты видно. Но ведь 08 00 45 это уже 16, 17 и 18 байты а не 12,13,14

 

Отсюда делаем вывод что Type/Length 0x8100 ядро просто вырезает и в фильтры не tcpdumpа не tc filter не попадает.

Вывод такой что нельзя с помощью tc filter классифицировать тегирированный траффик так как ядро просто вырезает этот заголовок и заменяет 0x8100 на 0x0800

Edited August 14, 2009 by adron2

[photon]

С помощью ebtables можно настроить маркировку пакетов на основе vlan tag, и в tc фильтровать уже по этим меткам (фильтр fw). А зачем все эти сложности и двойная бухгалтерия с вланами, если можно классифицировать юзеров просто по IP? Безотносительно к вашей задаче, я так думаю, что технология VLAN -- это, по большому счету, недоразвитый layer 3 для бедных, который только вносит неразбериху в модель сетевого взаимодействия. Чем меньше будет завязано на VLAN, тем проще будет поддерживать.

Edited August 14, 2009 by photon

[nuclearcat]

ebtables жрут проц

[vitalyb]

adron2

Наличие бгп с клиентами существенно усложняет задачу. И ipset тут не подойдет потому, что нельзя одной строкой по IP выставить MARK, и tc не умеет по MARK'у хешировать, а 20 фильров в tc и 20 match'ей в iptables - это очень много.

 

Я бы так тогда сделал... Или полез в ядро на предмет написать какой-нибудь модуль под задачу, или шейпил бы на каждом вилановом интерфейсе tbf, а rate ему менял скриптом через tc change. Скрипт запускается раз в митуту, смотрит у кого какая утилизация и обновляет полосы. Такую схему пришлось один раз использовать, но обновлялись ceil ~50 классов в htb. Нормально работало...

 

Кстати, можно не по вилану, а по маку пира смотреть еще. Или по своему маку, если на каждого пира на его вилане установить уникальный мак. Но это всё некрасиво.

[adron2]

adron2

Наличие бгп с клиентами существенно усложняет задачу. И ipset тут не подойдет потому, что нельзя одной строкой по IP выставить MARK, и tc не умеет по MARK'у хешировать, а 20 фильров в tc и 20 match'ей в iptables - это очень много.

 

Я бы так тогда сделал... Или полез в ядро на предмет написать какой-нибудь модуль под задачу, или шейпил бы на каждом вилановом интерфейсе tbf, а rate ему менял скриптом через tc change. Скрипт запускается раз в митуту, смотрит у кого какая утилизация и обновляет полосы. Такую схему пришлось один раз использовать, но обновлялись ceil ~50 классов в htb. Нормально работало...

 

Кстати, можно не по вилану, а по маку пира смотреть еще. Или по своему маку, если на каждого пира на его вилане установить уникальный мак. Но это всё некрасиво.

Ну почему же. Как раз идея с тем что на каждый влан поставить уникальный мак и по нему шейпить мне очень понравилась. Спасибо за подсказку :)

 

[photon]

Ну почему же. Как раз идея с тем что на каждый влан поставить уникальный мак и по нему шейпить мне очень понравилась. Спасибо за подсказку :)

Я не понимаю, как вы собираетесь классифицировать трафик в обоих направлениях по макам, если шейпинг исходящего трафика будет делаться на внешнем интерфейсе. Маки вланов появляются только во фреймах на внутреннем интерфейсе, а на внешнем будут только его мак и мак вашего upstream-провайдера. Классификация по IP -- это уже избитая и разработанная тема, зачем же придумывать себе лишние проблемы и классифицировать не пойми по чему? Кстати говоря, tc таки умеет классифицировать по MARK одним правилом, см. http://www.netfilter.org/projects/patch-o-...external-IPMARK Однако, для ebtables вроде бы нет модуля аналогичного IPMARK.

Edited August 15, 2009 by photon