Перейти до

Vlan и неуправляемый свитч


Рекомендованные сообщения

  • 3 months later...

Некропост, но всё же:

 

Свич хоть и тупой, но таблица коммутации в нём-то всё равно присуща в отличие от хаба.

А теперь вопрос: на какой порт будет отправлен инкапсулированый в 802.1q ? Где свич увидит мак получателя, если фрейм инкапсулирован в непонятный ему протокол?

 

 

П.С. это домыслы по теории, на практике такого не доводилось делать.

Ссылка на сообщение
Поделиться на других сайтах

Некропост, но всё же:

 

Свич хоть и тупой, но таблица коммутации в нём-то всё равно присуща в отличие от хаба.

А теперь вопрос: на какой порт будет отправлен инкапсулированый в 802.1q ? Где свич увидит мак получателя, если фрейм инкапсулирован в непонятный ему протокол?

 

 

П.С. это домыслы по теории, на практике такого не доводилось делать.

Так как 802.1Q не изменяет заголовки кадра (фрейма), то сетевые устройства, которые не поддерживают этот стандарт, могут передавать трафик без учёта его принадлежности к VLAN.

 

Почитайте википедию хоть

Ссылка на сообщение
Поделиться на других сайтах

Некропост, но всё же:

 

Свич хоть и тупой, но таблица коммутации в нём-то всё равно присуща в отличие от хаба.

А теперь вопрос: на какой порт будет отправлен инкапсулированый в 802.1q ? Где свич увидит мак получателя, если фрейм инкапсулирован в непонятный ему протокол?

 

 

П.С. это домыслы по теории, на практике такого не доводилось делать.

 

Теория говорит, что тег добавляется ПОСЛЕ МАС-ов, т.к. 99.9% тупарей работают по Cut-through схеме коммутации, то до тега дело даже не доходит.... так что протокол оные вообще не анализируют.

Ссылка на сообщение
Поделиться на других сайтах

Так как 802.1Q не изменяет заголовки [/size]кадра (фрейма), то сетевые устройства, которые не поддерживают этот стандарт, могут передавать трафик без учёта его принадлежности к VLAN.[/size]

 

Почитайте википедию хоть

Не верьте всему что пишут в интернете, даже если это википедия.

802.1Q увеличивает размер фрейма на 4 байта, и будет тупая железка пропускать такой трафик или нет зависит сугубо от ее дизайна(фактически - какой MTU на интерфейсах выставлен). Видел своими глазами медиаконвертор не пропускающий тегированный трафик, как вам такой вариант? :)

Ссылка на сообщение
Поделиться на других сайтах

Дело скорее всего не в MTU (иначе - мелкие пакеты бы ходили а большие дропались).

Любой чип в любом тупаре поддерживает вланы. Ограниченное кол-во, конфигурируемое через еепром/внешним процом, так что с мту граблей не вылезет.

А медиаконвертор - скорее всего на его чипе свича как раз и был сконфигурен один влан... Ессно, qinq свич не умеет, и левые вланы дропает, пропуская только нетегированные пакеты.

Ссылка на сообщение
Поделиться на других сайтах

Дело скорее всего не в MTU (иначе - мелкие пакеты бы ходили а большие дропались).

А оно насколько я помню так и происходит, мелкие пакеты бегают, а ничего не работает, одноглазники не открываются. Тупой свич ведь сам по себе выдрать(обрезать, удалить) тег из пакета в принципе не может.
Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від SanKo_mn
      У зв'язку з переходом на ПОН звільняються комутатори.
      Маємо:
      Alkatel 6850U24X       2
      Alkatel OS 6250-24 M      8
      D-LINK DES - 1210-28      1
      D-LINK DES - 1228       10
      D-LINK DES 1210-10       1
      D-LINK DGS - 1210-12 TS\ME     2
      TP-LINK - T 1500-28 TC      1
      TP-LINK - TL SL 2218 WEB      1
      HUAWEI - S2403TP -ЕU    1
      DELL - 3548    1
      TP-LINK TL-SL2210WEB    3
      D-LINK DES 3120-24SC    1
      D-LINK DES 1100-26   1
      HUAWEI - S2326TP    2
       
      Кількість і моделі весь ча змінюються - бо знімаються чергові)))
       
      Пишіть в особисті, що цікаво - за кількість і вартість будемо домовлятися)
    • Від ibrokeit
      Вітаю!
      Зіштовхнулися з проблемою із вланами на ZTE C300 (2.1.0) GTGHK.
      Загалом все працює нормально, але в окремих вланах просто перестає бігати трафіг, на ону відстутні мак-адреси, хоча статус порта full-1000.
      Якщо із таким же конфігом перевести ону в інший влан — все починає працювати (до певного часу). Виглядає так, що спрацьовує якесь блокування по номеру влану на рівні spanning-tree або детектора кілець (перше відключено, інше, якщо відключати — ситуацію не міняє).
      Чи може хтось підказати в якому напрямі копати рішення проблеми?
      Дякую
    • Від FosterUA
      Последних 2-3 дня начались отваливатся обладатели моделей Tp-Link 841 от Микротика с авторизацией пппОе. Хаотично по разным БД-КОМАМ. Не знаем где копать ?
    • Від Georgianairlink
      нужен OID, чтобы увидеть это с помощью snmp
      interface TGigaEthernet0/1 description test switchport trunk vlan-allowed 352,362,365,509,514-515,518,528,565-566,590 switchport trunk vlan-allowed add 720-723,1543-1546,2021,2201,2208,2378,2441 switchport trunk vlan-untagged 1 switchport mode trunk  
    • Від subhan
      У нас есть сервер Ubilling. к которому соединены 5 брасов. Каждый Nas работает по отдельному влану. В вланах браса в определенное время мы видим пустой трафик который поднимается. Например в норме если 200мб то 500мб. В влане котором видится пустое поднятие трафика, также и поднимается трафик во всех портах свитча. Это исправляется на время только при ребуте определенного Nas. Проблема раньше была только в одном Nas-э, щас и на других Nas-ах тоже данная проблема. Это проблема только наблюдается во вланах которые подключены в Ubilling.

      Можете пожалуйста, помочь в данной проблеме.
×
×
  • Створити нове...