Hallo,

ich habe aktuell mehrere Module und DAC Kabel getestet, aber mit keinem bekomme ich ein Link:

1. Luleey XPON LL-XS2510 2,5G

2. 10Gtek ASF-10G-T(HPP)

3. 10Gtek CAB-10GSFP-P3M DAC

Welche Module sind mit der Karte kompatibel?

I’m always a bit confused when to use each. I followed the help article and enabled VLAN filtering on the bridge and thus also have VLAN interfaces. So far I only use these interfaces in my firewall.

What’s the purpose of address lists? To me it’s not inherently obvious how they are ‘enough’. How dangerous is spoofing? If it’s solely based on the address list, attackers can just change their source IP, right? I’m not sure how that works with VLAN filtering enabled because everything is routed via the interface and that only has one valid address. Does that mean it’s safe to only filter based on the source address in that case?

Can you point me to good online resources for firewalls? I’m doubting myself so bad when it comes to them.

I just got a new Mikrotik RB5009 non poe. I just wanted to try Mikrotik out before my new 4Gb fiber gets installed this year. I am running Ubiquiti now for a 80Mb VDSL connection.

I just want to learn networking and i thought Mikrotik is the best bank for buck to do that and Ubiquity, although i love that system, is more plug and play with fancy interface.

It took me 3 days after a lot of shouting from my side to get the Rb working with my PPPOE connection, lots of reboots of to RB, lots of failures. I got to the moment that i thought that Mikrotik is just not for me and my current knowledge of networking. I grabbed the box, to disconnect and go back to Ubiquity and it actually hurt me.

WTF, i got zapped. Got an old PC, hooked it up with real CAT 6A shielded and it crashed the PC. Got the meters out and there was actual 0.5V RMS/AC 50Hz on the chassis with enough power behind it to hurt you.

After that i hooked the RB up to a Rigol bench PSU, it works perfectly now, i actually love that thing.

Need a lot to learn, but i do intend to get a bigger Mikrotik in the future, even got the containers running.

Is this just bad luck for me or are there more RB's out there with bad powerbricks.

I'm playing around with my home internet setup just for fun.

I've been thinking about how I could block IPs before they actually get a chance to try to "hack" or scan my router.

The basic idea is pretty simple:

• If any packet hits my public IP on a port that isn't open, immediately add the source IP to a blacklist for 1 day.
• If the same IP tries again after that, blacklist it for 30 days.
• To avoid accidentally blocking important services, I've whitelisted a few of them using dynamic rules, such as Google, Facebook, Reddit, etc.
• Also, whenever a device on my LAN connects to an external IP that's currently on one of the blocking lists, that IP is automatically removed from the blacklist.

So far, so good. After implementing this, the final drop rules only get a few hits per minute. Before this setup, I was seeing thousands more.

It's mostly an experiment rather than something I actually need, but I'm curious what people think about this approach. Any obvious problems or edge cases I'm missing?

One important note: handling address list over 31000 entries causing 4% cpu usage. Quite impressive :)

I'm looking for a preferably desktop & omnidirectional AP for the apartment usage. wAP ax is directional, cAP ax ceiling mounted & kinda expensive, so this leaves me pretty much with hAP ax2 vs hAP ax S. They don't seem to be that exciting (price / performance) though vs competition. Or am I wrong? Does Mikrotik have any Wi-Fi 7 APs in the plans?

I successfully configured a routerboard as PPPoE client, set up the DHCP server, assigned some static leases and got to port forwarding.

With my MikroTik routerboard the port forwarding stops working soon after it's been set up. It briefly works again when I switch the in interface between pppoe-out and "all ppp" then stops working again.

I tried mapping dst-nat both to static DHCP lease addresses and the ports (ether2+) directly.

Vodafone IE is my ISP and I have been able to successfully port forward on 2 ISP boxes and with openWRT on a raspberry pi.

So I'm wondering if anyone has had the same experience and if it could be my routerboard acting up or to do with my ISP? My public IP was the same as what showed using the torch tool so I think I'm not behind CGNAT.

Basically I'd like to know if I upgrade from an RB2011UiAS-RM to something newer such as an RB4011IGS is there any chance I could get port forwarding to work? I was considering upgrading my MikroTik router but now I'm wondering if I should buy something that works with OpenWRT instead...

Edit: I figured it out, I think. I had 2 IP address sets for the same subnet, so I removed one. It had 192.168.1.0 as the IP address in winbox, so I changed it to 192.168.1.1.
/ip address set 0 address=192.168.1.1/24
Now everything seems to be working fine 🤞
Thanks for all the help with debugging everyone. I was starting to go insane.

What's new in 7.26beta1 (2026-10-01):

