Login

Benvenuto, Ospite
Nome utente: Password: Ricordami
  • Pagina:
  • 1
  • 2

ARGOMENTO:

Messaggi DHCP - Offer & Ack - Unicast & Broadcast 9 Anni 4 giorni fa #16

  • roberto ulisse
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
qui un tracciamento con ethereal dei messaggi dhcp, e' evidenziato il messaggio di offer con in giallo e rosso il bt di broadcast settato a zero, puoi notare che le risposte sono tutte in broadcast a livello tre ed anche a livello due


Allegati:

Si prega Accedi a partecipare alla conversazione.

Messaggi DHCP - Offer & Ack - Unicast & Broadcast 9 Anni 4 giorni fa #17

  • jpalombi
  • Avatar di jpalombi Autore della discussione
  • Offline
  • Administrator
  • Administrator
  • Messaggi: 2641
  • Ringraziamenti ricevuti 1107

roberto ulisse ha scritto: con l'uso degli unicast a livello due si ottiene l'obiettivo di scaricare di lavoro inutile alle altre interfaccie di rete nel domino di broadcast quale e' l'esigenza e la necessita' di utilizzare anche gli ip unicast?


Per una questione di coerenza. Quando la scheda di rete del server incapsula a layer 2, per mettere un broadcast assoluto a Layer 3 dentro un unicast di Layer 2 dovrebbe contravvenire a quello che è il mapping (ARP cache) FFFF:FFFF:FFFF <--> 255.255.255.255 (perchè se è vero che lo stesso MAC può mappare/incapsulare differenti IP, allo stesso IP non corrispondono mai 2 o più MAC differenti. Cosa tra l'altro particolarmente logica: l'ethernet non può certo trovarsi in una situazione di conflittualità, e ovviamente un servizio di livello 7 non può certo dettare legge su uno di livello 2).


roberto ulisse ha scritto: qui un tracciamento con ethereal dei messaggi dhcp


Ti riporto un altro pezzo di RFC:

A server or relay agent sending or relaying a DHCP message directly
to a DHCP client (i.e., not to a relay agent specified in the
'giaddr' field) SHOULD examine the BROADCAST bit in the 'flags'
field. If this bit is set to 1, the DHCP message SHOULD be sent as
an IP broadcast using an IP broadcast address (preferably 0xffffffff)
as the IP destination address and the link-layer broadcast address as
the link-layer destination address. If the BROADCAST bit is cleared
to 0, the message SHOULD be sent as an IP unicast to the IP address
specified in the 'yiaddr' field and the link-layer address specified
in the 'chaddr' field. If unicasting is not possible, the message
MAY be sent as an IP broadcast using an IP broadcast address
(preferably 0xffffffff) as the IP destination address and the link-
layer broadcast address as the link-layer destination address.


Praticamente il tuo server ignora quel bit come descritto nel passaggio in grassetto. Il motivo andrebbe chiesto al produttore

NB: 0xffffffff è l'esadecimale di 255.255.255.255
IpCert Instructor
CCENT - CCNA - CCNA CyberOps - CCNP Enterprise - CCNP Collaboration - CCNP Service Provider
CCS - Enterprise Core, Ent. Advanced Infrastructure, SP Core, SP Advanced Routing, SP VPN Services, Collaboration Core, Coll. Applications

Si prega Accedi a partecipare alla conversazione.

Ultima Modifica: da jpalombi. Motivo: sistemazione spaziatura

Messaggi DHCP - Offer & Ack - Unicast & Broadcast 9 Anni 4 giorni fa #18

  • roberto ulisse
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
bene bene, quasi tutti i tasselli stanno andando al loro posto, la storia del server "indipendente" la avevo immaginata, del resto nel bit di broadcast il client mette una sua disponibilita' che non e' detto che il server recepisca ed attui anche quando possibile.
Adesso pero spunta un'altra questione e cioe' quella che potrai verificare dalle figure e cioe' che nella discovery il client ha messo a zero il bit di broadcast e quindi ha chiesto l'unicast ma nel messaggio ha impostato solo il client mac address e nessun ip, quindi anche se il server avese voluto quale indirizzo ip destinatario avrebbe potuto mettere, nella rfc mi pare di capire che si dica che il client indichi nel campo yaddr il ip richiesto ma qui nela discovery tutti i campi indirizzo livello 4 stanno azzerati, e poi se cosi fosse il client come potrebbe essere sicuro di non indicare un ip gia' in uso? probabilmente anche questa indicazione e' solo una preferenza e disponibilita' questa come prima sta al server scegliere se rispettarla o meno a seconda se l'indirizzo indicatogli dal client e' utilizzato da qualcun'altro o meno.
Quindi c'e' ancora da chiarire questo fatto e poi e' sospeso anche cio' che ho notato scritto nella rfc.
"The TCP/IP software SHOULD accept and forward to the IP layer any IP packets delivered to the client's hardware address before the IP address is configured;" non e' che si debba dire meglio: "The IP software SHOULD accept and forward to the udp (or tcp) layer any IP packets delivered to the client's hardware address before the IP address is configured;" a me cosi pare piu' chiaro
si o no?

Si prega Accedi a partecipare alla conversazione.

Ultima Modifica: da roberto ulisse. Motivo: ggiustamenti

Messaggi DHCP - Offer & Ack - Unicast & Broadcast 9 Anni 4 giorni fa #19

  • roberto ulisse
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
il client che ha generato questi messaggi e' microsoft win 7, quindi nulla di strano.

