klasicky to nefunguje
vo freebsd nefunguje "klasicky" model konfiguracie bridge a vlan ako napr. v linux alebo mikrotiku. a teda ze nad fyzickou sietovkou sa vytvoria vlan interface a kazdy sa potom prida do samostatneho bridgu.
------- br0 -------
| | -------
------------------- | ------ ------ | | |
| physical switch |---------| eth0 | | tap0 |------| VM1 |
------------------- | ------ ------ | | |
| | | -------
| | |
----|--------------
|
|
------------------
| |
------|------- --------|-----
| | | | | |
| ---------- | | ---------- |
| | eth0.100 | | | | eth0.200 | |
| ---------- | | ---------- |
------- | | | | -------
| | | ------ | | ------ | | |
| VM2 |------| tap1 | | | | tap2 |------| VM3 |
| | | ------ | | ------ | | |
------- | | | | -------
--- br100 ---- --- br200 ----
nakonfigurovat sa to da, ale tagovany trafik, ktory prichadza na fyzicku sietovku, "zozerie" bridge, v ktorom sa dana sietovka nachadza. standardne su tagovane pakety "prijate" vlan rozhranim a preposielane do prislusneho bridge (uz netagovane).
epair
na forach sa o tom da najst len velmi malo. nastastie freebsd disponuje roznymi vychytavkami, a jednou z nich je aj epair - virtualne ethernet-like rozhranie, resp. rozhrania, ktore su medzi sebou prepojene. konkretne sa vytvori rozhranie epair<n>a a jemu prisluchajuci par epair<n>b, napr. epair0a a epair0b. ich vlastnost je taka, ze co pride na jeden koniec, vyjde na druhom a naopak.
konfiguracia
- vytvorime bridge bridge0 pre netagovany trafik, v ktorom bude fyzicka sietovka (napr. re0), pripadne ine virtualne rozhrania pridelene virtualom, ktore chceme mat v netagovanej sieti (napr. tap0)
- vytvorime si bridge bridge100 (pre vlan-u 100), do ktoreho pridame virtualne sietovky tych virtualov, ktore chceme mat v danej vlan-e 100 (napr. tap1)
- vytvorime epair interface epair0 - a teda pribudnu nam v systeme dalsie dve rozhrania epair0a a epair0b
- interface epair0a pridame do bridge0
- nad epair0b vytvorime vlan interface, resp. pre kazdu vlan-u prave jeden (napr. epair0b.100)
- vlan interface epair0b.100 pridame do prislusneho bridge pre danu vlan-u, teda v nasom pripade bridge100
----- bridge0 ----- | | ------- ------------------- | ----- ------ | | | | physical switch |---------| re0 | | tap0 |------| VM1 | ------------------- | ----- ------ | | | | | ------- | --------- | | | epair0a | | | --------- | | || | --------||--------- || || --------- | epair0b | --------- | | ------------------ | | ---------|------- --------|-------- | | | | | | | ------------- | | ------------- | | | epair0b.100 | | | | epair0b.200 | | | ------------- | | ------------- | ------- | | | | ------- | | | ------ | | ------ | | | | VM2 |------| tap1 | | | | tap2 |------| VM3 | | | | ------ | | ------ | | | ------- | | | | ------- --- bridge100 --- --- bridge200 ---ako to funguje
na fyzicku sietovku pride netagovany trafik. odtial sa preposle do bridge0, odtial sa preposle na vsetky interface v danom bridge. napr. na tap0, kde ho potom spracuje virtual. trafik sa preposle sa aj na epair0a, ktory doslova "vyjde" na druhom konci na epair0b. ale kedze dalej uz mame len tagovane vlan sietovky (epair0b.n), tak sa dany trafik zahodi.
ak na fyzicku sietovku pride tagovany trafik (napr. vlan-100), tak tap0 ho zahodi, lebo to nie je vlan interface, dalej sa tento trafik preposle cez epair0a na epair0b, nad ktorym je vlan-aware interface epair0b.100, ktory dany trafik prijme, odtaguje a preposle na ostatne interface v danom bridge.
spatna komunikacia prebieha v opacnom poradi.
konkretnym bridgeom mozeme nastavit ip adresu, bud pre netagovany trafik na bridge0, alebo na nejaky iny bridge konkretnej vlan-y. napr. mu mozeme nastavit ip len na bridge, ktory patri do management vlan-y...
@samalama: vďaka za príspevok, súhlasil by si s pridaním do našej wiki alebo plánuješ ešte niečo pridať?
robte si s tym, co chcete...
@Mariovia: Mozno by bolo dobre to prehodit do Wiki alebo do clankov
Podakovanie pre samalama samozrejmostou
Mám taký smutný dojem, že rozdiely medzi PC-BSD, FreeBSD a NetBSD boli nielen primárnom určení danej distribúcie, ale aj v jej funkcionalite. Jedná sa o sieťový problém aj v NetBSD?
Vývoj BSD nesledujem už vyše 10 rokov, takže a radšej pýtam či je stále dôvod na rozdelenie BSD.
neviem, konkretne toto som na net|openbsd este neskusal.
rozdelenie samozrejme ano, su to uplne odlisne systemy...
Presne to isté napadlo i mňa, že by to bolo dobré dať ako článok, či blog.