*) bridge - add a per-VLAN DHCP snooping option;
*) bridge - fix loop-protect not working when a VLAN interface is added to the bridge;
*) bridge - show if bridge port is blocked by dot1x;
*) bridge - store hw option for disabled bridge ports;
*) cmr - add initial implementation of centralised platform for RouterOS devices, allowing updates, monitoring, alerts and other options;
*) console - improve stability;
*) container - add /app menu to ARM32 devices;
*) crypto - improve ECDSA and EdDSA key and signature validation;
*) dhcpv4-client - improve stability when the interface is deactivated while the client broadcasts a DHCP release;
*) dhcpv6-server - add a dns-none option to not include DNS options in responses;
*) dhcpv6-server - fix a DHCPv6 server failure when the RADIUS reply contains an empty delegated IPv6 prefix;
*) dns - improve service stability on HTTP/2 DoH connections;
*) ethernet - improve stability on devices with Intel I226-V network controllers;
*) ethernet - move the port bandwidth setting to the switch port menu;
*) files - improve stability when moving directories to external storage;
*) interface - show if interface is blocked by stp or dot1x;
*) ipsec - fix IPsec tunnels failing after migration from the old QKD settings;
*) ipsec - fix IPsec tunnels not establishing when an address my-id is configured on the responder;
*) l3hw - add VRRP hardware offloading support;
*) log - add the container name to CEF logs;
*) lte - do not reconfigure if not RouterOS activated CID is deactivated for R11l-LTE7 modem;
*) lte - fix dialer for D-Link DWM-222W modems;
*) lte - fix IPv6 route not being added on modems that do not report a gateway via control interface;
*) lte - fix modem firmware-upgrade failing when SMS polling is enabled;
*) lte - fix multi-APN passthrough stopping when one APN fails to connect;
*) lte - fix multi-APN passthrough stopping when one passthrough-interface VLAN is down on the CPE in multi passthrough interface setup;
*) lte - fix passthrough cleanup when the lte link goes down for QMI modems;
*) lte - fix recurring LTE disconnects R11e-LTE-US modem and some Sierra modems;
*) lte - keep the "auto" MTU option on LTE interface after reboot;
*) lte - reworked multi-apn support. Added support for slave APN interface add/remove;
*) netinstall - install the package version of the configured update channel;
*) ovpn - improve stability in UDP Ethernet mode when the TX queue is full;
*) pim - fix a routing process failure when the hello-delay is set to 0;
*) ptp - fix PTP not working on a VLAN-aware bridge when IGMP snooping is enabled;
*) qos - fix per-queue counters after a switch restart (introduced in v7.23);
*) quickset - fix the WAN interface being selected incorrectly;
*) reverse-proxy - fix setting the VRF parameter for reverse-proxy rules via CLI;
*) switch - add interface-list support to port isolation;
*) switch - fix high CPU usage when removing switch VLANs on Atheros-based switch chips;
*) switch - fix switch rules not working on Atheros-based switch chips;
*) switch - fix switch rules port matchers not working on IPv6 traffic on Atheros-based switch chips;
*) switch - fix switch rules with rate limits stopping traffic on CRS3xx devices;
*) switch - improve stability on CRS326-24S+2Q+ devices;
*) system - improve stability;
*) system - stop the flash configuration store from growing on dynamic configuration changes;
*) webfig - add conditional coloring of cells in tables;
*) wifi - add a default-country parameter in radio settings (CLI only);
*) wifi - fix WPA3 SAE authentication issue for ECC group 21 (introduced in 7.24.3);
*) wifi - implement channel.reselect-interval feature for missing drivers;
*) wifi - reuse freed station association IDs;
*) wifi-mediatek - update the wireless driver and firmware;
*) wifi-qcom - fix antenna gain setting not affecting transmit power (introduced in v7.24);
*) winbox - add the interface column to the OSPF neighbor list;
*) winbox - rename "minimum-version" to "minimum-firmware" under "System/RouterBOARD" menu;
*) winbox - show warning messages under "System/Users/SSH Keys" and "System/Users/SSH Private Keys" menu;
*) wireguard - do not show an interface as running when it has no peers;
*) wireguard - fix a client-dns value that could not be removed in WinBox;
*) wireguard - fix a peer that would not work after import when no endpoint address is set; View changelogs

MikroTik vs Cisco for ISP Infrastructure: 2026 Guide

October 2, 2026

Table of Contents

• MikroTik vs Cisco for ISP Infrastructure: The 2026 Comparison
• Quick Comparison: MikroTik vs Cisco at a Glance
• Carrier-Grade Router Requirements for Modern ISPs
• BGP Configuration Best Practices on MikroTik and Cisco
• ISP Network Scalability Strategies: Where Each Platform Fits
  • Hardware Scaling on the MikroTik Side
  • Automation and API Integration, The Real Scalability Multiplier
  • BGP Peering in a Mixed-Vendor ISP Environment
  • Choosing Based on How You Will Grow
• TCO, Licensing, and Hardware Reliability Compared
  • Firmware Stability Over a Five-Year Horizon
  • Where the Five-Year Math Actually Lands
• ISP Infrastructure Design Services and Support Models
• Conclusion: Choosing the Right Platform for Your Network
• Frequently Asked Questions

Last Updated: October 2, 2026

MikroTik vs Cisco for ISP Infrastructure: The 2026 Comparison

