You are not signed in. or register.

Network Auto-Magic Story Boards

Here are some "story boards" to explain what this project is about. We are using these to describe what various user experiences should be like, as a way to gather requirements. Note that the stories are presented in the usual black text on a white background whereas commentary about the stories is in white text on an orange background.

John is an experienced Solaris developer. He has a Ferrari 3400 laptop with Solaris (a mixture of 10 and Nevada) installed. He uses it in the office, at home, and especially on the road. He has the following network profile expectations:

When in his office (i.e., his actual office in MPK17), he plugs in an Ethernet cable and expects to get a DHCP address: any address on the SWAN (Sun Wide Area Network: essentially the network inside Sun's firewall) will do.
When at work but not in his office (i.e., anywhere else in MPK17), he uses wireless and expects to get a DHCP address outside the SWAN. In particular, MPK17 has two WLANs: one (named rover) which is open (the essid is broadcast), but which is NAT'd such that it is not useful for punchin (the name of some IPsec-based VPN software to create a tunnel to the SWAN), the other (named punchin) which may not be open (the essid is not broadcast), which can be used for punchin. (There are limitations in Solaris' IPsec implementation which prevent multiple punchin clients behind a single NAT box from working simultaneously; these limitations are being addressed by Tunnel Reform.) He expects to be queried the first time (i.e., the first time a given essid/bssid combination is encountered), and to indicate a preference for punchin, then to have the punchin WLAN selected automatically thereafter (i.e., any subsequent times that essid/bssid combination is encountered).
When at home in his home office, he plugs in an Ethernet cable and expects to get a DHCP address: an address which reverse maps to a requested domain name.
When at home outside of his office, he uses wireless and expects to get a DHCP address which maps to the same domain name. His home WLAN is closed (the essid is broadcast, but a WEP key is required), so he expects to be prompted for the key the first time, then to have that WLAN selected automatically thereafter.
When on the road, he uses wireless and will take whatever he can get to get on-line, punchin and check his mail. WLAN availability in the wild is completely haphazard, so he expects to be queried before connecting to any WLAN for the first time, so he can manually select a WLAN to avoid the possibility of doing something illegal.
When the IP address he gets is off-SWAN, he will often want to "punch in" (i.e., start the punchin software to create a tunnel to the SWAN) but generally wants to do this manually. Likewise, "punching out" is more often than not triggered manually, with the notable exception of system shutdown, when it should be automated.

John also has a different set of IP Filter rules which he would like in place depending on the scenario:

When on the SWAN, no filtering is needed.
When anywhere else, heavy filtering is required: all in-bounds ports are blocked except SSH from certain trusted IP addresses.

And he has different expectations for HTTP proxies:

When directly connected to the Internet, no proxies should be used.
When on the SWAN (whether directly or via any sort of VPN), the closest proxy should be used. John happens to have some knowledge of some proxies but not all and which proxy is best at any given time seems to vary greatly.

And finally:

He expects all of these scenarios to be dealt with "automagically": the system does as much as it can on its own, and only prompts the user when necessary. The trigger for the automation should be one of:
- the plugging in of an Ethernet cable
- the plugging in of a WLAN card
- booting when an Ethernet and/or wireless interface is available
- (when supported) resuming from suspend when an Ethernet and/or wireless interface is available
- moving into range of a wireless AP
- the enabling of the WiFi radio via the physical switch available on the Ferrari (and many other laptops)

Thus we can extract the following requirements:

The system must have the general ability to query the user, and not just "OK to do X?" type queries, but queries which allow for text input. Specific types of queries for various scenarios should be arranged. Furthermore, the default behavior when no user is logged in to any graphical window manager (i.e., either there are terminal-based logins only, or nobody is logged in at all), must be sane, and we must not allow the no-GUI scenario to prevent us from doing anything in this space.
The user should be able to specify a domain name to have the system request DHCP for.
The system needs to keep track of WLANs to which it has connected.
More generally, the system need to keep track of locations in such a manner that a return to a previous location should result in the same NWC as the previous time.
The system needs to be capable of DNA.

John also has four "desktop" systems: a SunBlade-2000 (his actual desktop in the office), an Ultra-10 (his test machine in the office), an Ultra-60 (his desktop at home) and an Ultra-10 (at home, used as a mail & web server for his personal domain). Each of these uses a single static IP address (the two at work use SWAN addresses, the two at home use ISP addresses). For each of these boxes, Solaris NWC is just fine at present.

