VLAN + bond + virtualizacio
Miloska <miloska@gmail.com>
Sziasztok,
adottak szerverek ket ethernet porttal, ket Cisco switch, mindegyik
gep beledugva mindket switchbe, bond interface, bond-on VLAN-ok,
mindenki orul.
Uj feladat, legyen virtualizacio.
KVM a kiszemelt megoldas, ahol azt irj a doksi, hogy csinaljak
bridge-et es abba rakjam a publikus interface-eket es a VM-ek
interface-eit.
Gondoltam a bond0 es a bond0.X VLAN interface-ekbol csinalok szepen
bridge-et, de a bond ezt nem szereti, nem mukodik az arp ellenorzes.
bonding: bond0: no path to arp_ip_target X.X.X.1 via rt.dev br0
Ket switch eseten viszont a bond doksi az arp ellenorzest javasolja.
Semmi gond, felhuzok akkor bridge-eket az ethernet interface-ekbol es
majd az STP megoldja a failovert, de ha tobb VLAN-om van (switchport
mode trunk) akkor elbeszelnek egymas mellett, (Cisco-n spanning-tree
mode rapid-pvst), es ha kihuzom az egyki kabelt akkor Loop_inc lesz
(mondjuk ezt nem teljesen ertem miert, de ez van), ha atrakom a portot
access-re akkor az STP megy, de igy VLAN-om nem lesz, amit azert
szeretnek.
Kerdesem, van erre valamilyen elengas megoldas? Cel, hogy legyen
redundancia is es VLAN-ok is.
Amit en latok, hogy talan mukodne az a bond mii-vel vagy az egesz
VLAN-ok nelkul, de valahogy ugy erzem a problema annyira trivialis,
hogy valami ezeknel szebb megoldas kellene, hogy legyen.
Ugy erzem nem latom a faktol az erodot.
Udv
_________________________________________________
linux lista - li...@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
Gabor HALASZ
Miloska wrote:
>
> Amit en latok, hogy talan mukodne az a bond mii-vel vagy az egesz
> VLAN-ok nelkul, de valahogy ugy erzem a problema annyira trivialis,
> hogy valami ezeknel szebb megoldas kellene, hogy legyen.
Segiteni nem tudok, de otletem van, merre keresgelj: a bridge teljesen
szar megint a kernelben, nalam utoljara 802.11 stack hulyult meg tole
teljesen, utoljara 2.6.31.x-el probaltam, de azon is azonnal megolte.
--
Gabor HALASZ <hala...@freemail.hu>
Papp Tamas
On Wed, Oct 28, 2009 at 03:25:46PM +0100, Gabor HALASZ wrote:
>
> Segiteni nem tudok, de otletem van, merre keresgelj: a bridge teljesen
> szar megint a kernelben, nalam utoljara 802.11 stack hulyult meg tole
> teljesen, utoljara 2.6.31.x-el probaltam, de azon is azonnal megolte.
A kvm oldalan (wiki?) irjak, hogy a wifi kartyak driverei nem
tamogatjak a bridge-inget? Ezek szerint ujabban megis, csak rosszul?
Mindenesetre lehet, ugyanaz a baja a bondingnak is.
tompos
Gabor HALASZ
Papp Tamas wrote:
> On Wed, Oct 28, 2009 at 03:25:46PM +0100, Gabor HALASZ wrote:
>> Segiteni nem tudok, de otletem van, merre keresgelj: a bridge teljesen
>> szar megint a kernelben,
> nalam utoljara 802.11 stack hulyult meg tole
>> teljesen, utoljara 2.6.31.x-el probaltam, de azon is azonnal megolte.
>
> A kvm oldalan (wiki?) irjak, hogy a wifi kartyak driverei nem
> tamogatjak a bridge-inget?
Nem erdekelnek a redhat marketingprojekjei, de sem a bridge, sem a wifi
nem resze a kvmnek; amugy sem nagyon erdekel, hogy a idetlen
kernelganyerek melyik napon mit szarnak el.
> Ezek szerint ujabban megis, csak rosszul?
Nem a bridge nem mukodik, az egesz wifi megbolondul egy brctl addif
hatasara; eleg idomet vette el, amig rajottem. Linux, nem kell bonyolult
dolgokat varni tole.
>
> Mindenesetre lehet, ugyanaz a baja a bondingnak is.
Lasd fent
--
Gabor HALASZ <hala...@freemail.hu>
Pápai Balázs
Gabor HALASZ írta:
> Nem erdekelnek a redhat marketingprojekjei, de sem a bridge, sem a wifi
> nem resze a kvmnek; amugy sem nagyon erdekel, hogy a idetlen
> kernelganyerek melyik napon mit szarnak el.
Szeretném megkérni a feleket, hogy a nem szakmai jellegű vitát ne ezen a
fórumon folytassák!
Lajber Zoltan
On Wed, 28 Oct 2009, Miloska wrote:
> KVM a kiszemelt megoldas, ahol azt irj a doksi, hogy csinaljak
> bridge-et es abba rakjam a publikus interface-eket es a VM-ek
> interface-eit.
KVM-et es linux bondingot nem nagyon ismeret, a tobbi resztvevot igen :)
Ket megoldast tartok esszerunek.
Ha tobb virtualis gep van mas-mas vlanban, akkor vlan-onkent kell egy-egy
linux bridge. Ezekbe a fizikai interface megfelelo vlan subinterface-e
kerul, es a virtualis gepek e celra szolgalo interface-e. Ezek nem
subinterface-ek, hanem dedikaltak adott vlan-hoz.
Kicsit regi xen-es terminologiaban tehat a bre0vlan100-ba kerul a
peth0.100, es a virt. gep eth0-ja. A bre1vlan100-ba kerul a
peth1.100, es a virt gep eth1-e. A virt. gepen bondingolod az eth0 es
eth1-et.
Ha a virt. gepeknek az osszes vlan-t latnia kell, akkor sokkal egyszerubb,
ha az egesz fizikai device-t atpasszolod neki. En pl igy csinalom a dhcp
szervereknel. A switchen a lab trunk, peth0 odaadva a virt. gepnek, csak
ott configolsz. De erzesem szerint neked nem ez kell...
Udv,
-=Lajbi=-----------------------------------------------------------------
LAJBER Zoltan Szent Istvan Egyetem, Informatika Hivatal
HTH=Hope This Helps, YMMV=Your Mileage May Vary, HAND=Have A Nice Day
Miloska <miloska@gmail.com>
Koszonom a valaszokat mindenkinek!
>
> Ha tobb virtualis gep van mas-mas vlanban, akkor vlan-onkent kell egy-egy
> linux bridge. Ezekbe a fizikai interface megfelelo vlan subinterface-e
> kerul, es a virtualis gepek e celra szolgalo interface-e. Ezek nem
> subinterface-ek, hanem dedikaltak adott vlan-hoz.
> Kicsit regi xen-es terminologiaban tehat a bre0vlan100-ba kerul a
> peth0.100, es a virt. gep eth0-ja. A bre1vlan100-ba kerul a
> peth1.100, es a virt gep eth1-e. A virt. gepen bondingolod az eth0 es
> eth1-et.
Ez elvben jo lenne, de ha ket fizikai interface-t rakok egy bridge-be
akkor STP-t kell futtatnom, viszont mivel tobb vlan van szebb lenne
MSTP vagy PVST, de ezeket a Linux nem ismeri, legalabbis en nem
talaltam meg.
>
> Ha a virt. gepeknek az osszes vlan-t latnia kell, akkor sokkal egyszerubb,
> ha az egesz fizikai device-t atpasszolod neki. En pl igy csinalom a dhcp
> szervereknel. A switchen a lab trunk, peth0 odaadva a virt. gepnek, csak
> ott configolsz. De erzesem szerint neked nem ez kell...
>
Jol latod, en VLAN-onkent szeretnek egy interface-t a virtualis gepbe.
Az lenne meg esetleg erdekes, ha alias interface-eket lehet igy
direktbe a VM-hez csatolni, gyanitom ez viszont nem lehetseges, nem
talalkoztam ilyen megoldassal a doksikban.
Idokozben ganyoltam egy akkorat, azt se tudom leirjam-e.
Rajottem, hogy ha a bond0 nincs bridge-ben akkor a bond mukodik jol es
a bond0.X VLAN interface-eket meg lehet hasznalni a bridge-ben. A
dolog egyetlen szepseghibaja, hogy azonos VLAN-nak kellene lennie
egyik Linux-os bridge-en es a bond0 interface-en is. Mivel a
switch-ben nem tudok bridge-et csinalni (Cisco 2960) igy egy kabellel
osszekotottem ket portjat a switchnek, igy 'osszebridgelve' a ket
VLAN-t.
Attol eltekintve, hogy
bond0.25: received packet with own address as source address
uzenetek jonnek a logba a mukodni latszik a dolog, bar eleg messze van
attol a fajta elegans megoldastol amit szeretnek.
Lajber Zoltan
On Thu, 29 Oct 2009, Miloska wrote:
> > linux bridge. Ezekbe a fizikai interface megfelelo vlan subinterface-e
> > kerul, es a virtualis gepek e celra szolgalo interface-e. Ezek nem
> > subinterface-ek, hanem dedikaltak adott vlan-hoz.
> > Kicsit regi xen-es terminologiaban tehat a bre0vlan100-ba kerul a
> > peth0.100, es a virt. gep eth0-ja. A bre1vlan100-ba kerul a
> > peth1.100, es a virt gep eth1-e. A virt. gepen bondingolod az eth0 es
> > eth1-et.
>
> Ez elvben jo lenne, de ha ket fizikai interface-t rakok egy bridge-be
En azt mondtam, hogy a ket fizikai interface-t ket bridge-be rakjad :)
> akkor STP-t kell futtatnom, viszont mivel tobb vlan van szebb lenne
> MSTP vagy PVST, de ezeket a Linux nem ismeri, legalabbis en nem
> talaltam meg.
MSTP + Rapid a jovo. De nem annyira jo failoverre az STP, jobb/gyorsabb a
bonding.
> Rajottem, hogy ha a bond0 nincs bridge-ben akkor a bond mukodik jol es
> a bond0.X VLAN interface-eket meg lehet hasznalni a bridge-ben. A
> dolog egyetlen szepseghibaja, hogy azonos VLAN-nak kellene lennie
> egyik Linux-os bridge-en es a bond0 interface-en is.
Miert lenne ez gany? :)
> Mivel a
> switch-ben nem tudok bridge-et csinalni (Cisco 2960) igy egy kabellel
> osszekotottem ket portjat a switchnek, igy 'osszebridgelve' a ket
> VLAN-t.
Miert nem tudsz bridget csinalni a switcheben? Mert az mar ugyis ezt
teszi? Ezt nem ertem.
Udv,
-=Lajbi=-----------------------------------------------------------------
LAJBER Zoltan Szent Istvan Egyetem, Informatika Hivatal
HTH=Hope This Helps, YMMV=Your Mileage May Vary, HAND=Have A Nice Day
_________________________________________________
Miloska <miloska@gmail.com>
>>
>> Ez elvben jo lenne, de ha ket fizikai interface-t rakok egy bridge-be
>
> En azt mondtam, hogy a ket fizikai interface-t ket bridge-be rakjad :)
>
Bocsanat, jogos, nem olvastam el rendesen.
A VM-en bonding vegulis nem rossz otlet, kerdes a host rendszernek
lehet-e valami redundans vonalat adni, bar eppen ha annak ket IP cime
van a bridge-eken nem dol ossze a vilag.
>
>> Mivel a
>> switch-ben nem tudok bridge-et csinalni (Cisco 2960) igy egy kabellel
>> osszekotottem ket portjat a switchnek, igy 'osszebridgelve' a ket
>> VLAN-t.
>
> Miert nem tudsz bridget csinalni a switcheben? Mert az mar ugyis ezt
> teszi? Ezt nem ertem.
>
Erteni en sem ertem, ha valakinek van otlete hogy is kellene halasan
veszem a megoldast (akar magaba, vegulis mar (meg) nem Linux). Sem
nekem sem az altalam ismert Ciscos sracoknak nem sikerult kitalalni
hogy is kellene.
Lajber Zoltan
On Thu, 29 Oct 2009, Miloska wrote:
> A VM-en bonding vegulis nem rossz otlet, kerdes a host rendszernek
> lehet-e valami redundans vonalat adni, bar eppen ha annak ket IP cime
> van a bridge-eken nem dol ossze a vilag.
Miert kell ip cim a bridge-re? Ha nem akarod routolni, csak brdigelni,
akkor nem kell neki ip.
> > Miert nem tudsz bridget csinalni a switcheben? Mert az mar ugyis ezt
> > teszi? Ezt nem ertem.
> >
>
> Erteni en sem ertem, ha valakinek van otlete hogy is kellene halasan
> veszem a megoldast (akar magaba, vegulis mar (meg) nem Linux). Sem
> nekem sem az altalam ismert Ciscos sracoknak nem sikerult kitalalni
> hogy is kellene.
Ha a switch ket laba trunk, akkor a 2960 hivatalbol osszebridgeli a ket
lab azonos vlan-ba tartozo forgalmat, mert ez a dolga. Hacsak valami
trukkos config nincsen, (dot1q vlan mapping, stb). De talan ilyent nem is
tud a 2960, csak a nagyobbak.
akkor megegyszer, az elkepzelesem:
-2960 ket laba a gep ket fizikai labara kot: peth0 es peth1.
-vlan-onkent es fizikai labankent kell kulon bridge-et csinalnod a
linuxon, a rend kedveert a pethX.vlanY -hoz tartozo bridge neve legyen
brpethXvlanY.
-ha egy virtualis gepnek kell az Y vlan-bol redundans kapcsolat, akkor
csinalsz neki ket interface-t: eth0 es eth1. Ezeketet berakod a
peth0.vlanY es peth1.valnY bridge-be, es a virtualis gepen belul
bondingolod.
Ez esetben a linux bridge-nek semmit nem kell tudnia a bondingrol. Viszont
a STP (mindegy hogy PVST, rapid vagy milyen) egyik utvonalat levagja.
Letilthatod az SPT -t a linuxos bridge-ben, de ekkor nagyon ugyelj arra,
hogy ne legyen hurok.
Beallitas szempontjabol egyszerubb lenne, ha a peth0 es peth1 lenne
bondingban, es a bond0.vlanY interfaceket raknad vlanonkent kulon
bridge-be (brvlanY), es ide tenned be a virtualis gep egyetlen
interface-et. Ennek tobb elonye van az elozo megoldashoz kepest:
-fele annyi bridge-ed van
-nem kell STP-vel bajlodnod
-nem kell bondingal bajlodni a virtalis gepeken.
De ha jol ertettem, neked indulaskor ez nem mukodott...
Udv,
-=Lajbi=-----------------------------------------------------------------
LAJBER Zoltan Szent Istvan Egyetem, Informatika Hivatal
HTH=Hope This Helps, YMMV=Your Mileage May Vary, HAND=Have A Nice Day
_________________________________________________
Miloska <miloska@gmail.com>
>
>> A VM-en bonding vegulis nem rossz otlet, kerdes a host rendszernek
>> lehet-e valami redundans vonalat adni, bar eppen ha annak ket IP cime
>> van a bridge-eken nem dol ossze a vilag.
>
> Miert kell ip cim a bridge-re? Ha nem akarod routolni, csak brdigelni,
> akkor nem kell neki ip.
Hogy erem el a host-ot? Mire rakjak ott IP-t ha nem a bridge-ekre?
...
> Ez esetben a linux bridge-nek semmit nem kell tudnia a bondingrol. Viszont
> a STP (mindegy hogy PVST, rapid vagy milyen) egyik utvonalat levagja.
> Letilthatod az SPT -t a linuxos bridge-ben, de ekkor nagyon ugyelj arra,
> hogy ne legyen hurok.
Koszonom, jo otlet, lehet, atgondolom mik az elonyok/hatranyok, minden
esetre ez mukodokepesnek latszik.
>
> Beallitas szempontjabol egyszerubb lenne, ha a peth0 es peth1 lenne
> bondingban, es a bond0.vlanY interfaceket raknad vlanonkent kulon
> bridge-be (brvlanY), es ide tenned be a virtualis gep egyetlen
> interface-et. Ennek tobb elonye van az elozo megoldashoz kepest:
> -fele annyi bridge-ed van
> -nem kell STP-vel bajlodnod
> -nem kell bondingal bajlodni a virtalis gepeken.
>
> De ha jol ertettem, neked indulaskor ez nem mukodott...
Mukodik, amig a bond0 interface nincs bridge-ben, csak a VLAN
al-interface-ek (bond0.vlanY).
Ezzel viszont az a baj, hogy az ARP ellenorzesnek azt a gateway-t
kellene ellenoriznie amit a virtualis gepek hasznalnak, tehat a bond0
es a bond0.vlanN egy halozatban kell legyen, amihez viszont ahogy en
latom bridge (kabel) kell....
Lajber Zoltan
On Thu, 29 Oct 2009, Miloska wrote:
> > Miert kell ip cim a bridge-re? Ha nem akarod routolni, csak brdigelni,
> > akkor nem kell neki ip.
>
> Hogy erem el a host-ot? Mire rakjak ott IP-t ha nem a bridge-ekre?
Arra kell ,egyetlen bridgere egyetlen ip. pl. Vagy a 3. vagy 4. eth
interface-en...
en azt szoktam csinalni xen-el, hogy az eth0 a domu-hoz megy, semmi mas.
Az eth1 standard modon a belso szerver halo ,az eth2 a dmz. Ha kell, akkor
egy-egy speci eszkoz (nyomtato szerver, dhcp/dns szerver) meg megkapja
fizikailag az eth3-at, e azon annyi vlan huzok fel a domU-ban, amennyi
kell.
> Ezzel viszont az a baj, hogy az ARP ellenorzesnek azt a gateway-t
> kellene ellenoriznie amit a virtualis gepek hasznalnak, tehat a bond0
> es a bond0.vlanN egy halozatban kell legyen, amihez viszont ahogy en
> latom bridge (kabel) kell....
Megint nem ertem. a bond0 a nativ vlan-ban van, ami tipikusan az 1-es
szokott lenni, es kultur ember managementen kivul masra nem is hasznalja.
Udv,
-=Lajbi=-----------------------------------------------------------------
LAJBER Zoltan Szent Istvan Egyetem, Informatika Hivatal
HTH=Hope This Helps, YMMV=Your Mileage May Vary, HAND=Have A Nice Day
_________________________________________________
Miloska <miloska@gmail.com>
>
> en azt szoktam csinalni xen-el, hogy az eth0 a domu-hoz megy, semmi mas.
> Az eth1 standard modon a belso szerver halo ,az eth2 a dmz. Ha kell, akkor
> egy-egy speci eszkoz (nyomtato szerver, dhcp/dns szerver) meg megkapja
> fizikailag az eth3-at, e azon annyi vlan huzok fel a domU-ban, amennyi
> kell.
>
Igy switch hiba eseten kiesik a belso halo/dmz/ami eppen azon az if-en jon.
>
> Megint nem ertem. a bond0 a nativ vlan-ban van, ami tipikusan az 1-es
> szokott lenni, es kultur ember managementen kivul masra nem is hasznalja.
Ebben az esetben a management is publikus IP-n zajlik, nyilvan tuzfalazava.
A gateway mar nem az enyem. Ket drotot kapok amin fut STP es a vegen
(gondolom HSRP-vel) a gateway IP cime.
Szerintem alap esetben azt lenne erdemes ellenorizni, hogy az a
gateway elerheto-e => bond0 -nak latnia kell a GW-t
(Amennyire tegnap kiteszteltem a bond0-nak raadasul nem is eleg
akarmilyen IP, egy IP tartomanyba kell esteni a ARP keres
celpontjaval. Ebben en sok logikat nem latok, ha jol gondolom magahoz
az ARP kerdeshez-valaszhoz IP cim sem kellene az adott interface-re,
de megis igy van.)
A virutualis gepeknek publikus IP cimek kellenek a szolgaltatasokhoz
=> a bridge-nek is 'latnia' kell a GW-t => bond0.vlanY-nak is 'latnia'
kell a GW-t.
Meg azt lehetne, hogy csinalni management VLAN-t es oda valami VPN-t,
de eddig ez nem merult fel, duplan megtuzfalazott (dedikalt firewall +
iptables a szerveren) SSH megfelelo volt.
Lajber Zoltan
On Thu, 29 Oct 2009, Miloska wrote:
> Igy switch hiba eseten kiesik a belso halo/dmz/ami eppen azon az if-en jon.
Igen. De redundans tap es engine van a switcben, a ket tap kulon-kulon
ups-re dugva (nem, nem 2960-as :)
> A gateway mar nem az enyem. Ket drotot kapok amin fut STP es a vegen
> (gondolom HSRP-vel) a gateway IP cime.
A HSRP/VRRP L3 dolog, ahhoz neked nem kell 2 drot.
> (Amennyire tegnap kiteszteltem a bond0-nak raadasul nem is eleg
> akarmilyen IP, egy IP tartomanyba kell esteni a ARP keres
> celpontjaval. Ebben en sok logikat nem latok, ha jol gondolom magahoz
Megint nem ertem. A bond l2 dolog, nincs ip. Lehet ip-t adni persze a bond
if-nek, attol lehet l3.
> A virutualis gepeknek publikus IP cimek kellenek a szolgaltatasokhoz
> => a bridge-nek is 'latnia' kell a GW-t => bond0.vlanY-nak is 'latnia'
> kell a GW-t.
Nagyon nem ertem. Rajzolni kellene... :)
Udv,
-=Lajbi=-----------------------------------------------------------------
LAJBER Zoltan Szent Istvan Egyetem, Informatika Hivatal
HTH=Hope This Helps, YMMV=Your Mileage May Vary, HAND=Have A Nice Day
_________________________________________________
Gabor Gombas
On Thu, Oct 29, 2009 at 10:56:02AM +0000, Miloska wrote:
> Mukodik, amig a bond0 interface nincs bridge-ben, csak a VLAN
> al-interface-ek (bond0.vlanY).
Hmm. Nem vagyok halozati szakerto, de ha jol ertelmezem igy
hirtelenjeben a bonding kodot, akkor igy nez ki az ARP kuldes:
- routing table alapjan megkeresi, melyik device-on kellene kikuldeni az
ARP kerest
- ha a route magara a bond device-ra mutat, akkor siman elkuldi
- ha a route a bond device-n beluli VLAN-ra mutat, akkor "kezzel"
megtaggeli es ugy kuldi el
- egyebkent panikba esik
Namost ha a bond0-nak nincs IP cime viszont benne van egy bridge-ben,
akkor a route a bridge-re fog mutatni, amirol a bonding driver-nek
persze nincs tudomasa, igy a "panikba esik" pont lep ervenybe.
Tehat az lehet egy megoldas, ha csinalsz egy uj VLAN-t, teszel ra egy olyan
halozatot, amit nem kell bridge-elni, es megfelelo routing magiaval
elered, hogy az ARP keresek ezen a dedikalt VLAN-on akarjanak kimenni
(meg persze hogy a tuloldal is ezen akarjon valaszolni).
Nem neztem tul hosszan a kodot, szoval nem eskuszom meg ra, hogy ez
tenyleg mukodik...
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
Miloska <miloska@gmail.com>
> - routing table alapjan megkeresi, melyik device-on kellene kikuldeni az
> ARP kerest
> - ha a route magara a bond device-ra mutat, akkor siman elkuldi
> - ha a route a bond device-n beluli VLAN-ra mutat, akkor "kezzel"
> megtaggeli es ugy kuldi el
> - egyebkent panikba esik
>
> Namost ha a bond0-nak nincs IP cime viszont benne van egy bridge-ben,
> akkor a route a bridge-re fog mutatni, amirol a bonding driver-nek
> persze nincs tudomasa, igy a "panikba esik" pont lep ervenybe.
>
Ez osszecseng azzal amit en 'kimertem' tegnap.
> Tehat az lehet egy megoldas, ha csinalsz egy uj VLAN-t, teszel ra egy olyan
> halozatot, amit nem kell bridge-elni, es megfelelo routing magiaval
> elered, hogy az ARP keresek ezen a dedikalt VLAN-on akarjanak kimenni
> (meg persze hogy a tuloldal is ezen akarjon valaszolni).
>
Igen, ez jonak tunik.
Nalam konkretan nem lesz jo szerintem, mert a gateway, amit erdemes
lenne ellenorizni az egy access porton jon be (1 VLAN) es ezt a VLAN-t
bizony kell bridge-elni. Ha a gateway is az enyem lenne akkor lehetne
megegy VLAN-t belekavarni a rendszerbe csak az ARP keresekre, ez az
amit te irtal.
Ezzel egyutt nem latom, miert hasznal barmi L3 informacio a bond ARP
ellenorzese, miert nem eleg neki a L2...mondjuk ez mar inkabb csak
felhangos bosszankodas :)
Miloska <miloska@gmail.com>
>> A gateway mar nem az enyem. Ket drotot kapok amin fut STP es a vegen
>> (gondolom HSRP-vel) a gateway IP cime.
>
> A HSRP/VRRP L3 dolog, ahhoz neked nem kell 2 drot.
STP-hez kell.
>
> Megint nem ertem. A bond l2 dolog, nincs ip. Lehet ip-t adni persze a bond
> if-nek, attol lehet l3.
Elmeletben.
Tegnap en mast tapasztaltam, ha nincs a bond0-n IP cim nem mukodik az
ARP ellenorzes. En sem ertem, megnezem megegyszer, lehet, hogy valamit
rosszul ertelmeztem.
Esetleg valakinek van mas teszt eredemnye? Uzemeletet barki ugy
bond-ot, hogy nincs IP cime? (kozben megjott Gabor levele)
>
>> A virutualis gepeknek publikus IP cimek kellenek a szolgaltatasokhoz
>> => a bridge-nek is 'latnia' kell a GW-t => bond0.vlanY-nak is 'latnia'
>> kell a GW-t.
>
> Nagyon nem ertem. Rajzolni kellene... :)
>
Legalabb nem vagyok egyedul... :)
Ferenc Wagner <wferi@niif.hu>
> Beallitas szempontjabol egyszerubb lenne, ha a peth0 es peth1 lenne
> bondingban, es a bond0.vlanY interfaceket raknad vlanonkent kulon
> bridge-be (brvlanY), es ide tenned be a virtualis gep egyetlen
> interface-et. Ennek tobb elonye van az elozo megoldashoz kepest:
> -fele annyi bridge-ed van
> -nem kell STP-vel bajlodnod
> -nem kell bondingal bajlodni a virtalis gepeken.
>
> De ha jol ertettem, neked indulaskor ez nem mukodott...
Ja, vagy úgy... Nekem ez jól bevált, mondjuk mii monitoringgal és
külön switch-ekbe kötve.
--
Feri.
Ferenc Wagner <wferi@niif.hu>
> Ha tobb virtualis gep van mas-mas vlanban, akkor vlan-onkent kell egy-egy
> linux bridge. Ezekbe a fizikai interface megfelelo vlan subinterface-e
> kerul, es a virtualis gepek e celra szolgalo interface-e. Ezek nem
> subinterface-ek, hanem dedikaltak adott vlan-hoz.
> Kicsit regi xen-es terminologiaban tehat a bre0vlan100-ba kerul a
> peth0.100, es a virt. gep eth0-ja. A bre1vlan100-ba kerul a
> peth1.100, es a virt gep eth1-e. A virt. gepen bondingolod az eth0 es
> eth1-et.
Ez miért jobb, mintha a fizikai interfészeket bondolnád a dom0-ában,
és a bond0.100-at tennéd a br100-ba a virtuális gép egyetlen
interfészével együtt?
--
Feri.
Miloska <miloska@gmail.com>
>
> Ja, vagy úgy... Nekem ez jól bevált, mondjuk mii monitoringgal és
> külön switch-ekbe kötve.
> --
Koszonom midenkinek az otleteket!
Az alap kerdesemre a valasz hatarozott nem, az en feltetelimmel nem
lehet ezt megoldani a tudomany jelenlegi allasa szerint.
A felhozott megoldasokat letesztelem aztan kitalalom melyik lesz a
legjobb nekem.
Udv