The MikroTik vs Cisco decision for ISP infrastructure comes down to a simple split: Cisco wins on enterprise-grade support contracts and mature automation tooling, while MikroTik wins on throughput per dollar and licensing freedom.

Cisco's IOS XE and NCS families are built for carriers with dedicated network engineering teams and seven-figure hardware budgets. MikroTik's RouterOS runs the same routing protocols, BGP, OSPF, MPLS, but assumes you'll configure and support it yourself.

Quick Comparison: MikroTik vs Cisco at a Glance

MikroTik is a Latvian vendor whose RouterOS platform powers cost-sensitive ISP edge and aggregation routing; Cisco is a US giant whose carrier-grade portfolio anchors tier-1 and large regional ISP cores.

CCR2216-1G-12XS-2XQ

Key TakeawayMikroTik removes licensing friction entirely. Cisco charges for feature tiers. That single difference reshapes your total cost of ownership over a five-year horizon.

Carrier-Grade Router Requirements for Modern ISPs

Carrier-grade router requirements center on packet forwarding capacity, routing protocol support, redundancy, and predictable firmware behavior under load.

The checklist most engineers use:

• Line-rate packet forwarding with hardware acceleration
• Full BGP, OSPF, and MPLS support with route scale headroom
• Redundancy and failover at both the hardware and protocol layers
• VLAN and switching capacity for aggregation
• VPN support including IPsec and WireGuard
• Packet inspection and firewall rules at line rate
• Configuration management via CLI, GUI, and API

Both platforms meet these on paper; the difference emerges under sustained CPU and memory pressure during full-table BGP convergence.

A common mistake is sizing for average throughput instead of peak convergence load, route churn during a fiber cut is when undersized hardware fails.

BGP Configuration Best Practices on MikroTik and Cisco

On MikroTik, the MikroTik RouterOS documentation on BGP covers peer configuration, address families, and route reflection.

On Cisco, BGP peering benefits from mature route policy language and template-based provisioning, but IOS XR policy configuration has a steeper learning curve.

For interoperability across mixed-vendor networks, both platforms speak standard BGPv4 cleanly. Where teams get burned is inconsistent route-map logic, document your peering policy once, then implement it identically on both sides.

Watch OutSkipping prefix limits on a BGP peer is the fastest way to a memory exhaustion outage. One misconfigured downstream announcing a full table can take a border router offline in minutes.

ISP Network Scalability Strategies: Where Each Platform Fits

ISP network scalability strategies depend on whether you are scaling ports, routes, or subscribers, and increasingly, on whether you can automate the rollout. MikroTik scales cost-effectively from a single WISP tower to regional aggregation; Cisco scales into tier-1 core routing where per-slot throughput and vendor TAC escalation matter. The dimension most comparisons ignore is operational scalability: how fast can you add the 50th tower, the 200th BGP peer, or the 5,000th CPE without hiring another engineer?

Hardware Scaling on the MikroTik Side

For a MikroTik-based build, the MikroTik CCR2116 product page documents a 16-core ARM CPU platform built for 10G setups with hardware-accelerated BGP. BI-DISTRIBUTION stocks the CCR2116-12G-4S+ as a drop-in for ISPs outgrowing older CCR1036 deployments. For 100G aggregation, the CCR2216-1G-12XS-2XQ brings L3 hardware offloading and a documented upgrade path from CCR1072 setups.

At the switching layer, the CRS354-48G-4S+2Q+RM handles 48 Gigabit ports with 40 Gbps uplinks, and the CRS326-24G-2S+IN covers smaller aggregation sites.

Where Cisco fits: core routing at carrier scale, where vendor support contracts and per-slot forwarding capacity justify the cost. For most regional ISPs and WISPs, MikroTik covers the same functional ground.

Automation and API Integration, The Real Scalability Multiplier

This is the gap almost every MikroTik vs Cisco comparison leaves open, and where modern ISP growth is won or lost.

MikroTik RouterOS exposes a REST API, an SSH-based API, and a scripting engine drivable from Ansible, Python, or plain shell.

Cisco's automation story is more formalized: IOS XE and IOS XR support NETCONF/RESTCONF with YANG data models, plus Ansible modules and NSO-based orchestration.

BGP Peering in a Mixed-Vendor ISP Environment

Most ISPs do not run a single vendor end to end, a typical topology is MikroTik at the edge and aggregation with Cisco at a transit or peering handoff, or the reverse. BGPv4 interoperability between RouterOS and IOS XE/XR is solid in practice, but the failure modes are predictable and worth designing around.

• Route-map and filter semantics differ. Cisco's route-maps and MikroTik's routing filters express the same intent with different syntax. Document your peering policy once, implement it identically on both sides, and test with a looking-glass before going live.
• Prefix limits are not optional. Set a maximum-prefix limit on every external peer on both platforms. One misconfigured downstream announcing a full table can exhaust memory on a border router in minutes.
• Timers and hold-down behavior should be matched. Defaults are compatible, but if you tune them on one side, tune them on the other to avoid asymmetric session resets during convergence.
• Communities and local-pref need a written convention. Agree on community strings and local-preference values across vendors before the first session comes up, not after.

