Сохранение маршрута при уходе на резерв

[KorDen]

Ultra 2 / 2.07. Есть основной провайдер (IPoE), есть резерв (Yota либо 3G-модем), уходит на резерв по ping check. Есть несколько маршрутов до внутренних сетей провайдера IPoE (например 10.0.0.0/9), в том числе диапазоны беляков, пример:

ip route 10.0.0.0 255.128.0.0 31.132.x.y ISP-IPTV auto

(31.132.x.y -default gateway)

По логике вещей, при уходе на 3G/4G по отвалу пинга у меня должен оставаться доступ к локалке IPoE согласно указанным маршрутам. На практике же получается что в этот момент через br2 роутится только дефолтный маршрут до подсети приходящего IP.

В давние времена у меня была Giga 1 (еще кажется 2.01, 2012 год вроде), основным было PPTP/L2TP, резерв был IPoE, работало в обратную сторону - при основном соединении по PPTP у меня была доступна локалка провайдера IPoE, при падении PPTP маршрут перекидывался на резерв, но сохранялись маршруты до локалок обоих провайдеров. Думал сделать аналогично, с учетом текущих условий, но логика похоже поменялась, либо я что-то делаю не так.

[4e.Guevara]

По логике вещей, при уходе на 3G/4G по отвалу пинга у меня должен оставаться доступ к локалке IPoE согласно указанным маршрутам. На практике же получается что в этот момент через br2 роутится только дефолтный маршрут до подсети приходящего IP.

Я уже где то здесь об этом писал... Ни ответа, ни привета...

[Le ecureuil]

Хорошо, давайте вместе подумаем над логикой поведения ping-check в таком случае.

Как вы пишете, существует два варианта:

• 1. Если ping-check определяет, что интерфейс недоступен, то он убирает ВСЕ маршруты с данного интерфейса
  
• 2. Если ping-check определяет, что интерфейс недоступен, то он убирает только маршрут по умолчанию с данного интерфейса

Оба варианта имеют право на жизнь, однако давайте подумаем что произойдет вероятнее у провайдера:

• 1. Обрыв линии, плохой контакт, сгоревший/отказавший коммутатор на чердаке (локальная проблема, затрагивающая одного / несколько пользователей, остальные работают нормально).
  
• 2. Отвал ядра сети, отказ BRAS, отказ биллинга, потеря связности с Интернет по BGP (глобальная проблема у провайдера, часть его сервисов / все сервисы недоступны всем пользователям)

Очевидно, что вторая ситуация у любого провайдера происходит куда реже, чем первая (в том числе и из-за простого дублирования ключевой инфраструктуры).

В таком случае выходит, что вариант номер 1 из первого списка (убрать все маршруты) нужно применять куда чаще, чем второй (убрать маршрут по умолчанию), и для пользователей он куда более чаще встречаем / важен.

Однако, можно обсудить реальную необходимость сохранения маршрутов не по умолчанию на отключенном ping-check'ером интерфейсе например через какую-либо команду в CLI.

Все, кто хотят именно такое поведение (возможность переключения с 1-го варианта на 2-й через команду в cli) пусть отпишутся.

[4e.Guevara]

В таком случае выходит, что вариант номер 1 из первого списка (убрать все маршруты) нужно применять куда чаще, чем второй (убрать маршрут по умолчанию), и для пользователей он куда более чаще встречаем / важен.

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

2. Если ping-check определяет, что интерфейс недоступен, то он убирает только маршрут по умолчанию с данного интерфейса

Смысл иначе добавлять маршрут руками????

[Dimash]

Хотелось в тоже второго варианта, пусть даже через Cli

[Le ecureuil]

В таком случае выходит, что вариант номер 1 из первого списка (убрать все маршруты) нужно применять куда чаще, чем второй (убрать маршрут по умолчанию), и для пользователей он куда более чаще встречаем / важен.

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

2. Если ping-check определяет, что интерфейс недоступен, то он убирает только маршрут по умолчанию с данного интерфейса

Смысл иначе добавлять маршрут руками????

Например, если его не присылает провайдер.

Для PPPoE-шных подключений это вообще норма, что приходится все руками прописывать.

[KorDen]

давайте подумаем что произойдет вероятнее у провайдера:

1. Обрыв линии, плохой контакт, сгоревший/отказавший коммутатор на чердаке (локальная проблема, затрагивающая одного / несколько пользователей, остальные работают нормально).
   
