.. meta:: :language: it :description language=it: Networking Fundamentals: DHCP :description language=en: Networking Fundamentals: DHCP :keywords: Networking Fundamentals, DHCP :author: Luciano De Falco Alfano P2/8 Dynamic Host Configuration Protocol ================================================= .. contents:: :local: 8.0 Introduzione ------------------ 8.0.1 Benvenuto ^^^^^^^^^^^^^^^^^ **8.0.1.1 capitolo 8: DHCP**. Alle risorse di rete con locazione logica statica (server, stampanti, router, ...) vengono dati indirizzi IP statici, assegnati manualmente [#]_. Per gli altri device, la maggioranza, una gestione manuale sarebbe troppo onerosa. Considerando anche l'elevata incidenza di device mobili. Quindi si ricorre al protocollo DHCP per assegnare dinamicamente i loro indirizzi. Un server centrale DHCP permette di gestire in un unico punto la logica di assegnazione degli indirizzi IP. DHCP può essere utilizzato per IPv4 (DHCPv4) e IPv6 (DHCPv6). 8.1 DHCPv4 ------------ 8.1.1 Operatività di DHCPv4 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **8.1.1.1 introduzione a DHCPv4**. DHCPv4 assegna dinamicamente indirizzi IP ed altre informazioni ai nodi di rete. Un router Cisco è in grado di fornire il servizio DHCPv4. L'assegnazione dinamica di un indirizzo IP è detta *noleggio* (*lease*) perché ha una durata temporanea. L'indirizzo è prelevato da un insieme di indirizzi disponibili (il *pool*), e perde validità dopo un determinato periodo di tempo. Usualmente da 24 ore a una settimana. Quando un *lease* scade, il client deve chiedere un nuovo indirizzo al sercer DHCPv4. Usualmente ottiene lo stesso indirizzo (rinnovo). **8.1.1.2 operatività di DHCPv4**. DHCPv4 funziona in modalità client/server. **inizio di un lease**. Quando un client parte, avvia un processo in quattro passi per ottenere un indirizzo IP, come segue. * il client invia un messaggio broadcast (layer 2 e layer 3) **dhcpdiscover**, con mittente il proprio indirizzo MAC (layer 2, il layer 3 è a 0 perchè sconosciuto), per scoprire il [#]_ server DHCP. * quando il server DHCP riceve il messaggio *dhcpdiscover*, riserva un indirizzo IP tra quelli disponibili per il client. E crea una ARP entry con MAC del richiedente e IP del lease da proporre. Quindi invia il messaggio **dhcpoffer** al client richiedente via MAC layer 2 (e layer 3 con IP in lease). * quando il client riceve il *dhcpoffer*, risponde broadcast [#]_ con un messaggio **dhcprequest** per comunicare al server l'accettazione dell'offerta. * A sua volta, quando il server riceve il messaggio *dhcprequest*, con un ping verifica che l'indirizzo sia ancora libero, crea la entry ARP per il lease ed invia un messaggio **dhcpack** al client. * il client alla ricezione del *dhcpack* registra le informazioni di lease, esegue un ARP sull'indirizzo proposto, e se l'ARP rimane senza risposta inizia ad usare l'indirizzo perché è certo che non vi sia collisione di indirizzi. **rinnovo dell'indirizzo** prima che il lease scada * il client invia un **dhcprequest** al server DHCPv4 che lo aveva assegnato. Se non riceve risposta entro un timeout, allora il client invia il *dhcprequest* via broadcast a un qualunque server DHCP in ascolto. * alla ricezioen del *dhcprequest* il server DHCP verifica le informazioni di lease inviando un messaggio **dhcpack**. Secondo lo standard ITF RFC 2131, i messaggi dhcp, sopratutto *dhcpoffer* e *dhcpack* possono essere inviati sia unicast che broadcast. Riassumendo, i messaggi chiave sono: * **dhcpdiscover**; * **dhcpoffer**; * **dhcprequest**; * **dhcpack**. **8.1.1.3 formato del messaggio DHCPv4**. Con i seguenti campi: +---------+-----------------+---------------+----------------------+--------------+ | n.word | 8 | 16 | 24 | 32 | +=========+=================+===============+======================+==============+ | 1 | OP code | hardware type | hardware addr.length | Hops | +---------+-----------------+---------------+----------------------+--------------+ | 2 | transaction identifier - 4 bytes | +---------+---------------------------------+-------------------------------------+ | 3 | seconds - 2 bytes | Flags - 2 bytes | +---------+---------------------------------+-------------------------------------+ | 4 | Client IP Address (CIADDR) - 4 bytes | +---------+-----------------------------------------------------------------------+ | 5 | Your IP address (YIADDR) - 4 bytes | +---------+-----------------------------------------------------------------------+ | 6 | Server IP address (SIADDR) - 4 bytes | +---------+-----------------------------------------------------------------------+ | 7 | Gateway IP address (GIADDR) - 4 bytes | +---------+-----------------------------------------------------------------------+ | 8 | Client hardware address (CHADDR) - 16 bytes, 4 words | +---------+-----------------------------------------------------------------------+ | ... | ... (follow) | +---------+-----------------------------------------------------------------------+ | 11 | ... (last) | +---------+-----------------------------------------------------------------------+ | 12 | Server Name (SNAME) - 64 bytes, 16 words | +---------+-----------------------------------------------------------------------+ | ... | ... (follow) | +---------+-----------------------------------------------------------------------+ | 27 | ... (last) | +---------+-----------------------------------------------------------------------+ | 28 | Boot Filename - 128 bytes, 32 words | +---------+-----------------------------------------------------------------------+ | ... | ... (follow) | +---------+-----------------------------------------------------------------------+ | 59 | ... (last) | +---------+-----------------------------------------------------------------------+ | 60 | DHCP Options - variable | +---------+-----------------------------------------------------------------------+ I campi sono i seguenti. * **Operation code** (OP Code) tipo di messaggio, 1 per richiesta, 2 per risposta. * **Hardware tipe** tipo di hardware usato in rete dati. Es. 1 Ethernet, 15 Frame Relay, 20 serial line. Stessi codici dei messaggi ARP. * **Hardware address length**. * **Transaction identifier** serve al client per matchare la risposta con la sua richiesta. * **Seconds** n.ro di secondi passati da quando il client ha iniziato a chiedere un lease. Il server lo gestisce per dare priorità alle richieste. * **Flags**. Il client setta il bit di broadcast per dire al server o all relay agent che necessita di risposta in broadcast. * **Client IP Address**. In prima richiesta quato campo è posto a 0 dal client. Se è un rinnovo, il client vi mette l'indirizzo IP da rinnovare. * **Your IP Address** il server vi mette l'inidirizzo IP proposto al client. * **Server IP Address** *a volte* utilizzato dal server DHCP, ma può essere diverso. L'indirizzo del server DHCP è *sempre* indicato nel campo speciale chiamato **Server Identifier DHCPv4 option**. * **Gateway IP Address** incanala il messaggio quando sono coinvolti DHCPv4 relay agents. Questo serve se client e server sono su (sotto)reti diverse. * **Client Hardware Address** il MAC del client. * **Server Name** *può* essere usato dal serve per indicare un proprio nickname o un DNS domain name. * **Boot filename** *può* essere usato dal client per richiedere nel *dhcpdiscover* message un partiolare tipo di boot file. Il server lo può usare per specificare una directory e file di boot. * **DHCP Options**, di lunghezza variabile, contiene vari parametri richiesti per le operazioni di base DHCP. Usato sia dal client che dal server. **8.1.1.4 messaggi DHCPv4 discover e offer**. Il client fuori rete all'avvio invia il *dhcpdiscover* message. Avremo: +-----------------------------+--------------------------+--------+--------------------+ | eth.frame | IP | UDP | DHCPDISCOVER | +=============================+==========================+========+====================+ | dest mac: ff:ff:ff:ff:ff:ff | src IP: 0.0.0.0 | UDP 67 | CIADDR: 0.0.0.0 | | | | | | | src mac: client MAC | dest IP: 255.255.255.255 | | GIADDR: 0.0.0.0 | | | | | | | | | | mask: 0.0.0.0 | | | | | | | | | | CHADDR: client MAC | +-----------------------------+--------------------------+--------+--------------------+ Si vede che è un messaggio in broadcast (vedi destination MAC e IP) per la porta UDP 67, in cui il client mette a zero tutte le informazioni sconosciute (source IP, CIADDR, GIADDR, ...). A questa il server DHCP risponde con un *dhcpoffer* message, come segue: +-----------------------------+--------------------------+--------+----------------------+ | eth.frame | IP | UDP | DHCPDISCOVER | +=============================+==========================+========+======================+ | dest mac: client MAC | src IP: 198.168.1.254 | UDP 68 | YIADDR: 192.168.1.10 | | | | | | | src mac: server MAC | dest IP: 192.168.1.10 | | GIADDR: 0.0.0.0 | | | | | | | | | | mask: 255.255.255.0 | | | | | | | | | | CHADDR: client MAC | +-----------------------------+--------------------------+--------+----------------------+ in cui il server indica le informazioni necessarie al cliente. Prima di tutto indirizzo IP (YIADDR) e netmask (mask), e altri paramentri qui non mostrati, come la durata del lease. Inoltre il *dhcpoffer* può contenere anche il *lease renewal time* e il DNS. Per concludere correttamente il dialogo, il cliente deve rispondere con *dhcprequest* e il server concludere con *dhcpack*. **8.1.1.5 attività: identificare i passi nelle oparazioni DHCPv4** **8.1.2 configurare un server DHCPv4 base**. La configurazione di base di un server DHCPv4 deve prevedere: * l'esclusione degli indirizzi IP gestiti manualmente:: R(config)# ip dhcp excluded-address low-addr [high-addr] * la creazione di un pool DHCPv4:: R(config)# ip dhcp pool pool-name R(dhcp-config)# * la configurazione del pool creato:: R(dhcp-config)# network net-addr [mask | prefix-len] R(dhcp-config)# default-router gw-addr1 [gw-addr2 ... gw-addr8] R(dhcp-config)# dns-server dns-addr1 [dns-addr2 ... dns-addr8] R(dhcp-config)# domain-name name R(dhcp-config)# lease [days [hours] [minutes] | infinite] R(dhcp-config)# netbios-name-server nns-addr1 [nns-addr2 ... nns-addr8] Dei precedenti, i primi due comandi sono obbligatori: definiscono il pool degli indirizzi e il default gateway dei client. Gli altri comandi sono facoltativi. Ad esempio:: R(config)# ip dhcp excluded-address 192.168.10.1 192.168.10.9 R(config)# ip dhcp excluded-address 192.168.10.254 R(config)# ip dhcp pool LAN-POOL-1 R(dhcp-config)# network 192.168.10.0 255.255.255.0 R(dhcp-config)# default-router 192.168.10.1 R(dhcp-config)# dns-server 192.168.11.5 R(dhcp-config)# domain-name example.com R(dhcp-config)# end Per **disabilitare** il servizio DHCPv4 si usa il comando:: R(config)# no service dhcp Mentre il comando:: R(config)# service dhcp lo abilita nuovamente. **8.1.2.2 verificare il DHCPv4**. Conficgurato il DHCPv4, il comando:: R# show running-config | section dhcp permette di controllare i comandi di configurazione effettuati. L'impegno di indirizzi IP può essere controllato usando il comando:: R# show ip dhcp binding Mentre la verifica di quali messaggi del protocollo stanno passando si effettua con:: R# show ip dhcp server statistics Questi comandi devono essere utilizzati subito dopo la configurazione del server, per controllare la baseline; e subito dopo l'accensione di uno o più client per verificare il corretto funzionamento del servizio. **8.1.2.3 DHCPv4 Relay**. Esiste la possibilità che un server DHCPv4 centralizzato operi su una rete che non sia raggiungibile via broadcast da un client, collegato in una rete diversa, la quale a sua volta è collegata tramite router [#]_. In queste condizioni, per non configurare un seconso dìserver DHPv4, è necessario utilizzare un relay agent che inoltri i messaggi DHCP tra le due diverse reti. In Cisco IOS un relay agent si configura tramite *helper address*:: R(config)# interface interf-id R(config.if)# ip helper-address dhcp-server-addr Per controllare:: R# show ip interface interf-id *Helper address* può inoltrare i seguenti servizi UDP: * porta 37, **time**; * porta 49, **TACACS** (login host protocol); * porta 53, **DNS**; * porta 67, **DHCP/BOOTP** server; * porta 68, **DHCP/BOOTP** client; * porta 69, **TFTP**; * porta 137, **NetBIOS name** service; * porta 138, **NetBIOS datagram** service. **8.1.2.4 lab - configurare un server DHCPv4 base in un router** **8.1.2.5 lab - configurare un server DHCPv4 base in uno switch** 8.1.3 configurare client DHCP ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **8.1.3.1 configurare un router come client DHCPv4** usare il lcomando:: R(config)# interface iterf-id R(config-if)# ip address dhcp Il risulato si controlla con: R# show ip interface interf-id **8.1.3.2 configurare un wireless router come client DHCPv4**. I router di casa o piccoli uffici di solito sono collegato tramite ISP o DSL. E spesso ricevono l'indirizzo IP dal ISP via DHCP. In questo caso, nell'interfaccia WEB di configurazione selezionare **automatic configuration - DHCP**. **8.1.3.3 packet tracer - configurare DHCPv4 usando Cisco IOS** 8.1.4 Troubleshoot DHCPv4 ^^^^^^^^^^^^^^^^^^^^^^^^^^^ **8.1.4.1 troubleshooting DHCPv4**. Per effettuare il troublesooting seguire questi task: #. risolvere i conflitti di indirizzi (*show ip dhcp conflict*); #. verificare la connettività fisica (*show interfaces interf-id*) ; #. provare un indirizzo IP statico; #. verificare la configurazione della porta dello switch (problemi di trunking, channeling, STP, RSTP); #. provare dalla stessa subnet/VLAN. **8.1.4.2 verificare la configurazione del router DHCPv4**. Se il router è in una rete diversa dal client, vi deve essere un relay tra i due. In questo caso: * verificare il comando *ip help-address dhco-verver-addr* ad esempio con:: R# show running-config | section interface interf-id oppure:: R# show ip interface interf-id * verificare che non sia stato eseguito il comando *no service dhcp*, ad esempio utilizzando:: R# show running-config | include no service dhcp **8.1.4.3 debugging DHCPv4** per verificare che un server DHCPv4 riceva effettivamente i messaggi del protocollo si può usare una *extended ACL* come segue:: R(config)# access-list 100 permit udp any any eq 67 R(config)# access-list 100 permit udp any any eq 68 R(config)# end R# debug ip packet 100 Dove la *extended ACL* 100 viene utilizzata dal processo di debug per mostrare i relativi pacchetti IP. Altro tool lutile in debug è:: R# debug ip dhco server events che mostra gli eventi del server dhcp, quale la presa di un indirizzo IP dal pool degli indirizzi e la sua assegnazione ad un client di determinato MAC. **8.1.4.4 lab - troubleshooting DHCPv4** 8.2 DHCPv6 -------------- 8.2.1 SLAAC e DHCPv6 ^^^^^^^^^^^^^^^^^^^^^^ **8.2.1.1 Autoconfigurazione Stateless Address (SLAAC)**. Un indirizzo IPv6 *global unicast address* può essere onfigurato manualmente o automaticamente. La configurazione automatica può avvenire in due modi: * **Statelass Address Configuration** (SLAAC); * **Dynamic Host Configuration Protocol** (stateful DHCPv6). **Introduzione a SLAAC**. Con questo metodo un client può ottenere un indirizzo IPv6 GUA senza l'uso di un server DHCPv6. Questo metodo utilizza ICMPv6, usando i messaggi **router solicitation** e **router advertisement**. * il messaggio **router solicitation** (RS) viene inviato dal client all'indirizzo **FF02::2**, ovvero *all-routers multiast address*. * il messaggio **router advertisement** (RA) è la risposta del router per fornire le informazioni necessarie ai client che devono configurare automaticamente un indirizzo IPv6. Include il *prefisso* e la *lunghezza del prefisso* del segmento locale. Queste sono usate dal client per costruire l'indirizzo IPv6. Un router invia il messaggio *RA* periodicamente, o in risposta ad un *RS*. I router Cisco inviano un *RA* ogni 200 secondi (default). L'inirizzo di destinazione dei messaggi *RA* è sempre **FF02::1** ovvero *all-nodes multicast address*. Il concetto di staeless mette in evidenz che non vi sono server che ricordano gli indirizzi assegnati. **8.2.1.2 operazioni dello SLAAC**. Per inviare messaggi *RA* il router deve essere abilitato al routing IPv6:: R(config)# ipv6 unicast-routing In queste condizioni: #. quando un client invia un messaggio *RS* a FF02::2; #. il router risponde a FF02::1 con il messaggio *RA* in cui include *prefix* e *prefix legth* della rete locale. Inoltre indica il proprio *link-local address* come IPv6 souce address; #. il client riceve il messaggio *RA*, e ricava *prefix* e prefix length* della rete (usualmente un indirizzo di 64 bit), dopo di che vi aggiunge la *interface ID* (IID), ovvero l'indirizzo host (usualmente altri 64 bit). Per creare un IID unico vi sono due possibilità: * **EUI-64** il client usa il proprio MAC address di 48 bit, modificandolo opportunamente. * **generazione casuale** il client utilizza un numero casuale generato dal suo sistema operativo. dopo di che il client unisce le due parti (prefisso di rete e IID) per generare l'indirizzo GUA e utilizza il IPv6 source address (ovvero il link-local del router) come default gateway. #. Quindi il client verifica se l'indirizzo è già in uso, perché il processo è stateless: nessun server tiene traccia degli indirizzi utilizzati. Per farlo invia un **neighbor solicitation message** (NS) ad un indirizzo multicast costruito con gli ultimi 24 bit del proprio indirizzo IPv6 (detto **solicited-node multicast adress**). Se nessuno risponde al messaggio *NS* utilizzando un **neighbor advertisement message** (NA), quasi sicuramente l'indirizzo è univoco. Se il client riceve un *NA* di risposta l'indirizzo è probabilmente già in uso e il sistema deve creare un altro IID da utilizzare. L'ultimo passo è parte del processo ICMPv6 **Neighbor Discovery**, ed è conosciuto con il nome di **Duplicate Address Detection** (DAD). **8.2.1.3 SLAAC e DHCPv6**. Nel messaggio *RA* vi sono due Flag che indicano se il client deve ottenere l'indirizzo IPv6: * solo usando i dati del *RA*; * oppure usando in parte i dati del *RA* e in parte i dati di un server DHCPv6 stateless; * oppure usando solo i dati di un server DHCPv6 stateful. I due flag sono: * **Managed Address Configuration flag** (M flag); * **Other Configuration flag** (O flag). Il client potrebbe comunque decidere di ignorare i flag *M* ed *O*, e utilizzare comunque un server DHCPv6 stateful. In ogni caso si raccomanda (RFC 4861) di eseguire sempre il controllo DAD utilizzando i messaggi di ICMPv6 (RFC 4443). **8.2.1.4 Opzione SLAAC**. Questa è la coppia di flag:: M flag = 0 / O flag = 0 ed indica che tutti i dati necessari per la generazione dell'IPv6 sono nel messaggio *RA*: * prefisso; * lunghezza del prefisso; * DNS server; * MTU; * default gateway. Il client deve generare l'IID utilizzando la procedura EUI-64 o con numero randomico. Il messaggio *RA* viene configurato su ogni singola interfaccia del router. Per essere sicuri di settare i valori a zero di questi flag si usano i seguenti comandi:: R(config-if)# no ipv6 nd managed-config-flag R(config-if)# no ipv6 nd other-config-flag **8.2.1.5 opzione stateless DHCPv6**. Il servizio DHCPv6 è definito in RFC 3315. Con l'opzione *stateless DHCPv6 e Router Advertisement*, le informazioni basilari sono trasmesse dal messaggio *RA*, le altre (di solito il o i DNS) sono disponibili da un server DHCPv6. In questo caso il server DHCP non fornisce indirizzi IPv6. Per lo stateless DHCPv6 i flag sono:: M flag = 0 / O flag = 1 e si impostano con:: R(config-if)# no ipv6 nd managed-config-flag R(config-if)# ipv6 nd other-config-flag **8.2.1.6 opzione stateful DHCPv6**. In questo caso tutte le informazioni provengono dal server DHCP, incluso l'indirizzo IPv6. Per lo stateful DHCPv6 i flag sono:: M flag = 1 / O flag = non importa e si imposta con:: R(config-if)# ipv6 nd managed-config-flag **8.2.1.7 Operazioni DHCPv6**. Come visto in precedenza, prima delle operazioni DHCPv6 vi è sempre una interazione *RS*-*RA*. Dopo di che, se *RA* indica DHCPv6 (stateless o stateful) il client deve iniziare un colloquio con il server DHCPv6. A questo scopo il client invi un messaggio DHCPv6 **solicit** all'indirizzo **FF02::1:2** che è un *all-DHCPv6-server multicast address*. Questo è un indirizzo con scopo link-local: i router non lo diffondono su altre reti. Il(i) server DHCPv6 rispondono con **advertise** che è un messaggio unicast, che informa il client della disponibilità del server. Il client ora invia un messagigo unicast **request** (o un **information-request**) a seconda che il DHCPv6 sia stateful o stateless. Se il server è stateful, il client invia *request* richiedendo l'indirizzo IPv6 e le altre infromazioni necessarie. Se il server è stateless il client invia *information-request*, richiedendo solo i parametri di configurazione, come ad es. l'inirizzo del server DNS. Mentre l'indirizzo IPv6 è generato autonomante dal client ome detto poc'anzi. Il server invia al client un messaggio **reply** contenente le informazioni richieste dalla *request*, o dalla *information-request*. **8.2.1.8 attività - identificare i passi della opratività DHCPv6** 8.2.2 Stateless DHCPv6 ^^^^^^^^^^^^^^^^^^^^^^^^^ **8.2.2.1 configurare un router come Server DHCPv6 stateless**. Quindi le informazioni principali inviate con messaggio *ruoter advertising* e gli altri parametri di configurazione tramite server DHCPv6. Bisogna effettuare 4 passi: * abiltare il routing IPv6; * configurare un pool DHCPv6; * configurare i parametri del pool; * configurare l'interfaccia DHCPv6; in generale eseguendo questi comandi:: R(config)# ipv6 unicast-routing R(config)# ipv6 dhcp pool pool-name R(config-dhcpv6)# dns-server dns-address R(config-dhcpv6)# domain-name dom-name R(config-dhcpv6)# exit R(config)# interface interf-id R(config-if)# ipv6 dhcp server pool-name R(config-if)# ipv6 nd other-config-flag Un esempio può essere il seguente:: R(config)# ipv6 unicast-routing R(config)# ipv6 dhcp pool IPV6-STATELESS R(config-dhcpv6)# dns-server 2001:db8:cafe:aaaa:5 R(config-dhcpv6)# domain-name example.com R(config-dhcpv6)# exit R(config)# interface g0/1 R(config-if)# ipv6 address 2001:db8:cafe:1::1/64 R(config-if)# ipv6 dhcp server IPV6-STATELESS R(config-if)# ipv6 nd other-config-flag **8.2.2.2 configurare un router come client di un DHCPv6 stateless**. Un client ha bisogno di un indirizzo *link-local* per poter operare con i protocolli IPv6. In Cisco IOS l'indirizzo *link-local* viene creaato automaticamente quando si abilita IPv6 in una interfaccia. Il seguente esempio abilita ipv6 sull'interfaccia e la configura per ottenere un indirizzo GUA in modo automatico:: R(config)# interface g0/1 R(config-if)# ipv6 enable R(config-if)# ipv6 address autoconfig il comando *ipv6 address autoconfig* abilita la configurazione automatica dell'indirizzo tramite SLAAC. **8.2.2.3 verificare DHCPv6 stateless** si deve analizzare l'esito del comando:: R# show ipv6 dhcp pool che deve indicare il pool configurato e i relativi parametri principali: dominio, server DNS, n.ro di client. Notare il fatto che non è indicata la rete su cui è attivo il pool: infatti dipende dall'interfaccia su cui il pool è stato legato. Anche *show running-config* è utile per verificare i comadi configurati Un client si presenta così:: R# show ipv6 interface g0/1 ... Stateless address autoconfig enabled Global unicast address(es): 2001:DB8:CAFE:1:32F7:DFF:FE25:2DE1,... Mentre per vrificare lo scambio di messaggi tra client e server si può usare:: R# debug ipv6 dhcp detail ... **8.2.3.1 configurare un router come server DHCP stateful** è simile alla configurazione stateless, ma in più vi è l'allocazione degli indirizzi nel pool. Quindi le fasi sono: * abilitare il routing IPv6; * configurare un pool DHCPv6; * configurare i parametri del pool; * configurare l'interfaccia. I comandi sono:: R(config)# ipv6 unicast-routing R(config)# ipv6 dhcp pool pool-name R(config-dhcpv6)# address prefix addr-prefix/length [lifetime {valid preferred |infinite}] R(config-dhcpv6)# dns-server dns-address R(config-dhcpv6)# domain-name dom-name R(config-dhcpv6)# exit R(config)# interface interf-id R(config-if)# ipv6 dhcp server pool-name R(config-if)# ipv6 nd managed-config-flag R(config)# ipv6 unicast-routing R(config)# ipv6 dhcp pool IPV6-STATEFUL R(config-dhcpv6)# address prefix 20018:DB8:CAFE:1::/64 lifetime infinite R(config-dhcpv6)# dns-server 2001:db8:cafe:aaaa:5 R(config-dhcpv6)# domain-name example.com R(config-dhcpv6)# exit R(config)# interface g0/1 R(config-if)# ipv6 address 2001:db8:cafe:1::1/64 R(config-if)# ipv6 dhcp server IPV6-STATEFUL R(config-if)# ipv6 nd managed-config-flag **8.2.3.2 configurare un router come client di un DHCPv6 stateful**, come segue [#]_:: R(config)# interface g0/1 R(config-if)# ipv6 enable R(config-if)# ipv6 address dhcp **8.2.3.4 verificare DHCPv6 stateful**. Come per lo stateless, utilizzare il comando per verificare il pool:: R# show ipv6 dhcp pool Mentre è possibile verificare il legame tra *link-local* e indirizzo assegnato al client tramite il comando (su server):: R# show ipv6 dhcp binding Client FE80::32F7:DFF:FE25:2DE1 ... Address: 2001:DB8:CAFE:1:5844:47B2:2603:c171 ... dove FE80:... è il local-link del client, mentre 2001:DB8:... è l'indirizzo GUA assegnato dal server. Questo legame è registrato perché è un server stateful, mantiene traccia dello stato della rete gestita. Nel client il comando:: C# show ipv6 interface g0/1 permette di verificare l'avvenuta ricezione dell'indirizzo e relativa configurazione da parte del client. Da notare che anche in questo caso, il default gateway è copiato dal mittente del messaggio *RA*. non dal server DHCPv6. **8.2.3.4 configurare un router come relay agent di DHCPv6**. Questa configurazione è analoga a quella di un relay agent IPv4 per DHCPv4. Questo corso non riporta il dettaglio dell'inoltro dei messaggi dal relay agent al server DHCPv6. Il relay agent è configurato con: R(config)# interface g0/0 R(config-if)# ipv6 dhcp relay destination 2001:db8:cafe:1:6 Il risultato si può controllare con:: R# show ipv6 dhcp interface g0/0 GigabitEthernet0/0 is in relay mode Relay destinations: 2001:DB8:CAFE:1::6 **8.2.3.5 lab - configurare DHCPv6 stateless e stateful** 8.2.4 Troubleshoot DHCPv6 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ **8.2.4.1 attività di troubleshooting** sono analoghe a quelle di DHCPv4: #. isolvere i conflitti di indirizzi; #. verificare i metodi di allocazione; #. provare con un indirizzo IPv6 statico; #. verificare la configurazione delle porte dello switch; #. provare dalla stessa subnet o VLAN. Per i conflitto di indirizzi utilizzare:: R# show ipv6 dhcp conflict che mostra il log dei conflitti rilevati dal server. Se vi è un conflitto, tipicamente il client DHCPv6 rimuove l'indirizzo e ne chiede uno nuovo. Per la verifica del metodo di allocazione: C# show ipv6 interace interf-id l'ultima linea dell'output permette di verificare come è stato allocato l'indirizzo. Riguardo l'uso di un indirizzamento statico, serve a verificare la connessione della rete. Se il client non raggiunge le risorse di rete con un indirizzo statico, il problema non è il DHCP (v6 o v4): è necessario effettuare il troubleshooting della connessione di rete. Per lo switch: se non permette il passaggio delle frame, il client non può funzionare. Verificare il trunking, il channeling e lo spanning treee. Di solito usando le configurazioni PortFast e edge port si risolvono i probelmi più comuni. Riguardo l'uso della stessa subnet o VLAN. In questo modo si elimina temporaneamente l'uso di un relay agent, concontrandosi sull'attività di configurazione client-server. Messa a punto questa, si passa al relay agent. L'interfaccia del router verso oil client deve essere configurata con:: R(config-if)# ipv6 dhcp relay destination **8.2.4.2 verificare la configurazione DHCPv6 di un router**. Le configurazioni dei servizi DHCPv6 stateless e stateful sono simili, ma hanno delle differenza significative. Servizi DHCPv6 stateful:: R(config)# ipv6 unicast-routing R(config)# ipv6 dhcp pool IPV6-STATEFUL R(config-dhcpv6)# address prefix 2001:DB8:CAFE:1::/64 lifetime infinite #+1 R(config-dhcpv6)# dns-server 2001:db8:cafe:aaaa::5 R(config-dhcpv6)# domain-name example.com R(config-dhcpv6)# exit R(config)# interface g0/1 R(config-if)# ipv6 address 2001:db8:cafe:1::1/64 R(config-if)# ipv6 dhcp server IPV6-STATEFUL R(config-if)# ipv6 nd managed-config-flag #-+1 in cui vi è il comando *address prefix ...* per configurare le informazioni d'indirizzamento. Inoltre il comando *ipv6 nd managed-config-flag* accende il bit M, che indica al client di rivolgersi ad un server DHCPv6 stateful per avere le informazioni relative all'indirizzo. Servizi DHCPv6 stateless:: R(config)# ipv6 unicast-routing R(config)# ipv6 dhcp pool IPV6-STATELESS R(config-dhcpv6)# dns-server 2001:db8:cafe:aaaa::5 R(config-dhcpv6)# domain-name example.com R(config-dhcpv6)# exit R(config)# interface g0/1 R(config-if)# ipv6 address 2001:db8:cafe:1::1/64 R(config-if)# ipv6 dhcp server IPV6-STATEFUL R(config-if)# ipv6 nd other-config-flag #-+1 qui *non abbiamo* il comando *address prefix ...*. Mentre il comando *ipv6 nd other-config-flag* accende il bit O, che indica al client di utilizzare per l'indirizzo le informazioni del messaggio *RA* e di rivolgersi ad un server DHCPv6 stateless per gli altri parameti di configurazione. Per visualizzare la configurazione corrente si può usare il comando:: R# show ipv6 interface iterf-id Che nell'ultima riga di output indica la modalità di funzionamento dell'indirizzamento automatico: * *Hosts use stateless autoconfig for addresses* per lo SLAAC; * *Hosts use DHCP to obtain other configuration* per il DHCPv6 stateless; qui abbiamo *ipv6 nd other-config-flag* e il client usa SLAAC per le informazioni d'indirizzamento, e il server DHCPv6 per gli altri parametri di configurazione; * *Hosts use DHCP to obtain routable addresses* per il DHCPv6 stateful; qui vale *ipv6 nd managed-config-flag* e il client recupera dal server DHCP sia le informazioni di indirizzamento che le altre informazioni. **8.2.4.3 debugging di DHCPv6**. Quando il router è configurato come server DHCPv6 stateful o stateless, per verificare l'invio e la ricezione di messaggi DHCPv6 si può usare:: R# debug ipv6 dhcp detail **8.2.4.4 lab - troubleshooting DHCPv6** 8.3 sommario -------------- 8.3.1 conclusioni ^^^^^^^^^^^^^^^^^^^ **8.3.1.1 attività di classe - IoE e DHCP** **8.3.1.2 packet tracer - skills integration challenge** **8.3.1.3 capitolo 8: DHCP** ------------------- .. [#] Anche per permettere una gestione da remoto più semplice. .. [#] Oppure *i server*, possono essere più di uno. .. [#] Broadcast perché in caso di più server DHCP, vengono avvertiti anche gli altri server che la loro offerta non è stata utilizzata. .. [#] Ricordiamo che un router non propaga i broadcast. .. [#] Ndr: non capisco perché questa configurazione deve essere diversa rispetto quella del client di un DHCPv6 stateless. Un client è un client, a mio avviso le differenze dovrebbero essere solo a livello di server.