Subject: Re: [dc] Requirement for a method to manage mac address in DC

From: Thomas Narten <[email-masked]>
Date: Thu, 02 Feb 2012 10:09:40 -0500

Lizhong Jin <[email-masked]> writes:

> The VMs connected by SPB-M or NVO3/VXLAN/NVGRE will still reside in one L2
> network,

But those L2 networks are generally scoped to only include the VMs of one
tenant/customer. So a) the number of VMs is smallish (not the entire
data center), and b) any collisions will have been caused by the tenant
and only impact the tenant (not other tenants).

I'm not saying address collisions are  never a problem, but the above
reduces the frequency and limits the impact.

> and the VMs MAC will still conflict if have same MAC address. VM
> MAC confliction could not be mitigated or solved by these mechanism if I
> understand correctly.

Overlay approaches hide client/customer MACs inside a second, outer
header. Thus, if two different tenants use the same VM MAC address,
that collision is not visible within the datacenter, because the data
center network only uses the addresses in the outer header.

Thomas

---

From: Truman Boyes <[email-masked]>
Date: Thu, 2 Feb 2012 10:50:00 -0500

> center network only uses the addresses in the outer header.
The L2 separation between multiple tenants is true in most circumstances in
DCs, but in commodity computing (ie. VPS, low cost dedicated servers, or
co-location) there is a concern on IPv4 address exhaustion or waste, so
machines/instances are grouped on single L2 segments. It is possible to
have virtual MAC overlaps on these segments. Is this something that this
group wishes to evaluate options to solve?

Kind regards,
--Truman

---

From: Thomas Narten <[email-masked]>
Date: Thu, 02 Feb 2012 10:55:07 -0500

> group wishes to evaluate options to solve?

IMO, this is putting the cart before the horse.

Can we first get a sense for how big a problem this is in practice and
whether existing mitigation approaches are not sufficient?

I.e., is this a real problem causing significant pain today, or are
their other bigger "pain points" that we should be looking at?

Thomas

---

From: Truman Boyes <[email-masked]>
Date: Thu, 2 Feb 2012 13:20:07 -0500

> their other bigger "pain points" that we should be looking at?
In the VPS/VM world,  I would say it's not a significant issue because
there are single entities (Organizations) that manage the MAC addresses.
Typically software would just increment the virtual MACs, and this does not
require external protocols to ensure uniqueness. If there are many
provisioning systems that manage VMs on the same network segment then they
will need to keep their database in sync.

-- 
--truman

---

From: Mallik Mahalingam <[email-masked]>
Date: Thu, 2 Feb 2012 11:21:56 -0800 (PST)

In a virtualized environment MAC addresses are not totally random generated. 
There is some notion of Management-Entity(s)/controller(s) allocating the 
MAC addresses for VMs and ensures that it does not assign the same MAC 
address to two different VMs and this work only within the scope of that 
management/controller administration. There are some exceptions of course 
(a) MAC address exhaustion under a given OUI category (b) manual 
copy/cloning of VMs and powering on them using standalone management 
entities (c) VMs that use MAC address override for legitimate reasons 
[because else things like licensing software breaks]. There are some 
mechanisms in place to address (a), but (b) and (c) requires co-operation at 
the management-entity/controllers. 

Mallik 

----- Original Message -----

From: "Truman Boyes" <[email-masked]> 
To: "Thomas Narten" <[email-masked]> 
Cc: "yu jinghai" <[email-masked]>, [email-masked], "Lizhong Jin" <[email-masked]> 
Sent: Thursday, February 2, 2012 10:20:07 AM 
Subject: Re: [dc] Requirement for a method to manage mac address in DC 

On Thu, Feb 2, 2012 at 10:55 AM, Thomas Narten < [email-masked] > wrote: 

Thomas 

In the VPS/VM world, I would say it's not a significant issue because there are single entities (Organizations) that manage the MAC addresses. Typically software would just increment the virtual MACs, and this does not require external protocols to ensure uniqueness. If there are many provisioning systems that manage VMs on the same network segment then they will need to keep their database in sync. 

-- 
--truman 

_______________________________________________ 
dc mailing list 
[email-masked] 
https://www.ietf.org/mailman/listinfo/dc

---

From: "Pat Thaler" <[email-masked]>
Date: Thu, 2 Feb 2012 20:01:13 +0000

