P2/8 Dynamic Host Configuration Protocol¶

8.0 Introduzione
- 8.0.1 Benvenuto
8.1 DHCPv4
8.2 DHCPv6
8.3 sommario
- 8.3.1 conclusioni

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 1.

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 2 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 3 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 mac: client MAC

src IP: 0.0.0.0

dest IP: 255.255.255.255

UDP 67

CIADDR: 0.0.0.0

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 mac: server MAC

src IP: 198.168.1.254

dest IP: 192.168.1.10

UDP 68

YIADDR: 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 4.

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 5:

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

1: Anche per permettere una gestione da remoto più semplice.
2: Oppure i server, possono essere più di uno.
3: Broadcast perché in caso di più server DHCP, vengono avvertiti anche gli altri server che la loro offerta non è stata utilizzata.
4: Ricordiamo che un router non propaga i broadcast.
5: 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.

networking fundamentals notes

Navigazione

Related Topics