2. Отвал ядра сети, отказ BRAS, отказ биллинга, потеря связности с Интернет по BGP (глобальная проблема у провайдера, часть его сервисов / все сервисы недоступны всем пользователям)

Очевидно, что вторая ситуация у любого провайдера происходит куда реже, чем первая (в том числе и из-за простого дублирования ключевой инфраструктуры).

Вы, возможно, слишком идеализированного мнения о провайдерах провинций. Бывают конечно невезучие дома, где регулярно горят свичи/рвут кабели/..., но бывают и те, где ничего не отваливается месяцами. А вот проблемы по п.2 могут происходить чаще из-за постоянных улучшений/изменений в инфраструктуре. Да, такие проблемы быстрее чинятся, но, по крайней мере у нас, мелочи встречаются довольно часто. Обычно это не полный отказ, а некорректно отработавшее резервирование, например кривая балансировка после отвала магистрали. В итоге интернет вроде есть, но либо не везде, либо с большими потерями. Пока скорректируют, может пройти условно полчаса-час, а в это время есть более стабильный резерв.

Кроме того, принципы работы сети разнятся - у одного провайдера коммутатор может сверять IP-MAC-Port каждый час и блокировать при недоступности биллинга, а у другого будет сохраняться последняя запомненная таблица до восстановления связи. А то и вообще может такой связки не быть, или она будет на более удаленном уровне (привязка только к дому/"лучу" оптики от районника или еще какая экзотика). В таких случаях вполне возможно сохранение связности в рамках [микро]района при проблемах чуть дальше.

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

Дополнительно хотелось бы видеть в пинговалке установку таймаута/размера пакета для отлавливания ситуаций, описанных выше, но это уже совсем другая история...

[Le ecureuil]

давайте подумаем что произойдет вероятнее у провайдера:

1. Обрыв линии, плохой контакт, сгоревший/отказавший коммутатор на чердаке (локальная проблема, затрагивающая одного / несколько пользователей, остальные работают нормально).
   
2. Отвал ядра сети, отказ BRAS, отказ биллинга, потеря связности с Интернет по BGP (глобальная проблема у провайдера, часть его сервисов / все сервисы недоступны всем пользователям)

Очевидно, что вторая ситуация у любого провайдера происходит куда реже, чем первая (в том числе и из-за простого дублирования ключевой инфраструктуры).

Вы, возможно, слишком идеализированного мнения о провайдерах провинций. Бывают конечно невезучие дома, где регулярно горят свичи/рвут кабели/..., но бывают и те, где ничего не отваливается месяцами. А вот проблемы по п.2 могут происходить чаще из-за постоянных улучшений/изменений в инфраструктуре. Да, такие проблемы быстрее чинятся, но, по крайней мере у нас, мелочи встречаются довольно часто. Обычно это не полный отказ, а некорректно отработавшее резервирование, например кривая балансировка после отвала магистрали. В итоге интернет вроде есть, но либо не везде, либо с большими потерями. Пока скорректируют, может пройти условно полчаса-час, а в это время есть более стабильный резерв.

Кроме того, принципы работы сети разнятся - у одного провайдера коммутатор может сверять IP-MAC-Port каждый час и блокировать при недоступности биллинга, а у другого будет сохраняться последняя запомненная таблица до восстановления связи. А то и вообще может такой связки не быть, или она будет на более удаленном уровне (привязка только к дому/"лучу" оптики от районника или еще какая экзотика). В таких случаях вполне возможно сохранение связности в рамках [микро]района при проблемах чуть дальше.

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

Дополнительно хотелось бы видеть в пинговалке установку таймаута/размера пакета для отлавливания ситуаций, описанных выше, но это уже совсем другая история...

Опять-таки, если вам нужен такой серьезный кастом никто не мешает на базе opkg/Entware реализовать все хотелки, ловя событие wan.d.

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

Сейчас идет тренд на упрощение Web-интерфейса и многих функций, а тем кому нужен кастом вполне могут его себе сделать сами.

[4e.Guevara]

Я так понял, что никакой галочки типа "Жестко привязать к интерфейсу" и "Обрабатывать по Ping Check" не планируется?

[Le ecureuil]

Я так понял, что никакой галочки типа "Жестко привязать к интерфейсу" и "Обрабатывать по Ping Check" не планируется?

Пока нет, пользуйтесь Opkg/Entware.