Sto cercando di realizzare un sistema in cui gli indirizzi ip sono
assegnati a seconda della porta dello switch a cui è connesso il
client.
I componenti per il test sono:
- server DHCP: ISC DHCPD in linux
- switch managged con funzionalità di Relay Agent e opzione 82 (per
sfruttare le informazioni del campo agent.circuit-id)
- 1 client che deve ottenere uno specifico indirizzo ip a seconda
della porta a cui è connesso con lo switch (come da esempio gli viene
proposto l'indirizzo 192.168.1.21)
file di configurazione dhcpd.conf usato nel test
#inizio dhcpd.conf
# The ddns-updates-style parameter controls whether or not the server
will # attempt to do a DNS update when a lease is confirmed. We
default to the # behavior of the version 2 packages ('none', since
DHCP v2 didn't # have support for DDNS.) ddns-update-style none;
default-lease-time 60;
max-lease-time 60;
# If this DHCP server is the official DHCP server for the local #
network, the authoritative directive should be uncommented.
#authoritative;
# Use this to send dhcp log messages to a different log file (you also
# have to hack syslog.conf to complete the redirection).
log-facility local7;
class "uno" {
match (binary-to-ascii(16, 8, ":",option agent.circuit-id)); }
subclass "uno" "b8:6:0:0:1:1:2:1";
subnet 192.168.1.0 netmask 255.255.255.0 {
pool {
allow members of "uno";
range 192.168.1.20 192.168.1.29;
}
}
#fine file
Il server DHCP ha indirizzo 192.168.1.30 ed è connesso allo switch.
Lo switch ha ip 192.168.1.101, ha attivo il relay agent su
192.168.1.30 ( per poter sfruttare l'opzione 82).
Il client è connesso allo switch alla porta corrispondente al
circuit-id pari a "b8:6:0:0:1:1:2:1"
__________
| |
SERVER DHCPD --------| Switch |------- Client
(192.168.1.30) |__________|
(192.168.1.101)
La cattura del traffico è la seguente:
No. Time Source Destination Protocol Info
1 0.000000 0.0.0.0 255.255.255.255 DHCP
DHCP Discover - Transaction ID 0xeaa79f3f
2 0.005068 192.168.1.101 192.168.1.30 DHCP
DHCP Discover - Transaction ID 0xeaa79f3f
3 0.005072 192.168.1.30 192.168.1.101 DHCP
DHCP Offer - Transaction ID 0xeaa79f3f
4 0.010307 192.168.1.101 192.168.1.21 DHCP
DHCP Offer - Transaction ID 0xeaa79f3f
5 0.010796 0.0.0.0 255.255.255.255 DHCP
DHCP Request - Transaction ID 0xeaa79f3f
6 0.010819 192.168.1.30 255.255.255.255 DHCP
DHCP NAK - Transaction ID 0xeaa79f3f
7 0.015958 192.168.1.101 192.168.1.30 DHCP
DHCP Request - Transaction ID 0xeaa79f3f
8 0.031054 192.168.1.30 192.168.1.101 DHCP
DHCP ACK - Transaction ID 0xeaa79f3f
9 0.035778 192.168.1.101 192.168.1.21 DHCP
DHCP ACK - Transaction ID 0xeaa79f3f
inizio nuova richiesta
10 1.054794 0.0.0.0 255.255.255.255 DHCP
DHCP Discover - Transaction ID 0x4a805463
11 1.059711 192.168.1.101 192.168.1.30 DHCP
DHCP Discover - Transaction ID 0x4a805463
12 1.070605 192.168.1.30 192.168.1.101 DHCP
DHCP Offer - Transaction ID 0x4a805463
13 1.074769 192.168.1.101 192.168.1.21 DHCP
DHCP Offer - Transaction ID 0x4a805463
14 1.075175 0.0.0.0 255.255.255.255 DHCP
DHCP Request - Transaction ID 0x4a805463
15 1.075228 192.168.1.30 255.255.255.255 DHCP
DHCP NAK - Transaction ID 0x4a805463
16 1.080844 192.168.1.101 192.168.1.30 DHCP
DHCP Request - Transaction ID 0x4a805463
17 1.105987 192.168.1.30 192.168.1.101 DHCP
DHCP ACK - Transaction ID 0x4a805463
18 1.112131 192.168.1.101 192.168.1.21 DHCP
DHCP ACK - Transaction ID 0x4a805463
Il problema si riscontra in quanto il server DHCP è connesso alla
stessa subnet del client e per tal motivo il server riceve sia la
richiesta DISCOVERY broadcast proveniente dal client che quella
unicast proveniente dal Relay agent (lo switch).
In questo scenario il server invia un NAK alla richiesta del client;
allora il client annulla la richiesta e inizia una nuova transazione
anche se successivamente arriva l'ACK relatico alla precedente
transazione.
Mi potreste dare qualche suggerimento?
_______________________________________________
http://www.areanetworking.it
http://www.areanetworking.it/blog
[email protected]
http://ml.areanetworking.it/mailman/listinfo/cug