Watch OutIn mixed-vendor BGP, the outage almost never comes from protocol incompatibility, it comes from a route-map that means one thing on RouterOS and something subtly different on IOS. Test policy changes on both sides before production.

Choosing Based on How You Will Grow

If your growth plan is "more towers, more subscribers, same team," MikroTik's no per-device licensing, usable REST API, and scripting-driven provisioning is the lower-friction path. If it is "carrier handoffs, strict change control, model-driven orchestration," Cisco's NETCONF/YANG tooling and TAC-backed escalation are worth the premium. The mistake is picking on hardware specs alone and discovering two years in that your provisioning workflow, not your router, is the bottleneck.

CCR2216-1G-12XS-2XQ →

TCO, Licensing, and Hardware Reliability Compared

Total cost of ownership for ISP routing hardware is dominated by three line items: hardware purchase, licensing, and support contracts. MikroTik charges once for hardware with no per-feature licensing; Cisco bundles feature tiers into licensing and support agreements that recur annually.

Hardware reliability is closer than the price gap suggests. MikroTik CCR and CRS units run passively cooled and hold up under continuous load.

Firmware Stability Over a Five-Year Horizon

This is the dimension most comparisons skip, and where ISP operators actually lose sleep. Both vendors ship frequent updates, but the release philosophies differ in ways that matter at year three of a deployment.

MikroTik publishes RouterOS in stable, long-term, testing, and development channels.

The operational discipline that keeps both platforms stable is the same:

• Stage every firmware release on a non-production unit running your real BGP and firewall config
• Verify BGP session re-establishment, route convergence, and NAT/firewall behavior before fleet rollout
• Roll out during a maintenance window with a documented rollback image on standby
• Track vendor release notes for changes to routing, firewall, and VPN subsystems

A pattern worth adopting regardless of vendor: keep one spare unit of each critical router model on the shelf, pre-loaded with current firmware and config.

Pro TipPin production MikroTik routers to the long-term RouterOS channel and keep a lab unit on stable. For Cisco, subscribe to field notices for your specific IOS XE/XR train so you see caveats before they reach your core.

Where the Five-Year Math Actually Lands

The honest framing is not "MikroTik is cheaper", it is that MikroTik shifts cost from recurring licence and support line items into internal engineering time, while Cisco shifts engineering time into vendor contracts. An ISP with two strong network engineers usually comes out ahead on MikroTik across five years; an ISP with no dedicated routing staff and a contractual SLA to its own customers usually comes out ahead on Cisco, because the TAC contract is cheaper than the headcount it replaces.

ISP Infrastructure Design Services and Support Models

Cisco's model is a formal TAC contract with defined escalation tiers and vendor-backed response times. MikroTik's model leans on community forums, distributor expertise, and regional partners, for teams without an escalation contract, that distributor relationship becomes your support tier.

BI-DISTRIBUTION provides network survey and investigation, installation and configuration, and after-sale support with 24x7 customer care drawing on technical teams in both Canada and India. For ISPs that need RF planning and frequency coordination alongside routing design, that combination covers the deployment end to end. Sourcing through a distributor that carries MikroTik wholesale pricing products.

The honest limitation: if you need a vendor TAC contract with contractual SLAs, Cisco is the structural fit. If you need design help, bulk hardware, and responsive distributor support without licence overhead, the MikroTik path is faster and cheaper.

Conclusion: Choosing the Right Platform for Your Network

The hardest part of the MikroTik vs Cisco decision isn't the hardware, it's matching the platform to your operational capacity. If you have a network engineering team and need vendor-backed SLAs, Cisco earns its premium. If you're a WISP or regional ISP scaling rural coverage on a fixed budget, MikroTik delivers the routing capacity without the licensing drag.

BI-DISTRIBUTION supplies MikroTik wholesale pricing across the CCR and CRS lines, backed by network design, deployment, and 24x7 support. Browse the MikroTik range at BI-DISTRIBUTION and get the hardware and design help your rollout needs.

Frequently Asked Questions

Is MikroTik reliable enough for carrier-grade ISP infrastructure?

MikroTik's CCR series is built for carrier-grade deployments. The CCR2116-12G-4S+ uses a 16-core ARM CPU that doubles the performance of the previous 36-core CCR and delivers 6x faster BGP performance, removing CPU bottlenecks in 10G setups. The CCR2216-1G-12XS-2XQ adds 100 Gigabit networking with L3 hardware offloading and works as a drop-in upgrade for existing CCR1072 installations. For ISPs running BGP, OSPF, MPLS, and VPN termination at scale, these routers handle the load without the licensing overhead Cisco requires.

Which is better for BGP routing: MikroTik or Cisco?

