virtual interface mac adress

virtual interface mac adress

[anil dahiya]

Hi 
I want to assign mac addres to virtual adpater and mac
address should be like that if it should not create
problem in arp resoultion(i.e. mac address should be
as real card which able to comunicate  on lan )

waiting for ur reply,
Anil 




		
__________________________________ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs

Re: virtual interface mac adress

[Rik van Riel]

On Sun, 4 Dec 2005, anil dahiya wrote:

> I want to assign mac addres to virtual adpater and mac
> address should be like that if it should not create
> problem in arp resoultion(i.e. mac address should be
> as real card which able to comunicate  on lan )

You may be able to get away with using a MAC address
inside the OUI range that XenSource registered.

-- 
All Rights Reversed

Re: virtual interface mac adress

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.63.0512041520320.29211@cuia.boston.redhat.com>
By author:    Rik van Riel <riel@redhat.com>
In newsgroup: linux.dev.kernel
>
> On Sun, 4 Dec 2005, anil dahiya wrote:
> 
> > I want to assign mac addres to virtual adpater and mac
> > address should be like that if it should not create
> > problem in arp resoultion(i.e. mac address should be
> > as real card which able to comunicate  on lan )
> 
> You may be able to get away with using a MAC address
> inside the OUI range that XenSource registered.
> 

Any MAC with bit 0 clear and bit 1 set in the first octet is "local
use"; the best thing to do (unless you have your own OUI) is just to
pick a random address inside this range.  You should only run into
collision problems when you get close to 2^23 hosts on a network.

	-hpa

Re: virtual interface mac adress

[Mark Rustad]

On Dec 4, 2005, at 2:41 PM, H. Peter Anvin wrote:

> Followup to:  <Pine.LNX. 
> 4.63.0512041520320.29211@cuia.boston.redhat.com>
> By author:    Rik van Riel <riel@redhat.com>
> In newsgroup: linux.dev.kernel
>>
>> On Sun, 4 Dec 2005, anil dahiya wrote:
>>
>>> I want to assign mac addres to virtual adpater and mac
>>> address should be like that if it should not create
>>> problem in arp resoultion(i.e. mac address should be
>>> as real card which able to comunicate  on lan )
>>
>> You may be able to get away with using a MAC address
>> inside the OUI range that XenSource registered.
>
> Any MAC with bit 0 clear and bit 1 set in the first octet is "local
> use"; the best thing to do (unless you have your own OUI) is just to
> pick a random address inside this range.  You should only run into
> collision problems when you get close to 2^23 hosts on a network.

Theoretically that is true, however there are usages that have been  
approved that violate that principal. One was for TI Token Ring  
chips. They were completely unable to use "global" MAC addresses -  
the local bit always had to be set. Since TI could/would not fix  
their chips, using the local address became allowed for a universally  
unique address.

This method was later used by Apple on Ethernet for their DOS card.  
The Macintosh environment would get the global address and the DOS  
card would get the local one through the shared ethernet port. You  
might think that you can ignore the token ring case, but you'd be  
wrong - there are ethernet/token ring bridges deployed. The Apple  
case is also best not ignored. I don't know how many others may be  
doing similar things.

So, I would not advise anyone to simply believe that they can use the  
entire local MAC address space safely. You are also very likely to  
have trouble if there is any DECnet usage in the area. Anyone else  
notice that DECnet kernel patch recently? Someone must still be using  
it...

This is an instance where Linus' comment a few weeks ago regarding  
specs vs. reality comes into play. This is kind of an obscure area so  
not a whole lot of people know about some of these things. Don't  
believe everything you read in magazines regarding MAC addresses  
either. I've seen some very bad advice there from time to time in  
this particular area.

I would recommend using the same MAC address with the local bit set  
(as Apple did) for a single additional address. If you need more  
addresses and need them to be visible on the LAN, I don't know of a  
reliable, generic solution off the top of my head.

-- 
Mark Rustad, MRustad@mac.com

Re: virtual interface mac adress

[H. Peter Anvin]

Mark Rustad wrote:
> 
> Theoretically that is true, however there are usages that have been  
> approved that violate that principal. One was for TI Token Ring  chips. 
> They were completely unable to use "global" MAC addresses -  the local 
> bit always had to be set. Since TI could/would not fix  their chips, 
> using the local address became allowed for a universally  unique address.
> 
> This method was later used by Apple on Ethernet for their DOS card.  The 
> Macintosh environment would get the global address and the DOS  card 
> would get the local one through the shared ethernet port. You  might 
> think that you can ignore the token ring case, but you'd be  wrong - 
> there are ethernet/token ring bridges deployed. The Apple  case is also 
> best not ignored. I don't know how many others may be  doing similar 
> things.
> 
> So, I would not advise anyone to simply believe that they can use the  
> entire local MAC address space safely. You are also very likely to  have 
> trouble if there is any DECnet usage in the area. Anyone else  notice 
> that DECnet kernel patch recently? Someone must still be using  it...
> 
> This is an instance where Linus' comment a few weeks ago regarding  
> specs vs. reality comes into play. This is kind of an obscure area so  
> not a whole lot of people know about some of these things. Don't  
> believe everything you read in magazines regarding MAC addresses  
> either. I've seen some very bad advice there from time to time in  this 
> particular area.
> 
> I would recommend using the same MAC address with the local bit set  (as 
> Apple did) for a single additional address. If you need more  addresses 
> and need them to be visible on the LAN, I don't know of a  reliable, 
> generic solution off the top of my head.
> 

By definition, using local addresses is probabilistic.  There are moron 
hardware manufacturers, as you show above (which aren't even the worst 
of the lot, from what I've seen), but your cross-section with other 
local-address users will be very small (collision only likely around 
2^23 nodes.)

Reducing the address space available to randomly pick from will only 
increase the likelihood of failure.

This is an instance where an understanding of statistics come into play.

	-hpa

Re: virtual interface mac adress

[Stephen Hemminger]

On Sun, 4 Dec 2005 11:29:58 -0800 (PST)
anil dahiya <ak_ait@yahoo.com> wrote:

> Hi 
> I want to assign mac addres to virtual adpater and mac
> address should be like that if it should not create
> problem in arp resoultion(i.e. mac address should be
> as real card which able to comunicate  on lan )
> 
> waiting for ur reply,
> Anil 
> 

use random_ether_addr (see include/linux/etherdevice.h)

-- 
Stephen Hemminger <shemminger@osdl.org>
OSDL http://developer.osdl.org/~shemminger