Вопрос ТЕМ кто знает

Вопрос исключительно к тем, кто знает (как теоретик я сам с усам)

Имеется 48 портовый свитч (гигабитный, если кому интересно), свитч не интеллектуальный - имеет свою MAC табличку и дальше не лезет.

К нему НЕПОСРЕДСТВЕННО подключено 48 же Ethernet адаптеров принадлежащим 4ем отдельным сетям - для определенности

1) 192.168.0.0/24
2) 192.168.1.0/24
3) 192.168.2.0/24
4) 192.168.3.0/24

Спрашивается какой путь будет у пакета пересылаемого Между сетями (скажем между Lan1 и Lan2)
Представляется 2а варианта

1) Lan1 - гейт1-СВИТЧ-Lan2
2) Lan1-СВИТЧ-Lan2

Если не подумать можно сказать, что путь 1, но если задуматься, то возникают вопросы

Свитч, не оперирует понятием Сеть (тупой он) - сидит и глядит в свою Таблицу port-MAC.

Для поиска Lan2 - хост в Lan1 пошлет ARP запрос по адресу (MAC) ff:ff:ff:ff:ff:ff - спрашивается куда СВИТЧ его перешлет - на все порты видимо (?) (вот суть вопроса в этом) Тогда разумеется хост в Lan2 ответит хосту Lan1 и пакеты пойдут между ними непосредственно (адресация то в сети плоская - и свитч Просто внутри себя просто будет перенаправлять порта ) и тогда, наши 4 сетки превращаются как бы в одну сеть (для данного частного случая) 192.168.0.0/22

Вот собственно и все. Как оно будет на самом деле? (кстати, экспериментально проверим.... однако, предварительно хотелось бы понять)

Поправка к первому пути - ток ща заметил ошибку :) Lan1-Свитч-Гейт1-Свитч-Lan2

Уточню конфигурацию... т.к. видимо принципиальный тут момент есть.

Суть в том, что есть кластер - из 12 узлов. Узел многопроцессорная система с 4мя Ethernet адаптерами (собственно вот откуда 4 разных подсеток) Операционка 6ая Федора (Linux)

В той конфигурации, что приведена выше вообщем то вроде все понятно (IMHO 2ой путь пойдет) В этой же ВАЖНЫЙ момент. Будет ли ОС (ядро) определять маршрут пакетов меж интерфейсов скажем с eth0 -> eth1 (в одном Ноде). Т.е. пакет пойдет eth0->Свитч-eth1 или eth0->eth1 (непосредственно)

Задача ЗАГРУЗИТЬ свитч полностью - чтобы можно было задействовать любую пару портов

Я, конечно, чайнег... Но тупой свитч (он же - железка) на то и свитч, шоб все порты мучать. :( Или там таки умный свитч, раз маки знает?

А разве тупой свич - это не хаб?

-=Велла=-, Не, не хаб.
Он хоть и тупой, но таки свитч :)
Да, бывают китайские мыльницы "switch hub 100" (да, именно так и написано на крышке), которые изображают из себя свитч, но это частный случай.
Отличие управляемого от неуправляемого в наличии фич типа виланов, MAC контроля на порту, ACL, SNMP и тд.

Тупой - значит НЕ ИНТЕЛЛЕКТУАЛЬНЫЙ. Интеллектуальный он уже знает о том что есть СЕТИ (на другом уроне работает) может содержать в себе ТАБЛИЦЫ МАРШРУТИЗАЦИИ (и понимать протоколы соответствующие) СЕТИ.
А этот Просто знает, к какому его порту подключен интерфейс с таким МАС адресом и все.

Опс .... в такой конфигурации появилась т.н. ARP Flux проблема :)
Суть, пингуем (из вне) наши 4 интерфейса, отвечает ОДИН
В ARP таблице (на хосте с которого пингуем) появляется 4 записи с 4мя IP адресами, НО одним MAC (т.е. на пинг отвечает только один интерфейс)

P.S. Следствие того, что IP адреса принадлежат НЕ интерфейсам, а системе :)

