[tartalaran]

Небольшая домовая сеть, у абонентов серые адреса. В ядре сети dlink 3627, аплинком к нему идет сервер, который занимается шейпингом, затем сервер, который натит на диапазон ip, stateful фаерволит, и держит AS. К краевому серверу подключены два аплинка разных провайдеров. Трафик - 500Мбит.

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

Какие есть мысли: продублировать оба сервера, аплинки подключить перекрестно, с двумя bgp сессиями на каждом. Проблема получается в НАТе и stateful фаерволе, т.е. одну сессию абонента (ip:port - port:ip) нужно пускать либо по одной, либо по другой ветке, но никак не по обеим сразу. В голову приходит только одно решение - поставить у железку, которая будет направлять соотв. пакеты на один из шейперов, пока тот работает. Работает, т.е. присылает, маршрут в инет по bgp или как то еще, хз.

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

[s.lobanov]

реализовать можно всё, что вы предложили. вопрос лишь цены, т.е. если для вас докупить сервера и сделать по 2 аплинка на сервер не проблема(в финансовом плане), то делайте

[tartalaran]

Всего два аплинка, расширить на них линковые сети до /29 (ну или по два линка/30 с провайдера), каждый сервер получит ип адрес обоих аплинков, т.е. это примерно "бесплатно". Где то недавно читал, что это считается нормальным, иметь как минимум две бгп сессии.

Вопрос, в таком случае в том, какую железку поставить между ядром сети и двумя независимыми шейперами, так что бы пакеты от одного абонента к конкретному сайту шли ТОЛЬКО через один из шейперов (в нормальном режими между двумя шейперами должна быть балансировка). Причем просто по src форвардить пакеты нельзя, нужна отказоустойчивость.

Для того, что бы обратно они шли оттуда-же, можно натить на разные диапазоны, это не проблема.

Таким образом, чисто теоретически, я предполагаю, ставлю туда железку с поддержкой bgp, которая получает анонсы дефолтового маршрута от краевых серверов и раскидывает абонентов, или лучше, сессии по разным шейперам (если есть маршрут через этот шейпер). Можно такое сделать? 500 мбит, с перспективой роста, на каком железке?

[tartalaran]

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

[s.lobanov]

где у вас точка терминирования абонентов и что такое ceccия? (dhcp binding/pppoe/l2tp ?)

[NiTr0]

Вопрос, в таком случае в том, какую железку поставить между ядром сети и двумя независимыми шейперами, так что бы пакеты от одного абонента к конкретному сайту шли ТОЛЬКО через один из шейперов (в нормальном режими между двумя шейперами должна быть балансировка). Причем просто по src форвардить пакеты нельзя, нужна отказоустойчивость.

Выделенное - исключить. Иначе Вася при 10 мбитах поимеет 10 мбит с одного пира в торренте и 10 мбит с другого.

 

Вообще - вариантов множество. Начиная от iBGP (шейпер при этом к слову не нужен - можно и на бордюрах шейпить, просто правильно трафик направить) заканчивая keepalived/carp/etc

[tartalaran]

Под сессией я имел ввиду установленное подключение между абонентом и ресурсом (ip:port - port:ip). Впрочем, как я уже потом отметил, и NiTr0 заметил выше, все пакеты абонента нужно пропускать только через один шейпер, поэтому это слово надо вычеркнуть. У нас dhcp option82, vlan per switch, так что никаких лишних телодвижений не нужно.

 

Насчет ненужности шейпера и бордера отдельно, да, можно и на бордере шейпить, но это значения не имеет, можно считать что бордер и шейпер - один сервер. Один черт, вопрос остается.

keepalived/carp/etc - балансировки не будет, если я правильно понимаю, а хотелось бы что бы была.

Предположим, используем iBGP на железке. Как по src направить трафик, есть ли вообще такая функциональность? У меня складывается ощущение, что я хочу невозможного.

Edited September 4, 2012 by tartalaran

[NiTr0]

keepalived/carp/etc - балансировки не будет, если я правильно понимаю, а хотелось бы что бы была.

