/ 31 Maschere bit da punto a punto


13

Quando è appropriato utilizzare una rete / 31 in produzione e il loro utilizzo è considerato una buona pratica? Su un collegamento point-to-point, le trasmissioni non dovrebbero essere richieste, quindi esiste un caso convincente per usare / 31 over / 30 come sembra / 30s sono ancora ampiamente diffusi e prevalenti. Questo è stato definito da RFC 3021 .

Esistono casi d'uso per l'utilizzo di un / 31 diverso da quello per conservare lo spazio degli indirizzi? L'introduzione di / 31s porta una nuova serie di preoccupazioni che non si trovano in / 30s?

Gli / 31 sono generalmente visti solo nello spazio pubblico, in particolare per gli ISP, o sono comunemente usati anche nello spazio privato sia per gli ISP che per le imprese?


2
Votare per chiudere poiché questa non sembra essere una vera domanda, ma più creare un forum di discussione (qualcosa che vogliamo evitare). Li ho visti usati un po 'in produzione - indipendentemente dal fatto che funzionino come previsto dipende dall'implementazione del fornitore.
John Jensen,

@JohnJensen fammi riformulare questo poi ....
knotseh

Penso che la domanda qui sia: "quando viene utilizzata questa configurazione?"
Bulki,

2
@ Mike-Pennington Non sono d'accordo con te su questo (rispettosamente ofc). Riesco a capire il problema con gli indirizzi / 31 a livello teorico. Dal momento che non si dispone di una parte dell'indirizzo che è solo un indirizzo e non una parte di trasmissione o subnet. Tuttavia, questo può essere utilizzato quando si utilizza il corretto instradamento verso questa rete, ecc. O punto-punto. Le domande "perché è possibile" o "quando viene utilizzato" sono buone domande.
Bulki,

1
Solo per notare qui Mikrotik non supporta / 31 o / 127. E non hanno intenzione di ripararlo.
sdaffa23fdsf,

Risposte:


11

Abbiamo usato / 31 nel nostro core (Brocade, Juniper, Cisco) per oltre tre anni senza problemi di sorta.

Questa è una rete ISP di produzione, quindi è opportuno utilizzarli in un ambiente di produzione fintanto che il kit lo supporta e l'hai testato


Non risponde davvero alla domanda, "l'abbiamo usato"
jwbensley,

È opportuno utilizzarlo ogni volta che lo desideri, poiché non causa alcun problema in una rete di produzione
mellowd

Quindi inseriscilo nella tua risposta :)
jwbensley,

6

Come è stato detto altrove, l'utilizzo delle maschere / 31 bit può funzionare ed è un buon modo per conservare lo spazio degli indirizzi disponibile.

Cos'è forse più importazione in quali circostanze non puoi usare / 31s? Quali protocolli o applicazioni potrebbero comportarsi in modo scorretto o rompersi a causa della mancanza di un indirizzo di trasmissione ?

BootP e DHCP sono in cima all'elenco secondo l'articolo precedente, ma non ci occupiamo di quelli sui collegamenti punto-punto del router. ARP utilizza un indirizzo MAC di trasmissione - non IP - quindi non dovrebbero esserci problemi ... OSPF ed EIGRP usano entrambi indirizzi multicast, RIP v1 sembra però che potrebbe essere un problema.

Cos'altro dipende dall'indirizzo di trasmissione o di rete?


IMHO questa è una domanda, non una risposta.
un CVn

1
Concordato. La domanda iniziale non era ben formulata e la domanda era effettivamente chiusa al voto. È stato riformulato e riaperto da quando questo post è stato originariamente realizzato. (Spero che abbia contribuito al miglioramento della domanda.)
Peter,

5

Li sto usando internamente nei laboratori che eseguono EIGRP per un po 'e finora non ho riscontrato alcun problema.

A mio modo di vedere se un / 24 è allocato per un intervallo P2P.

  1. / 30 bitmask = 64 collegamenti P2P
  2. / 31 bitmask = 128 collegamenti P2P

/ 23 allocazione

  1. / 30 bitmask = 128 collegamenti P2P
  2. / 31 bitmask = 256 collegamenti P2P

Va bene, non annoierò le persone con matematica di sottorete e poteri di due. Ma poiché siamo nella modalità di esaurimento IPv4, ci consente di utilizzare meglio le assegnazioni di subnet fornite.

Inoltre, in un P2P non vedo alcun motivo per cui abbiamo bisogno di un indirizzo di trasmissione. Ci sono solo due host in questa rete. Pertanto, tutti i pacchetti destinati alla trasmissione verranno ascoltati dall'altro host.

A proposito, i router Cisco supportano questa funzione da IOS 12.2 (2) T


quindi fai una domanda e 8 minuti dopo rispondi tu stesso ... sembra un po 'strano adesso no? Ad ogni modo, la sola implementazione di un / 31 secondo me è usata sui firewall dove sono necessari solo 2 indirizzi WAN (e NAT farà il resto).
Bulki,

@Bulki concorda sul fatto strano - pubblicato questo prima di modificare la domanda mentre stavo cercando più una struttura di forum / dibattito che non avevo realizzato che stavamo evitando.
Knotseh,

1
Non penso che questa domanda sia adatta dato che è così soggettiva. È comune usare / 31, almeno agli ISP. Non c'è motivo di non farlo perché i grandi venditori lo supportano da anni.
Daniel Dib,

È abbastanza aperto, ma formato come una domanda dovrebbe essere utile. Forse la domanda dovrebbe essere "c'è qualche motivo per non eseguire sempre / 31 e / 127 su collegamenti punto-punto", quindi potremmo ottenere dati interessanti sui distributori dove questo non funziona o altre motivazioni per non eseguirli (posso pensare di uno per / 127)
ytti

7
@bulki Non c'è niente di sbagliato nel pubblicare una domanda e poi rispondere alla propria domanda. Questo è letteralmente incoraggiato. meta.networkengineering.stackexchange.com/questions/4/…
Craig Constantine

2

Data la prudenza e l'importanza della conservazione degli indirizzi, l'approccio generale all'utilizzo di un / 31 dovrebbe essere "se funziona, usalo" .

Ovviamente, potresti fare un ulteriore passo avanti e iniziare a utilizzare lo spazio privato per i tuoi collegamenti punto-punto, ma questo ovviamente può essere problematico se eseguirai traceroute da Internet piuttosto che dalla tua stessa rete, sebbene anche questo può essere mitigato in qualche modo configurando il router per emettere errori ICMP con un indirizzo IP di origine specifico.

In breve, fai tutto il possibile per sprecare il minor numero possibile di indirizzi (entro i limiti delle migliori pratiche e fattibilità, non iniziare a lanciare concentratori NAT ovunque)

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.