Zdravim, mam taku otazku. Ti co mate na sieti L3 switche ako mate riesenu mgmt vlan?
Mate ju rozspanovanu po celej sieti jednu vlan, alebo riesite nejake mensie celky pripadne rozbijate mgmt do viacerych vlan napr jednu per switch a medzi nimi nejak routujete?
Ako mate riesene to sa aby customer nedostal do mgmt vlan? nejake vrf-y alebo len aclka?
Dik L.
❗️Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
Management VLAN
- zdenek.svarc
- Administrator
- Příspěvky: 1635
- Registrován: 20 years ago
- antispam: Ano
Přijde na to, v jaké části topologie sítě, zda-li přístupové nebo provozní. Na přístupových switchích, kde se nevyskytuje žádný nativní L3 provoz, pouze PPPoE provoz, je u nás management VLANa na uplinku tagovaná a na ostatních portech se nevyskytuje vůbec. Přístupový switch a agregační switch pak sdílí jednu management VLANu.
0 x
no je jasne ze koncove ( access ) switche budu mat mgmt vlan ukoncenu na uplinku to nie je problem. Ale co napr l3 switche niekde v core ?
Ak mas nejake kolecko a mas tam l3 switche, tak ako tu? stale mas jednu vlan aj napriek tomu kruhu? Pritom datovy traffic na takom kruhu asi routujes. Mimochodom pri pouziti stp ktore si nie je vedome vlan by potom mohol byt problem aj so sekanim liniek co nie je moc vhodne...
Ak mas nejake kolecko a mas tam l3 switche, tak ako tu? stale mas jednu vlan aj napriek tomu kruhu? Pritom datovy traffic na takom kruhu asi routujes. Mimochodom pri pouziti stp ktore si nie je vedome vlan by potom mohol byt problem aj so sekanim liniek co nie je moc vhodne...
0 x
- zdenek.svarc
- Administrator
- Příspěvky: 1635
- Registrován: 20 years ago
- antispam: Ano
Máme striktně hvězdicovou topologii, na zakruhované agregace jsou tu lepší kabrňáci, kteří se určitě ozvou 

0 x
potom mas spof .. co tiez nie je moc dobre .. resp vies urobit hviezdicu s dobrymi boxami v stacku 
Tak rozmyslam, MGMT traffic komplet oddlelit do samostatneho VRFu a mat samostatny ospf proces na mgmt. Este teda rozhodnut ake velke bcast domeny vytvarat.
No som zvedavy co odporucia miestni odbornici
Dik L .

Tak rozmyslam, MGMT traffic komplet oddlelit do samostatneho VRFu a mat samostatny ospf proces na mgmt. Este teda rozhodnut ake velke bcast domeny vytvarat.
No som zvedavy co odporucia miestni odbornici

