VRRP

lukas-svk

Zdravim, rad by som nasadil VRRP na 2 RB 450G, mam vsak zopar otazok.

V customer subnete nie su volne dalsie 2 verejne IP adresy (wiki MK spomina ze potrebujem okrem virtualnej IP adresy aj dalsie 2 ip adresy 1 kazdemu z tych 2 routrov).

Moja otazka znie, da sa nastavit (ma s tym niekto skusenosti) VRRP na MK tak, ze by som tie 2 ip adresy z rovnakeho subnetu nepotreboval?

Testoval som nasledovnu konfiguraciu (je uplne mimo odporucani ana wiki)

Master: ROS 5.11, RB450G

Backup: ROS 5.11, RB750G

Na otestovanie som zvolil nasledovne subnety: 192.168.1.0/24 - Uplink subnet smerom k ISP, VRRP virtual ip 192.168.1.2 (192.168.1.1 je ISP GW)

192.168.88.0/24 - Customer subnet, VRRP virtual IP 192.168.88.1

Master - RouterA:

> /interface print

Flags: D - dynamic, X - disabled, R - running, S - slave

# NAME TYPE MTU L2MTU MAX-L2MTU

0 R ether1-uplink ether 1500 1520 1520

1 R ether2-downlink ether 1500 1520 1520

2 ether3-local ether 1500 1520 1520

3 ether4-local ether 1500 1520 1520

4 ether5-local ether 1500 1520 1520

5 R vrrp1-uplink vrrp 1500

6 R vrrp2-donwlink vrrp 1500

> /interface vrrp print

Flags: X - disabled, I - invalid, R - running, M - master, B - backup

# NAME INTERFACE MAC-ADDRESS VRID PRIORITY INTERVAL VERSION V3-PROTOCOL

0 RM vrrp1-uplink ether1-uplink 00 1 250 1s 3 ipv4

1 RM vrrp2-donwlink ether2-downlink 00 2 250 1s 3 ipv4

/ip address> print

Flags: X - disabled, I - invalid, D - dynamic

# ADDRESS NETWORK INTERFACE

0 ;;; WAN VRRP Address

192.168.1.2/24 192.168.1.0 vrrp1-uplink

1 ;;; WAN Blind REAL

1.1.1.2/24 1.1.1.0 ether1-uplink

2 ;;; LAN VRRP

192.168.88.1/24 192.168.88.0 vrrp2-donwlink

3 ;;; WAN Blind VRRP

1.1.1.1/32 1.1.1.1 vrrp1-uplink

4 ;;; LAN Blind REAL

2.2.2.2/24 2.2.2.0 ether2-downlink

5 ;;; LAN Blind VRRP

2.2.2.1/32 2.2.2.1 vrrp2-donwlink

/ip firewall nat> print

Flags: X - disabled, I - invalid, D - dynamic

0 chain=srcnat action=src-nat to-addresses=192.168.1.2 src-address=192.168.88.0/24 out-interface=vrrp1-uplink

Backup - RouterB:

> /interface print

Flags: D - dynamic, X - disabled, R - running, S - slave

# NAME TYPE MTU L2MTU MAX-L2MTU

0 R ether1-uplink ether 1500 1520 1520

1 R ether2-downlink ether 1500 1520 1520

2 ether3-slave-local ether 1500 1520 1520

3 ether4-slave-local ether 1500 1520 1520

4 ether5-slave-local ether 1500 1520 1520

5 vrrp1-uplink vrrp 1500

6 vrrp2-downlink vrrp 1500

/interface vrrp> print

Flags: X - disabled, I - invalid, R - running, M - master, B - backup

# NAME INTERFACE MAC-ADDRESS VRID PRIORITY INTERVAL VERSION V3-PROTOCOL

0 B vrrp1-uplink ether1-uplink 00 1 100 1s 3 ipv4

1 B vrrp2-downlink ether2-downlink 00 2 100 1s 3 ipv4

/ip address> print

Flags: X - disabled, I - invalid, D - dynamic

# ADDRESS NETWORK INTERFACE

0 ;;; WAN Blind REAL

1.1.1.3/24 1.1.1.0 ether1-uplink

1 ;;; WAN VRRP

192.168.1.2/24 192.168.1.0 vrrp1-uplink

2 ;;; LAN VRRP

192.168.88.1/24 192.168.88.0 vrrp2-downlink

3 ;;; WAN Blind VRRP

