4:30 a.m.
Hi,
Looking through the driver API, I came across the
drv_lookup_by_mac_string. This function is prototyped in
internal.h, so I assume that it is a part of the public driver
API.
However, a problem may arise when multiple top-level interfaces
share mac addresses, as drv_lookup_by_mac_string only may return
one struct netcf_if *. This can occurr when using vlan
interfaces, e.g. eth0.2 and eth0.3, or if vlan ifs are not to be
considered top-level interfaces, the bridges or bonds that these
interfaces are a part of. I therefore recommend a switch to a
drv_list_interfaces-prototype for drv_lookup_by_mac_string.
For reference:
int drv_list_interfaces(struct netcf *ncf, int maxnames, char **names);
Best regards,
Jonas Eriksson
--
Jonas Eriksson
Consultant at AS/EAB/FLJ/IL
Combitech AB
Älvsjö, Sweden
5:28 p.m.
On Wed, 2009-06-10 at 11:30 +0200, Jonas Eriksson wrote:
Looking through the driver API, I came across the
drv_lookup_by_mac_string. This function is prototyped in
internal.h, so I assume that it is a part of the public driver
API.
The drv_ is not, but there is a public function ncf_lookup_by_mac_string
in netcf.h.
However, a problem may arise when multiple top-level interfaces
share mac addresses, as drv_lookup_by_mac_string only may return
one struct netcf_if *. This can occurr when using vlan
interfaces, e.g. eth0.2 and eth0.3, or if vlan ifs are not to be
considered top-level interfaces, the bridges or bonds that these
interfaces are a part of. I therefore recommend a switch to a
drv_list_interfaces-prototype for drv_lookup_by_mac_string.
Yes, you are right .. it's a mess. So far I only had situations like a
bridge and an enslaved physical NIC sharing a MAC address, and I made
sure that the bridge, not the enslaved NIC is returned when you ask for
an interface by NIC.
For reference:
int drv_list_interfaces(struct netcf *ncf, int maxnames, char **names);
You are right - we need a slightly more complicated interface to cover
those cases, something like
int ncf_lookup_by_mac_string(struct netcf *, const char *mac, int maxifs, struct
netcf_if **interfaces);
where the return value gives the total number of toplevel interfaces
that match the given MAC, the (randomly) first MAXIFS many are returned
in INTERFACES. Does that sound better ?
David
3:42 a.m.
On Thu, Jun 11, 2009 at 10:28:48PM +0000 David Lutterkort wrote:
On Wed, 2009-06-10 at 11:30 +0200, Jonas Eriksson wrote:
> However, a problem may arise when multiple top-level interfaces
> share mac addresses, as drv_lookup_by_mac_string only may return
> one struct netcf_if *. This can occurr when using vlan
> interfaces, e.g. eth0.2 and eth0.3, or if vlan ifs are not to be
> considered top-level interfaces, the bridges or bonds that these
> interfaces are a part of. I therefore recommend a switch to a
> drv_list_interfaces-prototype for drv_lookup_by_mac_string.
Yes, you are right .. it's a mess. So far I only had situations like a
bridge and an enslaved physical NIC sharing a MAC address, and I made
sure that the bridge, not the enslaved NIC is returned when you ask for
an interface by NIC.
> For reference:
> int drv_list_interfaces(struct netcf *ncf, int maxnames, char **names);
You are right - we need a slightly more complicated interface to cover
those cases, something like
int ncf_lookup_by_mac_string(struct netcf *, const char *mac, int maxifs, struct
netcf_if **interfaces);
where the return value gives the total number of toplevel interfaces
that match the given MAC, the (randomly) first MAXIFS many are returned
in INTERFACES. Does that sound better ?
That should work fine, and seems coherent with other API
functions sharing the same design. I'm all for it.
Regards,
Jonas
--
Jonas Eriksson
Consultant at AS/EAB/FLJ/IL
Combitech AB
Älvsjö, Sweden
12:48 p.m.
On 06/11/2009 06:28 PM, David Lutterkort wrote:
On Wed, 2009-06-10 at 11:30 +0200, Jonas Eriksson wrote:
> Looking through the driver API, I came across the
> drv_lookup_by_mac_string. This function is prototyped in
> internal.h, so I assume that it is a part of the public driver
> API.
The drv_ is not, but there is a public function ncf_lookup_by_mac_string
in netcf.h.
> However, a problem may arise when multiple top-level interfaces
> share mac addresses, as drv_lookup_by_mac_string only may return
> one struct netcf_if *. This can occurr when using vlan
> interfaces, e.g. eth0.2 and eth0.3, or if vlan ifs are not to be
> considered top-level interfaces, the bridges or bonds that these
> interfaces are a part of. I therefore recommend a switch to a
> drv_list_interfaces-prototype for drv_lookup_by_mac_string.
Yes, you are right .. it's a mess. So far I only had situations like a
bridge and an enslaved physical NIC sharing a MAC address, and I made
sure that the bridge, not the enslaved NIC is returned when you ask for
an interface by NIC.
> For reference:
> int drv_list_interfaces(struct netcf *ncf, int maxnames, char **names);
You are right - we need a slightly more complicated interface to cover
those cases, something like
int ncf_lookup_by_mac_string(struct netcf *, const char *mac, int maxifs, struct
netcf_if **interfaces);
where the return value gives the total number of toplevel interfaces
that match the given MAC, the (randomly) first MAXIFS many are returned
in INTERFACES. Does that sound better ?
In the libvirt code that I'd already written using the old version of
this function, I was using the MAC address as a cookie that could get me
back the original netcf_if at any point in the future (assuming the
interface hadn't been deleted from the config). If multiple interfaces
can have the same MAC address, that's not going to fly.
Will the interface's name always be unique? If so, I'll switch to using
that, and that will solve all problems but one (the libvirt public API
that retrieves interface by MAC address).
3:47 p.m.
On Tue, Jun 23, 2009 at 01:48:51PM -0400, Laine Stump wrote:
On 06/11/2009 06:28 PM, David Lutterkort wrote:
> On Wed, 2009-06-10 at 11:30 +0200, Jonas Eriksson wrote:
>
> You are right - we need a slightly more complicated interface to cover
> those cases, something like
>
> int ncf_lookup_by_mac_string(struct netcf *, const char *mac, int maxifs,
struct netcf_if **interfaces);
>
> where the return value gives the total number of toplevel interfaces
> that match the given MAC, the (randomly) first MAXIFS many are returned
> in INTERFACES. Does that sound better ?
In the libvirt code that I'd already written using the old version of
this function, I was using the MAC address as a cookie that could get me
back the original netcf_if at any point in the future (assuming the
interface hadn't been deleted from the config). If multiple interfaces
can have the same MAC address, that's not going to fly.
Why would we ever have duplicate MAC addresses? I realize that when you
configure a bonding device bond0, each eth0 and eth1 enslaved will be
configured with the same MAC address. We're not managing those as devices
directly though. We only care about doing a lookup of the 'end point'
interfaces, eg bond0, so fact that eth0 and eth1 have the same MAC should
not impact us.
Will the interface's name always be unique? If so, I'll
switch to using
that, and that will solve all problems but one (the libvirt public API
that retrieves interface by MAC address).
Interface names must be unique
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
12:22 p.m.
On Wed, Jun 24, 2009 at 10:20:00AM -0700, David Lutterkort wrote:
On Tue, 2009-06-23 at 21:47 +0100, Daniel P. Berrange wrote:
> Why would we ever have duplicate MAC addresses?
VLANs:
# vconfig add eth0 42
# cat /sys/class/net/eth0.42/address
00:15:58:81:5b:0e
# cat /sys/class/net/eth0/address
00:15:58:81:5b:0e
Ok, so for the libvirt API we should define that the lookup-by-mac API
will not return VLAN devices, since we cant provide a 1-1 lookup there
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
12:52 p.m.
On Wed, 2009-06-24 at 18:22 +0100, Daniel P. Berrange wrote:
On Wed, Jun 24, 2009 at 10:20:00AM -0700, David Lutterkort wrote:
> On Tue, 2009-06-23 at 21:47 +0100, Daniel P. Berrange wrote:
> > Why would we ever have duplicate MAC addresses?
>
> VLANs:
>
> # vconfig add eth0 42
> # cat /sys/class/net/eth0.42/address
> 00:15:58:81:5b:0e
> # cat /sys/class/net/eth0/address
> 00:15:58:81:5b:0e
Ok, so for the libvirt API we should define that the lookup-by-mac API
will not return VLAN devices, since we cant provide a 1-1 lookup there
Why would you do that ? When the user asks for interfaces with a MAC,
you don't know if they are looking for a VLAN or base device. If they
want the VLAN, how would they look that up ?
David
2:22 p.m.
On Wed, Jun 24, 2009 at 10:52:17AM -0700, David Lutterkort wrote:
On Wed, 2009-06-24 at 18:22 +0100, Daniel P. Berrange wrote:
> On Wed, Jun 24, 2009 at 10:20:00AM -0700, David Lutterkort wrote:
> > On Tue, 2009-06-23 at 21:47 +0100, Daniel P. Berrange wrote:
> > > Why would we ever have duplicate MAC addresses?
> >
> > VLANs:
> >
> > # vconfig add eth0 42
> > # cat /sys/class/net/eth0.42/address
> > 00:15:58:81:5b:0e
> > # cat /sys/class/net/eth0/address
> > 00:15:58:81:5b:0e
>
> Ok, so for the libvirt API we should define that the lookup-by-mac API
> will not return VLAN devices, since we cant provide a 1-1 lookup there
Why would you do that ? When the user asks for interfaces with a MAC,
you don't know if they are looking for a VLAN or base device. If they
want the VLAN, how would they look that up ?
By name, or by listing all devices.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
9:08 a.m.
(expanding Cc to include libvir-list, because this is more of a libvirt
issue)
On 06/24/2009 01:52 PM, David Lutterkort wrote:
On Wed, 2009-06-24 at 18:22 +0100, Daniel P. Berrange wrote:
> On Wed, Jun 24, 2009 at 10:20:00AM -0700, David Lutterkort wrote:
>
>> On Tue, 2009-06-23 at 21:47 +0100, Daniel P. Berrange wrote:
>>
>>> Why would we ever have duplicate MAC addresses?
>>>
>> VLANs:
>>
>> # vconfig add eth0 42
>> # cat /sys/class/net/eth0.42/address
>> 00:15:58:81:5b:0e
>> # cat /sys/class/net/eth0/address
>> 00:15:58:81:5b:0e
>>
> Ok, so for the libvirt API we should define that the lookup-by-mac API
> will not return VLAN devices, since we cant provide a 1-1 lookup there
>
Why would you do that ? When the user asks for interfaces with a MAC,
you don't know if they are looking for a VLAN or base device. If they
want the VLAN, how would they look that up ?
I think we need to do one of two things:
1) Modify the existing virInterfaceLookupByMACString() api to return a
list of virInterfaces. Although the public API has been in one release,
there has been no functionality behind the API, so there's nobody using
it as it is, and nobody is going to expect to use it as it is either.
Because of that, "backward compatibility" isn't as much of an issue, and
maybe we could let this modification to the API slide.
2) If we want to be really anal, we could modify
virInterfaceLookupByMACString() to return an error if there are multiple
interfaces with that particular MAC address, then provide a new function
(name suggestion?) that would return a list of interfaces.
9:28 a.m.
New subject: [libvirt] Re: Multiple interfaces with identical mac-addresses
Laine Stump wrote:
(expanding Cc to include libvir-list, because this is more of a
libvirt
issue)
On 06/24/2009 01:52 PM, David Lutterkort wrote:
> On Wed, 2009-06-24 at 18:22 +0100, Daniel P. Berrange wrote:
>
>> On Wed, Jun 24, 2009 at 10:20:00AM -0700, David Lutterkort wrote:
>>
>>> On Tue, 2009-06-23 at 21:47 +0100, Daniel P. Berrange wrote:
>>>
>>>> Why would we ever have duplicate MAC addresses?
>>>>
>>> VLANs:
>>>
>>> # vconfig add eth0 42
>>> # cat /sys/class/net/eth0.42/address 00:15:58:81:5b:0e
>>> # cat /sys/class/net/eth0/address 00:15:58:81:5b:0e
>>>
>> Ok, so for the libvirt API we should define that the lookup-by-mac API
>> will not return VLAN devices, since we cant provide a 1-1 lookup there
>>
>
> Why would you do that ? When the user asks for interfaces with a MAC,
> you don't know if they are looking for a VLAN or base device. If they
> want the VLAN, how would they look that up ?
>
I think we need to do one of two things:
1) Modify the existing virInterfaceLookupByMACString() api to return a
list of virInterfaces. Although the public API has been in one release,
there has been no functionality behind the API, so there's nobody using
it as it is, and nobody is going to expect to use it as it is either.
Because of that, "backward compatibility" isn't as much of an issue, and
maybe we could let this modification to the API slide.
2) If we want to be really anal, we could modify
virInterfaceLookupByMACString() to return an error if there are multiple
interfaces with that particular MAC address, then provide a new function
(name suggestion?) that would return a list of interfaces.
I haven't actually dug out the relevant network specs, but IIRC it's
legal to use duplicate mac addresses on different interfaces as long as
they are in separate broadcast domains, so this discussion can't be
limited to VLANs. Also alias interfaces have the same mac as the original.
Dave
2:15 p.m.
On Wed, Jun 24, 2009 at 10:20:00AM -0700, David Lutterkort wrote:
On Tue, 2009-06-23 at 21:47 +0100, Daniel P. Berrange wrote:
> Why would we ever have duplicate MAC addresses?
VLANs:
# vconfig add eth0 42
# cat /sys/class/net/eth0.42/address
00:15:58:81:5b:0e
# cat /sys/class/net/eth0/address
00:15:58:81:5b:0e
btw, there's also bonding:
# cat /sys/class/net/bond0/bonding/slaves
eth2 eth3
# cat /sys/class/net/eth2/address
00:1d:09:68:71:4e
[root@silver-vdsa ~]# cat /sys/class/net/eth3/address
00:1d:09:68:71:4e
2:23 p.m.
On Wed, Jun 24, 2009 at 10:15:16PM +0300, Dan Kenigsberg wrote:
On Wed, Jun 24, 2009 at 10:20:00AM -0700, David Lutterkort wrote:
> On Tue, 2009-06-23 at 21:47 +0100, Daniel P. Berrange wrote:
> > Why would we ever have duplicate MAC addresses?
>
> VLANs:
>
> # vconfig add eth0 42
> # cat /sys/class/net/eth0.42/address
> 00:15:58:81:5b:0e
> # cat /sys/class/net/eth0/address
> 00:15:58:81:5b:0e
btw, there's also bonding:
If you have bonding, you're not doing lookups of the underlying devices,
the top level netcf object would be the bond device itself
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
5426
days inactive
5441
days old
netcf-devel@lists.fedorahosted.org
13 comments
6 participants
participants (6)
-
Dan Kenigsberg -
Daniel P. Berrange -
Dave Allan -
David Lutterkort -
Jonas Eriksson -
Laine Stump