Mikrotik, routeros, policy routing

Hálózatok általános

Üdv mindenki,

A cégnél van két vonalunk. A cél az, hogy a hálózatunkból kb. mindent a "fő" vonalon, de bizonyos IP címeket egy "másik" vonalon érjenek el a kollégák.
A ***.***.129.158 az a "másik" vonalon lévő gateway, a "fő" vonalon a ***.***.55.254 a gw, két nagyon más hálózat.

Amit csináltam:

- Felvettem a kivételezett címeket (tartományokat) egy address list-be, az ip firewall address-list print szépen mutatja is.
- A preroutingban teszek rá egy cetlit (chain=prerouting action=mark-routing new-routing-mark=ToExample passthrough=no src-address=**.**.32.0/19 dst-address-list=Example)
- A route-ok között "másik" vonalra pöckölöm a forgalmat (dst-address=0.0.0.0/0 gateway=***.***.129.158 gateway-status=***.***.129.158 unreachable distance=1 scope=30 target-scope=10 routing-mark=ToExample)
- ÉS ki is van natolva (chain=srcnat action=masquerade routing-mark=ToExample src-address=**.**.32.0/19 src-address-type=!local out-interface=P2-Uplink2)

Ez még akár jó is lenne. A traceroute látszik hogy pl. az index felé a "fő" vonalon megy, az Example listában lévő címek felé viszont a "másik" vonalon megy.

De.

Nem megy pl. a Lync/Skype for business. Az SSH megy, de rettentően lagol. (Maga a vonal kb. üres, ha egy mezítlábas TP-Linken át megyek, akkor semmi gond). A ping nem látszik hogy lagolna, és most jut eszembe hogy nézhettem volna nagyobb csomaggal is (MTU?), de most visszaépítettem az eredeti konfigot, mert megint kell nekik.

A gateway-status azért unreachable, mert már visszaépítettem a vonalat az eredeti routerbe (a mezítlábas TP-Link), természetesen egyébként remek.
Kapcsolgattam a passthrough-t yes/no között, nem láttam érdemi változást.
Ethernet szinten nézve az első két port az uplink, egyik sincs rajta semelyik bridge-en. A harmadik port a belső, az egy külön bridge egyetlen tagja.
VLAN még nincs.

Mi lehet a nyomora? Mit felejtettem ki? Lehet hogy csak holnap reggel tudok megint foglalkozni vele, mert lehet hogy dolgoznának addig a "másik" vonalon is.

  • 1354 megtekintés

( bennyh | 2018. 09. 17., h – 14:18 )

Hűha, nagy a katyvasz. Én mindkét irány felé használok egy-egy routing mark-ot (to_ISP1 és to_ISP2).
Először is megjelölöm a lehetséges befele irányuló új kapcsolatokat connection mark-kal, aszerint melyik WAN vonalon jöttek (pl from_ISP1_conn, from_ISP2_conn).
Jöhetnek a kifele irányuló kapcsolatok.
A megfelelő IP címek/portok felé irányuló új kapcsolatokat is ugyanígy megjelöljük (ide jönnek a kivételek és a PCC).
Ha a kapcsolatok meg lettek jelölve, jöhetnek maguk a kapcsolatokhoz tartozó kimenő csomagok.
Az adott kapcsolathoz tartozó kifele menő(!!!, ha a WAN felöl jövő csomagot is megjelöljük, még képes a mocsok visszaküldeni a feladónak :D) csomagokra (pl a LAN felöl jövőkre) rátesszük a megfelelő routing mark-ot.
Ha nem akarunk minden kapcsolatot megjelölni, az a lényeg, hogy legyen egy általános route szabály, ami megmutatja az alapértelemzett átjárót, valamint még két route szabály, hogy melyik routing mark melyik WAN vonalat jelöli. Itt meg lehet és meg is kell majd bonyolítani, ha szeretnénk egy failover mechanizmust. Elvileg működhet a dolog külön ütemezett script nélkül is, de nem sikerült összehoznom, hogy két címmel is csekkolja, hogy adott WAN vonal tényleg működik-e (ha se a 8.8.8.8 sem az rs1.bix.hu IP címe nem érhető el, akkor valszeg azon WAN vonalon át már semmit nem érsz el az internetből, a másodlagos WAN-t meg 8.8.4.4-el és rs2.bix.hu IP címével tesztelem)