1.1.1.1/32 1.1.1.1 vrrp1-uplink

4 ;;; LAN Blind REAL

2.2.2.3/24 2.2.2.0 ether2-downlink

5 ;;; LAN Blind VRRP

2.2.2.1/32 2.2.2.1 vrrp2-downlink

/ip firewall nat> print

Flags: X - disabled, I - invalid, D - dynamic

0 chain=srcnat action=src-nat to-addresses=192.168.1.2 src-address=192.168.88.0/24 out-interface=vrrp1-uplink

Na stole to funguje, len treba davat pozor na to aby som si nenatoval aj VRRP pakety (cim by sa prerusila komunikacia medzi routrami a obaja by boli MASTRI).

Ma s tymto niekto skusenosti? Vidi v tom nejake problemy?

Ja vidim akurat jeden, nebudem mat priamu IP konektivitu z customer subnetu na oba routre mimo VRRP (budu tam ale adresy z ineho subentu cez ktore komunikuje to VRRP), co je v principe dostacujuce.

Este dodam ako to v principe funguje: VRRP peerovia komunikuju cez tie blind adresy na fyzickych rozhraniach. Na VRRP je uz dany subnet priamo ktory potrebujem. Podla toho toho ktory je master, ten reaguje na arp requesty, tym prechadzaju pakety, naopak backup dane pakety nespracuva. Ja tu mam nastavene 2 vrrp, 1 smerom na out, 1 smerom k zakaznikovi.

Je to uplne inak nastavene, standardne sa udava ze vrrp by malo byt nastavene nasledovne:

RouterA: na fyzickych rozhraniach: customer subnet IP X

na vrrp rozhran ip zo subnetu X/32

komunikacia potom prebieha medzi vrrp peermi napr 224.0.0.18 -> moja IP zo subnetu X. Takto by vlastne komunikovali cez verejne ip adresy, co je asi zbytocne si myslim, a navyse aj problem pri preplnenom subnete.

S tym mojim nastavenim komunikuju cez nejake blind ip adresy, pretoze celu tu komunikaciu som pochopil ako udrziavanie stavu vrrp rozhrani (Master/Backup). Vedel by ten config niekto skusit v labe, pripadne sa na to pozriet ci tam nevidi nejake zasadne problemy ktore ja nevidim?

Vdaka.

lukas-svk

Tolko odbornikov z oblasti a nikto nezareaguje? No tak nenechajte sa prosit a skuste sa na to mrknut.

Dik.

majklik

Ano, můžeš pro ty základní etherX rozhranní jako podložku pod VRRP použít úplně jiné adresy, než je pak na VRRP rozhranní. Často se to tak dělá úmyslně, aby se předcházelo některým jevům, které ti pak způsobuje, když ether i vrrp jsou ve stejném segmentu (začne se ti třeba uplatňovat ECMP, pokud vede tudy default routa, pokud tomu nepomůžeš jinými prostředky).

Dokonce ani ty IPčka na těch routerech nemusí být na etherX v jednom subnetu a stačí je mít /32 a bude to fungovat.

Pokud je to takováto konfigurace, tak se dá půjčit i IPčko z druhé strany a bude fungovat.

Třeba častá konfigurace je:

spojovací segment k ISP 192.0.2.0/30 (gate 192.0.2.1)

veřejné IPčka poskytnutá do sítě 198.51.100.0/24 (směrováno od ISP na 192.0.2.2)

a nastaví se to takto:

R1-ethet2-lan 198.51.100.1/24

R2-ethet2-lan 198.51.100.2/24

R12-vrrp-lan 198.51.100.254/24 (dafault gate z vnitřku sítě)

R1-ether1-wan 198.51.100.1/32

R2-ether1-wan 198.51.100.2/32

R12-vrrp-wan 192.0.2.2/30

default routa na R1 i R2 míří na 192.0.2.1

Takto to má výhodu, že se ti na WAN straně flákají legální IP, které máš. Když tam dáš nějaký totální úlet (1.1.1.1 atd), tak ti to ISPík může ustřihnout, pokud hlídá jaké IPčka chodí od zákazníka.

Pokud jsi ty ten ISPík, tk si samozřejmě asi nastavíš, co bude vyhovovat zákazníkovi nebo se s ISPíkem zkusíš domluvit. V podstatě by jsi to mohl nastavit obráceně, z WAN strany si půjčit IPčko dovnitř, pokud je na WAN volné.

