[lan-viper]

Привет!

 

Поимел головняк - от аплинка берём 150Мбит, но из-за отсутствия оптических интерфейсов на провайдерской железке, он нам дал два медных порта по 75 Мбит. Естественно ни о каком BGP речи не идёт, одноногие мы ))). На первом порту вот такая бяка: 1.1.1.2/31, на втором порту вот такая: 2.2.2.0/29 (второй порт подключили недавно, когда мы захотели более 100Мбит).

Это всё безобразие транком прилетает на PC-маршрутизатор (debian squeeze), vlan3 - 1.1.1.3 и vlan4 - 2.2.2.2 На данном маршрутизаторе работает NAT для наших абонентов.

В общем нарисовалась задача сварганить L3 балансировку, но дело осложнилось наличием NAT-а.

Сделал на данный момент две таблицы маршрутизации и iptables-ом маркирую пакеты соотв. таблицам метками 50/50. Сначала радовался, что действительно заработала балансировка, но радость продлилась до первой жалобы абонента (затем второй, третьей...), что выкидывает на авторизацию на некоторых важных и не очень сайтах, включая webmany. Проблема ясна - каждая новая tcp сессия может попасть случайным образом в одну или другую таблицу маршрутизации и соответственно NAT-иться будет на разные внешние ip...

 

Хотелось бы послушать советов, как сделать по правильному эту балансировку.

 

Я сам пока насочинял в голове следующие варианты:

1. поставить пред PC-маршрутизатором ещё один, который будет принимать аплинки, но подсеть из второго канала разбить на две: 2.2.2.0/30 и 2.2.2.4/30, которую повесить на интерфейс, смотрящий на нас. Тогда NAT можно спокойно делать на 2.2.2.6, а на принимающем аплинки маршрутизаторе уже делать балансировку.

2. сделать всё каким-то образом на одном тазике, но тут уже нужны советы от более шаристых в маршрутизации спецов, типа завести алиас на лупбэке с белым ip, на него делать NAT и после уже раскидывать по каналам...

[s.lobanov]

Сделал на данный момент две таблицы маршрутизации и iptables-ом маркирую пакеты соотв. таблицам метками 50/50. Сначала радовался, что действительно заработала балансировка, но радость продлилась до первой жалобы абонента (затем второй, третьей...), что выкидывает на авторизацию на некоторых важных и не очень сайтах, включая webmany. Проблема ясна - каждая новая tcp сессия может попасть случайным образом в одну или другую таблицу маршрутизации и соответственно NAT-иться будет на разные внешние ip...

 

просто сделайте балансировку по source ip(т.е. по абоненстким ip), а не по destination. если не сможете сами, выкладывайте всё что в iptables, rt_tables и ip ro li <все таблицы>, подскажу что поправить

[lan-viper]

просто сделайте балансировку по source ip(т.е. по абоненстким ip), а не по destination.

Только такое чувство, что у меня изначально сделано по src ip.

 

root@nas:~# cat /etc/iproute2/rt_tables
#
# reserved values
#
255     local
254     main
253     default
0       unspec
#
# local
#
#1      inr.ruhep
10     ISP1
20     ISP2

 

ip route show table main | grep -Ev '^default' | grep -Ev 'ppp' | while read ROUTE ;
do
 ip route add $ROUTE table ISP1
 ip route add $ROUTE table ISP2
done
ip route add default via 1.1.1.2 table ISP1
ip route add default via 2.2.2.1 table ISP2
ip rule add fwmark 10 table ISP1
ip rule add fwmark 20 table ISP2

 

# Mark chain
$IPT -t mangle -N BALANCING
$IPT -t mangle -A BALANCING -j CONNMARK --restore-mark
$IPT -t mangle -A BALANCING -m mark ! --mark 0 -j RETURN
$IPT -t mangle -A BALANCING -j MARK --set-mark 10
$IPT -t mangle -A BALANCING -m statistic --mode random --probability 0.5 -j MARK --set-mark 20
$IPT -t mangle -A BALANCING -j CONNMARK --save-mark
# Matching to route
$IPT -t mangle -A PREROUTING -i ppp+ -s $NET_VPN -j BALANCING
$IPT -t mangle -A PREROUTING -i $IF_LAN -m set --set IPOEUSERIPS src -j BALANCING
# Customers NAT
$IPT -t nat -N NATCHAIN
$IPT -t nat -A NATCHAIN -o vlan3 -j SNAT --to-source 1.1.1.3
$IPT -t nat -A NATCHAIN -o vlan4 -j SNAT --to-source 2.2.2.2
$IPT -t nat -A POSTROUTING -s $NET_VPN -j NATCHAIN
$IPT -t nat -A POSTROUTING -m set --set IPOEUSERIPS src -j NATCHAIN

 

