Trunk port VLAN-ов и нетегированный трафик...

[gorec2005]

Подскажите каким (стандартным) должно быть поведение trunk порта для нетегированного трафика?

1.входящий тегировать тегом PVID исходящий для PVID растегировать

2.отбрасывать совсем нетегированный трафик

3.входящий тегировать тегом PVID исходящий для PVID пропускать тегированным

4.?

5.?

 

 

802.1Q читал - но однозначного ответа не нашел, У кого какой опыт есть в этом

да, забыл - это все относительно свитчей 2-го уровня.

Пытаюсь найти истину вопроса... - посоветуйте где ее поискать?

[SergeiK]

Есть такое понятие - native vlan.

Именно он и идет (иногда) и принимается негериванным.

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

Cisco - by default - 1 влан native.

[gorec2005]

Есть такое понятие - native vlan.

Именно он и идет (иногда) и принимается негериванным.

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

Cisco - by default - 1 влан native.

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

[SergeiK]

Зависит от настроек.

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

Нетэгированный влан на порту может уходить только один и он же назначается на нетегированный пакеты.

 

Немного иначе, и, по мне сильно проще и удобнее это у Cisco происходит, но логика та же.

 

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

[gorec2005]

Зависит от настроек.

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

Хотелось бы уточнить - речь идет о коммутаторах второго уровня? если можно конкретные модели.

 

Нетэгированный влан на порту может уходить только один и он же назначается на нетегированный пакеты.

Прошу уточнить - порт типа trunk тегирует нетегированные пакеты на входе в свитч с tag=PVID

и растегирует пакеты с tag=PVID при выходе из этого порта, одновременно с пропуском тегированного трафика (с указанными тегами) через этот порт в обоих направлениях - я правильно понимаю?

Немного иначе, и, по мне сильно проще и удобнее это у Cisco происходит, но логика та же.

 

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

[vIv]

Ну например RUBY ES-2126C, ES-2310C - отдельный параметр "что делать с нетегированными пакетами"

[Nag]

В общем случае - чем более кривую систему изобретете сейчас, тем больнее она по вам ударит в будущем. ;-)))

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

[gorec2005]

В общем случае - чем более кривую систему изобретете сейчас, тем больнее она по вам ударит в будущем. ;-)))

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

А где почитать про "не кривую" доходчиво?

и что означает "базовые варианты"? -

в базовом варианте нет нетегированного трафика?

или диодная(в одну сторону тег добавляется а обратно не снимается) обработка нетегированного трафика есть норма?

[Nag]

На сколько понимаю, в "базовом" варианте на транковом порту вообще не должно быть нетегированного трафика. ;-)

И не очень понимаю, зачем искусственно создавать себе грабли с иными вариантами. ;-)

[ayamb]

Изначально кривоватую систему изобрели приняв стандарт 802.1Q. Естественно по настоятельным рекомендациям большинства ведущих производителей. В этом стандарте поле VID в пакете идет после полей MAC, якобы для совместимости... И якобы совместимостью этой еще не перестают пользоваться производители левых коммутаторов дуря головы доверчивых потребителей. Эта последовательность полей нарушает всю логику построения VLAN. Почему MAC и физический порт и на сей день занимает лидирующее положение перед VID у подавляющего числа производителей, небрежно выбирая, - поддерживать им VLAN или нет, и, если да, то в каком виде? Зачем нормальному коммутатору знать MAC пакета, если он еще не знает его VID? Поле VID, как де-факто, играет роль некоторого расширения поля MAC для коммутации пакета и роль субинтерфейса c инкапсуляцией dot1q физического порта для его маршрутизации. Теперь представьте, что поле VID занимало бы главенствующее положение перед полями MAC. А VLAN включала бы порты в себя, а не принадлежа ла бы портам в том виде, в котором этим портам захочется. Так ли бы уж были востребованы разного рода тунели и каналы в сетях EtherNet?.. Ой,.. о чем это я?.. Аааа… :) фигня всякая, но стирать не буду… :)

[gorec2005]

На сколько понимаю, в "базовом" варианте на транковом порту вообще не должно быть нетегированного трафика. ;-)

И не очень понимаю, зачем искусственно создавать себе грабли с иными вариантами. ;-)

Я прошу прощения, но объясните мне пожалуйста почему вариант trunk порта без нетегированного трафика есть "базовый", на основании чего? кем или чем (каким документом,rfc...) регламентируется этот момент? или это просто "устоявшееся" понятие, тогда зачем придумывали вообще 802.1Q со всеми его наворотами - остановились бы на port-based и все - устоялось же...