Я не очень понял топологию тестового стенда.
Что значит "извне" ?
С другой карты гейта ?
Дык так и будет. MAC карты гейта.

Топология звезда. Свитч. 12 хостов. На каждом по 4 сетевых интерфейса. Каждый их 4х интерфейсов имеет адрес Одной из 4х сетей. ОС Федора.

Все.



Дык так и будет. MAC карты гейта.

Разумеется НЕ будет :) Подумай, как пойдут ARP запросы :) Любой широковещательный запрос будет продублирован на ВСЕХ (!) портах (47) свича.

Я думал, что извне - это через роутер.
Управлял в свое время домашней сеткой на мыльницах.
Хоть и разные были IP у юзеров, но пакеты между разными сетями ходили через роутер, на котором были подняты алиасы типа eth0:1, eth0:2 и тд.

Извне - имелось ввиду - от другого хоста (ведь можно ж пакеты посылать и меж сетевых интерфейсов одного хоста - но в этом случае понятно, через свитч ничего не пойдет)

на первый вопрос - если сеть с маской /22 то пакеты на роутер не пойдут.
если же сеть /24, то в любом случае задействуется роутер.
если свитч может на лету определять топологию сети, включая маршрутизацию, да еще и оптимизировать её - было бы счастье у всех админов.

в /24 сети прохождение пакета между сетями выглядит так:
хост 192.168.1.1 хочет отправить пакет хосту 192.168.2.1.
видит, что это не локальная сеть, и отправляет пакет дефолтному шлюзу (скажем 192.168.1.254).
свитч находит мак адрес роутера 192.168.1.254 и отправляет пакет ему.
роутер обрабатывает пакет, сверяется с правилами фаервола, nat-а, редиректа и прочее. в нашем случае пакет просто отправляется хосту 192.168.2.1, который для этого должен уже оказаться в одной сети с роутером.
свитч находит мак адрес хоста 192.168.2.1 и направляет пакет ему.

получаем что пакеты никогда не адресуются от 192.168.1.1 к 192.168.2.1, а следовательно свитч никак не может "спрямить" прохождение.

(alexxisr @ 02.10.2007 - время: 15:39) на первый вопрос - если сеть с маской /22 то пакеты на роутер не пойдут.




/22 - псевдо я говорю ж КАК бы становится /22

если свитч может на лету определять топологию сети, включая маршрутизацию
Вообще то это называется МАРШРУТИЗАТОР (свои протоколы, свои таблицы)

в /24 сети прохождение пакета между сетями выглядит так:
хост 192.168.1.1 хочет отправить пакет хосту 192.168.2.1.
видит, что это не локальная сеть, и отправляет пакет дефолтному шлюзу (скажем 192.168.1.254).
СМОТРИМ на КОНКРЕТНУЮ конфгурацию. В этом случае ЭТО не работает! ARP Flux!!!

О том, кто ответит на пинг (например) принимает решение ЯДРО ОС (говорю о Линух) поэтому, например, с хоста 192.168.0.2 пингуем 4 IP адреса принадлежащих ОДНОМУ хосту (конкретной ОС)

После ответа СМОТРИМ arp ТАБЛИЦУ И ВИДИМ
4 IP адреса и ТОЛЬКО ОДИН MAC (одного из адаптеров)
Я могу отключить (выдернуть шнурки) 3 сетевухи, но всеравно получу ответ на пинг по ИХ адресам :)


Кстати - пинг между внутренними интерфейсами идет по лоопбэку (не выходя на свитч)
Не верите :)? ПРобуем - 2а сетевых интерфейса - свитч - и еще один хост, пингуйте оба интерфейса и смотрите, что будет в ARP таблице :)

"Имеется 48 портовый свитч"
"Вообще то это называется МАРШРУТИЗАТОР"
- нестыковочка, но это неважно

