Takze predpokladejme, ze je to opravdu potreba technicky vyresit a pojdme do vetsiho detailu ... chapu, protoze to taky potrebuju resit v prostredich, ktera ale vetsinou nepouzivaji FreeBSD jako virtualizacni hosty. Nicmene je mozne si z toho vzit patricne principy a treba si Mirek najde nejake pouzitelne reseni pro FreeBSD a svoje prostredi.
Miroslav Lachman > Na switchi je mi to k nicemu, to uz je "prilis daleko". Mozna ano, mozna ne. Zase zalezi na prostredi. Ja znam sitova prostredi, kde se vsechno extenduje do "top of rack" switchu. Jedna se o CISCO Nexus + FEX (fabric extenders). A toto je pak mozne jeste rozirit az do virtualizacnich platforem (VM-FEX), ale to urcite nebude tvuj pripad. Nicmene tim chci rict, ze na switchi to nemusi byt prilis daleko. Nicmene uznavam, ze pro tvoje prostredi to asi daleko je. 2012/11/18 Dan Lukes <d...@obluda.cz> > > Kazdopadne, smeruju k tomu, ze to co chce je dost specialni problem i pro > skutecne LAN a nema zadne "normalni" softwarove reseni. Neznam hypervisor, > ktery by mel naimplementovano reseni tohoto specialniho problemu (byt' je > nesleduju tak detailne, aby mi to nemohlo uniknout) V nevirtualizovanych "normalnich" modernich CISCO L3 LAN se to podle me da resit pomoci port-security arp spoofing viz. http://www.cisco.com/en/US/products/hw/switches/ps5023/products_configuration_example09186a00807c4101.shtml a jestlize se na portu objevi nepatricna MAC ci IP, tak se port prepne do err-disabled stavu. Takze tim napatricna sitova konfigurace na koncovem zarizeni zadisabluje port na switchi a je vystarano. V jinych nevirtualizovanych LAN sitich s podporou PVLAN je to mozne resit kombinaci preventivne pomoci privatnich VLAN a statickych ARP zaznamech na routeru. Staticke ARP zaznamy na routeru je mozne delat bud manualne a nebo nejakym proprietarnim resenim integrovat s nejakou databazi autorizovanych dvojic MAC a IP. Takto to podle mych informaci resi provideri, kteri poskytuji server housing a chteji ochranit jednotlive zakazniky mezi sebou. V softwarovych virtualnich sitich to dlouhodobe umi resit CISCO Nexus1000v, ktery relativne dlouho existuje pro VMware vSphere (ESX Enterprise Plus) a aktualne pry i pro MS Hyper-V a CITRIX Xen Server. S prvnim jmenovanym resenim mam prakticke hands-on zkusenosti s ostatnimi nikoliv a ani to neplanuji :-) V softwarovem VMware distribuovanem virtualnim switchi funguji PVLANs, takze se tam da pouzit ten PVLAN princip jako v nevirtualizovanych sitich. V opensource komunite ted pry leti OVS (Open vSwitch) http://openvswitch.org/ , ale zatim jsem nemel cas si s tim hrat. A koukam, ze existuje port pro FreeBSD http://www.freshports.org/net/openvswitch/ a tim se tak jako tak obloukem vracime zpet k tomu, ze mozna bude proste > nutne sahnout k netechnickemu reseni problemu ... > > netechnicke reseni muze byt opravdu nejjednodussi, ale to tady asi nema cenu resit a rozhodnout se musi Mirek. > > Zde bych dodal, ze jde o relativne novou vec, a to i na IPv4, a uvedene > moznosti maji jen dost nove switche, obvykle jeste navic jen s nejakym > dostatecne soucasnym firmwarem. Pokud by totez clovek chtel i pro IPv6 tak > to uz aby clovek vhodne zarizeni opravdu spendlickem pohledal. > > > Toto je urcite velka pravda. Je to opravdu hodne nova vec a vendori a cele odvetvi teprve hledaji svoje "nejlepsi" reseni. A je take pravda, ze mnozi to vubec neresi. A take je pravda, ze hodne zalezi na pouzitem hardwaru a jeho vlastnostech. Tim, ze jsem pracoval v CISCO a ted zase v DELLu (ktery koupil sitarskou firmu Force10) jako virtualizacni architekt a mam pristup k nejnovejsim technologiim prave pro virtualizaci a sitovou konvergenci, tak mam hrozne moc i internich informaci. A sitova vizibilita a kontrola pres fyzickou a virtualni sit je velke tema dneska, ktere se snazi vsichni resit, ale opravdu to neni jednoduche a nejdale je podle meho nazoru CISCO, ale to jsou technologie, ktere nam ve FreeBSD nepomuzou. S relativne standarnimi fyzickymi switchi s podporou VLAN a ve FreeBSD, ve kterem bezi ve virtualboxech virtualy, bych si dokazal predstavit relativne jednoduche technicke reseni takove, ze by ve fyzicke siti existovalo vice VLAN a tudiz by ve FreeBSD byly namapovany na virtualni sitova rozhranni, ktera by pak byla propagovana do prislusnych virtualu. Kazda VLAN by mela svoji IP sit a nekdo by to routoval. Spotrebovalo by se tim relativne hodne VLAN a IP siti, ale otazka je jestli to v tomto konkretnim prostredi vadi. U velkych cloudovych provideru to vadi, protoze pocet pouzitelnych VLAN je limitujici pro pocet zakazniku. Vsichni vedi, ze v L2 segmenu muzeme mit 4096 VLAN IDs, ale malokdo si uvedomi, ze vetsinou je realny limit cca 1024 pouzitych VLAN. -- David Pasek david.pa...@gmail.com -- FreeBSD mailing list (users-l@freebsd.cz) http://www.freebsd.cz/listserv/listinfo/users-l