PS

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

Edited September 1, 2012 by lan-viper

[Saab95]

Вам просто надо арендовать сервер в датацентре и подключить канал интернета с требуемыми характеристиками. Далее 2-мя L2TP каналами через разные соединения заберете его уже у себя на оборудовании. Тогда не будет проблем с сессиями.

 

Там и BGP будет и все что хотите.

[s.lobanov]

lan-viper

нет, у вас сейчас сделано балансировка по каждой вновь создаваемой tcp/udp/icmp-сессии, с точки зрения балансировки это наиболее эффективный метод, т.к. балансируется трафик, даже если у вас один абонент, но в реальных условиях можно и воспользовать ip-src балансировкой:

 

допустим, ваши абоненты распределены равномерно по сети 10.0.0.0/22, тогда правила

 

# Mark chain

$IPT -t mangle -N BALANCING

$IPT -t mangle -A BALANCING -j CONNMARK --restore-mark

$IPT -t mangle -A BALANCING -m mark ! --mark 0 -j RETURN

$IPT -t mangle -A BALANCING -j MARK --set-mark 10

$IPT -t mangle -A BALANCING -m statistic --mode random --probability 0.5 -j MARK --set-mark 20

$IPT -t mangle -A BALANCING -j CONNMARK --save-mark

 

замените на

 

# Mark chain

$IPT -t mangle -N BALANCING

$IPT -t mangle -A BALANCING -s 10.0.0.0/23 -j MARK --set-mark 10

$IPT -t mangle -A BALANCING -j MARK --set-mark 20

 

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

# Mark chain

$IPT -t mangle -N BALANCING

$IPT -t mangle -A BALANCING -s 10.0.0.0/24 -j MARK --set-mark 10

$IPT -t mangle -A BALANCING -s 10.0.1.0/24 -j MARK --set-mark 20

$IPT -t mangle -A BALANCING -s 10.0.2.0/24 -j MARK --set-mark 10

$IPT -t mangle -A BALANCING -j MARK --set-mark 20

 

ну и т.д., идея, надеюсь, вам понятна. Если абонентов совсем мало, то можно создать 2 ipset с чередованием совсем мелких сетей(вплоть до /32-/30) и балансировать по этим множествам

[lan-viper]

s.lobanov, спасибо за вариант.

Но дело в том, что изначально, как только появился второй канал, я именно так и сделал (типа по быстрому что-бы всё заработало), но реализация была ещё проще:

Небыло vlan-ов, каналы были в одном широковещательном домене, у себя на внешнем интерфейсе вторую подсеть просто алиасом прописал, а всех абонентов "попытался" раскидать на разные каналы с помощью NAT (много правил с разным -source).

Способ также работоспособен, но неэффективен и в дополнение - это не настоящая балансировка, а "логистическая". Часто были перекосы по нагрузке.

 

Мне интересно мнение о жизнеспособности этого варианта:

1. поставить пред PC-маршрутизатором ещё один, который будет принимать аплинки, но подсеть из второго канала разбить на две: 2.2.2.0/30 и 2.2.2.4/30, которую повесить на интерфейс, смотрящий на нас. Тогда NAT можно спокойно делать на 2.2.2.6, а на принимающем аплинки маршрутизаторе уже делать балансировку.

Тогда взять побыстрому MiniITX материнку с 2xGbLan от Intel, всё в дешёвый корпусик запихнуть и кинуть возле стойки на время, пока будем ждать, когда наш провайдер соизволит поменять платы расширения на оптические.

Edited September 2, 2012 by lan-viper

[AlKov]

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

ВОзможно я что-то недопонимаю, но никак не могу найти кардинального отличия между медным и оптическим портом (кроме разницы в среде передачи).

