[telecom]

Есть данные по производительности, что лучше ESFQ или SFQ+CLS_FLOW???

Сомневаюсь что увидите разницу...

А она есть! Правда небольшая, процентов 20-30, точно оценить сложно. Но в любом случае

>4) выпилен патч esfq

полностью оправдано, собираюсь в своей версии ядра и iproute сделать то же!

Спасибо за идею!

[Althathwe]

У сборок под 686 и amd64 есть какие-нибудь преимущества перед 486?

[NiTr0]

686 - какбы и ядро с поддержкой PAE, и поддержка многопроцессорности и архитектуроспецифиных вещей типа PCI-E, и оптимизировано под 686 и иже с ними (которые суперскалярные, и даже без использования специфичных инструкций оптимизация под i686 на тестах может дать 1.5-2-кратный прирост производительности). 486 ядро - в первую очередь для использования в раритетных тазиках не выше пенька 1, от того и вырезано все лишнее.

[QWE]

Схема сети до внедрения LEAF.

Два бордера, Первый с AS1 (основной оператор), второй с AS2 (резервный оператор), собственная АS3. Бордеры связаны между собой по iBGP. Протокол внутреннего шлюза OSPF.

Оба бордера принимают FV + default от каждого апстрима, по протоколу iBGP заперщено обмениваться дефолтом, в АS 2 объявляем префиксы AS3 с backup community. AS2 обявляет в AS3 (через непосредственный стык) свои сети как более крупными блоками /19 так и более мелкими /21. Из AS1 в AS3 объявляется маршрут из AS2 только /19.

Исходящие пакеты на IP адреса AS2 с сетей AS3 уходят через непосредственный стык т.е. через бордер с AS2. Ходили пакеты обратно или нет по тому же маршруту - через непосредственный стык сказать не могу, не снял дампы.

 

На бордерах крутится CentOS5.5 c ядром 2.6.18-194.8.1.el5 + BIRD 1.3.7. bird компилировался с ключами по умолчанию.

 

Меняю бордер с основным оператором ( AS1) на LEAF 4.2.1 (ядро 2.6.35.14-i686) c BIRD 1.3.7 и происходит следующее - трафик между AS3 и AS2 не ходит, tcpdump ом на стыке с AS2 вижу отправляемые из AS3 пакеты. Обратно пакеты не возвращаются, видимо срабатывает local pref резервного оператора. Возвращаю старый бордер - опять все работает

 

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

Может быть bird как то правился и компилировался хитро что поменялась работа BGP протокола?

Изменено 19 апреля, 2013 пользователем QWE

[QWE]

появилась версия что в ядре включена фича, что если пакет вернулся на (саб)интерфейс с которого не уходил то он попросту дропается. Эсли это так как отключить фичу?

Изменено 19 апреля, 2013 пользователем QWE

[QWE]

и еще вопрос как после загрузки добавить в систему пакет, допустим tcpdump и его зависимости когда нет возможности перегрузить железку?

[NiTr0]

Может быть bird как то правился и компилировался хитро что поменялась работа BGP протокола?

Нет, правок никаких в него не вносилось.

 

появилась версия что в ядре включена фича, что если пакет вернулся на (саб)интерфейс с которого не уходил то он попросту дропается. Эсли это так как отключить фичу?

rp_filter зовется.

auto eth3
iface eth3 inet static
address x.x.x.x
netmask y.y.y.y
broadcast z.z.z.z
ip_rp_filter 0

 

 

как после загрузки добавить в систему пакет, допустим tcpdump

apkg -i <путь/пакет>

[QWE]

тоже нашел

more /etc/sysctl.conf

...

 

# spoofprotect

net.ipv4.conf.default.rp_filter=1

net.ipv4.conf.all.rp_filter=1

[QWE]

# ethtool -i eth2

driver: igb

version: 3.3.6

 

ethtool -K|--offload DEVNAME Set protocol offload

[ rx on|off ]

[ tx on|off ]

[ sg on|off ]

[ tso on|off ]

[ ufo on|off ]

[ gso on|off ]

[ gro on|off ]

[ lro on|off ]

[ rxvlan on|off ]

[ txvlan on|off ]

[ ntuple on|off ]

[ rxhash on|off ]

 

Есть смысл для снижения нагрузки на CPU включить поддержку rx(tx)vlan ? на сколько упадет загрузка?

[NiTr0]

Проверьте. Я не проверял. Думаю, снижение нагрузки будет в пределах погрешности...

[NiTr0]

Зарелизили 5.0-rc1. Изменения: обновление ядра и пакетов, accel-ppp взят из trunk ветки (вроде достаточно стабилен уже, так что можно желающим обкатывать IPoE), поправлена компиляция некоторых пакетов (тип iscsitarget), которые отвалились с апдейтом ядра.

[OK-2004]

Прекрасно!

 

Маленькая хотелка -

 

если это Вас не затруднит:

 