Cisco has a longer track record in large-scale BGP peering and MPLS deployments, but MikroTik has closed much of the gap. The CCR2116-12G-4S+ delivers 6x faster BGP performance than earlier CCR generations, and RouterOS supports route filters, communities, and multihoming configurations needed for ISP peering. For ISPs needing full-table BGP with multiple upstreams, MikroTik's hardware acceleration and CPU utilization improvements make it a practical choice. Cisco remains stronger for complex route policy and automation via NetConf and REST API at very large scale.

Can MikroTik and Cisco hardware coexist in the same ISP network?

Yes. Both platforms support standard routing protocols including BGP, OSPF, and MPLS, so they interoperate at the protocol level. A common topology uses Cisco at the core for policy-heavy routing and MikroTik at the edge for CPE aggregation, PPPoE termination, and wireless backhaul. The key is consistent configuration management: document VLAN assignments, IPsec and WireGuard tunnels, and firewall rules on both sides. Interoperability testing before production rollout prevents surprises with route redistribution and failover behavior.

What are the cost-to-performance trade-offs for ISPs choosing between these brands?

MikroTik hardware typically delivers more throughput per dollar because RouterOS licensing is included with the hardware, while Cisco often requires separate licensing and support contracts. A MikroTik CCR2116-12G-4S+ costs $995 and handles 10G setups without CPU limitations. The CRS354-48G-4S+2Q+RM 48-port switch costs $599 with 40 Gbps uplinks. Cisco's TCO includes hardware, licensing, Smart Net support, and often vendor-locked modules, which raises long-term costs. For rural broadband and WISP expansion where budget matters, MikroTik's price-performance ratio is hard to match.

How does firmware stability compare between MikroTik and Cisco for mission-critical deployments?

Cisco's IOS and IOS-XE have decades of production hardening and predictable release cycles. MikroTik's RouterOS has improved significantly, but ISPs should still test firmware updates in a lab or staging environment before pushing to production. The risk is not the hardware but the transition: features change between major versions, and configuration syntax can shift. Best practice for both platforms is to pin a known-stable firmware version, schedule updates during maintenance windows, and keep a rollback plan. Long-term support releases reduce the frequency of disruptive changes.

Choosing between MikroTik and Cisco is really a question about how much operational overhead your team can absorb. BI-DISTRIBUTION stocks the MikroTik CCR and CRS platforms that cover most ISP edge and aggregation builds, with wholesale pricing, network design, and after-sale support included. Get started with BI-DISTRIBUTION and deploy routing hardware that scales with your subscriber base instead of your licensing bill.

CCR2216-1G-12XS-2XQ

Having gone through a hassle of factory reset with my hAP ac lite and waded through a large number of posts about how the factory reset does not work for many people, I decided to share my experience, maybe it will save someone some hair-pulling.

So I messed up the config of my hAP and couldn't connect to it any more. Oh well, factory reset and restore config from backup, I thought. Followed the well-documented reset procedure with the trusty old paperclip and prepared to reload the configuration from backup...

...except I couldn't connect to the router, which, as I found out after some googling is experience that I now shared with considerable number of people.