Бьете на 2 подсети всех абонов, каждую подсеть - на свой шейпер, при падении одного из шейперов - его подсеть поднимается на втором. Как длинк л3 заставить это делать - вам виднее, думается, можно. Хотя я бы вместо него поставил бы л2 и все завернул на шейпер-агрегатор, если трафик между юзерами ессно не превышает инет-трафик.

[tartalaran]

На длинке терминируются вланы абонентов, у нас vlan per switch, поэтому без L3 никак. В такой ситуации нужна src-based маршрутизация, чего естественно на длинке нет. =(

 

На вскидку, будь у меня железка, на которой был бы линукс, я попытался сделать так. Промаркировал абонентов iptable'сом. Сделал две кастомных таблиц маршрутизации, используемых по маркировке. Поднял бы две зебры, каждая из которых пишет маршруты со своего нейбора в свою таблицу, третья зебра писала бы маршруты в main с обоих нейборов. Можно такое на циске провернуть?

Edited September 4, 2012 by tartalaran

[NiTr0]

На длинке терминируются вланы абонентов, у нас vlan per switch, поэтому без L3 никак.

А что, сетевые карты уже разучились понимать тегированный трафик?

 

На вскидку, будь у меня железка, на которой был бы линукс, я попытался сделать так. Промаркировал абонентов iptable'сом. Сделал две кастомных таблиц маршрутизации, используемых по маркировке. Поднял бы две зебры, каждая из которых пишет маршруты со своего нейбора в свою таблицу, третья зебра писала бы маршруты в main с обоих нейборов.

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

[kapa]

Вопрос, в таком случае в том, какую железку поставить между ядром сети и двумя независимыми шейперами, так что бы пакеты от одного абонента к конкретному сайту шли ТОЛЬКО через один из шейперов (в нормальном режими между двумя шейперами должна быть балансировка). Причем просто по src форвардить пакеты нельзя, нужна отказоустойчивость.

При ваших объёмах трафика о втором шейпере можно пока не думать. Можете сделать stp и при падении шейпера просто гнать трафик в обход через свичи.

[tartalaran]

Насчет отсутствия src-based роутинга в длинке наврал, т.к. никогда не пользовался, оказывается он все таки есть (не знаю, правда работает ли...). В общем, предложенная схема на keepalived и carp пока остается ведущей, спасибо! Какие могут быть еще решения?

 

При ваших объёмах трафика о втором шейпере можно пока не думать. Можете сделать stp и при падении шейпера просто гнать трафик в обход через свичи.

Тоже вариант. Но хотелось бы жить по-спокойнее, так что если уехал в отпуск, а ночью одна ветка упала. Спокойно, зная что все работает в штатном режиме, на следующий день подцепился и сделал.

 

а если бордер упадет? Свитчи в обход потребуют наличие железки с поддержкой bgp, что бы балансировать нагрузку между аплинками и анонсировать нашу сеть

[kapa]

Насчет отсутствия src-based роутинга в длинке наврал, т.к. никогда не пользовался, оказывается он все таки есть (не знаю, правда работает ли...).

PBR там точно работает. С небольшими оговорками, но работает.

 

 

При ваших объёмах трафика о втором шейпере можно пока не думать. Можете сделать stp и при падении шейпера просто гнать трафик в обход через свичи.

Тоже вариант. Но хотелось бы жить по-спокойнее, так что если уехал в отпуск, а ночью одна ветка упала. Спокойно, зная что все работает в штатном режиме, на следующий день подцепился и сделал.

Можно собрать копию железа для замены и два харда - с образом шейпера и ната. Упал шейпер - всё работает без него, только не режется.

Пишется инструкция перед уходом в отпуск по починке и настраиваются алерты на падения шейпера.

 

 

а если бордер упадет? Свитчи в обход потребуют наличие железки с поддержкой bgp, что бы балансировать нагрузку между аплинками и анонсировать нашу сеть

Бордеров ставьте два. Распределять нагрузку сейчас не обязательно, а Длинк, если не путаю, может иметь 2 дефолтных гейтвея. Если не умеет, то теми же PBR можно всё зарулить на основной НАТ, при падении которого всё побежит через резерв.