LINUX.ORG.RU
ФорумAdmin

Equal Cost балансировка в Linux


0

2

Есть у меня некий хост, на котором вертится OSPF.

И есть два роутера (по сути - вирт. машины с кваггой) которые по OSPF анонсируют маршруты до нескольких сетей с одним весом, соответственно в таблицу роутинга заносятся оба хопа:

# ip ro
...
10.2.200.0/24  proto zebra  metric 20 
        nexthop via 10.1.16.6  dev vlan8 weight 1
        nexthop via 10.1.16.7  dev vlan8 weight 1
10.2.201.0/24  proto zebra  metric 20 
        nexthop via 10.1.16.6  dev vlan8 weight 1
        nexthop via 10.1.16.7  dev vlan8 weight 1
10.2.203.0/24  proto zebra  metric 20 
        nexthop via 10.1.16.6  dev vlan8 weight 1
        nexthop via 10.1.16.7  dev vlan8 weight 1
10.2.209.0/24  proto zebra  metric 20 
        nexthop via 10.1.16.6  dev vlan8 weight 1
        nexthop via 10.1.16.7  dev vlan8 weight 1
...
В какой-то момент было замечено, что есть проблемы с хождением траффика между этим хостом и удаленными сетями из таблицы роутинга.

Начал проверять iperf-ом и он у меня при передаче траффика от этого хоста в удаленную сеть просто залипает, приходится по ctrl+c убивать.

В обратную сторону - всё ок.

Поставил на одном из роутеров цену маршрута повыше - в таблице роутинга на хосте остался один маршрут и iperf заработал отлично.

Вот теперь думаю - это что же, балансировка в линухе страдает? Или у меня кривые руки?

Ответ на: комментарий от pr0mille

Я привёл пример с iperf - этого мало?

А так на практике на этом сервере стоит помимо прочего балансировщик HAProxy, который распределяет клиентов по серверам exchange и аутлуки у клиентов имеют лаги мощные.

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

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

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от blind_oracle

Я привёл пример с iperf - этого мало?

Таки мало.

клиентов имеют лаги мощные

потеря пакетов, повышение rtt, в дампе что-то видно? Возможно дело не Linux, а в самой сети, т.к. после манипуляций с весом, маршрут стал однозначным. Что там на сети тебе виднее.

Если говорить про мой опыт, то с ecmp вплоть до 3.11 проблем не замечено,но это больше был чистый роутинг.

pr0mille
()

если 10.1.16.6 и 10.1.16.7 это разные машины/маршрутизаторы, то представь,

что в tcp сессии первый SYN прошел на 10.1.16.6 а второй пакет - на 10.1.16.7

тогда 10.1.16.7 отбросит пакет, т.к. на него SYN не приходил

вот и залипание

victorb ★★
()
Ответ на: комментарий от victorb

эм, ecmp роутинг, выбор пути к хосту назначения, и tcp syn, с хостом назначения, несколько разные вещи.

первый SYN прошел на 10.1.16.6 а второй пакет - на 10.1.16.7

это как так вдруг так, при нормальном взаимодействии, изменяется ip одного из участника tcp-flow ?

pr0mille
()
Последнее исправление: pr0mille (всего исправлений: 1)
Ответ на: комментарий от victorb

Да, однако я устанавливаю tcp не с 10.1.16.6-7, а с хостом в совершенно другой сети, эти товарищи мне просто пакеты роутят и всё, им их содержимое в общем и целом до фонаря (если нет коннекшн трекинга, а его нет, но это другая песня).

что в tcp сессии первый SYN прошел на 10.1.16.6 а второй пакет - на 10.1.16.7

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

blind_oracle ★★★★★
() автор топика
Ответ на: комментарий от pr0mille

Пакеты пока не дампил, но оба маршрута работают отлично, если использовать их по-одиночке, поэтому сразу подумал что косяк в данном хосте.

Ядро там нынче 3.12, так что может что-то и поплохело в датском королевстве, понадеялся что оно теперь longterm поддержку имеет.

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

Проблема только на этом хосте т.к. он вертит OSPF и получает маршруты с этих роутеров напрямую.

blind_oracle ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.