Это первое.

Второе - где-то года полтора назад решал коллегам аналогичную задачу - принять 150М двумя медными 100М портами. Задача решилась на раз-два: по паре медюков на каждой стороне и LACP. И так они благополучно жили до тех пор, пока не выросли из 200М и "перепрыгнули" на оптический 1G порт.

Кстати, сам на следующей неделе буду заниматься тем же - собирать агрегацию 800М двумя оптическими портами (мультиплексор аплинка не может дать более 600М одним портом). Будем собирать тот же LACP.

Ваш пров не умеет этого, или я снова что-то не вижу?

 

P.S. Да, что интересно, от прова поступило предложение, балансировать аплинк по BGP, хотя мы такие же одноногие и не имеем своей АС. Соотв. я отказался.

[dsk]

Зачем весь этот геморой, когда есть LACP.

[lan-viper]

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

ВОзможно я что-то недопонимаю, но никак не могу найти кардинального отличия между медным и оптическим портом (кроме разницы в среде передачи).

Это первое.

Платы расширения у них стоят 100Мbit. Мы подключены к магистрали сотового оператора, у него установлен мультисервисный пограничный Huawei PTN 950, в него мы и подключены, наравне с БС-ками )). У них там какие-то проблемы с платами расширений и из-за этого пользуемся тем, что есть...

 

 

Второе - где-то года полтора назад решал коллегам аналогичную задачу - принять 150М двумя медными 100М портами. Задача решилась на раз-два: по паре медюков на каждой стороне и LACP. И так они благополучно жили до тех пор, пока не выросли из 200М и "перепрыгнули" на оптический 1G порт.

Кстати, сам на следующей неделе буду заниматься тем же - собирать агрегацию 800М двумя оптическими портами (мультиплексор аплинка не может дать более 600М одним портом). Будем собирать тот же LACP.

Ваш пров не умеет этого, или я снова что-то не вижу?

Мне предоставили такие технические условия подключения в ультимативной форме. Хотя нужно попробовать попросить их всё-таки сделать LACP (если честно, я так и думал, что нас подключат по LACP, но в итоге предоставили два разных L3 канала, чему я был очень сильно расстроен).

[lan-viper]

Зачем весь этот геморой, когда есть LACP.

Вот и я не понимаю, зачем? В общем написал письмо нашему менеджеру, надеюсь завтра ответят по поводу перехода на LACP.

[White_Alex]

так аплинк принципиально на дает BGP или Вы от него принципиально отказываетесь?:-)))

ибо при L3 балансировке аплинка лучше BGP еще ничего не придумали на мой взгляд.

в качестве примера - мы цепляемся за ТТК тремя L3 линками с балансировкой по BGP (нету в нашем колхозе у ТТК 10Г портов пока что), работает как часы, балансируется совершенно ровно

Edited September 2, 2012 by White_Alex

[lan-viper]

так аплинк принципиально на дает BGP или Вы от него принципиально отказываетесь?:-)))

ибо при L3 балансировке аплинка лучше BGP еще ничего не придумали на мой взгляд.

в качестве примера - мы цепляемся за ТТК тремя L3 линками с балансировкой по BGP (нету в нашем колхозе у ТТК 10Г портов пока что), работает как часы, балансируется совершенно ровно

На счёт BGP ничего против не имею, за исключением того, что представления не имею, как его настраивать на своём DGS-3612G, опыта нет. Ну и всегда считал, что BGP стык делается при наличии двух разных (возможно одного) ISP, из физически разных мест.

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

В дополнение ко всему, нам нужно будет покупать AS с PI или PA (тут тоже затрудняюсь сказать, что в нашем случае будет лучше) подсетью.

Так что городить BGP не имеет особого смысла, как мне представляется.

[White_Alex]

На счёт BGP ничего против не имею, за исключением того, что представления не имею, как его настраивать на своём DGS-3612G, опыта нет. Ну и всегда считал, что BGP стык делается при наличии двух разных (возможно одного) ISP, из физически разных мест.

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

В дополнение ко всему, нам нужно будет покупать AS с PI или PA (тут тоже затрудняюсь сказать, что в нашем случае будет лучше) подсетью.

Так что городить BGP не имеет особого смысла, как мне представляется.

 

