Комментарии 35
Пинговать шлюз ненадо, часто бывает отпадает внешка но гейт доступен
Я не ставил себе задачу описать ВСЕ возможности. Да, часто бывает так, что надо пинговать дальше. Для этого в статье есть ремарка, что ежли надо пинговать что то другое, то необходимо явно туда прописать маршрут.
Я попробовал взять самый простой случай и по возможности подробно его описать
Я попробовал взять самый простой случай и по возможности подробно его описать
ОФФ тебе: ценник в твоей визитке актуальный?
Похоже тоже придётся переквалифицироваться в «поденщики» — надо учиться.
Похоже тоже придётся переквалифицироваться в «поденщики» — надо учиться.
Да, очень интересно и актуально именно для случая балансировки между провайдерами.
Так что и куда прописать для не гейта провайдеровского?
А вариант для лоадбалансинга тоже интересен
А вариант для лоадбалансинга тоже интересен
В одной сети у моего клиента такая топология: рутер, смотрит езернетом на «железяку» провайдера, которая дальше обеспечивает радиоканал. До «железяки» 30 см езернета в серверной, а дальше — полкилометра воздуха и ненадежное оборудование.
Но при этом моим шлюзом для рутера является «железяка». Соответсвенно, чтобы исключить «стремный» кусок я пингую хост за радиоканалом. Пусть это некий HOST1. Тогда понятно, что этот хост не из присоединенной сети и поэтому может быть доступен как через одного, так и через второго прова.
Но проверяем то мы линк именно первого прова, поэтому пишу так
Чтобы заведомо ходить на HOST1 через первого прова.
По поводу одновременного использования: кое что требует проверки. Пока не оттестирую на новом IOS писать не буду. Но сторонний опыт может ускорить этот процесс.
Но при этом моим шлюзом для рутера является «железяка». Соответсвенно, чтобы исключить «стремный» кусок я пингую хост за радиоканалом. Пусть это некий HOST1. Тогда понятно, что этот хост не из присоединенной сети и поэтому может быть доступен как через одного, так и через второго прова.
Но проверяем то мы линк именно первого прова, поэтому пишу так
ip route HOST1 255.255.255.255 Gate(ISP1)
Чтобы заведомо ходить на HOST1 через первого прова.
По поводу одновременного использования: кое что требует проверки. Пока не оттестирую на новом IOS писать не буду. Но сторонний опыт может ускорить этот процесс.
Я правильно понял, что если я в sla напишу, ну, например, icmp-echo 4.2.2.2, чтобы быть уверенным, что у моего основного провайдера не отвалилась внешка, то я должен написать ещё ip route 4.2.2.2 255.255.255.255 Gate(ISP1)?
И ещё: если не писать sla и track для второго канала, то оно всё равно восстановится, когда поднимется первый?
И ещё: если не писать sla и track для второго канала, то оно всё равно восстановится, когда поднимется первый?
Тоже любите этот ДНС :) Самый короткий адрес + легко запоминается :)
Да, если вы хотите проверить первого провайдера то и пакет надо запускать через интерфейс первого.
Не совсем понял, что поднимется. Там так — пинг пытается идти постоянно. Если доходит, то трек в апе, если нет — в дауне. Если трек в дауне маршрут из таблицы удаляется. КАк только трек поднимается — маршрут снова добавляется. Я ответил на вопрос или не попал? :)
Да, если вы хотите проверить первого провайдера то и пакет надо запускать через интерфейс первого.
Не совсем понял, что поднимется. Там так — пинг пытается идти постоянно. Если доходит, то трек в апе, если нет — в дауне. Если трек в дауне маршрут из таблицы удаляется. КАк только трек поднимается — маршрут снова добавляется. Я ответил на вопрос или не попал? :)
Если в первом случае все понятно и однозначно, то в случае с одновременным использованием двух провайдеров возникают проблемы.
Абсолютно никаких проблем — Policy Based Routing (PBR) нам всем в помощь :)
Абсолютно никаких проблем — Policy Based Routing (PBR) нам всем в помощь :)
Если бы все было так просто — не было бы никаких проблем :)
Я тут начал описывать эту задачу: у себя на сайте положил чуток дописанный файл (здесь этой части нет пока — сегодня буду полностью дописывать и тестировать). Там проблема возникает, когда циске все равно, куда отправить ответный пакет от сервера.
Если интересно:
www.anticisco.ru
Закладка «Почитать», 3 пункт.
Я тут начал описывать эту задачу: у себя на сайте положил чуток дописанный файл (здесь этой части нет пока — сегодня буду полностью дописывать и тестировать). Там проблема возникает, когда циске все равно, куда отправить ответный пакет от сервера.
Если интересно:
www.anticisco.ru
Закладка «Почитать», 3 пункт.
Прочитал.
Есть у меня Exchange сервер. Есть 2 MX записи привязанные соответственно к ISP1 (pri) и ISP2 (sec).
Задача: ответ на пакет пришедший на ISP2, отправить через ISP2.
Решение: На сервере Exchange накручиваем еще один адрес. А на рутере прописываем PBR согласно которого все пакеты от этого адреса отправляем только в ISP2.
Есть у меня Exchange сервер. Есть 2 MX записи привязанные соответственно к ISP1 (pri) и ISP2 (sec).
Задача: ответ на пакет пришедший на ISP2, отправить через ISP2.
Решение: На сервере Exchange накручиваем еще один адрес. А на рутере прописываем PBR согласно которого все пакеты от этого адреса отправляем только в ISP2.
Да, так сделать легко. И это полностью укладывается в пример, где на внутреннем интерфейсе живет route-map STRELKA
Там как раз в 20 абзац надо было бы прописать в качестве интересного трафик от конкретного адреса.
Но есть 2 проблемы:
1. Если сервер имеет адреса из одной подсети, он часто получив запрос на вторичный адрес, отвечает с первичного :(
2. Если на сервере 2 адреса из разных подсетей, то дефолтный маршрут все равно только один для корректной работы.
Это можно обойти, но не красиво.
Там как раз в 20 абзац надо было бы прописать в качестве интересного трафик от конкретного адреса.
Но есть 2 проблемы:
1. Если сервер имеет адреса из одной подсети, он часто получив запрос на вторичный адрес, отвечает с первичного :(
2. Если на сервере 2 адреса из разных подсетей, то дефолтный маршрут все равно только один для корректной работы.
Это можно обойти, но не красиво.
Вопрос стоял о пакете пришедшем снаружи. В моем примере откуда пришел туда и ушел. Можно, конечно, подумать о более изящном решении :)
Был у меня такой случай. Повесили SMTP-сервис на Exchange на два порта — 25 и 26. 26-й натился на второго провайдера. Все работало, клиент не жаловался.
Да, так можно сделать, если только один порт надо транслировать.
В принципе похожий подход можно применить и для разных адресов: статически НАТить порт, а исходящие (инициированные сервером) соединения РАТить в этот же адрес, но динамически и в то, что сейчас живо.
ЗЫ ВОпрос Вам: когда Exch жил на 2 портах одновременно, как осуществлялась балансировка между этими портами?
В принципе похожий подход можно применить и для разных адресов: статически НАТить порт, а исходящие (инициированные сервером) соединения РАТить в этот же адрес, но динамически и в то, что сейчас живо.
ЗЫ ВОпрос Вам: когда Exch жил на 2 портах одновременно, как осуществлялась балансировка между этими портами?
Извините, может я чего-то недопонял, но:
зачем здесь танцы с SLA? Почему нельзя сделать 2 маршрута с разными AD? На Master — меньше, на Backup — больше. Зачем тут SLA?
По-моему, SLA нужно использовать исключительно в случае если падает не гейт, а что-то выше — тобишь маршрут остается, но его как-то нужно убить.
Может я конечно что-то не дочитал в Вашем посте, но лучше уж спрошу :)
Как вариант, можно еще BFD заюзать, но не знаю, умеет ли такое циска, а тем более, есть ли поддержка BFD на другом конце.
зачем здесь танцы с SLA? Почему нельзя сделать 2 маршрута с разными AD? На Master — меньше, на Backup — больше. Зачем тут SLA?
По-моему, SLA нужно использовать исключительно в случае если падает не гейт, а что-то выше — тобишь маршрут остается, но его как-то нужно убить.
Может я конечно что-то не дочитал в Вашем посте, но лучше уж спрошу :)
Как вариант, можно еще BFD заюзать, но не знаю, умеет ли такое циска, а тем более, есть ли поддержка BFD на другом конце.
Собственно про одновременное использование двух провайдеров и ожидал почитать в топике о_О
Какова будет минимальная стоимость железки, которая это умеет? И что это за железка? (№)
Практически любой рутер (начиная с 8хх серии думаю, но надо уточнить). 18хх серия уже точно может и далее — все: 28хх,38хх,72хх (и новые 19хх,29хх,39хх)
у нас пикс 515 в таком режиме работает
В таком — это в режиме резервирования? В таком режиме любой пикс/аса даже удобнее — не надо танцев с бубнами (роут-мапами). Однако, как толко встанет задача одновременного использования каналов — увы, ни пикс, ни аса не справится :( (см топик про АСА и чего она не умеет)
Тут есть проблема в чем. При переключении на запасного провайдера надо почистить таблицу трансляций. Иначе пользовательские сессии подвиснут.
Делается примерно так
event manager applet ISP_SWITCHED_20
event track 30 state any
action 1.0 cli command «enable»
action 2.0 cli command «clear ip nat trans forced»
Еще. Я при icmp-echo обязательно пишу source
Вот так
p sla 30
icmp-echo x.x.x.33 source-interface GigabitEthernet0/1
А то кто его знает с какого адреса будет пинговаться дальний адрес.
Еще. В правилах трансляции я пишу вот так (без пула):
ip nat inside source route-map via-gi01 interface GigabitEthernet0/1 overload
Чаще все же провайдер не дает пула адресов.
В route-map часто пишу вот так
route-map via-gi01 permit 10
match ip address nat_enabled
match interface GigabitEthernet0/1
Чтобы транслировать только адреса которые должны иметь доступ к внешней сети.
Делается примерно так
event manager applet ISP_SWITCHED_20
event track 30 state any
action 1.0 cli command «enable»
action 2.0 cli command «clear ip nat trans forced»
Еще. Я при icmp-echo обязательно пишу source
Вот так
p sla 30
icmp-echo x.x.x.33 source-interface GigabitEthernet0/1
А то кто его знает с какого адреса будет пинговаться дальний адрес.
Еще. В правилах трансляции я пишу вот так (без пула):
ip nat inside source route-map via-gi01 interface GigabitEthernet0/1 overload
Чаще все же провайдер не дает пула адресов.
В route-map часто пишу вот так
route-map via-gi01 permit 10
match ip address nat_enabled
match interface GigabitEthernet0/1
Чтобы транслировать только адреса которые должны иметь доступ к внешней сети.
Большое спасибо за дополнения!
Действительно, часто бывает так, что сессии «подвисают», т.е. в кэше сессий сохраняются старые записи. На старых ИОСах боролся с этим таймаутами. Чаще всего этим грешат статический НАТ трансляции. Для PAT (по портам) трансляций больших проблем на новых ИОСах не замечал. Обычно до падения трека проходит существенное время (30 секунд, например), и большая часть сессий падает и сессии пытаются переустановиться сами. С UDP засада, но только потоковым.
Но в любом случае, с ЕЕМ будет работать надежно и прогнозируемо. Тоже его советую пользовать для чистки сессий при падении канала. И ещё тогда таймаут на SLA ставить поменьше.
А вот про source-int не согласен: ИМХО правильнее указать именно маршрут явный на пингуемый хост с маской /32 (его никто не перебьет) через необходимый интерфейс. AFAIK source-int задает, какой адрес источника ставить пакету, а не с какого интерфейса его посылать.
Действительно, часто бывает так, что сессии «подвисают», т.е. в кэше сессий сохраняются старые записи. На старых ИОСах боролся с этим таймаутами. Чаще всего этим грешат статический НАТ трансляции. Для PAT (по портам) трансляций больших проблем на новых ИОСах не замечал. Обычно до падения трека проходит существенное время (30 секунд, например), и большая часть сессий падает и сессии пытаются переустановиться сами. С UDP засада, но только потоковым.
Но в любом случае, с ЕЕМ будет работать надежно и прогнозируемо. Тоже его советую пользовать для чистки сессий при падении канала. И ещё тогда таймаут на SLA ставить поменьше.
А вот про source-int не согласен: ИМХО правильнее указать именно маршрут явный на пингуемый хост с маской /32 (его никто не перебьет) через необходимый интерфейс. AFAIK source-int задает, какой адрес источника ставить пакету, а не с какого интерфейса его посылать.
Пулы провайдеры дают часто. На моей (московской) практике. Транслировать в интерфейс всегда просто, поэтому в примере привёл пул :)
А route-map с двумя критериями (интерфейс и список доступа) я рассмотрел в следующей части.
А route-map с двумя критериями (интерфейс и список доступа) я рассмотрел в следующей части.
А почему «в случае с одновременным использованием двух провайдеров возникают проблемы». Я сейчас на sla делаю почти аналогичную задачу: есть 2 серых сети и 2 шлюза. Одна сеть должна идти через первый, вторая через второй. В случае падения одного из них — обе через один. Настраиваем sla, tracking, а в route-map-ах пишет 2 set ip next-hop verify-availability с треком и разными AD. Для каждой сети свой роут мап и зеркальные AD и next-hop.
п.с.: оба сервера в одном vlan, на удаленном коммутаторе.
п.с.: set ip next-hop verify-availability with optional arguments to support object tracking using Internet Control Message Protocol (ICMP) ping or an HTTP GET request to verify if a remote device is reachable.
:)
п.с.: оба сервера в одном vlan, на удаленном коммутаторе.
п.с.: set ip next-hop verify-availability with optional arguments to support object tracking using Internet Control Message Protocol (ICMP) ping or an HTTP GET request to verify if a remote device is reachable.
:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
По просьбам трудящихся: Dual ISP на маршрутизаторах cisco без BGP