Перейти к содержимому
Калькуляторы

vmware esx virtual switch есть ли что-нибудь типа uplink failure detection?

Есть сервер, у него два сетевых интерфейса, на нём стоит vmware esxi 4.0, соответсвенно интерфейсы именуются vmnic0 и vmnic1.

 

Есть vSwitch1, в которому подключены vmnic1 и две виртуальные сетевые карты, всё работает нормально, но... Если по-каким либо причинам пропадает физический линк у vmnic1, то это никак не отражается на состоянии линка виртуальных сетевых карточек, а хотелось бы, чтобы при падении физики у vmnic1, все остальные порты опускались. Такая фича у cisco называется link state tracking, у HP - uplink failure detection и делают именно то, что хотелось бы.

 

Собственно вопрос в том, можно ли средствами esx это как-то реализовать?

 

Дело в том, что на виртуальной машине живёт ospf и если состояние виртуальной сетевой карты меняется не сразу при падении линка на vmnic1, то маршруты ospf удаляет только по истечению таймера, а хотелось бы чтоб сразу. Физический сервер включен напрямую в маршрутизатор, поэтому и хочется быстрой отработки ospf.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Костыльное решение: пинговать чтото через этот интерфейс, как только пингов нет - всё умерло.

Либо написать "обратный пингатор": гдето стоит генератор траффика UDP и шлёт каждую секунду пусть по 5 пакетов на ваш сервер через нужный интерфейс, на сервере программа ловит этот траффик. Как только траффика нет - или интерфейс умер или генератор траффика, зато таймауты срабатывания очень минимальные.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Костыльное решение: пинговать чтото через этот интерфейс, как только пингов нет - всё умерло.

Либо написать "обратный пингатор": гдето стоит генератор траффика UDP и шлёт каждую секунду пусть по 5 пакетов на ваш сервер через нужный интерфейс, на сервере программа ловит этот траффик. Как только траффика нет - или интерфейс умер или генератор траффика, зато таймауты срабатывания очень минимальные.

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

 

Кстати, тогда такой вопросец:

Схема включения:

 

Loopback(dummy0): 1.1.1.1/32

eth0: 1.0.0.2/24

eth1: 1.0.1.2/24

 

С помощью ospf в таблице роутинга(показываются оба через ip route list) появляются два маршрута по умолчанию:

0.0.0.0/0 via 1.0.0.1

0.0.0.0/0 via 1.0.1.1

 

Все сервисы слушают на лупбэке 1.1.1.1. Если пакет пришёл через eth0, то ответ всегда пойдёт через eth0 или может при каких-то условиях уйти через eth1?(речь идёт о linux 2.6)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.