Some work on managing MAC addresses of virtual devices in a Data Center may be worthwhile, though it isn’t clear to me whether such work would better fit in IETF or IEEE 802.

When virtualization ecosystem management entities are handing out addresses, there can be data centers with multiple such entities and one can’t count on them to coordinate their use of the address space. While each of them won’t hand out duplicate addresses to the set of VMs they manage, the addresses may be duplicated for VMs managed by different management entities. Sometimes this can be dealt with by manual assignment of ranges, but in a data center with multiple tenants, the tenants are unlikely to coordinate that. The potential duplicate addresses can in some cases be dealt with by mechanisms that keep the address space of the management entities separate such as: IVL (or other mechanisms that concatenate VLAN and MAC address for bridge learning) or layer 2 (e.g. PBB and TRILL) or layer 3 encapsulations.  But there could be some areas where a protocol for coordinating assignments to avoid duplication would help.
There have been discussions in the IEEE RAC about concerns regarding the use of MAC addresses from the global MAC address space for virtual devices; issues include potential for exhausting the global address space and that an address that looks like a global address is being used as a local address. Half the MAC address space is for local addresses, but there aren’t standardized mechanisms for managing addresses in that space.

<IEEE 802 Vice-Chair hat on> If work was done in the IETF on MAC address management/assignment, there should be close liaison with IEEE 802 and the IEEE RAC.

Pat

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mallik Mahalingam
Sent: Thursday, February 02, 2012 11:22 AM
To: Truman Boyes
Cc: Thomas Narten; yu jinghai; [email-masked]; Lizhong Jin
Subject: Re: [dc] Requirement for a method to manage mac address in DC

Mallik
________________________________
From: "Truman Boyes" <[email-masked]<mailto:[email-masked]>>
To: "Thomas Narten" <[email-masked]<mailto:[email-masked]>>
Cc: "yu jinghai" <[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]>, "Lizhong Jin" <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, February 2, 2012 10:20:07 AM
Subject: Re: [dc] Requirement for a method to manage mac address in DC

On Thu, Feb 2, 2012 at 10:55 AM, Thomas Narten <[email-masked]<mailto:[email-masked]>> wrote:

Thomas

--
--truman

_______________________________________________
dc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dc

---

From: [email-masked]
Date: Fri, 3 Feb 2012 14:08:39 +0800

Hi Mallik:
        I learned about that Xen generate MAC address by an algorithm base 
the timestamp.
I don't know well about other virtualization platform.

> management/controller administration.
 
why does it work only within the scope of that management/controller 
administration?
How do VMs get the MAC addresses?
Could you please elaborate?

>-----------------------------------------<
╭⌒╮¤　　　　　     Innovation change 
                          the world 
╭╭ ⌒╮        ●╭○╮　 
╰ ----╯       /█∨█\ 　
~~~~~~~~~~~~~~~~~∏~~∏~~~~~~~~~~~~~~~~~
           My nickname: Fisher Yu
>----------------------------------------<

> 
> In the VPS/VM world,  I would say it's not a significant issue 
> because there are single entities (Organizations) that manage the 
> MAC addresses. Typically software would just increment the virtual 
> MACs, and this does not require external protocols to ensure 
> uniqueness. If there are many provisioning systems that manage VMs 
> on the same network segment then they will need to keep their 
> database in sync. 
> 
> -- 
> --truman
> 
>

---

From: Mallik Mahalingam <[email-masked]>
Date: Thu, 2 Feb 2012 23:15:25 -0800 (PST)

Virtual Center [VMware management software] uses combination of one of the OUI assigned to VMware and Virtual Center ID [which can be configured] to generate MAC address with in a range for VM's use. It ensures that MAC address assigned to VMs that are managed by it gets non overlapping MAC address. 

Mallik 

----- Original Message -----

From: "yu jinghai" <[email-masked]> 
To: "Mallik Mahalingam" <[email-masked]> 
Cc: "Thomas Narten" <[email-masked]>, "Truman Boyes" <[email-masked]>, [email-masked], "Lizhong Jin" <[email-masked]> 
Sent: Thursday, February 2, 2012 10:08:39 PM 
Subject: [dc] 答复: Re: Requirement for a method to manage mac address in DC 

Hi Mallik: 
I learned about that Xen generate MAC address by an algorithm base the timestamp. 
I don't know well about other virtualization platform. 
> management/controller administration. 

