Login

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

ARGOMENTO:

Messaggi DHCP - Offer & Ack - Unicast & Broadcast 9 Anni 2 Settimane fa #1

  • jpalombi
  • Avatar di jpalombi Autore della discussione
  • Offline
  • Administrator
  • Administrator
  • Messaggi: 2641
  • Ringraziamenti ricevuti 1106
Salve a tutti,
segnalo la presente risorsa del blog per chi volesse approfondire l'argomento.

www.ipcert.it/blog/entry/messaggi-dhcp-o...icast-broadcast.html

Buona lettura ;)
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
Ringraziano per il messaggio: mrizzi

Si prega Accedi a partecipare alla conversazione.

Messaggi DHCP - Offer & Ack - Unicast & Broadcast 9 Anni 2 Settimane fa #2

  • roberto ulisse
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
Vorrei evidenziare come l'affermazione che i pacchetti di risposta alle dchp discovery e cioe le offer non siano unicast ma che possano essere sia broadcast che unicast cosi come descritto nella RFC 2131; inoltre vorrei fare osservare a tutti che quando eventualmente esplicitamente richiesto dal client che la negoziazione sia dhcp avvenga attraverso lo scambio di messaggi unicast (apppunto settando opportunamente un bit nel messaggio di discovery) questi messaggi siano unicast sia lvello due ed anche a livello tre e poi incapsulati in datagrammi puntanti alle porte UDP 67 e 68, e quindi non strutturati solamente a livello 2.

Si prega Accedi a partecipare alla conversazione.

Messaggi DHCP - Offer & Ack - Unicast & Broadcast 9 Anni 1 Settimana fa #3

  • mrizzi
  • Offline
  • Elite Member
  • Elite Member
  • Messaggi: 101
  • Ringraziamenti ricevuti 9
Ciao a tutti,
una curiosità:
sul sito Cisco, nella descrizione del servizio DHCP, viene specificato che nella versione IOS 12.2 sono supportate solamente le interfacce ethernet; sapete se nelle versione successive sono supportate anche le seriali?

Grazie

Si prega Accedi a partecipare alla conversazione.

Messaggi DHCP - Offer & Ack - Unicast & Broadcast 9 Anni 1 Settimana fa #4

  • roberto ulisse
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
Cio' che scrivi dovrebbe implicare una profonda riflessione sugli argomenti che trattammo all'inizio e cioe' il metodo di analisi (OPEN SYSTEM INTERCONNECTION) per strati dei processi di comunicazione che e' la linea guida che consente di semplificare e dominare tali contesti.
Secondo il modello OSI la stratificazione delle funzioni rende indipendenti due livelli distanti piu' di un "hop", intendo dire che il livello 3 non si deve interessare (NE INTERAGIRE!, NON DEVE FARLO!) e ne tantomeno deve essere influenzato da come la specifica infrastruttura di rete implementi il livello 1 fisico, questo perche' la realta' che vede l'entita'/processo livello rete sono i servizi che gli offre l'interfaccia con il livello inferiore e cioe' il livello 2 LLC.
Questo e' un concetto vero in generale difatti si puo' cambiare protocollo implementativo di un certo livello purche' il nuovo supporti gli stessi servizi anche in modo (protocollare) differente e non succede nulla.
Quindi che si sia letto da qualche parte che il DHCP, che e' un'applicativo che chiede servizi ad UDP livello 4, dipenda in qualche modo da come viene implementato il livello fisico (1) mi pare una cosa fuori da una logica razionale e basata sui metodi di modellazione e semplificazione dei processi di comunicazione adottati.
Quindi se la logica che guida anche la realizzazione degli apparati Cisco nella implementazione dei processi di comunicazione risponde alle regole che ho succintamente descritto sopra non riesco a capire come mai giri questa informazine, se cio' fosse vero mi dovrei porre altre domande.
p.s. per i piu' "sgamati" dietro una seriale ci puo' essere un accesso di tipo broadcast multicast cosi come per la ethernet, difatti una interfaccia ethernet viene vista anh'essa come una seriale (SPI) da chi scrive software per microcontrollori che utiizzino tale interfaccia.

Si prega Accedi a partecipare alla conversazione.

Messaggi DHCP - Offer & Ack - Unicast & Broadcast 9 Anni 1 Settimana fa #5

  • mrizzi
  • Offline
  • Elite Member
  • Elite Member
  • Messaggi: 101
  • Ringraziamenti ricevuti 9
Ciao Roberto, mi accontentavo di una risposta un pò più semplificata; senza fare polemica, "giro questa informazione" perchè in realtà volevo capire cosa si intendeva, perchè il testo dice letteralmente che al momento con la 12.2 sono supportate solo le interfacce ethernet e si sta provvedendo per supportare TUTTE le interfacce.......