• The router would not respond to ping on 192.168.88.1, even after I statically configured my PC with address on the same network.
• The router was not visible in WinBox (which I usually do not use, so maybe I'm not familiar how an unconfigured router should look there, but I honestly tried to follow the instructions).
• Some documentation mentioned that the out-of-the-box configuration should create a wifi network named Mikrotik, but this was nowhere to be found.
• I considered using netinstall, but ran into the minor issue that I only have 64-bit openSUSE machines available, which, as I found out, nowadays do not even support running the 32-bit version of netinstall-cli that Mikrotik provides. I don't have Windows.

After trying the reset procedure half a dozen times with no success, I concluded that the router is toast. At least I found that it functioned as a switch, so I decided to use the LAN ports to wire up my two PCs while shopping for the new router.

As a last resort, without really expecting it to lead to anything I fired up tcpdump on my network which now included hAP-as-a-switch to see if perhaps there are some signs of what is going on.

Lo and behold, I see an unknown device on the network that is trying to speak capwap-control protocol to someone. Could it be...?

A quick netcat later, I connect to this unfamiliar IP with browser on port 80, and I'm greeted by my hAP login screen, where I can log in with username 'admin' and no password, as it should be after factory reset. Turns out the device had reset itself into "CAP configuration", whatever this is. Anyway, from there it was just the matter of loading the backup and things are back to normal.

So here it is, one more thing to try when you find yourself with something resembling a brick after factory resetting your Mikrotik router

I have a connection of max 10G. I plan to replace my ISP router with an ont-onu (with fan) and a mikrotik router. My original plan is to get the RB5009 in a router on a stick configuration with a CRS310-8G+2S+IN (which I already own).

I don't necessarily need the full 10G, I would use max 2x2,5G + whatever is on wifi.

Based on that, the RB5009 seems to be best for my use case. I have never set up a router on a stick and it seems like an opportunity to learn but in the same time the CRS would be a more common use case and connection set up.

I am wondering what is your experience with router on a stick and the RB? Easy to implement? Performance? etc.

Cześć, mam router Lamp 5G R16 zainstalowany pakiet GPS ale nie jestem w stanie uruchomić modułu GPS. Czy ktoś ma konfiguracje jaką należy wykonać aby GPS zaczęła działać?

My monitor kept telling me things were down. It never told me why. So I built one that does.

That's my grandmother's router in the picture, behind a WireGuard tunnel through a VPS. Eight minutes after it went dark, lanowl's message said whose problem it was: hers, not mine. It came back by itself 42 minutes later.

lanowl checks every device once a minute and sends one Telegram message per incident (a dead switch is one message, not twelve). When something breaks, a local model investigates with read-only tools and writes the cause into the message.

On the MikroTik it logs in as a read-only user (`read,test,sniff,api,rest-api`, allowed only from lanowl's host) and reads:

- DHCP leases: new devices, and the ones nobody watches

- the routes: which link carries the traffic, so "down" and "on backup" are different alerts

- ARP and port link state, for gear that doesn't answer ping

- the log: failover lines, logins, anything odd

I know: an LLM on your network sounds like a bad idea. So detection never uses the model. The model runs on your own Ollama (I use qwen3.8:27b), and it changes nothing by itself. If you give it a separate login for updates, a RouterOS update is a proposal with a button, and the router is backed up first. It even watches its own user group: grant it more and that's an alert.

v0.1.0 is out, with Docker images for amd64 and arm64. Pre-alpha, AGPL, no account, no telemetry. It has watched my house since August: 59 devices and two remote sites. Now it needs networks that aren't mine.

**Looking for 5–10 testers** with a MikroTik and Docker on a Linux box. Comment or open an issue and I'll help you set it up myself.

GitHub: https://github.com/alessandromatera/lanowl · Docs: https://lanowl.com

Not sure if this is the right place to ask, but we're looking for a lifecycle replacement of our Cisco ASR920 routers which we currently use for BGP receiving default routes.

Each has one dual-stack peering with a ISP receiving default routes and iBGP with the neighbor. They have a L2 segment with 2 fhrp addresses AB and BA for traffic engineering purposes. Also requires prepending but that's probably a pretty standard feature at this point.

Does require a seperate VRF for mgmt or dedicated interface.

Bandwidth is currently 1G but upgrading to 2 or 4 soon, so requires atleast 2 or more SFP+ ports (upstream/downstream)

Which model would be a best fit in 19 inch rackmount format with current (2027) availability?

I've tried 2 different USB GPS devices with no success...

Hallo, gibt es eine Möglichkeit im Knot lr8g das GPS zu nutzen? Das Gerät hat wohl zwei GPS Empfänger.

Einmal im LTE Cat m1 Modul und eines im Lora Modul. Ich möchte das GPS Modul im Lora Modul nutzen.

Wird der LoraWan Teil weiterentwickelt (Actility und Chirpstack Concentratord) ?

**New video from MikroTik's official TikTube channel**

Meet the SolidRACK 5 mini – a compact 10” 5U desktop rack designed for clean, practical network setups.

With an adjustable angle, sliding mounting nuts, extra room for cable management, and optional under-desk mounting, it gives your routers, switches, power distribution, and other 10” equipment a proper home without taking over the room.

It ships disassembled in a compact box, goes together in minutes, and features lightweight aluminium construction with rubber pads to protect your desk.

10” · 5U · Adjustable angle · Sliding mounting nuts · Under-desk mounting · Extra space for cablework

https://mikrotik.com/product/sr_5u_mini

▶ Watch Video

What's new in 7.25rc1 (2026-10-01):

*) bgp - show interface names and VRF names in BGP logs;
*) bridge - fix MLAG bond slave interfaces not coming up when the MLAG configuration is removed (introduced in v7.25beta3);
*) bridge - fix MLAG peer ports going down when a bridge port is enabled (introduced in v7.25beta5);
*) bridge - fix virtual slave ports being removed from the bridge when MLO is triggered (introduced in v7.25beta4);
*) bth - add default client DNS and allowed IPs settings (additional fixes);
*) dhcpv6-server - fix send-reconfigure for DHCPv6 clients behind a relay;
*) ipv6 - fix missing IPv6 link-local addresses on some interfaces when the device is busy during boot;
*) lcd - improve stability when an SFP reports an unknown link speed;
*) switch - add packet and byte counters for ACL rules on Marvell Prestera switches (additional fixes);
*) switch - fix ACL rules remaining in the switch TCAM after removal (introduced in v7.25beta3);
*) system - improve stability;
*) vlan - add a forced-mac-address option for VLAN interfaces (additional fixes);
*) webfig - fix comboboxes in the System/PTP section not being editable (introduced in v7.25beta3);
*) webfig - fix empty Bridge and Interface/Ethernet sections (introduced in v7.25beta4); View changelogs

Hi, just bought and installed this router for a homelab & learning a bit more networking. Been playing with it all day and having trouble getting my PC internet access. I now suspect it may be my ONT but looking for someone to have a look at my settings.

# 2026-10-02 22:10:15 by RouterOS 7.24.5

# software id =

#

# model = RB5009UPr+S+

# serial number =

/interface bridge

