Tråd: WAN / 3G failover test med 2st UMR'er
Testade precis nya firmwaren och WAN / 3G failover funktionen.
Setupen består av.
2st UMR'er med senaste Beta firmwaren.
2st Abonnemang Tele2 och Tre
2st Modem Huawei E220 och Option Icon 7.2
1st RJ45 nätverkskabel.
Primära internet källan angav jag som UMR'en med Option modemet och Tre abb.
Kopplar från en LAN port på den till WAN port på den andra UMR'en.
Ställde om ip spannet på 1'an så de inte skulle krocka med 2'an ex. "192.168.200.1".
Notera att den går mot 192.168.200.1 dvs går vidare till den som agerar "ethernet".
Tracing route to ping.sunet.se [192.36.125.18]
over a maximum of 30 hops:1 1 ms <1 ms <1 ms UMR.*.local [192.168.0.1]
2 1 ms 1 ms 1 ms 192.168.200.1
3 412 ms 351 ms 378 ms 10.66.46.2
4 407 ms 500 ms 408 ms 10.66.38.42
5 337 ms 499 ms 439 ms 10.66.96.2
6 398 ms 499 ms 400 ms 80.251.201.186
7 327 ms 371 ms 477 ms netnod-ix-ge-b-sth.sunet.se [194.68.128.19]
8 375 ms 390 ms 539 ms c1sth-ae3.sunet.se [130.242.82.193]
9 457 ms 389 ms 380 ms ping.sunet.se [192.36.125.18]Trace complete.
Efter ha dragit ut nätverkssladden så kopplar den då upp mot sitt egna modem.
Tracing route to ping.sunet.se [192.36.125.18]
over a maximum of 30 hops:1 <1 ms <1 ms <1 ms UMR.*.local [192.168.0.1]
2 290 ms 377 ms 369 ms 130.244.219.2
3 293 ms 409 ms 339 ms avk3-dr-1.tengigabiteth9-3s300.swip.net [130.244.219.1]
4 282 ms 349 ms 339 ms avk1-dr-1.tengigabiteth9-1.swip.net [130.244.194.245]
5 274 ms 349 ms 331 ms avk-ncore-1.tengigabiteth2-3.swip.net [130.244.194.233]
6 287 ms 359 ms 358 ms avk-core-1.gigabiteth9-0-0.swip.net [130.244.52.121]
7 293 ms 368 ms 349 ms netnod-ix-ge-b-sth.sunet.se [194.68.128.19]
8 284 ms 361 ms 378 ms c1sth-ae3.sunet.se [130.242.82.193]
9 304 ms 369 ms 411 ms ping.sunet.se [192.36.125.18]Trace complete.
Så det fungerar helt enkelt!
Min lilla setup gör att ifall ena operatörern strular till det så går den över till andra vilket resulterar i minimal nertid.
En sak att lägga till är att så länge WAN kopplingen fungerar så är modem nr 2 i "sov läge", dvs inte uppkopplad och kopplar inte upp sig förens kopplingen dör på ethernet delen.
Och nertiden är nått i stil med 60-90 sek beroende på vart i intervallen det falerar då pingen ligger på 1 min internvall som minst.
Och efter den märket att det inte går så skall den koppla upp.
Hur det funkar i praktiken med DNS'er osv när applikationer är i full gång med koppling mot nätet om man kanske borde köra en /flushdns för att få in ny info.
Noterade att mina ping och traceroute rutor inte ville forstätta trotts att kopplingen hade kommit igång igen och att jag kunde surfa.
När jag stängde alla cmd rutor och öppna nya och körde samma commando så funka det fint.
Så antagligen låser sig cmd rutan till en viss utväg, t.ex. "192.168.200.1" och när den slår över till den andra externa ip'n exempel "130.xxx.xxx.xxx" så förstår den inte.
Men det är ett lokalt problem eller limit i windows.