Bridge на серверах при подключении к 2 коммутаторам ядра

[SunSunych]

Всем доброго времени суток!

 

Есть сеть, схема которой приведена. Из нее я исключил маршрутизатор и иное сетевое оборудование, ибо все наши коммутаторы работают на L2 и ничего не роутят.

 

Имеем 3 сервера, 2 коммутатора Cisco на уровне ядра сети (хотя SG500 у меня не поворачивается назвать коммутатором ядра сети) и коммутаторы доступа SG200-18 и SF200-48.

 

Межвиланового роутинга нет, виланы есть. На коммутаторах включен Rapid-PVST+. Сервера пока не подключены.

 

Я хочу на каждом сервере настроить 2 сетевые карты в режиме моста, назначить некий ip-адрес и подключить в 2 коммутатора ядра сети для отказоустойчивости. На серверах будут клиент-серверные приложения для абонентов на коммутаторах доступа.

 

Когда я переведу сетевые карты в режим моста, то, смотря с какого коммутатора ядра сети посмотреть, я буду видеть разные МАС адреса для одного и того же ip-адреса сервера. Получается, что на первом коммутаторе ip-адрес 192.168.100.100 (к примеру) имеет МАС XX:XX:XX:XX:XX:XX, а на втором коммутаторе, этот же ip-адрес имеет МАС YY:YY:YY:YY:YY:YY. Если я правильно понимаю. То есть на 2 уровне претензий нет, МАС-и разные.

 

В связи с этим вопрос, сможет ли технология Rapid-PVST+ заблокировать один порт в сторону сетевого моста какого-либо конкретного сервера? Нужны ли дополнительные настройки на Cisco? Или на мостах Windows Server, Linux?

Edited July 17, 2016 by SunSunych

[dignity]

Зачем? Вам нужно совсем не это... Вам нужен ethtool, ping, bash и все. Добавление циклов в вашу топологию полное зло. Как вариант еще bonding в режиме active-passive.

[SunSunych]

Я бы рад, но сеть мультисервисная, в ней по виланам ходит телефония, видеонаблюдение, вай-фай, гостевой вай-фай, магазины, конференец-залы и прочее. Если у нас будет 1 коммутатор и вдруг он откажет, то все сервисы будут работать только в пределах access-коммутаторов, что равносильно серьезному ЧП.

Edited July 17, 2016 by SunSunych

[pfexec]

Если у нас будет 1 коммутатор и вдруг он откажет, то все сервисы будут работать только в пределах access-коммутаторов, что равносильно серьезному ЧП.

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

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

[dignity]

Видимо, вы не поняли о чем я написал.

[SunSunych]

dignity я понял и не так давно реализовывал схемы с перестройкой маршрутов и ethtool знаю как облупленного (выставлял буфера и отключал хеши для 900kpps через бюджетных комп)

[zi_rus]

это делает по-другому

На vmware по встроенном свиче по-умолчанию включен split-horizon. Все что пришло с одного порта, не будет отправляться в другой бриждевый порт, без всяких STP.

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

 

Я тоже думал в свое время про STP, но линуксовый бридж умеет только dot1d версию, это боль и страдания, не говоря о том что сам STP это тот еще генератор проблем

[dignity]

Bonding active-passive?

[zi_rus]

Тоже тема. Наши ИТ через active-passive сервера и включают

[vlad11]

Стек коммутаторов и M-LAGG выручил бы вас.

[zi_rus]

стек злое зло

[vlad11]

стек злое зло

 

Смотря какой, на каком оборудовании, какими стекирующими кабелями. Ну и тип траффика, например мультикаст :)