Well, this is a pretty massive change log—thanks for all your hard work, Mikrotik team.
SAD! No news related to Circuit-ID/Remote-ID in ASCII.
I even updated just to check if they had just forgot to mention this fix.
As you exemplified, it smells so much like flowspec.
A bit anxious here to see it happen.
Yeah, did you make a formal complaint regarding this to support?
- No. VRF doesn't use TCAM, unless you use ACL Switch Rules to set VRF.
- 98DX8208 (CRS309-1G-8S+), 98DX8212, 98DX8332, 98DX3257, 98DX3255 (e.g. CCR2116-12G-4S+) support 512 VRF tables, others support 1024.
- Just VRFs. Can you share your use cases with routing tables with FIB enabled?
Thanks for sharing!
Regarding 3, I don't have a use-case where this is helpful, but just wanted to make sure that I don't have to prevent leakage of such tables 
You suggest that I open a new one, specific for this ASCII theme?
Obs.: O my understanding this is covered on the old one I Opened 2 years ago, and reopened beginning of June.
P.S.: No irony, no sarcasm contained. A honest question. I really cannot comprehend how MikroTik deals with demands of support.
Yes, I think it would probably be a good idea to open a new ticket specifically for the ASCII Circuit-ID/Remote-ID issue, and maybe reference the old ticket.
Not because I think you should have to do that, but because old/reopened tickets have a way to get buried, forgotten, or mixed up with other related issues. Mikrotik’s handling of these long-standing feature/bug requests can be pretty hard to read from the outside when you don’t know their internal way of working.
That's why I think a new ticket with a clear reproducer and a reference to the old ticket may be easier for support to route internally.
Ps..
As I see it, Winbox/ROS should show ASCII as the default and fall back to hex for binary values (or optionally display everything in binary if the user chooses that).
Usually, on other vendors, when you do a route-leak across VRF, it duplicate the routes in FIB.
To exemplify:
Imagine a scenario of a Internet Transit Provider with two Transit products:
- Common DFZ
- Common DFZ + Prioritized Routes (some kind of optimized choices, that usually goes through cables and paths that costs a bit more)
A MX204 with a Full DFZ routing on a VRF called "DFZ". 1 million IPv4 Routes.
And you leak it to a VRF called "DFZ-With-Prioritized-Routes". It will Double the entries on TCAM. so 2 million routes.
A good alternative to this is:
- You put a Default Route on VRF "DFZ-With-Prioritized-Routes" pointing to VRF "DFZ".
- You leak the routes from VRF "DFZ" to VRF "DFZ-With-Prioritized-Routes", but RIB Only. (you do this to have the routes on BGP-RIB and be able to export it to your downstream).
- And you put the "optimized routes" (usually less the 50K routes) on the RIB and FIB of VRF "DFZ-With-Prioritized-Routes".
With this, you have 1 million + 50K + 1(default) in the FIB with the same result.
This is a real use case of mixed RIB-Only and FIB.
It applies to Juniper, Cisco, Arista, Huawei...
They do that as the packets can be forwarded directly on the first round of route-lookup, and keep tracking of statistics of route usages and etc.
Considering that in RouterOS, apparently, all the routes are in the "same" table.
IPv4 and IPv6. RIB and FIB, including rejected routes on filters...
I really don't know how to compare the described real use case scenario to Mikrotik Way.
P.S.: The VRF existency itselves do not need to be on FIB(TCAM), It usually is there to cause the creation of Label-Per-VRF in MPLS scenarios, and also to force some methods of route-propagation (RT-Filter) on certain BGP engines.
I have a device that reports:
executing script wg-rotate-port from dhcpclient failed, please check it manually (not enough permissions)
The same script and configuration (I think, could not find a difference in related parts of configuration) works just fine on another device. Any idea?
Thank you so much for that very precise explanation. I hope it's taken into account and the processes in MikroTik, for example in VRF, are improved.
Best regards.
Setting dont-require-permissions=yes for the script helps... Are there changes related to permissions/policies that I missed?
regarding tagged traffic in vxlan tunels, i did test, bridged vxlan with one sfp+ port and sent tagged traffic. It worked, but only if vlan setup uses single vlan ID (say 123), if i set any range (122-123) it no longer works
If you could share the config used, or screenshots.
I will try to reproduce here.
For me the mode-button is completely non-functional. Can anybody confirm?
it's not much of a config, just vxlan interface bridged with physical port and bridge->vlans added. if it's:
interface bridge vlan add bridge=bridge1 tagged=sfp-sfpplus2,vxlan1 vlan-ids=123
it nicely works with frames tagged with vlan 123
but if i do:
interface bridge vlan add bridge=bridge1 tagged=sfp-sfpplus2,vxlan1 vlan-ids=122-123
neither frames tagged 122 nor 123 get through
How does the security issue affects 7.24 series, beta and rc?
If it is not on stable or Long-Term Release, it should no be used on production.
Or, if it is on production, should be in a way that moving it back to Stable or Long-Term should be unpainfull.
If you were talking about other vendors, the expected is that they would be clear(not nitpicking) about what is really happening.
And you would need to judge for your self what to do.
Examples for that?
SEVERAL!
With Junos I lived a few cases were we need to judge to moving version or just blocking TCP/179 strictly, or dropping address-families, and hold the impact of choices.
In the other thread @normis wrote (before deleting the posts) that the fix for the CVE is not yet in the current 7.24rc. You should move to stable if you are exposing the affected PPP services to untrusted sides.