[vaegkuulja]

Hi, miks Workstation kõrvaldab vlan IEEE 802.1Q headerid nii sisse kui välja pakettidest ning kas selle vastu rohtu on. Siis pean silmas virtuaalmasina virtuaalse võrgukaardi ühendust hosti füüsilise võrgukaardiga bridgena läbi virtualswitchi.
Natuke paremaks sain asja nii et ostsin USB3 kaardi ja USB3-->LAN1000 adapteri, hostis suunasin adapteri Win2012 guesti ja seal tegin windowsi bridge virtuaalmasinate team virtuaalse adapteriga. Nüüd saavad kõik teami VM-id kasutada lan-teami virtuaalvõrgukaarte. Selgus et nii IEEE 802.1Q header siiski jõuab VM-idesse, kuid tagasi tulevad paketid on ikka ilma. Põhimõtteliselt VLAN-e juba teha saab, kuna ühest suunast piisab. Manageeritava virtuaalse switchina saab mingisse VM-i installitult
edukalt kasutada Mikrotikut, mis oskab VLANe suunata, kui tage lisada ja eemaldada. Kuid ikkagi Vmware Workstationi tööga pole rahul.

[scrapper]

Kas sul on VLAN tagitud kõikides portides kus on mitu VLANi? Virtuaalmasin ei midagi teadma VLANidest kui ta tal neid mitu võrgukaardi/pordi kohta pole.

[vaegkuulja]

[scrapper]

Workstation toetab VLANe ilusasti - alates 6.0st. Mulle jääb arusaamatuks miks sul virtuaalmasinad VLANe tagivad. Mida sa sellega saavutada soovid, VM-ruuterit? VLANide tagimine on vajalik vaid siis kui sul pordist liigub läbi mitu erinevat VLANi ja reeglina lõppseadmes (VMs) on vaid üks võrk.

Kui sul on füüsilises võrguseadmes mitu võrku ning Workstationis mitu võrku siis peab olema tagitud vaid switchi port ning Workstationi switchipoolne füüsiline port. Kõige lihtsam on aga kui sa WM-Hostis võrgukaardil seadistad VLANid virtuaalseteks võrgukaartideks ja ühendad Workstationis iga guesti virtuaalse võrgukaardi külge. Eeldusel, et hosti võrgukaart VLANe ka toetab.

[vaegkuulja]

[scrapper]

Kui sul VM-hosti võrgukaart toetab rauas VLANi siis sul ei olegi vaja mitut porti/kaarti - loe uuesti mida kirjutasin.

[vaegkuulja]

[scrapper]

Ma ei tea mis NICe sa kasutad aga näiteks Inteli ProSet tarkvaraga saab küll virtuaalkaarte teha VLANi põhiselt. Broadcomi tarkvaraga ka. Egress tagging pole samuti probleem olnud.

[vaegkuulja]

[scrapper]

Võrgukaardi driver saab teha iga VLANi jaoks virtuaalse NICi mida saad eraldi hallata OSis nagu päris kaarti. Workstationis lihtsalt bridge'id need guestidega. Inteli kaardid peaks toetama 64 VLANi.

[vaegkuulja]

[scrapper]

Intel Proset on asja nimi ja sa pead installi käigus kindlasti advanced features vmt. linnukese panema.

[vaegkuulja]

[scrapper]

Kas sellega saad?

[vaegkuulja]

[scrapper]

Huvitav ma lugesin oma saadetud lingist et on nimelt sinu kaart ja os (Server 2012 ja ka R2) toetatud.

[vaegkuulja]

[OFFF]

Nõustun täiesti scrapperi soovitusega. Enamasti puudub reaalne vajadus 802.1q VMi vedada. Mõtle oma võrgu planeering korralikult läbi ja untagi kõik kaadrid virtualiseerimise hostis. Igale VLANile oma bridge ja VMidele "untagged".
Teine asi... see VLANide asi tundub Sul enda jaoks olema korralikult selgeks tegemata. Loe ajaviiteks teooria mõttega läbi ja saad aru, mis on mis ja mis on milleks.

[vaegkuulja]

[karu]

[vaegkuulja]

[OFFF]

Tegelikult teeb VLAN header eetrikaadri suuremaks. Nüüd oleneb väga palju mittemanageeritava kommutaatori max MTUst, kas sealt lähevad nii suured kaadrid läbi või ei lähe.
Tsitaat Wikipediast:
802.1Q does not encapsulate the original frame. Instead, for Ethernet frames, it adds a 32-bit field between the source MAC address and the EtherType/length fields of the original frame, leaving the minimum frame size unchanged at 64 bytes (octets) and extending the maximum frame size from 1,518 bytes to 1,522 bytes (for the payload a 42-octet minimum applies when 802.1Q is present; when absent, a 46-octet minimum applies. IEEE 802.3-2005 Clause 3.5). Two bytes are used for the tag protocol identifier (TPID), the other two bytes for tag control information (TCI). The TCI field is further divided into PCP, DEI, and VID.[1]
ja üks asjakohane lugemine, mees kes on testinud mitmeid odavswitche 802.1q kontekstis
http://blog.thelifeofkenneth.com/2014/03/pushing-vlan-tags-through-unmanaged.html

[OFFF]

