Re: strange kernel message when hacking the NIC driver

[Timothy Covell <timothy.covell@ashavan.org>]

On Friday 11 January 2002 13:02, Timothy Covell wrote:
> On Friday 11 January 2002 07:11, Alan Cox wrote:
> > > Let me clarify what I said earlier.  You cannot have
> > > identical MAC addresses on two different NICs.   Indeed,
> > > it is impossible w/o trying to fool the kernel into
> > > redefining the NICs hardware based MAC address.
> >
> > Wrong
> >
> > A mac address is per system. Now in fact almost all systems do it per
> > ethernet card but that is not what the specifications guarantee. There
> > are machines out there and cards out there which use the same MAC on all
> > interfaces. -
>
> IMHO, they _should_ be unique except for multicast addressing and uses
> such as in HSRP/VRRP and such.   Network admins usually like to have
> a firm grip concerning how traffic is routed.  They don't want traffic on
> one segment/subnet getting routed to another.  IHMO, this is a vector
> for viruses proliferation because the host vulnerable thinks that all
> segments/subnets are the same.
>
>

OK, here are some snippets which I found from reading the IEEE 802.x
standards.   As far as I can see, the only justification for your and Sun's
(OpenBootProm) method is to assume that all ports will be aggregated.

IEEE 802:
---------
However, due to the shared-medium nature of the IEEE 802 LANs, there is 
always a MAC Sublayer.


IEEE 802:
---------

5.1 Organizationally Unique Identifier 
5.1.1 Concept. 

Organizationally Unique Identifiers allow a general means of assuring unique 
identifiers for a 
number of purposes. Currently, the IEEE assigns Organizationally Unique 
Identifiers to be used 
for generating LAN MAC addresses and protocol identifiers. Assuming correct 
administration by 
the assignee, the LAN MAC addresses and protocol identifiers will be 
universally unique.



IEEE 802.1D
-----------

a) A Bridge is not directly addressed by communicating end stations, except 
as an end station for
management purposes: frames transmitted between end stations carry the MAC 
Address of the peer-end
station in their Destination Address field, not the MAC Address, if any, of 
the Bridge. 

b) All MAC Addresses must be unique within the Bridged LAN. 

c) The MAC Addresses of end stations are not restricted by the topology and 
configuration of the Bridged LAN.


IEEE 802.1G 
-------------

Preservation of the MAC service The MAC service offered by a remotely bridged 
LAN is 
similar (see 5.3) to that offered by a single LAN. In consequence 

a) A bridge is not directly addressed by communicating end stations, except
as an end station for management purposes: frames transmitted between end 
stations carry the MAC address of the peer end station in their Destination 
Address fields, 
not the MAC address, if any, of a bridge. 

b) All MAC addresses are unique and addressable within the bridged LAN. 

c) The MAC addresses of end stations are not restricted by the topology and 
configuration of the bridged LAN.


IEEE 802.1Q
----------------
B.1.2 Duplicate MAC Addresses 

The simplest example of a need for Independent VLAN Learning occurs where
two (or more) distinct devices in different parts of the network reuse 
the same individual MAC Address, or where a single device is connected to 
multiple LAN segments, and all of its LAN interfaces use the same individual 
MAC Address. This is shown in Figure B-3.


[picture ommitted for obvious reasons]

The example shows two clients with access to the same server; both clients 
are using the same individual MAC Address, X. If the Bridge shares learning 
between VLAN Red (which serves Client A) and VLAN Blue (which serves Client 
B), 
i.e., the Bridge uses the same FID for both VLANs, then Address X will appear 
to 
move between Ports 1 and 2 of the Bridge, depending upon which client has 
most recently 
trans-mitted a frame. Communication between these Clients and the server will 
therefore 
be seriously disrupted. Assignment of distinct FIDs for Red and Blue ensures 
that 
communication can take place correctly.




IEEE 802.3
----------  
The only thing which I could find that supported you and Sun's
position is in using LACP.  Then, one uses the SystemID 
(the hostid from eeprom, or one of the port's MAC).  So, if you are
assuming that all ports should belong to an aggregate group by
default, then I could understand this point.  However, the vast
majority of system's NICs (aside from the QFE cards) are never
aggregated.  So, it's a bit of a stretch to using LACP as a default.

Quotations:


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). 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).



