Сетевики, помогите разобраться в ситуации.

[zVlad]

Сетевая карта (OSA-ICC - SNA коммуникайшн сервер фактически) на МФ с двумя Ethernet портами. Для избыточности порты должны быть подключены к разным субнет (свитчам, или что там еще, физически разными). Чтобы если один свитч и порт выпал другой вместо него. 5 лет назад было сконфигуриванно так что один порт (порт 0) подключен к субнет 10.210.17.16 (vlan! - 600), другой (порт 1) к 192.75.75.10 (vlan - 78). Устройства в системе на МФ сконфигурированы на оба порта, но постоянно использовались только устройства на порт 0.
В понедельник связь пропала на порт 0. Сетевик в его логах нашел что один из свитчей "глюкнул". Система на МФ сообщила об i/O error на устройствах порт 0. Порт 1 тоже "сдулся". Ping по обоим портам не проходил.

Прошла почти неделя. Сетевик все добивался от людей в data center "протрассировать" (вручную!) кабеля от OSA-ICC до свитчей, на которых, я сам видел, есть лаблс с инфой откуда-куда. Как будто у них, сетевиков, нет таблицы что с чем связано. Парень в дата центре тупил мол другой работы дофига.

В итоге то что связи с OSA-ICC не было привело к major incident строго говоря не связанному напрямую с устройствами на OSA-ICC. Накинулись на сетевиков и парней в дата центр. Те зашевелись и что-то (что? - так мне и не известно) сделали. Связь восстановилась на обоих портах OSA. Наш сетевик позвонил мне (зачем?) и настойчиво (что странно!) демонстрировал мне ситуацию что если порт на свитче для OSA порт 0 "хрякнул" (как он его хрякал я не знаю) то и связь по порту 1 тоже отвалится. Я в этом "убедился", да именно так "оно" и работает. Спрашиваю "почему?" он что-то пробормотал про "разные" vlans (600 и 78) и что "IBM design is bad", при том что постоянно твердил мол он "не занет МФ".

ОК, говорю, что надо сделать чтобы выход одного свитча не рвал обе связи, ведь они для того и сделаны две чтобы защититься от "single switch failure"? Может можно перекофигурировать OSA порт 1 на vlan 600 subnet 10.210.*? Ответов нет. Попробую думаю сам сконфигурировать порт 1 на имевшийся у меня в запасе IP address 10.210.*. Сделал, переконфигурировал. Порт 1 не пингуется, и... порт 0 пинговаться перестал!!!!!

Возвращаю конфигурацию OSA в исходное положение. Нет связи по обоим портам все равно. Сетевик что-то делает на его стороне и связь восстанавливается. Добиться от него "правды" не удается.

Сетевеки, что это было? Как изменение конфигурации одного порта на устройстве подключенным к двум разным свитчам может импактнуть другой порт? Почему выход одного свитча влияет на работу порта подключенного к другому.

Кстати, частично я ответ знаю. В конфигурации OSA есть адрес gateway он один и он в vlan 600. Но значит моя идея перенести оба порта в vlan 600 приведет к желаемому?

[Palych]

В целом в IP то что устройство подключено сети в двух точках, не означает автоматически что бесперебойная связь обеспечена.
Для автоматического переключения на резерв нужно взаимодействие устройства с сетевой инфраструктурой.
Есть много разных способов этого добиться, зависит от требований, условий...
Главная засада мне видится в том что с одной стороны считают что IBM design bad, а с другой - наоборот. Диалектика получается...

[veey+]

первый раз вижу такой дизайн. обычно 2 порта на разный свичи. и создается 1 виртуальный адаптер с 1-м IP и, соответственно, 1 VLAN. В самом простом варианте это все rely on Spanning Tree Protocol running on the switches, но есть и switch-independent solutions.
но я с МФ дел не имел, мож там все по-другому.
и я не особо сетевик...

[zVlad]

В целом в IP то что устройство подключено сети в двух точках, не означает автоматически что бесперебойная связь обеспечена.
Для автоматического переключения на резерв нужно взаимодействие устройства с сетевой инфраструктурой.
Есть много разных способов этого добиться, зависит от требований, условий...
Главная засада мне видится в том что с одной стороны считают что IBM design bad, а с другой - наоборот. Диалектика получается...

Автоматического переключения в данном случае не надо. Устройства это терминалы для людей - операторов. Они должны иметь возможность перейти на другую конекцию если основная сдохлас. Вручную перейти.
Говорить просто "bad design" не приводя никаких обоснований для меня признак непрофессионализма.

