Le sottoreti sono sempre 1 contigue? [duplicare]


25

Capisco la premessa di base dietro le maschere di sottorete, come ad esempio 255.255.255.0. Ma tutti gli esempi di sottorete che ho visto sono stati (da sinistra a destra) contigui 1 (bit HI). Ad esempio, 255.255.0.0( /16) si traduce nei seguenti ottetti:

11111111 . 11111111 . 00000000 . 00000000

Io ritengo che questi bit devono essere contigue, perché il punto di subnetting è host ID derive e gamme di ID di dispositivo disponibili. Ma mi chiedo, potresti mai avere una subnet mask di, diciamo 255.17.255.0, o:

11111111 . 00010001 . 11111111 . 00000000
  • Questo sarebbe mai successo? O è impossibile che esistano sottoreti senza 1s contigui? Se è così, perché?
  • Altrimenti, se è possibile farlo, perché (alcuni esempi concreti)?

@MSalters Proprio per sapere che ora il commento automatico è stato modificato per dire "Possibile duplicato di ...", quindi non è più necessario inserire manualmente il commento. ;-)
Chris Jester-Young,

Risposta breve: sì, hai ragione.
Polpo,

Risposte:


18

La sezione 3.1 nella RFC mostra le maschere consentite nell'instradamento interdominio senza classi. I bit devono essere contigui affinché il routing funzioni correttamente.

Inoltre, quando si pensa logicamente, non avrebbe davvero senso avere strane maschere di rete casuali.


28

Sì, il modo più semplice di pensarci è che le maschere di sottorete sono sempre 1s all'inizio. Se un indicatore di dimensione di sottorete non ha 1s all'inizio della rappresentazione binaria, direi che l'indicatore di dimensione di sottorete non è una corretta "maschera di sottorete", che utilizza standard moderni.

RFC 1219 afferma che la precedente RFC 950 consente bit non contigui. In effetti, RFC 950 pagina 15 (sezione 3) ha chiaramente un esempio che "illustra bit di sottorete non contigui". Tuttavia, non c'è modo di convertire tali sottoreti in notazione CIDR. La notazione in stile CIDR è ciò che IPv6 ha usato (at almeno dalla RFC 1884 pagina 7 , prima frase della sezione 2.4), quindi i bit non contigui non sono mai stati ampiamente supportati per le reti IPv6 Il metodo RFC 1219 specifica che "i bit di sottorete (maschera = 1) sono assegnati dal bit più significativo funzionante verso il minimo ". (La RFC 4632 sezione 3.1 , menzionata dalla risposta di Sami, indica uno standard ufficiale che discute della notazione CIDR.)

RFC 1878 pagina 2 mostra la notazione standard "subnet mask" per tutte le sottoreti IPv4 ad eccezione di /0.

Tuttavia, ho intenzione di approfondire un po 'la risposta di Sami, esaminando il "perché" (con un esempio concreto, come ha fatto la domanda) ...

Alcune apparecchiature Cisco di livello professionale supportano qualcosa chiamato "maschera jolly", che inverte i bit. Quindi una sottorete normale potrebbe essere rappresentata da qualcosa chiamato 00000000.00000000.00000000.11111111.

Con le maschere jolly di Cisco, non c'era una regola che tutti gli zeri dovevano andare per primi. Quindi potresti usare 00000000.00000000.00000000.11111110.

Ciò finirebbe per creare un gruppo che contenesse tutti gli indirizzi IP con numero pari.

Questo era in realtà importante da sapere, perché la formazione di Cisco lo copriva, e quindi il processo di esame per le certificazioni professionali di Cisco potrebbe chiedere una cosa del genere.

Tuttavia, penso che sia stato per lo più inutile. Invece di dividere una rete a metà usando indirizzi pari o dispari, puoi semplicemente dividere una rete a metà usando indirizzi a basso numero e indirizzi a numero alto, creando sottoreti normali che sono la metà delle dimensioni.

Le maschere jolly con bit non contigui non erano estremamente utili e potrebbero essere più difficili da utilizzare. Il punto del bit della maschera di sottorete impostato su 1 è dire che il bit aiuta a identificare in quale sottorete si trova un dispositivo. Non c'è motivo convincente per diffondere quei bit nell'indirizzo, invece di raggrupparli in modo corretto all'inizio dell'indirizzo . Il risultato è stato che il supporto di questi tipi di maschere costituiva un'ulteriore complessità senza vantaggi sostanziali.

Immagino che alla fine Cisco fosse d'accordo sul fatto che non ci fosse motivo per maschere di sottorete non tradizionali, perché alla fine hanno abbandonato il supporto per le "maschere jolly". I vecchi firewall Pix supportano "maschere jolly", ma le unità ASA più recenti usano invece "maschere di sottorete" standard .

Non proverei nemmeno a creare una rete con "bit di sottorete" non contigui nella maschera, perché molti software seguiranno le tendenze / gli standard più recenti e rifiuterebbero tale progetto di rete. Anche se stavo usando un software più vecchio, probabilmente vorrei che la mia rete fosse facilmente modificabile per poter usare software più recente senza dover riprogettare la rete. Pertanto, i "bit di sottorete" contigui sono l'unica strada da percorrere.

