RouterOS CHR/bare-metal — DPDK/VPPBut you've been going on about how MikroTik should look into DPDK. What are you trying to say? That MikroTik should develop DPDK high end appliances, or did I miss something like an alternative to DPDK?
I just said "not the only option", AKA it MEANS, DPDK is NOT the only option.DPDK in an MT embedded system using a standard SoC? You're joking, right? BTW, it's not 100GB of code we're talking about here, but hugepages for buffer sizes, queue depths, etc..
Any ideas about MPLS/VPLS single-CPU-core choking problem? Did they fix that?Not in Hardware
Nah, it's terrible and doesn't even function like *BSD real pf stack or in today's world, eBPF.Although macOS PF is pretty okay
Isn't VRF already working?Hi raimondsp, is VRF support on the roadmap?
/ip firewall nat add chain=srcnat src-address=10.0.0.0/24 dst-address=10.0.0.0/24 action masquerade
That would likely result in your early appointment with heaven/god/reincarnation, lolWell, if you really want to annoy Italians, you should suggest sipping a cappuccino while eating the pineapple pizza.
And for hAP ax³, why would sticks rotate around second axis, if it's doughnut shape?
I can't seem to find this on the documentation. How does it work? How do we configure it? How are the values mapped or parsed internally?What's new in 7.14.2 (2024-Mar-27 09:48):
*) wifi-qcom - added configuration.distance setting to enable operation over multi-kilometer distances (CLI only);
Nope. The protocol literally is peer to peer, it is not a server/client protocol like OpenVPN. This is about as stupid as saying OSPF has a sever and a client. People are really stuck up on NATted server/client model to the point they forgot what peer to peer really means.including client/server
Then make it, or simply allow official ONIE support on your hardware, we'll flash any OS of choice and get over RouterOS.We can't "Add stuff", we can only "Make stuff"
Still not BQL for RouterOS? I still see poor bufferbloat/CPU usage issues under stress testing. Come on MikroTik, just add BQL support already.*) defconf - use "fq_codel" queue as default interface queue for wired ports on LTE devices;
No, I live in economies that are far away from most IETF events. But have fun, and maybe try to get MikroTik employees to go there instead. They never participated in the IETF since 1997.I will be at IETF next month, will you ?
It would be good to meet up.
They failed to add BQL:Change log says:
*) defconf - use "fq_codel" queue as default interface queue for wired ports on LTE devices;
Forget RouterBOOT, they can save up money/R&D efforts and just use ONIE, which is a bootloader.Or, at least START by having some method to allow the V7 RouterBOOT to install (or at least boot) an alternative Linux disto. But I don't think the NIH mentality is going away.
Doesn't take away the fact that Juniper hardware + software are carrier-class in the industry, even better than Cisco. Can you call CCR2216 as carrier-class?One was so rich it sold out to HPE (who will ruin it). The other probably makes decent money for the founder/owner and staff.
See here, dynamic name isn't only issue:with BGP-VPLS can you stop dynamic names on that?
+10000Agree, there must remain a possibility to change these values administratively. Changelog quality is piss-poor.
You could do that, by running a cable from ether8 to ether9, but why? This is a bandwidth poor approach.But it doesn't have to be two bridges, one bridge spanning all ether ports will do just fine.
The delegated prefix. Client receives /56 PD from upstream, /56 aggregate is blackholed.Apologies, but I'm not following. What routes will be automatically added as blackholes to the routing table by DHCPv6 client?
Obviously they don't dude. It was a joke. My point stands, want Linux vanilla networking? Go for Debian or OpenWRT.OpenWrt doesn't sell routers.
You can install BIRD / FRR on OpenWrt.
I don't think there is an RFC that states this, but it's always good practice to blackhole aggregates to prevent layer 3 loops. Most end-users won't know how to do this, so this auto-feature, will take care of that.What RFC / part of RFC is being implemented here?
RFC3021 is simply not supported on MikroTik platform, I can't imagine what's taking them so long to support this.Why on Earth, would you need to use /32 on local and /31 on remote? This is a very poor implementation of RFC3021, if you could even call it an attempt.
Don't forget to read this:Thank you for sharing, I am starting to do the same process, only by using netmap instead of src-nat, I aim to reduce the number of rules.
It's strange, isn't it? The Marvell ASICs that MikroTik uses supports MPLS/VXLAN/EVPN in hardware, but MikroTik decided it was a terrible idea to support these three on the ASICs.There is no hardware MPLS support in RouterOS v7 at this point.
Why? NAT-PMP was already obsoleted by RFC6887. It would've made more sense to implement PCP, which is also usable in 464xlat, NAT64 and MAP-T.*) firewall - added "nat-pmp" support;
Disagree. We route to blackhole even on expensive high-end Juniper MXes and PTXes.I think it is a mistake to apply techniques developed for business-on-budget applications to prosumer cases which my firewall is for.
viewtopic.php?t=176358#p864371I actually disabled all the other rules as well. Is there a base ruleset I should be using? The implicit drop at the bottom is disabled as well.
Works fine on v7.11.2. No problems here for months/weeks now. Even cross-vendor.When is really ready and works...Or even better, BFD. It was made for this purpose.
How small is the market for this? What are some modern-day use-cases for it in carrier networks? I just can't think of any because of EVPN.MPLS-TP is not legacy, but its a niche market.