V7.20beta [testing] is released!

I know it’s not the feature requests thread but +1 to the “more CGNAT features” thoughts above!

Well, the “lease script” can do absolutely nothing for “client authorization”, as it is called after a lease has already been acknowledged.
It is intended to provide a hook to handle new systems, e.g. to create a DNS record, to send an alert mail when new systems join the network, etc.
I have proposed before that a “pre-lease script” could be added that is called when the request comes in, and that can examine the request parameters and decide whether a lease should be granted, from what pool, etc. In that functionality, mapping of requests to RADIUS could also be done, e.g. by setting some magic variables (that RouterOS first sets to a default, and that the user can then modify when desired).

I am starting to get (again, after a few versions):“could not save configuration changes, not enough storage space available.” on hAP ac2 with wifi-qcom-ac and minimal AP/CAPsMAN/NAT router/DHCP server/wireguard config. Everything was fine until 7.19rc3 (this is my home device, always on latest testing-development channel).
I know, I can netinstall it and save a few bytes, but wouldn’t it be easier for Mikrotik to finally split wifi-qcom-ac into two packages, as suggested many times before, and fix this problem once for all 16MB devices?

@sinisa you can show your support over here http://forum.mikrotik.com/t/cap-ac-wifi-qcom-ac/183993/1

I'm waiting for them to do this, I depend on this to install the wifi-qcom-ac package on my ac2

@Kentzo, I wrote up what I know about /console/inspect and LSPs in this thread:
http://forum.mikrotik.com/t/routeros-lsp-for-better-syntax-checking-command-completion-in-editors-like-vscode-neovim/184067/1

Sorry @mrz, but… can’t you test it yourselves with all the resources and devices you have?

You’re asking users to be beta testers. Can’t you reproduce something as basic as this? It happens with several users. I don’t think it’s too difficult to reproduce the problem yourself.

I believe Mikrotik support engineers or developers are probably not allowed or able to investigate bugs independently and on their own initiative. It likely needs to go through the support helpdesk first, where it gets triaged and prioritized before being assigned accordingly. There is surely a defined workflow for this, and “cherry-picking issues from the forum release topic” is probably not part of the official process.

Hooray !!! EVPN in place. Lab time.


Thank you Mikrotik Team.

Did you tried do not specify any routers id in bgp ?

You do realize this is a beta release, and the first publicly available beta of this version at that. By loading it onto your router, you are volunteering to be a beta tester. They can’t imagine up your configuration and outcome without seeing specifically what the router is doing.

Sending them a support file from 7.19 doesn’t even require you to keep running the beta. It takes all of a couple of minutes to grab the file, open a ticket, upload the file, and voila–done.

For BGP instance put the ASN id into configuration .. simple, easy, fast solution.

Rewrite Radius-Request username with Circuit-ID DHCP-Option82 or PPPoE+

Suggestion: Hooks to Scripts on /routing/filter/rule actions

A further enhancement needed to make either option82 or PPPoE+ actually usefull, is the ability to compose the injected option82(circuit AND-OR remote-id) tag using local variables
(inbound-port, inbound-mac, inbound-vlan, node-id, etc…)

as implemented today, snooping happens on all-interfaces, all-vlans, at the same time, and simply rewrites the option82 header with the inbound interface “internal interface name”

this is not really useful in a practical scenario (imagine a 2-tiered Gpen network with 14 Netpower-16 connected to a CRS317, then upstream to a router)
if one enables snooping in the Netpower “tier”, inbound requests get tagged with the local interface name “ether1-16”, and you end up with 16 clients with the same CID
if one enables snooping in the CRS317, you end up with all customers in a given Netpower having the same CID, as tagged by the CRS317: “sfp-sfpplus1-14”

This should be an option but shouldn’t be the ‘only’ option if they are going to improve leases
Splynx (Which uses FreeRADIUS for its backend) can already authenticate directly with circuit/remote ID and simply ignore the username/MAC address
I’d like to see the same thing directly on RouterOS as well as User Manager

It’s not a big deal running Splynx for authentication on a major network for direct customers. For the tenants of the customer (i.e. internal network) I want to localize the authentication to their MikroTik router itself for i.e. holiday parks, hotels/motels, multi tenancy businesses. Not having to involve any third party software

The real question is, what exactly is the correct configuration to have prior to upgrading to v7.20, so that after upgrading, BGP works out of the box?

There are routers that won’t be accessible remotely to correct the ASN and/or router-id after the fact, so MikroTik should publish a valid/tested upgrade path (covering at least a few common setups) so we don’t have to travel to remote datacenters and mountains to do the upgrade.

Do you guys don’t have OOB management so that you can re-establish control with the device and fix this? I’m not saying MT is not at fault here actually you are right they should a a test coverage for this basic things :), what i’m trying to emphasize is for a worst case scenario you have back backdoor to manage the device, just my 0.002$ don’t get me wrong :slight_smile:

And this is precisely why its a Beta firmware. Specifically so it can be used for testing, finding problems, determining fixes and then implemented before the production release :slight_smile:

A lot of people on this forum do tend to forget that. Then again, v7 itself is largely still a beta with a lot of outstanding problems… Would help tremendously if MikroTik did release a bug tracker, as has been mentioned many times before

I asked before but got no response. In its current state does EVPN work with Traffic Engineering paths? or another way to ask it, dis EVPN MPLS supported or only EVPN VXLAN?
If not - @MikroTik is it planned to be supported? Or even better is Segment Routing on the roadmap?

@millenium7 it wasn’t clear there’s no roadmap or anything I hope mac-vrf and anycast gateway should also included just like @fischerdouglas wanted, let just hope and trust them to do the right thing :slight_smile: