On Thu, Jun 18, 2009 at 04:06:40PM +0200, Daniel Veillard wrote:
> On Thu, Jun 18, 2009 at 10:46:45AM +0100, Daniel P. Berrange wrote:
>
> > > > I was thinking of sugesting an attribute
> > > >
> > > > <ip type="ipv6" address="2001:23::2" prefix="24"/>
> > > >
> > > > but I think its possibly better to have a different element name
> > > >
> > > > <ip6 address="2001:23::2" prefix="24"/>
> > > >
> > > > since the former would not work if we ever needed to worry about
> > > > non-IP based addresses.
> > >
> > > Either works for me, with a slight preference for the first version, on
> > > purely esthetic grounds. And even if we go with that, there's nothing
> > > keeping us from adding an <ipx> element as an alternative to the <ip>
> > > element in the future.
> >
> > Or a 3rd option is to group addresses by family
> >
> >
> > <addresses family='ipv4'>
> > <ip address='122.0.0.3' prefix='24'/>
> > <ip address='24.24.224.4' prefix='24'/>
> > </addresses>
> > <addresses family='ipv6'>
> > <ip address='2001:23::2' prefix='48'/>
> > <ip address='fe:33:55::33' prefix='64'/>
> > </addresses>
> > <adddresses family='ipx'>
> > <ipx address='2423.4521.66.3.252.'/>
> > </address>
>
> Hum, right now the syntax is far more restrictive for addressing,
> there is one address, period, with an optional route we need to extend
> that IMHO.
>
> [...]
>
> The problem with the propsal is that it opens the door to a variety of
> errors like using the same familly twice, which I would like to avoid
> at the RNG level but it's not trivial.
>
> We should allow standalone IPv4 and IPv6, or both. Each could either
> use DHCP or allow one or more IP address and routes.
You need to have allow for IP adddresses & routes to be present even
when doing DHCP, because you need to discover what was auto-configured.
> I think if we have routes, at most one need to be a gateway and the
> other ones having destination + prefix.
>
> So I suggest the following rewrite of interface-addressing
>
> <!-- Assignment of IP address to an interface -->
> <define name="interface-addressing">
> <choice>
> <ref name="interface-addr-ipv4"/>
> <ref name="interface-addr-ipv6"/>
> <group>
> <ref name="interface-addr-ipv4"/>
> <ref name="interface-addr-ipv6"/>
> </group>
> </choice>
> </define>
>
> This allows one or 2 blocks of addresses ipv4, ipv6 or both
This is overly strict, because it does not allow for an interface
without any addresses - something you want todo if configuring a
bridge device just for guest traffic and do not want any IP on it
for the host. So just need to make both optional
<define name="interface-addressing">
<group>
<optional>
<ref name="interface-addr-ipv4"/>
<optional>
<optional>
<ref name="interface-addr-ipv6"/>
<optional>
</group>
</define>
>
> <define name="interface-addr-ipv4">
> <element name="addresses">
> <attribute name="family">
> <value>ipv4</value>
> </attribute>
> <choice>
> <ref name="interface-addr-static"/>
> <ref name="interface-addr-dhcp"/>
> </choice>
> </element>
> </define>
>
> An IPv4 addresses block, allows for either static or dhcp
> <define name="interface-addr-ipv6">
> <element name="addresses">
> <attribute name="family">
> <value>ipv6</value>
> </attribute>
> <choice>
> <ref name="interface-addr-static"/>
> <ref name="interface-addr-dhcp"/>
> </choice>
> </element>
> </define>
>
> same for IPv6
Not quite - IPv6 needs to allow for more options
- static - fully manual setup
- autoconf - auto assign addresses/routes. Assume DNS etc via dhcpv4 or manual
- autoconf + statless dhcp - auto assign addresses/routes. DNS etc via dhcpv6
- statefull dhcp - everything via dhcpv6
Check out this preso for an overview if you dare.
http://lacnic.net/documentos/lacnicxi/presentaciones/autoconf_and_dhcpv6.pdf
In all cases we need to include <ip> tags to show the manual, or
automatically configured addresses/routes.
> <define name="interface-addr-static">
> <oneOrMore>
> <element name="ip">
> <attribute name="address"><ref name="ip-addr"/></attribute>
> <attribute name="prefix"><ref name="prefix-pattern"/></attribute>
> </element>
> </oneOrMore>
> <optional>
> <ref name="interface-addr-routes"/>
> </optional>
> </define>
>
> A static addressing scheme is made of one or more <ip> elements with
> address and prefix followed by optional routing info
>
> <define name="interface-addr-dhcp">
> <element name="dhcp">
> <optional>
> <attribute name="peerdns">
> <ref name="yes-or-no"/>
> </attribute>
> </optional>
> </element>
> </define>
>
> For DHCP the only option is the peerdns yes/no attribute
>
> <define name="interface-addr-routes">
> <element name="route">
> <attribute name="destination">
> <value>default</value>
> </attribute>
> <attribute name="gateway"><ref name="ip-addr"/></attribute>
> </element>
> <zeroOrMore>
> <element name="route">
> <attribute name="destination"><ref name="ip-addr"/></attribute>
> <attribute name="prefix"><ref name="prefix-pattern"/></attribute>
> <optional>
> <attribute name="gateway"><ref name="ip-addr"/></attribute>
> </optional>
> </element>
> </zeroOrMore>
> </define>
>
> And for routes we have at least one default route and
> then an optional set of routes with prefixes and optional gateways for
> that device. To note all the ip/dhcp/route constructs are similar for
> IPv4 and IPv6 as we don't check content precisely here. I assume it's
> sufficient.
The 'ip-addr' match rule will need separate rules for IPv4 vs IP6
addresses, since the former use '.' as a seprator, while the latter
use ':'. The 'prefix-pattern' can be same, since its just a number
>
> <interface type="ethernet" startmode="onboot">
> <name>eth1</name>
> <mtu size="1500"/>
> <mac address="00:1A:A0:8F:39:A6"/>
> <addresses family='ipv4'>
> <dhcp peerdns="no"/>
..... possible <ip> tag(s) here if interface is active
> </addresses>
> </interface>
>
> <interface type="ethernet" startmode="none">
> <name>eth2</name>
> <addresses family='ipv4'>
> <dhcp/>
> </addresses>
> <addresses family='ipv6'>
> <dhcp/>
This also needs to indicate whether 'autoconf' is on vs off.
Probably just want an <autoconf/> element for that with
any combo of '<dhcp/>' and '<autoconf/>' allowed, including
neither.
> </addresses>
> </interface>
>
> <interface type="ethernet" startmode="hotplug">
> <name>eth3</name>
> <mac address="00:1A:A0:8F:50:B7"/>
> <addresses family='ipv4'>
> <ip address="192.168.0.15" prefix="24"/>
> <ip address="192.168.1.10" prefix="24"/>
> <route destination="default" gateway="192.168.0.1"/>
> <route destination="192.168.1.0" prefix="24" gateway="192.168.1.1"/>
> </addresses>
> </interface>
>
> This makes parsing a bit heavier, and I didn't checked if this really
> affected bridging and bonding interfaces in a wrong way, but I think
> that at least at an ethernet level definition this looks more complete.
>
> That said I have no idea how much of a problem it would be on the netcf
> impletmentation side.
>
> Daniel
>
> P.S.: full rng attached, double check the prefix-pattern definition
> I have no idea if it's sufficient for Ipv6
The prefix is fine. the ip address rule needs to allow ':' for IPv6.
> <!-- A Relax NG schema for network interfaces -->
> <grammar xmlns="http://relaxng.org/ns/structure/1.0";
> datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes";>
> <start>
> <choice>
> <ref name="ethernet-interface"/>
> <ref name="bridge-interface"/>
> <ref name="bond-interface"/>
> </choice>
> </start>
>
> <!--
> FIXME: How do we handle VLAN's ? Should they be their own interface
> or should we treat them as an option on the base interface ? For
> example, for vlan eth0.42, it would make sense to make that part of
> the definition of the eth0 interface.
> -->
VLANs are tricky, because you can define VLANs on a physical
inteface or a bond interface, and you then may want to also
add a bridge on top of a VLAN, eg take 2 physical NICs, eth0
and eth1, here are some possible combes
- One NIC for storage, another for host mgmt, and put
the guests all on VLANs
eth0 -> br0 IP addr used for storage
eth1 -> br1 IP addr used for host mgmt
eth1.42 -> br1.42 IP addr, used to talk to guests
eth1.43 -> br1.43 No IP, guest traffic only
eth1.44 -> br1.44 No IP, guest traffic only
- Bonded NICs, used for everything
eth0 + eth1 -> bond0 -> br0 IP addr used for all
- Bonded NICs, and VLANs for guests
eth0 + eth1 -> bond0 IP addr used for host admin+storage
bond0.42 -> br0.42 IP addr, used to talk to guests
bond0.43 -> br0.43 No IP, guest traffic only
- Bonded NICs, and VLANs for host and for guests
eth0 + eth1 -> bond0 No IP, not used directly.
bond0.42 IP addr, Host mgmt traffic
bond0.43 -> br0.43 No IP, guest traffic only
I think the currently approach of modelling bond, bridges and NICs
makes this a little hard, particularly if the netcf API only exposes
'connections' and not interfaces, because some of these setups are
not really connections, only building blocks for 'n' other connections
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 :|
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list