-
Fototrend
Mikrotik routerekkel foglalkozó téma. Mikrotik router típusok, hardverek, router beállítások, programozás (scriptek írása), frissítés, és minden Mikrotik routerrel kapcsolatos beszélgetés helye.
Új hozzászólás Aktív témák
-
mrots
junior tag
válasz
stopperos
#24505
üzenetére
"A Bridge > VLANS oldalon pedig felveszed a 100-as VLAN-t, tagged a bridge, sfp1; untagged az sfp8."
Szeretnem megkerdezni, hogy miert lenne tagged az sfp1? A szolgaltato valoszinuleg nem ad vlan taget a beerkezo ethernet keretek fejleceben. Szerintem az sfp1 untagged kellene hogy legyen, hiszen sima access port, nincs ott tobb vlan, ugyanugy, ahogy az sfp8. -
#24494
mrots
junior tag
E.Kaufmann
#24493
mrots
junior tag
válasz
E.Kaufmann
#24493
üzenetére
A portszam irrelevans, mivel a wireguardnak nincs dedikalt portszama, csak default van. Ha szolgaltatoi priorizalas okozza (ami csak egy tipp, lehet az, lehet nem) akkor application fingerprint azonositja a forgalmadat, nem a portszam. Tok mindegy melyik porton futtatod.
-
mrots
junior tag
-
#24456
mrots
junior tag
E.Kaufmann
#24455
mrots
junior tag
válasz
E.Kaufmann
#24455
üzenetére
Birnam a kritikat, csak nem ertem...
-
mrots
junior tag
válasz
myk_to
#24447
üzenetére
"free-hdd-space: 0 "
Eleve ac2-t 7.13 vagy fole upgrade-elni szerintem bator dolog. 50-50, hogy belefutsz misztikus problemakba. A torles amit csinalsz okes, de nem segit igazabol, a netinstall gyalulja le ugy a flash-t, hogy tenyleg szabaduljon fel valami hely, de igazabol az is minimalis. Nem is kell nullanak lennie a szabaly helynek problemakhoz, elegendo siman keves szabad hely is, attol fugg milyen beallitasaid, scriptek, naplozas stb vannak.
-
#24453
mrots
junior tag
E.Kaufmann
#24445
mrots
junior tag
válasz
E.Kaufmann
#24445
üzenetére
"Lehet azért rugdosni kifele klienset RSSI alapján (amik utánna nagyobb sanszal mennek át az erősebb AP-ra)"
Az, hogy melyik AP-t valasztja egy vegpont, az mindig a vegpont dontese. Lehet segiteni (802.11k), lehet bedurvulni (RSSI alapjan disconnect) de ha mindket oldal makacs akkor ebbol mukodo halozat ritkan van. -
#24426
mrots
junior tag
lionhearted
#24422
mrots
junior tag
válasz
lionhearted
#24422
üzenetére
Nem tudom miert keresi az SFP+ portot es nem is annyira erdekel, viszont a teny az teny marad: hasznalhat SFP+ -t es tud rezet hasznalni, ha tortenetesen epp azt akarna.
-
#24421
mrots
junior tag
lionhearted
#24417
mrots
junior tag
válasz
lionhearted
#24417
üzenetére
"Lehet én vagyok helikopter, de SFP+ AP-n? Azon nem megy delej."
Az SFP+ csak egy modul. Aminek az egyik opcioja lehet optika, de van RJ45 rez SFP+ modul is, amin megy delej. -
-
mrots
junior tag
válasz
yodee_
#24386
üzenetére
A beacon egy keret, amit 100 ms-enkent kikuld minden access point, ez tartalmazza az SSID jellemzoit, ugy mint az opcionalis SSID nev, titkositasi algoritmusok, tamogatott protokollok, idobelyeg, tamogatott sebesseg ertekek, ilyesmik.
A beacon frame gyakorisaga allithato bizonyos hatarokon belul. Ha az egyik oldal arra panaszkodik, hogy nincs, akkor
- vagy nem lett elkuldve
- vagy nem eleg gyakran van elkuldve
- vagy elkuldve el volt, megfelelo idoben volt elkuldve, de megsem erkezett meg (zavar)En biztos beraknek egy monitor AP-t, amivel sniffelnem, hogy mi tortenik a levegoben akkor, amikor az egyik oldal panaszkodik. Ha van tobb, akkor tobb monitor AP-t is, egyet kozel a forrashoz, egyet kozel a vevohoz es ket kulon tcpdump-ot osszehasonlitanek. Ezzel lehet igazolni, hogy a vevo azt hallja-e amit a kuldo kuld, innen pedig latszik, hogy mi a hiba, ha nem.
-
mrots
junior tag
-
mrots
junior tag
válasz
grabber
#24351
üzenetére
Valoszinuleg o csak a bentrol kezdemenyezett forgalomra gondolt, ahol a visszatero forgalom kezelese trivialis. Nem gondolt a kintrol kezdemenyezett forgalomra, ahol a visszatero forgalom kezelesehez marking vagy egyeb routing szabalyok szuksegesek. Mondjuk ezt meg mindig nem hivnam szkriptelesnek, csak tuzfal szabalynak.
-
#24226
mrots
junior tag
Alteran-IT
#24224
mrots
junior tag
válasz
Alteran-IT
#24224
üzenetére
"Számomra ez még mindig egy modernebb dizájn elem, ami olyan elvárás is lenne egy komolyabb router esetén mint opció"
A csapatom durvan 3500 halozati eszkozt uzemeltet. Nem csak, hogy jogosultsaguk sincs bemenni az adatkozpontok egyikebe sem (nem nyitja a kartyajuk, az enyem sem) de biztosan tudom, hogy van koztuk legalabb 6-7 olyan ember, aki eleteben nem latott meg olyan eszkozt fizikai valojaban (tehat nem foton) amit amugy 8 oraban uzemeltet evek ota. En peldaul eletemben nem fogtam a kezemben palo alto tuzfalat, pedig jo regota uzemeltetek tobb szazat.
El nem tudom kepzelni, kinek kell LCD kijelzo. Dolgoztam sufni bt-nek is regen, a halozati eszkoz ott is el volt zarva valami rackbe, ami egy zart szobaban volt. Oda be nem ment senki. Minek is ment volna?
-
mrots
junior tag
válasz
zelikocc
#24173
üzenetére
"Esetleg arra is várok tippet, hogy a S2S forgalom az IPSec vagy WG legyen?"
Nalam is ugyanilyen felallas van, csak bonyolitva BGP-vel, IPv6 routinggal. En az ipsec mellett tettem le a voksomat, tobb okbol is.
1) azt akarom, hogy platformfuggetlen legyen a megoldas. Mivel nalam is tobb orszagban van leteve halozati eszkoz a csaladban, ahol nem feltetlen tudok azonnal megfordulni, ha gond van, mindenhol van lerakva tartalek eszkoz is. Van, ahol hot backup, tehat HSRP / VRRP billenti a forgalmat at, van ahol cold backup, tehat a fiokban vagy egy tartalek, elore felkonfiguralt eszkoz. Viszont mivel az eszkozpark igy nagy, nem mindenhol van ugyanolyan. Van, ahol cisco router az elsodleges de mikrotik a masodlagos eszkoz, van ahol forditva, van ahol linux miniPC van tartaleknak. Tehat nekem fontos, hogy a VPN-t olyan protokoll implementalja ami platformfuggetlen, amibol igazabol egyetlen egy van: az ipsec.
2) nekem fontos, hogy tobb fajta protokoll fut a VPN-en belul. Fut nyilvan ipv4, de ipv6 is, azert, hogy a kulonbozo lakasok egymast akkor is a VPN felett erjek el, ha IPV6-on cimzik egymast. Ezen tulmenoen fut VXLAN is, szinten ipsec-be agyazva. Raadasul, mivel vannak olyan lakasok ahol dupla eszkoz fut (hotbackup) ezek mindegyike sajat VPN tunnelt epit fel a tobbiekkel, ezek kozott pedig dinamikus routinggal tortenik az utvonalvalasztas. Ezt nekem a legegyszerubben egy ipsec felett futo GRE tunnel tudja megvalositani, amiben a routing protokollok is tudnak kozlekedni.
-
mrots
junior tag
Ismerkedem a vxlannal es elakadtam, erdeklodnek, hogy szerintetek merre tovabb / hol a hiba?
Ket hap ax2, 7.12 es 7.15 kozott van a vxlan. Mindket mikrotik mogott tobb vlan van, de csak az egyik a lenyeges. Az egyik oldalon van egy vlan 6 amit ki akarok terjeszteni a masik mikrotik moge. Direkt vxlan-nal, nem massal, mert a vxlan-t akarom megtanulni.
Egyik oldal, ahol a vlan6 letezik:/interface vxlanadd group=239.0.0.1 interface=vrrp_vlan2 local-address=192.168.25.157 \mac-address=1E:5D:9E:33:F8:3B name=vxlan1 port=4789 vni=1200 vrf=main \vteps-ip-version=ipv4/interface vxlan vtepsadd interface=vxlan1 port=4789 remote-ip=192.168.25.199Ezen az oldalon igazabol ket mikrotik van, akik VRRP-znek de ez most mellekes. Eleinte nem volt group es interface sem megadva, ugyanez volt a helyzet. A kurrens beallitasnal az interface az a kettes vlan-hoz tartozo vrrp interfesz, amiben egyebkent a local address is van.
Ezen az oldalon a vxlan1 interfesz benne van a bridge-ben, 6-os VLAN ID-vel, untagged. Tehat lenyegeben a vlan 6 es a vxlan1 van ossze bridge-elve, mert ezt a vlan-t akarom kiterjeszteni.
Masik oldal, ahol egyetlen gep akar resze lenni a vlan 6-nak:/interface vxlanadd group=239.0.0.1 interface=wifi1 local-address=192.168.25.199 mac-address=\3A:59:7F:97:50:C5 name=vxlan1 port=4789 vni=1200 vrf=main vteps-ip-version=\ipv4/interface vxlan vtepsadd interface=vxlan1 port=4789 remote-ip=192.168.25.157Ezen az oldalon is volt group es interface nelkul, nem valtozott semmi. A wifi1 interfesz az, amin a 192.168.25.199 ip cim van. Ez egy route-olt interfesz es station modban van, tehat o kapcsolodik wifin a halozathoz es erre tudja elerni a tuloldali VTEP-et.
Ezen a mikrotiken a vxlan1 interfesz es az ether2 van osszebridge-elve, semmi vlan, semmi egyeb.
Ugyanitt az FDB:[lab@site2-gw1] > /interface/vxlan/fdb/print0 remote-ip=0.0.0.0 mac-address=3A:59:7F:97:50:C5 interface=vxlan1 (3A mac cim a tuloldali vxlan1 cime)1 remote-ip=192.168.25.157 mac-address=1E:5D:9E:33:F8:3B interface=vxlan1 (1E mac cim a tuloldali mikrotik)2 remote-ip=0.0.0.0 mac-address=1E:5D:9E:33:F8:3B interface=vxlan13 remote-ip=0.0.0.0 mac-address=00:00:5E:00:01:06 interface=vxlan1 (ez momentan nem tudom kinek a mac-je)4 remote-ip=192.168.25.157 mac-address=00:00:5E:00:01:06 interface=vxlan15 remote-ip=0.0.0.0 mac-address=48:A9:8A:35:7B:CC interface=vxlan16 remote-ip=192.168.25.157 mac-address=48:A9:8A:35:7B:CC interface=vxlan1 (48 kezdetu a lokalis mikrotik)
A vxlan mukodik. A vlan 6 forgalmat latom a masik mikrotiken az ether2 -re kotott laptopon futo wiresharkon. Latom a STP forgalmat, latom a konstans VRRP forgalmat tehat layer 2-ben latok mindent a tuloldalrol. De ennyi. Kuldeni semmilyen forgalmat nem tudok, DHCP-n nem kapok IP cimet. Ha beallitok statikusan a laptopon egy IP cimet ami a tuloldali vlan 6-ba tartozik, nem lat semmit, nem tud pingelni senkit.
Kicsit elakadtam, a neten talalhato doksik vacakok. A vxlan nyilvan mukodik, mert a forgalom atjon a masik mikrotikre es latszik az ether2-n. De ennyi. Az sem vilagos nekem, hogy azon az oldalon, ahol nincs vlan6, csak vxlan-on keresztul, kellene mennie a dhcp-nek? Kell ehhez lokalis dhcp szerver? Kellene a lokalis mikrotiknak IP cimmel rendelkeznie ebben (a szamara ismeretlen) vlanban?
Ha adok a mikrotiknak (ahol nincs vlan6) egy cimet abbol a tartomanybol (a .17 a masik oldali mikrotik cime is, tehat ugyanazt osztom ki mindket oldalon a mikrotiknak)[lab@site2-gw1] > /ip/address/printColumns: ADDRESS, NETWORK, INTERFACE# ADDRESS NETWORK INTERFACE[...]8 10.8.31.17/28 10.8.31.16 ether2akkor megjelenik a routing tablaban egy bejegyzes ami igeretesnek tunik:
[lab@site2-gw1] > /ip/route/printFlags: D - DYNAMIC; I - INACTIVE, A - ACTIVE; c - CONNECT, s - STATIC; H - HW-OFFLOADEDColumns: DST-ADDRESS, GATEWAY, DISTANCE# DST-ADDRESS GATEWAY DISTANCE[...]DAc 10.8.31.16/28 bridge_vxlan 0Ebbol nekem ugy tunik, hogy tudja, hogy a kerdeses tartomany a tuloldalon, a vxlan-on at van. De kuldeni nem kuld semmit es oszinten, kezdem elveszteni a fonalat is. Valamit nyilvan elrontok, de tud valaki segiteni, hogy mit?
-
mrots
junior tag
válasz
Bubukain
#24108
üzenetére
En csinalnek egy packet capture-t. A logbejegyzesek arra utalnak, hogy a vegpont ker IP cimet, de a valaszt mar nem kapja meg, tehat adatkapcsolati retegben lehet a problema, meghozza szimplex kommunikacio. dhcp discover megerkezik a broadcast cimre, a mikrotiked meghallja, probal valaszolni a felado mac cimere, de az mar nem er celba, tehat ujra discover, ujra valaszol, ujra nem er celba. Erdemes volna tudni, hogy kimegy-e a dhcp valasz a vezeteknelkuli iranyba, esetleg a jo vlan-ban van-e, nincs e filterezve.
-
#24074
mrots
junior tag
Alteran-IT
#24023
mrots
junior tag
válasz
Alteran-IT
#24023
üzenetére
Udv a klubban
nekem is nemreg volt egy kirohanasom, mert 20+ vagy nem is tudom mar hany ev cisco tapasztalattal a hatam mogott a mikrotik egy ocskavas. En is azt hittem, hogy a tobbi szerencsetlen szappantartohoz kepest vegre egy doboz aminek kozepkategorias ara van es cserebe a feature-ok benne vannak. Hat, benne, de olyan lutri az egesz. Nemreg az LTE-vel szenvedtem, vegul rendszeres reboot lett a dologbol, ami azert eleg szanalmas, ha ugy nezem. Most ket napja eppen egy ipsec kapcsolat szakadozik nekem is. Egy olyan ipsec kapcsolat ami kb evek ota stabilan megy, nem kellett hozza nyulni, most hirtelen ket napja kezzel ki kell torolnom az active peer-eket es hagyni ujra felepulni.Visszaternek a ciscora, csak az a baj, hogy a savszelesseg amit ki kell szolgalni csak akkora cisco cuccal megy, ami befuti a szobat, az meg nem tesz jot a villanyszamlanak.
-
mrots
junior tag
válasz
laracroft
#23971
üzenetére
Szerintem mindez siman megoldhato es nem jelent kihivast - egy kivetellel: az egy csomag ket celba torteno kozvetiteset. En nem tudok olyan mikrotik beallitasrol vagy modszerrol aminek segitsegevel egy csomagbol kettot csinalnal, mivel altalaban a routerek nem tamogatnak olyan metodust, hogy egy csomagbol ketto legyen.
A multicast egy picit kivetel, ott valoban tortenik csomag duplikalas, de nem feltetlenul az a router vegzi aki az egesz halozat elejen van, hanem a multicast forgalom tovabbitasa soran ugyanazt a csomagot kuldik ki tobb helyre (kb mint a switchek, amikor meg hubok voltak) attol fuggoen, hogy hol van feliratkozo az adott multicast csoportra.
Logikus, hogy a mikrotik az egyik helyre kuldi csak ki a csomagot, hiszen megy vegig fentrol lefele a NAT szabalyokon es ami eloszor passzol azt csinalja, utana nem keres tovabb. Ha jol tudom - de lehet rosszul tudom.
Mivel azt irod, hogy a masodik cim az elso tartaleka csupan, ha semmikeppen nem tudod a forgalmat ket helyre kikuldeni es mas iranybol kozelitenek es felvennem a masodlagos gepen (megfelelo ellenorzesek utan) az elso IP cimet es ugy mukodne tovabb. Mint egy IP alias. Nem a kerdesedre a valasz, de mukodne.
Ha mindenkepp kozpontilag akarod megoldani, akkor valoszinuleg egy reverse proxyra van inkabb szukseged.
-
-
mrots
junior tag
válasz
ekkold
#23925
üzenetére
Minden halozatomban van ilyen, mert mindenhol igenye volt a csaladnak erre.
Szerintem a kerdesnek nem lenyeges resze, hogy a wireguard-e a kapcsolat, ez csak egy technikai reszlet. Altalanossagban a lepesek a kovetkezoek:
1 a helyi halozatban mindekninek ugyanaz a default gw, ami a helyi mikrotik
2 a helyi mikrotikban kell egy PBR a kivalasztott forras IP-re, a next hop a tavoli mikrotik
3 a tavoli mikrotiknak ismernie kell a helyi IP cimeket (tudja, hogy merre kell route-olnia)
4 a tavoli mikrotiknak PATolnia is kell, hiszen alapesetben valoszinuleg csak a sajat helyi halozatara PATolA legkonnyebb a 4. Normalis esetben a MASQ szabaly ugy nez ki, hogy forras IP cim legyen a helyi halozat tartomanya, outbound interfesz legyen az amin a kapcsolat az internet fele kilep, action masquerade. Duplikald meg a szabalyt, a forras IP cim az a /32 lesz, akit kivalasztottal a tuloldalon, minden mas ugyanaz.
A masodik legkonnyebb a 3. Egyszeruen egy /32 route-ot fel kell vegyel a tavoli mikrotikon (aki kilepteti a kapcsolatot) ami a helyi mikrotik fele mutat (ahol a kliens valojaban talalhato). Nyilvan a route a wireguard-ba fog mutatni.
Ha szoros tuzfal szabalyaid vannak, akkor elkepzelheto, hogy modositanod kell ezeken is, hogy a forgalom a ket mikrotik kozott kozlekedni tudjon.
A tobbit pedig kronologiailag. Tehat 1. valoszinuleg adott, DHCP oszt egy gw-t ami a helyi mikrotik LAN interfesze.
Marad a 2. En elsokent felvennek egy uj routing tablat. Routing / Tables, +, adj neki nevet, es legyen FIB is. Ezt a routing tablat fogja hasznalni az az egy vegpontod.
Koveetkezo lepesben ebbe az uj routing tablaba vegyel fel egy darab route bejegyzest: IP / Route, +. a cel a 0.0.0.0/0, a gateway a tavoli mikrotik wireguard cime, a routing table mezonel pedig valaszd ki az uj routing tablat amit letrehoztal.
Ez utan a route tabladban ket default gateway bejegyzes lesz. Az egyik amit eddig is hasznaltal, a main tablaban, a masik amit most vittel fel az uj tablaba, ezt meg nem hasznalja senki.
Az utolso lepes, egy routing szabaly felvetele: Routing / Rules, +. A forras cim legyen az az egy host akinek masfele kell mennie, az action legyen 'lookup only in table', a table pedig legyen az uj tabla amit most hoztal letre.
Ennyi. Ugyelned kell, hogy ha a tuzfal szabalyok tul szigoruak, akkor mindket oldalon at kell engedned a legitim forgalmat ami eddig nem volt, valamint a forras oldalon, ahol a kivetelezett egy darab vegpont van, ha tul laza a PAT szabaly, akkor ellenorizd, hogy erre az egy hostra ne vonatkozzon cimforditas. Mivel a PAT szabaly resze a kimeno interfesz is, ennek a hostnak pedig mar nem ez lesz a kimeno interfesze (hanem a wireguard) elvileg az eddigi PAT szabaly nem fog ra mar vonatkozni, de ellenorizd.
-
mrots
junior tag
válasz
yodee_
#23919
üzenetére
"*) lte - fixed R11e-LTE no traffic flow when modem with older firmware version is used;"
Ezt kiszurtam en is, koszonom, hogy bemasoltad ide. Ugyan nem pontosan passzol, ez R11e-LTE -rol szol, a kerdeses eszkozben R11e-LTE6 van, de egye fene. 7.16-hoz irtak, en 7.11 -en futok jelenleg. Ez egy nagy ugras tavolrol. Ugy latom nem vagyok egyedul akik nem biznak a ROS upgrade-ben. Viszont a bug azt mondja a bug akkor letezik, ha regi firmware verzio volt. Nem specifikalja mi a regi, de a firmware frissitest kisebb rizikonak ereztem, mint a ROS frissitest, tavolrol, ugyhogy most igy fut:
/interface/lte/firmware-upgrade lte1
installed: R11e-LTE6_V038
latest: R11e-LTE6_V038Ez, illetve atmenetileg betettem egy 12 orankenti feltetel nelkuli ujraindulast. Meglatjuk par napig, hogy valtozik-e valami. Ha igy stabil, akkor 24 orankenti ujrainditas, utana meglatom.
-
#23921
mrots
junior tag
lionhearted
#23914
mrots
junior tag
válasz
lionhearted
#23914
üzenetére
"Kritikus" rendszert építettél egy SPoF-re. Ha elpukkan a tápegység, akkor mi van?
Idezojelbe tetted, szoval nem tudom pontosan mit ertesz alatta. A rendszer nem kritikus, csak par kamera aminek a kepe nezheto tavolrol. Mi tortenik ha a kamerak kepe nem nezheto? Igazabol semmi. Ennyit a kritikussagrol. Ha valoban kritikus lett volna, akkor nem egy es nem mikrotik eszkozt teszek oda
" mint írtam voltak rá panaszok, konkrétan az LTE modemre is."
A konkretumok erdekesek lehetnek, de azt nem irtal. Ugy altalanossagban en is olvastam sok panaszt, de nem tartottam oket relevansnak. Lehet, hogy a rossz helyen olvastam?"nem mi írjuk, nem is tudunk adni changelogot"
Talan felreerthetoen fogalmaztam, vagy talan nem ment at amit mondtam. Nem azt vartam, hogy itt valaki irjon change logot, hanem azt, hogy segitsen valaki megtalalni. A release notes-ot megtalalom a ROS-hoz, de a firmware-hez nem. En ahhoz vagyok szokva, hogy a gyarto aminek a termeket hasznalom ha kihoz egy uj szoftvert, megmondja mi valtozik benne. Ezt kerestem es segitseget kertem abban, hogy hol talalom a change logot." RSRP: nem összetévesztendő az RSSI-vel"
Nyilvan en osszekevertem, de koszonom a magyarazatot."a workaround meg már csak ilyen, melós, szenvedős"
nincs ezzel semmi baj, csak nem erre szamitottam, ennyi. -
mrots
junior tag
válasz
Reggie0
#23906
üzenetére
Ezt nem ketlem, hogy a legtobb cucc hatterben kezeli, csak itt eppen nem kezeli. Egy masik eszkoz:
gw#sho logging | i Cellular0/1/0
Feb 17 09:00:37.835: %LINK-5-CHANGED: Interface Cellular0/1/0, changed state to reset
Feb 17 09:00:38.835: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/1/0, changed state to down
Feb 17 09:00:42.835: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed state to down
Feb 17 09:03:46.178: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed state to up
Feb 17 09:03:47.178: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/1/0, changed state to up
Feb 17 15:30:38.803: %LINK-5-CHANGED: Interface Cellular0/1/0, changed state to reset
Feb 17 15:30:39.803: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/1/0, changed state to down
Feb 17 15:30:43.803: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed state to down
Feb 17 15:31:46.504: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed state to up
Feb 17 15:31:47.504: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/1/0, changed state to up
Feb 17 22:00:38.486: %LINK-5-CHANGED: Interface Cellular0/1/0, changed state to reset
Feb 17 22:00:39.486: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/1/0, changed state to down
Feb 17 22:00:43.486: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed state to down
Feb 17 22:03:46.848: %LINK-3-UPDOWN: Interface Cellular0/1/0, changed state to up
Feb 17 22:03:47.848: %LINEPROTO-5-UPDOWN: Line protocol on Interface Cellular0/1/0, changed state to upEzzel peldaul tudok elni. Hat - het orankent egy-harom percre leszakad es visszajon. Mert visszajon. Azt gondoltam tud hasonlot a mikrotik es ezert gondoltam:
[root@oob] > interface/lte/monitor lte1 once without-paging
[...]
session-uptime: 5h38m13s -
#23910
mrots
junior tag
lionhearted
#23903
mrots
junior tag
válasz
lionhearted
#23903
üzenetére
Elhiszem, ha amit irok ezt a latszatot kelti. Hadd vilagitsam meg, miert nem csak vagdalkozas szerintem amit irok:
- hardver hiba: ez kb az utolso utani lehetoseg, amikor mar semmilyen megoldas nem mukodik. ez nagyjabol az a kategoria, hogy fogalmam sincs de akkor mondjuk ra, hogy hw hiba, mert ugysem lehet bebizonyitani, hogy az vagy sem. Mindaddig, amig barmilyen modon lehet szoftveresen elore jutni, ez az opcio nem jatszik, hiszen mielott leraktam az eszkozt oda ahova, ket hetig nyuztam ugy, hogy mellettem volt es semmi baja. Szoval egyelore ez a hardver hiba ez nem tobb, mint egy vaktaban lott tipp.
- firmware hiba: megint csak azt mondom, hogy ket hetig mukodott mellettem. Igen, idonkent leszakadt, ujra csatlakozott - ezt be lehet tudni a mobil terero sajatjanak, ha idonkent megtortenik. Nem hinnem, hogy a mostani helyen lett hirtelen hibas a modem firmware. Az, aki javasolta ezt, nem adott linket changelog -ra, hogy a ket fw verzio kozott mi a kulonbseg, en sem talaltam ilyet sehol. Vaktaban nem upgrade-elek firmware-t, mert mint irtam, az eszkoz 1500 km-re van tolem. Ha nem sikerul, vagy offline meg valami entert kene nyomni, vagy megerositeni valamit, az nem fog menni tavolrol, mivel ha jol tudom a fw frissites OTA. Legalabbis egyet frissitettem, mielott letelepitesre kerult. Szoval mivel a riziko nagy, a benefit meg kicsi (igazabol senki se tudja, mi a kulonbseg a ket verzio kozott, szoval tudomanyos alap nelkuli a javaslat) ezert jelenleg nem opcio. De meg mindig jobb, mint a hw hiba tipp.
- mobil terero: most, hogy tobben is irtak ezt a 103-mat, illetve osszehasonlitottam mas lerakott eszkozzel kezdem atertekelni a dolgot. Eddig azert huztam ki, mint potencialis hibaforras, mert a helyszinen 30-50 mbit kozott ment. Tobb sim kartyaval probaltam, huzamosabb ideig egy T kartya volt benne aminek botranyos terereje volt, at kellett helyezni de meg azzal is stabilan ment par napot. Az eszkozt athelyezni nem tudom, szoval az egyetlen opcio: rakenyszeriteni egy masik mobilszolgaltato halozatara, hatha az jobb. De ez is borderline ugyanaz a riziko, mint a fw frissites: ha nem csatlakozik, vagy az rosszabb, akkor vegleg kizarom magam, tehat kb ez a javaslat is olyan, hogy most eppen nem tudok vele mit kezdeni
- a netwatch mukodese: pontosan ez az amire szuksegem volt, csak valoszinuleg nem tudtam megfogalmazni rendesen. Amikor lattam, hogy instabil, akkor a netwatch tunt kezenfekvo megoldasnak, de mint most mas megvilagitotta, a korlatai miatt nem teljesen alkalmas arra, amire hasznalni akarom. Ez momentan a legjobb utvonal elore, mivel kizarni nem tudom magam tavolrol, viszont a helyzethez alkalmazkodni tud egy jol megirt script es ki tudja hozni a helyzetbol a maximumot.
Nem azzal van bajom, ha fw-t kell frissiteni, vagy hw-t kell cserelni. Azzal van bajom, ha minden tudomanyos alap vagy teny nelkul kellene valamit csinalni ugy, hogy a kovetkezmenyeket a javaslat nem veszi figyelembe.
-
mrots
junior tag
válasz
grabber
#23899
üzenetére
Szia,
ne erts felre, halas vagyok az otletert, illetve a tanacsert. De pontosan azert tettem mikrotik eszkozt az LTE vegere, hogy ne kelljen ilyen barkacsolasokat csinalnom. Mar a napi 1 reboot is feszegeti a hatarokat. Ettol meg a tenda is jobb volt, ami eveken keresztul logottt az LTE-n ujrainditas vagy barmi nelkul es teljesen jol mukodott.
Miert szedtem ki? Mert tavolrol nem menedzselheto, kellett valami ami VPN kepes. Azt gondoltam, hogy egy mikrotik van olyan szinten, mint egy huszezer forintos szappantarto.
-
mrots
junior tag
válasz
dombila
#23897
üzenetére
Koszonom a javaslatot, ha visszajott online akkor igy fogok tenni, bar az az igazsag, hogy mivel egy sima pingelest csinal, igazabol nem esemenyvezerelt. Ezt irod:
"az általa figyelt esemény bekövetkeztekor - pl szakadás - egyszer megpróbálja futtatni a scriptet. Ha az valamiért nem sikeres, akkor nem próbálja többször elindítani"
A script ami jelenleg van, amit bemasoltam korabban, nem esemenyvezerelt. Fixen 5 percenkent indul es pingel egyet. Ha sikeres, akkor nem csinal semmit. Ha sikertelen, akkor csinalja, amit csinalnia kell. Mivel nekem sincs jobb otletem, kovetem a javaslatod, es at fogom irni idozitett scriptre. De igazabol most is az. Szoval nem teljesen latom, hogy miert lesz jobb, mint a mostani.
-
mrots
junior tag
válasz
yodee_
#23892
üzenetére
"Amint látszik a firmware nem a legfrisebb, én azzal kezdenék."
Ezek ilyen vaktaba lovoldozesnek erzem. En nem lattam release notes-ot a ket firmware kozotti kulonbsegrol. Illetve nyilvan LTE modem firmware-t sem fogok tavolrol frissiteni ami utan esetleg valtozik valami a kodban, vagy menet kozben tortenik valami es egyatalan nem lesz elerheto utana.
"Ez külföldön található cucc"
Magyar halozaton log, mint lathato a kimenetbol, pannon vagy hogy hivjak most eppen. A sim kartya nem magyar, azert, mert igy barmelyik szolgaltato halozatat hasznalni tudja. A T-s halozat felejtos, 1-2 mbit/s a maximum, olyan a terero - a mikrotik is sargan / naracssargan jelzi a jelszinteknel, hogy nem oke. Vodat nem probaltam. A T-vel a terero olyan volt, hogy a teraszon ha kint volt, akkor mukodott egyatalan."Sajnos azt én is tapasztaltam, hogy a netwatch egyszer próbálkozik, ha nem sikerül után nincs több próba"
Ezt nem teljesen ertem, mire irod. Az en tapasztalatom, es mint a logokbol latszik, az esetek nagy reszeben elkapja, amikor az LTE leszakad es az interfesz billentessel visszahozza a routert. A problema akkor van, amikor ismeretlen ok miatt ket napig nem fut egyatalan. Hogy ilyenkor miert jon vissza a router egyatalan, nem tudom, de ha visszajott, a netwatch megint ugy tunik megy es elkapja a problemat es megoldja. Szoval fut es teszi a dolgat. Kiveve amikor nem.
A terv az volt, hogy ma este miutan a gyerekek lefekudtek reszelek a scripten egy kicsit, de nyilvan ma estere megint offline lett a mikrotik, szoval most megint varok addig, hogy elerheto legyen. Eddig ketszer tamadt fel tok varatlanul ilyen masfel nap utan. Hatha most is.
-
mrots
junior tag
válasz
Reggie0
#23891
üzenetére
"Azert a -103dbm RSRP eleg gyengusz jel."
Az lehet, de 40-50 mbit megvan rajta, egyreszt, masreszt pedig teljesen jol latszik a logokbol, hogy a netwatch script mukodik. Naponta 1x - 2x leszakad a mikrotik az LTE-rol, a netwatch eszreveszi, billent egyet az interfeszen es visszajon. Nem ez a problemam. A problemam az, amikor a netwatch scriptnek futnia kellene, de nem is fut - a logokbol erre lehet kovetkeztetni. Ez nem a mobilhalozat problemaja.
-
mrots
junior tag
válasz
yodee_
#23886
üzenetére
No kerlek, ma 18 ora utan ismet ugy dontott a mikrotik, hogy online lesz, fel is epult a tunnel azonnal es a nagios is szolt, hogy a vegpont online. Amig offline volt, addig nem csak a vpn nem ment, de a mogotte levo kamerak sem.
Kerdeztel az eszkozrol, most tudok belole informaciot kiszedni:
eloszor:
routerboard: yes
board-name: LtAP
model: RBLtAP-2HnD
revision: r2
firmware-type: mt7621L
factory-firmware: 6.48.6
current-firmware: 7.11
upgrade-firmware: 7.11aztan:
uptime: 1w4d13h47m44s
version: 7.11 (stable)
build-time: Aug/15/2023 06:33:51
factory-software: 6.46.6
free-memory: 68.5MiB
total-memory: 128.0MiB
architecture-name: mmips
board-name: LtAP
platform: MikroTika modemet kerdezted meg azt hiszem:
pin-status: ok
registration-status: roaming
functionality: full
manufacturer: "MikroTik"
model: "R11e-LTE6"
revision: R11e-LTE6_V035
current-operator: Yettel HU
roaming: yes
access-technology: LTE
session-uptime: 2h36m18s
primary-band: B7@20Mhz earfcn: 3350 phy-cellid: 158
cqi: 11
ri: 2
rssi: -72dBm
rsrp: -103dBm
rsrq: -7.5dB
sinr: 8dBA firmware pedig:
installed: R11e-LTE6_V035
latest: R11e-LTE6_V038Szerintem ezek a relevans beallitasok illetve parameterek. A logok pedig lentebb. Eloszor 13-an delutan, amikor legutobb visszajott es be tudtam lepni. Csinaltam gyorsan mentest is, modositottam a netwatch scriptet majd kileptem, ez volt delutan, majd jott egy szakadas. A netwatch kiszurta, LTE interfesz disable, varunk 30 masodpercet, enable, ra 15 masodpercre az interfesz beregisztralt, ra 7 masodpercre a link felkott, ra negy masodpercre mar indult is az ipsec. 10.7.20.13 az ipsec tuloldalan van, ez az amit monitoroz a netwatch. Ime:
02-13 15:56:55 system,info,account user root logged out from 10.7.20.13 via winbox
02-13 16:30:28 interface,info lte1 link down
02-13 16:33:57 netwatch,info event down [ type: simple, host: 10.7.20.13 ]
02-13 16:33:57 script,warning OOB VPN down
02-13 16:33:57 system,info device changed
02-13 16:34:27 system,info device changed
02-13 16:34:43 lte,info lte1: registered roaming
02-13 16:34:50 interface,info lte1 link up
02-13 16:34:52 ipsec,info initiate new phase 1 (Identity Protection): 10.148.24.74[500]<=>XXX.XXX.XXX.24[500]
02-13 16:34:54 ipsec,info ISAKMP-SA established 10.148.24.74[4500]-XXX.XXX.XXX.24[4500] spi:c31b2xxxxxcc3d4a:4312cdxxxxxe23cb
02-13 16:39:07 netwatch,info event up [ type: simple, host: 10.7.20.13 ]Szoval minden ugy mukodik ahogy kellene. A fentihez hasonlo borulas volt 23:04 -kor is, amit negy perc mulva eszrevett a netwatch es raizgult. LTE disable, 30s varakozas, enable, 15 sec mulva lte regisztralt a mobilhalozaton, interfesz fel, ipsec felepites sikeres, netwatch megnyuszik. Majd ugyanez lejatszodik par oraval kesobb, 14-en reggel kettokor is, ahol azonban mar az utolso lepes, az ipsec felepites hibara fut, es onnantol egy darab logbejegyzes sincs ma 18:42-ig, amikor is hirtelen eletre kel. De meg az 5 percenkenti netwatch futas es a log bejegyzes sincs.
02-14 02:09:59 interface,info lte1 link up
02-14 02:10:00 ipsec,info initiate new phase 1 (Identity Protection): 10.151.71.133[500]<=>XXX.XXX.XXX.24[500]
02-14 02:10:55 interface,info lte1 link down
02-14 02:11:00 ipsec,error phase1 negotiation failed due to time up 10.151.71.133[500]<=>XXX.XXX.XXX.24[500] 7a6xxxxxxab9f691:0000000000000000
18:42:15 lte,info lte1: registered roaming
18:42:22 interface,info lte1 link up
18:42:22 ipsec,info initiate new phase 1 (Identity Protection): 10.147.208.178[500]<=>XXX.XXX.XXX.24[500]
18:42:26 ipsec,info ISAKMP-SA established 10.147.208.178[4500]-XXX.XXX.XXX.24[4500] spi:751052xxxxxx351:6b4f1cxxxxxxa9f4
18:44:03 netwatch,info event up [ type: simple, host: 10.7.20.13 ]
18:44:03 script,warning OOB VPN upSzoval nekem most eppen az a gyanus, hogy 02:11 -kor meghalt a net, rendben van, masnap este haromnegyed hetkor visszajott, oke, de a ketto kozott a netwatch-nak sirnia kellett volna, hogy nincs net es probalkozni az interfesz lekapcsolas - varakozas - visszakapcsolassal. Ami nem tortent meg. Amikor viszont visszajott, ugy tunik azonal latta is. Lehet, hogy meg futott az elozo netwatch script es ket peldany nem futhat?
Valoszinuleg egy kondicio nelkuli reboot 24 orankent ezt megoldja, csak... hogy is mondjam... olyan szanalmas ez. Foleg, hogy a parezer forintos tendat eveken keresztul nem kellett rebootolni.
A netwatch script amugy:
/tool netwatch
add disabled=no down-script="log warning \"OOB VPN down\"\r\
\n/interface/lte/disable lte1\r\
\n:delay 30s\r\
\n/ip/ipsec/active-peers/kill-connections\r\
\n/interface/lte/enable lte1" host=10.7.20.13 http-codes="" interval=5m src-address=10.7.20.17 \
test-script="" timeout=10s type=simple up-script="log warning \"OOB VPN up\"" -
-
mrots
junior tag
válasz
yodee_
#23884
üzenetére
Ahogy irtam, egy evolucios folyamat vegen vagyok az asztalra csapas fazisaban. A tegnap esti netwatch script modositas, amibe beletettem egy hosszabb varakozast es interface disable / enable parancsokat, azt hittem eleg lesz. Nyilvan nem, durvan 8-9 ora utan megint offline lett. Tegnap este megszuntettem a loggolast a teszt parancsnal is, mert teleszemetelte a logot es nem lattam a relevans uzeneteket. Ha egyatalan visszajon, akkor a kovetkezo lepes a minden reggel 1kor reboot lesz, akar van lte akar nincs, tokom tele van mar. Azt hittem ez egy megbizhato marka, de szerintem a vege az lesz, hogy odaviszek egy ciscot aztan az menni fog es kesz.
-
mrots
junior tag
válasz
yodee_
#23880
üzenetére
Most eppen offline - reggel 4 ota, szoval ha a kerdesre a valaszt egy /system/routerboard print vagy hasonlo adja meg, akkor ezt most nem tudom megadni. A legutobb 4 napig volt offline es utana egyszer csak visszatert, tegnap este bovitettem a netwatch scriptet arra, hogy lte interfesz disable, delay 30s majd enable. Nyilvanvaloan nem segitett, hiszen ezzel ha reggel 4kor elveszti a halozatot, 4:06 -ra mar ujra online kellene, hogy legyen.
Szoval nem tudom pontosan a valaszt a kerdesre, de raadasul megnezni sem tudom most. Az eszkoz kb 1500 km-re van tolem.
-
mrots
junior tag
válasz
yodee_
#23878
üzenetére
A tenda valami hasznalt szutyok - ez az ami mindig mukodott.
A cisco volt 1921, 1941, 2921 es 3g / 4g HWIC kartyakkal.
A mikrotik ltap lte6 kit.Ugyanolyan simkartya ugyanttol a szolgaltatotol, ugyanazon a halozaton a mikrotikban hetente dobal, semelyik masik eszkozben nem.
-
mrots
junior tag
válasz
yodee_
#23864
üzenetére
En is hasonloval kuzdottem es meg kell mondjam, hogy kicsit csalodtam az MT-ben. Valamikor evekkel ez elott vettem hasznaltan egy ko egyszeru hot primitiv tenda 4g wifi routert, azert, hogy egy idos csaladtaggal lehessen facebook portalon beszelgetni. Az idosek otthonaban nem volt wifi, szoval vittem a portalt es vittem hozza egy 4g routert is, amit csak bedobtam az agy ala egy sim kartyaval. Tobb, mint egy even at folyamatosan ment, soha semmi panasz nem volt ra, havonta egyszer kellett megvennem a prepaid simre a havi korlatlan internetet es ennyi torodest igenyelt. Ja, meg evente egyszer az epulet elott wifin racsatlakoztam (covid alatt nem lehetett bemenni), hogy a szolgaltatoi SMS-t elolvassam az adategyeztetesnel. Se VPN se semmi nem volt, olyan primitiv megodas volt amilyet csak elkepzelni lehet. Soha nem kellett foglalkoznom vele.
Most egy eladas elott allo lakasba vittem par kamerat, meg egy mikrotik lte kitet. Mar legalabb a hatodik script verzional tartok, mert hetente egyszer mindig az van, hogy leszakad a mikrotik a mobilhalozatrol. Pedig nem bonyolult igazabol: ad wifin netet a kameraknak, illetve egy ipsec-et felepit egy VPS-hez, hogy tavolrol ra tudjak nezni ha szukseges az eszkozre. Ugy, hogy elotte ket hetig futtattam probakeppen az eszkozt, kellett egyre durvabbra irni a netwatch scriptet. Mennyi idonkent pingeljen, mi legyen a timeout, mi tortenjen, stb. Eloszor csak kill-eltem az ipsec kapcsolatokat. Aztan jatszottam a timerekkel. Aztan mar az lte interface disable meg enable. Aztan megint a timerekkel jatszani. Aztan a naplozassal, hogy latszodjon mi tortent amikor elerhetetlen volt az eszkoz. Most a nagios eppen megint azt jelzi, hogy leszakadt es valoban, az appban a kamerak is leszakadtak, pedig azokhoz nem kell ipsec. A kovetkezo lepes most mar az lesz, hogy reggel egykor kerdes nelkul el fogom bootolni a routert, mert kezd a tokom tele lenni.
Mindekozben ott volt a filleres tenda eszkoz, amivel eveken at nem kellett semmit foglalkozni, csak ment, illetve ott van a sajat cisco routeremben egy LTE HWIC, amiben szinten sim kartya van, arra az esetre ha a vezetekes netem leszakadna - ezzel sincs durvan 2 eve gond, elotte 3G HWIC kartya volt benne, az is legalabb negy-ot evig ugy futott, hogy talan ketszer kellett tavolrol hozzanyulnom ennyi ido alatt.
Szoval en ugy vagyok vele, hogy LTE-ben a mikrotik szerintem eleg fos, megbizhatatlan es nem szabad onmagaban letelepiteni, csak ha van mellette backup megoldas. Mondjuk egy masodik mikrotik egy masik sim kartyaval, amin keresztul be lehet menni a halozatra, ha az elso megall.
-
mrots
junior tag
válasz
myk_to
#23695
üzenetére
Tok ertheto mit es miert akarsz csinalni, en is csinaltam. Az egyetlen kulonbseg, hogy olcson szereztem hasznalt mikrotik routert ami a labor eszkoz lett es azon tudtam mindent kiprobalni. Nem kellett licensz problemakkal kuzdeni, emulalni wifit, driverekkel vacakolni - csak ott volt es ment. Bonusz elony, hogy legalabb volt egy hidegtartalek eszkoz, ha az eles esetleg bekrepalt volna.
-
#23591
mrots
junior tag
Szpilu__25
#23590
mrots
junior tag
válasz
Szpilu__25
#23590
üzenetére
A mikrotik tuzfala ha ures konfiggal inditottal, akkor alapbol enged barmilyen forgalmat barhonnan barhova. Ha allitottal be tilto szabalyt (mondjuk barmely interfeszrol barmi jon az drop, kiveve amit korabban engelyeztel) akkor nyilvan engedni kell a vpn forgalmat. Route elvileg nem kellene, hiszen altalaban a mikrotik az alapertelmezett atjaro is, tehat a visszairanyu forgalom hozza kerul es o tudja merre kell kuldeni. Bonyolultabb esetben ez nyilvan nincs igy akkor kellhet routing is.
-
mrots
junior tag
válasz
Gyula888
#23588
üzenetére
Megkoszonnem, ha kiprobalnad. Nincs ra szuksegem most, de hasznos lenne tudni. Jelenleg a szuloknel a kabeles (one/voda/upc) modemnek van 4 LAN portja, maga a modem bridge modban van. Ebben van ket router es mindketto DHCP-n teljesen onallo cimet kap, megcsak nem is azonos subnetben vagy tartomanyban.
Ha jol ertettem a T-s helyzetet, akkor van PPPoE passthrough, tehat a kerdes, hogy lehet-e ket pppoe session egymastol fuggetlenul felepitve ugyanazon login adatokkal, ugyanazon modem mogul, ket teljesen kulonbozo router altal.
En most hirtelen rakerestem es egy forumot talaltam csak, ahol valaki pont a pppoe passthrough / bridge modrol kerdez. A valasz szerint:
"Don't forget to delete your pppoe username and password at sagemcom. You can only use 1 pppoe session on 1 device.
Yes In Pppoe passthrough mod You can use your own device as firewall. "A fenti tanacs 2019-es, szoval lehet azota valtoztak a dolgok, de senkinek a kornyezetemben nincs T-s elofizetese, szoval sosem kerultem olyan helyzetbe, hogy kiprobaljam.
-
mrots
junior tag
válasz
Gyula888
#23586
üzenetére
De nem csak 1 pppoe session lehet per elofizetes? Hogy akasztok a dobozra ketto darab eszkozt, amelyek kulon-kulon kapnak publikus ip cimet es kulon-kulon cimezhetoek? Mert most a szuloknel igy van letelepitve, mivel nem jarok gyakran arra. Ket router, amelyek kulon-kulon kapnak IP-t, belul HSRP-znek, es ha az aktiv elromlik, a standby atveszi a szerepet addig amig odaerek megjavitani / kicserelni az elromlottat. A halozatukban pedig zero kieses van mindekozben. Az egyetlen single point of failure jelenleg a szolgaltato illetve a modeme amit biztosit, de mivel van egy harmadik router 4G backuppal, igazabol az sem single point of failure.
Szoval ha csak egy pppoe session lehet, akkor nem tud ket router egymastol fuggetlenul publikus ip-t kapni, mert ahhoz mindkettonek sajat pppoe session-t kell felepitenie.
De sose voltam T elofizeto, szoval lehet rosszul tudom.
-
mrots
junior tag
válasz
Protezis
#23576
üzenetére
"Olyan előírást, amire én számítanék, miszerint 100.x.x.x IP-ről jövő, public IP-re menő csomagnál is SRCNAT "
Azert, mert ez sehol nem eloiras. Te magad is bemasoltad, mit mond az RFC. Es azt is irtad, hogy teljesul. Azert latsz 100 kezdetu cimeket, mert ezek a csomagok nem hagytak el a szolgaltato halozatat, tehat nem kotelesek cimforditani.
A mikrotik arul eszkozoket ISP-nek, ilyen kontextusban teljesen valid, hogy a dokumentacio azt javasolja, hogy a 100 kezdetu cimek blokkolva legyenek. Mert az ISP nem lathat ilyen forrascimrol bejovo forgalmat a halozat hataran, hiszen az a masik ISP akitol erkezne, RFC szerint cimforditani koteles, hiszen a csomag elhagyja a halozatat.
Szoval a javaslat lehet helyes - attol fugg, kinek szol.
-
mrots
junior tag
válasz
Zwodkassy
#23111
üzenetére
Nem az a kerdes, hogy melyik orszagban vagy, mivel nem ettol valtoznak a hostnevek. Attol fugg, hogy a telefon, aki a halozatodra csatlakozik eppen, az melyik orszag melyik szolgaltatojanal van, az o nevfeloldasa es cel IP cime annak megfeleloen valtozik. Nem irtad, hogy mifele halozat, ceges campus vagy sajat. De igazabol lenyegtelen is, ket okbol. Az egyik, hogy nekem az itthoni halozatomon is rendszeresen megfordulnak olyan vendegeim, akik valami random orszag halozatan vannak es probalnak vowifizni. Eleg, ha valami reg nem latott iskolai ismeros ugrik fel egy kavera, aki ma mar masik orszagban el, vagy masik orszag sim kartyajat hasznalja. Pl amiota van az eves kotelezo adategyeztetes, van aki riasztoba, beagyazott eszkozbe kulfoldi SIMet tesz, mert azt nem kell evente adategyeztetni (es nem mellesleg barmely mobilhalozatot tudja hasznalni, nem csak egyet).
A masik ok, ami miatt nem kuzdenek a regexp-pel az az, hogy ez csak egy hostnev amit leker a DNSbol es gondolom valami konfigot lehuz onnan, a valos IP cim amivel az ipsec kapcsolat felepul, nem feltetlen lesz ugyanez a cim. Szoval ha nevre akarsz regexpet irni, azzal nem vagy elorebb, mert nem ez az a forgalom, aminek qos prioritast akarsz adni.
-
mrots
junior tag
Csinaltam egy gyors tesztet, bekapcsoltam a vowifit a telefonon. A DNS szerverben latszik is:
26-Oct-2024 00:27:07.611 queries: info: client [...] (epdg.epc.mnc020.mcc234.pub.3gppnetwork.org): query: epdg.epc.mnc020.mcc234.pub.3gppnetwork.org IN A
26-Oct-2024 00:27:07.615 queries: info: client [...] (epdg.epc.mnc020.mcc234.pub.3gppnetwork.org): query: epdg.epc.mnc020.mcc234.pub.3gppnetwork.org IN AAAA
26-Oct-2024 00:27:08.663 queries: info: client [...] (epdg.epc.mnc020.mcc234.pub.3gppnetwork.org): query: epdg.epc.mnc020.mcc234.pub.3gppnetwork.org IN AAAA
26-Oct-2024 00:27:13.791 queries: info: client [...] (epdg.epc.mnc020.mcc234.pub.3gppnetwork.org): query: epdg.epc.mnc020.mcc234.pub.3gppnetwork.org IN AAAAUtana megneztem, mi az IP cim amit a telefon kapott a DNS szervertol, mikor elkezdett beregisztralni:
epdg.epc.mnc020.mcc234.pub.3gppnetwork.org has address 185.153.237.96Inditottam egy hivast, majd megneztem a netflow adatokban, hogy milyen forgalom ment ehhez az IP cimhez. Na, ehhez semmilyen. Ez a konfiguracios IP cim volt, a forgalom a konkret hivasfelepitessel mashova ment, ugyhogy a subnetre szurtem, felteve, hogy a fentihez kozeli (szomszedos) cimekre megy a konkret hang kapcsolat.
mrots@rpi$ nfdump -R . -t 2024/10/26.00:00:00 "dst net 185.153.237.96/28"
Date first seen Duration Proto Src IP Addr:Port Dst IP Addr:Port Packets Bytes Flows
2024-10-26 00:27:09.684 0.000 UDP [...]:500 -> 185.153.237.98:500 1 466 1
2024-10-26 00:27:09.756 0.308 UDP [...]:4500 -> 185.153.237.98:4500 4 816 1
2024-10-26 00:27:10.264 6.068 UDP [...]:4500 -> 185.153.237.98:4500 23 8656 1
2024-10-26 00:27:35.684 0.000 UDP [...]:4500 -> 185.153.237.98:4500 1 29 1
Summary: total flows: 4, total bytes: 9967, total packets: 29, avg bps: 3066, avg pps: 1, avg bpp: 343Szoval ezert mondom, hogy szerintem nem IP cim alapjan kene qos-t adni.
-
mrots
junior tag
válasz
Zwodkassy
#23088
üzenetére
A konnyebbik, ha a protokollt fogod meg. A vegpont (telefon) ipsec kapcsolatot epit ki a szolgaltatoval. Ha a qos feltetelenek a protokollt adod meg (esp, talan 50?) akkor ez minden vowifi kapcsolatra igaz lesz, azon az aron, hogy az az ipsec forgalom is prioritast kap, ami nem vowifi miatt lett kiepitve. Mondjuk nem hinnem, hogy tul sok belso vegpont allandoan ipsec-et huzna ki mindenhova a jobb qos parameterek miatt. Csinalhatod layer 4 portszamok alapjan is (UDP 500 peldaul, ami ipsec-hez kell) de ezt konnyebb megkerulni, mintha layer 3 protokoll alapjan priorizalsz.
A masodik lehetoseg, hogy megnezed az IP cimeket, amihez a telefon kapcsolodni fog. Ezeket DNS forgalombol kis kinezheted, a hostnevek valoszinuleg pub.3gppnetwork.org -ra fognak vegzodni, az elejuk pedig mindenfele mcc es mnc kodok lesznek (mcc: mobile country code, mnc: mobile network code). Peldaul egy ilyen vegpont hostneve, amit a telefon keres: epdg.epc.mnc020.mcc234.pub.3gppnetwork.org. Adhatsz jobb qos parametereket tehat a cel IP cim alapjan. Ez tuti nem priorizal mas, nem vowifi kapcsolatokat, tehat jo, viszont ami rossz, hogy ismerned kell, milyen szolgaltatohoz tartoznak azok, akik vowifit akarnak a halozatodon hasznalni. Ertelemszeruen a DNS nevek / IP cimek valtozni fognak szolgaltatonkent es nem is csak egy van beloluk.
En szerintem elindulnek az ipsec priorizalasaval es megneznem, hova vezet.
-
mrots
junior tag
-
mrots
junior tag
Amikor en migraltam mikrotikrol mikrotikra, akkor egy fizikai interfeszt fenn tartottam magamnak a konfiguralasra, ahol IP cim sem volt, MAC cim alapjan csatlakoztam csak. Ezt a fizikai interfeszt kihagytam a bulibol a kezdeti konfiguralaskor, mivel vlanokat, bridge-eket is erintett a konfiguracio, szoval menet kozben tuti elvesztettem volna a kapcsolatot.
Ha nincs felesleges interfeszed amit erre dedikalhatsz, akkor csak hagyd ki azt az egy portot, konfiguralj fel minden mast, es a vegen mikor mar elered az eszkozod uzemszeruen, akkor azt az egy fizikai interfeszt is hozzaadod a bridge-hez, vagy vlan-hoz vagy amihez akarod.
-
mrots
junior tag
Vannak kulonbsegek. Nem tudom teged erint-e. En amikor ax2-rol ax3-ra valtottam (hasonloan 6.49-rol 7.x -re) akkor megkuzdottem peldaul azzal, ahogy a BGP redisztribucional a filterek megvaltoztak, es a 7-es ROS nem hirdette azokat a halozatokat amiket korabban a 6-os igen.
Ezen tulmenoen ugy emlekszem a VPN-nel is valtoztak dolgok, a wifinel is megjelentek a profilok, vagy nem tudom mar minek hivjak oket. Szoval az alap dolgok (ip cim, dhcp pool stb) azok ugyanazok, de jo sok dolog teljesen mas.
nekem is nemreg volt egy kirohanasom, mert 20+ vagy nem is tudom mar hany ev cisco tapasztalattal a hatam mogott a mikrotik egy ocskavas. En is azt hittem, hogy a tobbi szerencsetlen szappantartohoz kepest vegre egy doboz aminek kozepkategorias ara van es cserebe a feature-ok benne vannak. Hat, benne, de olyan lutri az egesz. Nemreg az LTE-vel szenvedtem, vegul rendszeres reboot lett a dologbol, ami azert eleg szanalmas, ha ugy nezem. Most ket napja eppen egy ipsec kapcsolat szakadozik nekem is. Egy olyan ipsec kapcsolat ami kb evek ota stabilan megy, nem kellett hozza nyulni, most hirtelen ket napja kezzel ki kell torolnom az active peer-eket es hagyni ujra felepulni.
Új hozzászólás Aktív témák
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- Teljes verziós játékok letöltése ingyen
- Mobil flották
- Epson nyomtatók
- Path of Exile (ARPG)
- Kazy Computers - Fehérvár - Megbízható?
- Yettel topik
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Diablo 3
- További aktív témák...
- RTX 4080 SUPER,16GB. Ryzen 7 7800X3D, 32 RAM Fury RGB! Garancia!
- Asztali PC , i7 9700K , RX 5700 XT , 32GB DDR4 , 500GB NVME , 1TB HDD
- Dell Inspiron 5406 2-in-1i5-1135G7 16GB DDR4 3200 512GB NVME 14" FHD Érintőkijelző W11Pro
- Eladó MacBook Pro 14" M1 Pro (2021) 16/512 99% akku Makulátlan állapotban!
- Újszeru GIGABYTE G5 - 15.6" FullHD 144Hz - i7-13620H - 48GB - 1TB - RTX 4050 - Win11 - 1,5 év gari
- Így lesz a Logitech MX Keys magyar billentyűzetes
- ÁRGARANCIA!Épített KomPhone i5 12400F 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- MacBook felvásárlás!! MacBook, MacBook Air, MacBook Pro
- Országosan a legjobb BANKMENTES részletfizetési konstrukció! Dell G15 5530
- BESZÁMÍTÁS! ASRock H310CM i3 9100F 8GB DDR4 240GB SSD 1TB HDD GTX 1060 3GB AeroCool Strike-X 500W
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged