Newsgroup: it.comp.reti.ip-admin
Titolo: Subnetting: cosa faccio adesso?

Ciao ragazzi...
mi trovo in una LAN in classe C privata (
192.168.0.0/24
) la quale è connessa
con altre LAN C-class (
192.168.1.0/24
, 
192.168.2.0/24
, ecc.) in WAN,
mediante router ISDN.
Ora mi trovo in una situazione in cui sto per esaurire gli IP a disposizione
per gli host nella mia LAN. Cosa mi suggerite di fare? Come posso procedere?
Pensavo a mettere nella mia stessa LAN dei PC con reti diverse dalla mia
attuale, ma il tutto penso creerebbe problemi di convivenza, voi che ne
dite?
Accetto suggerimenti!
Grazie...
--
Software Is Like Sex:
It's Better When It's Free...

[...]
Io cambierei linea, centinaia di host su ISDN la vedo dura. :-)
Configuri il router come gateway di un'altra LAN di classe C, e
poi assegni gli indirizzi alle macchine. Nessun problema direi, a 
parte il fatto che i trasferimenti di grossi file tra una rete 
all'altra passeranno per il router. 
Ciao.

 all'altra passeranno per il router.
Allora, quello che interessa a me, a prescindere dalle altre LAN collegare,
è che la *mia* LAN sta esaurendo i propri IP liberi.
Se capisco bene, tu mi dici di configurare il mio gateway (che al momento è
un computer con LINUX) con un IP di un'altra sottorete (es.: 192.168.5.254)
ed in questo modo potrei installare anche dei PC nella rete 
192.168.5.0/24
 e
farli convivere con gli altri in rete 
192.168.0.0/24
?
Dovrei impostare delle route particolari sul mio gateway? Intendo dire: l'IP
del GW per la "nuova" rete sarebbe un alias della mia eth0, la quale
attualmente è l'IP del GW della mia rete 
192.168.0.0/24
. Il tutto
funzionerebbe?
Grazie ancora...

 
Secondo me si.
Io ho una configurazione cosi' con un cisco al posto di linux,
e va bene.
Provaci; metti un ip secondario sull'interfaccia, configuri.
una macchina con l'ip della nuova rete, e vedi se funziona.
Ciao 

 > alias della mia eth0, la quale attualmente č l'IP del GW della mia


 di rete tra le due reti.
Ecco... dopo aver aspettato la conferma della funzionalità di tale sistema,
pensavo proprio di mettere un'altra scheda di rete...
OK, avete fugato i miei dubbi!
Ciao e grazie...

"OxygeN"  ha scritto

Mettere differenti reti logiche all'interno di uno stesso segmento fisico
(perché di questo si tratta), non ti dovrebbe creare alcun problema.
Ti spiego anche un'altra strada però. Potresti cambiare la subnet mask ed
utilizzare per l'ID di rete 23 bit anziché 24.
Mi spiego meglio: la tua rete diventerebbe 192.168.0.0 subnetmask
255.255.254.0, oppure /23. In pratica raddopieresti il numero di indirizzi
ip disponibili perché il tuo range diventerebbe 
192.168.0.1/23
 -
192.168.1.254/23
. Se conti gli indirizzi sono 510.
Perché farlo:
aumenti il numero di host che puoi mettere in una rete logica, utile nel
caso in cui tu non abbia a disposizione gli apparati di rete idonei a
mettere in comunicazione diversi segmenti fisici e reti logiche.
Perché non farlo:
raddoppi il traffico broadcast all'interno del tuo segmento.
Quindi, la soluzione migliore è quella di creare reti differenti, di
dimensioni più piccole e messe in comunicazione tra loro.
Se hai a disposizione un router o una macchina che funga da tale, fai così.
In pratica come ti hanno suggerito gli altri... Abbi cura però di utilizzare
due differenti schede di rete e di impostare correttamente i gateway per
uscire su internet e per comunicare con l'altra subnet.
Ciao, Antonio

 raddoppi il traffico broadcast all'interno del tuo segmento.
me posso sapere da dove pescate 'ste sorate?!??
è qualche tempo che, su vari ng, tanti parlano di broadcast dipendenti dalla
subnet ip su cui si trovano le macchine, ma non uno, dicasi uno solo che
riesce a spiegare PERCHE' o DA COSA dipendano 'sti cavolo di fantomatici
broadcast tcp/ip!
i broadcast li genera windows, con i suoi protocolli proprietari (vedi
netbios) e NON IL TCP/IP!
cambiare la subnet, NON INFLUISCE SUI BROADCAST TCP/IP! (che non c sono,
almeno normalmente...)
un router con il solo tcp, non manda broadcast a caso sulla rete. per cosa
poi?
anche linux configurato come volete (ma senza samba) non manda broadcast!
se avete documentazione che smentisce quanto sopra, ben venga, ma non
continuate a ripetere dei sentito dire, peraltro piuttosto inverosimili!
(scusate se il tono sembra un pò incaxxato, ma vorrei qualche riferimento e
non ne ho ancora avuti... :-))
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.427 / Virus Database: 240 - Release Date: 06/12/2002

 netbios) e NON IL TCP/IP!
E allora perché il tcp/ip richiede un indirizzo specifico per il 
broadcast di ogni subnet? ;))))
Comunque AFAIK hai ragione: è il netbios che usa il broadcast per la 
risoluzione dei nomi.
Solo che è VERO che se la subnet è ampia, il numero di broadcast (dovuti 
acchittepare.... ;P) aumenta!
Si potrebbe utilizzare WINS per abbassarne il numero.
-- 
		Luca Amicone
		(da casa)

 Si potrebbe utilizzare WINS per abbassarne il numero.