Si prega Accedi a partecipare alla conversazione.

Messaggi DHCP - Offer & Ack - Unicast & Broadcast 9 Anni 1 Settimana fa #6

  • roberto ulisse
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
Mi spiace che si pensi che co' che scrivo sia polemica, purtroppo le cose non sono semplici come tutti vorremmo ma e' forse proprio una eccessiva approssimazione che ci rende la vita difficile e ci fa equivocare, dimmi piuttosto dove hai letto quanto hai citato, intendo l'url?
Ripeto non e' polemica le cose devono chiudersi sempre in modo razionale.
Per spiegarti meglio la situazione ti potrei fare riflettere che esistono sistemi trasmissivi che alle due terminazioni presentano interfaccie differenti, per esempio da un lato seriale rs232 o altro e dall'altro ethernet, e che esistono in commercio adattatori per quasi tutte le coppie di protocolli del livello fisico esistenti.
Quindi se Cisco non fa funzionare il dhcp sulle interfaccie seriali dipende solo da una scelta Cisco, ed io volevo capire dagli istruttori quali sono i motivi che hanno impedito a Cisco di implementare il protocollo dhcp sulla seriale, io stavo solo stimolando una risposta molto interessante e non volevo fare nessuna polemica.
Ringraziano per il messaggio: mrizzi

Si prega Accedi a partecipare alla conversazione.

Messaggi DHCP - Offer & Ack - Unicast & Broadcast 9 Anni 1 Settimana fa #7

  • mrizzi
  • Offline
  • Elite Member
  • Elite Member
  • Messaggi: 101
  • Ringraziamenti ricevuti 9
Probabilmente ho interpretato male le tue parole :)
Comunque il link è questo qui:
www.cisco.com/c/en/us/td/docs/ios/12_2/i...fdhcp.html#wp1009276

In allegato trovi lo screenshot della parte relativa alle interfacce.

Grazie
Allegati:

Si prega Accedi a partecipare alla conversazione.

Messaggi DHCP - Offer & Ack - Unicast & Broadcast 9 Anni 1 Settimana fa #8

  • jpalombi
  • Avatar di jpalombi Autore della discussione
  • Offline
  • Administrator
  • Administrator
  • Messaggi: 2641
  • Ringraziamenti ricevuti 1106
Ciao Roberto e Massimiliano,
la discussione è veramente interessante. Rispondo alle vostre domande ma necessariamente devo chiarire che la feature di cui parla Massimiliano è quella "lato client", ovvero la possibilità di assegnare un indirizzo IP ad una interfaccia seriale, e non alla capacità del router di operare come server DHCP.

DHCP Client Overview

The Cisco IOS DHCP client now enables you to obtain an IP address from a DHCP Server dynamically using the DHCP protocol as specified in RFC 2131. In Cisco IOS Release 12.2, only Ethernet interfaces are supported; work is in progress to support all interface types.

Ad ogni modo, quello che scrive Roberto è assolutamente corretto, soprattutto lo stupore nel constatare una "violazione" del modello TCP/IP (non credo volesse fare polemica, credo che "giri" fosse inteso come congiuntivo ;) ).

Il fatto per cui sulle seriali non si utilizzasse il DHCP è presto detto: si preferivano altri metodi di assegnazione IP (e dunque altri protocolli): ad esempio tramite IPCP (Internet Protocol Control Protocol) su PPP, o su macchine Cisco tramite SLARP (Serial Line Address Resolution Protocol) su cHDLC (PPP e cHDLC sono due protocolli Layer 2).

Credo che questo possa risolvere i dubbi di entrambi - e magari generarne altri mille, ovvio ;)
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
Ringraziano per il messaggio: roberto ulisse, mrizzi

Si prega Accedi a partecipare alla conversazione.

Messaggi DHCP - Offer & Ack - Unicast & Broadcast 9 Anni 1 Settimana fa #9

  • roberto ulisse
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
Ho letto la risposta di Jody e se avro' tempo leggero il link che gentilmente ha inserito mrizzi, volevo solo fare alcune ulteriori importanti riflessioni su quanto ho letto scritto e cioe' : "work is in progress to support all interface types" quindi si parla di work in progress, e su cosa stanno lavorando? c'e' tutto scritto ed anzi vorrei aggiungere che se fosse necessaria una qualche modifica all'applicativo client dhcp sviluppato per l'interfaccia ethernet per adattarlo alla porta seriale ( :P ) vorrei veramente leggerne i dettagli.
La realta' in enerale e' normalmente complicata, spesso fraintendimenti la rendono anche incoerente, questo topic e' stato utilissimo spero a chi piu' giovane di me si era "accasciato" ed aveva accettato una cosa che non e' assoluta ma e' una scelta, magari di carattere comerciale e quindi secondo me ci sono cose che sfuggono al controllo dei tecnici e sono cosi come dice tra noi del popolo che il padrone attacca il ciuccio dove vuole lui perche' il ciuccio e' di sua proprieta', e cisco ha SCELTO di non dare questa feature chissa per quali motivi, forse un giorno lo capiro' ed allora capiro perche' cisco ha deciso cosi.
Comunque attaccare un ciuccio e' cosa ben differente dall'affidare le comunicazioni della gente, le comunicazioni sono di nessuno e chi le tratta con i propri apparati deve essere trasparente, anche per questo i livelli devono interagire scondo gli schemi definiti dai serizi e dalle api, e' una questione di trasparenza e giustizia e quindi non solo di ordine e razionalita'.
Ringraziano per il messaggio: mrizzi

