Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: Bobik 09. 07. 2015, 15:17:10
-
Ahoj,
mám problém, z důvodu chybného plánování musím použít (pro mě) nestandardní masku pro cca 400 IP.
Jedná se o jedinou a plochou síť bez členění (o členění nelze diskutovat - omlouvám se a děkuji).
Stávající subnet 10.57.175.0/C nelze přeadresovat a je zcela plný, vyčerpaný.
Řešením by ASI bylo použít masku: 255.255.254.0
Síť by tedy byla 10.57.174.0/255.255.254.0
IP pro počítače: 10.57.174.1 - 10.57.175.254
Broadcast: 10.57.175.255
Je to alespoň přiměřeně korektní?
Problém mám s tím, že jsem takovou masku nikdy v běžné počítačové síti nepoužil, nerad bych, aby to zlobilo.
Nevím, jestli to nadělá nějakou paseku a jestli jsem to spočítal dobře, nejsem kovaný síťař.
Budu rád, pokud mi ohledně masky poradíte.
Díky, Bob.
-
Maska je naprosto standardní.
Zdá se to být v pořádku, nevidím gateway.
-
10.57.174.0/23 - naprosto normální (byť poněkud neobvyklá) síť. Pokud tam není nějaké prehistorické zařízení tak to fungovat musí.
-
Na té masce není nic divného, hranici mezi adresou sítě a adresou zařízení si můžete stanovit kde chcete. Nešikovné na původním rozsahu je to, že pokud jste měl výchozí bránu na 1. adrese (tj. 10.57.175.1), bude teď najednou uprostřed adresního prostoru.
Když si zadáte do Google „IP calc“, najde vám spoustu kalkulátorů, kde zadáte IP adresu a masku a ono vám to vypíše rozsah adres apod. Případně další výpočty. Tím si to snadno můžete zkontrolovat.
Každopádně pokud teď máte 400 zařízení, není důvod v rozsahu privátních adres šetřit a dávat tam jen rozsah pro cca 500 adres. Zvětšete si ten rozsah třeba na /20 (255.255.240.0) a nové IP adresy, které budete přidělovat, si začněte seskupovat podle typu. Sice budete mít pořád jednu síť, ale rovnou podle IP adresy poznáte, co je to zařízení zač, a postupně si připravíte možnost snadno tu síť rozdělit na několik nezávislých sítí.
-
....
Nejaky duvod proc nepouzit /16 ??? Je tam pak dost prostoru pro nejaky interni administrativni cleneni a zaroven zbejva dost prostoru pro pripadny pridani dalsiho routovanyho subnetu. Zaroven clovek nepotrebuje premejslet, jaka cast IPcka jeste patri subnetu.
Jinak jak bylo receno, uz hezkych par patku je zcela standardni zcela libovolnej prefix.
-
/16 no jasne nebo rovnou /8 a pak az prijdes nekde s VPN a budou kolidovat site tak neudelas nic ... resp. je to pak peknej problem. Takze /23 nebo /20 v klidu, ale delat obri networky je prasarna ve finale, pokud k tomu neni nejaky velmi dobry duvod. Mensi segmenty jsou modularnejsi a da se s tim lip pracovat.
-
/16 no jasne nebo rovnou /8 a pak az prijdes nekde s VPN a budou kolidovat site tak neudelas nic ... resp. je to pak peknej problem. Takze /23 nebo /20 v klidu, ale delat obri networky je prasarna ve finale, pokud k tomu neni nejaky velmi dobry duvod. Mensi segmenty jsou modularnejsi a da se s tim lip pracovat.
A kdyz budu mi /30 a vpn bude kolidovat tak stim udelam co? Uplne stejny howno ze? Privatni IPcka jsou proto privatni, ze se snima nesetri. Je naopak mnohem horsi delat maly subnety, a pak jak idiot porad resit, ze neni misto. Pro interni administraci se pak prave proto pouziva vyhradne /8 nebo /16. Protoze neni treba porad pocitat, co je jeste subnet a co uz ne. Specielne, kdyz polovina kramu v ty siti bude mit fixne nastaveny IPcko, a druha bude mit appky ktery maj ty IPcka v konfiguraci.
Zcela bezne se pak cast vyhrazuje klienskym PC, dalsi trebas ntb, dalsi serverum, dalsi ... proste proto, aby v pripade reseni nejakyho problemu admin mel prehled, co s cim komunikuje a nemusel zkoumat nejakej seznam, co ma zrovna kterou z tech adres. A to zcela bezny cleneni je prave po /24.
-
"A kdyz budu mi /30 a vpn bude kolidovat tak stim udelam co?"
Preadresujete sve dve zarizeni jinam, trabe o jednu /30 niz ci vys. Furt jste ve "sve siti" a na zacatku adres furt pisete treba 10.11.12 jak jste zvykly. Pokud kolidujete s 10.0.0.0/8 tak uz musite uhybat do 192.168 nebo se vejit do 172.16-172.30, kazdopadne je to velky diskomfort a pokud z nejakeho duvodu opakovane datlite IP adresy do klavesnice, zahravate si se svym dusevnim zdravim...
-
10.57.174.0/23 - naprosto normální (byť poněkud neobvyklá) síť. Pokud tam není nějaké prehistorické zařízení tak to fungovat musí.
Pokial zariadenia doteraz zvladli /24, tak zvladnu aj /23.
-
Sit s maskou 23 proc ne, ale je to prasarna. Takto velka broadcastova domena je psycho. Nechtel bych videt vasi sit nebo spise chtel, protoze takovou prasarnu to se musi videt a zazit. Nez delat takto sit, to se radeji na to vys.rte a jdete delat neco jineho - rozvazka rohliku taky dobry ne.
-
Stávající subnet 10.57.175.0/C nelze přeadresovat a je zcela plný, vyčerpaný.
Změnil bych to na 172.16.0.0/B, tedy 172.16.0.0/16. To je dost prostoru pro 64K adres. Pokud bych potřeboval další podsítě, tak 172.17.0.0/16 .. 172.31.0.0/16. Dost prostoru pro hromadu typů rozšiřování, členění sítě, VPN apod. a stále jsme u standardního řešení.
-
Nejaky duvod proc nepouzit /16 ??? Je tam pak dost prostoru pro nejaky interni administrativni cleneni a zaroven zbejva dost prostoru pro pripadny pridani dalsiho routovanyho subnetu. Zaroven clovek nepotrebuje premejslet, jaka cast IPcka jeste patri subnetu.
Jinak jak bylo receno, uz hezkych par patku je zcela standardni zcela libovolnej prefix.
No a to mám ještě štěstí, protože rozsahy před 174 a za 176 mají jiné laby.
Původní Ajťák nepochopil, že by mohl továrny číslovat jinak, než na třetí pozici, prosil jsem o 10.16.x.x, ale to bylo zamítnuto, že všechny lokality budou pěkně postupně a na Čechy (už kdysi) vyšla ta 175ka...ještě že se ta jedna lokalita scípla...
Přeadresování by vyšlo tak na 600 tisíc korun základní nástřel, takže to hodlám pytlíkovat tak, že některé zařízení si budou i nadále myslet, že jsou v síti 10.57.175.0/C a pouze DHCP rozsah pro počítáky dám do 10.57.174.1-10.57.174.254, počítáky stejně komunikují s technikou přes servery.
Všechno, co jede přes ARP/MAC to je buřt a počítáky stejně nekomunikují s ničím přímo.
Ostatní zařízení časem změním, jak se budou zvát dodavatelé.
-
Já to na kalkulátoru samozřejmě testoval, ale protože bych to nazval čuňárnou, raději jsem se chtěl zeptat.
Chtěl jsem nějaký pěkný rozsah (10.16.x.x) a utřel jsem, že by to vyšlo moc draze (musí se zavolat dodavatel od každé kraviny, která se tu provozuje, většina jich jezdí z kdejaké zadekky, takže musí přiletět nebo v lepším případě přijet...moc drahý), takže jsem si mohl vybrat mezi dalším rozsahem 10.57.175.0 a 10.57.235.0 nebo mezi blbou maskou.
A navíc, dvě sítě = administrativní opruz, složitý failover a asi by to ani nešlo uroutovat nějakým mormálním routerem, gigabytové switche to sotva stíhají.
-
Pozor ...
ze síťařského hlediska si zaděláváte na problémy.
Můžete mít třebas tisíce počítačů v jedné síti (10.0.0.0/8) ale budete mít jednu velikou broadcast doménu. Jeden každý počítač čas od času potřebuje oslovit všechny počítače. Například aby zjistil MAC adresu nějakého jiného počítače. Broadcasty nejsou dále šířeny mimo síť směrovačem. Takže si představte, že čas od času, třebas každé dvě minuty, některý počítač pošle rámec, který bude poslán všem. Pokud máte těch počítačů pár, tak prostě takových broadcastů bude dostávat každý počítač několik za minutu. Budete-li mít těch počítačů několik tisíc, tak těhle broacastů bude dostávat pár set za sekundu. Pozor, přepínač (switch) vytváří pouze kolizní doménu, neplést s broadcast doménou. Ještě píšete, že switche jedou na hranici svého výkonu. Přidáním dalšího provozu, který je v podstatě tak trochu nechtěný jim rozhodně nepomůžete. Na tak velký počet počítačů v jedné broadcast doméně budete mít asi i větší počet přepínačů, porty mezi nimi asi nebudou kapacitně nejsilnější a broadcastem je můžete zahltit. Pokud nastane nějaký zásadnější problém, například ethernet smyčka, tak vám prostě padne najednou obrovské množství počítačů a hledejte ve 400 portech kde se jej podařilo vytvořit.
Píšete, že nemůžete přeadresovat. Jenže rozšířením stávající sítě prostřednictvím masky si taky vlastně nepomůžete. Spíše naopak. Každý počítač (myšleno také jakékoliv zařízení ve Vaší síti) ví, v jakém rozsahu vidí své přímé okoli. Počítač A bude chtít kominikovat mimo tento rozsah, tak paket pošle na směrovač. Ten ale bude mít zcela jiné povědomí o rozsahu sítě a paket přepošle zpátky do té samé sítě (sakra, jak tohle chování popsat v textu). Cílový počítač B dostane paket a udělá "arp request" (hej, vy všichni, řekněte mi, jakou MAC adresu má IP adresa 10.11.12.13) pomocí broadcastu. Protože se právem domnívá, že počítač A je ve stejné broadcast doméně jako on. Jenže počítač A si myslí něco jiného, dostane "arp request" který je pro něj, má IP adresu 10.11.12.13, ale problém je, jak se vypořádá s faktem, že žadatel, počítač B, má IP adresu z rozsahu který není v jeho síti. Nejsem si jistý, jak se který operační systém vlastně zachová. Riskujete nepříjemné překvapení. Komunikace mezi některými počítači vám "záhadně" nebude fungovat.
Jinými slovy, přestaňte šetřit a najměte si síťařskou firmu. Plácat to můžete do prvního průšvihu, který vás bude stát ve finále víc než faktura od síťařů.
Text je psán spíše pro síťařského laika.
-
Asi nejjednodušší řešení je do stejné L2 sítě dát ještě jednu L3 síť 10.57.174.0/24
Znamená to:
- na routeru přibude definice další IP sítě na jednom interface (pomocí ip addr add 10.57.174.1/24 dev eth0)
- nové počítače budou dostávat adresy ze sítě 10.57.174.0/24
- logiku komunikace starých počítačů s novými to nijak nenaruší - budou komunikovat přes router
- komunikace mezi koncovými stanicemi podle popisu moc neprobíhá, takže paket půjde L2 sítí pouze jednou
- počet broadcastů vzroste lineárně - i tak mám pocit, že se vliv broadcastů přeceňuje (ARP potřebujete až po vypadnutí záznamu z ARP cache)
A pak je samozřejmě otázka, proč jsou ty gigabitové switche tak vytížené, zvlášť když se tvrdí, že počítače mezi sebou moc nekomunikují - to je totiž spíš logický nesmysl, protože v udávané situaci by byl bottleneck připojení routeru a zbytek portů by neměl co dělat.
-
A je ještě otázka, proč musejí být počítače v jedné L2 síti, když mezi nimi podle popisu komunikace přes L2 protokoly neprobíhá. Jsou to patrně inteligentní switche, které zvládají VLANy, takže by klidně stačilo vytvořit další VLAN, nové počítače vrazit do ní a routovat to stávajícím routerem.
-
Bobiku, ozvi se mi do zprávy. Zkusím ti poradit, jak to rozdělit efektivně, přitom bez zbytečných komplikovaností a tak, aby ti to celá infrastruktura zvládala.
-
Bobiku, ozvi se mi do zprávy. Zkusím ti poradit, jak to rozdělit efektivně, přitom bez zbytečných komplikovaností a tak, aby ti to celá infrastruktura zvládala.
Klidně to naiš i sem. Některé "pokročilé laiky" jako sem já ;) by to zajímalo :)
-
Nebude potřeba přepsat masku ve všech zařízeních v siti?
Pokud ano tak už by se při tom mohly změnit i IP adresy.
-
Nebude potřeba přepsat masku ve všech zařízeních v siti?
Pokud ta zařízení nepotřebují komunikovat s těmi novými IP adresami, tak ne. A správně by to mělo fungovat, i kdyby to potřebovala - ale to už záleží na tom, zda jednotlivé implementace IP stacku nejsou moc pokažené.
-
Pokud ta zařízení nepotřebují komunikovat s těmi novými IP adresami, tak ne. A správně by to mělo fungovat, i kdyby to potřebovala - ale to už záleží na tom, zda jednotlivé implementace IP stacku nejsou moc pokažené.
Počítáky komunikují jen se servery, komunikace ve směru PC->zařízení tu prakticky neprobíhá, vše je jen PC->Server<-Zařízení a tam, kde taková komunikace teoreticky přichází v úvahu, masku změnit zvládnu (Telefonní ústředna atd).
Opravte mě, že to říkám tak zevrubně, ale maska slouží k tomu, aby počítač poznal, že daný počítač leží v místní síti.
Pokud počítač vidí, že stroj podle masky leží v místní síti, L3 to předá L2, L2 vrstva pošle ARP požadavek WHO HAS IP a pokud mu přijde odpověď (tj. má pár IP:MAC), může zahájit komunikaci. V opačném případě to počíták pošle na výchozí bránu.
Takže by koexistence dvou překrývajících se sítí, TEORETICKY, mohla normálně fungovat.
Tj. stávající síť: 10.57.175.0/C s novou 10.57.174.0/255.255.254.0 s DHCP rozsahem 10.57.174.10-10.57.174.254, bránou 10.57.175.1
Rozsah 10.57.174.(255) bude použitý pro DHCP, kde jsou výhradně klienti Windows 7 nebo Linux.
Pak se na to mrknu Wiresharkem, co mi po síti vlastně lítá a v průběhu roku síť změním na úplně všech zařízeních z původní 10.57.175.0/C na novou 10.57.174.0/255.255.254.0, hlavní je, že se to nebude muset dělat naráz, ale až jak budou dodavatelé jezdit, jako že se všechna zařízení stejně pravidelně servisují.
Skoro se bojím toho, aby to po změně masky z C na 255.255.254.0 nezačalo zlobit víc, než když na některých zařízeních nechám masku na C. Opravdu nevím, jak se ty zařízení s maskou 255.255.254.0 vyrovnají....no....dělá mi to větší vrásky než koexistence dvou překrývajících se sítí.
Rozhodně všem děkuji za připomínky.
-
Opravdu nevím, jak se ty zařízení s maskou 255.255.254.0 vyrovnají....no....
Úplně normálně jako s každou jinou... Není nad to vědecky dumat nad krávovinama.
-
Takže by koexistence dvou překrývajících se sítí, TEORETICKY, mohla normálně fungovat.
Tj. stávající síť: 10.57.175.0/C s novou 10.57.174.0/255.255.254.0 s DHCP rozsahem 10.57.174.10-10.57.174.254, bránou 10.57.175.1
Rozsah 10.57.174.(255) bude použitý pro DHCP, kde jsou výhradně klienti Windows 7 nebo Linux.
Pak se na to mrknu Wiresharkem, co mi po síti vlastně lítá a v průběhu roku síť změním na úplně všech zařízeních z původní 10.57.175.0/C na novou 10.57.174.0/255.255.254.0, hlavní je, že se to nebude muset dělat naráz, ale až jak budou dodavatelé jezdit, jako že se všechna zařízení stejně pravidelně servisují.
Skoro se bojím toho, aby to po změně masky z C na 255.255.254.0 nezačalo zlobit víc, než když na některých zařízeních nechám masku na C. Opravdu nevím, jak se ty zařízení s maskou 255.255.254.0 vyrovnají....no....dělá mi to větší vrásky než koexistence dvou překrývajících se sítí.
Především bych doporučoval uvádět masku vždy stejně, nejlépe /prefix, tj. počet bitů masky; zápis ve stylu /C jsem snad až dosud nikdy neviděl, podobně "Rozsah 10.57.174.(255)" ;-).
Vámi navrhované uspořádání by teoreticky fungovat mělo, nicméně zelený je strom života. Potenciální nebezpečí vidím hlavně v těch zařízeních, o kterých (resp. o jejich TCP/IP stacku) asi moc údajů nebude. Pokud by nastal problém, bylo by podle mých zkušeností dost obtížné rychle jej identifikovat, on by se mrška jistě projevoval snad až okultními příznaky. Používáte nějaký nástroj na centrální správu? Broadcastová doména o 400 uzlech není legrace. Jinak u nás provozujeme na jedné L1/L2 síti více L3 sítí, ovšem IP adresní rozsahy se nám nepřekrývají.
-
Opravte mě, že to říkám tak zevrubně, ale maska slouží k tomu, aby počítač poznal, že daný počítač leží v místní síti.
Pokud počítač vidí, že stroj podle masky leží v místní síti, L3 to předá L2, L2 vrstva pošle ARP požadavek WHO HAS IP a pokud mu přijde odpověď (tj. má pár IP:MAC), může zahájit komunikaci. V opačném případě to počíták pošle na výchozí bránu.
Ano, je to tak. Maska určuje, které IP adresy jsou dosažitelné přímo, zbytek se posílá přes výchozí bránu.
Takže by koexistence dvou překrývajících se sítí, TEORETICKY, mohla normálně fungovat.
Tj. stávající síť: 10.57.175.0/C s novou 10.57.174.0/255.255.254.0 s DHCP rozsahem 10.57.174.10-10.57.174.254, bránou 10.57.175.1
Pokud brána dostane paket, který patří do stejné sítě, jako odesílatel, měla by jej správně přeposlat a odesílateli poslat ICMP paket s přesměrováním, na základě kterého by si odesílatel měl upravit routovací tabulku. I pokud to odesílatel neudělá, mělo by to fungovat – akorát bude router pořád pakety přeposílat. Teoreticky by tedy vše mělo fungovat, v praxi ale mohou nastat problémy se špatnou konfigurací nebo implementací.
Skoro se bojím toho, aby to po změně masky z C na 255.255.254.0 nezačalo zlobit víc, než když na některých zařízeních nechám masku na C. Opravdu nevím, jak se ty zařízení s maskou 255.255.254.0 vyrovnají....
Musela by to být hodně stará zařízení, která by počítala jen s třídami sítí A (/8), B (/16) a C (/24). Takové zařízení by vám s největší pravděpodobností ani jinou masku nedovolilo nastavit, takže byste hned věděl, že je v tom problém. Pokud vám ta maska půjde nastavit, problém bych už nečekal – to už by ten kód musel být záměrně rozbitý.
-
Opravdu nevím, jak se ty zařízení s maskou 255.255.254.0 vyrovnají....no....
Úplně normálně jako s každou jinou... Není nad to vědecky dumat nad krávovinama.
Máš pravdu Laeli.
-
Jestli by skoro nebylo lepší udělat druhou /24 síť a na routeru nastavit druhou gw a sítě proroutovat. Pokud mezi sebou zařízení nemají potřebu komunikovat, router to zatěžovat nebude a tobě to dost usnadní administraci.
Jinak ta maska /23 je rozhodně zcela v pořádku a není na ní nic špatnýho. Pokud by byla možnost všechny zařízení projít a předělat do nové sítě, nebyl by problém. Pokud budeš mít dvě překrývající se sítě, bral bych to jako silně dočasný řešení jen na dobu potřebnou ke změně, styl ono se to časem pomění tak nějak samovolně ti v tom mezičase nadělá dost problémů.