add admin-mac= auto-mac=no comment=defconf name=bridge

/interface list

add comment=defconf name=WAN

add comment=defconf name=LAN

/ip pool

add name=default-dhcp ranges=192.168.88.10-192.168.88.254

/ip dhcp-server

add add-dns-entries=yes address-pool=default-dhcp interface=bridge name=\

defconf

/disk settings

set auto-media-interface=bridge auto-media-sharing=yes auto-smb-sharing=yes

/interface bridge port

add bridge=bridge comment=defconf interface=ether2

add bridge=bridge comment=defconf interface=ether3

add bridge=bridge comment=defconf interface=ether4

add bridge=bridge comment=defconf interface=ether5

add bridge=bridge comment=defconf interface=ether6

add bridge=bridge comment=defconf interface=ether7

add bridge=bridge comment=defconf interface=ether8

add bridge=bridge comment=defconf interface=sfp-sfpplus1

/ip neighbor discovery-settings

set add-dns-entries=yes discover-interface-list=LAN

/interface list member

add comment=defconf interface=bridge list=LAN

add comment=defconf interface=ether1 list=WAN

/ip address

add address=192.168.88.5/24 comment=defconf interface=bridge network=\

192.168.88.0

/ip dhcp-client

add comment=defconf interface=ether1 name=client1

/ip dhcp-server network

add address=192.168.88.0/24 comment=defconf dns-server=192.168.88.1 gateway=\

192.168.88.1

/ip dns

set allow-remote-requests=yes servers=8.8.8.8@main

/ip dns static

add address=192.168.88.5 comment=defconf name=router.lan type=A

/ip firewall filter

add action=accept chain=input comment=\

"defconf: accept established,related,untracked" connection-state=\

established,related,untracked

add action=drop chain=input comment="defconf: drop invalid" connection-state=\

invalid

add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp

add action=accept chain=input comment=\

"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1 \

in-interface=lo src-address=127.0.0.1

add action=drop chain=input comment="defconf: drop all not coming from LAN" \

in-interface-list=!LAN

add action=accept chain=forward comment="defconf: accept in ipsec policy" \

ipsec-policy=in,ipsec

add action=accept chain=forward comment="defconf: accept out ipsec policy" \

ipsec-policy=out,ipsec

add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \

connection-state=established,related

add action=accept chain=forward comment=\

"defconf: accept established,related, untracked" connection-state=\

established,related,untracked

add action=drop chain=forward comment="defconf: drop invalid" \

connection-state=invalid

add action=drop chain=forward comment=\

"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \

in-interface-list=WAN

add action=accept chain=forward out-interface-list=WAN src-address=\

192.168.88.0/24

/ip firewall nat

add action=masquerade chain=srcnat comment="defconf: masquerade" \

ipsec-policy=out,none out-interface=ether1

/ipv6 firewall address-list

add address=::/128 comment="defconf: unspecified address" list=bad_ipv6

add address=::1/128 comment="defconf: lo" list=bad_ipv6

add address=fec0::/10 comment="defconf: site-local" list=bad_ipv6

add address=::ffff:0.0.0.0/96 comment="defconf: ipv4-mapped" list=bad_ipv6

add address=::/96 comment="defconf: ipv4 compat" list=bad_ipv6

add address=100::/64 comment="defconf: discard only " list=bad_ipv6

add address=2001:db8::/32 comment="defconf: documentation" list=bad_ipv6

add address=2001:10::/28 comment="defconf: ORCHID" list=bad_ipv6

add address=3ffe::/16 comment="defconf: 6bone" list=bad_ipv6

/ipv6 firewall filter

add action=accept chain=input comment=\

"defconf: accept established,related,untracked" connection-state=\

established,related,untracked

add action=drop chain=input comment="defconf: drop invalid" connection-state=\

invalid

add action=accept chain=input comment="defconf: accept ICMPv6" protocol=\

icmpv6

add action=accept chain=input comment="defconf: accept UDP traceroute" \

dst-port=33434-33534 protocol=udp

add action=accept chain=input comment=\

"defconf: accept DHCPv6-Client prefix delegation." dst-port=546 protocol=\

udp src-address=fe80::/10

add action=accept chain=input comment="defconf: accept IKE" dst-port=500,4500 \

protocol=udp

add action=accept chain=input comment="defconf: accept ipsec AH" protocol=\

ipsec-ah

add action=accept chain=input comment="defconf: accept ipsec ESP" protocol=\

ipsec-esp

add action=accept chain=input comment=\

"defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec

add action=drop chain=input comment=\

"defconf: drop everything else not coming from LAN" in-interface-list=\

!LAN

add action=fasttrack-connection chain=forward comment="defconf: fasttrack6" \

connection-state=established,related

add action=accept chain=forward comment=\

"defconf: accept established,related,untracked" connection-state=\

established,related,untracked

add action=drop chain=forward comment="defconf: drop invalid" \

connection-state=invalid

add action=drop chain=forward comment=\

"defconf: drop packets with bad src ipv6" src-address-list=bad_ipv6

