VLAN "tunnel"

Hálózatok általános

Sziasztok.

Lehet, hogy teljesen triviálisat kérdezek, de nem szeretnék belekezdeni amig elméletben sem vagyok képben.

Adva van egy 3 switch-ből álló, nagyon egyszerű hálózat:

sw1 -> sw2 -> sw3

Jelenleg nincs VLAN benne, működik is minden. A cél az volna, hogy a jelnelegi kábelezés megtartásával (1-1 kábel uplinkeli össze a switcheket) az sw1-be kapcsolódó gép (virtualizációs host egyik guest-je) kapjon egy VLAN-t, egészen az sw3 után lévő router-ig. (a többi guest-je, ugyanazon a kábelen pedig működjön tovább vlan nélkül ahogy eddig)

Ha tudnék külön kábelt dedikálni, akkor megcsinálnám a switch-eket a vlan-t és minden érintett portot tagged -be tennék és gondolom működne. (guest és a router is vlan képes)

És itt jön az elméleti(?) problémám, ha tagged a port, akkor a vlan nélküli csomagok is megkapják a vlan-t és akkor a nem vlan megszűnik működni. Ha untagged-be teszem, akkor meg "elvszik" a vlan már a középső switch-nél.

Vagy valamit nagyon félreértek :)

A kérdés tehát, hogy lehet-e egy vlan "tunnelt" csinálni a nem vlan forgalom mellett, ugyanazon a portokon? És ha igen, akkor mire kellene állitani a switch portokat. (cisco smart business switch-ek)

Nekem végülis az kellene, hogy ne variáljon a switch semmit a tagekkel, ami vlan taggel jön, az menjen tovább vlan-ként, ami meg anélkül az meg anélkül.

  • 1737 megtekintés

( kroozo v | 2018. 07. 09., h – 08:11 )

Egyrészt átalában lehet, a hívószó native vlan, az lesz az a vlan, ami az adott trunkon vlan id nélkül közlekedik.

Esetedben kis nehezítés, hogy ilyet pl a vmware mikor utoljára néztem (5.5, vagy 6 eleje) még nagyon nem tudott. És ugye neked a setupod igazából a vswitch -> sw1 -> sw2 -> sw3. vswitch alatt nyilván az adott virtualizációs cucc switche értendő, ami kvmnél pl a host gép lesz gyakorlatilag.

De nem kell ezt túlmisztifikálni, az uplinkek trunkök, lesz rajta két vlan, az egyik az eddigi forgalomnak, a másik különszedni kívánt hostnak. Az előbbi portja untaggedben (access, vagy ahogy épp hívják) megy ez egyik vlanba, a többi hosté meg a másikba, szintén untagged. Ez megy a vswitchel is simán.

És, ha tagged-ben van, akkor úgy fog működni a sima vlan mentes forgalomnál, hogy beleirja, hogy márpedig 1-es vlan a csomag, átadja a következő switch-nek és, ha azon van pl. a célállomás, akkor az meg leveszi a tag-et róla az egyik untagged portján?

(félek, hogy kizárom magam, ha megszűnik a tag mentes hálózat :)

Továbbmenve, ha a virtalizációs gépbe menő port tagged lesz, az nem fogja kinyirni a vlan mentes csomagokat? Nem fogja úgy kiküldeni a sima forgalmat, hogy benne van az 1-es tag? Mert azt szerintem nem fogja tolerálni a többi vm.
Nekem tényleg az kellene, hogy a jelenlegi packet-ekhez ne nyúljon egyik switch se, csak taggelje fel az új vlan-os packeteket, pontosabban még az sem kell, fel lesz az taggelve a két végpont által (vm és router), csak forwardolják tovább.

(bocs, hogy akadékoskodok)

> És, ha tagged-ben van, akkor úgy fog működni a sima vlan mentes forgalomnál, hogy beleirja, hogy márpedig 1-es vlan a csomag, átadja a következő switch-nek és, ha azon van pl. a célállomás, akkor az meg leveszi a tag-et róla az egyik untagged portján?

