= Сообщение: 2915 из 10763 ===================================== RU.UNIX.BSD = От : Eugene Grosbein 2:5006/1 04 May 15 00:16:10 Кому : Victor Sudakov 04 May 15 00:16:10 Тема : Re: Полностью прозрачный Ethernet туннель FGHI : area://RU.UNIX.BSD?msgid=grosbein.net+b8f60634 На : area://RU.UNIX.BSD?msgid=2:5005/49+5545e1eb = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.UNIX.BSD?msgid=2:5005/49+55476b9d ============================================================================== 03 май 2015, воскресенье, в 13:41 NOVT, Victor Sudakov написал(а):
EG>> Дело в том, что на тему служебных PDU в стандартах много чего EG>> понаписано и, по хорошему, всякие STP нельзя пропускать транзитом EG>> через обычные ethernet-устройства, VS> Как ты считаешь, является ли офисный свич на 16 портов "обычным VS> ethernet-устройством" и должен ли он пропускать или фильтровать служебные PDU? VS> Речь не об офисных свичах, это я спросил для прояснения позиций сторон.
Если мы рассматриваем сеть, в которой бегают (и не просто так, а нужные) фреймы STP BPDU, то в ней не должно быть неуправляемых свичей и под "офисным свичем на 16 портов" мы понимаем управляемый свич и да, он должен обрабатывать такие PDU сам и не пропускать их транзитом.
EG>> эти пакеты должны ходить с одного EG>> физического порта до другого физического порта и не дальше.
VS> Вопрос в том, что считать Ethernet устройством.
Это стандартизированное понятие, формально это 802.1D MAC Bridges.
VS> Мне удобнее,
Увы (или ура), на эту тему давным-давно приняты стандарты.
VS> чтобы каналообразующее оборудование работало с Ethernet-каналами так же, как испокон VS> веков работало с V.35 или E1 каналами: обеспечивало транспорт кадров из пункта A VS> в пункт B. А уж что сделать со служебными кадрами в точке прибытия - я сам решу, VS> например с помощью полноценного Ethernet коммутатора, а не недокомммутатора, VS> встроенного по недоразумению в канальное оборудование. VS> Вот например мультиплексор Nateks позволяет организовать несколько независимых VS> Ethernet каналов, а spanning tree у него в одном экземпляре на весь VS> мультиплексор. Это нормально по-твоему? IMHO лучше уж никак, чем как-нибудь.
Это вопрос использования подходящего оборудования. Если тебе мало одного spanning tree, то не надо использовать оборудование, которое умеет только простейший вариант STP/RSTP, а надо использовать такое, что умеет Multiple Spanning Tree с разными областями или там Per-Vlan Spanning Tree с нужными модификациями. А кому-то такие навороты не нужны, одного дерева достаточно - ему нормально.
EG>> А то, что EG>> тебе хочется, в простейшем варианте называется L2 tunneling, когда EG>> одно устройство (например, коммутаторы Cisco Catalyst это умеют) VS> Вот, хочу эхотаг подобному же научить. Пока дело идет туго, но надежда есть.
L2 tunneling отдельная тема от стандартного MAC Bridging.
Eugene -- Господа Действительного Положения Вещей предохраняют себя от голода своим богатством, от общественного мнения - тайной и анонимностью, от частной критики - законами против клеветы и тем, что средства связи находятся в их распоряжении. (Hорберт Винер) --- slrn/1.0.1 (FreeBSD) * Origin: RDTC JSC (2:5006/1@fidonet)