Dik L .
0 x
- zdenek.svarc
- Administrator
- Příspěvky: 1635
- Registrován: 20 years ago
- antispam: Ano
No jasně, ale ten single point vychází z geografických a prostorových předpokladů. Core už je doublované.
0 x
To se nedá takto jednoduše rozhodnout co je lepší. Záleží na topologii celé sítě. Někdy vyjde lépe jedna vlan pro velkou oblast (a pomocí nějakého spanning tree skončí na jednom z routerů), někdy je zase lepší je "vázat" k nejbližšímu routeru a na L2 ji nekruhovat. Můžeš mít v cestě nějaké rádio (klidně i lepší) a spanning tree může blbnout.
U RSTP je zase standardně dost riziko mít těch switchů za sebou moc ... u MSTP je to pro změnu vcelku fuk. Takže pokud je všude striktně MSTP, vyjde lépe mít jednu VLAN pro všechny switche.
Pokud máš jen jednu VLAN všude, končí ti na jednom routeru, takže nastává problém SPoF (pokud ten router není zdvojený např. pomocí VRRP).
Někdy máš v síti zakruhováno jen po L3, takže tu vlanu stejně musíš rozdělit ...
Pokud ta vlana bude velká (tedy velká bcast doména), hrozí, že pokud se ti tam už nějaký "divný" provoz dostane, může ohrozit všechny switche. A to je hned ... chyba při konfiguraci, porucha switche, výpadek elektřiny ve špatný okamžik (resp. náběh), hacker/cracker.
Jinak se to vymýšlí pokud máš síť jen optiku, jen čistý ethernet. A jinak zase pokud je tam spousta rádií a routerů ...
L3 switche ovšem tento problém nemají, tam se to dělá tak, že si vypropaguješ management IP (loopback) do zbytku sítě jiným protokolem, tedy nejspíš OSPF. Nemá cenu si to komplikovat po L2.
Někdy je zase problém praktický - máš router na baráku a v něm několik lidí po ethernetu. Má smysl si pro jeden switch vyplácat extra segment? Někdy to vyjde tak, že ano (už tam třeba je VLAN pro management rádií). Ale většinou se na to kašle a management je v lidském segmentu ...
V každém případě koncové stroje by neměly mít přístup do této VLANy. Ať už po L2, tak po L3. I když se zvlášť to druhé blbě dělá - pak někam přijdeš, potřebuješ poladit - a nemůžeš. A související rada: nemít management na VLAN 1 (ale to také občas switche neumí). A pokud to jde, tak využívat ACL switchů, přeci jenom jsou hardwarové.
Prostě co člověk, to názor.
U RSTP je zase standardně dost riziko mít těch switchů za sebou moc ... u MSTP je to pro změnu vcelku fuk. Takže pokud je všude striktně MSTP, vyjde lépe mít jednu VLAN pro všechny switche.
Pokud máš jen jednu VLAN všude, končí ti na jednom routeru, takže nastává problém SPoF (pokud ten router není zdvojený např. pomocí VRRP).
Někdy máš v síti zakruhováno jen po L3, takže tu vlanu stejně musíš rozdělit ...
Pokud ta vlana bude velká (tedy velká bcast doména), hrozí, že pokud se ti tam už nějaký "divný" provoz dostane, může ohrozit všechny switche. A to je hned ... chyba při konfiguraci, porucha switche, výpadek elektřiny ve špatný okamžik (resp. náběh), hacker/cracker.
Jinak se to vymýšlí pokud máš síť jen optiku, jen čistý ethernet. A jinak zase pokud je tam spousta rádií a routerů ...
L3 switche ovšem tento problém nemají, tam se to dělá tak, že si vypropaguješ management IP (loopback) do zbytku sítě jiným protokolem, tedy nejspíš OSPF. Nemá cenu si to komplikovat po L2.
Někdy je zase problém praktický - máš router na baráku a v něm několik lidí po ethernetu. Má smysl si pro jeden switch vyplácat extra segment? Někdy to vyjde tak, že ano (už tam třeba je VLAN pro management rádií). Ale většinou se na to kašle a management je v lidském segmentu ...