Eddig arról volt szó, hogy elméletben szeretnéd megérteni :) Szóval fogalmam sincs, mi fog történni, pl mert még azt sem árultad el, hogy milyen switch, meg milyen virtualizáció.

> Nekem tényleg az kellene, hogy a jelenlegi packet-ekhez ne nyúljon egyik switch se, csak taggelje fel az új vlan-os packeteket, pontosabban még az sem kell, fel lesz az taggelve a két végpont által (vm és router), csak forwardolják tovább.

Nem, neked az kellene, hogy működjön két szeparált hálózat, ez csak a szerinted elképzelt megvalósítási módja :)

Alapvetően az van, hogy egy egy L2es csomag vagy taggelt, vagy nem. A vlan képes switchek, mint kolléga írta, valami belső vlanhoz minden gyártó hozzá rendeli az untagged forgalmat.

- Az alap "access" portokon untagged forgalom van, ami ott megy, az része az intefacehez hozzárendelt vlannak (ha nincs explicit vlan hozzárdenelve, akkor szokott játszani a default vlan). Itt a többi eszköznek már nem kell tudni arról, hogy ez egyébként egy vlan.
- A trunk portokon a switch azt várja, hogy legyen vlan id minden packeten. Az alapján megy vlanba. Amin nincs, az a levesbe. Ebből következőleg, ha ilyenre van rádugva a kliens, akkor neki emiatt explict taggelnie kell ugye, különben megy a cucca a levesbe.
- A mixed, generic, vagy ahogy épp hívják a taggeletlen packeteket beteszi az interfacenek megmondott natív vlanba, a taggelteket meg a tag alapján. Kifele dettó ugyanezt teszi, a natív vlant taggeletlenül küldi. Ezt nem biztos, hogy a vswitch tudja

Neked ebből kell főzni, és ehhez konfigolni be mindent, konzisztensen.

Ennek a legalapabb módja, hogy
- az eddigi kliens portok mind maradnak accessben, és hozzárendelődnek egy vlanhoz (ez lehet a default 1es, vagy akármi).
- kitalálsz egy vlan idt az új vlannak
- az eddig switchek közötti portok trunké alakulnak, és átengedik mindkét vlant
- Az a port, amire a vmware van dugva, szintén ilyen trunk lesz
- A virtuális switch uplinkje szintén ilyen trunk lesz
- A virtuális interface (port), amin a kérdéses virtuális gép lóg access lesz az új vlanban
- Az összes többi virtuális port szintén access lesz, de a régi vlanban.

Így minden host saját portja taggeletlenül közlekedik a megfelelő vlanban, a switchek között meg szépen minden taggelve megy.

Persze bonyolíthatod, hogy de a switchek között csakazértis taggeletlenül menjen valamelyik vlan a natív vlan belekeverésével, de az szerintem csak netto önszopatás.

"azt sem árultad el, hogy milyen switch, meg milyen virtualizáció."

Bocsi, csak lejjebb linkeltem, SG-300 -as cisco: https://imgur.com/Cltrdmr

A másik switch meg SG-200-as. A virtualizáció az Hyper-V 2016. (bár ott kevésbé érzem a problémát, akár dedikált vswitch-en, akár kövzetlenül a vm-ből meg tudom oldani a tagging-ot, annak a VM-nek aminek erre szüksége van)

"A trunk portokon a switch azt várja, hogy legyen vlan id minden packeten. Az alapján megy vlanba. Amin nincs, az a levesbe. Ebből következőleg, ha ilyenre van rádugva a kliens, akkor neki emiatt explict taggelnie kell ugye, különben megy a cucca a levesbe."

Ez zavar meg leginkább. Trunkban van minden port (ez a gyári, default beállitás) és működik most is minden, pedig nincs semmilyen tag semelyik porton.

