Как узнать next-hop на Dialer интерфейсе в Cisco?

Question

[Владимир Пилипчук]

Есть Cisco-роутер, который натит небольшую подсеть + проброс сервисов.

Запитан двумя аплинками от двух провов. Один пров вещает Ehernet, а второй PPPoE.

Задача — резервировать канал в глобальную сеть, если упал один из провов — переключить все на живого ISP. после подъема — вернуть обратно.



Хочу решить вопрос с помощью ip sla и route-map, но есть проблема — verify-availability возможен только на set ip next-hopи нельзя его использовать при set default interface



Интересует вопрос — как узнать ip шлюза для Dialer в cisco ios или, возможно, есть иной способ решить задачу?

Comments

[Владимир Пилипчук]

по умолчанию работают ОБА канала одновременно, но если случается авария нужно переключиться на один живой. После восстановления поднять второй. Для этого и выбрана проверка в route-map.
При sh ip ro в таблице маршрутизации, шлюзом на PPPoE-провайдера фигурирует адрес PPPoE интерфейса, что логично, но я где-то встречал/видел, что есть и еще один адрес, который и есть шлюз на стороне провайдера и его можно использовать как шлюз (на него и пересылаются пакеты с моего интерфейса). Но по sh ip ro его не видно.

Answer 1

[JDima]

как узнать ip шлюза для Dialer

Show ip route.

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

Можно обойтись и без PBR. Достаточно сделать нечто вроде:
ip route 0.0.0.0 0.0.0.0 gi0/0 1.1.1.1 track 1
ip route 0.0.0.0 0.0.0.0 di1 250

Где: «1.1.1.1» — первый хоп по езернету. Track 1 завязан на IP SLA, трекающий нечто доступное только через gi0/0. Лучше бы это был надежный хост в интернете — и на него сделать еще один маршрут с маской /32, дабы пакеты до него улетали только через езернет.
Перестали приходить отклики? Первый маршрут исчезает, и остается последний, который ранее бездействовал из-за высокого AD. Это, кстати, официально рекомендуемая конфигурация, «floating static routes».

И маленькое пояснение. Создавая статический маршрут в сторону ppp интерфейса, указывать next hop не требуется. Только не надо так делать для ethernet.

Comments

[Владимир Пилипчук]

попробовал — не помогло. в этом случае предусматривается что есть ОДИН канал, и потом переключаемся на запасной. Но есть нюанс — по дефолту работают ОБА канала, но при инциденте переключаемся на один живой, пото возвращаемся к дефолту.

[JDima]

по дефолту работают ОБА канала, но при инциденте переключаемся на один живой

Дык тоже не проблема. В этом случае (если предполагается балансировка исходящих пакетов 1:1) делаем:
ip route 0.0.0.0 0.0.0.0 gi0/0 1.1.1.1 track 1
ip route 0.0.0.0 0.0.0.0 di1 track 2
В случае дайлера, в принципе, можно трек не заводить и полагаться на падение интерфейса при аварии — но авария может быть за первым хопом, лучше проверять реальную доступность какого-либо интернет-ресурса. И опять же, по /32 маршруту до каждого из трекаемых строго в свой интерфейс. И IP SLA строго сорсить с соответствующего интерфейса.

[Владимир Пилипчук]

так и сделано. SLA отрабатывает событие «Up --> Down» на обоих интерфейсах, проблема в переключении «сетов» внутри route-map. без роутмапов нат не работает правильно.
хочется
route-map PBR permit 10 set ip next-hop verify-availability x.x.x.1 1 track 10 set ip next-hop verify-availability y.y.y.1 2 track 20
но у.у.у.у — это мой иетерфейс.

[JDima]

А зачем вообще задействован PBR? Есть какие-то причины помимо резервирования? С точки зрения указанной задачи он не нужен, можно обойтись маршрутами. Это и проще в настройке, и легче для железки.

[Владимир Пилипчук]

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

[JDima]

Ну тогда смотрите show ip route. Там обязан быть адрес next hop'а, если стоит опция setroute. По идее, в каких-то других show командах вроде sh int тоже должно дать адрес пира…

Или попробовать «set interface gigabitEthernet 0/1». По идее, должно работать, хотя в случае с PBR не проверял. Опять же, так делать нельзя в случае езернета, но на ppp проблем нет.

[JDima]

То есть, конечно, «set interface dialer 1».