Best practice per la pianificazione dello spazio degli indirizzi IPv4


16

Una recente domanda di Craig Constantine riguardava IPv6, ma molte persone non sono ancora all'avanguardia con IPv6 e sono ancora responsabili di implementazioni IPv4 nuove o migliorate.

Vorrei convalidare la mia pianificazione dello spazio degli indirizzi IPv4 della mia azienda rispetto a qualsiasi documento pubblico o guida fornita direttamente qui. L'indirizzamento ha alcune esigenze uniche tra DC e Campus che verrebbero idealmente prese in considerazione.

Sto specificamente cercando di vedere quali sono le migliori pratiche per la pianificazione di assegnazioni di spazi IP privati (RFC1918) per regioni, città, campus, edifici, piani, uplink, collegamenti WAN, loopback, ecc. Wired vs wireless. Reti interne vs. reti ospiti. * So che questo da solo può essere un po 'una domanda a risposta aperta, quindi sto cercando riferimenti o esempi specifici a piani comprovati e ben ponderati in modo simile alle risposte IPv6. I blocchi CIDR suggeriti sarebbero utili quando lo spazio viene allocato.

L'aggregazione per il routing, ovviamente, è desiderata, così come la possibilità di avere ACL semplificati. C'è un compromesso negli ACL con il desiderio di aggregare tutte le sottoreti dei dipendenti, ad esempio, sia cablate che wireless rispetto all'aggregazione di tutti gli utenti wireless, indipendentemente dal fatto che siano dipendenti, appaltatori o ospiti.

Risposte:


10

Essendo in una società semi-piccola, abbiamo rotto la nostra rete privata in modo un po 'generoso:

/ 24 per Vlan / 16 per posizione

I Vlan sono sparsi, saltando 10/24 per. Il numero Vlan corrisponde al terzo ottetto. Le posizioni sono sequenziali, a partire da 10 / 16s in.

vale a dire

  • 10.10.1.0/24 - Posizione A, Management Vlan 1

  • 10.10.11.0/24 - Posizione A, Wireless Vlan 11

  • 10.11.11.0/24 - Posizione B, Wireless Vlan 11

  • 10.11.81.0/24 - Posizione B, SAN Vlan 81

  • 10.11.101.0/24 - Posizione B, Wired Office Vlan 101

Esempi Vlan:

  • 1 - gestione

  • 2 - gestione per wireless

  • 11 - accesso wireless

  • 21 - ospiti

  • 31 - dispositivi mobili

  • 41 - attrezzatura di fabbrica

  • 51 - SAN

  • 61 - VoIP

  • 71 - Accesso cablato

E così via.

I vantaggi che abbiamo visto con questo sono:

  • Facile riferimento a un'intera posizione tramite / 16. Lo usiamo abbastanza spesso per ACL VPN.

  • Facile raggruppare i tipi di dispositivi per il filtro web.

  • Qualsiasi Vlan nei prossimi 10/24 appartiene allo stesso tipo della radice precedente.

    • Quindi, ad esempio, le apparecchiature di fabbrica ... Vlan 31, per alcuni fornitori che hanno accesso remoto 24/7, abbiamo dato loro il proprio Vlan, 32 o 33 o 34, fino a 40. Il loro accesso VPN li limita alle apparecchiature che supporto senza ottenere granularità su IP / ACE. Se il team di produzione deve inserire più apparecchiature, non è necessario aggiornare gli ACL VPN. Ciò include anche l'accesso ACL / ACE tra i Vlan.

    • Un altro esempio: SAN Vlans, ne utilizziamo almeno due per ridondanza. Quindi sono sempre 81 e 82.

    • Ultimo esempio: la gestione wireless è suddivisa in un proprio Vlan, 2. Facciamo questo perché abbiamo abbastanza AP per avere bisogno di un controller WLAN ma nessun budget per i controller. Questo Vlan utilizza le opzioni tftp e dhcp per configurare e avviare automaticamente gli AP da un repository di configurazione centrale e non vogliamo altre apparecchiature che possono avviarsi automaticamente per estrarre le configurazioni wireless.

Questa configurazione ci offre un modo semplice per guardare un IP e conoscere la posizione e il tipo di apparecchiatura a cui appartiene. Ciò significa per noi meno ACL / ACE nei file di configurazione, specialmente per utenti VPN limitati. Abbiamo anche spazio per l'espansione nel caso in cui rimaniamo senza IP in un Vlan o perché dobbiamo separare ulteriormente il traffico. E poiché siamo una piccola azienda, non abbiamo ancora suddiviso la numerazione delle posizioni a tre cifre. Un sacco di spazio per la crescita.


Fornendo un / 16 a ciascuna posizione e attenendosi a quel piano, è anche possibile riepilogare i collegamenti WAN tra le posizioni che sono utili dal punto di vista della tabella di routing. Supponendo di avere il design del core / distribuzione corretto!
Knotseh,

9

Dato che IPv4 esiste da così tanto tempo, ci sono milioni di modi diversi in cui le persone scelgono di allocare il proprio spazio IPv4.

Per noi (un ISP) utilizziamo la dimensione della sottorete più piccola possibile su collegamenti di transito puri (/ 30 di solito) e quindi in termini di clienti dipende da quali sono le loro esigenze, a causa della brevità che tutti hanno su IPv4 significa che invece di utilizzare un regola generale devi prendere ogni cliente come propria entità e raccogliere i suoi requisiti di conseguenza.

Questo è ovvio se ti riferivi allo spazio IPv4 PUBBLICO, in termini di roba RFC1918 interna, quindi pianifica le tue allocazioni in modo da creare spazio per l'espansione (ad esempio un edificio ha solo 50 persone al suo interno, non dare loro un / 26 solo perché è la sottorete di dimensioni successive ma forse dare loro un / 24 per consentire l'espansione.

Un'altra buona pratica è quella di allocare in aggregato, cioè se si dispone di un edificio con 10 piani allocare un / 20 (o più grande) all'edificio e quindi allocare le sottoreti per ogni piano / dipartimento fuori da quel / 20, in questo modo è possibile pubblicizzare solo il / 20 sul resto della rete anziché su tutte le singole subnet per ciascun piano.


Modificato Q. per indicare che sono principalmente interessato alla pianificazione dello spazio IP privato. Supponevo che l'aggregazione fosse un obiettivo compreso da tutti, ma lo aggiungerò per chiarire che è desiderato.
generalnetworkerror,
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.