proNovell

Подскажите как организовать подключение второго (резервного) интернет канала. В настоящее время установлен BorderManager с двумя сетевыми интерфейсами (внешний и внутренний). Хотелось чтобы при пропадении одного из каналов маршрутизация переключалась автоматически.
Наверное как вариант это добавить еще один внешний интерфейс, ибо поставить еще один сервер с BorderManager.
Может у кого есть ссылки на обсуждение данного вопроса ?
Спасибо.

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

смысл ответа был таков

т.е. правильным вариантом будет купить аппаратный маршрутизатор с двумя WAN портами или собрать чтонибуть аналогичное на Linux/unix и включить это перед сервером с BorderManager ?

АлександрСмирнов писал(а):т.е. правильным вариантом будет купить аппаратный маршрутизатор с двумя WAN портами или собрать чтонибуть аналогичное на Linux/unix и включить это перед сервером с BorderManager ?

Да, аппаратный маршрутизатор - это правильно. Включить - перед ВМ.

АлександрСмирнов писал(а):Хотелось чтобы при пропадении одного из каналов маршрутизация переключалась автоматически.

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

DEFAULT GATEWAY. Я так понимаю, эта фича для того и задумывалась?

Default Gateway по определению больше одного не бывает. если в системе больше 1-го интерфейса и на всех прописан дефолтный гейт - это не правильно.
Про автономную систему конечно красиво сказали но если человек спрашивает об организации запасного канала ему такие умные слова вряд ли помогут

Если оба канала - основной и резервный идут к одному и тому же провайдеру - то просто надо договорится с теми админами - какой протокол маршрутизации они используют (RIPv2, EIGRP - если оборудование Cisco и т.п.) и настроить у себя тоже самое. в этом случае нужен будет номер автонономной системы прописать такой же как и у провайдера.

Если использовать протокол маршрутизации типа EIGRP, то указав в настройках интерфейса bandwith - по умолчанию будет использоваться канал с более широкой полосой пропускания.

То же самое можно сделать прописав статикой 2 пути указав для них разные метрики ("стоимость канала")

в любом случае надо это обговорить с провайдером

При постановке задачи не забудьте правильно определить терминологию:
Если канал действительно резервный, т.е. используется ТОЛЬКО в случае недоступности основного канала, то девайса PIX/ASA вполне достаточно http://www.ciscolab.ru/2007/02/18/pix_multihome.html
Но если Вы потом захотите сделать что-то вроде балансировки нагрузки и т.п., то нужен нормальный рутер.

Да и вообще, никогда не выставлял наружу прокси (хотя BM на NW сломать - дураком стать можно) и никому не советую.

для такой схемы в разрезе Cisco шлюз позволит создать "виртуальный" шлюз, которым будет управлять раутер.
При этой схеме ОС будет сама отслеживать состояние каждого отдельного реального шлюза (в итоге порта) и строить схему самостоятельно, исходя из правил - или раскидывать четные/нечетные запросы, или переключаться на резервный канал или разделиться по пулу адресов.

При этом у конечного пользователя останется и будет только 1 шлюз- "виртуальный"

Про резервный канал понял, лучший вариант "аппаратный" маршрутизатор,
но задача, как выяснилось, поменялась - канал не резервный, а дополнительный для нового сервера к которому будут коннектится клиенты через интернет (Пока даже не знаю по какому протоколу).
Видимо возникает вопрос по балансировке. Провайдеры разные.
Сейчас к примеру стоит почтовый (SMTP) сервер - ip адрес выделен первым провайдером, возможено ли организовать доступ к этому серверу через второго провайдера, если к примеру первый канал падает или да же когда оба канала работают. Если прописать в DNS вторую MX запись для этого почтовика с адресом выделенным вторым провайдером ?

Андрей Старков писал(а):Default Gateway по определению больше одного не бывает. если в системе больше 1-го интерфейса и на всех прописан дефолтный гейт - это не правильно.
Про автономную систему конечно красиво сказали но если человек спрашивает об организации запасного канала ему такие умные слова вряд ли помогут

Если оба канала - основной и резервный идут к одному и тому же провайдеру - то просто надо договорится с теми админами - какой протокол маршрутизации они используют (RIPv2, EIGRP - если оборудование Cisco и т.п.) и настроить у себя тоже самое. в этом случае нужен будет номер автонономной системы прописать такой же как и у провайдера.

Если использовать протокол маршрутизации типа EIGRP, то указав в настройках интерфейса bandwith - по умолчанию будет использоваться канал с более широкой полосой пропускания.

То же самое можно сделать прописав статикой 2 пути указав для них разные метрики ("стоимость канала")

в любом случае надо это обговорить с провайдером

Чуш пишете. Никто вам не запрещает иметь несколько dafault gataway. Конструкция вида:
ip route 0.0.0.0 0.0.0.0 1.1.1.1
ip route 0.0.0.0 0.0.0.0 2.2.2.2
отличается от:
ip route 0.0.0.0 0.0.0.0 1.1.1.1 50
ip route 0.0.0.0 0.0.0.0 2.2.2.2 100
только тем, что в первом случаи будет осуществляться балансировка по каналам, а во втором канал через который через который указан default gataway с метрикой 100 будет резервным.

