Zero Touch Provisioning
Vi har tidligere holdt foredrag om provisjonering i praksis, og nå publiserer vi den skriftlige utgaven.
Målet for denne demonstrasjonen var å koble opp en fabrikkny Juniper EX2300-12T og få den til å provisjonere seg selv, uten menneskelig interaksjon. Demonstrasjonen var vellykket da switchen ble tilgjengelig via management-addresse spesifisert i config-fil hentet inn av den fabrikknye switchen.
Metoden som switchen bruker til å identifisere seg selv, hente config og eventuelt oppgradere JunosOS til spesifisert versjon heter Zero Touch Provisioning (ZTP).
ZTP baserer seg tungt på DHCP.
Terminologi
- Access Switch: Den fabrikknye switchen som skal få config automatisk. I mange kontekster kaldt "klient", da den er en klient i en protokollmodell.
- Distrobution Switch: I dette tilfellet her så er det enheten som tar seg av ruting, og da DHCP relay-ing.
- DHCP relay: En funksjon på en nettverksenhet som fasiliterer kontakt mellom en lokal DHCP-klient (i samme LAN) og en sentral DHCP-server.
- DHCP option: En bit med informasjon i en DHCP-pakke, som enten klient eller server kan velge å bruke.
Topologi

I demonstrasjonen ble det brukt 2 x EX2300-12T, men mange modeller i EX/QFX-serien (alle?) støtter Zero Touch Provisioning.
Enheter
- Distribution: Juniper EX2300-12T
- Blank/Aksess: Juniper EX2300-12T
- DHCP/HTTP-server: Felles virtuell Debian-instans
Nettverket mellom distribution switch og access switch er 10.0.30.0/24. For enkelhetens skyld har vi fjernet andre nettverk fra distribution switch, men original config ligger på Github som nevnt lenger opp.
Programvare og versjoner
På DHCP- og HTTP-serveren kjører Debian Jessie (8.7) med ISC-DHCP-server 4.3.1, Apache 2.4.10 og PHP 5.6.30. Alt dette er open source, og enkelt tilgjengelig på internett.
Hvilken DHCP- og HTTP-server man velger å bruke er egentlig ikke viktig, så lenge den nødvendige funksjonaliteten støttes. Apache og PHP kunne f.eks vært byttet ut med nginx og python.
DHCP som protokoll
DHCP brukes hovedsaklig til å dele ut nettverksinformasjon til klienter som spør om det. Ofte ser man på det som at DHCP kun deler ut IP-adresser, DNS og default gateway. DHCP er derimot en fleksibel protokoll, som i stor grad baserer seg på options. Options er bruddstykker med informasjon som en DHCP-klient og DHCP-server kan velge å forholde seg til. Både DHCP-klienter og DHCP-servere kan sette inn DHCP options.
En option kan f.eks være hvilken default route klienten skal få, eller hvilken NTP-server klienten kan bruke. Eller eksotiske, veldig lite brukte options som f.eks default IRC-server på nettverket.
Kommunikasjonen mellom DHCP-klient og DHCP-server under oppkobling vil se slik ut:

DHCP-klient i denne settingen er da altså den fabrikk nye switchen som blir koblet opp og skal finne configen sin.
Overordnet virkemåte
- Juniper-boksen sender ut DHCP-forespørsler, med visse options satt.
- DHCP server responderer med visse options satt.
- Juniper-boksen spør en sentral server om config, og eventuelt nytt image.
- Sentral server responderer med config og eventuelt nytt image.
- Juniper-boksen commiter configen og eventuelt installerer nytt image.
Oppsett på Distribution Switch
DHCP-klienter broadcaster ut DHCP DISCOVER-pakker. Det vil si at de DHCP DISCOVER-pakkene i utgangspunktet holder seg innenfor ett broadcast-domene. For å få de DHCP DISCOVER-pakkene fra DHCP-klienten til en sentral server bruker vi en metode som heter DHCP relay.
DHCP relay fungerer på den måten at den lytter til DHCP-pakker som blir broadcastet, og videresender de unicast til en DHCP server. Den vil på samme vis sende DHCP-pakkene som DHCP-serveren responderer på tilbake til DHCP-klienten. I grafikken under vil DHCP relay-en være plasset i midten, og behandle alle DHCP-pakkene.
Rent configmessig ser den slik ut:
interfaces {
ge-0/0/0 {
description "Towards customer";
native-vlan-id 10;
unit 0 {
family ethernet-switching {
interface-mode trunk;
vlan {
members [ ZTP ];
}
}
}
}
irb {
unit 10 {
description ZTP;
family inet {
address 10.0.10.1/24;
}
}
}
}
forwarding-options {
dhcp-relay {
server-group {
ZTP-DHCP {
1.2.3.4;
}
}
active-server-group ZTP-DHCP;
group ZTP-GROUP {
relay-option-82 {
circuit-id {
prefix {
host-name;
}
}
}
interface irb.10;
}
}
}
vlans {
ZTP {
vlan-id 10;
l3-interface irb.10;
}
}
Det er verdt å merke seg denne configen her:
relay-option-82 {
circuit-id {
prefix {
host-name;
}
}
}
Den instruerer Distribution switch i å sette på option 82 i DHCP-pakkene fra klienten. Option 82 inneholder med dette informasjon om hostnamet til DHCP-relayen, den fysiske porten DHCP-klienten er tilkoblet, og hvilket VLAN den er tilkoblet.
Kort fortalt gir dette grunnlaget for at sentralt system (DHCP/HTTP-server) kan identifisere hvilken klient som er tilkoblet, uten å kjenne til f.eks MAC-adresse på forhånd.
Oppsett DHCP-server
DHCP-serveren sin funksjon i seg selv er egentlig ganske enkel - den deler ut IP-adresser og DHCP options til klientene som spør. I dette eksempelet her er det ISC-DHCP som gjør den jobben, da den er fleksibel å sette opp.
DHCP DISCOVER-pakka treffer DHCP-serveren. DHCP-serveren ser på innholdet i DHCP DISCOVER-pakka, og matcher den mot sin config. I vårt tilfelle vil den bl.a. se på option 82.
# Definerer struktur på options som skal brukes.
option space ztp;
option ztp.config-file-name code 1 = text;
option ztp.transfer-mode code 3 = text;
option ztp-encapsulation code 43 = encapsulate ztp;
option option-150 code 150 = { ip-address };
group {
default-lease-time 120;
max-lease-time 120;
vendor-option-space ztp;
option option-150 10.0.30.2;
option ztp.transfer-mode "http";
option ztp.config-file-name = concat("?config=", (option agent.circuit-id));
subnet 10.0.10.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option routers 10.0.10.1;
pool {
range 10.0.10.100 10.0.10.200;
}
}
}
Det som skjer i denne configen er at på toppen definerer vi strukturen av option 43. Det gjøres fordi det er en "fleksibel option" som produsenter kan velge å strukturere som de vil. De har valgt å ha bruke suboptions (options i options) for å kunne sende flere parametere til klienten i samme option.
Det interessante i denne configen er egentlig linjen som inneholder "concat". DHCP-relayen setter, som tidligere forklart, inn option 82 med en suboption 1 (circuit-id, også vist som 82.1). DHCP-serveren tar da den innkommende verdien i denne optionen og returnerer den til kilenten i en annen option ("ztp" med suboption, som definert i toppen av configen), sammen med en annen streng.
Eksempel
- DHCP serveren mottar option 82.1 med verdi "relayhostname:ge-0/0/0:ZTP".
- DHCP serveren bygger så option 43.1 ved å sette sammen "?config=" og "relayhostname:ge-0/0/0:ZTP".
- DHCP-serveren sender DHCP OFFER til klienten (via DHCP relay) vil option 43.1 inneholde "?config=relayhostname:ge-0/0/0:ZTP" og option 43.3 inneholde "http". Option 150 vil inneholde "10.0.30.2" som er IP-adressen til HTTP-serveren.
Når DHCP-transaksjonen er gjennomført mellom DHCP-server og DHCP-klient vil med andre ord DHCP-klienten ha følgende informasjon:
- Hvilken IP-adresse den skal ha
- Hvilken subnettmaske den skal ha
- Hvilke default route den skal ha
- Hvilken URL som skal hentes
- Hvilken protokoll som skal benyttes for å hente config (HTTP)
- IP-adressen til HTTP-server som inneholder ZTP-data (config i dette tilfellet, kunne óg vært ny software)
HTTP-server
HTTP-serveren har som oppgave å motta en HTTP-forespørsel (i vårt tilfelle "GET /?config=relayhostname:ge-0/0/0:ZTP HTTP/1.1") og svare opp med innhold. Innholdet er i vårt tilfelle en configfil (i vanlig Junos-syntax).
Som et veldig enkelt eksempel kan vi bruke følgende PHP-kode i index.php i rotmappa på serveren.
<?php
if(isset($_GET['config']) && $_GET['config'] === 'relayhostname:ge-0/0/0:ZTP'){
readfile('example.conf');
}
Videre vil det være naturlig å knytte dette opp mot en database.
Hva skjer videre nå
Den fabrikknye switchen vil nå bruke den informasjonen som er mottatt via DHCP til å sette seg opp rent nettverksmessig, og hente config fra sentral server. Den vil committe configen, og da være ferdig provisjonert.
Hva som skal være i configen som sendes til switchen vil være opp til dere.
Linker:
- Juniper Understanding Zero Touch Provisioning
- Juniper Day One: Deploying Zero Touch Provisioning
- ISC-DHCP man pages
- Debian
- PHP