[zVlad]

В целом в IP то что устройство подключено сети в двух точках, не означает автоматически что бесперебойная связь обеспечена.
Для автоматического переключения на резерв нужно взаимодействие устройства с сетевой инфраструктурой.
Есть много разных способов этого добиться, зависит от требований, условий...
Главная засада мне видится в том что с одной стороны считают что IBM design bad, а с другой - наоборот. Диалектика получается...

Автоматического переключения в данном случае не надо. Устройства это терминалы для людей - операторов. Они должны иметь возможность перейти на другую конекцию если основная сдохлас. Вручную перейти.
Говорить просто "bad design" не приводя никаких обоснований для меня признак непрофессионализма.

Как следует из доков Порт 0 это для работы с удаленными терминалами (через гэйтвэй и роутер) и теми что сидят на той же субнет из которой назначе ИП для порта 0.
Порт 1 только для терминалом из субнет где ИП для этого порта - локальных терминалов.
В нашей сети, исходя из того как сконфигуриваны порты на OSA, локальных терминалов нет. Следовательно когда падает свитч для порта 0 доступа к OSA по обоим портам. Просто как умывальник.
Остается только стыдно за нашу контору в целом.

[Serb]

В целом в IP то что устройство подключено сети в двух точках, не означает автоматически что бесперебойная связь обеспечена.
Для автоматического переключения на резерв нужно взаимодействие устройства с сетевой инфраструктурой.
Есть много разных способов этого добиться, зависит от требований, условий...
Главная засада мне видится в том что с одной стороны считают что IBM design bad, а с другой - наоборот. Диалектика получается...

Автоматического переключения в данном случае не надо. Устройства это терминалы для людей - операторов. Они должны иметь возможность перейти на другую конекцию если основная сдохлас. Вручную перейти.
Говорить просто "bad design" не приводя никаких обоснований для меня признак непрофессионализма.

Как следует из доков Порт 0 это для работы с удаленными терминалами (через гэйтвэй и роутер) и теми что сидят на той же субнет из которой назначе ИП для порта 0.
Порт 1 только для терминалом из субнет где ИП для этого порта - локальных терминалов.
В нашей сети, исходя из того как сконфигуриваны порты на OSA, локальных терминалов нет. Следовательно когда падает свитч для порта 0 доступа к OSA по обоим портам. Просто как умывальник.
Остается только стыдно за нашу контору в целом.