"A mixed, generic, vagy ahogy épp hívják a taggeletlen packeteket beteszi az interfacenek megmondott natív vlanba, a taggelteket meg a tag alapján. Kifele dettó ugyanezt teszi, a natív vlant taggeletlenül küldi"

Nekem ez tűnik annak amit én szeretnék. Tagnélküli tagnélkül, taggelt taggelve.

"az eddigi kliens portok mind maradnak accessben"

itt kezdődnek a gondjaim :)

"az eddig switchek közötti portok trunké alakulnak"

ezzel pedig folytatódnak, most is trunk mind :)

Azt hiszem nem lesz más, vagy helyben kell csináljam, vagy dedikálnom kell magamnak egy külön portot amihez nem nyúlok és akkor talán nem zárom ki magam egy elbaltázott vlan konfiggal.

Nagyon köszi az infokat.

Sajna nincs, csak a web-es felület és a reset gomb.

https://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbms/sf30x_sg30x/administration_guide/78-19308-01.pdf - SG300

https://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbss/sf20x_sg20x/administration_guide/78-21139.pdf - SG200

https://software.cisco.com/download/home/283771828/type/282463182/release/1.4.8.06 - Mindkét verzióhoz jó a firmware.

Én sem értem a felháborodást, ez nem egy internetszolgáltató gerince, miért ne felelne meg 40 géphez ez a széria. Minek kellene ide ennél nagyobb cisco? Mi az amit ez nem tud és szükség lenne rá egy kisirodában?

Ezt a vlan-t és meg lehetett oldalni rajta kb 10 kattintásból, csak tudni kellett melyik az a 10 :)

"A trunk portokon a switch azt várja, hogy legyen vlan id minden packeten. Az alapján megy vlanba. Amin nincs, az a levesbe. Ebből következőleg, ha ilyenre van rádugva a kliens, akkor neki emiatt explict taggelnie kell ugye, különben megy a cucca a levesbe."

Ez így nyilván minimum sántít, a natív vlan-nak pont trunk-nél van egyáltalán értelme, tehát trunk-ön a tag nélküli csomagok a leves helyett a natív vlan-ba mennek.

Nem sántít az, csak próbáltam összerakni barátunknak, taggeletlen traffic, taggelt traffic, vegyes traffic dolgokat a fejében, ott van a harmadik.

Az, hogy a harmadikat éppen úgy látod, hogy trunk meg alatta natív vlan, vagy van neki külön neve (rémlik még cisco, ahol ezt genericbe kellett tenni), vagy úgy, mint a kolléga screenshotján, hogy a vlan alatt tudod kattogtatni, hogy melyik interfacen tagged meg untagged, az sajnos zavaros implementációs részlet.

( denke v | 2018. 07. 09., h – 10:32 )

Szia!

Egy switchporton (ebbol a szempontbol) ket kulon fajta csomag kozlekedhet, "tagged", es "untagged".

Te most normal halozatos kommunikacio alatt mindent "untagged" modon kuldesz at.
VISZONT!! egy VLAN kepes switch nem ismer olyat a sajat *belso kommunikaciojaban* (ket portja kozott) hogy untagged, ott minden egyes csomag mindig egy vlan resze, defaultban ez a vlan1 ... kvazi mindig (ez cisconal a "switchport access vlan [szam]" parancssal allithato).

Egy vlan kepes switch egyes portjaira meg tudod adni hogy mi az aktualis mod. Ezek a modok gyartok kozott kvazi ugyanazok, de az elnevezesuk gyartonkent elter, megprobalok most a cisco terminologianal maradni.
-Access mod: az adott port untagged kommunikaciojat egy bizonyos (belso) vlan tagjanak tekinti, (Ezt PVID-nek vagy nativ vlannak nevezzuk defaultbol VLAN 1). a portra beeso taggelt csomagokat eldobja.
-Trunk / global / mixed / hibrid stb. (ezt mindig keverik a gyartok...) mod: az untagged csomagokat eldobja (ez a masodik viselkedes) vagy az access-hez hasonlo modon kezeli (ez a harmadik), a taggelteket pedig a megegyezo szamu "belso" vlanhoz koti, vagy eldobja, attol fuggoen hogy az adott port szamara mely vlanok vannak engedelyezve.