Dále, máš to VRRP zřejmě na straně, kam ti mlžou chodit nejrůznější cizí pakety, co když ti pošle někdo omylem/úmyslně svoje VRRP? :-) Takže bych použil VRRP verze 2 a zapnul si autorizaci AH a nějaké patřičně náhodný klíč, aby se tomuto předešlo.

Jinak jen takto hole nastavené dvě VRRP jdoucí proti sobě je taková naivní konfigurace a VRRP k ní nebylo úplně zamýšleno používat. V takovéto konfiguraci by tz VRRP by měly být konfigurovány závisle na sobě, což ROS neumí, ale jde k tomu použít trochu skrptování. LAN VRRP priorita by měla být měněna dle toho, který router drží master VRRP na WAN straně, případně to jde vylepšít, že si to i hlídá, zda VRRP master vidí default gate a když ne, tak přehodit na druhý, ale to už je simulace a náhražka za dynamické směrování. Jak to máš v tom demu, tak to řeší jen variantu, že opravdu selže router1 jako celek.

lukas-svk

No vybrone. Dik za reakciu. To co som tu pastol je konfig z labu, pre customera by som to nastavil s AH. :) to je samozrejmost.

Samozrejme presne ako pises, to mala byt druha otazka, az ked sa ktosi chyti .. je jasne ze sa mi moze stat ze M vrrp1 bude na inom routri ako M pre vrrp2 a vtom pripade bude customer odrezany. To skriptovanie nie je bohvie co.. tie grupy rozhrani mohli vazne uz dorobit :)

Este som pre ten pripad rozmyslal nad 1 vlanou medzi oboma routrami, ospf medzi nimi. V pripade ze nastane situacia vyssie, tak to skusit vyriesit cez tu prepojovaciu vlan. Skusim este porozmyslat. Pripadne neskusal si spravit nejake skriptiky?

Dalsia otazka: mozem potom pri tom setupe spravit vrrp iface a nad to stavat vlany? pride mi to lahsie nez nad kazdou vlanou robit vrrp iface, aj ked je to rozdiel pretoze vrrp iface nad kazdou vlanou pokryva aj situaciu kedy nastane prerusenie vrrp komunikacie iba v danej vlan.

Btw, ohladom ECMP... prave preto aby sa mu predislo navrhuju na vrrp rozhranie /32 ipcku.. tym apdom cez vrrp budu chodit len prichodzie pakety a odchodzie pojdu cez subnet v ktorom je gw (/30 a vacsi) je tak?

ECMP by sa uplatnil ak by som mal napr. /24 subnet na ethX a inu IP z daneho napr. /24 subnetu na vrrpX? (toto by asi tiez skomplikovalo fw pravidla na routri ?)

Edit: to skriptovanie: imho potrebujem nie len na zaklade wan ovplyvnovat lan stranu, ale aj opacne, lebo nejaky problem moze nastat aj na lan strane, ak by zmena na lan strane nespustila zmenu na wan, bol by to asi rovnaky pripad.

Dik

majklik

Grupy VRRP se dělají snadno, stačí jeden řádek do master up/down v záložce řídícího VRRP a je to. Viz dále.

VLANa mezi routery pro záložní trasu - když se ti rozhodí VRRP moc neřeší, protože máš šanci, že daná vlan cesta bude ta přes rozbitou síť. Potřebuješ na to přímý propoj routeru R1 a R2 pro obejítí chcíplé trasy (VLANa by šla, pokud by šla současně jako kruh skrz LAN i WAN stranu, což asi nechceš).

Ano, lze VLAN iface umístnít nad VRRP a dle toho, zda řídící VRRP je master/slave jsou dané VLANy povoleny/zakázány. Jde použít proti ISP, pokud souhlasí s VLANou, tak oddělím VRRP bordel od inet provozu. V podstatě mám dva dráty k ISP do jeho switche, inet provoz jde VLAN1 tagován a netagován provoz je povolen jen mezi těmi dvěma porty. V netag běží VRRP a VLAN1 se přepíná na vybraný router a ten vidí internet. Má to jen jednu slabinu, a to změnu MAC adresy, pokud na té přehazovanáé VLAN na obou rouuterech bude stejná IP. Při změně, kde je VLANa aktivní, se ti změní MAC adresa svázaná s tím IPčkem ve VLANě, což může dělat občas chaos. Pokud se jen stěhuje IPčko přímo na VRRP iface, tak se ti stěhuje i virtuální MAC a je to transparentní pro protistranu...