why does it work only within the scope of that management/controller administration? 
How do VMs get the MAC addresses? 
Could you please elaborate? 

╭⌒╮¤ Innovation change 
the world 
╭╭ ⌒╮ ●╭○╮ 
╰ ----╯ /█∨█\

---

From: Andy Dockerty <[email-masked]>
Date: Fri, 3 Feb 2012 18:26:23 +1100

Mallik,

I like the idea of extending the use of OUIs beyond his. If the future holds true "grid" computing, with providers offering cycle competitively, a unique organizational identity at layer 2 could be useful.

 I  am aware that there are concerns about "OUI address space", that not withstanding, the creation of an OUI space analogous with RFC1918 address space, coupled with the extension of OUI registration may offer an option to ensure organizational or locally significant MAC uniqueness....

Andy

---

From: Thomas Narten <[email-masked]>
Date: Fri, 03 Feb 2012 08:45:18 -0500

Andy Dockerty <[email-masked]> writes:

> I am aware that there are concerns about "OUI address space", that
> not withstanding, the creation of an OUI space analogous with
> RFC1918 address space, coupled with the extension of OUI
> registration may offer an option to ensure organizational or locally
> significant MAC uniqueness....

RFC 1918 space is shared in the sense that anyone can use it as they
see fit. Different organizations use the same space, so if you
merge/join to organizations you risk having collisions. Even within an
organization, assignments must be done in such a way as to avoid
collisionss. RFC1918 space is defined to have local scope only, i.e.,
not be globally unique.

Seems to me that MAC addrs satisfy that property already, via
appropriate use of the "local" bit.

So when you suggest creation of an "OUI space analagous with RFC1918
space", do we not already have that?

Thomas

---

From: Mallik Mahalingam <[email-masked]>
Date: Fri, 3 Feb 2012 09:50:47 -0800 (PST)

Hi Thomas:

Yes, extending LAA [Locally Administered Address] is something that I discussed with David Black and few others in the past in the context of MAC address exhaustion. I did see some initial activity in IEEE on this, but I didn't get much time to spend on that activity and secondly, with the advent of encapsulation techniques, I am yet to find  if this even a real problem because the MAC address VM sees is hidden from the fabric.

Mallik

----- Original Message -----
From: "Thomas Narten" <[email-masked]>
To: "Andy Dockerty" <[email-masked]>
Cc: "Mallik Mahalingam" <[email-masked]>, "yu jinghai" <[email-masked]>, "Truman Boyes" <[email-masked]>, [email-masked], "Lizhong Jin" <[email-masked]>
Sent: Friday, February 3, 2012 5:45:18 AM
Subject: Re: [dc] 答复: Re:  Requirement for a method to manage mac address in DC

Thomas

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 3 Feb 2012 13:17:37 -0500

Hi Pat,

Please see below:

On Thu, Feb 2, 2012 at 3:01 PM, Pat Thaler <[email-masked]> wrote:
> Some work on managing MAC addresses of virtual devices in a Data Center may
> be worthwhile, though it isn’t clear to me whether such work would better
> fit in IETF or IEEE 802.
>
>
>
> When virtualization ecosystem management entities are handing out addresses,
> there can be data centers with multiple such entities and one can’t count on
> them to coordinate their use of the address space. While each of them won’t
> hand out duplicate addresses to the set of VMs they manage, the addresses
> may be duplicated for VMs managed by different management entities.
> Sometimes this can be dealt with by manual assignment of ranges, but in a
> data center with multiple tenants, the tenants are unlikely to coordinate
> that. The potential duplicate addresses can in some cases be dealt with by
> mechanisms that keep the address space of the management entities separate
> such as: IVL (or other mechanisms that concatenate VLAN and MAC address for
> bridge learning) or layer 2 (e.g. PBB and TRILL) or layer 3 encapsulations.

Sorry to be nit-picky, but TRILL is not a layer 2 encapsulation. It is
provably above layer 2.

In my opinion, the best way to tell if a device of type X is at a
higher layer, at the same layer, or at a lower layer, than a device of
type Y is to look at peering. Generally speaking, layer 2 devices are
transparent to TRILL and TRILL switches peer through layer 2 devices,
just like layer 3 routers peer with each other through layer 2
devices. On the other hand, TRILL switches look like end stations to
and block peering between layer 2 devices, just like layer 3 routers
look like end stations and block peering between layer 2 devices. See
attached slides.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