"После ответа СМОТРИМ arp ТАБЛИЦУ И ВИДИМ
4 IP адреса и ТОЛЬКО ОДИН MAC (одного из адаптеров)
Я могу отключить (выдернуть шнурки) 3 сетевухи, но всеравно получу ответ на пинг по ИХ адресам :)"
- это либо неправильная конфигурация сети, либо ядро у Линукса еще глючнее чем у винды. На freebsd все работает как положено - 2 сетевухи - 2 адреса - 2 мака. и если выдернуть один из шнурков, то до этого адреса можно достучаться только явно прописав маршрутизацию через второй адрес.

Кстати - пинг между внутренними интерфейсами идет по лоопбэку (не выходя на свитч)

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

(alexxisr @ 03.10.2007 - время: 09:41) "Имеется 48 портовый свитч"
"Вообще то это называется МАРШРУТИЗАТОР"
- нестыковочка, но это неважно



Конечно не важно, но интересно.
Под свичем я понимаю (может я и ошибаюсь, но я так считаю)
Сетевой коммутатор или свитч (от англ. switch — переключатель) — устройство, предназначенное для соединения нескольких узлов компьютерной сети в пределах одного сегмента. В отличие от концентратора, который распространяет трафик от одного подключенного устройства ко всем остальным, коммутатор передает данные только непосредственно получателю. Это повышает производительность и безопасность сети, избавляя остальные сегменты сети от необходимости (и возможности) обрабатывать данные, которые им не предназначались.
под маршрутизатором
Маршрутиза́тор или ро́утер (от англ. router) — сетевое устройство, на основании информации о топологии сети и определённых правил принимающее решения о пересылке пакетов сетевого уровня модели OSI между различными сегментами сети.

Работает на более высоком уровне, нежели коммутатор и является более совершенным по своей функциональности, чем сетевой мост. и добавлю от себя работающий на основе протоколов (например IGRP) маршрутизации (вот тогда то НА лету он будет знать про сети почти (!) все )

Так что У меня СВИТЧ, а не маршрутизатор.


либо ядро у Линукса еще глючнее чем у винды
это не глюк а Фича, обходиться вообщем то ARP фильтром (который закрывает друг от друга локальные сетевые интерфейсы)

Я ж говорил ЭТО следствие того, что АДРЕСА принадлежат НЕ сетевым интерфейсам, а ЯДРУ ОС. Вот ядро и смотрит, достижимость того или иного хоста, с того иль иного интерфейса. В моем случае, ясен пень, все удаленные хосты доступны с любого из 4х интерфейсов (все ж адресация в сети идет не по IP, а по МАС) - вот ядрышко пользует им. Если бы интерфейсы глядели в разные стороны (в разные , скажем свитчи) то все было БЫ классически - просто мой пример специфичен.

На freebsd все работает как положено - 2 сетевухи - 2 адреса - 2 мака. и если выдернуть один из шнурков, то до этого адреса можно достучаться только явно прописав маршрутизацию через второй адрес.
возможно что во фри о другому

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

А про ARP Flux - если кому интересно, можно почитать ТУТ

"Я ж говорил ЭТО следствие того, что АДРЕСА принадлежат НЕ сетевым интерфейсам, а ЯДРУ ОС."
"возможно что во фри по другому"

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

"это не глюк а Фича"

возможно, но я плохо представляю ее полезность

Полезность? Гм...IMHO это такая реализация/ "Проблемы" возникают в очень и очень специфических случаях, но есть рецепты их обхода. Так, что нормально.

Я представляю сколько трафа у тебя на всех сегментах скапливается.
Как здесь верно было подмечено - запросы идут во ВСЕ сегменты.
Для того и созданы управляемые свитчи, чтобы такие вещи настраивать и разруливать траф.

(Klimon @ 17.10.2007 - время: 16:07)
Для того и созданы управляемые свитчи
;-)Если приспичит, можно обойтись и так - прописав статические ARP таблицы :)

Не суть, был конкретный специфичный вопрос - получен ответ :)

З.Ы. Вообще весь сыр бор был вызван, некоторыми нюансами (попыткой их понять) при создании САМОПАЛЬНОГО стоечного кластера