vero a metà...
se ho una subnet di macchine linux, che me ne faccio di wins?!
:-)



Ok, mi spiego meglio.
1)In condizioni ideali tcp/ip non genera traffico broadcast.
2) Ho usato impropriamente il termine broadcast, per indicare anche tutto il
traffico che viene generalmente creato dai vari servizi all'interno di una
rete.
Do per molto verosimile, che in una rete con tanto di dominio e più di 255
host esista anche un server DHCP. Già metto in conto un broadcast di ciascun
pc per ogni DHCPDISCOVER seguito da altro broadcast generato dal server
dhcp. Seguono a questi dhcpoffer, dhcprequest, dhcpack. Tutto questo
considerando un solo server ed escludendo i dhcpnack. A questo poi va
aggiunto il rinnovo dei lease, il traffico di replica dei vari sever,
l'eventuale replica tra i router ecc. Aggiungo pure il NetBIOS su TCP/IP
descritto nelle RFC 1001 e 1002 (almeno un riferimento te lo do). Tieni
presente l'esistenza di nodi broadcast, ibridi e misti. Non bisogna poi
trascurare la malignità dei sistemi Microsoft, che in una rete generica
media, sono sicuramente la maggior parte.
Ti do ragione per il termine broadcast, che ho utilizzato anche per
"lagnusia" ("pigrizia", per i non siculi), però penso di aver ragione
anch'io sulla crescita esponenziale di tutto il traffico di rete rispetto al
numero di host.
Per quel che riguarda me, puoi usare il tono che ritieni più opportuno o
naturale, purché la discussione, il litigio o quant'altro (in positivo o in
negativo), porti a qualcosa di costruttivo. O sbaglio ;-) ?
Ciao, Antonio

 :-)
Vero a metà: che te ne fai del NetBios (e quindi dei broadcast, e quindi 
di WINS per evitarli..)? ;)))))))


 1)In condizioni ideali tcp/ip non genera traffico broadcast.
???
Per comunicare all'interno di una rete locale, gli host
hanno necessita' di risalire dall'indirizzo IP all'indirizzo
fisico (MAC) dell'host di destinazione.
Per fare cio' mandano una richiesta ARP in broadcast. 
Quindi, il broadcast e' _indispensabile_!
Ciao

 [...]
Ti dico come la so io (sotto ci sono un paio di link) :-)
All'interno di una LAN, gli host per mandare i pacchetti agli altri
host hanno necessita' di conoscere il loro indirizzo fisico (MAC). 
Pero' a livello applicativo gli host comunicano utilizzando gli
indirizzi IP, e non quelli fisici. Quindi occorre un metodo per 
tradurre gli indirizzi IP in indirizzi fisici.
Questo metodo si chiama ARP (Address Resolution Protocol); esso
consiste nel fatto che l'host che vuole mandare il pacchetto 
fa' una richiesta in broadcast, chiedendo a tutti gli host della
rete "a quale indirizzo fisico corrisponde questo indirizzo IP?"
Tutti gli host leggono il pacchetto, ma solo quello interessato
risponde (questa volta in unicast) specificando il proprio MAC.
Ovviamente, una volta determinato l'accoppiamento IP/MAC, l'host
che ha fatto la richiesta se lo mettera' nella propria cache ARP
(quella che da linux puoi leggere col comando arp -a) onde non 
oberare la rete di richieste inutili.
Quello che voglio dire e' che le richieste ARP in broadcast sono 
fondamentali per il funzionamento di una LAN, e che tutti gli host
della rete fanno richieste ARP, a meno di non configurare su tutti 
gli host delle voci ARP statiche relative a tutti gli altri host, 
rendendo non necessaria la richiesta in broadcast. 
Inoltre le voci ARP apprese dinamicamente non hanno una vita eterna, 
e prima o poi le richieste verranno ripetute.
La parola magica e' arp.
Calcola che non ho molto approfondito la ricerca.
http://www.networkingitalia.it/TCP/arp.asp
http://www.pte.enel.it/it/icfaq/tecnici.htm#udp
 (u
Ciao
:-)

 Calcola che non ho molto approfondito la ricerca.
D'accordissimo con te, però devi rileggere il mio ultimo post nell'economia
della "discussione" con PaoloOpg.
Altrimenti ci sarebbe troppo da dire...
:-) Ciao, Antonio


hai ragione.
se un host vuole sapere a quale mac corrisponde un ip, manda un broadcast a
livello fisico e ottiene una sola risposta (che mette in cache), sia che sul
segmento abbia 3 host, sia ne abbia 500.
ovvio che se ne ho 500, sono più probabili molti arp req contemporanei (e
quindi più traffico).
se io subnetto per avere meno host nella subnet ip, ma non suddivido la rete
fisicamente (vlan, apparati diversi con router/bridge), non c'è verso, il
broadcast di livello fisico, viene comunque visto da tutti gli host, che
abbiano subnet uguali o differenti, dato che a livello fisico, il tcp, non
c'entra proprio niente!
quindi, non è risolutivo il subnettare puro e semplice: può essere una
soluzione se e solo se accompagnato da una suddivisione fisica della rete.
forse non sono stato molto chiaro, ma anche il post iniziale era abba
ambiguo: pareva che il subnetting fosse la panacea di tutti i mali!
:-)


 :-)
Magari lo fosse, ti immagini  quanti soldi si risparmierebbero..!? :-)
Ciao, Antonio