Si prega Accedi a partecipare alla conversazione.

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

  • roberto ulisse
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
Purtroppo devo rimettere in discussione un po tutto,
ho fatto qualche approfondimento e dal sito dell'universita' di bologna risulta che il flag settato dal client nella fase di discovery determini solo se l'indirizzo mac di destinazione (e quindi di livelo due e non l'indirizzo ip) nelle risposte debba essere di unicast o broadcast, mentre l'indirizzo dilivello tre sia sempre di broadcast.
Quindi se flag=1 allora il server dhcp nel comporre il messaggio di risposta deve utilizzare come indirizzo destinazione livello 2 broadcast, diversamente (se flag=0) utilizzera il mac unicast rilevato dalla trama di discovery ricevuta, mentre a quanto pare l'indirizzo destinazione livello rete Iip address) nei messaggi verso il client resta sempre di broadcast.
A supporto di questi fatti ci sono le seguenti considerazioni che sono legate all'efficientamento dei processi sulle altre interfaccie di rete che giustificano il motivo per il quale il protocollo viene implementato in questo modo.
pemetto che: tra le tante funzioni del sottolivello MAC una e' quella di analizzare tutte le trame, anche quelle che sono semplici disturbi elettrici chiamati "ghost signal" l'analisi tra le tante cose prevede anche la verifica della rivelazine di eventuali trame corrotte da errori ed anche e l'analisi del mac address di destinazine contenuto nella trama, questi controlli servono a non passare al sottolivello llc lavoro inutile e dannoso, pensate a cosa serve passare una trama affetta da errori o indirizzata ad un'altra stazione?.
nella analisi in particolare focalizziamo gli aspetti connessi al campo destinazione di livello 2 (MAC ADDREDD DESTINAZIONE), esso puo' coincidere con l'indirizzo della NIC (interfaccia di rete) oppure essere un multicast o un broadcast, in questi casi il sottolivello mac passera al sottolivelo llc la trama per la successiva elaborazione.
E' evidente che che nei casi diversi i.e. se la trama e' unicast e contiene indirizzo di destinazione differente da quello della scheda dalla quale lo si e' ricevuto ed inoltre non e' ne brodcast e ne multicast non esiste nessun motivo per il quale il sottolivello mac debba passare la trama al sottolivello llc per la successiva elaborazione, questo per non sovraccaricare di lavoro inutile l'hardware di rete, quindi mettere un indirizzo unicast in un frame ottimizza il lavoro alle altre interfaccie di rete presenti nel dominio di collisione.
Considerate che quando furono scritte le regole del dhcp era importantissimo (lo e' anche oggi comunque) non sovraccaricare le schede di rete perche' le tecnologie non consentivano alle stesse un processamento delle informazioni veloce, quindi quanto piu' i protocolli erano efficienti scartando inutili messaggi per i livelli superiori tanto meglio funzionava il tutto.
Bene e' proprio da queste necessita' che nasce questa procedura del bit di broadcast nel messaggio di dhcp discovery, questo bit se settato a zero dal client indica al server di utilizzare nelle risposte l'indirizzo di unicast che il server ha rilevato nel precedente messaggio di discovery.
A questo punto qualcuno potrebbe dire: " ma allora perche non fare sempre utilizzare a livello 2 l'indirizzo di broadcast visto e considerato che in questo modo si ottimizza il processo e le altre stazioni rilevando un indirizzo mac non loro scarteranno il pacchetto subito gia' a livello mac?
Certo che sarebbe auspicabile, ma evidentemente normalmente non tutti i client sono capaci di ricevere e processare i pacchetti di unicast se ancora il sottolivello rete non e' stato configurato (ed e' il caso nostro) e quindi spetta al client stabilire se ricorrere all'unicast o meno a seconda se e' capace o meno a processare l'unicast livello 2.
Vi riporto qui il tracciamento dei messaggi dhcp, notate che il client ha settato ad il flag a zero, significa che nelle risposte richiede unicast e che in effetti le risposte sono uniast ma solo a livello due mentre a livello tre l'indirizzo destinazione nei pacchetti verso il client e' sempre di broadcast.
Qui le screenshot della spiegazione:



Allegato 2.png non trovato



dice testualmente:
DHCP DISCOVER
Usato dal client in modalita' broadcast per localizzare i server disponibili.
In quest tipo di messaggi gli unici campi significativi oltre ai htype, hlen e xi sono:
flags-> se posto ad 1 i bootreply (le risposte intende) saranno broadcast anche a livello ethernet.
anche significa che a livello tre sono sempre di broadcast
Allegati:

Si prega Accedi a partecipare alla conversazione.

Ultima Modifica: da roberto ulisse. Motivo: inserimento seconda immagine

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

  • jpalombi
  • Avatar di jpalombi Autore della discussione
  • Offline
  • Administrator
  • Administrator
  • Messaggi: 2641
  • Ringraziamenti ricevuti 1106
Non credo (senza offesa) ci sia da ridiscutere alcunchè ;)
La risorsa che hai trovato dice ESATTAMENTE ciò che ho già esposto. Quando all'inizio scrivi:

ho fatto qualche approfondimento e dal sito dell'universita' di bologna risulta che il flag settato dal client nella fase di discovery determini solo se l'indirizzo mac di destinazione (e quindi di livelo due e non l'indirizzo ip) nelle risposte debba essere di unicast o broadcast, mentre l'indirizzo dilivello tre sia sempre di broadcast.

Credo tu abbia male interpretato. Proseguendo, concordo fino a:

quindi quanto piu' i protocolli erano efficienti scartando inutili messaggi per i livelli superiori tanto meglio funzionava il tutto.

La domanda successiva poi non la capisco proprio, sebbene le conclusioni tornino nuovamente su ciò che avevo già espressamente enunciato nel blog e nel presente topic. Credo semplicemente tu abbia fatto confusione in qualche misura/passaggio
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 3 giorni fa #12

  • roberto ulisse
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
La risorsa che ho trovato non dice assolutamete cio' che hai scritto nel blog, difatti tu non fai nessun riferimento ad indirizzi di livello due mentre qui si.
Le parole sono rilevate sul sito dell'universita' di bologna sono queste:
DHCP DISCOVER
Usato dal client in modalita' broadcast per localizzare i server disponibili.
In quest tipo di messaggi gli unici campi significativi oltre ai htype, hlen e xi sono:
flags-> se posto ad 1 i bootreply (le risposte intende) saranno broadcast anche a livello ethernet.

quindi dice che flags-> se posto ad 1 i bootreply saranno broadcast anche a livello ethernet. io che leggo l'italiano capisco che dire broadcast anche a livello ethernet significa esprimere il fatto che a livello ip sono sempre broadcast e lo diventano anche a livello due se esplicitamente richiesto nel flag.
Nel blog non noto nessunn riferimento ad indirizzi di livello 2,
se no dimmi tu cosa vuole dire?

Si prega Accedi a partecipare alla conversazione.

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

  • jpalombi
  • Avatar di jpalombi Autore della discussione
  • Offline
  • Administrator
  • Administrator
  • Messaggi: 2641
  • Ringraziamenti ricevuti 1106
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
Allegati:

Si prega Accedi a partecipare alla conversazione.

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

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

io che leggo l'italiano capisco che dire broadcast anche a livello ethernet significa esprimere il fatto che a livello ip sono sempre broadcast e lo diventano anche a livello due se esplicitamente richiesto nel flag.


E' qui che ti sbagli, la risposta non è SEMPRE broadcast a livello 3. Il frame/pacchetto è

o Unicast L2 / Unicast L3
o Broadcast L2 / Broadcast L3
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 3 giorni fa #15

  • roberto ulisse
  • Offline
  • Platinum Member
  • Platinum Member
  • Messaggi: 289
  • Ringraziamenti ricevuti 35
comunque sia io dalle mie prove ho rilevato che la implementazione reale del protocollo dhcp non risponde alle regole che noi abbiamo descritto, in particolare i campi destinazione degli indirizzi sia a livello due che a livello tre risultano essere sempre di broacast anche quando viene esplicitamente richiesto dal client attraverso il settaggio del flag bit al valore di zero (unicast) .
Questa e' la realta', sulla rfc mi pare che le cose siano non definite al 100%, lascia troppi margini interpretativi perche non india in maniera esplicita quando parla di indirizzi a quale livello si riferisca, poi non ho veramente capito dove dice: "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 pare cosi chiaro.
e quindi se e' come ho scritto (e tu ti sei detto daccordo) che 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?

Si prega Accedi a partecipare alla conversazione.

  • Pagina:
  • 1
  • 2
Moderatori: jpalombi