Menu Hamburger

Zero Touch Provisjonering i praksis

Zero Touch Provisioning

Vi har tidligere holdt foredrag om provisjonering i praksis, og nå publiserer vi den skriftlige utgaven.  

Oppsettet i helhet er publisert på GitHub, og det finner du her.

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:

DORA

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

  1. DHCP serveren mottar option 82.1 med verdi "relayhostname:ge-0/0/0:ZTP".
  2. DHCP serveren bygger så option 43.1 ved å sette sammen "?config=" og "relayhostname:ge-0/0/0:ZTP".
  3. 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: