IP design

hilo

 

A cegnel szuksegem lenne egy kicsit erosebb IP design tudasra...tud valaki ajanlani konyvet/kurzust ami segithet nekem ebben 'gyurni'? (VLAN, VRF, VPRN, DSCP. BGP, subnet...es hasonlo temak)

Az a problemam , hogy kb vegtelen mennyisegu anyag van a temaban a neten  es indulasnak kb lehetetlen megtippelni melyik lehet a nyero..

 

koszi!

Hozzászólások

Konkrét gyártói tudás kell vagy elméleti alapozó?

Biztos, hogy IP designra gondoltál? Mert az általad írt fogalmak már network design (L2, L3), ami sokkal szélesebb.

Továbbá IPv4? IPv6?

Az ilyen topikokban az általában sosem szokott kiderülni. A kérdező a nagy eszmecserék közben általában csendben felszívódik, és többé a saját fóruma felé se néz.

Mondjuk 15 éves reggel már illene tudni hogyan kellene itt segítséget kérni.

Alapvetoen high level design jellegu hozzaertesre van szuksegem amit enterprise mobil halozatban kellene hasznalnom.

Pl : a mostani egyik nyunnyoges targya, hogy egy privat halozatban szukseg van pubic IP cimet kezelni; az egyik belso subneten levo alkalmazasnak elerhetove tenni. Erre mondtak, hogy hasznaljunk NAT-ot, de peldaul nem vilagos, hogy ahhoz hogyan fog mukodni a routing es hogyan kulonul el a tobbi , privat forgalomtol.

Hat, ilyen es ehhez hasonlok.

High level szintű tanácsok, kérdések:
- Először is rajzold fel a hálózatot nagyvonalakban (subnetek, routerek, NAT, gatewayek stb.).
- Jelöld be a tervezett útvonalat nyilakkal a vonal végén - Ki akar elérni kit?
- Ebből látszódni fog, hogy vajon van-e olyan eszköz az útvonalon, ami képes elvégezni a feladatot - Esetleg ezt a forgalmat alternatív útvonalon kell átvinni? Vagy új eszközt kell beszerezni?
- Milyen teljesítmény igénye van ennek a kapcsolatnak (sávszélesség, latency, packet/sec stb.)? Ezt vajon tudják-e a meglévő útvonalon lévő eszközök?
- KISS (keep it simple and smart)
- Elkezdesz alternatívák után kutatni, ha szükséges. Van, amit L2, mást L3 vagy L7 szinten érdemes megoldani. Nem szabad leragadni egyik vagy másik mellett (szög és kalapács).
- Kellhet-e ezt a rendszert később továbbfejleszteni? Vajon lehetséges lesz-e?
- A NAT-olást érdemes elkerülni, amíg csak lehetséges. Sok fejfájástól tudod magad megkímélni.

koszi!

Sajnos mar meglevo termek, design-ba kell(ene) belefaragni, aminek megvannak a maga lehetosegei , korlatai...

 

A NAT-tal kapcsolatos tanacs bovebben erdekelne, van konkret dolog ami vissza tud utni ha ilyet kezdunk hasznalni?

 

(KISS - en ugy ismertem, hogy Keep It Stupid Simple :)

Ugye NAT-nál valamilyen IP-(k)ről forgatsz valamilyen IP-(k)re - DNAT, SNAT most mindegy. Nem feltétlenül publikus <-> privát, lehet ez privát -> privát is (architektúra függvényében).
Pár hátránya, kockázata a NAT-nak:
- Megnehezíti a hibakeresést. Legalább +1 lépés, mert a logokban a NAT eszköz IP címe fog látszódni.
- Lassabb, mint a routolás - IP fejléceket kell módosítani.
- Teljesítmény igényesebb, mint a routolás a NAT eszközön.
- Könnyen elfogyhatnak a szabad portok a NAT-oló eszközben (betelik a NAT tábla, 65536-mínusz pár port ~=65500 port áll rendelkezésre/IP cím). Ezért szoktak játszani például a TCP keepalive-val (ne tartsa fenn túl sokáig a kapcsolatokat, ha nincs forgalom).

Ez így kb. igaz egy 1-N NAT-olásnál, de lehet 1-1 NAT-olni is public és privát cím között, csak azért, hogy a belső hálóban, privát címen ülő szerverre ne kelljen minden áron beroute-olni egy public IP-t, mert nem is mindig lehetséges, vagy esetleg több public IP-t is el kell használni miatta.

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Szerintem egyszerre ne akarj ennyi lovat megülni, mert eltipornak mint a szart.

Kezdésnek érdemes a fizikai igények egyeztetése után a meglévő tartomány(ok)ból elkülöníteni a szükséges host+50%-nyi méretű subnetet, szépen egymás után VLSM-el. Aztán ha ezek békében megvannak egymás mellett, akkor jöhet a következő.
De ne akarj egyszerre mindent, ha ennyi a hiányosság.
sak szépen sorban, mert éles környezetben nem vicces ha 2 perc alatt csinálsz magadnak 2 heti munkát.
Legyen mindig backup és legrosszabb esetre konzolos hozzáférés.
Amikor élő rendszeren konfigurálsz, akkor pedig természetesen legtávolabbról jössz visszafelé.

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

No igen... a vlan, subnet téma is kérdés, akkor a BGP és a többi... Szóval messziről kell indulni, nem vitás... És ahogy már felmerült, én is azt kérdezem a poszt-tolótól, hogy mi a feladat? Mert általánosan a subnet/vlan kérdéstől a BGP-is és hasonlókig eljutni nem lesz rövid tanulási folyamat, és fene tudja, hogy mi az, amire tényleg szükség van...

Az sem mindegy, hogy hogyan és mennyire meg milyen eszközökkel kell a hálózatot szeparálni, és sajnos sokszor az sem, hogy milyen eszközökkel kell azt megvalósítani, mert nagyon sok esetben nem csak a parancsok (az még hagyján...) de az elnevezések illetve a lehetőségek sem azonosak az egyes gyártóknál...

Mert van olyan hogy IP Designer? Az olyan mint a belsőépítész? :D

"Sose a gép a hülye."

Ne sorban nézd meg, hanem amik érdekelnek.
Kicsi Angol tudás kell hozzá :)

https://www.youtube.com/watch?v=uS8OtrP7bVw&list=PLLcWJondP8tK9V4T-cQ8OJy_Vwuefn--1
Szerkesztve: 2024. 07. 16., k – 12:46

Szerintem ma már a leghatékonyabb tanulás a konkrét, "éles" feladatmegoldás Google segítségével. Többszáz oldalnyi száraz elmélet olvasgatásával nem szerzel annyi alkalmazható tudást, amennyi időt elcseszel rá. Persze, gyakorlat közben a releváns elméletre kell időt szánni!

Az biztos, hogy a felsorolt funkciók/modulok nagyon nem ugyanaz a szakmai szint. Amíg pl. VLAN, subnet témában bármi kérdés, bizonytalanság felmerül (nem megy kisujjból, készség szinten), addig ne akarj VRF-ezni, meg BGP-zni (...meg a többit)!

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"