Настройка основного и двух резервных операторов на Linux-роутере с NetGWM

[beho1der]

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

[gserge]

согласен, ведь было бы неплохо, но это уже получается другой продукт.

[nemox]

Добрый день,
А в чём состоит преимущество данной платформы относительно раутера?

[gserge]

Не совсем понял вопрос, поясните пожалуйста, что имеете в виду под раутером: железные решения?

[mrobespierre]

VyOS например

[shurup]

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

[nemox]

имеется в виду Cisco, Juniper etc (bare metal)

[gserge]

Да, наверное, принципиальное преимущество в том, что зачастую роутер на Linux не только роутер. Он, как минимум, еще и DNS-сервер. То есть, выбирая решение на Linux, выбирают, в первую очередь, мультисервисность. Cisco, Juniper и т.д, конечно, тоже легко справляются с задачей, поставленной в статье.

[nemox]

Спасибо за разъяснение.
Просто меня в своё время учили что раутер должен быть только раутером и всё.
А все комбайны всё_в_одном, обычно не есть хорошо.

[trublast]

Надо полагать, серьезные pps возникают на серьезных проектах, под которые есть AS, и вся эта свистопляска со сменами маршрутов для хоумроутеров не нужна, так как работает BGP.
К примеру, в сети провайдера с десятком тысяч абонентов и чуть менее 10Гбит внешнего канала чуть тюненый conntrack/mark работает (connmark не использую, сказать не могу) и не жужжит на обычном Xeon E3. Внешние маршруты строятся через BGP (поэтому такие вот штуки, как в статье не нужны), но используем NAT, так как адресов маловато.
И уж тем более conntrack будет работать в сетке малого/среднего офиса, с сотней-другой сотрудников, для которого нет своей автономки. Но нужен резервный канал.

[gserge]

да, верно, это решение для небольших проектов, имеющих высокие требования к надежности.

[trublast]

Использую похожую схему, скрипт-тестер написан за 5-10 минут на пыхе, не претендует на красоту кода, но отлично работает тоже лет 5 безотказно

кусок кода на PHP

<?php
function test_gw($gw) {

    if ($gw=='') return 2;
    $test_ip='4.2.2.4';
    exec("ip ro del {$test_ip} >/dev/null 2>/dev/null");
    exec("ip ro add {$test_ip} {$gw}");
    exec("ping -c4 -i0.1 {$test_ip}", $output, $status);
    exec("ip ro del {$test_ip}");
    return $status;
}

function get_gw($table) {
    $route=exec("ip route show table {$table}");
    $route=str_replace("default ",'',$route,$count);
    if (!$count) $route='';
    return $route;
}

function change_default($default_gw,$new_gw) {
    if ($default_gw==$new_gw) return;
    exec("ip route replace default {$new_gw} table default");
    exec("ip route flush cache");
    mail('[e-mail]','GW change!',"Change gw:\n {$default_gw} {$new_gw}");
    exit;
}

// main code

    $gw_oper1=get_gw('oper1');
    $status_oper1=test_gw($gw_oper1);
    $gw_oper2=get_gw('oper2');
    $status_oper2=test_gw($gw_oper2);
    $gw_oper3=get_gw('oper3');
    $status_oper3=test_gw($gw_oper3);

    
    $default_gw=get_gw('default');


    if ($status_oper1==0)
        change_default($default_gw,$gw_oper1);
    if ($status_oper2==0)
        change_default($default_gw,$gw_oper2);
    if ($status_oper3==0)
        change_default($default_gw,$gw_oper3);
	//bla-bla oper12345
?>    
    

Суть похожая: используется несколько таблиц oper1 oper2 oper3, в которых есть default маршрут. И таблица default с маршрутом по умолчанию. В таблице main шлюза нет. В таблицы oper1/2/3 роутятся некоторые статические сети/абоненты/порты/маркированные соединения, то есть они в общем то используются, где-то для балансировки, где-то для других вещей.
А вот когда основной канал «падает», то в default таблицу подгружается шлюз по умолчанию из более приоритетного, но при этом рабочего другого канала. А как только основной (или другой более приоритетный) маршрут «оживает» — маршрут по умолчанию тоже возвращается.

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

[gserge]

Классно! Хорошие идеи часто рождаются одновременно у нескольких человек, и это прекрасно. Выкладывайте на GitHub, оформится как конечное решение в итоге.