"Kõigepealt virtuaalmasinate hostile ma ei taha riskuks rohkem kui ühte kaablit. "
Kui sul on TRUNK port, kust kõik VLANid läbi lähevad, siis saab hakkama ka ühe kaabilga. Mina soovitaks miinimum kahte ja 802.3ad "channel bond" sinna teha. Kiirem. Ja tõrkekindlamJa
Ja minu ja scrapperi soovitused ei käinud ÜLDSE selle kohta.
Põhimõtteliselt on kaks võimalust. Virtualiseerimise hosti võrguliides on ühendatud trunk porti, kus sees on ports VLANe (ja võib olla ka native VLAN). See trunk port on sillatud ja kõik VMid näevad oma virtuaalse liidese peal kõiki kaadreid ja korjavad üles ainult need, mille jaoks nende liides on seadistatud.
Teine võimalus on see, et virtualiseerimise hosti tuleb sisse ports vlane, iga vlani jaoks on tehtud vastav liides ja vastav sild. Virtuaalmasinate virtuaalsed liidesed on ühendatud ainult neile määratud VLANi sillaga.
Teine võimalus on üldiselt turva mõttes mõistlikum ja ka ressursihalduse mõttes mõistlikum.
Ma saan aru, et idee on Sul hea, aga Sinu seletuste järgi on natuke raske mõista, milline sinu võrguarhitektuur täpselt on ja mida sa soovid saavutada.
"Ma ei kasuta VLANe üldse nii et kahe võrgupunkti vahel on VLAN ja et neid omavahel ruuteriga ühendada. "
Aga selle jaoks pole VLAN üldse mõeldudki. VLAN on "virtuaalne LAN". Virtuaalne kohtvõrk. Ühes füüsilises seadmes saab olla mitu virtuaalset kohtvõrku. Enamasti pannakse ühte kohtvõrku kokku loogiliselt kokku kuuluvad seadmed. Suurtes võrkudes lahutatakse vahel virtuaalseteks kohtvõrkudeks laiali ka loogiliselt samasse võrku kuuluvad seadmed, et broadcast domain oleks väiksem ja kõiksugune overhead oleks madalam. Sellisel juhul kasutatakse enamasti vlanide vaheliseks marsruutimiseks L3 võimekusega kommotaatoreid.
Kui võrkude vaheline liiklus vajab filtreerimist (tulemüürireeglid), siis suunatakse VLANide vaheline liiklus läbi marsruuter-tulemüüri. Saab ka kommutaatoris ACLe kasutada, aga siis tekib see probleem, et pääsureeglid "roomavad laiali" üle mitme seadme ja hallatavus muutub kehvemaks.
Mul on näiteks ka kodus "kodune VLAN", omaenda väikefirma "test VLAN", "klientide virtuaalmasinate VLAN" ja nii edasi ja nii edasi. Kõigi nende VLANide vahelist marsruutimist toimetab tulemüür, mis lubab, vastavalt reeglitele, sinna kuhu vaja, neid keda vaja.
See segmenteerimise IDEE on Sul isenesest õige, aga teostuse oled sa, IMHO ajanud enda jaoks jaburalt keeruliseks ja raskesti hallatavaks.
Nüüd on tuleb mängu veel selline huvitav asi, nagu 802.1q standardi REALISATSIOON erinevate tootjate poolt.
Näiteks (de-facto standardil) Cisco on "access port" "trunk port" ja "hybrid port"
Access port on "tavaline port" mis kuulub mingisse VLANi (ehk siis ingress on sellesse VLANi kuuluvad kaadrid ja egress on untagged)
Trunk port laseb vaikimisi läbi kõik TAGGED kaadrid koos tagiga ja lisaks võib olla üks "native VLAN" kuhu kuuluvad kaadrid egressis untagitakse. Reeglitega saab piirata, millise markeeringuga kaadreid trunk porti lubatakse.
Hybrid port on selline naljakas perverssus, kus lisaks markeeritud kaadritele võib olla MITU native VLANi, mis lähevad egressi untaggedina. Üldjuhul peab olema VÄGA MÕJUV põhjus seda asja kasutada ja enamasti tehakse siis filtreerimist kommutaatori ACLidega.
Brocadel on asjad samamoodi nagu Ciscol.
HP/3Com maailmas on asi põhimõtteliselt sama moodi v.a. see, et vaikimisi lubab seadistamata trunk port läbi ainult "default VLAN" ehk VLAN1 markeeritud kaadreid. Egress on vaikimisi
markeeritud. Kõik soovitud VLANid tuleb ekskulsiivselt lubada.
Enterasys kasutab seda Sinu poolt mainitud ja ka TP-LINK kommutaatorites kasutusel olevat egress/ingress süsteemi.
Üldiselt vahet pole, kõik ülalmainitud implementatsioonid ajavad asja ära, aga minu isikliku arvamuse kohaselt on trunk-access lähenemine natuke loogilisem ja parimini hoomatavam ja hallatavam, kui see ingress-egressiga mängimine. Tuelmus, kui asja õigesti tööle paned, on mõlemal juhul sama.
Ja üks vahemärkus veel, Sinu probleemid algasid tegelikult sellest, et sa kasutad virtualiseerimise hostis natuke puujalgset operatsioonisüsteemi, millel on kööbakas võrgupinu ja (nagu me Sinu näitel kenasti nägime) probleeme ohjurite, ühilduvuse ja dokumentatsiooniga. Kasuta mõnda mõistlikku, unixi derivatiividel põhinevat, töökindlat virtualiseerimise platvormi ja kõik need probleemid hajuvad isenesest nagu udu. Edu!
P.S. Ja VLAN on L2 kontseptsioon ja IP on L3 ... VLAN Sul nüüd küll kuidagi otseselt IP konflikte vältida ei aita. Sama VLANi sees elavad õnnelikult kõik IP subnetid. Proovi järele, kui ei usu

[vaegkuulja]

[OFFF]