переход на PI адреса и обновление DNS

[annawhite]

Добрый день, Уважаемый Алл
прошу совета ибо не могу придумать как решить проблему лучшим способом.
Было: подсеть класса С реальных адресов от прова. на этих адресах есть несколько серверов, в том числе и веб серваки. ДНС прописано соответствующе.
Сейчас: Переходим на BGP с другими реальными IP шниками - получили AS и PI.
Настроили необходимое подключение со вторым провом
Хотим: Перевести наши серваки на второго прова с уже настроенными PI адресами и подключить первого прова по бгп
Но проблема в ДНС. она меняется в течении 4-6 часов.
Возможности собрать подобные серваки для резерва нету.
Вопрос. как можно обойти проблему ДНС? (чтобы сервисы не останавливались на некое количество часов)
есть джунипер J2320 с одним свободным портом и каталист 2950

Спасибо за внимание и за любую мудрую мысль!

[lehisnoe]

Варианты на вскидку:

1. Настроить сервисы на текущих сервантах на прием входящих подключений как по старым адресам, так и по новым.
Если п.1. неосуществим в силу специфичности сервисов, способных работать только на одном адресе, тогда можно поломать голову над п.2:
2. Серванты поместить за J2320 (чтобы она была дефолт-роутером для сервантов), на котором натить входящие запросы только к старым адресам так, чтобы они преобразовывались в запросы к новым адресам. Но тут возникнет засада с "разNATчиванием" трафика, т.к. ответы будут уходить по дефолт-роуту. Мы, правда, такого рода "засаду" решали, но на FreeBSD.

После чего менять записи в ДНС со старых на новые адреса. Таким образом сервант в обоих случаях будет одновременно обслуживать входящие подключения и на новые и на старые адреса, что и нужно на время обновления зон. Более того, я бы такую схему оставил бы на недельку для того, чтобы в сторонних кэширующих ДНСах старая зона экспайрнулась и заменилась новой.

[lehisnoe]

Единственное замечание по п.1: не забывай PBR'ом отправлять ответы с новых адресов в сторону их gw - BGP-машины.

[annawhite]

Спасибо большое за советы. думаю на счет первого пункта.
Можно ли ещё один вопрос?
сейчас канал прова первого приходит в один общий свич Л2 (назовём его ZZZ) но не настроенного (честно говоря мне как-то не по себе от такого подхода)
уже настроила транковую связь джунипера и каталиста и планирую через вланы делить сеть.
будет ли работать такая схема?
первый пров подключен к общему свичу, к нему же подключены все серваки, к нему же подключу и порт джунипера, планируемый как бгп аплинк к первому прову.
второй пров (на котором поднят бгп) смотрит в джунипер, далее по транку идет на каталист. и порт из каталиста (на котором уже прописана нужная подсеть для серверов) подключаю к этому же ZZZ
в сервера на сетевые карты (которые смотрят в этот свич) прописываю по 2 ип-шника.

И на сколько я понимаю все должно работать, ведь свичу ZZZ без разницы какие сети обслуживать.
меняю ДНС
далее поверх этого всего безобразия поднимаю бгп с первым провом и делаю нормальную схему.

Или я что-то не бум-бум?
Спасибо
ЗЫ. прошу прощения за много буковок....


upd. предварительные тесты на линухах прошли успешно. только непонятно как будет себя вести винды и иса сервер...

[lehisnoe]

И на сколько я понимаю все должно работать, ведь свичу ZZZ без разницы какие сети обслуживать.

Да, свичу без разницы, только ответы от новых адресов сервантов полетят по дефолт-роуту к первому прову. Чтобы это изменить и нужен PBR (Policy Base Routing - изменение адреса next-hop в зависимости от src-адреса). Если сервантов немного, то я бы делал PBR силами самих сервантов (на FreeBSD это можно сделать при помощи ipfw fwd либо же pf-ного route-to).

Надеюсь что, суть ты уловила, а конкретная реализация - это уже дело техники

[annawhite]

Да, свичу без разницы, только ответы от новых адресов сервантов полетят по дефолт-роуту к первому прову. Чтобы это изменить и нужен PBR (Policy Base Routing - изменение адреса next-hop в зависимости от src-адреса). Если сервантов немного, то я бы делал PBR силами самих сервантов (на FreeBSD это можно сделать при помощи ipfw fwd либо же pf-ного route-to).

Спасибо большое!
только извиняюсь за глупый вопрос, зачем в виртуальном интерфейсе на порту тогда дефаул гейтвей?

[lehisnoe]

зачем в виртуальном интерфейсе на порту тогда дефаул гейтвей?

Порту чего, свича? Если да, то для того, чтобы быть доступным не только из собственной подсети, но и из других подсетей, пакеты к которым он как раз и отправит через дефолт-роут.

[annawhite]

зачем в виртуальном интерфейсе на порту тогда дефаул гейтвей?

Порту чего, свича? Если да, то для того, чтобы быть доступным не только из собственной подсети, но и из других подсетей, пакеты к которым он как раз и отправит через дефолт-роут.

Извиняюсь, просто никогда не приходилось ставить виртуальные интерфейсы и поэтому видимо что-то недопонимаю.
на сетевой карте сервера оставляю eth0 со старыми значениями
и добавляю eth0:0 с новым PI адресом. в eth0:0 ставлю gateway влана каталиста как шлюза.
почему пакет пришедший с каталиста будет отправляться через первого прова? ведь для этой сети гейтвей прописан однозначно, и разве дефаулт гейтвей не перебивается по приоритету гейтвеем которой прописан для этой сети?

[lehisnoe]

в eth0:0 ставлю gateway влана каталиста как шлюза.

Начнем с того, что 2950 - это свитч 2-го уровня и роутить он ничего не умеет.
К сожалению, с линуксами не работаю, а потому подсказать на тему прописывания там одновременно двух дефолтов не смогу
По логике дефолт может быть только один (метрики оставляем за кадром) - это адрес, куда посылаются все пакеты, путь до которых серверу "не известен".
А ты смотрела, что у тебя в таблице роутинга сервера получается после прописывания второго дефолта?

[annawhite]

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

Спасибо!