Автор |
Сообщение |
phant
Зарегистрирован: 15 июл 2017, 21:08 Сообщения: 70
|
Народ подскажите в ASA 5505 прописано route ISP1 0.0.0.0 0.0.0.0 1.1.1.1 1 track 1 route ISP2 0.0.0.0 0.0.0.0 2.2.2.2 10 track 2 route ISP2 8.8.4.4 255.255.255.255 2.2.2.2 1
Падает 1-й провайдер, на втором провайдере инет не поднимается при падении 1-го провайдера какой маршрут по умолчанию будет ?
|
16 янв 2019, 15:25 |
|
|
root99
Зарегистрирован: 29 май 2017, 21:19 Сообщения: 1404
|
Вот так будет работать если ISP1 является основным каналом
sla monitor 1 type echo protocol ipIcmpEcho 8.8.4.4 interface ISP1 sla monitor schedule 1 life forever start-time now ! track 1 rtr 1 reachability ! route ISP1 0.0.0.0 0.0.0.0 1.1.1.1 10 track 1 route ISP1 8.8.4.4 255.255.255.255 1.1.1.1 10 route ISP2 0.0.0.0 0.0.0.0 2.2.2.2 64
|
16 янв 2019, 15:46 |
|
|
Demm
Зарегистрирован: 01 янв 1970, 03:00 Сообщения: 498
|
ну а если не работает при падении, то sh route, чтоб увидеть маршруты
|
16 янв 2019, 15:50 |
|
|
phant
Зарегистрирован: 15 июл 2017, 21:08 Сообщения: 70
|
root99 писал(а): Вот так будет работать если ISP1 является основным каналом
sla monitor 1 type echo protocol ipIcmpEcho 8.8.4.4 interface ISP1 sla monitor schedule 1 life forever start-time now ! track 1 rtr 1 reachability ! route ISP1 0.0.0.0 0.0.0.0 1.1.1.1 10 track 1 route ISP1 8.8.4.4 255.255.255.255 1.1.1.1 10 route ISP2 0.0.0.0 0.0.0.0 2.2.2.2 64 не не логика в том чтобы трафик шел через 2-го на 8.8.4.4 , чтобы при работе первого мы могли со второго пинги видеть а когда 1-й падает дефолтным становился маршрут route ISP2 0.0.0.0 0.0.0.0 2.2.2.2 так мы мониторим доступность 2-го провайдера из вне (точнее из инета)
Последний раз редактировалось phant 16 янв 2019, 15:53, всего редактировалось 1 раз.
|
16 янв 2019, 15:51 |
|
|
phant
Зарегистрирован: 15 июл 2017, 21:08 Сообщения: 70
|
Demm писал(а): ну а если не работает при падении, то sh route, чтоб увидеть маршруты это понятно, просто воспроизвести не можем..... т.е нет возможности отрубить 1-го
|
16 янв 2019, 15:52 |
|
|
Demm
Зарегистрирован: 01 янв 1970, 03:00 Сообщения: 498
|
phant писал(а): не не логика в том чтобы трафик шел через 2-го на 8.8.4.4 , чтобы при работе первого мы могли со второго пинги видеть а когда 1-й падает дефолтным становился маршрут route ISP2 0.0.0.0 0.0.0.0 2.2.2.2 так мы мониторим доступность 2-го провайдера из вне (точнее из инета) ну тогда пишите в sla 8.8.8.8 вообще выложите ваш текущий конфиг sla
|
16 янв 2019, 15:55 |
|
|
root99
Зарегистрирован: 29 май 2017, 21:19 Сообщения: 1404
|
Это всё фигня что вы написали - если вам нужно получить рабочую схему то пример вверху
И конфиг не полностью выложен с какого бадуна должен отрабатываться триггер при падении ISP1 если его нет...
|
16 янв 2019, 15:56 |
|
|
phant
Зарегистрирован: 15 июл 2017, 21:08 Сообщения: 70
|
root99 писал(а): Это всё фигня что вы написали - если вам нужно получить рабочую схему то пример вверху
И конфиг не полностью выложен с какого бадуна должен отрабатываться триггер при падении ISP1 если его нет... sla monitor 1 type echo protocol ipIcmpEcho 8.8.8.8 interface iSP1 num-packets 5 threshold 1000 frequency 5 sla monitor schedule 1 life forever start-time now sla monitor 2 type echo protocol ipIcmpEcho 77.88.8.8 interface ISP2 num-packets 5 threshold 1000 frequency 5 sla monitor schedule 2 life forever start-time now
|
16 янв 2019, 15:59 |
|
|
Demm
Зарегистрирован: 01 янв 1970, 03:00 Сообщения: 498
|
track на isp2 не нужен Логика такая. трак отрабатывает на основном маршруте, когда он не доступен переходим на следующий дефолтный, когда опять доступен - возвращаемся обратно
|
16 янв 2019, 16:06 |
|
|
phant
Зарегистрирован: 15 июл 2017, 21:08 Сообщения: 70
|
Demm писал(а): track на isp2 не нужен Логика такая. трак отрабатывает на основном маршруте, когда он не доступен переходим на следующий дефолтный, когда опять доступен - возвращаемся обратно а не может быть , что route ISP2 8.8.4.4 255.255.255.255 2.2.2.2 1 вот этот маршрут становится дефолтным, т.к дистанция 1 , а у route ISP2 0.0.0.0 0.0.0.0 2.2.2.2 10 track 2 - 10, ????и из-за этого не работает ISP2 точнее работает криво....
|
16 янв 2019, 16:10 |
|
|
phant
Зарегистрирован: 15 июл 2017, 21:08 Сообщения: 70
|
Demm писал(а): track на isp2 не нужен Логика такая. трак отрабатывает на основном маршруте, когда он не доступен переходим на следующий дефолтный, когда опять доступен - возвращаемся обратно да конечно попробую
|
16 янв 2019, 16:10 |
|
|
root99
Зарегистрирован: 29 май 2017, 21:19 Сообщения: 1404
|
track 2 имеет смысл если у вас отрабатывается 3 условие например переключение на следующий маршрут отличный от ISP1 и ISP2
А в случ. когда ISP1 основной канал то для для отработки переключения на резерв достаточно track 1 и он должен быть привязан к ISP1 - пример конфига сразу же был выложен под вашу задачу
|
16 янв 2019, 16:19 |
|
|
Demm
Зарегистрирован: 01 янв 1970, 03:00 Сообщения: 498
|
phant писал(а): Demm писал(а): track на isp2 не нужен Логика такая. трак отрабатывает на основном маршруте, когда он не доступен переходим на следующий дефолтный, когда опять доступен - возвращаемся обратно а не может быть , что route ISP2 8.8.4.4 255.255.255.255 2.2.2.2 1 вот этот маршрут становится дефолтным, т.к дистанция 1 , а у route ISP2 0.0.0.0 0.0.0.0 2.2.2.2 10 track 2 - 10, ????и из-за этого не работает ISP2 точнее работает криво.... дефолтный маршрут, в понятии циски "Gateway of last resort", это только маршруты 0.0.0.0 0.0.0.0 - 8.8.4.4 255.255.255.255 2.2.2.2 это просто статика только для 8.8.4.4 Как правильно сделать, вам написали.
|
16 янв 2019, 16:40 |
|
|