>  But there could be some areas where a protocol for coordinating assignments
> to avoid duplication would help.
>
> There have been discussions in the IEEE RAC about concerns regarding the use
> of MAC addresses from the global MAC address space for virtual devices;
> issues include potential for exhausting the global address space and that an
> address that looks like a global address is being used as a local address.
> Half the MAC address space is for local addresses, but there aren’t
> standardized mechanisms for managing addresses in that space.
>
>
>
> <IEEE 802 Vice-Chair hat on> If work was done in the IETF on MAC address
> management/assignment, there should be close liaison with IEEE 802 and the
> IEEE RAC.
>
>
>
> Pat
>
>
>
> In the VPS/VM world,  I would say it's not a significant issue because there
> are single entities (Organizations) that manage the MAC addresses. Typically
> software would just increment the virtual MACs, and this does not require
> external protocols to ensure uniqueness. If there are many provisioning
> systems that manage VMs on the same network segment then they will need to
> keep their database in sync.
>
>
>
> --
> --truman
>
>

---

From: "Pat Thaler" <[email-masked]>
Date: Fri, 3 Feb 2012 18:51:37 +0000

Donald,

Everything has to be somewhere. By your argument, TRILL bridges aren't layer 3 devices either because they aren't peering with the routers in your slides. They are below layer 3 - not working in the layer 3 addressing domain so they are in layer 2. It is just that layer 2 has some sublayers of peered devices. Long before TRILL and PBB, there were Ethernet repeaters which were also layer 2 devices and didn't peer with switches. Provider bridges, provider backbone bridges and TRILL all work at different sublayers in layer 2. 

I also don't see how that matters to the content of this discussion. Whether one considers TRILL bridges to be at some new layer 2.5 or not or even at layer 3 doesn't matter to the point that they provide isolation between the address spaces of tenants.  That isolation only applies if any traffic between those tenants goes through a layer 3 devices that removes the original MAC addresses from the frame.

Regards,
Pat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Friday, February 03, 2012 10:18 AM
To: Pat Thaler
Cc: Thomas Narten; [email-masked]; yu jinghai; Truman Boyes; Lizhong Jin; Mallik Mahalingam
Subject: Re: [dc] Requirement for a method to manage mac address in DC

Hi Pat,

Please see below:

On Thu, Feb 2, 2012 at 3:01 PM, Pat Thaler <[email-masked]> wrote:
> be worthwhile, though it isn't clear to me whether such work would better
> fit in IETF or IEEE 802.
>
>
>
> there can be data centers with multiple such entities and one can't count on
> them to coordinate their use of the address space. While each of them won't

Thanks,
Donald

> Half the MAC address space is for local addresses, but there aren't

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 4 Feb 2012 14:14:30 -0500

Hi Pat,

On Fri, Feb 3, 2012 at 1:51 PM, Pat Thaler <[email-masked]> wrote:
> Donald,
>
> Everything has to be somewhere.

"remember: no matter where you go... there you are" The Adventures of
Buckaroo Banzai Across the 8th Dimension...

> By your argument, TRILL bridges aren't layer 3 devices either
> because they aren't peering with the routers in your slides. They
> are below layer 3 -

Yes. Exactly the same form of proof that proves that TRILL switches
are above layer 2 also proves that TRILL switches are below layer 3.

> not working in the layer 3 addressing domain so they are in layer 2.

No. TRILL Data packets are routed by TRILL switches using the TRILL
nickname address space. I do not know what the basis is of your
assertion that TRILL nicknames are not layer 3 addresses but I don't
believe they are layer 2 addresses.

> It is just that layer 2 has some sublayers of peered devices.
> Long before TRILL and PBB, there were Ethernet repeaters which were
> also layer 2 devices and didn't peer with switches. Provider
> bridges, provider backbone bridges and TRILL all work at different
> sublayers in layer 2.

I disagree the TRILL is a sublayer of Layer 2. It is fairly easy to
order devices as to relative layer based on peering although, like
with anything else, if you apply a sufficiently strong magnifying
glass you can find some odd glitches and corner case:

Repeater < Prov. Bridge < Cust. Bridge < TRILL Switch < L3 Router

In my opinion, the arguments that TRILL is in Layer 2 or Layer 3 are
in exact equipoise. I do not agree that anything on or inside the
border betwen Layer 2 and Layer 3 should be classified as Layer 2.