Darren is an experienced Solaris developer like John, who has the same type of laptop and uses it in quite similar ways, but with some additional needs:

In addition to just getting IP addresses, he also wants to join the local NIS or LDAP name service domain and get local printing set up.
He would also like an override so that he can go "Standalone" even when he can see WiFi networks - sometimes he just does not want to be seen by anyone else or be seen on the network.
He would also like some preference where he can say what happens when both wired and wireless are available. He thinks the default should be to enable wired, but we should allow for wireless to be the default and also to have both enabled, particularly if they are both on the same LAN (IPMP between wired and wireless ).

Dan is an experienced Solaris developer like John and Darren, who has the same type of laptop and uses it again in quite similar ways, but with one other exception:

He has two different prefixes on the same LAN segment at his house. One is the Cable company's, where he gets DHCP, and all of that. Another is a net-10 prefix, where his local at-home IP services (printer, etc.) reside. He would like to be able to have bge0:0 on the cable modem's prefix, and bge0:1 on the net-10 at the same time. It's convoluted, but it's possible.

Eric Admin wants to add capacity to an existing pool of hardware resources by adding a piece of hardware that is probably pretty similar to other pieces of hardware already there; i.e., it is some h-scaled pool of machines. Each machine has a couple of network cards, and Eric may be using hardware virtualization on the machines to allow different OS instances to map to each device, or is sharing some devices between OSes using software bridging, or maybe he is running a single instance of Solaris with multiple NICs. And of course he is using Zones too.

Eric wants as few places as possible to have to "pre-configure" the system(s) and system images beyond some higher-level policy statements (a statement like "clone this template" is OK); i.e. we would need to use various discovery protocols to find what is present where it is connected to and ideally to configure it in a "reasonable" way, pending more specialized configuration.

Weimin has a laptop he uses for personal information and personal work. He uses it primarily in the office (where it is not networked because of corporate policy), at a coffee shop (where he uses a wireless connection) and at home (where he uses a pay-per-hour DSL connection).

In the office, he expects to be able to use his computer without problems even though it has no network connection. Of course, he understands that things like web access and shared directories will not work.

In the coffee shop, he expects to be able to just open the laptop and have it automatically connect to the network there without prompting him at all. [The first time he went into the shop, he had to tell the computer about the network, but has long since forgotten this].

At home, he plugs in a network cable, and tells the computer to connect to the DSL network. [Because of the cost of using the network, he does not want the computer to automatically connect when the cable is put in], but he does not want to do more than just issue a "[dis-]connect to my home network" command [he does not want to type in username, password, or even see this info].

Sometimes a friend visits him at home, and he wants to share his network connection with his friend. So, he just wants to issue a "Wirelessly share my network connection with other people in the room" command. Again, he does not want to see what is going on.

Note that one of Weimin's expectations is in direct contrast with one on John's; i.e., John expects everything to happen when he plugs in an Ethernet cable whereas Weimin expects nothing to happen until he explicitly requests it. This would imply that the mechanism for both expectations needs to be supported, though which policy should be enabled by default needs further input to be decided. An important datum is that Mac OS X's default policy is to do everything when an Ethernet cable is plugged in (i.e., John's scenario).

