[netcf-devel] mac-tag in XML

Jonas Eriksson jonas.j.eriksson at ericsson.com
Thu Jul 30 07:49:30 UTC 2009


On Wed, Jul 29, 2009 at 06:59:54PM +0200 David Lutterkort wrote:
> On Wed, 2009-07-29 at 09:39 +0200, Jonas Eriksson wrote:
> > Is the <mac> tag in XML to be used to search for interfaces or to
> > set the mac address of that interface that contains the mac tag?
> > As this is converted to HWADDR and, according to the info that I
> > have found, I have asumed that this is for searching for the
> > correct interface.
> 
> Yes, initscripts uses the HWADDR only to search for an interface. When
> you issue 'ifup IFACE', initscripts first look for a file ifcfg-IFACE.
> If none exists, it looks up the actual MAC address for IFACE from /sys,
> then searches for an ifcfg file that mentions that MAC as its HWADDR.
> 
> I'm actually in the middle of fixing the initscripts driver to respect
> that search order - it's not an issue for interfaces that netcf defined,
> but I also need to make sure that netcf produces reasonable results on a
> box that has been configured by hand, and the output of dumpxml/list
> etc. should match what the native scripts do.
>
> > This proved a bit difficult on SuSE, as the connection device
> > name <-> mac address is handled strictly by persistent udev-rules
> > written when an interface is first found.
> 
> Yes, that's how it's handled on newer Fedora (and I think RHEL5), too.
> The device name/MAC association is made through udev rules.
> 
> >  I solved this by
> > implementing the following prio logic:
> > 
> > 1. xmlif.name == hostif.name && xmlif.macaddr == hostif.macaddr
> > 2. xmlif.macaddr == hostif.macaddr
> > 3. xmlif.name == hostif.name
> > 
> > This may lead to interface name changing when doing a
> > define/dumpxml-cycle given that an interface with the wrong name
> > but correct mac address is found. Is this the intended way of
> > netcf's mac address handling?
> 
> Whether this is correct or not highly depends on how config files for an
> interface are searched on SuSe. I'd say whatever matches the native SuSe
> scripts is the right thing.

As SuSE's ifcfg-files do not have the possibility of this (other
than the ifcfg-eth-id-aa:bb:cc:dd:ee:ff in earlier verions), and
only handles mac-mapping through udev the behavior of the driver
is correct as implemented now, then.

I'm also thinking of moving this lookup code to dutil.c, to make
the prioritization more easily accessable. The prototype looks
like this and will always return a malloced string (or NULL if
name == NULL and no interface with matching mac was found):
char *normalize_if(struct netcf *ncf, const char *name,
    const char *mac);

> > If this assumption is correct, why cannot the interface-tag
> > inside the vlan-tag in netcf-xml contain a mac-tag? If this is
> > wrong, i hope that we can mitigate this even though the xml
> > schema is considered stable.
> 
> I didn't add a <mac> to vlan interfaces, because they always get their
> MAC address from the underlying device, and that device is known becuase
> of the naming convention for vlan's. But if you see a need to specify it
> explicitly, we can easily add that to the schema as an optional entry.

Yes, but we do have to find that underlying device somehow, and
perferrably do this through the same logic as when finding bridge
slaves or ordinary interfaces. My point is that you should be
able to say "vlan 5 of the interface with mac X", much like "br0
should enslave the interface with mac X".

/Jonas

--
Jonas Eriksson
Consultant at AS/EAB/FLJ/IL
Combitech AB
Älvsjö, Sweden


More information about the netcf-devel mailing list