Имеется 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
Это сообщение отредактировал do-do - 25-09-2007 - 20:27
Суть в том, что есть кластер - из 12 узлов. Узел многопроцессорная система с 4мя Ethernet адаптерами (собственно вот откуда 4 разных подсеток) Операционка 6ая Федора (Linux)
В той конфигурации, что приведена выше вообщем то вроде все понятно (IMHO 2ой путь пойдет) В этой же ВАЖНЫЙ момент. Будет ли ОС (ядро) определять маршрут пакетов меж интерфейсов скажем с eth0 -> eth1 (в одном Ноде). Т.е. пакет пойдет eth0->Свитч-eth1 или eth0->eth1 (непосредственно)
Задача ЗАГРУЗИТЬ свитч полностью - чтобы можно было задействовать любую пару портов
Это сообщение отредактировал do-do - 25-09-2007 - 22:05
Он хоть и тупой, но таки свитч :)
Да, бывают китайские мыльницы "switch hub 100" (да, именно так и написано на крышке), которые изображают из себя свитч, но это частный случай.
Отличие управляемого от неуправляемого в наличии фич типа виланов, MAC контроля на порту, ACL, SNMP и тд.
А этот Просто знает, к какому его порту подключен интерфейс с таким МАС адресом и все.
Это сообщение отредактировал do-do - 26-09-2007 - 07:53
Суть, пингуем (из вне) наши 4 интерфейса, отвечает ОДИН
В ARP таблице (на хосте с которого пингуем) появляется 4 записи с 4мя IP адресами, НО одним MAC
(т.е. на пинг отвечает только один интерфейс)P.S. Следствие того, что IP адреса принадлежат НЕ интерфейсам, а системе :)
Это сообщение отредактировал do-do - 28-09-2007 - 15:52
Что значит "извне" ?
С другой карты гейта ?
Дык так и будет. MAC карты гейта.
Все.
| QUOTE |
| Дык так и будет. MAC карты гейта. |
Разумеется НЕ будет :) Подумай, как пойдут ARP запросы :) Любой широковещательный запрос будет продублирован на ВСЕХ (!) портах (47) свича.
Управлял в свое время домашней сеткой на мыльницах.
Хоть и разные были IP у юзеров, но пакеты между разными сетями ходили через роутер, на котором были подняты алиасы типа eth0:1, eth0:2 и тд.
если же сеть /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, а следовательно свитч никак не может "спрямить" прохождение.
| QUOTE (alexxisr @ 02.10.2007 - время: 15:39) |
| на первый вопрос - если сеть с маской /22 то пакеты на роутер не пойдут. |
/22 - псевдо я говорю ж КАК бы становится /22| QUOTE |
| если свитч может на лету определять топологию сети, включая маршрутизацию |
Вообще то это называется МАРШРУТИЗАТОР (свои протоколы, свои таблицы)
| QUOTE |
| в /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 таблице :)
"Вообще то это называется МАРШРУТИЗАТОР"
- нестыковочка, но это неважно
"После ответа СМОТРИМ arp ТАБЛИЦУ И ВИДИМ
4 IP адреса и ТОЛЬКО ОДИН MAC (одного из адаптеров)
Я могу отключить (выдернуть шнурки) 3 сетевухи, но всеравно получу ответ на пинг по ИХ адресам :)"
- это либо неправильная конфигурация сети, либо ядро у Линукса еще глючнее чем у винды. На freebsd все работает как положено - 2 сетевухи - 2 адреса - 2 мака. и если выдернуть один из шнурков, то до этого адреса можно достучаться только явно прописав маршрутизацию через второй адрес.
да, а многие пользователи так пытаются проверить сетевуху.
пингуют собственный адрес и удивляются что неработающая сетевуха отвечает.
| QUOTE (alexxisr @ 03.10.2007 - время: 09:41) |
| "Имеется 48 портовый свитч" "Вообще то это называется МАРШРУТИЗАТОР" - нестыковочка, но это неважно |
Конечно не важно, но интересно.
Под свичем я понимаю (может я и ошибаюсь, но я так считаю)
Сетевой коммутатор или свитч (от англ. switch — переключатель) — устройство, предназначенное для соединения нескольких узлов компьютерной сети в пределах одного сегмента. В отличие от концентратора, который распространяет трафик от одного подключенного устройства ко всем остальным, коммутатор передает данные только непосредственно получателю. Это повышает производительность и безопасность сети, избавляя остальные сегменты сети от необходимости (и возможности) обрабатывать данные, которые им не предназначались.
под маршрутизатором
Маршрутиза́тор или ро́утер (от англ. router) — сетевое устройство, на основании информации о топологии сети и определённых правил принимающее решения о пересылке пакетов сетевого уровня модели OSI между различными сегментами сети.
Работает на более высоком уровне, нежели коммутатор и является более совершенным по своей функциональности, чем сетевой мост. и добавлю от себя работающий на основе протоколов (например IGRP) маршрутизации (вот тогда то НА лету он будет знать про сети почти (!) все )
Так что У меня СВИТЧ, а не маршрутизатор.
| QUOTE |
| либо ядро у Линукса еще глючнее чем у винды |
это не глюк а Фича, обходиться вообщем то ARP фильтром (который закрывает друг от друга локальные сетевые интерфейсы)
Я ж говорил ЭТО следствие того, что АДРЕСА принадлежат НЕ сетевым интерфейсам, а ЯДРУ ОС. Вот ядро и смотрит, достижимость того или иного хоста, с того иль иного интерфейса. В моем случае, ясен пень, все удаленные хосты доступны с любого из 4х интерфейсов (все ж адресация в сети идет не по IP, а по МАС) - вот ядрышко пользует им. Если бы интерфейсы глядели в разные стороны (в разные , скажем свитчи) то все было БЫ классически - просто мой пример специфичен.
| QUOTE |
| На freebsd все работает как положено - 2 сетевухи - 2 адреса - 2 мака. и если выдернуть один из шнурков, то до этого адреса можно достучаться только явно прописав маршрутизацию через второй адрес. |
возможно что во фри о другому
| QUOTE |
| да, а многие пользователи так пытаются проверить сетевуху. пингуют собственный адрес и удивляются что неработающая сетевуха отвечает. |
"возможно что во фри по другому"
да, во фришке адрес принадлежит именно сетевухе.
и заставить ее работать так как было описано для линукса будет проблематично.
"это не глюк а Фича"
возможно, но я плохо представляю ее полезность
Как здесь верно было подмечено - запросы идут во ВСЕ сегменты.
Для того и созданы управляемые свитчи, чтобы такие вещи настраивать и разруливать траф.
| QUOTE (Klimon @ 17.10.2007 - время: 16:07) |
| Для того и созданы управляемые свитчи |
;-)Если приспичит, можно обойтись и так - прописав статические ARP таблицы :)
Не суть, был конкретный специфичный вопрос - получен ответ :)
З.Ы. Вообще весь сыр бор был вызван, некоторыми нюансами (попыткой их понять) при создании САМОПАЛЬНОГО стоечного кластера
| QUOTE (do-do @ 17.10.2007 - время: 16:52) |
| З.Ы. Вообще весь сыр бор был вызван, некоторыми нюансами (попыткой их понять) при создании САМОПАЛЬНОГО стоечного кластера |
А зачем изобретать велосипед?
Тем более, что самопал в большинстве случаев имеет надежность на порядок меньше
| QUOTE (Klimon @ 18.10.2007 - время: 08:43) |
| А зачем изобретать велосипед? |
А в чем изобретение ?
Технология известна. Так шо МЫ СТОЯЛИ на плечах Гигантов :)
А почему САМИ - цена вопроса (в баксах - существенна)
| QUOTE |
| что самопал в большинстве случаев имеет надежность на порядок меньше |
Так как Я принимал в этом участие в этом проекте ТОЛЬКО на уровне обсуждения (даже больше косвенно обсуждал. А больше с любопытством следил за реализацией) могу ЗАМЕТИТЬ (и не прослыть хвастунишкой) НЕ тот случай. Система получилась стабильной и неожиданно производительной (но без разрешения не могу обнародовать детали).