Чем дальше, тем интереснее - у кого не спрашиваю - никто доходчиво объяснить не может - все говорят, кто как понимает, и причем самое любопытное большинство говорит про какие-нибудь основопологающие вещи, но кроме 802.1Q (где я ответа не нашел - может плохо искал?) ни на что не ссылаются :-((( - ну помогите пожалуйста - не дайте погибнуть неучем!!! Знаний хочу!

 

И не очень понимаю, зачем искусственно создавать себе грабли с иными вариантами. ;-)

а почему грабли? - согласен схема не совсем стандартная, но (в кач. примера) по моему мнению использовать старый, военный кабель в роли витой пары для пропуска езернет трафика на расстояния бОльшие заявленного в стандарте (а вдруг заработает - и ведь работает-же!) ради экономии(в первую очередь!) это ли не изврат? - ведь гораздо правильнее оптику положить... - а форум изобилует и сообщениями про кабель и обзоры про него нередки... вот и выходит - кто может(читай знает, умеет,хочет) извлечь максимум возможности при минимуме капиталовложений (компенсируя иногда находчивостью, иногда нестандартными знаниями, а иногда интуицией) тот и испытывает от этого радость в жизни - от результата. И я думаю любой сисадмин (активно развивающейся структуры) каждый день сталкивается с необходимостью что-нибудь выдумывать, мастерить, программировать - это все из пионэрии ноги растут - кто-то этим переболел, а кто-то вечно остается "молодым" - возможно я из таких :-) - ну все мне интересно...

[gorec2005]

Изначально кривоватую систему изобрели приняв стандарт 802.1Q. Естественно по настоятельным рекомендациям большинства ведущих производителей. В этом стандарте поле VID в пакете идет после полей MAC, якобы для совместимости... И якобы совместимостью этой еще не перестают пользоваться производители левых коммутаторов дуря головы доверчивых потребителей.

Это почему 802.1Q кривоватая? - жесткая да, но это в основном из-за того, что езернет фрейм не резиновый :-) а возможностей в этой спецификации заложено не мало! - одни только стп овер влан и динамические влан-ы чего стоят бррр - я даже разбираться с этим пока не стал :-)

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

Эта последовательность полей нарушает всю логику построения VLAN. Почему MAC и физический порт и на сей день занимает лидирующее положение перед VID у подавляющего числа производителей, небрежно выбирая, - поддерживать им VLAN или нет, и, если да, то в каком виде? Зачем нормальному коммутатору знать MAC пакета, если он еще не знает его VID? Поле VID, как де-факто, играет роль некоторого расширения поля MAC для коммутации пакета и роль субинтерфейса c инкапсуляцией dot1q физического порта для его маршрутизации. Теперь представьте, что поле VID занимало бы главенствующее положение перед полями MAC.

а какая разница кто первый кто второй - все равно фрейм дожен приняться целиком, а уже потом на основании заголовка дожно быть принято решение о его "vlan-маршрутизации"

А VLAN включала бы порты в себя, а не принадлежа ла бы портам в том виде, в котором этим портам захочется.

Ну насколько я понимаю в dlink 3226 примерно так и сделано(или я ошибаюсь?)

[SergeiK]

А в моем посте что было не понятно-то?

 

Прямая схема - когда тот трафик, что уходит в порт нетэгированным во влане X и приходит обратно в том же влане, или негерированным и попадает во влан X.

 

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

 

Умееют отдавать нетэгированным один влан в порт dlink, HP procurve, Allied Telesys точно... Этот же влан назначается на негэгированные пакеты. Конечно, это все L2 коммутаторы.

 

Как делает cisco внутри себя - может быть Nailer рассказал бы.

Но для нас важно, что naitve влан уходит нетэгированный. Нетегированный трафик с этого порта приходит тоже в native влан.

Да, если трафик тегирован native-вланом, это тоже работает.

 

В общем-то, все просто.

 

 

Что касается того, как должно быть в идеале - Cisco сначало придумала ISL, где нет нетегированных пакетов и более того, тегированные пакеты закрывались своим CRC. Мировому сообществу не понравилось, "Ресурсов пересчитывать CRC не обеерешься!" сказали они. Нам бы что попроще... Так получился 802.1q

 

И у него есть один важный нюанс. Если позволяет размер MTU, то 802.1q трафик обрабатывается обычными свичами и бриджами... С точки зрения реальности - это хорошо, хотя архитектурно - не верно абсолютно!

 

В общем, мы работаем с тем что есть, а те, кто хочет сделать мир лучше может попробовать записаться в нужную группу IEEE 802.1 и сделать свой новый супер эзернет, и все тогда скажут: "Вот это да! Ну нах 802.1q, QinQ, MACinMAC, будет пользоваться новым протоколом ибо он рулез форева!".

[Nag]

ачем нормальному коммутатору знать MAC пакета, если он еще не знает его VID? Поле VID, как де-факто, играет роль некоторого расширения поля MAC для коммутации пакета и роль субинтерфейса c инкапсуляцией dot1q физического порта для его маршрутизации. Теперь представьте, что поле VID занимало бы главенствующее положение перед полями MAC. А VLAN включала бы порты в себя, а не принадлежа ла бы портам в том виде, в котором этим портам захочется.

Видимо потому, что тогда виланы считались второстепенной подпоркой. ;-) А большая часть трафика коммутировалась свитчами-вилана-не-помнящими. ;-)

 

а почему грабли? - согласен схема не совсем стандартная, но (в кач. примера) по моему мнению использовать старый, военный кабель в роли витой пары для пропуска езернет трафика на расстояния бОльшие заявленного в стандарте (а вдруг заработает - и ведь работает-же!) ради экономии(в первую очередь!) это ли не изврат?

В том-то и дело, то в случае неправильных виланов никакой особой экономии не видно. ;-) Разве что экономия на образовании... :-)