Na něco, co funguje, se přece zásadně nešahá. :-)
Jinak varianta 2) nebude dělat co chceš. I když RB bude opožděno o 10 sec, tak co mám vyzkoušeno, tak stejně nějaký klient nakonec dostane adresu od záložního routeru a ne primáru. A navíc, kdo dostane IP od záložního DHCP, tak se ho bude držet jak sopel, prootže při vypršení leasu se snaží primárně snaží kontaktovat přímo původní DHCP server a pokud tne bude odpovídat, tak si bude držet IP od něj. A budeš mít v LAN po čase slušný chaos. Vyzkoušeno. :-)
To by to záložní DHCP musel úplně ztichnout, když jede primár. MKčku chybí funkce pro spolupráci DHCP serverů a synchronizaci, případně HA mezi sebou.
Varianta 3) RBčko s Linuchem propojíš VLANou přes kteoru jde provoz přímo do netu jako teď, na RB hodíš další VLAN nebo ether port, který bude přímo na LAN, třeba ta 10.10.10.0/24. Na linux na ethX dáš IP 10.10.10.1/24, na MKčko na etherX 10.10.10.2/24. Dále pustíš na MKčku VRRP nad etherX, stejně tak si pustíš na linuxu vrrpd nebo keepalived nad ethX s tím, že budou držet IP 10.10.10.254/32, adresa .254 bude defualt brána ven. DHCP pustíš na linuxu i MKčku se stejným nastavneím, jenom pro dynamick přidělované rozsahy dáš třeba, ať linux přiřazuje z bloku 10.10.10.32/27 a MKčko jako pool má 10.10.10.64/27. Statikcé přiřazení a spol musíš dát stjeně do obou, jako DNS jim dáš tu 10.10.10.254. Pokud máš v LAN počtač,e které dělají hlubší analýza paketů, dělají to iněkteré antivir balíky, tak možná bude třeba vypnout na nich ARP inspekci, aby se dostaly do Inetu.
MKčko bude NATovat jen to, co přileze přímo z 10.10.10.0/24.
