| 1 |
Hi! |
| 2 |
|
| 3 |
Я обращался с этой проблемой к техподдержке своего прова, но мальчикам из |
| 4 |
обычной техподдержки не хватает квалификации для решения таких вопросов, |
| 5 |
а реальные админы от клиентов хорошо прячутся (телефон их не дают, а на |
| 6 |
email они не отвечают). :( ... Может вы сможете мне что-нить подсказать. |
| 7 |
|
| 8 |
|
| 9 |
У меня два adsl-канала, к разным провайдерам (велтон и укртелеком). Оба на |
| 10 |
модемах DSL-500T, и оба в режиме bridge, т.е. pppd для них запускается на |
| 11 |
моём linux-сервере (hardened gentoo). |
| 12 |
У меня настроен default route одновременно через оба канала, а-ля: |
| 13 |
ip route add default scope global \ |
| 14 |
nexthop via 195.5.5.18 dev ppp1 weight 4 \ |
| 15 |
nexthop via 85.90.204.62 dev ppp0 weight 1 |
| 16 |
|
| 17 |
Уже очень много месяцев, раз в сутки (где-то между 22:00 и 03:00) у меня |
| 18 |
отваливается default route через велтон, при этом ОБА канала продолжают |
| 19 |
работать как ни в чём не бывало, но с default route только через |
| 20 |
укртелеком. Если в это время через велтон что-то тянулось - оно |
| 21 |
продолжает тянуться. У меня на велтоновском канале статический ip и сайт - |
| 22 |
они снаружи остаются доступны. Если передёрнуть pppd велтоновского канала - |
| 23 |
я без проблем переподключаюсь и default route снова использует оба канала. |
| 24 |
Можно и просто ручками default route добавить через велтоновский канал. |
| 25 |
|
| 26 |
На моём сервере никаких событий (напр. по cron) в это время не происходит, |
| 27 |
в логах ничего подозрительного тоже не видно. Поэтому единственное, что |
| 28 |
приходит мне в голову - на стороне прова что-то в это время происходит, |
| 29 |
при этом мой pppd от них получает какой-то пакет и сбрасывает default |
| 30 |
route через свой канал. |
| 31 |
|
| 32 |
У меня было подозрение, что в этой проблеме виноват второй канал |
| 33 |
(укртелеком раз в сутки сбрасывает соединение для подсчёта статистики по |
| 34 |
трафику, в то время как велтон ничего такого не практикует). Но я |
| 35 |
несколько дней внимательно понаблюдал за системой в это время - в момент |
| 36 |
передёргивания укртеловского pppd с велтоновским каналом и default route |
| 37 |
ничего не происходит (в нескольких случаях default route через велтон |
| 38 |
отваливался через пару часов после того, как передёрнулся укртеловский |
| 39 |
pppd). |
| 40 |
|
| 41 |
|
| 42 |
|
| 43 |
Если нужно, я могу скинуть свои скрипты, которые поднимают default route. |
| 44 |
Вкратце, это ip-up.local, с простой логикой: если в момент поднятия |
| 45 |
текущего канала второй канал не поднят - поднимается default route только |
| 46 |
через этот канал; а если второй канал поднят, то считывается информация о |
| 47 |
текущем default route и он заменяется на default route через оба канала. |
| 48 |
В ip-down.local, соответственно, если отключается один канал из двух, то |
| 49 |
default route через оба заменяется на default route через оставшийся канал, |
| 50 |
если отключается единственный канал то default route удаляется вообще. |
| 51 |
В момент запуска ip-up.local и ip-down.local ставится блокировка (через |
| 52 |
`chpst -l` из пакета runit - аналог setlock из пакета daemontools), так |
| 53 |
что одновременно может работать только один из этих скриптов, и проблем |
| 54 |
из-за race condition здесь возникать не может. |
| 55 |
|
| 56 |
Поскольку default route я поднимаю в этих скриптах сам, то pppd (для обоих |
| 57 |
каналов) запускается с опцией nodefaultroute......... чисто теоретически, |
| 58 |
если он получает со стороны велтона какой-то пакет, или по какой-то другой |
| 59 |
причине решает форсировать эту опцию, то он может удалять default route |
| 60 |
через велтон (а через укртелеком это может не происходить, например, из-за |
| 61 |
того, что они сами раз в сутки канал передёргивают). |
| 62 |
|
| 63 |
В общем, фигня какая-то творится! :( |
| 64 |
|
| 65 |
-- |
| 66 |
WBR, Alex. |
Archives