Edward Pilatowicz wrote:
hey erik,
some questions after reading the interface document. (and i apologize in
advance if some of the questions seem silly because i'm not a networking
expert.)
No problem - I explicitly want reviews from the zones perspective. And
I'm getting reviews from the networking experts as well.
- what will happen in zonecfg if the administrator sets
ip-type=exclusive and then also configures networking parameters
(address and netmask) for an interface?
zonecfg verify will print an error message. It checks that address is
set if the ip-type is shared, and that is is not set if the ip-type is
exclusive.
- how about the opposite scenario. a user configures a zone with
without and an exclusive ip instance and sets up a bunch of network
configuration inside that zone that would normally only apply to a
zone with an exclusive ip instance. then the user boots the zone.
does this result in any errors during boot?
The same thing would happen as if you today did
echo 10.1.2.3 >/etc/hostname.bge0
echo 10.1.1.1 >/etc/defaultrouter
reboot
in a zone. This is silently ignored.
(Or, as I've seen some scripts do, put IP configuration into
$ZROOT/etc/sysidcfg; also silently ignored today.)
The way the smf methods are structured in S10 they skip the IP level
configuration. The only change introduced by IP instances is the
predicate used to test whether to skip.
For example, net-physical has these udiffs:
-smf_is_globalzone || exit $SMF_EXIT_OK
+smf_configure_ip || exit $SMF_EXIT_OK
- you mention that no GLD or layer 2 changes will be supported inside
zones. your example then mentions aggregations. i'm rusty on
remembering all the layers so i'll just ask, are vlans and ip
tunnels supported
Aggregations can be configured using dladm in the global zone, and then
the aggr<N> datalink names can be given to exclusive-IP zones.
VLANs will be supported for GLDv3 devices. (We can't get e.g. the ce
driver to have a separate /dev/ce<N> entry per instance and per VLAN.)
IP tunnels work today, but they are not devices but a funny construct
using a tunneling streams module.
The clearview tunnel project will turn tunnels into GLDv3 links, and
they are aware of the implications of IP instances. (I use separate IP
Instances on the laptop punched into separate punchin points just for fun.)
- if an a zone is configured with an exclusive stack, will the
/dev (and eventually /dev/net) devices associated with that stack
also be automatically imported into that zone? if so, then how does
this interact with non-native zones? (linux won't be expecting
/dev/bge0 in it's namespace. linux uses network devices like
/dev/net0.)
Yes.
The BrandZ merge was done recently, hence is not covered in the design
document.
One part is getting things like /dev/ip show up in the exclusive-IP
zones, and not in the shared-IP zones.
This is done by extensions to platform.xml in the form of
+ <!-- Devices to create in exclusive IP zone only -->
+ <device match="ip" iptype="exclusive" />
The other part is e.g. /dev/bge33000, which is done with
di_prof_add_dev() as part of the vplat bringup.
Should we just limit that to certain brands for the time being? Or we
can disable the ability to setup exclusive-IP with certain brands.
Suggestions?
- wrt to brandz, supporting an exclusive ip instance in an an lx
branded zone will require the implementation of network configuration
interfaces within the lx brand. it will probably involve translating
a bunch of ioctls and socket operations. also, looking at a centos
machine i see that it uses iptables instead of ipfilters. so all
the iptables configuration system calls would need to be translated
into their corresponding ipfilters commands.
I've asked Darren Reed whether it is even feasible to do iptables to IP
Filter mappings.
will this project do this work? if not it seems that users should be
unable to create such a configuration in zonecfg.
No.
We can certainly disable IP instances with non-native brands in zonecfg.
But I assume we'd want to support sn-1, thus "non-native" might not be
the right test.
- have you considered providing a way to configure an ip instance
assigned to a zone from the global zone?
Yes. Whether it is sensible depends what the definition is of
"configure". If all we are talking about is static configuration i.e. an
ifconfig and route command done at boot time, then I'm sure the one can
put together a solution in many different ways.
However, I doubt the desire stops at static configuration.
If there is a need to do dynamic configuration, whether a DHCP client or
a routing daemon, then I think such an approach becomes intractable.
In such a case the non-global zone has to have some observability and
interaction with the daemon. For instance being able to start it and
stop it, but also be able to extract non-IP configuration from the DHCP
client (DNS configuration, timezone, etc.)
I doubt "static only" would be a stable state. For the dynamic approach
I suspect it is less work, short-term as even more so as brandZ evolves,
in doing the ioctl translation and running the regular Linux daemons.
this would help with the situation above where the lx branded zone
can't configure itself.
another reason that i ask this is because currently you plan to make
SMF startup scripts detect if a zone has an exclusive configuration
or not.
Yes, all encapsulated in the form of smf_configure_ip.
this becomes more complicated when it comes to modifying
linux startup scripts. currently we disable most of them. if we
take the same approach for non-native zones then we'll have to stop
disabling the script and patch them to be stacked instances aware
as well?
Do you disable them, or do they check "has IP already been configured"
and just skip doing the work themselves?
- you mention that this will help us get NAT support for zones, then
you also mention vSwitch. so i'm a little confused. after ip
instances goes back will we be able to use the global zone as a NAT
for local zones or not? (rfe 6338667) if so, could you provide an
example configuration to illustrate how this might be setup using
ip instances? if not, could you explain a little more what additional
functionality is still required?
What this project provides by itself is IP isolation when different
zones are connected to different (V)LANs.
To easily do NAT in the global zone there is a need for an internal-only
Ethernet software construct.
The crossbow project is building that as a combination of what is
currently called a vSwitch and a VNIC.
The VNIC support is already there in the crossbow bits folks can
download from opensolaris.org.
The vSwitch, which isn't much code at all, remains to be done.
- will dladm show-* subcommands work in a zone? will they display the
interfaces associated with exclusive ip instances assigned to that
zone?
dladm is restricted to PRIV_SYS_NET_CONFIG, hence only works in the
global zone.
- clearview will allow interfaces to be renamed via dladm, so once an
interface has been assigned exclusively to a zone will zone
administrators be able to rename it via dladm?
Yes. But what problem are you trying to solve?
The clearview team realizes that renaming as a way to replace an
Ethernet is a fine thing, but other forms of renaming require changing
other configuration that use the name.
Thus if you use dladm vanity naming to name bge0 to be net3, then later
you can rename e1000g2 to be net3 without any effect on the rest of the
system. Other forms of rename will require changes elsewhere (ipf.conf,
zonecfg).
Erik
_______________________________________________
zones-discuss mailing list
[email protected]