cat Bering-3.4.37.config-i686|sed -ei 's/CONFIG_NET_NS is not set/CONFIG_NET_NS=y/g'|sed -ei 's/CONFIG_VETH is not set/CONFIG_VETH=y/g'|\

sed -ei 's/CONFIG_MACVLAN=m/CONFIG_MACVLAN=y/g' > Bering-3.4.37.config-i686

 

по мотивам статьи уважаемого sirmax

 

Извините...

[NiTr0]

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

[NiTr0]

Итак, вышла 5.0 версия. Изменения: обновлено ядро, свежий аксель с гита (собран с поддержкой LUA), поправлены немного скрипты initrd чтобы не было ругани на присваивание некорректной переменной, пофиксен iscsitarget, ну и еще мелочи.

accel-ppp из транка вроде как достаточно стабилен (судя по ветке форума) - но на боевых серверах я его еще не тестировал.

[dtcom]

Bering-uClibc_5.0.1_x86_64_syslinux_vga.tar при попытке что либо настроить, консоль вываливается в крякозябры. Как лечить ? На Bering-uClibc_5.0.1-rc1_i686_syslinux_vga.tar такого нет, но есть другие проблемы, при попытке запустить accel-pppd говорит canot load libpcre.so.1. Лечится созданием ссылки libpcre.so.1 -> libpcre.so.1.2.1 и перепаковкой initrd.lrp с этой ссылкой.

[NiTr0]

Что конкретно пишет в консоли-то? Можно скрин? Я как-то x86_64 не тестировал, ввиду малополезности на роутере 64-битного софта (прироста производительности практически не будет).

 

Насчет libpcre - таки да, после обновления симлинк не поправили... Закоммитил фикс, в 5.0.2 будет поправлено.

[dtcom]

Например выбираю 1 пункт меню 1) Network configuration. Там выбираю любой пункт для настройки, в результате вижу одни крякозябры. Или выхожу из меню конфигурации, попадаю в обычную консоль. Там например запускаю e3vi /patch/to/file и опять вся консоль в крякозябрах. Такую картину наблюдал и раньше на компах с видеокартой nvidia на других дастрах linux, лечилось вроде какими то манипуляциями с видео драйверами, не помню точнее. Тут что не могу сообразить что делать.

[NiTr0]

Угу таки поломался e3 в 64бит версии. Будем смотреть в чем причина.

Можете в плане эксперимента сгенерить конфиг ан 32бит дистре, закинуть на 64бит. Заодно сравнить скорость. Как по мне - в роутинге IPv4 ощутимой разницы в производительности не будет, а может случиться и наоборот проседание (размеры структур и кода больше, cache misses соответственно чаще).

 

UPD: фикс закоммитили, будет поправлено в следующем релизе.

[NiTr0]

Итак, вышла версия 5.0.2-beta1. Из изменений: пофикшен e3 в 64бит версии, апдейты пакетов и ядра.

[QWE]

Удалил сообщение по причине вероятного решения проблемы.

Изменено 24 декабря, 2013 пользователем QWE

[NiTr0]

Зарелизили 5.0.2, в основном - обнвления пакетов, добавлен ddclient, немного переработан hash-shaper для ускорения инициализации.

Идет работа над 5.1.0-alpha, основные изменения - ядро 3.10, билд для Raspberry PI (возможно - еще на какой-то MIPS из доступных мыльниц будет), небольшая доработка окружения сборки (чтобы в будущем не собирать тулчейн при каждой пересборке пакетов).

[dtcom]

Такая проблема, не работает нат в пул адресов. Вот такое правило в iptables не работает:

-A POSTROUTING ! -s 192.168.68.254/32 -o vlan68 -j SNAT --to-source 192.168.68.32-192.168.68.63

Внешний адрес интерфейса на котором происходит подмена адреса 192.168.68.254. Если стоит --to-source 192.168.68.254, то все работает. Как выяснилось LEAF не отвечает на ARP запросы, если натит в адрес отличный от ип адреса исходящего интерфейса. На обычных линуксах все работает.Как я подозреваю дело в каких то параметрах ядра, но вот в каких выяснить не получается. Есть мысли в чем может быть дело ?

[dtcom]

Оказывается и в других linux работает через раз. Проблему решил просто космически ужасным костылем: "ip addr add dev vlan68 label vlan68:1 192.168.68.32/32, ip addr add dev vlan68 label vlan68:2 192.168.68.33/32, ...., ip addr add dev vlan68 label vlan68:32 192.168.68.63/32". Так на arp естественно отвечает и пользователи ходят в сеть. Но этож бред, а если я захочу натить в пул из 1000 ип адресов, мне что всю тысячу прописывать, хотя один раз можно заморочиться, но как то не красиво.

[DVM-Avgoor]

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

Если все эти ip для вашего апстрима connected, то других вариантов и нет.

[dtcom]

Да так и есть, а то думал баг какой то