> I also don't see how that matters to the content of this
> discussion. Whether one considers TRILL bridges to be at some new

TRILL routers

> layer 2.5 or not or even at layer 3 doesn't matter to the point that
> they provide isolation between the address spaces of tenants. That
> isolation only applies if any traffic between those tenants goes
> through a layer 3 devices that removes the original MAC addresses
> from the frame.

I agree that it does not matter much to the point under discussion. I
just didn't want people to be confused about the true nature of TRILL
switches.

Thanks,
Donald

---

From: Joel jaeggli <[email-masked]>
Date: Sun, 05 Feb 2012 10:03:57 -0800

> collisionss. RFC1918 space is defined to have local scope only, i.e.,

In my experience the by far the number #1 way to produce oui collisions
with VMs by far is when cloning systems or images with predefined oui's.
I'm sort of of the opinion that if you shoot yourself in the foot it
should hurt. attempting to hide or ameliorate that sort of brokenness
would seem like a mistake.

---

From: AshwoodsmithPeter <[email-masked]>
Date: Mon, 6 Feb 2012 01:56:38 +0000

This numbering of layers was useful way back when but its starting to get worn out and confusing. Probably simpler if people just name the layer by layer encapsulations they are talking about especially in a technical discussion.

Eg:

MACinVXLANinIPV4inMAC
MACinTRILLinMAC
MACinMAC
MACinMPLSinMPLS
Yada yada ..

Peter

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Saturday, February 04, 2012 2:15 PM
To: Pat Thaler
Cc: Thomas Narten; [email-masked]; yu jinghai; Truman Boyes; Lizhong Jin; Mallik Mahalingam
Subject: Re: [dc] Requirement for a method to manage mac address in DC

Hi Pat,

TRILL routers

Thanks,
Donald

---

From: Linda Dunbar <[email-masked]>
Date: Fri, 10 Feb 2012 00:01:46 +0000

As long as Addresses (MAC or IP) within one Virtual Network Instance are unique, there shouldn’t be any issue.
If there are multiple management entities handling addresses, I would assume they will (and should) be coordinated well enough to not giving duplicated addresses within one Virtual Network Instance.
Are they out of scope of IEEE and IETF?

Linda

From: [email-masked] [mailto:[email-masked]] On Behalf Of Pat Thaler
Sent: Thursday, February 02, 2012 2:01 PM
To: Mallik Mahalingam; Truman Boyes
Cc: Thomas Narten; yu jinghai; [email-masked]; Lizhong Jin
Subject: Re: [dc] Requirement for a method to manage mac address in DC

Pat

Mallik

Thomas

--
--truman

---

From: Lizhong Jin <[email-masked]>
Date: Thu, 2 Feb 2012 22:47:06 +0800

Hi Thomas,
The VMs connected by SPB-M or NVO3/VXLAN/NVGRE will still reside in one L2
network, and the VMs MAC will still conflict if have same MAC address. VM
MAC confliction could not be mitigated or solved by these mechanism if I
understand correctly.

Lizhong

-------------------------------------
yu.jinghai at zte.com.cn writes:

>
>    I wonder whether it is necessary to manage mac address in DC.
> As you know,VM's mac is randomly generated.
> The risk of mac conflict is increasing with  the amount of VMs in DC.
> If there is a method to auto manage and allocate mac address,the
>    risk maybe avoid.
> That method may facilitate the operator to control network easily
>    and other available benefits.

One straightforward way to mitigate C-MAC conflicts is via
encapsulations, whether through something like SPB-M or
NVO3/VXLAN/NVGRE.

Do such approaches not address the problem sufficiently?

Thomas

---

From: David Allan I <[email-masked]>
Date: Sat, 11 Feb 2012 17:27:38 -0500

Hi Lizhong

VM MACs are administered, and only require uniqueness within a customer VLAN. So as long as a single customer VLAN does not have multiple administators, there should be no issue.

IMO a MAC conflict within a single VLAN administration is complete incompetence, not somthing to kill ourselves trying to find a solution over!

my 2 cents
Dave

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lizhong Jin
Sent: Thursday, February 02, 2012 6:47 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [dc] Requirement for a method to manage mac address in DC

Hi Thomas,
The VMs connected by SPB-M or NVO3/VXLAN/NVGRE will still reside in one L2 network, and the VMs MAC will still conflict if have same MAC address. VM MAC confliction could not be mitigated or solved by these mechanism if I understand correctly.

