Protože piješ špatnou značku. :-( Ale pokud to musí být, tak viz příloha. :-)
Zkrátka APčka nemá připojení do něčeho, co routuje, ale na bridge a pokud to má pobastleno na UBQT, který neumí routovat, tak má problém, jak se vypořádat s tím, když mu chcícpne třeba propoj mezi bridge A a bridge B. Podobně, když chcípne propoj mezi router 1 a bridge C.
Pak se mu hodí to použití VRRP pro přetažení default routy na druhou stranu.
Jinak, pokud tam má něco, co neumí routovat a není ochoten to vyhodit a dát tam něco jiného, tak cesta nejmenšího odporu a funkčnosti je PPPoE.
Klienti budou mít aktivného PPPoE klieta, PPPoE servery poběží na iface routerů 192.168.1.1 a 192.168.7.1. Klienti tam dostanou IP jiné, než 192.168.1.0 a 192.168.7.0 (třeba něco z 100.64./10).
Na roputeru 2 běží jednoduchý ping test na obě strany, zda je dostupný 192.168.1.1 a 192.168.7.1, pokud ano/ne, tak zakáže/povolí PPPoE server na ifacech 192.168.1.8 a 192.168.7.40.
Na kruhu běží klasické OSPF, který bude pasivně redistribuovat IPčka z PPPoE serveru.
Klienti normálně budou viset na PPPoE serveru blíže k hlavní bráně, když se mu v bridge síti něco rozbije, tak se pustí PPPoE i na druhé straně bridge segmentu, takže klienti přilezou na něj, když ten provní už nbeuslyší, bez problému mu to pojede i v případě, že se rozpadne spoj mezi btrigeA a bridgeB, když na bridgeA budou viset také klienti, stejně jak na bridgeB, část klientů pak pobere PPPoE server na hlavní bráně, část na router2. OSPF zařídí, aby se správné klientské IP/32 adresy dostaly ke správnému PPPoE serveru nějakou existující cestou. KDyž s emu bridge část správí, tak vzdálený PPPoE server se shodí a klieti se vrátí na tne blíže vrcholu. NAT má jen jeden na hlavní bráně IP klienta se nemění, ať přiteče kudikoliv. Nic lepšího asi nevymyslí, pokud nechce ty bridge body předělávat. :-)
