Jump to content
Калькуляторы

создание сервера для маршрутизации 500 мегабит интернета

Здравствуйте. Вот стала задача создания такого сервера. Будет маршрутизировать 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 by adron2

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Шейпить на 300Мбит это наверное перебор... Полисинг не пойдет?..

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

 

Share this post


Link to post
Share on other sites
Здравствуйте. Вот стала задача создания такого сервера. Будет маршрутизировать 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 by photon

Share this post


Link to post
Share on other sites
Здравствуйте. Вот стала задача создания такого сервера. Будет маршрутизировать 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 смотрит. Надо же чемто траффик со всех вланов объединять, чтобы управлять исходящим траффиком на клиентов. Или я не прав?

 

 

Share this post


Link to post
Share on other sites
Ну руками потому что на каждый процессор тратится еще немного места в ядре.

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Ну руками потому что на каждый процессор тратится еще немного места в ядре.

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
adron - в u32 запихать фильтр на vlan.... mac же можно отфильтровать, значит по идее и влан тоже

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

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

Share this post


Link to post
Share on other sites

Никак не могу 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 by adron2

Share this post


Link to post
Share on other sites

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

 

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

 

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

 

Share this post


Link to post
Share on other sites
А зачем фильтровать по VLAN вообще?

 

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

 

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

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

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

Share this post


Link to post
Share on other sites
Никак не могу 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 by adron2

Share this post


Link to post
Share on other sites

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

Edited by photon

Share this post


Link to post
Share on other sites

adron2

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

 

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

 

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

Share this post


Link to post
Share on other sites
adron2

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

 

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

 

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

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

 

Share this post


Link to post
Share on other sites

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

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

Edited by photon

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this