Pokud by těch VLAN měla být stovka, tka pak raději VLAN nad VRRP než VRRP v každé VLANě. Jenom pka pozor na zmíněný artefakt výše. Pokud přímo na té VLANě budou klienti, tak dneska řada antivirů/firewallů při změně MAC adresy default gejtu bude řvát nebo přímo blokovat.

U toho, zda VRRP IP má mít /32 nebo ne záleží přesně na to, jak to chceš použít, obvkyle ano. V některých verzích ROSu blblo za určitých kombinací (pokud i přímo na nositelném Iiface je IP za stejného segmentu a ten je menší než /24).

Jistě, potřebuješ hlídat, zda ti to jede správně na LAN i WAN straně a dle toho to VRRP přehazovat, nebo i nemusíš, pokud se tomu pomůže. Blbé je, že nemáš s jednoduchou konfigurací vždy dostatek informací pro správnou volbou, vždy to bude nějaký kompromis. Záleží, zda chceš překlenou tjen chybu jendoho místa nebo dvou (upadne třeba wan strana na R1 a současně LAN strana na R2 a chci, aby to fungovalo dál a data protekla spojkou).

Pro inspiraci, přihodím vykuchanou verzi konfigurace dvou routerů, které používají VRRP na WAN i LAN straně a snaží se přehazovat master dle nejlepší aktuální volby.

klasika, ether1 = WAN, ether2 = bod-bod propoj R1 a R2 a ether3 = LAN:

/interface vrrp

add arp=enabled authentication=ah disabled=no interface=ether1-wan interval=\

1s mtu=1500 name=vrrp1-wan on-backup="" on-master="" password=Heslo1 \

preemption-mode=yes priority=100 v3-protocol=ipv4 version=2 vrid=101

add arp=enabled authentication=ah disabled=no interface=ether3-lan interval=\

1s mtu=1500 name=vrrp3-lan on-backup="" on-master="" password=Heslo3 \

preemption-mode=yes priority=100 v3-protocol=ipv4 version=2 vrid=103

/ip address

add address=169.254.166.1/32 disabled=no interface=ether1-wan network=\

169.254.166.1

add address=192.168.0.1/30 disabled=no interface=ether2-ptp network=\

192.168.0.0

add address=192.168.1.1/24 disabled=no interface=ether3-lan network=\

192.168.1.0

add address=192.0.2.2/30 disabled=no interface=vrrp1-wan network=192.0.2.0

add address=192.168.1.254/32 disabled=no interface=vrrp3-lan network=\

192.168.1.254

/ip firewall nat

add action=accept chain=srcnat disabled=no dst-address=224.0.0.18 protocol=\

ipsec-ah

add action=src-nat chain=srcnat disabled=no out-interface=vrrp1-wan \

to-addresses=192.0.2.2

add action=src-nat chain=srcnat disabled=no out-interface=ether2-ptp \

to-addresses=192.168.0.1

/ip route

add check-gateway=ping disabled=no distance=1 dst-address=0.0.0.0/0 gateway=\

192.0.2.1 scope=30 target-scope=10

add check-gateway=ping disabled=no distance=10 dst-address=0.0.0.0/0 gateway=\

192.168.0.2 scope=30 target-scope=10

add check-gateway=ping disabled=no distance=10 dst-address=192.168.1.0/24 \

gateway=192.168.0.2 scope=30 target-scope=10

/tool netwatch

add disabled=no down-script="/interface vrrp set vrrp1-wan priority=80" host=\

192.168.1.253 interval=1s timeout=200ms up-script=\

"/interface vrrp set vrrp1-wan priority=100"

/interface vrrp

add arp=enabled authentication=ah disabled=no interface=ether1-wan interval=\

1s mtu=1500 name=vrrp1-wan on-backup=\

"/interface vrrp set vrrp3-lan priority=90" on-master=\

"/interface vrrp set vrrp3-lan priority=110" password=Heslo1 \

preemption-mode=yes priority=90 v3-protocol=ipv4 version=2 vrid=101

add arp=enabled authentication=ah disabled=no interface=ether3-lan interval=\

1s mtu=1500 name=vrrp3-lan on-backup="" on-master="" password=Heslo3 \

preemption-mode=yes priority=90 v3-protocol=ipv4 version=2 vrid=103