Проблема обеспечения отказоустойчивость подключения хоста к сети решена довольно давно и не есть ноу хау. Имеется два основных типа :
На уровне L3. Встречается довольно редко так как требуются манипуляции с IGP на уровне хоста . IP addressа на каждом интерфейсе хоста обычно разные , маршрут по умолчанию тоже разный при этом в таблице маршрутизации на уровне дата плейн всегда должен присутствовать только один маршрут . В Слепаков пропадания доступности некст хоп должна инициироваться процедура переключения на другой интерфейс и айпи, при этом все сервисы должны быть bound на все интерфейсы , dns записи меняется автоматически и тд. Так как при таком способе сложно определить точки демаркации (где кончается Зина ответ верности сетевиков и где начинается зона ответсвенности сисетмщиков - применяется редко .



На уровне л2 . Тут есть два типа: active/active and active/passive .

A/A требует наличия протокола взаимодействия между хостом и сетью . (Bonding with static or dynamic protocol (lacp) . Требует правильной конфигурации с обоих сторон . Со стороны сети возможны варианты: MLAG либо кластерное объединение свитчей) . Трафик идёт по обоим (или больше ) интерфейсам . В случае падения интерфейса уменьшается доступная скорость .

A/S . Конфигурация на уровне свитчей не требуется . Трафик идёт по одному интерфейсу. Либо по другому в случае паления первого . Может быть больше чем два интерфейса .

В обоих случаях IP address назначается виртуальному интерфейсу . Маршрут по у олчан только один и при падении линков не меняется ни айпи ни гейтвей . Dns не меняется . Процесс прозрачен для сервисов хоста


Оба интерфейса на стороне свитчей должны быть в одном влан.

Че наворочено в вашем случае вообще не понятно .

[zVlad]

В целом в IP то что устройство подключено сети в двух точках, не означает автоматически что бесперебойная связь обеспечена.
Для автоматического переключения на резерв нужно взаимодействие устройства с сетевой инфраструктурой.
Есть много разных способов этого добиться, зависит от требований, условий...
Главная засада мне видится в том что с одной стороны считают что IBM design bad, а с другой - наоборот. Диалектика получается...

Автоматического переключения в данном случае не надо. Устройства это терминалы для людей - операторов. Они должны иметь возможность перейти на другую конекцию если основная сдохлас. Вручную перейти.
Говорить просто "bad design" не приводя никаких обоснований для меня признак непрофессионализма.

Как следует из доков Порт 0 это для работы с удаленными терминалами (через гэйтвэй и роутер) и теми что сидят на той же субнет из которой назначе ИП для порта 0.
Порт 1 только для терминалом из субнет где ИП для этого порта - локальных терминалов.
В нашей сети, исходя из того как сконфигуриваны порты на OSA, локальных терминалов нет. Следовательно когда падает свитч для порта 0 доступа к OSA по обоим портам. Просто как умывальник.
Остается только стыдно за нашу контору в целом.

Проблема обеспечения отказоустойчивость подключения хоста к сети решена довольно давно и не есть ноу хау. Имеется два основных типа :
На уровне L3. Встречается довольно редко так как требуются манипуляции с IGP на уровне хоста . IP addressа на каждом интерфейсе хоста обычно разные , маршрут по умолчанию тоже разный при этом в таблице маршрутизации на уровне дата плейн всегда должен присутствовать только один маршрут . В Слепаков пропадания доступности некст хоп должна инициироваться процедура переключения на другой интерфейс и айпи, при этом все сервисы должны быть bound на все интерфейсы , dns записи меняется автоматически и тд. Так как при таком способе сложно определить точки демаркации (где кончается Зина ответ верности сетевиков и где начинается зона ответсвенности сисетмщиков - применяется редко .



На уровне л2 . Тут есть два типа: active/active and active/passive .

A/A требует наличия протокола взаимодействия между хостом и сетью . (Bonding with static or dynamic protocol (lacp) . Требует правильной конфигурации с обоих сторон . Со стороны сети возможны варианты: MLAG либо кластерное объединение свитчей) . Трафик идёт по обоим (или больше ) интерфейсам . В случае падения интерфейса уменьшается доступная скорость .

A/S . Конфигурация на уровне свитчей не требуется . Трафик идёт по одному интерфейсу. Либо по другому в случае паления первого . Может быть больше чем два интерфейса .

В обоих случаях IP address назначается виртуальному интерфейсу . Маршрут по у олчан только один и при падении линков не меняется ни айпи ни гейтвей . Dns не меняется . Процесс прозрачен для сервисов хоста


Оба интерфейса на стороне свитчей должны быть в одном влан.

Че наворочено в вашем случае вообще не понятно .

Спасибо за обстоятельный рассказ об отказоустойчивости, но в случае с МФ и в том о чем я писал здесь это решается иначе. Просто надо зарядить не одну а две ОSА карты на работу с терминалами.
На нашем МФ 4 ОSA карты по два порта на каждой. Их можно сконфигурировать под разные цели. Сейчас две OSA карты (4 ports) под обычный TCP/IP трафик. Причем эти 4 порта имеют каждый свои IP addresses и есть виртуальный адррес (один!) в стаке TCP/IP по которому адресуется трафик TCP/IP (можно было сделать дав стака с разными виртуальными адресами и два порта под каждым).
В случае выхода из строя любого из 4 портов трафик автоматически подхватывается оставшимися. Все это делается на уровне МФ.
Третья карта, о которой я начал топик этот) была сконфигурирована для работы VTAM terminals (эмулирует легаси IBM 3174 Communication Controller, SNA/VTAM).
Четвертая карта тоже SNA/VTAM но не для терминалов. Она на даный момент не используется и я ее перенастрою на OSA-ICC и она обеспечит отказоустойчивость и от свитчей и от single OSA-ICC.
От свитчей можно было бы и с одной OSA-ICC справится, но для этого нужны более отзывчивые сетевики. У нас сетевики это "вещь в себе".

[deev_a_v]

Спасибо за обстоятельный рассказ об отказоустойчивости, но в случае с МФ и в том о чем я писал здесь это решается иначе. Просто надо зарядить не одну а две ОSА карты на работу с терминалами.

Пожалуйтесь начальству. Пусть ваших сетевиков лишат премии за незнание основ отказоустойчивости на МФ