Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | |
так, мысль одна... 03.02.04 10:16 Число просмотров: 1326
Автор: nemo Статус: Незарегистрированный пользователь
|
Я не большой спец в 4400, помню только что они поддерживают стандарт PoE (Power over Ethernet) в добавок ко всем функциям 4300, но мысль у меня тут одна появилась.... может я и не прав.
Насколько я смутно припоминаю свои курсы и общее образование на Cisco Catalyst 2950, то 802.1q потры, т.е те порты которые маркируют все исходящие пакеты ISL тегами могут работать только с теми портами (сетевыми устройствами) которые воспринимают эти теги.
Т.е если ты приписываешь какой-то порт к VLAN1 режима 802.1q, то фреймы приходящие на этот порт с какого-то устройства будут маркироваться коммутатором тегом 1. Все фреймы выдаваемые на этот порт должны обязательно содержать тег 1, при этом при передаче на этот порт поля тега будет удаляться из фрейма.
Если порт переведён в режим 802.1q TRUNK, то через этот порт будут передаваться фреймы с любыми тегами.
При этом если к TRUNK порту подключен другой коммутатор своим TRUNK портом, то он будет выбирать из общего потока только те фреймы в которых есть в поле тега номер одного из зарегистрированных на этом конкретном коммутаторе VLAN и если на нём есть ещё порты в режиме TRUNK, то коммутатор будет передавать на них ВСЕ пакеты пришедшие с других TRUNK портов (ну конечно с учётом таблиц MAC-адресов).
Если к TRUNK порту подключен девайс, сетевой интерфейс которого понимает энкапсуляцию 802.1q, то этот девайс может настроиться на получение пакетов только тех VLAN теги которых он знает и хочет получать.
Все остальные варианты не канают.
|
|
<sysadmin>
|
Мёртвый IEEE 802.1q VLAN 31.01.04 12:11 [StR]
Автор: void <Grebnev Valery> Статус: Elderman
|
Подскажите,плз.
Не могу разобраться, почему не работают tagged (IEEE 802.1q) VLAN
на свиче 3Com Switch 4400. Компы в untagged-портах свича не видят
tagged-порты (там серверы, на tagged).
Прога в свиче свежая (v 3.0)
Пробовал с разными карточками. Так, например, делаю tagged-портами
порты 7 и 9 для некого VLAN "TEST".
В один смотрит навороченная карта Intel ProServer Adapter
с поддержной IEEE 802.1p,q.... (7-порт), в другой 3Com905B-TX
с поддержной IEEE 802.1p,q.... (9-порт)
Мастерю, например, VLAN "TEST" с одним единственным untagged 10-м портом.
Добавляю в VLAN "TEST" 7 и 9 порты в качестве tagged.
Не работает. Шайтан-арба.
Порт 10 (VLAN "TEST") не видет tagged-порты
7 и 9 (там серверы с карточками, см. выше)
Телнетом делаю, например, такую тестовую конфигурацию:
********************************************************************
VLAN ID: 1 Name: Default VLAN
Unit Untagged Member Ports Tagged Member Ports
------------------------------------------------------------------------
1 1-6,8,11-24 none
Aggregated Links AL1-AL4 none
********************************************************************
VLAN ID: 2 Name: TEST
Unit Untagged Member Ports Tagged Member Ports
------------------------------------------------------------------------
1 10 7,9
Aggregated Links none none
********************************************************************
ПС. Около трёх лет делал то же на свичах AT8224XL. Работало на ура.
И это, несмотря на то, что AT8224XL - лоукост железки (но как теперь оказывается -очень надёжные).
Здесь всёж 3Com - а не арбайтен! Ума не приложу, почему?
Начальство уже косо смотрит и немного ругается.
Помогайте, плз.
|
|
Мертвяк он и есть мертвяк 08.02.04 03:41
Автор: void <Grebnev Valery> Статус: Elderman
|
Спасибо всем, кто откликнулся ...
Увы, пока ничего не получается.
Раздобыл ещё одну машинку. Проверил конфигурацию
свичей ещё так:
Switch1 |Switch2
VLAN1 |<---->|VLAN1
VLAN2 | |VLAN2
Это была конфигурация, где tagged портом для обоих
свичей были порты аплинка между ними. Это работает.
Так, что со свичами всё в порядке :(
Попробовал в разных позах конфигурировать карточку
Intel Pro Server Adapter (предварительно обновив дрова)
по аналогии с тем, как делал для FreeBSD - мёртво :(
Что примечательно. Достаточно прописать хотяб один VLAN
(из тех, что сконфигурированы на свиче) на сабинтерфейсе
этого NIC - комп просто ничего не пингует.
Сухой остаток - предложу начальнику сегментировать сетку
(на уровне IP), поставить FreeBSD для рулежки vlan -
и сделать всё по-человечи.
ПС. Не даёт покоя только одна мысли.
Как всё работало на AT8224XL под W2k?
|
| |
А нет ли там (на 3коме) фичи типа "фильтрация пакетов с... 09.02.04 08:46
Автор: StR <Стас> Статус: Elderman
Отредактировано 09.02.04 08:55 Количество правок: 1
|
> Как всё работало на AT8224XL под W2k?
А нет ли там (на 3коме) фичи типа "фильтрация пакетов с левыми тэгами"?
Загляни в статистику по портам 7 и 9... Сколько там пакетов отфильтрованных, сколько прошедших и т.п.
|
|
Эти два сервера друг друга видят? VLAN ID для карточек... 02.02.04 18:19
Автор: vitaliy_m Статус: Незарегистрированный пользователь
|
> В один смотрит навороченная карта Intel ProServer Adapter
> с поддержной IEEE 802.1p,q.... (7-порт), в другой
> 3Com905B-TX
> с поддержной IEEE 802.1p,q.... (9-порт)
Эти два сервера друг друга видят? VLAN ID для карточек правильно установленны?
> Порт 10 (VLAN "TEST") не видет tagged-порты
> 7 и 9 (там серверы с карточками, см. выше)
Если, для эксперемента, сделать порты 7 и 9 untagged - работает?
Зачем оно тебе вообще нужно? Если на порту с сервером только один VLAN будет, то делай его untagged и будет тебе счастье.
Tagged нужен только для совмещения более одного VLAN-а на одном порту - для аплинка либо для двух девайсов (например IP phone + PC) либо для создания двух виртуальных карточек из одной физической для разделенных сабнетов.
|
| |
Нет, не видят. Эти порты тегированные, и втой конфигурации,... 03.02.04 03:21
Автор: void <Grebnev Valery> Статус: Elderman
|
> > В один смотрит навороченная карта Intel ProServer
> Adapter
> > с поддержной IEEE 802.1p,q.... (7-порт), в другой
> > 3Com905B-TX
> > с поддержной IEEE 802.1p,q.... (9-порт)
> Эти два сервера друг друга видят?
Нет, не видят. Эти порты тегированные, и втой конфигурации, о которой я пропостил - они не входят ни в один из VLAN в качестве untagged.
Конечно, если их ввести в некий VLAN "SHARE-SERVERS-PORTS"в качестве untagged, то они начинают друг друга видеть. Но untagged порты из других VLAN по прежнему их не видят.
> VLAN ID для карточек
> правильно установленны?
Я в начале забыл пропостить, что сие счастье под W2k. Там нет необходимости, и Вы не поверите, даже возможности на сетевом интерфейсе прописать ID vilan. Под W2k всё происходит "автоматически".
Достаточно в свойствах NIC установить поддержку IEEE 802.1q(p).
То, о чём Вы говорите, действительно необходимо делать, например, на FreeBSD (до 4.7 включительно, а может уже и выше). Там действительно, для различных vlan, которые имеют свой ID, ипредставляет_уникальную_сетьподсеть)_в_смысле_IP_адресации,
на карточке FreeBSD в tagged-портике прописывать vlan c указанием адреса сети и ID. Ну а далее трафикмаршрутизируетсямежду vlan-нами, или другими интерфейсами FreeBSD.
Здесь же задача схожая, но отличная - необходимы untagged VILANS, все хосты которЫХ принадлежат одной сетке, пусть, 192.168.1.0/24 и которые видят как бы "зашаренные" tagged порты.
> > Порт 10 (VLAN "TEST") не видет tagged-порты
> > 7 и 9 (там серверы с карточками, см. выше)
> Если, для эксперемента, сделать порты 7 и 9 untagged -
> работает?
Да, работает. Но в том смысле, что 7 и 9 видят друг друга. Эти порты по-прежнему недоступны из других VLAN (несмотря на то, что они в этих других VLAN прописаны как tagged).
> Зачем оно тебе вообще нужно? Если на порту с сервером
> только один VLAN будет, то делай его untagged и будет тебе
> счастье.
Кабельная система у трёх контор одна. Можно, конечно, разрулить и без IEEE 802.1 vilan. Но тогда придётся покупать рутер. Нет щас денег у федеральщиков. Я предлагал разрулить рутером FreeBSD. Да боится начальство unix, чего-то.;)) (сам я через месяц увольняюсь. так, что некому будет за фрюшей смотреть здесь ;(() Очень пристрастно относится начальство к виндовз. Говорят виндовз фореве. Может и потому, что вбухали туда немеряно бабок в своё время.
|
| | |
Я все-таки не понял, что коткретно нужно 03.02.04 19:52
Автор: vitaliy_m Статус: Незарегистрированный пользователь
|
Сколько VLAN-ов тебе надо?
Какая конфигурация каждого из VLAN-ов:
- Что кто должен видеть?
- Какие сабнеты на каждом VLAN-е?
- Сколько VLAN-ов на каждом порту?
Какие девайсы у тебя в сетке и понимают ли они IEEE 802.1p/q
Пару замечаний:
Если девайс не понимает IEEE 802.1p/q, то он ничего не услышит (IEEE 802.1p/q инкапсулирует все пакеты и прицепляет заголовок. Для непосвещенного девайса этот заголовок будет выглядеть как испорченный пакет)
Tagged/Untagged имеет смысл только для каждого порта а не для VLAN-а в целом:
- Untagged - все пакеты данного VLAN-а будут передоваться на этот порт без IEEE 802.1p/q заголовка и будут поняты любым девайсом.
- Tagged - все пакеты данного VLAN-а будут инкапсулированны в IEEE 802.1p/q пакет с заголовком и могут быть поняты только девайсом, знающим IEEE 802.1p/q и сконфигурированным для него.
- На конретном порту может быть только один Untagged и любое количество Tagged VLAN-ов.
Для раутинга между VLAN-ами нужен IP раутер (Layer 3). Layer 2 свитч не покатит.
|
| | | |
Ещё раз о том, что мне надо. 04.02.04 08:23
Автор: void <Grebnev Valery> Статус: Elderman
|
Для простоты примем, что имеется 4-е различных
конторы, у каждой из-которых только по 3-и компьютера.;))
Эти конторы должным быть изолированы друг от друга,
но должны иметь достум к некому общему, "зашаренному" ресурсу
на SERVER.
При этом все хосты различных виланов (контор) принадлежат
одной сетке. Это данность. Развести в разные
сетки, ... - нельзя по ряду причин (так захотел мой начальник).
На свиче создаём 4-e VLAN-а (помимо Default Vlan ID=1)
для хостов 4-х различных контор:
VLAN2, Name = KONTORA1, ID = 2
VLAN3, Name = KONTORA2, ID = 3
VLAN4, Name = KONTORA3, ID = 4
VLAN5, Name = KONTORA4, ID = 5
Все хосты любого из виланов (контор) не должны видеть хосты
другого видана (конторы). Конторы должны быть изолированы.
Т.е. хосты VLAN2 изолированы от VLAN3, а VLAN2 от VLAN4, ... ,
а VLAN3 от VLAN4 и так далее.
Для этого создаём, положим, такую конфигурацию всех
виланов, где все порты хостов контор - _ТОЛЬКО_UNTAGGED_:
**
VLAN2:
Ports 2,3,4 - Все эти порты "назначены" UNTAGGED
К этим untagged портам подключены три рабочие станции
из KONTORA1. Сетевые интерфейсы NIC каждой их трёх рабочих
станций НЕ поддерживают инкапсуляцию IEEE 802.1q.
**
VLAN3:
Ports 5,6,7 - Все эти порты "назначены" UNTAGGED
К этим untagged портам подключены три рабочие станции
из KONTORA2. Сетевые интерфейсы NIC каждой их трёх рабочих
станций НЕ поддерживают инкапсуляцию IEEE 802.1q.
**
VLAN4:
Ports 8,9,10 - Все эти порты "назначены" UNTAGGED
К этим untagged портам подключены три рабочие станции
из KONTORA3. Сетевые интерфейсы NIC каждой их трёх рабочих
станций НЕ поддерживают инкапсуляцию IEEE 802.1q.
**
VLAN5:
Ports 11,12,13 - Все эти порты "назначены" UNTAGGED
К этим untagged портам подключены три рабочие станции
из KONTORA4. Сетевые интерфейсы NIC каждой их трёх рабочих
станций НЕ поддерживают инкапсуляцию IEEE 802.1q.
Теперь надо сделать так, чтобы хосты каждой из
вилан видели один единственный общий ресурс
сервера SERVER, который подключен к порту #1.
Для этого:
1) на сетевом интерфейсе SERVER поднимаем поддержку
IEEE 802.1q. (в W2k это делается просто - в свойствах
карточки устанавливаем соответствующий пункт "enabled")
2) Вкаждыйиз виланов в качестве мембера добавляем
port#1. Делаем егоTAGGEDв конфигурации каждой из вилан.
Теперь виланы будут выглдеть следующим образом:
**
VLAN2:
Ports 2,3,4 - Все эти порты "назначены" UNTAGGED
Port 1 - назначен TAGGED
**
VLAN3:
Ports 5,6,7 - Все эти порты "назначены" UNTAGGED
Port 1 - назначен TAGGED
**
VLAN4:
Ports 8,9,10 - Все эти порты "назначены" UNTAGGED
Port 1 - назначен TAGGED
**
VLAN5:
Ports 11,12,13 - Все эти порты "назначены" UNTAGGED
Port 1 - назначен TAGGED
Вот.... Не работает.
Хосты, принадлежащие к одноименной вилан, видят друг-друга. Это хорошо.
Хосты, принадлежащие к различным вилан, не видят друг друга. Это хорошо.
Но! Хосты вилан не видят общего SERVER. Это плохо.
|
| | | | |
Вроде все правильно, только... 04.02.04 09:28
Автор: vitaliy_m Статус: Незарегистрированный пользователь
Отредактировано 04.02.04 09:29 Количество правок: 1
|
> Для простоты примем, что имеется 4-е различных
> конторы, у каждой из-которых только по 3-и компьютера.;))
> Эти конторы должным быть изолированы друг от друга,
> но должны иметь достум к некому общему, "зашаренному"
> ресурсу
> на SERVER.
> При этом все хосты различных виланов (контор) принадлежат одной сетке.
[покусанно]
Конфигурация выглядит правильно.
[покусанно]
> 1) на сетевом интерфейсе SERVER поднимаем поддержку
> IEEE 802.1q. (в W2k это делается просто - в свойствах
> карточки устанавливаем соответствующий пункт "enabled")
А вот тут наверняка и проблема. Я посмотрел об Intel карточке, которая на сервере, и Интел говорит, что нужно использовать ихнюю утилитку для конфигурации VLAN-ов. Про 3com ничего не нашел, но наверняка там то же самое.
Как оно выглядит в системе? На линухе для каждого VLAN-а создается отдельный "виртуальный" адаптер. Должно что-то подобное быть и для винды. А то как же тогда разные ИП раздавать этим VLAN-ам?
То, что в настройках опция есть ни о чем не говорит. Видел я 802.11 карточки у которых в настройках были опции включения WAP - хрен там, не работало нифига. Надо было дополнительной утилиткой это дело настраивать. Даже под ХР не работало.
Покопайся в доках на эти карточки, там должно быть написанно как их настраивать для VLAN-ов.
PS
Еще один эксперимент: сделать один из VLAN-ов на сервере Untagged. Это не должно ни на что повлиять (VLAN-ы по прежнему будут разделенны). Будет ли та контора видеть сервер или нет? Если да, то проблема точно с конфигурацией карточки.
PPS
Если Ethereal-ом поснифить (http://www.ethereal.com/) что он покажет? Приходит ли инфа с разных VLAN-ов и в какой форме?
|
| | | | | |
И большой вопрос... 04.02.04 12:37
Автор: StR <Стас> Статус: Elderman
|
сможет ли сервер одним айпишником смотреть в четыре влана...
А все-таки у тебя проблема в структуре сети... Нельзя так делать, неправильно это - отсюда и сложности...
|
| | | | | | |
может ;) 04.02.04 13:51
Автор: nemo Статус: Незарегистрированный пользователь
|
есть три способа - два легитимных (нормальных) и один "хакерский".
Вообще говоря все проблемы как раз из-за того, что в W2K нет нормального понятия subinterface, и Intel ProSet насколько я пока успел выяснить не делает новых "Подключение к локальной сети #x". Хотя последнее утверждение это ещё вопрос...
1) Все хосты во всех VLAN-ах принадлежат сети с одной "широкой" маской.
2) Все хосты принадлежат разным сетям, но на интерфейсе сервера назначены несколько IP адресов. Тут могут быть проблемы (в виде существенных задержек) если сервер должен инициировать соединение (например используются сервисы на базе RPC или FTP в активном режиме). Если же сервер только отвечает на запросы (т.е не шлёт SYN пакетов), то всё будет нормально.
3) Наконец "хакерский" способ: если сервер указать в качестве Default Gateway, а при этом его IP лежит вне любой подсети к которой принадлежат клиенты, то у модуля маршрутизации Win2K есть одна интересная особенность которой можно воспользоваться для решения проблемы: а именно если шлюз по умолчанию (default gateway) не лежит в той же подсети что и IP адрес хоста, то нормальные системы сообщили бы об ошибке конфигурации или написали no route to host, однако Win2K прежде чем "обломаться" пошлёт ARP запрос с IP адресом шлюза по умолчанию... Если ответ не придёт, то винда обломается, а если ответ придёт, то он начнёт работать как нивчём небывало пересылая все пакеты не принадлежащие его подсети на этот шлюз, который тоже не лежит в его подсети. Вообще это неплохой способ заморочить голову многим админам... ;)
Вот такие вот пироги.
|
| | | | | | | |
дополнение... 04.02.04 14:17
Автор: nemo Статус: Незарегистрированный пользователь
|
Сейчас испытал на Intel PRO Set II как работает создание VLAN-ов
Всё очень просто.. Каждый новый VLAN создаёт в Network Connections новый сетевой интерфейс, для которого можно назначить привязки служб, свой IP адрес и маску... а также прочие настройки присущие нормальному сетевому интерфейсу....
Таким образом это ничуть не хуже subinterface-ов в FreeBSD (OpenBSD) или Cisco.
Жаль только, что у Windows (даже 2003) Scope DHCP-сервера нельзя привязывать к интерфейсам, только весь сервер целиком. Та же проблема с DNS - зоны нельзя привязывать к интерфейсу как это можно делать в BIND-е. Это жаль... Кстати порт BIND есть и для Windows и весьма прилично надо сказать работает.
|
| | | | | |
согласен. см. мои посты ниже. 04.02.04 10:11
Автор: nemo Статус: Незарегистрированный пользователь
|
|
|
| | |
ещё мысль... 03.02.04 10:25
Автор: nemo Статус: Незарегистрированный пользователь
|
Я так подозреваю, что раньше у тебя это могло работать, т.к твои старые девайсы по умолчанию при включении режима поддержки VLAN 802.1q приписывали все порты к дефолтному VLAN (VLAN1). А 4400 это не делает по умолчанию, и ты явно должен переводить порт в одно из трёх состояний:
1) untagged - не участвует в 802.1q VLAN-ах и не поддерживает энкапсуляцию 802.1q.
2) tagged - маркирует все приходящие от устройства на порт фреймы выбранным тобой тегом. Удаляет из всех отсылаемых устройству фреймов теги 802.1q. Выдаёт устройству только те фреймы, тег у которых совпадает с номером VLAN этого порта и с учётом таблицы MAC.
3) truk - пересылает все маркированные 802.1q фреймы без фильтрации по полю тега, но естественно с учётом таблиц MAC.
Таким образом полагаю, что логично подключать станции к tagged портам, а Сервера с спецовыми карточками понимающими 802.1q к trunk-портам. При этом untagged порты это как бы отдельный port-based VLAN и все кто в них включены НИКАК не будут взаимодейстововать с теми кто в портах tagged или trunk.
|
| | | |
Не совсем так... 04.02.04 08:15
Автор: void <Grebnev Valery> Статус: Elderman
|
> Я так подозреваю, что раньше у тебя это могло работать, т.к
> твои старые девайсы по умолчанию при включении режима
> поддержки VLAN 802.1q приписывали все порты к дефолтному
> VLAN (VLAN1). А 4400 это не делает по умолчанию, и ты явно
> должен переводить порт в одно из трёх состояний:
> 1) untagged - не участвует в 802.1q VLAN-ах и не
> поддерживает энкапсуляцию 802.1q.
> 2) tagged - маркирует все приходящие от устройства на порт
> фреймы выбранным тобой тегом. Удаляет из всех отсылаемых
> устройству фреймов теги 802.1q. Выдаёт устройству только те
> фреймы, тег у которых совпадает с номером VLAN этого порта
> и с учётом таблицы MAC.
> 3) truk - пересылает все маркированные 802.1q фреймы без
> фильтрации по полю тега, но естественно с учётом таблиц
> MAC.
Всё делаю только руками, явно задаю, проверяю и перепроверяю своиства портов.
>
> Таким образом полагаю, что логично подключать станции к
> tagged портам, а Сервера с спецовыми карточками понимающими
> 802.1q к trunk-портам. При этом untagged порты это как бы
> отдельный port-based VLAN и все кто в них включены НИКАК не
> будут взаимодейстововать с теми кто в портах tagged или
> trunk.
Нет. Так не делают. Рабочие станции принято подключать к untagged портам.
К tagged портам подключают девайсы с разделяемыми ресурсам.
И это не моё мнение. Это "картинки" и рекоментадии гайдов к железкам телесина и 3com-a.
Разумеется здесь не имеются ввиду более сложные схемы использования VLAN c поддержкой VGRP.
|
| | |
так, мысль одна... 03.02.04 10:16
Автор: nemo Статус: Незарегистрированный пользователь
|
Я не большой спец в 4400, помню только что они поддерживают стандарт PoE (Power over Ethernet) в добавок ко всем функциям 4300, но мысль у меня тут одна появилась.... может я и не прав.
Насколько я смутно припоминаю свои курсы и общее образование на Cisco Catalyst 2950, то 802.1q потры, т.е те порты которые маркируют все исходящие пакеты ISL тегами могут работать только с теми портами (сетевыми устройствами) которые воспринимают эти теги.
Т.е если ты приписываешь какой-то порт к VLAN1 режима 802.1q, то фреймы приходящие на этот порт с какого-то устройства будут маркироваться коммутатором тегом 1. Все фреймы выдаваемые на этот порт должны обязательно содержать тег 1, при этом при передаче на этот порт поля тега будет удаляться из фрейма.
Если порт переведён в режим 802.1q TRUNK, то через этот порт будут передаваться фреймы с любыми тегами.
При этом если к TRUNK порту подключен другой коммутатор своим TRUNK портом, то он будет выбирать из общего потока только те фреймы в которых есть в поле тега номер одного из зарегистрированных на этом конкретном коммутаторе VLAN и если на нём есть ещё порты в режиме TRUNK, то коммутатор будет передавать на них ВСЕ пакеты пришедшие с других TRUNK портов (ну конечно с учётом таблиц MAC-адресов).
Если к TRUNK порту подключен девайс, сетевой интерфейс которого понимает энкапсуляцию 802.1q, то этот девайс может настроиться на получение пакетов только тех VLAN теги которых он знает и хочет получать.
Все остальные варианты не канают.
|
| | | |
Всё, что Вы написали - абсолютно правильно. Согласен.
04.02.04 07:53
Автор: void <Grebnev Valery> Статус: Elderman
|
Всё, что Вы написали - абсолютно правильно. Согласен.
Ниже только мои коментарии, а в корень я ответил дополнительную дополниетльной инфой.
Мои коментарии связаны с тем, что терминология, принятая у цисок,
телесинов и 3ком - несколько различается.
>
> Если порт переведён в режим 802.1q TRUNK, то через этот
> порт будут передаваться фреймы с любыми тегами.
>
Под TRUNK телесины и 3Com (а кажется, что и hp ) понимают группу портов с повышенной полосой пропускания. Можнов_той_терминологии объединить несколько портов в TRUNK для повышения "скорости" обмена между портами, входящими в TRUNK.
Таким образом TRUNK аналог tagged, как мне кажется.
> При этом если к TRUNK порту подключен другой коммутатор
> своим TRUNK портом, то он будет выбирать из общего потока
> только те фреймы в которых есть в поле тега номер одного из
> зарегистрированных на этом конкретном коммутаторе VLAN...
Именно так ведёт себя tagged-порт с подключённым к нему NIC c поддержкой (на NIC) 802.1q. На tagged-порту не будут дропиться
те кадры, которые в заголовке имеют ID одного из VLAN. Но!!! Только
тех, в которые данный порт входит в качестве tagged (tagged-порт может быть прописанным в нескольких одновременно, в отличии от untagged портов, которые могут входить только в один из виланов) .
>
> Если к TRUNK порту подключен девайс, сетевой интерфейс
> которого понимает энкапсуляцию 802.1q, то этот девайс может
> настроиться на получение пакетов только тех VLAN теги
> которых он знает и хочет получать.
>
Согласен. Немного об этом и выше. Однако непонятна ещё такая вещь....
IEEE 802.1q - не имеет отношения ко всему, что начинается с сетевого уровня и выше OSI.
Но!!! Вот примеры из моей практики, и думаю что другие админы здесь согласятся.
1) Когда настраиваешь сабинтерфейсы FreeBSD на одном единственном (физически) NIC для вилан, то длякаждогосабинтерфейса_ необходимо было прописывать IDs VLANs. Грубо говоря, тем самым мы говорили карточке, которая подключена к tagged-порту свича:"Получай ethernet кадры (т.е. передавай дровам дальше) от таких VLAN, если в заголовке будут ID=2, ID=4 и т.д. На другие кадры на этом NIC - не реагируй (отбрасывай)".
2) Когда настраиваешь интерфейс хоста W2k, подключённого к tagged порту - всего этого не надо. Достаточно в свойствах карточки только добавить поддержку IEEE802.1q.
И 1) и 2) - работают. Однако, не понятны два возможно взаимосвязанных вопроса.
Зачем на FreeBSD для tagged дополнительно "рассказывать" про ID "допустимых" виланов, когда это и так прописано на свиче
(на свиче и так прописано, что tagged - порт с интерфейсом NIC FreeBSD входит в качестве tagged в VLAN1, 2, .... ) ?
Второе, что не ясно - как W2k работает прекрасно на tagged порту, когда на карточке ничего общего с FreeBSD не прописывается ?
Никаких сабинтерфейсов. Ничего. Всё работает;)) Как?
|
| | | | |
ещё про VLAN, W2K и GVRP. 04.02.04 09:54
Автор: nemo Статус: Незарегистрированный пользователь
|
Дополнительное изучение Intel PRO Set II показало, что он поддерживает GVRP (GARP VLAN Registration Protocol) - этот протокол поддерживают не все коммутаторы. Этот протокол позволяет динамически управлять VLAN-ами и членством в них. Я полагаю что на других коммутаторах, где у Вас это всё работало, возможно был включён протокол GVRP.
А вот выдержка из хелпа:
Because there are different implementations of GVRP, enabling GVRP on the adapter does not guarantee GVRP compatibility between network devices. If GVRP does not seem to be functioning, disable GVRP on the adapter.
|
| | | | |
хм.. добавление Subinterface-ов в w2k 04.02.04 09:45
Автор: nemo Статус: Незарегистрированный пользователь
|
У себя в сетке я не применял пока VLAN-ы на основе фреймов 802.1q. Развернуть такую конфигурацию на моём испытательном стенде сложно - нет свободного коммутатора с поддержкой 802.1q, поэтому извиняюсь что даю советы в слепую.
Однако на многих моих серверах стоят по 2-е интегрированные карты Intel PRO 100 Server Adapter или Intel PRO 1000 Server Adapter. Для использования всех их возможностей (в частности Adaptive Load Balansing) я обязятельно ставлю Intel PRO Set II посвежее (8.0.0.0 и 8.2.1.0). Кстати, если интересно, могу рассказать про один весьма интересный глюк с картами Intel и старыми версиями Intel PRO Set II.
Так вот изучение настроек "родных" драйверов Intel PRO Set II Версии 8.0.0.0 и выше показало:
1) Включение 802.1q энкапсуляции производиться на конкретном адаптере если он не в группе или на группе (параметр QoS Packet Tagging).
2) Для управления тем, какие VLAN "видит" адаптер используется настройка: главное меню Action->Add VLAN.
Если не включать инкапсуляцию 802.1q на шаге 1, то при настройке 2 она будет включена автоматически на всех адаптерах (это всё из Help-а в Intel PRO Set).
Вывод: включение только параметра драйвера QoS Packet Tagging на адаптере или на группе не вносит сетевую карту ни в один VLAN 802.1q.
Для корректной работы с VLAN 802.1q обязательно нужно ставить "родные" драйверы от Intel под названием Intel PRO Set II.
|
|
Извините, что ору... 02.02.04 05:50
Автор: void <Grebnev Valery> Статус: Elderman
|
... но правда - очень надо.
Понятно, что влом, но всё же хелп ми, пожалуйста.
|
| |
Товарищь void
10.02.04 11:57
Автор: XerX Статус: Незарегистрированный пользователь
|
Товарищь void
как человек долгое время работавший с 3com
могу официально заявить что сетевухи серии 3c905b НЕ ПООДЕРЖИВАЮТ 802.1q
вот если бы 3com980 (серверные) -то там в настройках сетевой МОЖНО указать виртуальные интерфейсы, привязать их к VLAN ID, и назначить каждому свой IP
|
|
|
подробно о проекте
Анализ криптографических сетевых...