V každém případě koncové stroje by neměly mít přístup do této VLANy. Ať už po L2, tak po L3. I když se zvlášť to druhé blbě dělá - pak někam přijdeš, potřebuješ poladit - a nemůžeš. A související rada: nemít management na VLAN 1 (ale to také občas switche neumí). A pokud to jde, tak využívat ACL switchů, přeci jenom jsou hardwarové.
Prostě co člověk, to názor.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
no ten loopback ma nenapadol avsak potom ako sa riesi pristup len zo spravneho subnetu? ( mozno by stacilo nastavit access-class )
Ak mam nejake radia po ceste ktore nechcem mat len tak volne pohodene? ( tj ich mgmt vlan niekam umiestnit tak co potom?
Inak dik za prispevok, tento bol dobry
Ak mam nejake radia po ceste ktore nechcem mat len tak volne pohodene? ( tj ich mgmt vlan niekam umiestnit tak co potom?
Inak dik za prispevok, tento bol dobry
0 x
Ano, na to jsou ACL. Aneb firewall jiným slovem ...
Rádia jsou zase jiný problém
Pokud nejsou v cestě kruhu, tak to buď neřeším (a nechám normálně inband management), nebo na obou je stejná vlan končící na nejbližším a stejném routeru (či dál - opět co ti vyhovuje).
Ale pokud to je součást kruhu, tak tohle řešení má nevýhodu, že pokud se rozpadne rádiolink, na jednu z toho se nedostaneš. Nebo stačí, když se otočí provoz (z nějakého jiného důvodu) a pak je to opět problematické. Takže v takovém případě má má každý konec rádia jinou VLAN a ta končí na nějakém routeru, aby tomu prostě změny v L3 topologii nevadili.
A pokud jsou ty rádia s outband managementem (ceragony např., obecně asi vše s IDU), tak tam to je takto rozdělené vlastně vždy. U nás až na ty ceragony, protože nám to tenkrát disk blbě vysvětlil a tedy i nakonfiguroval
On tam jde totiž i ten outband protáhnout servisním kanálem rádiem na druhou stranu ... ale dělat se to nemusí.
Je ovšem bezpečnější si to od běžného provozu oddělit vždy, stejně jako ty switche. Je to ale úplně stejné přemýšlení - mám použít segment /30 jsou spojovačku routerů a další dva /30 pro management? Nebo to risknout a celé to mít v jedné /29?
lukas-svk píše:no ten loopback ma nenapadol avsak potom ako sa riesi pristup len zo spravneho subnetu? ( mozno by stacilo nastavit access-class )
Ak mam nejake radia po ceste ktore nechcem mat len tak volne pohodene? ( tj ich mgmt vlan niekam umiestnit tak co potom?
Rádia jsou zase jiný problém

Ale pokud to je součást kruhu, tak tohle řešení má nevýhodu, že pokud se rozpadne rádiolink, na jednu z toho se nedostaneš. Nebo stačí, když se otočí provoz (z nějakého jiného důvodu) a pak je to opět problematické. Takže v takovém případě má má každý konec rádia jinou VLAN a ta končí na nějakém routeru, aby tomu prostě změny v L3 topologii nevadili.
A pokud jsou ty rádia s outband managementem (ceragony např., obecně asi vše s IDU), tak tam to je takto rozdělené vlastně vždy. U nás až na ty ceragony, protože nám to tenkrát disk blbě vysvětlil a tedy i nakonfiguroval

Je ovšem bezpečnější si to od běžného provozu oddělit vždy, stejně jako ty switche. Je to ale úplně stejné přemýšlení - mám použít segment /30 jsou spojovačku routerů a další dva /30 pro management? Nebo to risknout a celé to mít v jedné /29?
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
Určite rozdeliť na viacero VLAN,nie kvoli kruhovaniu , to sa dá na L3 poriešiť a na L2 kruhy porobené nemáme
. Ale kvoli veľkosti bcast domény. Nemusí ísť ani o hackera, stačí ak nejaké zariadenie zblbne a začne posielať bcast do siete a kopec zariadení z toho dokáže zblbnúť. Osobne mám jednu vlan pre rádiá (Ceragony, Alcomy ,...) jednu pre L3 switche , jedna pre L2 agregačné switche a čo acces switch tak to VLAN končiaca na najbližšom L3 switchi , alebo routri a tam je nadefinované pravidlo čo do nej môže a všetko osttné drop.

0 x
noo .. ale to co pisal ludvik ak mam ptp radiovy spoj a jednu stranu na jeden l3 switch do samostatnej mgmt vlany a druhu stranu na druhy l3 switch tiez samostatna vlan ma jednu nevyhodu.
Ak mi spadne jeden z tych 2 l3 switchov tak sa do mgmt radia na druhej strane nedostanem vobec nijak. Na niektorych radiach sa viem na druhu stranu dostat cez cli, v pripade ze by boli oba konce v jednej vlan sa viem dostat na protistranu a zistit aspon ci je dole port ( aj ked tato samotna informacia je malo prinosna )
Kazdopadne inak by som nemal ani tuto a potom by som mohol spekulovat co sa deje ( elektrika? vadny switch ? nekorektna konfiguracia ? ). Je fajn nejak problem ohranicit aby sa to lahsie nasledne odservisovalo..
Ak mi spadne jeden z tych 2 l3 switchov tak sa do mgmt radia na druhej strane nedostanem vobec nijak. Na niektorych radiach sa viem na druhu stranu dostat cez cli, v pripade ze by boli oba konce v jednej vlan sa viem dostat na protistranu a zistit aspon ci je dole port ( aj ked tato samotna informacia je malo prinosna )
Kazdopadne inak by som nemal ani tuto a potom by som mohol spekulovat co sa deje ( elektrika? vadny switch ? nekorektna konfiguracia ? ). Je fajn nejak problem ohranicit aby sa to lahsie nasledne odservisovalo..
0 x
Tento problém může nastat při libovolném výběru konfigurace těch VLAN ... Když to zakončíš na jedné straně, tak ti spadne zrovna tenhle L3
A nedostaneš se ani na jedno rádio. Když ti to končí na dvou stranách, tak je ta pravděpodobnost poloviční, alespoň na jedno se dostaneš a můžeš se podívat v jakém je stavu (dle typu - alespoň po rádiové stránce). Samozřejmě (a to jsem se minule snažil vysvětlit), že to počítá s nějakým stylem zakruhování, že ty konce VLAN jsou dostupné z více tras, bez toho je to v podstatě asi zbytečná komplikace.
Ono se ti nemusí porouchat ten L3, ale třeba i to rádio. Ať už po hw stránce třeba na modemu, nebo ti ho někdo zaruší (třeba ti tam postaví novou střechu paneláku).
Při troše snahy se na ty rádia dostaneš vždy, i když se ti rozpadne routing (tedy v tom rádiu je neplatná defaulta). Ale je to někdy děsná práce - konfigurovat si NATky na routerech, nebo SSH tunelování, a tak podobně.
Vždy najdeš na síti nějaké místo, jehož pád ti prostě vadí. Nelze všechno zdvojit tak, abys byl úplně imunní proti SPoF. Resp by to asi i šlo, ale náklady tě od toho odradí.

Ono se ti nemusí porouchat ten L3, ale třeba i to rádio. Ať už po hw stránce třeba na modemu, nebo ti ho někdo zaruší (třeba ti tam postaví novou střechu paneláku).
Při troše snahy se na ty rádia dostaneš vždy, i když se ti rozpadne routing (tedy v tom rádiu je neplatná defaulta). Ale je to někdy děsná práce - konfigurovat si NATky na routerech, nebo SSH tunelování, a tak podobně.
lukas-svk píše:noo .. ale to co pisal ludvik ak mam ptp radiovy spoj a jednu stranu na jeden l3 switch do samostatnej mgmt vlany a druhu stranu na druhy l3 switch tiez samostatna vlan ma jednu nevyhodu.
Ak mi spadne jeden z tych 2 l3 switchov tak sa do mgmt radia na druhej strane nedostanem vobec nijak. Na niektorych radiach sa viem na druhu stranu dostat cez cli, v pripade ze by boli oba konce v jednej vlan sa viem dostat na protistranu a zistit aspon ci je dole port ( aj ked tato samotna informacia je malo prinosna )
Kazdopadne inak by som nemal ani tuto a potom by som mohol spekulovat co sa deje ( elektrika? vadny switch ? nekorektna konfiguracia ? ). Je fajn nejak problem ohranicit aby sa to lahsie nasledne odservisovalo..
Vždy najdeš na síti nějaké místo, jehož pád ti prostě vadí. Nelze všechno zdvojit tak, abys byl úplně imunní proti SPoF. Resp by to asi i šlo, ale náklady tě od toho odradí.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
Proto jsem také psal: co člověk, to názor. Ještě bych to mohl rozšířit: co síť, to řešení. Někdy dokonce co větev, to jiné řešení.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.