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
zones-discuss@opensolaris.org

Reply via email to