Azure

OpenStack

VMware

Advanced Install

Cluster Administration

Upgrade/Software Updates

User Management

Troubleshooting

User Guides

Bare Metal: Network Setup

This guide shows how to create a DHCP/TFTP/DNS network boot environment to work with bootcfg to boot and provision PXE, iPXE, or GRUB2 client machines.

bootcfg serves iPXE scripts or GRUB configs over HTTP to serve as the entrypoint for CoreOS cluster bring-up. It does not implement or exec a DHCP, TFTP, or DNS server. Instead, you can configure your own network services to point to bootcfg or use the convenient coreos/dnsmasq container image (used in libvirt demos).

Note: These are just suggestions. Your network administrator or system administrator should choose the right network setup for your company.

Requirements

Client hardware must have a network interface which supports PXE or iPXE.

Goals

Add a DNS name which resolves to a bootcfg deploy.

Chainload PXE firmware to iPXE or GRUB2

Point iPXE clients to http://bootcfg.foo:port/boot.ipxe

Point GRUB clients to http://bootcfg.foo:port/grub

Setup

Many companies already have DHCP/TFTP configured to "PXE-boot" PXE/iPXE clients. In this case, machines (or a subset of machines) can be made to chainload from chain http://bootcfg.foo:port/boot.ipxe. Older PXE clients can be made to chainload into iPXE or GRUB to be able to fetch subsequent configs via HTTP.

On simpler networks, such as what a developer might have at home, a relatively inflexible DHCP server may be in place, with no TFTP server. In this case, a proxy DHCP server can be run alongside a non-PXE capable DHCP server.

This diagram can point you to the right section(s) of this document.

The setup of DHCP, TFTP, and DNS services on a network varies greatly. If you wish to use rkt or Docker to quickly run DHCP, proxyDHCP TFTP, or DNS services, use coreos/dnsmasq.

DNS

Add a DNS entry (e.g. bootcfg.foo, provisoner.mycompany-internal) that resolves to a deployment of the CoreOS bootcfg service from machines you intend to boot and provision.

dig bootcfg.foo

If you deployed bootcfg to a known IP address (e.g. dedicated host, load balanced endpoint, Kubernetes NodePort) and use dnsmasq, a domain name to IPv4/IPv6 address mapping could be added to the /etc/dnsmasq.conf.

# dnsmasq.conf
address=/bootcfg.foo/172.18.0.2

iPXE

Servers with DHCP/TFTP/ services which already network boot iPXE clients can use the chain command to make clients download and execute the iPXE boot script from bootcfg.

proxy DHCP

Alternately, a DHCP proxy server can be run alongside an existing non-PXE DHCP server. The proxy DHCP server provides only the next server and boot filename Options, leaving IP allocation to the DHCP server. Clients listen for both DHCP offers and merge the responses as though they had come from one PXE-enabled DHCP server.

coreos/dnsmasq

On networks without network services, the coreos.com/dnsmasq:v0.3.0 rkt ACI or coreos/dnsmasq:latest Docker image can setup an appropriate environment quickly. The images bundle undionly.kpxe and grub.efi for convenience. Here are some examples which run a DHCP/TFTP/DNS server on your host's network: