sitA -- eth0 PC1 -- tap0 -------- tap0 PC2 eth0 -- sitB
I I
I tap1
I I
I I
I I
I I
I tap1
I I
I -------- tap0 PC3 eth0 ---sitC
přičemž brigde jsou následovně:
PC1 : eth0 + tap0
PC2 : eth0 + tap0 +tap1
PC3 : eth0 + tap0 +tap1
s jednoduchou konfigurací v interfaces
iface br0 inet dhcp
bridge_ports eth0 tap0 tap1
bridge_fd 9
bridge_hello 2
bridge_maxage 12
bridge_stp on
PC1 je openvpnserver proti PC2 a PC3 klientu
PC2 je openvpn server proti PC3 klentu
Tak a teď problém - site B a C (jednotky ks PC) mají mezi sebou infrastrukturu které rychlost se náhodně (párkrát denně) mění tak že je buď několikrát rychlejší nebo naopak několikrát pomalejší než spoje A-B a A-C. (optimální cesta mezi BC vede buď napřímo nebo přes A)
Hlavní síť A (stovky ks PC) má pomalou linku k síťím B a C a rád bych jí ulehčil o přímou komunikaci mezi sítěmi B a C pokud mezi nimi v ten okamžik bude linka rychlejší.
Píši sice sítím, ale vzhledem k tomu že se jedná o L2 topologii tak je to stále síť jedna kde PC1, PC2, PC3 jsou jen "geograficky vzdálené porty virtuálního switche".
Převod na L3 nepřichází do úvahy, běží tam i jiné než TCP/IP protokol.
Jediné co mne napadá je zrušit stávající bridge nad vpn spoji, nahodit nad vpn spoji A-B-C (tapx.y rozhraní) dva vlany (jeden pro provoz +měření odezvy a druhý jen měření odezvy), teprve nad nimi bridge, povolit stp, path costy poladit aby provoz ve vlanech chodil v zájemně reverzních směrech a na základě měření odezvy (+-, závislé i na vytížení) přehazovat pomocí změny parametrů stp směr provozu na vlanech.
Nějaký lepší nápad ? Něco s menším overheadem?