43.2.8 Aggregator An Aggregator comprises an instance of a Frame Collection 
function,
an instance of a Frame Distribution function and one or more instances of the 
Aggregator 
Parser/Multiplexer function for a Link Aggregation Group.A single Aggregator 
is associated 
with each Link Aggregation Group.  An Aggregator offers a standard IEEE 802.3 
MAC service 
interface to its associated MAC Client;access to the MAC service by a MAC 
Client is always 
achieved via an Aggregator. An Aggregator can therefore be considered to be a 
logical MAC ,
bound to one or more ports,through which the MAC client is provided access to 
the MAC service. 
A single,individual MAC address is associated with each Aggregator (see 
43.2.10). An Aggregator is 
available for use by the MAC Client if the following are all true: 

a)It has one or more attached ports. 
b)The Aggregator has not been set to a disabled state by administrative 
action (see 30.7.1.1.13).
c)The collection and/or distribution function associated with one or more of 
the attached ports is 
enabled (see 30.7.1.1.14). 

NOTE  To simplify the modeling and description of the operation of Link 
Aggregation,it is assumed that 
there are as many Aggregators as there are ports in a given System; however, 
this is not a requirement 
of this standard.Aggregation of two or more ports consists of changing the 
bindings between ports and 
Aggregators such that more than one port is bound to a single Aggregator.The 
creation of any aggregations 
of two or more links will therefore result in one or more Aggregators that 
are bound to more than one port,
and one or more Aggregators that are not bound to any port.An Aggregator that 
is not bound to any port appears 
to a MAC Client as a MAC interface to an inactive port.During times when the 
bindings between ports and Aggregators a
re changing,or as a consequence of particular con  guration choices, there 
may be occasions when one or more ports 
are not bound to any Aggregator.

43.2.10 Addressing Each IEEE 802.3 MAC has an associated globally-unique 
individual MAC address,whether that MAC 
is used for Link Aggregation or not (see Clause 4). Each Aggregator to which 
one or more ports are attached has 
an associated globally-unique individual MAC address (see 43.3.3).The MAC 
address of the Aggregator may be the 
globally-unique individual MAC addresses of one of the MACs in the associated 
Link Aggregation Group,or it may 
be a distinct MAC address.The manner in which such addresses are chosen is 
not otherwise constrained by this standard. 
Protocol entities sourcing frames from within the Link Aggregation sublayer 
(e.g.,LACP and the Marker protocol)use the 
MAC address of the MAC within an underlying port as the source address in 
frames transmitted through that port.The MAC 
Client sees only the Aggregator and not the underlying MACs,and therefore 
uses the Aggregator  s MAC address as the source 
address in transmitted frames.If a MAC Client submits a frame to the 
Aggregator for transmission without specifying a 
source address,the Aggregator inserts its own MAC address as the source 
address for transmitted frames.



RFC 826:
--------

However, 48.bit Ethernet addresses are supposed to be unique and fixed for 
all time, so they shouldn't
change.


>From the Ethernet FAQ:
----------------------

02.10Q: What is a MAC address?
A: It is  the unique hexadecimal serial number assigned to each Ether-
net  network device to identify it  on  the network.  With Ethernet
devices  (as  with  most other  network  types),  this  address  is
permanently set at  the time of manufacturer, though it can usually
be changed  through  software (though this is  generally a Very
Bad Thing to do). 

02.11Q: Why must the MAC address to be unique?  

A: Each card  has  a  unique MAC address,  so  that
it will be able to exclusively  grab  packets  off the wire
meant  for  it.   If  MAC addresses are not unique,  there is 
no  way  to distinguish between two  stations.  Devices on the 
network  watch  network traffic and look for their own MAC address 
in each packet to determine whether they should decode  it or  not.
Special circumstances exist  for broadcasting to every device.

04.01Q: What is a "segment"?
A: A  piece of network wire bounded by bridges,  routers, repeaters or
terminators. 

04.02Q: What is a "subnet"?
A: Another overloaded  term. It can  mean, depending on  the usage,  a
segment, a set of machines  grouped together by a specific protocol
feature  (note  that  these machines do not have to be on  the same
segment, but they could be) or a big  nylon  thing used  to capture 
enemy subs.


-- 
timothy.covell@ashavan.org.