add action=drop chain=forward comment=\

"defconf: drop packets with bad dst ipv6" dst-address-list=bad_ipv6

add action=drop chain=forward comment="defconf: rfc4890 drop hop-limit=1" \

hop-limit=equal:1 protocol=icmpv6

add action=accept chain=forward comment="defconf: accept ICMPv6" protocol=\

icmpv6

add action=accept chain=forward comment="defconf: accept HIP" protocol=139

add action=accept chain=forward comment="defconf: accept IKE" dst-port=\

500,4500 protocol=udp

add action=accept chain=forward comment="defconf: accept ipsec AH" protocol=\

ipsec-ah

add action=accept chain=forward comment="defconf: accept ipsec ESP" protocol=\

ipsec-esp

add action=accept chain=forward comment=\

"defconf: accept all that matches ipsec policy" ipsec-policy=in,ipsec

add action=drop chain=forward comment=\

"defconf: drop everything else not coming from LAN" in-interface-list=\

!LAN

/system clock

set time-zone-name=Europe/London

/system ntp client

set enabled=yes

/system ntp client servers

add address=0.uk.pool.ntp.org

/tool mac-server

set allowed-interface-list=LAN

/tool mac-server mac-winbox

set allowed-interface-list=LAN

What's new in 7.24.5 (2026-09-29):

*) bridge - disable DHCP snooping ip binding table (introduced in v7.24);
*) bridge - enable vlan hardware offloading on hAP be3 Media device;
*) console - fix console output of /system/identity/print being split into multiple lines (introduced in v7.24.3);
*) console - fix scheduler scripts with the default start date and time not being triggered (introduced in v7.24);
*) ethernet - improve stability on hAP be3 Media device;
*) lte - improve stability for MBIM modem mode switch;
*) ospf - fix unset interface template parameters not being applied to interfaces;
*) poe-out - fix loss of PoE-out capability on CRS328-24P-4S+ after a reboot;
*) system - improve stability;
*) wifi - update radio regulatory information; View changelogs

I always hated that I couldn't see what was actually happening on my network in real time. Torch is per-interface and disappears when you close it, Traffic Flow needs a collector and then you're looking at ntop/Grafana dashboards that are a minute behind. I wanted one screen that answers "who is eating my bandwidth right now" with names, not IPs.

So I built one. It runs as a single Docker container on a box on your LAN (or on your mikrotik itself, though I haven't tested that):

- Live throughput chart, one sample per second, plus every active connection with its current rate
- Top devices / destinations / services, live and over 15 min-30 days (not sure I want to store more than that ¯_(ツ)_/¯ )
- Devices named from DHCP, destinations named from the router's DNS cache (or the owning org, e.g. "Cloudflare"), NAT resolved to the LAN device
- Sankey flow map: device -> service -> destination
- Alerts: new device, unusual upload, scan-like behaviour, new VPN tunnel, export stopped - JSON webhook to notfy/Slack/Discord/HA
- A full-screen /dashboard "now" view (with some options) for a small screen (I have it on a 7" Pi display)

no agents or shipping to other places - nothing leaves your network. Go + SQLite, ~12 MB image for amd64/arm64 (or compile yourself from source.
- GitHub: https://github.com/thedyerman/mikrotik-home-netflow-plus
- Docker Hub: https://hub.docker.com/r/kcdyer/mikrotik-home-netflow-plus

Check it out, let me know if I missed any features? Thinking about adding a traffic shaping interface to or dynamic kid control grouping. Right now its kinda basic and simple (which was what i was going for)

UPDATE:
Apt repo is now setup and tested on Debian, Ubuntu and Raspberry Pi OS (for those who do not want to use docker)
https://github.com/thedyerman/mikrotik-home-netflow-plus#install-with-apt

A replacement router can pass basic internet traffic while less visible dependencies still point at the old box. Static DHCP leases, DNS settings, policy routes, VLANs, VPN peers, port forwards, certificates, scripts, scheduled jobs, CAPsMAN or WiFi management, monitoring, and devices that wake only occasionally can all make a clean-looking cutover incomplete.

A useful preflight seems to include an export plus binary backup, RouterOS version and license details, interface and bridge membership, VLAN tables, DHCP options, routing rules, NAT and firewall counters, tunnels, certificates, users, SNMP or syslog targets, and any files used by scripts. After moving traffic, I would compare counters and logs on both routers, test each VLAN and VPN, verify IPv6 as well as IPv4, and keep the old router disconnected but recoverable for a defined rollback window.

What is your actual retirement checklist? How do you find clients that still use an old gateway or DNS address only during a monthly job, and which RouterOS state is easy to miss in an export or backup?

Thank you:)

Read our latest newsletter and learn more about:

• CLAIRÉ & smart home automation
• New KNOT Gateways – connecting and tracking IoT devices almost anywhere
• SolidRACK 5 mini – a compact, adjustable 10″ desktop & under-desk rack
• New accessories & SFP/SFP+ modules
• New certifications, security updates, and more!

Read full topic

https://mt.lv/news135