Jump to content
  • 0

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


KorDen
 Share

Question

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 маршрут перекидывался на резерв, но сохранялись маршруты до локалок обоих провайдеров. Думал сделать аналогично, с учетом текущих условий, но логика похоже поменялась, либо я что-то делаю не так.

Link to comment
Share on other sites

9 answers to this question

Recommended Posts

  • 0

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

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

Link to comment
Share on other sites

  • 0

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

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

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

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

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

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

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

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

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

Link to comment
Share on other sites

  • 0

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

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

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

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

Link to comment
Share on other sites

  • 0

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

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

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

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

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

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

Link to comment
Share on other sites

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

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

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

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

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

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

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

Link to comment
Share on other sites

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

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

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

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

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

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

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

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

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

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

Link to comment
Share on other sites

  • 0

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...