|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] vif tx drops
> So the xen side of the vif isn't see on the wire except for a: the
> backend driver domain( usually domain-0) and that vif's front and driver
> domain eh? (I got the front and back end locations right yes?)
Noone ever sees the backend MAC address -- it is never written into
any packet. We only need to give the backend a MAC address because we
hook into the Linux networking code as a normal Ethernet interface,
and normal Ethernet interfaces need a normal MAC address. :-)
It needs to be unique because of sanity checks in the bridge that fail
if it sees a remote address == a local address that it knows about.
> Either way it goes, how would one go about verifying that the MAC is
> truly unique on it's visible lan? I'd be i very interested in this as a
> safety precaution. Right now I can't think of how to do the uniqueness
> test... 8-P if someone can give me an idea or two I could try to code it
> since it's something that I want.(brain fried this morning)
I'm pretty sure there's no way of soliciting a response from an
Ethernet host without using some higher-level protocol; probably IP or
RARP. RARP is hardly ever used, but maybe if you know the IP subnet
you could do a broadcast ping and collect the responses and look at
their source MAC addresses?
-- Keir
> On Thu, 2004-10-14 at 03:21, Keir Fraser wrote:
> > One option is to have the backend interfaces pick their MAC addresses
> > from a well-known range: e.g., AA:00:FF:00:00:00 + <vif id>.
> > These wouldn't need to be unique -- they'd never be seen 'on the
> > wire'.
> >
> > The random MAC allocator would never pick a MAC in that range, and
> > xend could ensure that manually-selected MACs never fall in that
> > range and print an error if they did.
> >
> > It's a shame that the backend needs a MAC different from the frontend
> > -- but if it doesn't then the bridge code complains. :-(
> >
> > -- Keir
> >
> > > I temporarilly solved this by converting the IP to hexidecimal and
> > > setting the first 2 bytes of the mac to DE:AD. Unfortunately xen
> > > increments the 3rd if you set the mac. We need a way to set the mac on
> > > both ends of the vif device.
> > >
> > > Maybe we can have things this way. options...
> > > a: set the mac on one end and have a standard "increment" bit somewhere
> > > higher up(say first byte).
> > > b: set the macs on both ends
> > > c: set a specific range of macs to use
> > >
> > > Either way xen really should test (not certain how exactly) to see if
> > > it's already in existence prior to using a mac that is dynamicly set.
> > > Not testing is playing russian roulette IMHO (as some including myself
> > > have found out already).
> > >
> > > Opinions?
> > >
> > > On Wed, 2004-10-13 at 15:17, Keir Fraser wrote:
> > > > >
> > > > > " This is *definitely* worth checking
> > > > > " out at this point, and can be fixed by picking your own MAC
> > > > > addresses.
> > > > >
> > > > > Yep. How big a space do you randomize for mac addrs?
> > > > >
> > > > > # grep -i AA:00:00:24:22:F3 a
> > > > > batch009 (172.16.12.19) at AA:00:00:24:22:F3 [ether] on eth0
> > > > > batch075 (172.16.12.85) at AA:00:00:24:22:F3 [ether] on eth0
> > > > >
> > > >
> > > > I think AA:00:00:00:00:00 - AA:00:00:7F:FF:FF (i.e., 8 million
> > > > addresses). But the random-number generator is crap.
> > > >
> > > > You're definitely best off generating your own if creating any decent
> > > > number of VMs.
> > > >
> > > > -- Keir
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> > > > Use IT products in your business? Tell us what you think of them. Give
> > > > us
> > > > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out
> > > > more
> > > > http://productguide.itmanagersjournal.com/guidepromo.tmpl
> > > > _______________________________________________
> > > > Xen-devel mailing list
> > > > Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> > > > https://lists.sourceforge.net/lists/listinfo/xen-devel
> > >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> > Use IT products in your business? Tell us what you think of them. Give us
> > Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> > http://productguide.itmanagersjournal.com/guidepromo.tmpl
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/xen-devel
>
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [Xen-devel] vif tx drops, (continued)
- Re: [Xen-devel] vif tx drops, Brian Wolfe
- Re: [Xen-devel] vif tx drops, Keir Fraser
- Re: [Xen-devel] vif tx drops, Brian Wolfe
- Re: [Xen-devel] vif tx drops,
Keir Fraser <=
- Re: [Xen-devel] vif tx drops, Brian Wolfe
- Re: [Xen-devel] vif tx drops, Christian Limpach
- Re: [Xen-devel] vif tx drops, Christian Limpach
- Re: [Xen-devel] vif tx drops, Ian Pratt
- Re: [Xen-devel] vif tx drops, Keir Fraser
- Re: [Xen-devel] vif tx drops, Alvin Starr
|
|
|
|
|