"Az adott kapcsolathoz tartozó kifele menő(!!!, ha a WAN felöl jövő csomagot is megjelöljük, még képes a mocsok visszaküldeni a feladónak :D) csomagokra (pl a LAN felöl jövőkre) rátesszük a megfelelő routing mark-ot."

Igen, ezt megcsináltam.

"Ha nem akarunk minden kapcsolatot megjelölni, az a lényeg, hogy legyen egy általános route szabály, ami megmutatja az alapértelemzett átjárót"
Az is van.

"valamint még két route szabály, hogy melyik routing mark melyik WAN vonalat jelöli."

Áhm, na ezt nem értem. Ha jól látom, akkor itt csak egy plusz route-ot tesz fel, mert amint nincs mark, az úgyis megy a "rendes" default route felé.

A te megoldásod akkor ha jól értem annyi, hogy mindenképpen teszel rá mark-ot, egyet ha illeszkedik a feltételre, és egyet akkor, ha nem. Így van? És akkor lehet hogy ezért van neked több route-od.

Én súlyozott terheléselosztást hoztam létre, 2 PCC szabály helyett 5-öt csináltam, 5/0,5/1,5/2,5/3,5/4-es Per Connection Classifier-rel, amiből az első három szabály az ISP1 felé terel az utolsó 2 meg az ISP2 felé. Érdemes a forrás és a cél IP cím szerint is osztályozni az összes kapcsolatot, ha meg fontosabb a megbízhatóság a hatékonyabb kihasználtságnál és nincs proxy szerver, akkor csak forráscím alapján, ilyenkor a kliens gépeket osztja automatikusan a két csoportba.

Nham, összeállt. Kicsit megzavart, hogy pont a PCC részt kell kihagyni.

Működik. Ugyanúgy, mint az első. Az ssh lagol mint az állat, mást (pl. a Lync-et) most nem tudok tesztelni. Érdemben már csak holnap tudok foglalkozni vele, gyanús, hogy a policy routingtól független valami lesz a baj.

Nem olyan nagy katyvasz ez, csak valóban:

- A connectiont mark-old kifelé feltétel alapján
- Szintén a connection-t befelé, ha 2nd WAN-ról jön
- AZTÁN a packet-eket a connection mark alapján routing mark-old

Ennek mennie kell akkor is, ha csak a kivételeket tereled a 2nd route-ra, minden más megy default-ban.

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

( csabka v | 2018. 09. 17., h – 17:11 )

egy kérdés, miért nem csinálsz egyszerűen arra a néhány dst IP-re (vagy tartományokra) static route-ot az ISP2 felé és kész.
már ha jól értettem a feladatot, hogy bizonyos távoli szervereket az ISP2 felé szeretnél terelni IP alapján.

Persze minden szerszám előbb utóbb kalapács :-) így a mangle is sok dologra jó, de néha az egyszerűbb jobb megoldás.

Ha pedig teljes szétválasztás kell akkor másik topicban már írtam VRF-es javaslatot (persze ez elég speciális igény volt): https://hup.hu/node/160431

Én úgy vagyok vele, ha már van 2 WAN kapcsolatom, akkor egyik se heverjen parlagon. Ehhez meg már kell a mangle.
Lehetnek olyan spéci esetek, amikor tényleg kizárólagos WAN vonallal jobban járunk, de azért sokszor ilyenkor is egy queue tree-vel be tudjuk úgy szabályozni, hogy a fontos forgalom kapjon elsőbbséget.

PS: ha az illetőnek meg nehéz belőnie ezeket (elsőre nekem se volt könnyű) akkor lehet jobban járt volna Mikrotik helyett egy Draytekkel (de már a TP-Link-nek is régóta van ilyen routere)
Egyiket se bonyolult belőni, a Draytek stabilabb, mi is azt használtuk LB-re, de az megpusztult (8 év után az ethernet portjai bizonytalankodtak, de még mindig van rá frissítés!!!), ROS-sal meg már bűvészkedtem eleget, meg olvasgattam sokat utána, hogyan is működik vele az LB, ezért lett az utódja egy RB760-as router.

PS2: A Draytek tudott olyan üzemmódot, amire ez egyik PH-s Mikrotikes szaki azt írta, hogy ilyen márpedig nem is létezhet sehol semmilyen módon :) , de mások is megerősítettek, hogy Draytekkel biza működik a dolog.