Se ti viene posta la domanda su un test, mi sento sicuro di dire che tutti gli 1 devono essere all'inizio dell'indirizzo. Questo è ciò che ogni tester sano vorrebbe che la maggior parte degli studenti imparasse in questi giorni.


+1 - L'unica volta che ho visto le maschere jolly utilizzate senza tutti gli 1 alla fine sono le maschere che sono state inserite in modo errato.
Mark Henderson,

2

RFC 950 dice nel capitolo 2.2:

 To support subnets, it is necessary to store one more 32-bit
  quantity, called my_ip_mask.  This is a bit-mask with bits set in
  the fields corresponding to the IP network number, and additional
  bits set corresponding to the subnet number field.

 The code then becomes:

   IF bitwise_and(dg.ip_dest, my_ip_mask)
                               = bitwise_and(my_ip_addr, my_ip_mask)
         THEN
             send_dg_locally(dg, dg.ip_dest)
         ELSE
             send_dg_locally(dg,
                    gateway_to(bitwise_and(dg.ip_dest, my_ip_mask)))

quindi la proposta riguardava una semplice operazione di bit a cui non importavano bit contigui.

Nel 1985, CPU e memoria erano molto più limitate, quindi qualsiasi operazione più complessa semplicemente non si adattava al tempo.

Diventa ancora più esplicito nel capitolo 3:

e che sulla rete è in uso un campo di sottorete a 3 bit (01011000), ovvero la maschera dell'indirizzo è 255.255.255.88.

Tuttavia, tali RFC sembrano essere obsoleti. Su Windows 7 SP1, ad esempio, non è possibile impostare una maschera di sottorete simile:

Maschera di sottorete contigua richiesta su Windows 7

Anche su Windows XP SP2, questo non era più possibile:

Maschera di sottorete Windows XP SP2

Il clone di Windows 98 ReactOS, tuttavia, consente di impostare la "strana" maschera di rete:

Maschera di sottorete ReactOS


1

Sono d'accordo con la risposta di @Sami Kuhmonen:

La sezione 3.1 nella RFC mostra le maschere consentite nell'instradamento interdominio senza classi. I bit devono essere contigui affinché il routing funzioni correttamente. Inoltre, quando si pensa logicamente, non avrebbe davvero senso avere strane maschere di rete casuali.

Tuttavia, anche se non è desiderato o consentito, è comunque possibile definire una subnet mask di 1 non consecutivi. Il motivo alla base di questo:
l'ID di rete e l'ID host vengono calcolati dall'indirizzo IP e dalla maschera di sottorete utilizzando le operazioni binarie AND e XOR. Tutto il resto è irrilevante.

Ho provato che anni fa su Win 2000, funziona. Entrambi i computer avevano una maschera 255.160.0.0. Erano in una LAN senza router, quindi non posso dire del comportamento del router (normalmente puoi impostare la maschera del router solo nella sua interfaccia web, che la rifiuterà).
Inoltre, non è possibile immettere una maschera di sottorete "non valida" nel campo corrispondente delle impostazioni di rete; la GUI si rifiuta di prenderla. Ma puoi imbrogliare modificandolo direttamente nel registro. Successivamente riavviare o disabilitare + abilitare la scheda NIC affinché le modifiche diventino attive.
Lo scopo di tutto questo: uhm, probabilmente nessuno.


Grazie per la condivisione, ma questo non si qualifica come risposta autonoma. Dovrebbe essere un commento sulla risposta di Sami Kuhmonen.
agtoever,

2
Troppo lungo per un commento ... Inoltre non mi aspetto che sia contrassegnato come risposta.
Tobias Knauss,

@agtoever: dopo aver modificato e aggiunto ulteriori dettagli, penso che ora si qualifichi come risposta autonoma, perché ha molte informazioni che non fanno parte di altre risposte.
Tobias Knauss,

"Funziona su una implementazione" non è una buona risposta, però. E non è solo "funziona su un sistema operativo", no, apparentemente hai testato un PC particolare con (soprattutto) una rete. Ciò significa che non hai verificato se il codice di routing della sottorete in Windows 2000 funziona effettivamente, ed è proprio lì che sono necessari gli ID di rete. Potresti instradare tra due 255.160.0.0reti non adiacenti ?
Salterio

@MSalters Funziona su un'implementazione significa ancora che funziona. Non ho preteso di parlare per tutti i possibili sistemi operativi di configurazione. Inoltre, cosa ne pensi di come i pacchetti passano da un PC all'altro? Il computer deve conoscere il percorso. Pertanto, deve calcolare se il computer di destinazione si trova nella stessa sottorete (invia il pacchetto direttamente) o lontano (interroga il gateway configurato per una route). // No, non penso che potrei fare un tale instradamento, perché queste subnet non erano pensate per essere usate. Ho dimostrato un caso se funzionasse, ma senza sottorete diversa. Forse funziona anche questo, chissà ...
Tobias Knauss,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.