Lizhong

Thomas

---

From: [email-masked]
Date: Sun, 12 Feb 2012 15:40:15 +0800

Hi David：
   In an Large L2 network，the MAC conflict is likely，especially when 
mutil-vlan interwork through supervlan.
in addition，the benefit is not only avoiding the MAC conflict but also 
getting more controlling of their DC。

fisher.

╭⌒╮¤　　　　　     Innovation change 
                          the world 
╭╭ ⌒╮        ●╭○╮　 
╰ ----╯       /█∨█\ 　

David Allan I <[email-masked]> 写于 2012-02-12 06:27:38:

> Hi Lizhong
> 
> VM MACs are administered, and only require uniqueness within a 
> customer VLAN. So as long as a single customer VLAN does not have 
> multiple administators, there should be no issue.
> 
> IMO a MAC conflict within a single VLAN administration is complete 
> incompetence, not somthing to kill ourselves trying to find a solution 
over!

> Hi Thomas,
> The VMs connected by SPB-M or NVO3/VXLAN/NVGRE will still reside in 
> one L2 network, and the VMs MAC will still conflict if have same MAC
> address. VM MAC confliction could not be mitigated or solved by 
> these mechanism if I understand correctly. 
> 
> Lizhong
>

---

From: David Allan I <[email-masked]>
Date: Sun, 12 Feb 2012 20:53:54 -0500

HI Fisher:

The size of the network is independent of the size of the VLAN. And I assume a larger network simply has more VLANs. So IMO the problem does not assert itself in proportion to network size.

MAC conflict is perhaps true when vendors manufacture many NICs with the same MAC and we have lots of experience with that. When the MAC is administered, and within a single administered broadcast domain,, a.k.a. VLAN I still assert problems will only arise via incompetence.

SuperVLAN looks to me like asymmetric VID or ETREE. Which is the one scenario when multiple MAC administrations MAY share a single subnet, although I suspect the cloud model where ETREE would  be used would preclude that (e.g. SaaS). If one is going to use ETREE for multiple IaaS instances, buyer beware...

cheers
Dave

________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Saturday, February 11, 2012 11:40 PM
To: David Allan I
Cc: [email-masked]; Lizhong Jin; [email-masked]
Subject: 答复: RE: [dc] Requirement for a method to manage mac address in DC

Hi David：
   In an Large L2 network，the MAC conflict is likely，especially when mutil-vlan interwork through supervlan.
in addition，the benefit is not only avoiding the MAC conflict but also getting more controlling of their DC。

fisher.

╭⌒╮¤　　　　　     Innovation change
                         the world
╭╭ ⌒╮        ●╭○╮　
╰ ----╯       /█∨█\ 　

David Allan I <[email-masked]> 写于 2012-02-12 06:27:38:

> incompetence, not somthing to kill ourselves trying to find a solution over!
>
> my 2 cents
> Dave
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 13 Feb 2012 09:52:46 +0000

On 13/02/2012 01:53, David Allan I wrote:
> MAC conflict is perhaps true when vendors manufacture many NICs with 
> the same MAC

Maybe  drivers should refuse to enable in the presence of
such a conflict?

That would result in operators correctly rejecting equipment
from their vendors on the grounds that they were supplying
goods not fit for purpose.

- Stewart

---

From: Thomas Narten <[email-masked]>
Date: Mon, 13 Feb 2012 10:02:46 -0500

> Maybe  drivers should refuse to enable in the presence of

That is what IPv6 effectively does, when stateless address autoconfig
is done. If there are duplicate addresses, the interface shuts
down.

You are pretty much guaranteed to get get duplicate IPv6 link-local
addresses if there are duplicate MAC addrs in use.

But in a data center, I would not expect so much use of stateless
autoconfig...  

Thomas

---

From: Truman Boyes <[email-masked]>
Date: Mon, 13 Feb 2012 20:38:31 -0500

> But in a data center, I would not expect so much use of stateless

Really depends, you could quite easily use stateless autoconfig in data centers where the machines are designed for HPC or large compute farms where static addressing is too complex. SLAAC + DHCPv6 would fit the bill nicely. In this case, duplicate MACs would be pretty harmful to the whole idea of SLAAC. 

A lot of people have looked at Puppet / CFengine / or other automation technologies to do static IP addressing on DC machines, but we already have protocols to handle addressing, be it DHCPv6 or SLAAC.

Truman