/ip address

add address=192.0.2.2/30 disabled=no interface=vrrp1-wan network=192.0.2.0

add address=192.168.0.2/30 disabled=no interface=ether2-ptp network=\

192.168.0.0

add address=192.168.1.2/24 disabled=no interface=ether3-lan network=\

192.168.1.0

add address=169.254.166.2/32 disabled=no interface=ether1-wan network=\

169.254.166.2

add address=192.168.1.254/32 disabled=no interface=vrrp3-lan network=\

192.168.1.254

/ip firewall nat

add action=accept chain=srcnat disabled=no dst-address=224.0.0.18 protocol=\

ipsec-ah

add action=src-nat chain=srcnat disabled=no out-interface=vrrp1-wan \

to-addresses=192.0.2.2

add action=src-nat chain=srcnat disabled=no out-interface=ether2-ptp \

to-addresses=192.168.0.2

/ip route

add check-gateway=ping disabled=no distance=1 dst-address=0.0.0.0/0 gateway=\

192.0.2.1 scope=30 target-scope=10

add check-gateway=ping disabled=no distance=10 dst-address=0.0.0.0/0 gateway=\

192.168.0.1 scope=30 target-scope=10

add disabled=no distance=1 dst-address=192.168.1.0/24 gateway=ether3-lan \

scope=30 target-scope=10

add check-gateway=ping disabled=no distance=10 dst-address=192.168.1.0/24 \

gateway=192.168.0.1 scope=30 target-scope=10

Zjendodueně, na WAN straně je segment 192.0.2.0/30, kde ..1 je ISP a ...2 je router, tento segment cestuje s VRRP na WAN straně. VRRP podklad používá link-local adresy 169.254...

Na LAN straně klasika 192.168.1.0/24, kdy .254 je gate hlídaná pomocí VRRP. Dále je odkazováno na IP 192.168.1.253, což je nějaký cluster server a IP by měla vždy jet, slouží k testování, zda R1 vidí do LAN (pomoci netwatch), když ne, tak změní VRRP na WAN tak, aby to přepadlo na R2.

Dále, pokud R2 zíáská master VRRP na WAN straně, tak změní prioritu VRRP LAN strany tak, aby i LAN strana přešla na L2, pokud to jde. IPčko defualt gate u ISP se hlídá pomocí pingu, pokud nepojede, tak nebude aktivní a provoz se pokusí poslat spojkou k druhému routeru, zda bude mít štestí on. Podobně se případně pošle i LAN provoz do kříže (tohle by šlo vylepšit o použití OSPF, aby při trátě wan nebo LAN strany obou routerů něbehaly pakety tou spojkou tam sem do chcípnutí TTL). Tahle šílenost funguje s tím, že VRRP je píchnuto přímo nad etherX, pokud to dáš nad bond nebo bridge, tak už nebude fungovat to odpadávání rout.

majklik

Add to použití VRRP a nad ním VLANy. Zjistil jsem, že tohle mi funguje v RB1100/AH/x2. Nefunguje to na mipsových RBčkách. Tam to nastavit jde, ale do VLAN se přes VRRP data dostnaou, z VLANy k podložnému Ethernetu ne.

Je otázka, zda to vůbec mělo někdy fungovat (a na PPC je náhoda, že to jde) nebo je to chybička u mipsové verze. :-)

lukas-svk

ja mam vyskusane vrrp nad vlan interfejsom na rb450g a tam to funguje

majklik

VRRP nad VLAN funguje, čili něco takovéhoto:

etherX

vlanA vrrpA

vlanB

vrrpB

vlanC

vrrpC

Problém dělá konstrukce

etherX

vrrpX

vlanA
vlanB
vlanC

Pokud mám těch vlan pár desítek a více, tak druhé je příjemnější, že ušetřím tunu VRRP blázince, ale fungovalo mi jen PPC platformě, na MIPSu ne . Po pravdě to nebylo dáváno nad ether přímo, ale je pod tím bud brige mezi dvěma ether nebo bond mezi dvěma ether.

lukas-svk

aha vlan rozhrania nad vrrp rozhranim .. to som neskusal, najma kvoli faktu ze toto nepokryva konfiguracny mistake na eth rozhrani (ina nativna vlana na oboch stranach) => odpojene vsetky user vlany. Ale suhlasim ak tych vlan je vela, asi je to jednoduchsia cesta. Vyskusam, dam vediet....