JET with multiple subnets

In the simplest Jumpstart environment, the JET/Jumpstart server is sitting on the same subnet as the client being built. However, there are many situations where there is a requirement to build clients that are on different subnets than the Jumpstart server.

Unfortunately (from a complexity point of view), but fortunately (from a flexibility point of view) there are a number of ways of dealing with this issue, and what you do is dependent on your particular environment.

The problem with Jumpstart between subnets

All of the protocols used for Jumpstart use IP, and for that reason shouldn't have a problem with subnets. However, during the initial bootstrap phase, where the client is trying to get its IP address, it needs to use broadcast, and therefore SOMETHING on the local subnet needs to provide the initial IP address and boot server location information.

There are 2 cases to consider:

Subnets when using rarp/bootp

The rarp/bootp protocol does not provide routing information, therefore the server providing the tftp image and nfs boot media needs to be on the same subnet.

Subnets when using dhcp

The dhcp protocol DOES provide routing information, therefore all we need is a dhcp service provided on each subnet.

Solution 1: Use DHCP

The simplest way to allow Jumpstarting throughout a subnetted infrastructure is to use dhcp (or PXE for x64) for all builds. On each subnet, the router for that subnet should be configured to dhcp forward all requests to your JET dhcp server. See the Using DHCP with JET guide for more details.

The main issue with this configuration is that some environments do not allow dhcp on build networks, or have their own dhcp service running. There are a number of ways of engineering around this problem, but this is a dhcp issue rather than a Jumpstart issue. Work with your network team to come up with a solution. JET IS capable of updating a non-local dhcp server.

Solution 2: Multihome your JET server using VLANS.

Nothing stops you from using your networking infrastructure and VLANS to simply put your JET server on every single subnet you might want to build from.

Solution 3: Have multiple JET servers

Simply have multiple JET servers to cover your build requirements.

Solution 4: Use a connected hierarchy of JET servers

Using JET with the JetMASTER and JetSLAVE modules, you could have boot servers running JET on all your subnets, with a master JET server with all the media running centrally. On issuing a make_client on the master, it will propogate the build instruction to the correct build server based on the subnet. The JetSLAVE AND JetMASTER modules are not generally available as they require more complex setup, and would normally require an ACS engagement.

Solution 5: Use WANBOOT

If ALL your clients are SPARC machines, you could use WANBOOT. See the Jet and WanBoot guide for details.

Solution 6: Hybrid

Nothing stops you from combining the above solutions to come up with a solution that works best for your environment. The solutions have been listed in order of preference in terms of complexity and ease of use.