Jane's expectations are very similar to John's except she has a daughter who occasionally borrows her laptop. When this happens, Jane wants to be able to enable a certain profile (she doesn't care exactly how, as long as it is fairly easy to do) which will trigger a stricter set of IP Filter rules, restrict certain WLANs from being connected to, etc.

Sebastien is a developer much like John, Darren and Dan. His story is not much different from theirs in that he has a laptop that he lugs around between home and work, and that he likes to have his Ethernet or wireless interfaces automatically configured via DHCP. He would like to point out one additional detail though.

When he is at home, he is either connected to his home wireless network to access his local IP services and the public Internet, or he is connected to his home wireless network and "punched in" to the SWAN. These two states have properties that have already been detailed in other people's stories.

In both cases, he is connected to his home wireless network. When he goes from state 1 to state 2, he would hope that his wireless interface does not get unplumbed/disconnected, then reconnected/replumbed. This situation could be generalized to two profiles that share some configuration that should remain in place when transitioning between those profiles.

Should the system automatically know that the wireless interface is involved in both profiles, and that it should not touch it when going from one profile to the other?

Andre is a developer and works for DusselFranc LLG in the capital of Lukteinstein. He works in the main office three days each week. For two days each week he works out of his home office in the hilly suburbs outside of the capital. In the office he uses his laptop attached to a docking station and essentially gets a wired connection. At home, however, his only networking choices are dial-up or a via-satellite networking solution. The latter is far too expensive for either him or his company, so he uses dial-up.

When he is at home, he plugs his laptop in when he starts working. Because phone access is charged per minute in Lukteinstein, Andre prefers to start and stop the network access only when he particularly needs access (e.g. to do a check-in or check-out, or send batches of email). He also requires VPN any time he connects to the DusselFranc intranet. His preference is simply to perform a single gesture to start the dial-up and VPN connection, and another to disable.

Al is a developer whose story is similar to that of John and Dan, but with an extra requirement: he would like there to be different sorting criteria for order in which multiple WiFi networks would be presented to a user:

By network signal strength (strongest first)
By security "rating", where rating would include:
- insecure
- WEP secured
- WPA secured
- WPA2 secured
By "familiarity". One has been used on many occasions for many hours at a time - so the user is "familiar" with it and would probably use it again.
Likewise, where one has been used on several occasions, but only remained connected on it for a few minutes or did not move much traffic over it, it is probably the result of several unsuccessful attempts to use it ... and should be at the bottom of the user's familiarity ordering.
Various combinations of 1 through 3. That is, allow a secondary and tertiary sort key.

Stuart is a professor who has an IBM notebook (T43p) that comes with XP and an IBM (now Lenovo) application called Access Connections. It scans adapters for networks with set up profiles and connects as appropriate. For example, he has a DHCP entry using the built-in gigabit ethernet, an 802.11g entry using WPA for home, an 802.11a entry using WEP for work, an 802.11g entry without encryption for the general university network (requires a VPN to do anything of use), and so on. Works nicely and fairly automatically. It even allows control of default printers, web browser home page, internet connection sharing, and so on for each separate profile. If he leaves work and bring home the notebook, it connects to the 802.11g home profile. When he goes back to work and the built-in gigabit is available via the cable plugged into a docking station, the DHCP profile is used.

He would like to see something similar for Solaris.

Erik is a developer whose story is somewhat similar to John's, but with certain differences needing emphasis.

When some low-level "trigger" event (plugging in the Ethernet cable, walking into range of an AP) happens, the system should have different responses depending on the policy. Possibilities include:
- nothing
- a pop-up window asking "Do you want to connect?"
- some "discovery" mechanisms e.g. to determine what the IP subnet is, which might then trigger an event for some higher level policy engine
Mechanism and policy need to be separated, so that the solution can apply to servers (which have different policy mechanisms, but might still want to discover that after <insert network infrastructure provider name here> leaves the lab, Jurassic finds that one of its NICs is connected to the wrong subnet).
The solution needs to consider servers, but in terms of aiding configuration and "post <insert network infrastructure provider name here> verification". For instance:
- Detecting that two NICs are connected to the same switch which is speaking LACP; can suggest to use link aggregation.
- Detecting that two NICs are connected to the same subnet; can suggest to setup IPMP.
- Detecting when a static IP address doesn't match the IP addresses that are used on the subnet (probably requires heuristics).
A sys-admin needs to clone a big server (like Jurassic), so after installing from DVD, the 15+ NICs need to be matched up with the 15+ Ethernet cables in the corner of the room. What happens next?

Erik's second story suggests the need for some sort of verification functionality, where the user asynchronously asks the system to verify that everything is configured as specified, and the system checks and reports any problems. His fourth story suggests the need for export/import functionality: the user on one system can export the configuration, which will result in that configuration being saved in some format which can be copied to another machine and imported there.

Liz is a system administrator for a small company. The company has two locations and Liz works at one of them. She has setup an install server with images of Red Hat Linux and Solaris - which she then uses to setup laptops for her company's execs and marketing staff - most of whom are located at the other location. Both locations have static addressing and a different DNS setup (domains) on their networks.

When installing at her site, she completes the Red Hat network install successfully and at the end, the installer asks if she would like to apply the information she has used to do the network install or enter new information. Knowing the configuration at the other location is different, she just supplies information applicable to that location. When the execs get their Red Hat installed laptops, they just work with the local network. However when she starts installing Solaris, there is no such option and she discovers that the only way she can provide this is to do a sys-unconfig once the system is setup. She is mad. :-(

Liz's story implies the need for a distinction between the profile used at installation time vs the profile used later for the "working" system.

Tony is in Sun IT, specializing in setting up people for iWork (i.e., Sun people working remotely in all sorts of different environments). He reports:

Each story above covers another aspect to a "typical" iWork user, i.e., there is no typical iWork user: it is any one who works nomadically in any fashion - road warrior, home based, campus flitter, coffee shop user.
I have given up trying to please everyone. Something like the Mac tool is probably something that is closest to what we need with an addition of maybe a user settable option to turn on/off trying to automatically configure networking (since it takes forever to timeout if a network is not available and it is trying to get a DHCP address).
If you could provide something that is as good as Windows, it would satisfy the majority of people, i.e.:

set DHCP/static wired network setup
don't hang if it is setup to use wired but there is no connection
if you see a wireless AP, tell me about it
allow me to automatically connect to a wireless AP if I have already told you to
allow me to save ESSID/encryption keys accordingly.
One thing I would like to see is a default option not to bring up the wireless interface if there is already a wired interface configured and vice versa. Bridging networks is not good, i.e., a user on the SWAN via wired ethernet but has wireless interface listening as well which configures itself to an external non-SWAN network. There are those times when you want to have both interfaces up, which is why it needs to be an option, but I think it should default not to do it. Another option would be to splash up a warning with an Accept button before it happens.

Bill loves cars. He suggests:

Consider a mobile embedded system (I'm thinking of a large-capacity automotive digital audio (mp3, etc.) player. Like dme's E450, only not as power hungry )
Add a short-range wireless interface (802.11 or what have you).
When your car is parked within range of your home wireless network, it should be able to automatically join the network and resynch with your home music collection, pull upgraded maps for nav system, etc., etc.)

Jurassic is a big server: a SunFire with over 330 mail users, over 500 home directory users, 40 IPv4 addresses, 18 IPv6 address (plus loopback for each) and IPMP used to manage the different interfaces and addresses. All of the IP addresses are static. Although no specific requirements are imposed by a configuration like this, it does impose a general requirement of being able to scale to this degree. It also imposes the general requirement that any solution not break existing functionality (e.g., if a sys-admin were to dynamically reconfigure a NIC, something sane should happen: the principle of least surprise is in play here).

Following is an excerpt from the lead Jurassic administrator:

The main question is, is this project just going be be some glue to manipulate the existing network configuration and do the appropriate "ifconfig" invocations, or are you guys going to change the way in which we store the network config information.

If you guys change the way we store and manage network configurations, I think jurassic adds the requirement of providing a tool that can convert a large complex configuration into the new database. If upgrading jurassic to this feature required me to manually re-enter the current configuration, I'd be pissed! Jurassic's config will become more complicated in the near future, by making use of the aggregation and vlanning features provided by nemo. This tool should not only be available during upgrade, but at any time so that admins can slap down any old config they may have laying around, and then convert it to the new database. Perhaps if the system boots and detects the existence of the old /etc/whatever files, it can automatically generate a new config based on these files, and log some messages about this to help out the admin.

The main point is, don't make this painful for admins that have been using the existing static config methods. Give them tools so that they can still use their old configs, at least initially.

You've already mentioned the scaling issues in this web page. This is obvious. Don't be like sysidtool and spend forever interrogating all the interfaces one by one.

Open Questions

Some questions have been raised about how the system should react to changes in network topology and configuration. E.g., if a new WLAN was detected in addition to the two existing WLANs, should the system still proceed with the previous selection? Or present a new option? (John's tentative thought is to present a new option.) What about other changes in the network configuration? (John is not sure, hence this question section to solicit feedback.

None of the stories have yet discussed Zones.

Does anyone know anything about diskless systems? Editor's note: I have never run across one of these in almost 9 years at Sun, but senior engineers ask about them often enough that it seems we need to consider them.

What are the requirements for configuring systems in a horizontally-scaled, grid-type environment?

Is there something different about what should be experienced during installation of the system vs. day-to-day use?

We need a story to cover a Red Hat user who is new to Solaris: what expectations and assumptions does s/he bring?

OpenSolaris

Network Auto-Magic Story Boards