1. Ось для бордера

[telecom]

не надо играться с бурстами, квантами и прочим чтобы добиться хотя бы мало-мальски сносного поведения при колебаниях полос от 1 до 100 Мбит.

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

[zlolotus]

 

Ого, это он у Вас 2.5 гигабита гоняет?? А сетевые какие и сколько если не тайна?

 

 

Сетевых карт - 2 шт по 2 головы .

igb0@pci0:2:0:0:	class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00
   vendor     = 'Intel Corporation'
   class      = network
   subclass   = ethernet
igb1@pci0:2:0:1:	class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00
   vendor     = 'Intel Corporation'
   class      = network
   subclass   = ethernet
igb2@pci0:3:0:0:	class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00
   vendor     = 'Intel Corporation'
   class      = network
   subclass   = ethernet
igb3@pci0:3:0:1:	class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01 hdr=0x00
   vendor     = 'Intel Corporation'
   class      = network
   subclass   = ethernet

 

Пока без агрегации.

 

 

quagga?

драйвера штатные? или с сайта?

можно посмотреть sysctl.conf и /boot/loader.conf??

я так понимаю, два процессора?

Изменено 3 января, 2012 пользователем zlolotus

[catalist]

не надо играться с бурстами, квантами и прочим чтобы добиться хотя бы мало-мальски сносного поведения при колебаниях полос от 1 до 100 Мбит.

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

А не огласите формулу?

[andriyj]

quagga?

драйвера штатные? или с сайта?

можно посмотреть sysctl.conf и /boot/loader.conf??

я так понимаю, два процессора?

 

1. quagga

2. Драйвера штатные:

dev.igb.0.%desc: Intel(R) PRO/1000 Network Connection version - 2.0.7
dev.igb.0.%driver: igb
dev.igb.0.%location: slot=0 function=0
dev.igb.0.%pnpinfo: vendor=0x8086 device=0x10c9 subvendor=0x8086 subdevice=0xa03c class=0x020000

3

sysctl.conf

dev.igb.0.rx_processing_limit=4096
dev.igb.1.rx_processing_limit=4096
dev.igb.2.rx_processing_limit=4096
dev.igb.3.rx_processing_limit=4096

kern.ipc.nmbclusters=400000
kern.ipc.maxsockbuf=83886080
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
net.inet.icmp.drop_redirect=1
net.inet.icmp.maskrepl=0
net.inet.icmp.icmplim=100
kern.ipc.maxsockets=204800

loader.conf

 

hw.igb.rxd=4096
hw.igb.txd=4096
hw.igb.rx_process_limit=2048
hw.igb.num_queues=4
hw.igb.max_interrupt_rate=32000

4

FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs
FreeBSD/SMP: 1 package(s) x 6 core(s) x 2 SMT threads

Изменено 6 января, 2012 пользователем andriyj

[sirmax]

коллеги, кто то поделиться примерчиком для hfsc?

А заодно может кто то знает замену ESFQ?

[NiTr0]

А заодно может кто то знает замену ESFQ?

SFB же.

[telecom]

А заодно может кто то знает замену ESFQ?

SFB же.

 

Это чисто теоретически, или у Вас есть реальный опыт использования SFB в боевых условиях?)

Изменено 11 января, 2012 пользователем telecom

[telecom]

А заодно может кто то знает замену ESFQ?

А чем ESFQ не угодила???

[NiTr0]

Это чисто теоретически, или у Вас есть реальный опыт использования SFB в боевых условиях?)

Пока опыта нет, проапдейчу дистр на бордюрах - поэкспериментирую.

 

А чем ESFQ не угодила???

Может, отсутствием патчей для свежих ядер?

[Alex/AT]

Кстати да - очень интересен опыт с SFB. Почитал статьи, с виду ну прямо таки silver bullet :)

Скоро буду заниматься - попробую впилить в центосовское 2.6.32, кто знает, может оно s/b и есть.

Изменено 12 января, 2012 пользователем Alex/AT

[telecom]

А чем ESFQ не угодила???

Может, отсутствием патчей для свежих ядер?

Вроде с этим проблем нет. 3.1.6 видел патч

Изменено 12 января, 2012 пользователем telecom

[photon]

SFB -- это реализация алгоритма, предотвращающего переполнение очереди (аналогично RED). Это не аналог ESFQ т.к. она не позволяет задавать признак, по которому строится хэш для fair queueing (IP-адрес, номер порта). Заменой ESFQ можно считать дисциплину DRR:

http://www.linuxhowtos.org/manpages/8/tc-drr.htm

 

Возвращаясь к исходной теме. Порадовал устойчивый 0% у OpenBSD.

Изменено 13 января, 2012 пользователем photon

[telecom]

SFB -- это реализация алгоритма, предотвращающего переполнение очереди (аналогично RED). Это не аналог ESFQ т.к. она не позволяет задавать признак, по которому строится хэш для fair queueing (IP-адрес, номер порта). Заменой ESFQ можно считать дисциплину DRR:

http://www.linuxhowtos.org/manpages/8/tc-drr.htm

Повторюсь, это теория или есть практический опыт использования?)

[photon]

Повторюсь, это теория или есть практический опыт использования?)