Использование IGP протоколов накладывает дополнительную зависимость вас от провайдера. Помимо "физики" могут возникать проблемы с "логикой". Хотя если у провайдера нормальные специалисты и в договоре предусмотрены ответственность за неверные действия по вине персонала, то впринципе проблем быть не должно. С использованием протокола IGP провайдер анонсирует вам default gataway. Если каналы у вас одинаковой пропускной способности и вы специально не опредиляете метриками основной и резервный, ваш маршрутизатор будет содержать 2 default gataway в таблице маршрутизации. В случаи использования EIGRP вы можете использовать возможность not equal path load-balancing

2 default gateway не будут нормально работать для интерфейсов не поддерживающих state (например конвертер эзернет-оптика, дсл модем,vlan), что сейчас в большинстве случаев и используется.
Если канал упал чуть дальше у вашего провайдера, тоже облом.
Такчто ЧушЬ пишет не Андрей Старков.

Опять-же если договориться с обоими провайдерами то автономную зону можно серую сделать.

Я что хотел сказать, что простого решения типа купил железку всё полетело - не будет. Нужно ещё грамотно всё настроить, и вариантов решений может быть несколько, в зависимости от тех условий.
Как вариант комп с 2 прокси(squid без кэша например), которые идут по разным каналам, а бордер пользует их парентами. И собственно циска не нужна.

АлександрСмирнов писал(а):Сейчас к примеру стоит почтовый (SMTP) сервер - ip адрес выделен первым провайдером, возможено ли организовать доступ к этому серверу через второго провайдера, если к примеру первый канал падает или да же когда оба канала работают. Если прописать в DNS вторую MX запись для этого почтовика с адресом выделенным вторым провайдером ?

Примерно так.
Можно ещё у dns записи прописать оба адреса без всяких mx. я так делал на момент миграции. Будет работать round-robin по очереди.

Но есть такой момент,что ответы будут уходить всё равно по дефолтовому маршруту, а некоторым системам это не нравится.

например:
сервер имеет адрес 1.1.1.1 и 2.2.2.2
шлюз по умолчанию 1.1.1.2
smtp сессия пришла на адрес 2.2.2.2
а ответ ушел по маршруту с адреса 1.1.1.1
и если канал 1.1.1.1 умрёт, толком ничего работать не будет.

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

АлександрСмирнов писал(а):Про резервный канал понял, лучший вариант "аппаратный" маршрутизатор,
но задача, как выяснилось, поменялась - канал не резервный, а дополнительный для нового сервера к которому будут коннектится клиенты через интернет (Пока даже не знаю по какому протоколу).
Видимо возникает вопрос по балансировке. Провайдеры разные.
Сейчас к примеру стоит почтовый (SMTP) сервер - ip адрес выделен первым провайдером, возможено ли организовать доступ к этому серверу через второго провайдера, если к примеру первый канал падает или да же когда оба канала работают. Если прописать в DNS вторую MX запись для этого почтовика с адресом выделенным вторым провайдером ?

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

v13 писал(а):2 default gateway не будут нормально работать для интерфейсов не поддерживающих state (например конвертер эзернет-оптика, дсл модем,vlan), что сейчас в большинстве случаев и используется.
Если канал упал чуть дальше у вашего провайдера, тоже облом.
Такчто ЧушЬ пишет не Андрей Старков.

Еще один. Вы бы хоть ссылку приведенную Стоговым Кирилом ради интереса посмотрели, прежде чем писать.

cut

!--- Введите следующую команду чтобы отслеживать статический маршрут.
!--- Это статический маршрут, инсталлируемый в таблицу маршрутизации пока отслеживаемый объект доступен
!--- Величина после слова "track" это идентификатор слежения.

route outside 0.0.0.0 0.0.0.0 10.200.159.1 1 track 1

!--- Определяем резервный маршрут используемый когда отслеживаемый объект недоступен.
!--- Административная дистанция резевного маршрута должна быть больше чем административная дистанция
!--- отслеживаемого маршрута.

route backup 0.0.0.0 0.0.0.0 10.250.250.1 254

!--- Конфигурируем новый процесс мониторинга с ID 123.
!--- Указываем протокол мониторинга и отслеживаемый сетевой объект чью доступность отслеживает процесс мониторинга.
!--- Указываем число пакетов высылаемых в каждом опросе и скорость с которой процесс повторяется

sla monitor 123
type echo protocol ipIcmpEcho 10.0.0.1 interface outside
num-packets 3
frequency 10

!--- Планирование процесса мониторинга
!--- В этом случае время жизни бесконечное. Мониторинг начинается сразу как только введена команда

sla monitor schedule 123 life forever start-time now

!
!--- Связываем отслеживаемый статический маршрут с процессом SLA.
!--- track ID должен соответствовать track ID у статического маршрута, а 123 - это ID процесса SLA

track 1 rtr 123 reachability

end cut

Возможности Enhanced tracking и IP SLA "пришли" в PIX/ASA из Cisco IOS, так что роутеры их поддерживали и ранее.

Не стоит наверное писать, что можно отслеживать не только доступность шлюза провайдера но и дальше?

З.Ы. Вам никто не говорит что это идеальное решение. Наиболее правильным при использовании 2-х и более каналов является наличие собственной автономной системы и протокола BGP, с получением full view от всех провайдеров. Правда это не всегда возможно по различным причинам (финансирование, наличие необходимого оборудования, провайдеры и т.д.)