ох.... ну так хозяин как говорится барин :-))

а вообще - приватная автономка спасет от необходимости получения AS и PI, хотя бы до момента появления второй ноги :-)

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

[lan-viper]

ох.... ну так хозяин как говорится барин :-))

Да причём тут "хозяин барин"? Говорю же, никогда не приходилось сталкиваться с динамической маршрутизацией, по этому я могу ошибаться, говоря, что BGP нам не нужен. Вот, к примеру, впервые слышу о приватных автономных системах и возможно именно это может нам подойти. В таком случае BGP нужно будет настраивать на PC-маршрутизаторе, т.к. при настройке на 3612 не хватит белых адресов, что-бы маршрутизировать до сервера доступа. Это если я правильно понимаю, как будут распределяться публичные адреса на наших сетевых устройствах при сохранении текущей адресации каналов.

Edited September 2, 2012 by lan-viper

[White_Alex]

 

Да причём тут "хозяин барин"? Говорю же, никогда не приходилось сталкиваться с динамической маршрутизацией, по этому я могу ошибаться, говоря, что BGP нам не нужен. Вот, к примеру, впервые слышу о приватных автономных системах и возможно именно это может нам подойти.

 

где-то здесь у нага валялась на вике отличнейшая дока для желающих ознакомиться с азами BGP, прочтите, куча вопросов сами собой решатся

[snark]

В принципе всё уже сказали:

по паре медюков на каждой стороне и LACP

Зачем весь этот геморой, когда есть LACP

 

Я бы только хотел добавить, что поставив такой свич (выбрал самый дешевый) Вы поднимите все что захотите + получите wire speed роутинг.

Edited September 2, 2012 by snark

[AlKov]

Навскидку, если я не ошибся, Huawei PTN 950 - это всего лишь, говоря "по-деревенски", обычный "преобразователь SDH/Ethernet" (ну типа медиаконвертера, если совсем уж утрировать), а собственно "IP" Ваш аплинк для Вас реализует совсем не на точке доступа (БС), а совсем в другом месте, которое именуют "узлом доступа". Где живут железки, которые умеют то, что надо.

Отсюда, ИМХО, предоставление услуги в том виде, какой сейчас Вам предложен, это со стороны аплинка всего лишь реализация по типу "как проще".

Попробуйте договориться о варианте, "как надо", т.е. как Вам удобнее. ИМХО, это будет LACP, ну или, если Вы реально видите рост со своей стороны, переход на 1G порт.

Edited September 2, 2012 by AlKov

[s.lobanov]

s.lobanov, спасибо за вариант.

Но дело в том, что изначально, как только появился второй канал, я именно так и сделал (типа по быстрому что-бы всё заработало), но реализация была ещё проще:

Небыло vlan-ов, каналы были в одном широковещательном домене, у себя на внешнем интерфейсе вторую подсеть просто алиасом прописал, а всех абонентов "попытался" раскидать на разные каналы с помощью NAT (много правил с разным -source).

Способ также работоспособен, но неэффективен и в дополнение - это не настоящая балансировка, а "логистическая". Часто были перекосы по нагрузке.

 

Т.е. даже если сделать 2 ip-set с чередованием адресов по /32(ну или хотя бы по /30), то всё равно балансировка будет плохая? Получается что 1-2 абонентов-мега-качков сильно портят картину?

 

Если с LACP у вас не получится(я бы на месте мегафона не стал этого делать, чтобы не огребать лишний геморрой на тему порт-ченел не поднимается/не восстанавливается/ой всё зафлудилось), то можно сделать для tcp/80 и tcp/443 балансировку по ip-src(как я набисал выше, но в цепочку BALANCING отправлять только трафик для http/https), а весь остальной трафик балансировать как вы это делаете сейчас(random), т.е. ваши правила поместить в цепочку BALANCING2 и направлять туда весь не http/https трафик

[s.lobanov]

Навскидку, если я не ошибся, Huawei PTN 950 - это всего лишь, говоря "по-деревенски", обычный "преобразователь SDH/Ethernet"

 

ага, медиаконвертер, поддерживающий ip, mpls(включая, te, l2 тунели и FRR). хотя, вопрос о точке терминирования присоединённых операторов не самый простой с точки зрения дизайна и лучше всего использовать заточенные под это дело железяки

