Administrace komentářů

OK, tak uz jsem trosku moudrejsi, akorat stale ne dostatecne

Wireshark na vnetx nebo primo na bridgi nedelal zadny rozdil, ale rikam si fajn, vsechno to rozbiju a pojedu znovu.

A dostal jsem se do celkem vtipne situace, opet, pres nmtui vytvoreny bridge br0 a VM povesene na dany bridge.

Tedka mi pro zmenu virtualky v bridgi pri startu pfSense, kdy pfSense zacne konfigurovat rozhrani, proste zmizi...

Z dmesg | grep br0 hypervisoru:

Spoustim CentOS VM:

br0: port 1(vnet0) entered blocking state

br0: port 1(vnet0) entered disabled state

br0: port 1(vnet0) entered blocking state

br0: port 1(vnet0) entered forwarding state

vsechno cajk dle ocekavani.

Spoustim pfSense VM:

br0: port 2(vnet1) entered blocking state

br0: port 2(vnet1) entered disabled state

br0: port 2(vnet1) entered blocking state

br0: port 2(vnet1) entered forwarding state

pfSense startuje a zacina nastavovat interfacy, mezitim v dmesg:

br0: port 1(vnet0) entered disabled state (mi to sestrelilo i sit z te CentOS VM?!)

br0: port 2(vnet1) entered disabled state (a tady to odstrihne i sebe; fyzicka rozhrani se na pfSense vsak bezi v poradku)

... a proste schluss.

Tak pro zmenu mudruju, proc se deje tady todle.

Loop tam nikde neni a chtelo by to fakt hodne kreativity jej dokazat vytvorit, takze STP je na tom bridgi neaktivni, nicmene jeho zapnuti na zkousku nemelo zadny vliv.

Ted uz ale mam aspon funkcni workaround. Po startu pfSense staci pustit

brctl addif br0 vnet0 vnet1

a najednou je vsechno azuro...

Tak prinejhorsim si holt udelam nejakej skript na autostart virtualek s pevnym cekanim dvou minut, nez porty do bridge rucne prida a bude, ale ... prece to musi mit nejakej duvod, ze se todle deje...?