Jump to content
Калькуляторы

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

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

 

Есть сеть, схема которой приведена. Из нее я исключил маршрутизатор и иное сетевое оборудование, ибо все наши коммутаторы работают на 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?

post-135753-019811800 1468759793_thumb.jpg

Edited by SunSunych

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Edited by SunSunych

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

Share this post


Link to post
Share on other sites

стек злое зло

 

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

Share this post


Link to post
Share on other sites

Join the conversation

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

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.