А мне незачем было использовать, я сторонник простых решений: каждому по фиксированной полосе в обе стороны, и делай с ней что хочешь. По ссылке есть готовый пример правил для DRR. SFB имеет смысл на загруженном канале, когда суммарная полоса, используемая юзерами, уже подходит к потолку внешнего канала. Это не замена ESFQ для fair queueing, а всего лишь продвинутый и более простой в использовании аналог RED:

http://en.wikipedia.org/wiki/Blue_%28queue_management_algorithm%29

http://www.pps.jussieu.fr/~jch/software/sfb/

Изменено 14 января, 2012 пользователем photon

[NiTr0]

Это не аналог ESFQ т.к. она не позволяет задавать признак, по которому строится хэш для fair queueing (IP-адрес, номер порта).

Странно, но в доке указывается обратное:

Depending how it is configured, SFB can treat each flow (TCP connection) as an aggregate, or all traffic destined to a given IP address as an aggregate, etc.

[photon]

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

It is not clear how well this translates into fairness in throughput between flows, notably with varying RTT and different implementations of congestion control.

[zlolotus]

[

4

FreeBSD/SMP: Multiprocessor System Detected: 12 CPUs
FreeBSD/SMP: 1 package(s) x 6 core(s) x 2 SMT threads

 

Гипертрэйдинг включен или выключен?

[andriyj]

Гипертрэйдинг включен или выключен?

Включен

[zlolotus]

Гипертрэйдинг включен или выключен?

Включен

 

uptime какой?

 

top -SPH

[andriyj]

uptime какой?

 

top -SPH

Все описал тут

Изменено 21 января, 2012 пользователем andriyj

[lllsergeyv]

Как сейчас обстоят дела с VRF в Linux или FreeBSD? Все также печально(на подпорках и костылях) или кто-то пилит юзабельную версию?

[Alex/AT]

В смысле, "на костылях"? В Linux множественные таблицы маршрутизации доступны уже о-очень давно, как раз аналог VRF, самый ближайший. Даже несколько более функциональный. Комбинация ip route / ip rule позволит и VRF создать, и трафик в VRF запихать. Хоть поинтерфейсно, хоть по источнику/назначению, хоть на базе fwmark от iptables. BIRD прекрасно поддерживает множество таблиц. В продакшне все это работает нормально, не жужжит.

Изменено 28 февраля, 2012 пользователем Alex/AT

[lllsergeyv]

В смысле, "на костылях"? В Linux множественные таблицы маршрутизации доступны уже о-очень давно, как раз аналог VRF, самый ближайший. Даже несколько более функциональный. Комбинация ip route / ip rule позволит и VRF создать, и трафик в VRF запихать. Хоть поинтерфейсно, хоть по источнику/назначению, хоть на базе fwmark от iptables. BIRD прекрасно поддерживает множество таблиц. В продакшне все это работает нормально, не жужжит.

 

Чудесно! Я правильно понял, что BIRD умеет перекидывать маршруты из одной таблицы в другую?

Повесить на разных интерфейсах одинаковые адреса получиться? Не сильно загрузит систему маркировка пакетов с помощью iptables?

[Alex/AT]

Да. BIRD'ом можно сделать как BGP в отдельные RT, так и route leak.

 

Повесить одинаковые адреса на разных интерфейсах получится, но вам нужно аккуратно следить, чтобы интерфейсы между "VRF" (таблицами) не пересекались тогда, как входящие, так и исходящие. Все интерфейсы, сквозь которые гонится трафик в пределах "VRF", должны использовать одну и ту же таблицу.

В таком случае даже iptables может быть и не придется юзать, просто надо фильтр в ip rule делать по iif (входящему интерфейсу), соответственно для каждого iif выбирать нужную таблицу.

В общем, лимитация такая же, как и у циски - каждый интерфейс может лежать только в одном контексте форвардинга.

 

С хитрой маркировкой на netfilter возможны конечно варианты, но я бы не советовал с точки зрения производительности, если нет крайней необходимости.

В любом случае, когда будете проектировать - аккуратно прикиньте, как будет следовать трафик сквозь правила маршрутизации. Как в прямом направлении, так и в обратном.

Изменено 28 февраля, 2012 пользователем Alex/AT

[lllsergeyv]

Да. BIRD'ом можно сделать как BGP в отдельные RT, так и route leak.

 

Повесить одинаковые адреса на разных интерфейсах получится, но вам нужно аккуратно следить, чтобы интерфейсы между "VRF" (таблицами) не пересекались тогда, как входящие, так и исходящие. Все интерфейсы, сквозь которые гонится трафик в пределах "VRF", должны использовать одну и ту же таблицу.

В таком случае даже iptables может быть и не придется юзать, просто надо фильтр в ip rule делать по iif (входящему интерфейсу), соответственно для каждого iif выбирать нужную таблицу.

В общем, лимитация такая же, как и у циски - каждый интерфейс может лежать только в одном контексте форвардинга.

 

С хитрой маркировкой на netfilter возможны конечно варианты, но я бы не советовал с точки зрения производительности, если нет крайней необходимости.

В любом случае, когда будете проектировать - аккуратно прикиньте, как будет следовать трафик сквозь правила маршрутизации. Как в прямом направлении, так и в обратном.

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