Alap esetben tehat azert mukodik ez az egesz, explicit vlan konfig nelkul, mert minden port access, es minden port untagged kommunikacioja a belso vlan 1 resze.

----
Amit neked tenned kell a switchek kozott, valamint a router es a vmware fele (feltetelezem hogy a vlan tagging mode defaultbol 802.1q):
-belepsz config modba ("configure terminal")
-letrehozod a switcheken az altalad kivalasztott vlan-t, pl vlan 100. ("vlan 100")
-A masik switchek fele nezo switchportokat egyesevel vagy csoportosan (interface 1/0/1 pl vagy interface range ...) atteszed "access" -bol valami olyan modba, ami kezel tagged es untagged kommunikaciot is, cisconal ez altalaban "trunk" neven fut. ("switchport mode trunk")
-Ezeket a switchportokat hozzaadod az adott vlanhoz hogy atengedje a taggelt kommunikaciot ("switchport trunk allowed vlan add 100")
-kilepsz konfig modbol (exit)
-mented a configot (write memory / copy running-config startup-config)

Ezek utan hozzaadhatod a routeren es a vmware-en a vlant az adott porthoz. A legregebbi vmware amivel dolgoztam az 4.4 volt de mar az is tudta ezt.

Köszi. Az biztos, hogy eddig is trunked vlan1-ben volt minden port gyárilag és átment rajta a vlan tag mentes forgalom.

Ezek smart switch-ek, webes felületen kezelem őket. Bár van ssh elérés is, de inkább maradnék a webesen, ha lehet.
Odáig stimmel, hogy trunk-ban van minden. Viszont ilyen allowed dologhoz még hasonlót sem látok a felületen:

https://imgur.com/Cltrdmr

A GE26-os porttal játszok, kínomban már áttettem General-ba trunkból.

(az külön jó, hogy amilyen hülye vagyok távolról csinálom és folyamatosan rettegek, hogy mikor zárom ki magam, ezért volna fontos, hogy a vlan mentes forgalom még véletlenül se álljon meg)

( Skuzzy | 2018. 07. 09., h – 16:01 )

A kérdésem, hogy igazából miért is akarod külön vlan-ba azt a forgalmat (ha ennyire nem tiszta a dolog) ?

A teljes történet, hogy van néhány unifi AP az sw1-en és van egy unifi controller VM szintén az sw1-re kötve. (ugyanezen szerveren meg van még sok más VM és van még sok más szerver is)
Az AP-kat szeretném követlenül az sw3 mögött lévő router-be vinni egy szeparált vlannal, de persze a controllernek is el kell érnie az AP-kat, ezért neki is ebben a vlan-ba kell kerüljön. (de a többi VM-nek nem)

De nem szeretném külön kábellel/portokon vinni a vlan-t a routerig, hanem szeretném a meglévő kábeleken, meglévő portokon vinni, mint egy tunnel, a meglévő (taggeletlen) forgalom mellett.

( zoli2468 | 2018. 07. 10., k – 07:38 )

Nagyon köszönöm mindenkinek az infokat, sikerült beállitanom az éjjel, anélkül, hogy kizártam volna magam távolról :)

A megoldás az lett, hogy
- a vlan-t nem érintő portok maradtak trunkban, 1-es vlanon untagged-ben, 1-es PVID-vel, az új 4-es vlan-ban pedig exluded-ban
- a vlan-t érintő portok átmentek generalba (bár úgy tűnik maradhatnak trunk-ban is, nincs jelentősége), marad az 1-es vlan untaggedben és 1-es PVID, és megkapták a 4-es vlan-t tagged-ben

Összefoglaló a felületről: https://imgur.com/KB2jMXy