[lan-viper]

Мне интересно мнение о жизнеспособности этого варианта:

1. поставить пред PC-маршрутизатором ещё один, который будет принимать аплинки, но подсеть из второго канала разбить на две: 2.2.2.0/30 и 2.2.2.4/30, которую повесить на интерфейс, смотрящий на нас. Тогда NAT можно спокойно делать на 2.2.2.6, а на принимающем аплинки маршрутизаторе уже делать балансировку.

Тогда взять побыстрому MiniITX материнку с 2xGbLan от Intel, всё в дешёвый корпусик запихнуть и кинуть возле стойки на время, пока будем ждать, когда наш провайдер соизволит поменять платы расширения на оптические.

Так как на счёт этого варианта, если с LACP откажут?

Абонентский трафик после NAT будет всегда иметь адрес 2.2.2.6, а дальше уже с ним можно вытворять, что душе угодно.

 

PS

s.lobanov, а с чего Вы взяли, что это мега ))) ?

[AlKov]

...я бы на месте мегафона ..

Так это про мегафон речь?!!

Ой.. А можно тогда я влезу сюда со своим, наболевшим? ;)

С прошлого года веду беседы с мегафоном.. Очень вкусное предложение оттуда получил. И доступ обещают также с БС. И типа по оптике и типа "без проблем любой каприз"..

Планируем вступить в мегафон "второй ногой" (сейчас только ТТК).

Неужели нас ожидает то же самое, что озвучил ТС?! В плане такого же гемора.

У них везде так? Или просто ТС "не повезло"?

[s.lobanov]

Мне интересно мнение о жизнеспособности этого варианта:

1. поставить пред PC-маршрутизатором ещё один, который будет принимать аплинки, но подсеть из второго канала разбить на две: 2.2.2.0/30 и 2.2.2.4/30, которую повесить на интерфейс, смотрящий на нас. Тогда NAT можно спокойно делать на 2.2.2.6, а на принимающем аплинки маршрутизаторе уже делать балансировку.

Тогда взять побыстрому MiniITX материнку с 2xGbLan от Intel, всё в дешёвый корпусик запихнуть и кинуть возле стойки на время, пока будем ждать, когда наш провайдер соизволит поменять платы расширения на оптические.

Так как на счёт этого варианта, если с LACP откажут?

Абонентский трафик после NAT будет всегда иметь адрес 2.2.2.6, а дальше уже с ним можно вытворять, что душе угодно.

 

Таким образом весь трафик от вас будет c ip.src=2.2.2.6 и всегда возвращаться по "нижнему каналу", т.е. входящий трафик в вашей новой схеме не балансируется вообще, только исходняк

 

PS

s.lobanov, а с чего Вы взяли, что это мега ))) ?

 

по набору ключевых слов

[lan-viper]

Таким образом весь трафик от вас будет c ip.src=2.2.2.6 и всегда возвращаться по "нижнему каналу", т.е. входящий трафик в вашей новой схеме не балансируется вообще, только исходняк

Мда...

 

PS

s.lobanov, а с чего Вы взяли, что это мега ))) ?

 

по набору ключевых слов

Он самый.

[s.lobanov]

...я бы на месте мегафона ..

Очень вкусное предложение оттуда получил. И доступ обещают также с БС. И типа по оптике и типа "без проблем любой каприз"..

Планируем вступить в мегафон "второй ногой" (сейчас только ТТК).

Неужели нас ожидает то же самое, что озвучил ТС?! В плане такого же гемора.

У них везде так? Или просто ТС "не повезло"?

 

Ну вы сначала запросите тех.условия, прежде чем паниковать. Если вы местный мусохранск-телеком, а у меги есть 1G, то хватит вам этого, скорее всего. В случае ТС тут он как бы сам виноват. По хорошему, надо получать AS, сеточку, делать bgp и балансировать трафик стандартными способами. LACP с кем попало делать - ну его нафиг, отнеситесь к этому с пониманием.

[lan-viper]

LACP с кем попало делать - ну его нафиг, отнеситесь к этому с пониманием.

А в чём проблемы? Именно с этим протоколом или вообще L2 проблемный?

Edited September 2, 2012 by lan-viper