- Milyen GPS-t vegyek?
- Samsung Galaxy S21 FE 5G - utóirat
- One mobilszolgáltatások
- Okosóra és okoskiegészítő topik
- Egy szenzor, két zoomkamera: újraírta a Huawei a mobilfotózás történetét
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Samsung Galaxy A16 5G - a hetedik évben megpihen
- Samsung Galaxy A34 - plus size modell
- Nothing Phone (3a) és (3a) Pro - az ügyes meg sasszemű
-
Mobilarena
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
-
E.Kaufmann
veterán
Van már RouterOS 7.3.1 is, 3011-es bootloop-ot javít SFP modullal, valamint Wifiwave2 javítás.
-
válasz
E.Kaufmann #17491 üzenetére
Mikrotiknél ppp kapcsolatnál meg lehet adni az interface-t átjárónak,de dhcp esetén ez nem működik. Ott ez a baj mert állandóan változik a GW.
Én is vettem fel virtuális IP címeket amik a DNS szerverek felé mutatnak,de a utána azoknsk is valós GW kell amit mindig áz kell írni szolgáltatói GW változásnál.
-
ekkold
Topikgazda
Másnál sem megy a /ip cloud? Bármilyen mikrotikes gyariszam.sn.mynetname.net címet próbálok elérni, nem ad vissza rá a DNS IP címet.
R:\>ping 123456789ABCD.sn.mynetname.net
A pingkérés nem találta meg az állomást (123456789ABCD.sn.mynetname.net). Ellenőrizze a nevet, és
próbálja meg újra. -
ratkaics
senior tag
Sziasztok!
Én nagyon basic szinten kezelem a mikrotik-et, szóval előre is elnézést kérek a lámaságért.
Szóval már korábban kérdeztem, hogyan lehetne egy IP cím forgalmát korlátozni. Most sikerült egy "tesztkörnyezet" összeraknom, ahol próbálgatni szeretném a queue-t, de valamiért nekem egyáltalán nem csinál semmit.
Szóval a felállás az, hogy arra az aljzatra, amire a "védeni kívánt" plc volt radugva, ráakasztottam a hapac3 egyik portját, és egy másik portjára pedig a plc-t dugtam rá. Majd létrehoztam egy bridge-t, amiben a két port van. Így most kvázi ugyan úgy megy a kommunikáció, ahogyan eddig is ment. Innen szerettem volna azt megcsinálni, hogy korlátozom a "bejövő" csomagok számát egy bizonyos IP cím tartomány felől. De a simple queue-t hiába állítgatom a stat-jában nincs is forgalom.
Mit csinálok rosszul? -
Reggie0
félisten
-
E.Kaufmann
veterán
válasz
grabber #17489 üzenetére
Fix IP ADSL, de nem számít, mert azt az ISP adja dinamikusan így is, na meg a szkriptnek hótmindegy. A PPP interfészre hivatkozom, onnan meg kitalál. Amúgy nem a GW-t kell átírni, hanem felveszel több szabályt és a distance-ot állítgatod:
Eredeti szabály:
add comment=PCC1_PRI distance=1 gateway=... routing-mark=to_PCC1_GW
add comment=PCC1_SEC distance=20 gateway=pppoe0 routing-mark=to_PCC1_GWScript amit csinál, ha történik valami:
/ip route set [find comment="PCC1_PRI"] distance=20
/ip route set [find comment="PCC1_SEC"] distance=1Egy IP cím helyet vagy valami DNS trükközést használsz (Round Robin DNS), vagy VPS szervereket bérelsz. Ha meg minden kötél szakad akkor BGP alapú hálózat, ami biztos nem olcsó, meg őszintén szólva sosem volt hozzá szerencsém, csak olvastam, hogy így is lehet.
-
válasz
E.Kaufmann #17488 üzenetére
Már működött ez így nekem. De most nem is az lenne a lényeg,hogy fail overt elérjem, hanem hogy a világ felé 3 WAN IP cím helyett csak 1 IP címmel lássanak.
PL kintről befelé jönne egy VPN akkor elég egy IP nem kell 3x felvenni. Emellett a sebesség is nőhetne.Bondignál meg ha egy vonal úgy sem élne akkor, úgy sem küldene rajta adatot. Fail over is meglenne. Jó pár szolgáltatás jön be és nehéz a 3 interneten elosztani és macerás is. Ezért lenne jó a Bonding.Én is ezt csináltam. Csak a GW az állandóan változik dinamikus címnél. Vagy FIX ip kell és akkor fix a GW vagy script kellene ami állandóan ellenőrzni a GW és a route táblábal átírja a DNS route-khoz tartozó GW címeket. De nekem az nem működött,ha jól emlékszem ezt próbáltam:
:local newgw [ip dhcp-client get [find interface="ether1"] gateway];
:local routegw [/ip route get [find comment="isp1"] gateway ];
:if ($newgw != $routegw) do={
/ip route set [find comment="isp1"] gateway=$newgw;
}FIX ip-vel nincs gond,de dinamikusra még nem oldottam meg. Gondolom neked is a 3. wan dinamikus lenne?
-
E.Kaufmann
veterán
válasz
grabber #17486 üzenetére
Amúgy a PCC routing elég jól működik, ha pl a router mögötti kliensek felhős kapcsolatait szeretnénk szétdobni, kis trükközéssel egész jól ki lehet használni több különböző sebességű kapcsolatot is. Kell egy közös többszörös amennyi részre felosztjuk az összforgalmat és egy irány felé több mangle PCC szabályt is használhatunk, annak arányában hogy az összforgalomból adott irány mennyi forgalmat tud biztosítani.
Redundáns routing szabályokkal meg lehet oldani a failovert is: [link]
Én egy ütemezett scriptből piszkálgattam a routing tábla elemeinek distance értékét, és több DNS szervert is pingeltem WAN betáponként, nehogy csak azért ne használjuk, mert egy DNS szerver IP-je nem válaszol (mondjuk nem feltétlen technikai hiba, hanem esetleg elkezdik az ICMP-t jobban szűrni). Két WAN-nal ez ment is, most írom át háromra a scriptet és a konfigot, ugyanígy több DNS-t is pingelve, hátha jó lesz
, ha nem, akkor hagyom a fenébe a hármas LB-t, megoldom máshogy.
-
válasz
Reggie0 #17471 üzenetére
Van már ezzel tényleges tapasztalat? Mekkora teljesítmény kell? KB 2 gbit internet kapcsolat,egy FIX IP biztosan kell. Tűzfalazni meg nem nagyon kell,úgy is az eredeti tűzfal fog végezni mindent.
SD-WAN sajna nagyon drága. Nekem is kéne egy 3 vonalat egyesíteni. De csak a bonding a legolcsóbb és járható út. Úgy tűnik. -
Horvi
őstag
Sziasztok,
Próbáltam a két hapac2-t felfrissíteni az új 7.3-as RouterOS-re viszont mindkétszer elhasalt a dolog ezzel az üzenettel:
jun/03/2022 16:32:40 system,error,critical router was rebooted without proper shutdown, probably kernel failureValószínű ez lehet a probléma, hogy nincs hely:
Hogyan tudnék helyet felszabadítani?
Köszi -
Reggie0
félisten
válasz
E.Kaufmann #17474 üzenetére
Nem marad mas, mint hogy scriptelni kell. Viszont elo fog jonni a kerdes, hogy melyik hozzaferesnek legyen prioritasa, merje-e hogy melyik net a jobb minosegu/sebessegu, stb.. Eleg konnyu elbonyolitani a kerdest.
-
Horvi
őstag
Itt a második, harmadik kérdésre van valami jótanács? Esetleg valakinek tapasztalata, hogy egy ilyen kültéri falra szerelt megoldással mekkora hatótávot ad a cap/wap eszköz?
-
Reggie0
félisten
válasz
Istv@n #17470 üzenetére
Valoszinuleg az a baj, hogy az LTE-s eszkoz nem tudja merre kell visszakuldeni a valaszcsomagot ezert kikuldi az internet iranyaba, mert a konfigjaban levo default gateway-t talalja a megfelelo routingnak. Erre az a legegyszerubb megoldas, hogy ha a LTE alatt levo router-t allitod be default gateway-nek es ott masqueradingelsz, vagy az LTE-s eszkozon felveszed a routing tablaba a tavolabbi routered cimtartomanyat.
-
Reggie0
félisten
válasz
E.Kaufmann #17469 üzenetére
Sejtem, hogy nem erre gondolsz, de a legegyszerubb es legjobb megoldas a vps berlese, harom tunnel felhuzasa es oda bonding.
-
Istv@n
aktív tag
Sziasztok!
Van két hAp ac2-es routerem, amik l2tp vpn-nel vannak összekötve. Routingok beállítva, mindkét hálózat gépei látják egymást, működik minden, aminek kell... Viszont most az egyik router wan portjára került egy lte eszköz, aminek el kellene érnem a webes felületét. Az lte modem lan kábelen csatlakozik a routerhez természetesen, más ip szegmensben van, mint a router.
Próbálgatom a routingokat, de valahogy nem akar sikerülni az elérés. Az lte-s hálózaton lévő routerre csaltakozva elérem a weblapot, a másikról pedig csak azt látom, a tracert-ben, hogy a csomag elmegy a helyi router vpn interfészének a címéig, utána pedig time out...Hogy kellene ezt beállítani? Kell esetleg masquerade is valahová, nem elég a routing?
-
E.Kaufmann
veterán
Sziasztok! Mi mostanában a legegyszerűbb mód RouterOS-ben három WAN porton failover and backup-nak, úgy hogy az egyik dinamikus PPPoE a másik kettő meg fix IP/átjáró?
-
Reggie0
félisten
válasz
bicajoskema #17466 üzenetére
Ha a mobilnet szakad, az kb. barmitol is lehet. Idonkent a szolgaltato is megszakithatja. Meg kene nezni az LTE logot a mikrotiken, hogy mi tortenik.
-
Richárd22
csendes tag
válasz
bicajoskema #17466 üzenetére
A system menü pontban van egy watchdog nevezetű fül. Az oda beírt watchdog address-t folyamatosan nézi az eszköz, azaz időközönként pingeli, majd ha túl lépi a sikertelen ping a watchdog timeout nevű értéket a rendszer automatikusan rebootol.
Ez az ip akár lehet a google dns 8.8.8.8 címe. -
bicajoskema
tag
Sziasztok!
Van egy LHGR6+r11e modemmel szerelt eszközöm, ami egy TP link AX1500-ba megy be cat5e kábellel és POE-n kapja a tápot. A ház tetejére fel van téve az eszköz, jó ping-el és elfogadható sebességgel adja a korlátlan Yettel netet. Sajnos időnként ledobja a netet, és kapom az értesítést, az androidos telón vagy laptopon, hogy nincs internet a WIFI-n, tehát az AX1500-ról nem dob le, és az LHGR-AX1500 kapcsolat sem szakad meg, mert a mikrotik-es IP címen mindig elérem az LHGR6-ot, amit rebootolva már meg is javul a kapcsolat.
Sajnos ez nagyon zavar, mit lehetne tenni, beállítási probléma lehet? Illetve akárhányszor felmegyek a Mikrotik webes felületére, mindig másik IP címet látok (amit a Yetteltől kapok). RouterOS-t most frissítettem 7.3-ra.Mi a célom: Adja az LHGR a netet, mintha csak egy szolgáltató volna, ne korlátozzon semmit, frissítse magát és rebootolja időközönként, ne is vegye észre hogy ott van. Majd az AX1500-ban kiosztom az IP-ket meg megoldom a port forwardingokat stb. (lesz egy jópár eszközöm Home Assistant miatt, klímák, okoseszközök, shelly-k, termosztátok stb.)
Ha valaki egy jelképes összegért be configolná a hálózatot atom stabilra teamvieweren keresztül, az is nagyon jó lenne nekem
-
válasz
amargo #17460 üzenetére
nálam Zabbixba van bekötve, de hülye vagyok, hogy ezt eddig nem jutott eszembe nézni
az elmúlt 1 év... a beszakadások jelölik az (általában frissítések miatti) újraindításokat. január 15-én frissítettem ezt a router rOS7-re, látszik is, hogy onnantól indult el felfelé a memóriahasználat, előtte viszonylag stabilan 30-40% között volt.
most a 7.2 megjelenése óta nem frissítettem. hétvégén majd frissítek 7.3-ra, aztán pár hét múlva szóljon rám valaki, hogy nézzek rá erre a grafikonra. -
-
megjelent a stabil 7.3
7.3 changelog:
*) bgp - added "name" parameter for connections;
*) bgp - added initial support for prefix limit;
*) bgp - fixed "keepalive-timeout" value when upgrading from RouterOS v6;
*) bgp - fixed "l2vpn" distribution;
*) bgp - improved stability when editing BGP template;
*) bgp - moved "interface bgp-vpls" menu to "routing bgp vpls";
*) bgp - remove unused commands and parameters;
*) bluetooth - improved long-term service stability;
*) bonding - added "lacp-user-key" setting;
*) bonding - fixed LACP flapping for RB5009 and CCR2004-16G-2S+ devices;
*) bridge - added more details for loop detection warning;
*) bridge - do not set VLAN on inactive port with a "set" command;
*) bridge - fixed TCP, UDP port parsing for loop detect warning;
*) bridge - fixed packet marking for IP/IPv6 firewall;
*) bridge - ignore VLAN tagged BPDU;
*) capsman - fixed bridge disabling when using L2 connection;
*) capsman - fixed loss of manager configuration when "package-path" is set to external disk;
*) capsman - improved traffic processing over CAP communication tunnels:
*) ccr - added "passthrough" flag for interfaces on CCR2004-1G-2XS-PCIe;
*) ccr - added visible "passthrough" flag for interfaces on CCR2004-1G-2XS-PCIe;
*) ccr - improved interface link stability on CCR2004-16G-2S+PC;
*) ccr - usability and stability improvements for passthrough interfaces on CCR2004-1G-2XS-PCIe;
*) cd-install - allow selecting on which drive to install RouterOS;
*) chr - fixed Cloud DDNS update after license renewal;
*) conntrack - limited full Connection Tracking warning to 1 message per minute;
*) console - fixed "terminal inkey" command;
*) crs1xx/2xx - improved system stability during switch reset;
*) defconf - do not add passthrough ports to local bridge on CCR2004-1G-2XS-PCIe;
*) dhcpv4-server - added "age" parameter for dynamic leases;
*) dhcpv4-server - fixed conflicting or declined lease detection when IP pool differs from server's configuration;
*) dhcpv4-server - fixed minor logging typo;
*) dot1x - fixed RADIUS State attribute when client is reauthenticated;
*) dot1x - fixed port based VLAN ID assignment on devices without a switch chip;
*) dot1x - improved server stability when using re-authentication;
*) export - fixed value ID exporting that does not refer to any name;
*) fetch - fixed SFTP upload;
*) fetch - improved full disk detection;
*) filesystem - fixed possible boot failure on RB850Gx2 and RB1100AHx2;
*) filesystem - improved UBIFS stability and data integrity after downgrade to RouterOS v6 and upgrade to RouterOS v7;
*) filesystem - improved long-term filesystem stability and data integrity;
*) gps - added GPS package support for Chateau devices;
*) gps - fixed minor value unit typo;
*) ipsec - fixed IPsec IRQ initialization on startup on TILE;
*) ipsec - fixed printing of active peer statistics;
*) ipv6 - added "ra-preference" parameter support for RA;
*) ipv6 - fixed dynamic non link-local addresses displaying;
*) ipv6 - removed bogus commands from IPv6 neighbors menu;
*) l2tp - added VRF support for L2TP client;
*) l3hw - greatly improved route offloading speed;
*) l3hw - improved offloading for directly connected hosts on CRS305, CRS326-24G-2S+, CRS328, CRS318, CRS310;
*) l3hw - improved offloading in cases of HW table overflow for CRS305, CRS326-24G-2S+, CRS328, CRS318, CRS310;
*) l3hw - improved route table offloading for CRS317, CRS309, CRS312, CRS326-24S+2Q+, CRS354, CRS5xx, CCR2x16 devices;
*) l3hw - log HW routes count and the shortest offloaded subnet prefix if the HW memory gets full;
*) l3hw - offload only main routing table;
*) l3hw - optimized offloading when dealing with large volume of directly connected hosts;
*) l3hw - partial routing table offload for Marvell Prestera DX4000/DX8000 switch chip series;
*) leds - fixed ethernet LED behavior on wAP R ac;
*) leds - fixed wireless related LED behavior with WW2 package;
*) lhgg - improved system stability (introduced in v7.2);
*) lora - do not allow setting non-existing forwarding server;
*) lora - fixed bogus TOO_EARLY errors;
*) lora - removed TX lookup table;
*) lte - added SMS sending support for MBIM protocol;
*) lte - added support for generic PXA1802 based modems;
*) lte - allow only MCC/NMC format in "operator" parameter;
*) lte - clear SIM values when modem in "stopped" state;
*) lte - disabled extended signal info query for Telit LN940 module;
*) lte - disabled wait for LTE auto attach;
*) lte - expose diagnostics channel for all modems;
*) lte - fixed LTE firwmare upgrade on RBLtAP-2HnD with R11e-LTE6;
*) lte - fixed Sierra MC7455 modem initialization;
*) lte - hide slave interfaces from export;
*) lte - improved LTE interface initialization process on LtAP-2HnD;
*) lte - improved stability when configuring multiple APN's at the same time in MBIM mode;
*) lte - improved stability when upgrading LTE firmware on Chateau 5G;
*) mlag - fixed MAC address moving between bridge ports;
*) mpls - do MPLS forwarding for nexthops without mappings;
*) mpls - fixed MPLS MTU and path MTU selection;
*) mpls - fixed MPLS forwarding after any interface configuration parameter is changed;
*) mpls - improved LDP AF selection process and behavior;
*) mpls - made LDP bindings work on PPP interfaces;
*) ntp - do not allow setting port number in "server" parameter;
*) ntp - fixed "use-local-clock" behavior when enabling server;
*) ospf - fixed GRE interface compatibility with OSPF;
*) ospf - ignore instance route when originate-default=if-installed is enabled;
*) ospf - improved stability when enabling or removing interface-template entries;
*) ovpn - adjusted SHA2 authentication algorithm naming to allow legacy OpenVPN implementations to connect;
*) ovpn - fixed hardware offloading support on CHR;
*) ovpn - fixed memory leak on TILE architecture;
*) ovpn - fixed packet processing on MT7621A;
*) ovpn - fixed server instance not responding to incoming connections after reboot on CHR;
*) ovpn - improved Windows client disconnect procedure in UDP mode;
*) ovpn - improved server stability under continous overload;
*) ovpn - improved service stability when outbound packets are blocked by firewall in UDP mode;
*) ovpn - improved service stability when processing frequent disconnects in UDP mode;
*) ovpn - improved stability when forwarding traffic on TILE;
*) ovpn - moved authentication failure messages to "info" logging level;
*) ovpn - reply with the same IP address that the connection was established to;
*) ping - fixed socket allocation after VRF change;
*) port - do not loose "parity" setting;
*) ppp - added support for VRF;
*) ppp - added warning when using prefix length other than /64 for router advertisement;
*) ppp - fixed "remote-ipv6-prefix" parameter unsetting;
*) ppp - fixed active sessions sometimes getting stuck;
*) ppp - fixed issue with multiple active sessions when "only-one" is enabled;
*) profile - added "wireguard" process classificator;
*) profile - added "zerotier" process classificator;
*) qsfp - reset module only when all ports are disabled;
*) queue - allow to set higher limits than 4G;
*) queue - display warning for CAKE type in simple and tree setups when "bandwidth" parameter is configured;
*) queue - improved stability in large list of queue scenarios;
*) rb5009 - fixed 10G linking issues with Intel X520, XXV710 NICs;
*) resource - fixed CPU type display under system resources for ARM and ARM64;
*) romon - fixed VLAN tagged packet processing;
*) route - fixed "nexthop" table printing;
*) route - fixed "table" menu emptying after RouterOS upgrade;
*) route - fixed IPv6 /127 route nexthop resolution;
*) route - fixed static routes in VRF becoming invalid after reboot;
*) route-filter - fixed community matchers;
*) routerboard - fixed USB bus numbering on LtAP and M33G;
*) routerboot - added extra shortcut information on how to boot into etherboot;
*) routerboot - prevent enabling "protected-routerboot" on unsupported factory firmware versions;
*) routerboot - properly reset system configuration when protected bootloader is enabled and reset button used;
*) rsvp-te - improved stability when "Resv" received for non-existing session;
*) sfp - added 2.5Gbps rate for SFP+ and QSFP+ interfaces on 98DXxxxx and 98PX1012 switches (requires disabled auto-negotiation);
*) sfp - hide empty monitor values in console;
*) sfp - improved Q/SFP interface initialization and stability for 98DXxxxx and 98PX1012 switches;
*) sfp - improved QSFP/SFP interface initialization for 98DXxxxx switches;
*) smb - fixed SMB2 file list reporting;
*) snmp - added VRF support (CLI only);
*) snmp - added VRF support;
*) snmp - fixed reported disk size when multiple external disks are attached;
*) snmp - hide Vendor ID in DHCP MIB when branding is present;
*) snmp - report "ifSpeed" as 0 if value out of bounds (use "ifHighSpeed" for high speed interfaces instead);
*) ssh - added AES-GCM cipher support;
*) ssh - fail non-interactive client after first invalid password;
*) ssh - fixed corrupt host key automatic regeneration;
*) ssh - fixed private key usage after downgrade;
*) ssh - removed DSA public key authentication support;
*) supout - added IGMP-Proxy section;
*) supout - added NTP servers section;
*) supout - added PIMSM section;
*) supout - added RIP section;
*) supout - added WireGuard section;
*) supout - added simplified IPv4 and IPv6 routing table prints;
*) switch - added option to match source and destination IP addresses in ARP packets for RB5009 (requires mac-protocol=arp setting);
*) switch - fixed missing stats from traffic-monitor for 98DXxxxx and 98PX1012 switches;
*) system - fixed IP service initialization in VRF after system startup;
*) system - fixed Kernel timer consistency;
*) system - fixed rare partial loss of RouterOS configuration after package upgrade/downgrade/install/uninstall;
*) torch - properly capture all related IPv6 traffic;
*) tr069-client - fixed RPC download of "1 Vendor Configuration File" with branding package;
*) tunnels - improved packet handling over EoIP, IPIP and GRE tunnels;
*) upnp - improved stability when processing incomplete HTTP header;
*) user-manager - added "Acct-Interim-Interval" to predefined attribute list;
*) user-manager - improved stability when received EAP attribute with non-existing state attribute;
*) vpls - fixed "pw-l2mtu" parameter usage;
*) vpls - fixed TE transport path usage after startup;
*) vrrp - fixed learning of bridged local MAC addreses;
*) w60g - improved stability on Cube 60Pro ac and CubeSA 60Pro ac;
*) webfig - properly show all routing table content;
*) wifiwave2 - fixed VLAN tag handling;
*) wifiwave2 - general stability and throughput improvements;
*) winbox - added "Comment" parameter for BGP templates and connections;
*) winbox - added "Default Cost" parameter under "Routing/OSPF/Area" menu;
*) winbox - added "ra-preference" parameter under "IPv6/ND" menu;
*) winbox - added SKID and AKID parameters under "Certificate" menu;
*) winbox - added missing "IBGP", "EBGP", "Limit Exceeded" and "Stopped" parameters under "Routing/BGP/Sessions" menu;
*) winbox - added missing "Keep Sent Attributes" parameter under "Routing/BGP/Connection" menu;
*) winbox - added missing "Scan List" parameter for W60G interfaces;
*) winbox - added missing BGP session commands;
*) winbox - added support for 2.5Gbps and 100Gbps Ethernet speed options;
*) winbox - added warning message for LTE upgrade process;
*) winbox - do not auto start Wireless Sniffer when opened;
*) winbox - do not show "Session Uptime" parameter under "LTE" menu if not supported by modem;
*) winbox - do not show "unknown" area under "Routing/OSPF/LSA" menu;
*) winbox - do not show type value for NXDOMAIN entries under "IP/DNS/Cache" menu;
*) winbox - fixed "Disconnect Timeout" parameter type under "CAPsMAN" menu;
*) winbox - fixed "IP/Cloud" window refreshing after changes are detected;
*) winbox - fixed "Type" values under "IP/Route" menu;
*) winbox - fixed graph drawing in QuickSet;
*) winbox - fixed hex type values under "User Manager" menu;
*) winbox - fixed minor typo in reboot confirmation prompt;
*) winbox - fixed typo in ZeroTier instance title;
*) winbox - made "Interface Templates" table sortable under "Routing/OSPF" menu;
*) winbox - made "MPLS Interface" table sortable under "MPLS" menu;
*) winbox - made 56 the default ping size;
*) winbox - made wireless access list entries sortable when using the wifiwave2 package;
*) winbox - minimal required version is v3.33;
*) winbox - moved "src-address-list" and "dst-address-list" parameters to "General" tab under "IP/Firewall" menu;
*) winbox - moved "src-address-list" and "dst-address-list" parameters to "General" tab under "IPv6/Firewall" menu;
*) winbox - properly clean up SFP module information after it is unplugged;
*) winbox - properly clean up disk after a failed file upload;
*) winbox - properly load band values under "LTE" menu;
*) winbox - removed obsolete "Routing Table" parameter under "IP/Firewall" menu;
*) winbox - show "System/RouterBOARD/Mode Button" on devices that have such feature;
*) winbox - show PVID column by default under "Bridge" menu;
*) winbox - show correct file system type under "System/Disks" menu;
*) winbox - take into account timezone for timed values under "User Manager" menu;
*) wireless - fixed "wmm-support=required" checking;
*) wireless - fixed EAP-TLS authentication;
*) wireless - fixed GUD version in 3gpp information;
*) x86 - added support for Solarflare SFC1920 NIC;
*) x86 - fixed soft-id reading on virtualized x86 installations (introduced in v7.2);
*) x86 - improved support for Intel E810 NIC;
*) zerotier - added support for Controller configuration;Download the new 'RouterOS 7.3' version here: https://mikrotik.com/download
-
-
Horvi
őstag
Sziasztok,
Lenne pár kérdésem a nagyérdeműhöz.Van két hapac2-m és és össze vannak kötve wireguardal. Az egyik a RouterA-hoz a 192.168.1.0/24-es tartomány tartozik a RouterB-hez a 192.168.10.0/24.
A RouterA mögött van egy nginx proxy manager. Azt a RouterA dns címével simán elérem gond nélkül(a legutóbbi segítségetek alapján). Azt szeretném megoldani, hogy a DNS címével elérjem viszont a RouterB mögötti ip tartományból is.
Próbáltam úgy, hogy a RouterB-ben csináltam egy statikus DNS bejegyzést ami a 192.168.1.50-es címre mutat ami az nginx.
Viszont az figyeltem meg, ha a mikrotik beépített dns címe mögötti wan ip frissül akkor mintha nem épülne ki rendesen a wireguard kapcsolat illetve nem lehet az egyik hálózatból elérni a másikat. Csak ha letiltom a statikus dns címet aztán lekapcsolom és vissza a wireguard interfacet meg az ether1/pppoe interfacet. Lehet a kettőnek nincs köze egymáshoz, ez csak egy ilyen megfigyelés volt.
Hogy lehetne ezt jól megcsinálni, hogy rendesen működjön?Felmerült otthon a wifi hatótáv bővítése így egy ap felszerelésén gondolkodom a ház külső falára. A táp PoE-vel lenne megoldva, a fő router-ben(hapac2) van elvileg PoE képes port. Két opció is van az egyik a külső fal lenne az eresz alá kb közvetlenül szóval ott viszonylag fedett részen lenne.
A másik lehetőség egy teljesen fedett boltíves rész ott nem érné nap meg eső meg semmi ilyesmi. Az lenne a kérdésem, hogy milyen ap-t lenne célszerű választani? Nagyjából amit találtam mint lehetőség az a cap/capac/wap/wapac. Mindenképpen rá kéne menni a kültéri egységre?
Illetve nem vagyok benne biztos, hogy az ac képes eszközök megérhetik-e a felárat.Megtaláltam ezt a régebbi hozzászólást és az lenne a kérdésem, hogy ezeket a szabályokat hova érdemes tenni a sorban?
Köszi! -
silver-pda
aktív tag
válasz
silver-pda #17343 üzenetére
Mióta a caplite-t 7.2.1-ről 7.2.3-ra frissítettem, nincs memó miatti reboot.
2 hét alatt a 25MB szabad helyből 1MB-ot használt el. Lassan már a hapac3-t is merem frissíteni. -
Reggie0
félisten
válasz
E.Kaufmann #17441 üzenetére
Alap, virtual wifi interfeszre kell feldobni minden ilyet.
Itthon pl. a mobiltelefonok nalam is a felig guest wifi halozaton lognak: kb. semmit sem csinalhatnak az interneten kivul, egymast sem latjak, de a NAS-ra egy porton, csak olvasasi joggal csatlakozhatnak. -
Reggie0
félisten
válasz
E.Kaufmann #17438 üzenetére
-
E.Kaufmann
veterán
válasz
Reggie0 #17436 üzenetére
Én mondjuk nem is ettől félek, hanem hogy felnyomják a felhőt és azon keresztül változtatják zombivá az eszközöket, akár így ellenem akár mások hálózata ellen is támadást indítva.
Időkorlátot már beállítottam, este hattól reggel hatig nincs felhőzés, úgy is otthon vagyunk, valamint néztem, hogy UDP kapcsolatot nyit egy IP cím felé mindkét klíma. Majd még próbálgatom beszorítani a klímákat, hogy tényleg csak annyit kommunikáljanak, amennyi feltétlenül kell a működéshez. -
Reggie0
félisten
válasz
Istv@n #17434 üzenetére
Miert buknanak? LG is megcsinalta, megsem bukott bele.
Minimum a wifi halozatok listajat es jelszintjet elkuldi a szerverre, a te erdekedben, hogy tudjal wifit valtani.
Ezzel meg is van a geoloc az IP cimedre. A hasznalati szokasaidat, tartozkodasi helyedet ugyis szerver oldalon gyujtik, ahhoz nem kell a halozatod.
-
ekkold
Topikgazda
válasz
Istv@n #17434 üzenetére
Attól még lehet, hogy sokkal ügyesebben csinálják mint gondolnád.
A nagy cégekről meg annyit, hogy tizensokéve, amikor kiderült hogy az Lg tv-k kémkednek (meg a többi is), tulajdonképpen semmilyen következménye nem lett. Gyakorlatilag akkor egy sima drótcápával kimutatták, hogy a beledugott pendrájv tartalomjegyzékét elküldi a neten, méghozzá kódolatlanul! Akkoriban voltak skype futtatására képes tv-k, kamerával és mikrofonnal felszerelve... vajon mekkora az esélye, hogy ezekben volt hátsó ajtó, amit a gyártó (és akinek még kiadta, pl. titkosszolgálatok) ezt távolról aktiválni tudja? -
Istv@n
aktív tag
válasz
E.Kaufmann #17422 üzenetére
Ugyan tüzetesen nem nézem a logokat napi szinten, de eddig nem vettem észte semmi rendkívülit.
Mondjuk én sonoff és xiaomi termékeket használok, ezek pedig talán már akkora gyártók, hogy nem kockáztatnak ilyesmit... Ha kitudódna elég nagyot buknának.... -
Reggie0
félisten
válasz
taki01 #17430 üzenetére
Volt rola doksi is, de ezek szerint leszedtek:
https://help.mikrotik.com/docs/display/ROS/Container
7.1rc3-ban van benne, az volt az egyetlen verzio, azota nincs.Itt a forumban talalsz maradekot a mikrotikes manualbol: [link]
MIPS architekturan is mukodott emlekeim szerint. TILE-re is megcsinaltak, csak azt a docker nem tamogatja, igy nem volt kesz dockeres cointainer.
-
taki01
őstag
Valaki tud valamit, hogy áll a mikrotiken a docker konténerizáció? Azt tudom, hogy 64bit-es arm soc kell hozzá (meg arm64-es image-k), ja és persze elegendő háttértár és memória
. A dokumentációk között nem találtam még semmit. Egy forum bejegyzés van, hogyan lehet futtatni egy teszt konténert.
-
user12
őstag
válasz
Reggie0 #17427 üzenetére
Ezt:
"A gateway IP címet írom be és OK/Apply után átírja erre.
Ezért nem nagyon értem.
Sőt azt se, hogy mi alapján van az, hogy valahol átírja és van ahol meghagyja a beírt IP címet (pl a középső elemnél)."Mondjuk ezeket még rá is lehet fogni bugra, ahogy írtátok, hogy még koránt sem tökéletes a 7-es verzió
Igazából az érdeklődésem középpontjában a % jelölés áll, hogy ez mit takar. -
jerry311
nagyúr
-
Reggie0
félisten
válasz
user12 #17423 üzenetére
Az atjaro alapbol azt jelenti, hogy ha nem tudod az IP cimhez tartozo gep MAC cimet, akkor az atjaronak megadott gep MAC cimere kell kuldeni a csomagot. Egyes esetekben, ha pl. egy switchen van szomszedos IP cimu, akkor siman megkerdezi egy ARP keressel, hogy mi az IP-hez tartozo MAC cim es oda fogja kuldeni. Ha ezt nem lehet megtenni, mert mondjuk nem szomszedos a gep, azaz nem egy kozos L2 retegen vannak(pl. swithen keresztul), akkor az ARP keresre nem fog valasz jonni. Ilyenkor kell megadni az atjarokent(routerkent) funkcionalo gep cimet, mint atjarot, ekkor annak a gepnek kerdi le ARP-al a MAC cimet, es oda kuldi a csomagot. Az atjaro tudja a csomagban levo celcim IP cime alapjan, hogy az nem neki jott igazabol es forwardolja(tovabbkuldi) a csomagot vagy egy masik atjaronak, vagy ha a routeren L2 retegen, akkor kozvetlen oda ahova kell. Ez az alap koncepcio. Tehat minden networkhoz(ipcim+mask) kell egy atjarot megadni, ha az a 2-es retegen(MAC) nem szomszedos gep, mert nem lehet hozza MAC cimet lekerni.
A specialis esetek peldaul a tunnelek, mert azokon az L2(MAC) reteg nem feltetlenul van implementalva, igy nem is lehet beszelni MAC cimrol, nem is lehet lekerni. Az ilyen interfeszek jellemzoen egy csokent viselkednek, azaz amit bedobsz egyik oldalon azt a masik oldalon egyetlen gep fogadja. Ilyen esetekben az atjaronak csak magat a fizikai interfeszt lehet megadni, hiszen csak egy gep van a tuloldalt, szinte tok mindegy milyen IP cimmel. Ezeknel emiatt van, hogy nem is lehet IPcimet megadni atjarokent.
-
Istv@n
aktív tag
válasz
E.Kaufmann #17416 üzenetére
Nekem a vendég wifin vannak... Csak internet, lan eszközökhöz nincs hozzáférésük...
-
user12
őstag
Sziasztok
Az IP route táblában mit jelentenek az egyes interface nevek vagy IP címek előtt a % jelek?
Kerestem volna róla infót, de sehol nem találtam.
Valamint: 7-es verzió esetén másnál is fennáll a következő anomália: tetszőleges route módosítása esetén eltűnik a bejegyzés a web gui-ról, de kilépés-belépést követően újra ott van.
Köszönöm előre is.
-
Audience
aktív tag
válasz
E.Kaufmann #17416 üzenetére
Külön VLAN-ban van minden amiben nem bízom és VPN-en keresztül érhetőek csak el. Amelyik felhő nélkül szigetüzemben nem megy és nem bízom a felhőben/cégben azt nem használom.
-
E.Kaufmann
veterán
Kínai Wifis klímáknál ki milyen óvintézkedéseket tett, ha mégis szerette volna mobilról használni? Külön szeparált wifi háló? Időzített hozzáférés a nethez, sávszél korlátozás? Speciális tűzfal szabályok? AUX klímákról lenne szó, de gondolom hasonlóan működik a többi is, valami felhős szerverre jelentkezgetnek befele és szedik le a parancsokat.
-
jerry311
nagyúr
válasz
Reggie0 #17413 üzenetére
Csak a fizikai interface megy le, bond végig up (a logok szerint). A SH4 hivatalosan nem támogat balance-rr-t, de működik. [link]
Nem is a bond a lényeg, mert ez eleve workaround lett volna. Az igazi probléma, hogy a fizikai interfaszok lemennek 4 másodpercre. Nekem az is jó lenne, ha 1 fizikai interface-t használok (egyébként jelenleg visszaálltam erre, bonding nélkül), és az lenne folyamatosan UP. -
jerry311
nagyúr
válasz
Reggie0 #17411 üzenetére
Próbáltam többet is. Mindegy, az eredmény (vagy hiba) ugyanaz, ha valamelyik fizikai interface lemegy, akkor (és itt javítanom kell az első hsz-t) valószínű, hogy 4 másodpercen át megakad a játék is. De nem mindig, van amikor ránézek a logra a meccsek után és azt látom, hogy az 1-2 óra játék alatt volt 5 interface down, de nem akadt meg a játék.
-
jerry311
nagyúr
Érdekes problémába ütköztem. (UK Virgin Media)
Itt ez a Super Hub 4 (SH4), van rajta 4 Ethernet port. Ha nem is hivatalosan, de támogatja a balance rr bondingot. Ez azért jó, mert 1050 Mbps jön ki belőle, míg 1 porton legfeljebb 940M. Na de nem is ez a lényeg, hanem hogy a a SH4-re kötött 4011 portjai véletlenszerűen eldobják a kapcsolatot 4 másodpercre. Ha 1 port van bekötve, akkor az, ha több, akkor véletlenszerűen bármelyik, egyszerre akár több is. Ami miatt bondingot próbáltam az a redundancia, reménykedve, hogy az online játékok UDP forgalmának mindegy lesz néhány elveszett csomag, de nem. Minden esetben 4 másodpercig nincs semmi, és ez bizony eldönthet meccseket.
Egyelőre ott tartok, hogy egy 5 portos Netgear-t dugtam a SH4-re, hátha ezzel kompatibilisebb, stabilabb. Netwatch figyeli a 8.8.8.8 elérhetőségét, mert a mini Netgear ugyan tud VLAN-okat, és IGMP-t, de nincs rajta sem SNMP, sem semmilyen log. Ha ezzel nem tapasztalok 4 másodperces szakadásokat, akkor egyelőre így marad, de jobb lenee ha csak vezeték lenne a SH4 és a 4011 közt.Minden más port, ami nem a SH4-re megy az stabil.
A kérdés, hogy mit lehet ezzel kezdeni?
Hol nézelődjek keresgéljek még hibát kutatva? -
-
adika4444
addikt
válasz
silver-pda #17401 üzenetére
Igen, az valószínű RNDIS-t használ, a /interface/lte helyen is látnod kell. Elég sok mifi megy így MikroTik-kel, két szépséghibával
- Az akkus darabok (mint az én ZyXEL WAH7706-om) telep nélkül nem mennek, viszont az nem okvetlen szereti a nonstop tápellátást.
- Másrészt pedig DHCP-vel auto kér IP-t ettől az interfésztől, emiatt az IP-je, routing-ja dinamikus lesz, és ebbe nem igazán lehet belenyúlni. Azaz kézi ipkonfig-ra a WAN-nak használt USB-n nem igazán van lehetőség sajna.#17404 yodee_:
Igen, sajna PPP emulációs módban (az én Huawei E3372-153 is ilyen) van némi sebességcsökkenés, meg nem is LTE if-ként látszik, ami miatt elég sok mobilhálózat-specifikus beállítás nem vagy csak nehezen érhető el. -
yodee_
őstag
válasz
silver-pda #17403 üzenetére
Az jobb mert valami olyat olvastam hogy a ppp emuláció esetén sebesség korlát van. Milyen eszközöd van?
-
silver-pda
aktív tag
válasz
yodee_ #17402 üzenetére
PPP Client-nél nem tudom kiválasztani, de lett egy LTE típusú interface a listában.
Sztem ez nem PPP típusú.
A listában is vannak egyes eszközök amik sima LTE, van ami meg PPP. Mondjuk ami nálam van, az nincs felsorolva és nem is stick, hanem MIFI.
Vhogy ki kellene engednem az lte-t a tűzfalon, hogy tesztelhessem. -
yodee_
őstag
válasz
silver-pda #17401 üzenetére
PPP -> PPP client-nél ha ki tudod választani az usb1 interface-t akkor igen.
-
silver-pda
aktív tag
Ha USB-n csatlakoztatok egy USB stick/mifi eszközt és a "System -> Resources -> USB"-nél megjelenik + "Interface lists"-ben megjelenik egy LTE típúsú interface, akkor az elvileg használható is?
Új hozzászólás Aktív témák
Hirdetés
- BESZÁMÍTÁS! MSI B550 R7 5700X 32GB DDR4 500GB SSD RTX 3070 8GB ZALMAN Z1 Plus Be quiet! 650W
- Telefon felvásárlás!! Samsung Galaxy Note 10+/Samsung Galaxy Note 20/Samsung Galaxy Note 20 Ultra
- Azonnali készpénzes AMD Radeon RX 6000 sorozat videokártya felvásárlás személyesen/csomagküldéssel
- ÁRGARANCIA! Épített KomPhone i5 12400F 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- Update 06.12. Bomba árak 2025-ben is! Üzleti - Consumer laptopok DELL FUJITSU HP LENOVO
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged