 |
问答管理员：
待解决问题
中兴OLT-C300 丢弃MAC地址以"0x02"开始的帧合理么？ (进入论坛模式)
离问题结束还有0天0小时 |
提问者：联通草根
|
提问时间：2012-4-10 16:27
前几天处理BAS故障的时候，发现中兴的 OLT-C300对于MAC地址以"0x02"开始的帧都给丢弃了。原来，Redback的BAS在配置链路捆绑的时候会以“0x02”开始的SA来回应用户的PADI包，即从BAS发出以“0x02”开头的MAC地址的PADO包，而这个帧被中兴的OLT-C300丢弃了......查阅IEEE 802资料发现以“0x02”开头的MAC地址属于“locally administrated”，而这个词到底是什么含义在标准里就没有规定了。
反观其他品牌的OLT，比如 HUAWEI、烽火、贝尔，没有哪个厂家的OLT会进行这样的检查，难道是这些厂家的OLT做的都不规范？还是中兴没事找事呢？
请高人指点。
反观其他品牌的OLT，比如 HUAWEI、烽火、贝尔，没有哪个厂家的OLT会进行这样的检查，难道是这些厂家的OLT做的都不规范？还是中兴没事找事呢？
请高人指点。
问题答案 ( 11 条 )
:lol
还是鬼子热心肠啊！
国外论坛的回复还是快：
Locally administered simply refers to how they are assigned. Universally administered are assigned by the IEEE RA and thus guaranteed globally unique. Locally administered can be assigned by anyone and are typically only guarnteed unique within a LAN (ie., local area network).
还有人说 U/L=1 可以用于任何私有意图构造帧，比如“U/L=1 frames in 802.1aq for algorithmically constucted multicast MAC addresses”。
所以，看到的几个回复都认为ZTE的OLT过滤这个帧是不对的。
国外论坛的回复还是快：
Locally administered simply refers to how they are assigned. Universally administered are assigned by the IEEE RA and thus guaranteed globally unique. Locally administered can be assigned by anyone and are typically only guarnteed unique within a LAN (ie., local area network).
还有人说 U/L=1 可以用于任何私有意图构造帧，比如“U/L=1 frames in 802.1aq for algorithmically constucted multicast MAC addresses”。
所以，看到的几个回复都认为ZTE的OLT过滤这个帧是不对的。
不对能咋的？
严格来说，redback bras链路聚合采用本地分配地址是不对，这个地址是链路聚合子层内部使用的私有mac。如果这个地址作为源地址发出去，就存在私有mac地址到处乱飞的情况。作为LAN还好说，作为MAN，或者多个BRAS使用链路聚合，就也可能存在MAC冲突的情况。
IEEE802.3标准中有明确说明，见下面红色部分文字。
43.2.1 Principles of Link Aggregation
Link Aggregation allows a MAC Client to treat a set of one or more ports as if it were a single port. In doing
so, it employs the following principles and concepts:
a) A MAC Client communicates with a set of ports through an Aggregator, which presents a standard
IEEE 802.3® service interface to the MAC Client. The Aggregator binds to one or more ports within
a System.
b) It is the responsibility of the Aggregator to distribute frame transmissions from the MAC Client to
the various ports, and to collect received frames from the ports and pass them to the MAC Client
transparently.
c) A System may contain multiple Aggregators, serving multiple MAC Clients. A given port will bind
to (at most) a single Aggregator at any time. A MAC Client is served by a single Aggregator at a
time.
d) The binding of ports to Aggregators within a System is managed by the Link Aggregation Control
function for that System, which is responsible for determining which links may be aggregated,
aggregating them, binding the ports within the System to an appropriate Aggregator, and monitoring
conditions to determine when a change in aggregation is needed.
e) Such determination and binding may be under manual control through direct manipulation of the
state variables of Link Aggregation (e.g., Keys) by a network manager. In addition, automatic determination,
configuration, binding, and monitoring may occur through the use of a Link Aggregation
Control Protocol (LACP). The LACP uses peer exchanges across the links to determine, on an ongoing
basis, the aggregation capability of the various links, and continuously provides the maximum
level of aggregation capability achievable between a given pair of Systems.
f) Frame ordering must be maintained for certain sequences of frame exchanges between MAC Clients
(known as conversations, see 1.4). The Distributor ensures that all frames of a given conversation are
passed to a single port. For any given port, the Collector is required to pass frames to the MAC Client
in the order that they are received from that port. The Collector is otherwise free to select frames
received from the aggregated ports in any order. Since there are no means for frames to be misordered
on a single link, this guarantees that frame ordering is maintained for any conversation.
g) Conversations may be moved among ports within an aggregation, both for load balancing and to
maintain availability in the event of link failures.
h) This standard does not impose any particular distribution algorithm on the Distributor. Whatever
algorithm is used should be appropriate for the MAC Client being supported.
[color=red]i) Each port is assigned a unique, globally administered MAC address. This MAC address is used as
the source address for frame exchanges that are initiated by entities within the Link Aggregation
sublayer itself (i.e., LACP and Marker protocol exchanges).
[/color]NOTE—The LACP and Marker protocols use a multicast destination address for all exchanges, and do not
impose any requirement for a port to recognize more than one unicast address on received frames.
j) Each Aggregator is assigned a unique, globally administered MAC address; this address is used as
the MAC address of the aggregation from the perspective of the MAC Client, both as a source
address for transmitted frames and as the destination address for received frames. The MAC address
of the Aggregator may be one of the MAC addresses of a port in the associated Link Aggregation
Group (see 43.2.10).
IEEE802.3标准中有明确说明，见下面红色部分文字。
43.2.1 Principles of Link Aggregation
Link Aggregation allows a MAC Client to treat a set of one or more ports as if it were a single port. In doing
so, it employs the following principles and concepts:
a) A MAC Client communicates with a set of ports through an Aggregator, which presents a standard
IEEE 802.3® service interface to the MAC Client. The Aggregator binds to one or more ports within
a System.
b) It is the responsibility of the Aggregator to distribute frame transmissions from the MAC Client to
the various ports, and to collect received frames from the ports and pass them to the MAC Client
transparently.
c) A System may contain multiple Aggregators, serving multiple MAC Clients. A given port will bind
to (at most) a single Aggregator at any time. A MAC Client is served by a single Aggregator at a
time.
d) The binding of ports to Aggregators within a System is managed by the Link Aggregation Control
function for that System, which is responsible for determining which links may be aggregated,
aggregating them, binding the ports within the System to an appropriate Aggregator, and monitoring
conditions to determine when a change in aggregation is needed.
e) Such determination and binding may be under manual control through direct manipulation of the
state variables of Link Aggregation (e.g., Keys) by a network manager. In addition, automatic determination,
configuration, binding, and monitoring may occur through the use of a Link Aggregation
Control Protocol (LACP). The LACP uses peer exchanges across the links to determine, on an ongoing
basis, the aggregation capability of the various links, and continuously provides the maximum
level of aggregation capability achievable between a given pair of Systems.
f) Frame ordering must be maintained for certain sequences of frame exchanges between MAC Clients
(known as conversations, see 1.4). The Distributor ensures that all frames of a given conversation are
passed to a single port. For any given port, the Collector is required to pass frames to the MAC Client
in the order that they are received from that port. The Collector is otherwise free to select frames
received from the aggregated ports in any order. Since there are no means for frames to be misordered
on a single link, this guarantees that frame ordering is maintained for any conversation.
g) Conversations may be moved among ports within an aggregation, both for load balancing and to
maintain availability in the event of link failures.
h) This standard does not impose any particular distribution algorithm on the Distributor. Whatever
algorithm is used should be appropriate for the MAC Client being supported.
[color=red]i) Each port is assigned a unique, globally administered MAC address. This MAC address is used as
the source address for frame exchanges that are initiated by entities within the Link Aggregation
sublayer itself (i.e., LACP and Marker protocol exchanges).
[/color]NOTE—The LACP and Marker protocols use a multicast destination address for all exchanges, and do not
impose any requirement for a port to recognize more than one unicast address on received frames.
j) Each Aggregator is assigned a unique, globally administered MAC address; this address is used as
the MAC address of the aggregation from the perspective of the MAC Client, both as a source
address for transmitted frames and as the destination address for received frames. The MAC address
of the Aggregator may be one of the MAC addresses of a port in the associated Link Aggregation
Group (see 43.2.10).
楼上兄弟的分析太“专业”了，俺们看不太懂。
但是，爱立信工程师的的说明也很有道理：
“中兴企业对此问题的发现、分析均为事实，且正确。但是，OLT-C300的App代码对‘local administrated address’的理解有误。对于‘local administrated address’在IEEE 802里并没有规定“local”的具体含义，而中兴企业声明的“本地地址不应该出现在跨网段二层网络中”的说法应属于主观臆断，只是从字面意思去理解其含义是不正确的。我企业对“locally administrated address“的理解是“本地网络地址”，这是与“Globally administrated address”对应的。他们的区别可以理解为“公有IP地址”和“私有IP地址”在路由器上的处理，没有哪家的路由器会丢弃”10.x.x.x”的IP包吧？所以二层“本地管理的地址”可以用本地网络 (LAN) 中，即从BRAS下发到PON设备再转发给最终用户，这也是绝大多数数据产品厂商的共识，[u]这也就是为什么爱立信BRAS发出的以“0x02”开头的帧能够被除OLT-C300之外的所有的二层设备所转发的原因[/u]。”
本人不是专家，但对于中兴企业开始给的说法“[color=red]私有MAC不能跨二层设备...[/color]”的说法也表示疑惑。如果按照中兴的说法“[color=red]私有MAC不能跨二层设备...[/color]那么私有MAC还有啥用？难道是给BRAS设备自己用么？
请中兴专家指教。
但是，爱立信工程师的的说明也很有道理：
“中兴企业对此问题的发现、分析均为事实，且正确。但是，OLT-C300的App代码对‘local administrated address’的理解有误。对于‘local administrated address’在IEEE 802里并没有规定“local”的具体含义，而中兴企业声明的“本地地址不应该出现在跨网段二层网络中”的说法应属于主观臆断，只是从字面意思去理解其含义是不正确的。我企业对“locally administrated address“的理解是“本地网络地址”，这是与“Globally administrated address”对应的。他们的区别可以理解为“公有IP地址”和“私有IP地址”在路由器上的处理，没有哪家的路由器会丢弃”10.x.x.x”的IP包吧？所以二层“本地管理的地址”可以用本地网络 (LAN) 中，即从BRAS下发到PON设备再转发给最终用户，这也是绝大多数数据产品厂商的共识，[u]这也就是为什么爱立信BRAS发出的以“0x02”开头的帧能够被除OLT-C300之外的所有的二层设备所转发的原因[/u]。”
本人不是专家，但对于中兴企业开始给的说法“[color=red]私有MAC不能跨二层设备...[/color]”的说法也表示疑惑。如果按照中兴的说法“[color=red]私有MAC不能跨二层设备...[/color]那么私有MAC还有啥用？难道是给BRAS设备自己用么？
请中兴专家指教。
中兴的银都在忙啥子哟？出来说话撒.
[b][size=5]中兴兄弟的上述回应我转给爱立信了，他们的回答是：[/size][/b]
=========================================================================
[size=5]ZTE所引用的标准(802.3 43.2.10)描述了LACP PDU的MAC规则，即两台二层设备进行LACP协商的过程中MAC地址的构造规则。而ZTE C300-OLT的问题是丢弃MAC以0x2开头的PADO包的问题，这完全是两个问题。即此规范之规定不适用PADO中MAC构造规则。[/size]
=========================================================================
[size=6][color=red][b]中兴兄弟，人家说你跑题啦？赶快给看看啊！你贴上来这么多的英文标准，要是真的跑题了的话，那就真的悲催了！[/b][/color][/size]
哇咔咔 我就喜欢
中兴的兄弟你在哪里？
你要是不搭理我，这件事情可就这样下定论了？
你要是不搭理我，这件事情可就这样下定论了？
中兴的兄弟你在哪里？
你要是不搭理我，这件事情可就这样下定论了......
你要是不搭理我，这件事情可就这样下定论了......
原来联通那边的人让厂商分析问题都是在互联网上，好高端，我还是第一次听说啊
而且问题出了几个月了还在帖子上问，联通会这么脓包吗，佩服啊
而且问题出了几个月了还在帖子上问，联通会这么脓包吗，佩服啊
热点问题
Copyright © 1999-2024 C114 All Rights Reserved | 联系大家 | 沪ICP备12002291号 |