Si prega Accedi a partecipare alla conversazione.

Messaggi DHCP - Offer & Ack - Unicast & Broadcast 9 Anni 4 giorni fa #20

  • jpalombi
  • Avatar di jpalombi Autore della discussione
  • Offline
  • Administrator
  • Administrator
  • Messaggi: 2641
  • Ringraziamenti ricevuti 1107

roberto ulisse ha scritto: se cosi fosse il client come potrebbe essere sicuro di non indicare un ip gia' in uso?

Il client in fase discovery non valorizza nulla, e come potrebbe chiedere un IP non sapendo nemmeno su che rete si trovi? È normale che sia tutto a 0, la scelta è del server.
IpCert Instructor
CCENT - CCNA - CCNA CyberOps - CCNP Enterprise - CCNP Collaboration - CCNP Service Provider
CCS - Enterprise Core, Ent. Advanced Infrastructure, SP Core, SP Advanced Routing, SP VPN Services, Collaboration Core, Coll. Applications

Si prega Accedi a partecipare alla conversazione.

Messaggi DHCP - Offer & Ack - Unicast & Broadcast 9 Anni 4 giorni fa #21

  • roberto ulisse
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
Leggendo cio' che e' evidenziato qui:

e che riporto testualmente qui: "Normally, DHCP servers and BOOTP relay agents attempt to deliver DHCPOFFER, DHCPACK and DHCPNAK messages directly to the client using unicast delivery.
The IP destination address (in the IP header) is set to the DHCP 'yiaddr' address and the link-layer destination address is set to the DHCP 'chaddr' address. "
e che traduco qui:"Normalmente, i server DHCP e BOOTP relays agent tentano di recapitare i messaggi di DHCPOFFER, DHCPACK e DHCPNAK direttamente al client utilizzando cnsegna unicast. L'indirizzo IP di destinazione (nell'intestazione IP) è impostato su 'yiaddr' indirizzo DHCP e l'indirizzo di destinazione del livello di collegamento è impostato l'indirizzo DHCP 'chaddr'."
quindi dice che e' l'ip destinazione ad essere impostato come yaddr (The IP destination address (in the IP header) is set to the DHCP 'yiaddr') e non il contrario come tu affermi che sia il server a mettere li l'indirizzo che sceglie e nello stesso pacchetto lo usera' come ip destinazione (a cosa servirebbe ripeterlo?); io giustificavo e ritenevo che potesse essere utila ad un client rimettere il vecchio ip per esempio un client che si fosse spento per un tempo maggiore del lease time (e comunque un pc che si spegne non e' certo e sicuro al 100% alla riaccensione del tempo passato) in quel caso il client avrebbe potuto tentare di inserire nel campo YADDR il suo vecchio ip cosi per cercare di riottenerlo nuovamente , tutte le considrazioni sono SHOULD e mon MUST, quindi se come dici tu il client sbagia indirizzo che e' occupato oppure si risveglia su nn'atra net semplicemente il server ignora e facoe vuole lui!, io avevo pensato cosi, prendo atto che tu dici non sia cosi ma sia come hai scritto prima.
Ancora non hai risposto a quanto ho scritto prima e cioe' se la frase "The TCP/IP software SHOULD accept and forward to the IP layer any IP packets delivered to the client's hardware address before the IP address is configured;" non sia da considerare meglio scritta cosi,: "The TCP/IP software SHOULD accept and forward to the IP upper layer identified by the protocol field information present in the IP header (udp for the case) any IP packets delivered to the client's hardware address before the IP address is configured;".
Da cio' che scrive pare che il processo TCP/IP debba accettare e forwardare ad ip (errato!), semmai e' ip (la parte di tcp/ip che si interfaccia al llc) che accetta l'indicazione (indicazione=interazione level 2->level 3 che e' notifica di riccevimento di una PDU) e quindi decapsula la pdu di livello tre e la consegna ( o forwarda come dice la rfc) al livello 4 udp e non ip come scritto anche se ancora non c'e' un ip definito all'interfaccia.
Allegati:

Si prega Accedi a partecipare alla conversazione.

Ultima Modifica: da roberto ulisse. Motivo: importanti integrazioni

Messaggi DHCP - Offer & Ack - Unicast & Broadcast 9 Anni 3 giorni fa #22

  • jpalombi
  • Avatar di jpalombi Autore della discussione
  • Offline
  • Administrator
  • Administrator
  • Messaggi: 2641
  • Ringraziamenti ricevuti 1107

roberto ulisse ha scritto: quindi dice che e' l'ip destinazione ad essere impostato come yaddr (The IP destination address (in the IP header) is set to the DHCP 'yiaddr') e non il contrario come tu affermi che sia il server a mettere li l'indirizzo che sceglie e nello stesso pacchetto lo usera' come ip destinazione (a cosa servirebbe ripeterlo?)


Stai traducendo male, è esattamente il contrario. Quello che segue dunque va rivisto in considerazione di questo.
IpCert Instructor
CCENT - CCNA - CCNA CyberOps - CCNP Enterprise - CCNP Collaboration - CCNP Service Provider
CCS - Enterprise Core, Ent. Advanced Infrastructure, SP Core, SP Advanced Routing, SP VPN Services, Collaboration Core, Coll. Applications

Si prega Accedi a partecipare alla conversazione.

  • Pagina:
  • 1
  • 2
Moderatori: jpalombi