Couple of questions
(1) what is "ein-snat" and "ein-dnat" ( searched mt docs and no match ).
(2) CLI winbox import & export capability - will this get ported to winbox eventually?
The Dude client is corrupt on the download page!
Opened SUP-133893 where RA deprecate messages for an active RA are sent at the same time as the active RA.
Workaround: toggle "use interface duid" to temporarily get a new PD then it reverts back to the actual PD and the RA will be correct.
Well you get a non working config:Why is that a problem? That is intended behaviour at the moment.
Thanks - I have a workaround (mentioned before), so I'm good for now.This is actually already fixed in 7.13 which is coming soon. Deprecate message will not be sent if actual prefix is re-used.
7.13? not 7.12.1 ???This is actually already fixed in 7.13 which is coming soon. Deprecate message will not be sent if actual prefix is re-used.
My thought as well. I am looking forward for a stable long term release 7.12.87.13? not 7.12.1 ???This is actually already fixed in 7.13 which is coming soon. Deprecate message will not be sent if actual prefix is re-used.
Install wifwave2 package (from extra packages). Next time use built-in upgrade feature which upgrades all installed packages automaticalky.Hi buy one Rb L41G-2axD I upgraded from 7.8 to 7.12and the Wireless interface disappeared, what should I do to get the wireless interface back?
Thank You Very Much Work AgainInstall wifwave2 package (from extra packages). Next time use built-in upgrade feature which upgrades all installed packages automaticalky.Hi buy one Rb L41G-2axD I upgraded from 7.8 to 7.12and the Wireless interface disappeared, what should I do to get the wireless interface back?
Tested with RB5009 and AX3 and BTH is working without a problem. Will test with my RB4011 tomorrow.Updated 3 devices with similar config from 7.11.2 to 7.12 stable:
1. Hex s - works fine, including DoH.
2. Hap ac3- DoH doesnot work.
3. Rb4011 - DoH doesnot work, BtH - unable to connect.
Thanks for the added support for ed25519 keys for user authentication.ssh - added support for user ed25519 public keys;
/interface/lte/firmware-upgrade lte1
installed: 16121.1034.00.01.01.03
latest: 16121.1034.00.01.01.04
/interface/lte/firmware-upgrade lte1 upgrade=yes
status: download failed
/tool/fetch https://upgrade.mikrotik.com/firmware/FG621-EA/16121.1034.00.01.01.04/image
status: failed
failure: closing connection: <404 Not Found> 159.148.172.226:443 (4)
https://upgrade.mikrotik.com/firmware/FG621-EA/16121.1034.00.01.01.03/image
/routing ospf interface-template set *9 area=backbone-v3 auth=md5 auth-id=1 auth-key=************** ...
default-v3 { version: 3 router-id: 10.***.***.1 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::de2c:****:fe45:c**b%ether2 } authentication failed from fe80::3eec:****:fef2:4f**%*2 received message with authentication trailer
7.12 not working with CCR2004-1G-12S+2XS and RJ45 SFP-GB-GE-T , very sad thing, you fix one thing and break another.
7.13? not 7.12.1 ???This is actually already fixed in 7.13 which is coming soon. Deprecate message will not be sent if actual prefix is re-used.
Yes, once I set it to "No" DoH immediately starts working properly until next reboot. Then when I set this option back to "Yes" DoH starts working properly again.For those who experience issues with the DoH service? Is "/certificate/settings/set crl-use=" set to "yes" on your routers? If it is "yes", then do DoH work if you change value to "no"?
and now I have following error messages in the log:and now re enable together with the download option too:
/certificate settings
set crl-download=yes crl-use=yes
Does that mean if I want to have a 40G link on the qsfp28-1 port of a CCR2216-1G-12XS-2XQ, I have to enable all qsfp28-1-{1,2,3,4} interfaces before updating? What will be the state of those sub-interfaces when the 40G link is established?*) qsfp - use sub-interface configuration for establishing link (for 40Gbps and 100Gbps links, all sub-interfaces must be enabled);
So is the documented behavior the old or the new one? Could you please – whichever it is – clarify the documentation?*) route - reverse community "delete" and "filter" command behavior;
How about extending the property verify-doh-cert with a new value yes-without-crl, just like fetch command with its property check-certificate?and now re enable together with the download option too:
/certificate settings
set crl-download=yes crl-use=yes
There is no such item in the winbox gui.For those who experience issues with the DoH service? Is "/certificate/settings/set crl-use=" set to "yes" on your routers? If it is "yes", then do DoH work if you change value to "no"?
There is. Go to Certificates menuThere is no such item in the winbox gui.For those who experience issues with the DoH service? Is "/certificate/settings/set crl-use=" set to "yes" on your routers? If it is "yes", then do DoH work if you change value to "no"?
Would you be so kind to provide cli script to get the current value of this param?
Thank you.
Ps. DoH doesnot work when "verify DoH certificate" is unchecked!
Do you have static DNS record that points to used DOH server DNS name?Ps. DoH doesnot work when "verify DoH certificate" is unchecked!
I checked it before I wrote:
There is. Go to Certificates menu
Upgrade v7.12 on vultr and no problem so far. Local instances of CHR and x86 upgraded and working fine also.I updated a CHR on AWS from 7.11.2 to 7.12 and it is not starting anymore, is there a known issue?
Even the serial console isn't showing anything, it looks like the whole instance is broken.
I presume this is incompatible with regular "wireless" package station-bridge and all APs not able to run wifiwave2 right?*) wifiwave2 - added station-bridge interface mode;
Yesterday posted all the fetails:sas2k, there are no other checboxes. What RouterOS version are you running?
Updated 3 devices with similar config from 7.11.2 to 7.12 stable:
1. Hex s - works fine, including DoH.
2. Hap ac3- DoH doesnot work.
3. Rb4011 - DoH doesnot work, BtH - unable to connect.
No problem, but will it help?send your supout.rif file to support@mikrotik.com from 7.12
I do not know the internal parameter references of wireguard but simply generate the lineAs for the "client-allowed-ips" do you mean the parameter10.155 that will be installed on client device when importing configuration? IPs allowed from remote peer?
set client-allowed-ips = 10.200.200.1/32,192.168.1.0/24
AllowedIPs = 10.200.200.1, 192.168.1.0/24
I experienced this exact same issue when going from 7.7 to 7.10 with CHR on Google CE. I had to rebuild using an old snapshot.I updated a CHR on AWS from 7.11.2 to 7.12 and it is not starting anymore, is there a known issue?
Even the serial console isn't showing anything, it looks like the whole instance is broken.
I am observing the same here, running 7.12. Perhaps this is a cosmetic issue, where it displays 3s but internally it is 500ms? And yes, you can't set ra-delay to any millisecond value, it rounds it down to 0s when attempting:*) ipv6 - fixed IPv6 RA delay time from 5s to 500ms according to RFC;
Upgraded hAP AX^3 from ROS 7.11.2 to 7.12, and upgraded the firmware, but IPv6 RA Delay Time still shows as 3 seconds and cannot be changed to 500ms. The parameter in ND only accepts seconds. Have I missed something?
/ipv6 nd set 0 ra-delay=500ms
Warning: value of ra-delay was rounded down to 0s
Most likley wireless conditions change in some way. Wireless is wireless.Upgraded my RB5009+three AX2 to 7.12 but still I have very slow speeds on my local network (around 23 MB/s) between my iPad and my NAS whereas I had around 50 MB/s before 7.11 or so. Don’t understand what to do.
I have also confirmed this situation.On my rb850gx2 I have no service, I updated it remotely and now it no longer responds.
Why not switch to HMAC-SHA-X Algorithm instead of MD5?MD5 encryption still doesn't work with OSPFv3 - testing between FRRouting 9.0.1 and 7.12. FRRouting vs FRRouting works fine.
config:log:Code: Select all/routing ospf interface-template set *9 area=backbone-v3 auth=md5 auth-id=1 auth-key=************** ...
Code: Select alldefault-v3 { version: 3 router-id: 10.***.***.1 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::de2c:****:fe45:c**b%ether2 } authentication failed from fe80::3eec:****:fef2:4f**%*2 received message with authentication trailer
/routing ospf interface-template
add area=ospf3-backbone auth=sha512 auth-id=0 auth-key=\
gsCHixQReM8cITbm8-8iedXG63ao8i9s dead-interval=20s disabled=no \
hello-interval=5s interfaces=bridge1.3999 retransmit-interval=2s
protocol ospf v3 ospf3_main {
area 0 {
interface "br0.3999" {
type broadcast;
hello 5; retransmit 2; wait 10; dead 20;
authentication cryptographic;
password "gsCHixQReM8cITbm8-8iedXG63ao8i9s" { id 0; algorithm hmac sha512; };
check link on;
};
};
}
Noticed that on all of them I needed to reboot a second time to upgrade the routerboard firmware despite having "/system routerboard settings set auto-upgrade=yes" configured.
<CLIENT IP ADDRESS>: disconnected <TLS error: ssl: unexpected message (6)>
ovpn_server1: terminating... - TLS error: ssl: unexpected message (6)
<CLIENT IP ADDRESS>: disconnected <explicit peer disconnect>
[sarcasm]... I was assured that this bug has been fixed in the 7.12 branch.
Well, it isn't. Still...
Corrected/clarified :)[sarcasm]Well, 7.12 branch isn't abandoned/surpassed yet.[/sarcasm]
I have 3 hap x2 as access points. 5GHz spectrum is clear. The AP (in fact ANY of them) is in the line of sight but still…Most likley wireless conditions change in some way. Wireless is wireless.Upgraded my RB5009+three AX2 to 7.12 but still I have very slow speeds on my local network (around 23 MB/s) between my iPad and my NAS whereas I had around 50 MB/s before 7.11 or so. Don’t understand what to do.
Ah, okay. Thanks for clarifying the behaviour."Noticed that on all of them I needed to reboot a second time to upgrade the routerboard firmware despite having "/system routerboard settings set auto-upgrade=yes" configured."
This has always been required. All the auto-upgrade does is save you the effort of having to go in and manually upgrade the router board firmware before rebooting.
Perhaps you missed this part from the announcement?FoxGate ONU 1001XP-SFP is not initializing on RB5009 either Auto negotiation or force . Was working on 7.8 (with eeprom-checksum: bad to be precise).
It may have worked before this release, but changes have been made to SFP functionality. It would seem that your SFP module is non-compliant. In that case, replace the SFP module with a compliant one or roll-back to any version before 7.12 if you're not ready to replace the module just yet but need it working.Notice - SFP/QSFP functionality has been refactored for consistent behavior and better scalability. Now, compliance with SFP/SFP+/QSFP MSA standard is mandatory. This may cause issues with SFP/QSFP modules that are not fully compliant. All current MikroTik modules abide this standard.
I'd love to replace my SFP module with compliant, however, as far as I understand, Mikrotik is NOT have any compliant (such a simple thing) SFP EPON ONU. :-(replace the SFP module with a compliant one
To be fair, "SFP-ONU" modules are not just simple transceivers, as defined in the MTA
I'd love to replace my SFP module with compliant, however, as far as I understand, Mikrotik is NOT have any compliant (such a simple thing) SFP EPON ONU. :-(
Now, I believe, this phrase should be deleted "MikroTik devices and SFP, SFP+, SFP28, QSFP+, and QSFP28 modules do not have any restrictions for other vendor equipment."
Mikrotik has just clearly restricted me from using other vendor equipment. Unbelievable.
Come on, it's not just SFP-ONU. I have a ticket open for six months for a simple SFP+ from Ubiquity (to replace S+RJ10), it's crickets, I test every new release, and it's still the same.To be fair, "SFP-ONU" modules are not just simple transceivers, as defined in the MTA
I'd love to replace my SFP module with compliant, however, as far as I understand, Mikrotik is NOT have any compliant (such a simple thing) SFP EPON ONU. :-(
Now, I believe, this phrase should be deleted "MikroTik devices and SFP, SFP+, SFP28, QSFP+, and QSFP28 modules do not have any restrictions for other vendor equipment."
Mikrotik has just clearly restricted me from using other vendor equipment. Unbelievable.
they are full-blown router/bridges , with firmware, folded into a SFP mechanical form-factor (sometimes disregarding electrical and thermal specs)
let alone the firmware(and simulated EEPROM responses), those are amongst the crappiest CPE's possible, from a support, and stability standpoints.
To the point that Mikrotik themselves, and even finisar (that specializes in high-end transceivers), had products in this category, and pulled them from the market
The modules themselves are CRAP, This is not mikrotik's fault.
to# 7.11.2
set $ifcId mode=ap-bridge band=2ghz-b/g/n disabled=no wireless-protocol=802.11 \
distance=indoors installation=indoor
and
# 7.12
set $ifcId mode=ap-bridge band=2ghz-b/g disabled=no wireless-protocol=802.11 \
distance=indoors installation=indoor
To:# 7.11.2
set $ifcId mode=ap-bridge band=5ghz-a/n/ac disabled=no wireless-protocol=802.11 \
distance=indoors installation=indoor
set $ifcId channel-width=20/40/80mhz-XXXX;
Any reason why the change?# 7.12
set $ifcId mode=ap-bridge band=5ghz-a disabled=no wireless-protocol=802.11 \
distance=indoors installation=indoor
set $ifcId channel-width=20mhz;
In my case it was a new instance which I created around Oct 15th and this date is shown as "Last Seen" on the license management as well. I guess the "Next Renewal Date" would be around Nov 15th, can't tell because it's broken :)I experienced this exact same issue when going from 7.7 to 7.10 with CHR on Google CE. I had to rebuild using an old snapshot.I updated a CHR on AWS from 7.11.2 to 7.12 and it is not starting anymore, is there a known issue?
Even the serial console isn't showing anything, it looks like the whole instance is broken.
In our case, I believe the issue was related to the CHR license not being applied when I upgraded from 6.49.x to 7.x, as evident from the last contact date in the license management page.
So its seems like, if the license cannot be verified within the allowed grace period, the CHR gets trashed during the reboot or upgrade.
This is terrible behavior MikroTik needs to change -- especially since we use CHR in a production environment to terminate hundreds of remote-site VPN connections. Instead of rendering a CHR install non-functional, when the license has not been verified outside the grace period, simply downgrade link speed and/or disable all functionality except that necessary to login to the CHR and correct the license issue.
My device (SFP ONU) was working on RB5009. Now Mikrotik decided that is a CRAP (without offering any equivalent) and forbid me to install any future updates. Nice. Well done, Mikrotik!The modules themselves are CRAP, This is not mikrotik's fault.
Thanx to tell us on what kind of router, please...I tried updating from 6.49.10 to 7.12 bootloop and tried netinstall, the result was the same, downgrading to 7.11.2, it worked with netinstall, I used an RB 850 GX2, for those of you, it's best to have the same as me, avoid 7.12
rb850gx2Thanx to tell us on what kind of router, please...I tried updating from 6.49.10 to 7.12 bootloop and tried netinstall, the result was the same, downgrading to 7.11.2, it worked with netinstall, I used an RB 850 GX2, for those of you, it's best to have the same as me, avoid 7.12
The station-bridge mode, as implemented in the wifiwave2 package, is incompatible with APs running the bundled 'wireless' package and vice versa.
fixed my problems.Updated 3 devices with similar config from 7.11.2 to 7.12 stable:
Why not switch to HMAC-SHA-X Algorithm instead of MD5?
FRRouting 9.0 OSPFv3 docs
I have OSPFv3 running with HMAC-SHA-512 Auth between Bird 2.0.14 and ROS 7.12 with success. After the inclusion of bugfix "ospf - fixed OSPFv3 authentication header length calculation"
ROS 7.12
Bird 2.0.14 (on Debian Linux 12)Code: Select all/routing ospf interface-template add area=ospf3-backbone auth=sha512 auth-id=0 auth-key=\ gsCHixQReM8cITbm8-8iedXG63ao8i9s dead-interval=20s disabled=no \ hello-interval=5s interfaces=bridge1.3999 retransmit-interval=2s
Unless you capture the OSPFv3 packets on the wire and analyze the Authentication contents in e.g. Wireshark. It is hard to know what is going wrong for your setup with FRR 9.0.1 and ROS 7.12.Code: Select allprotocol ospf v3 ospf3_main { area 0 { interface "br0.3999" { type broadcast; hello 5; retransmit 2; wait 10; dead 20; authentication cryptographic; password "gsCHixQReM8cITbm8-8iedXG63ao8i9s" { id 0; algorithm hmac sha512; }; check link on; }; }; }
My problem was the the authentication header length before 7.12 was set to an incorrect value. Where ROS missed the addition of 16 bytes in the len field in the OSPFv3 authentication header. ( HMAC-SHA-512 / 8 = 64 bytes, instead of HMAC-SHA-512 / 8 + 16 = 80 bytes)
@vecinoYes I know about this option, but I guess to simplify my configuration file I prefer MD5, which I also use in OSPFv2. OSPFv2 can only do MD5 - https://docs.frrouting.org/en/stable-9.0/ospfd.html
# 2023-11-11 22:00:00 by RouterOS 7.11.2
# software id = G8MZ-MQ11
# model = CCR2004-16G-2S+
#
# 2023-11-12 22:00:00 by RouterOS 7.12
# software id = G8MZ-MQ11
# model = CCR2004-16G-2S+
/user ssh-keys import public-key-file=flash/pub/id_ed25519_sk.pub user=my-user
sk-ssh-ed25519@openssh.com AAAAGnNrLXNzaC1lZDI1NTE5QG9wZW5zc2guY29tAAAAIAA0HdRkQwPCMwy/KxKR3A49kleuXZMvknZbU9aO0Ob2AAAAFnNzaDpZdWJpS2V5XzE4LjA4Ny43OTA= my-user@my-domain.com
As usual, you do not provide any useful info, like from what version you upgrade...Not sure if it's related, but...
That's expected and has been so ever since auto-upgrade is available. The reason is that .fwf files with new routerboot are part of ROS package and are only available after new ROS version gets installed. What the auto-upgrade=yes does is that it installs the new routerboot firmware right after new ROS boots for the first time (so one doesn't have to go via System->RouterBOARD->Upgrade manually) ... but an extra reboot is still necessary.
/system routerboard settings
set auto-upgrade-reboot=yes
It really isn't a good idea (anymore) to set automatic firmware upgrade. The reason is that the firmware version now changes every time, it is the same as the RouterOS version. But usually there is no update at all in the firmware. Update just does nothing, but it incurs a small risk of rendering the router unbootable and requiring a netinstall using the backup booter.Can Mikrotik add a flag to reboot the router automatically just after software + firmware upgrade ?
Like:This will have the advantage of having only one down time (and only one operation) for the cost of a small extra down time.Code: Select all/system routerboard settings set auto-upgrade-reboot=yes
In production this will be very valuable.
More harm can come from running a firmware version from 10 years ago, than upgrading the firmware each time automatically. I've seen too many MikroTik boxes in prod, running latest ROS, but firmware from 1965, and then they whine about why some SFP issue pops up or some other issues buried in the changelogs. I enforce auto-upgrade = yes as company policy, personally. But MikroTik could probably improve the user experience here, for sure.It really isn't a good idea (anymore) to set automatic firmware upgrade. The reason is that the firmware version now changes every time, it is the same as the RouterOS version. But usually there is no update at all in the firmware. Update just does nothing, but it incurs a small risk of rendering the router unbootable and requiring a netinstall using the backup booter.
It is best to update the firmware once after purchase of the device, and then only when release notes indicate some firmware change is required for the particular device you are running it on.
Then you can just do a manual update and consider if you even need the change to become active rightaway, or can wait to the next reboot.
*) ovpn - improved system stability;
So can we assume OpenVPN is in a state comparable to ROS 6 again, stability-wise? Every release after 7.6 has been horribly unstable (including numerous complete lockups) for me, for any system running even one OVPN client.Can confirm that the OpenVPN UDP issues described in viewtopic.php?p=1024643#p1024643 have been fixed in 7.12, at least for me.
noNoticed that on all of them I needed to reboot a second time to upgrade the routerboard firmware despite having "/system routerboard settings set auto-upgrade=yes" configured.
That's expected and has been so ever since auto-upgrade is available. The reason is that .fwf files with new routerboot are part of ROS package and are only available after new ROS version gets installed. What the auto-upgrade=yes does is that it installs the new routerboot firmware right after new ROS boots for the first time (so one doesn't have to go via System->RouterBOARD->Upgrade manually) ... but an extra reboot is still necessary.
This has been discussed on this forum before ... and MT staffers' response was that it is not possible to flash new routerboot image before new ROS is booted. Personaly I have hard time believing this (I guess it would be non-trivial and might pose a threat to stability of upgrade process, but I'm pretty sure it would be possible to do it in same leg as ROS upgrade).
More harm can come from running a firmware version from 10 years ago, than upgrading the firmware each time automatically. I've seen too many MikroTik boxes in prod, running latest ROS, but firmware from 1965, and then they whine about why some SFP issue pops up or some other issues buried in the changelogs. I enforce auto-upgrade = yes as company policy, personally. But MikroTik could probably improve the user experience here, for sure.
Bullshit. Buy a device today, netinstall with latest ROS and firmware. Now one year later, ROS version has changed 15 generations and firmware is 15 generations behind, and you're back to ancient firmware.Of course he did not read what I wrote. I wrote "It is best to update the firmware once after purchase of the device" so you won't have ancient firmware.
ipv6 ospf6 authentication key-id 1 hash-algo hmac-sha-256 key 12CBFE21AC3D4D981AD4FD32C1A28E0DBE259A1F60E35BB6C4ADECD2989432F6
/routing ospf interface-template set *9 area=backbone-v3 auth=sha256 auth-id=1 auth-key=12CBFE21AC3D4D981AD4FD32C1A28E0DBE259A1F60E35BB6C4ADECD2989432F6 + etc
default-v3 { version: 3 router-id: 10.***.***.1 } backbone-v3 { 0.0.0.0 } interface { broadcast fe80::****:6eff:****:c79b%ether2 } authentication failed from fe80::****:efff:fef2:****%*2 sha mismatch
I was unable to import the public key ED25519 from my YubiKey,
No in any way - see viewtopic.php?p=1035315#p1035315*) ovpn - improved system stability;So can we assume OpenVPN is in a state comparable to ROS 6 again, stability-wise? Every release after 7.6 has been horribly unstable (including numerous complete lockups) for me, for any system running even one OVPN client.Can confirm that the OpenVPN UDP issues described in viewtopic.php?p=1024643#p1024643 have been fixed in 7.12, at least for me.
Would be awesome if I could actually try new versions again on important routers.
*) ovpn - improved memory allocation during key-renegotiation;
Thanks for input. It seems to to me that the slot is always pcie1.Are you sure it's not because the slot name of USB disk changes after reboot ?
As usual, I'm akways ready to reply to kind questions about useful informations needed to help me: from the previous version.As usual, you do not provide any useful info, like from what version you upgrade...
I hope MikroTik does a clean, fresh, codebase for ROS v8 with fresh kernel base (latest long-term version at that point in time). Otherwise, we're really f***ed. At this point, Debian + FRR or BIRD or VPP is far more stable.MikroTik's software quality is a very bad joke. Guys should go back to the first chapters of any good book on software engineering. It looks like in the past their software was written by the old timers and then the "young, dynamic, from big cities, who think they know better" came on board and ruined everything what the old timers put in place. That's why we have such a nightmare right now and that's why MikroTik can't be seen as a long term solution for production/enterprise/mission-critical networks. To this day, the simple PC with Linux OS is a few galaxys ahead of any MikroTik solution in terms of stability, reliability, updates...
Just look at the 7.13beta1 changelog:Am I the only one with conclusion, that MikroTik programmers are reimplementing existing code? I have such fears for years now.Code: Select all*) ovpn - improved memory allocation during key-renegotiation;
If they would be taking the original OpenVPN source code, then they won't have such problems - especially on the memory management level.
Works for me in any version above 7.11Until v7.12 in MPLS L3 env/ topology.
/routing/route/print where routing-table=xxxx or /ip/route print where routing-table=xxxx did not show any routes when /ip/vrf interfaces=none.
[admin@MikroTik] /ip/route> /ip vrf/print
Flags: X - disabled; * - builtin
0 name="xx" interfaces=none
1 * name="main" interfaces=all
[admin@MikroTik] /ip/route> /routing/route/print where routing-table=xx
Flags: U - UNREACHABLE; s - STATIC; H - HW-OFFLOADED
Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE
DST-ADDRESS GATEWAY AFI DISTANCE SCOPE TARGET-SCOPE
UsH 0.0.0.0/0 1.2.3.4 ip4 1 30 10
Dear Mrz,Works for me in any version above 7.11Until v7.12 in MPLS L3 env/ topology.
/routing/route/print where routing-table=xxxx or /ip/route print where routing-table=xxxx did not show any routes when /ip/vrf interfaces=none.
Code: Select all[admin@MikroTik] /ip/route> /ip vrf/print Flags: X - disabled; * - builtin 0 name="xx" interfaces=none 1 * name="main" interfaces=all [admin@MikroTik] /ip/route> /routing/route/print where routing-table=xx Flags: U - UNREACHABLE; s - STATIC; H - HW-OFFLOADED Columns: DST-ADDRESS, GATEWAY, AFI, DISTANCE, SCOPE, TARGET-SCOPE DST-ADDRESS GATEWAY AFI DISTANCE SCOPE TARGET-SCOPE UsH 0.0.0.0/0 1.2.3.4 ip4 1 30 10
And what is your previous version? 7.11.2?from the previous version
Alias Commands (with args) would be a helpful solution to that...(already said a couple of time in the last months .. and sent support requests)
Old v6 command "ip route check x.y.z.k" still missing!
e.g. /ip route check 8.8.8.8 (linux equivalent "ip route get 8.8.8.8")
It's very usefull when you have many routes in your routing table and you don't want to waste your time looking for the best match (and/or make mistakes chosing the wrong one when in a hurry or under pressure!)
it should be trivial to get it done..
*) www - fixed allowed address setting for REST API users;
/routing ospf instance
add disabled=no name=backbone-v2 originate-default=never redistribute="" router-id=192.168.0.66 routing-table=main
add disabled=no name=backbone-v3 originate-default=never redistribute="" router-id=192.168.0.66 routing-table=main version=3
/routing ospf area
add disabled=no instance=backbone-v2 name=backbone-v2
add disabled=no instance=backbone-v3 name=backbone-v3
add area-id=0.0.0.66 disabled=no instance=backbone-v2 name=area-stub-v2 type=stub
add area-id=0.0.0.66 disabled=no instance=backbone-v3 name=area-stub-v3 type=stub
/routing ospf area range
add area=area-stub-v2 cost=10 disabled=no prefix=10.177.66.0/24
add area=area-stub-v2 cost=10 disabled=no prefix=100.70.66.0/24
add area=area-stub-v2 cost=10 disabled=no prefix=100.71.66.0/24
add area=area-stub-v2 cost=10 disabled=no prefix=172.17.66.0/24
add area=area-stub-v3 cost=10 disabled=no prefix=2804:XXXX:XXXX::/48
/routing ospf interface-template
add area=backbone-v2 cost=10 disabled=no interfaces=loopback networks=192.168.0.66/32 passive priority=1
add area=backbone-v3 cost=10 disabled=no interfaces=loopback networks=2804:XXXX:XXXX::/64 passive priority=1
add area=backbone-v2 cost=10 disabled=no interfaces=vlan10 networks=172.17.37.8/29 priority=1 type=ptp
add area=backbone-v3 cost=10 disabled=no interfaces=vlan10 priority=1 type=ptp
add area=area-stub-v2 comment="AREA STUB" cost=10 disabled=no networks=10.177.66.0/24,100.70.66.0/24,100.71.66.0/24,172.17.66.0/24 passive priority=1 type=ptp
add area=area-stub-v3 comment="AREA STUB" cost=10 disabled=no networks=2804:XXXX:XXXX::/48 passive priority=1 type=ptp
I've noticed this problem too. type=PTP doesn't fix it. I'll open a ticket with Mikrotik.Has anyone other than me noticed that this 7.12 update "killed" the stub area? I use stub area to summarize the PPPoE IPs and other IPs on each routerboard and only export /24 or larger blocks from the routerboard. I used it as follows and it works on 7.11.2 and earlier, but after updating to 7.12 it stopped working and even deleting, resetting and configuring it again, the routerboard doesn't work.
The only thing that I found strange (but it only works like that), was having to announce the stub area with type=ptp, instead of type=broadcast.Code: Select all/routing ospf instance add disabled=no name=backbone-v2 originate-default=never redistribute="" router-id=192.168.0.66 routing-table=main add disabled=no name=backbone-v3 originate-default=never redistribute="" router-id=192.168.0.66 routing-table=main version=3 /routing ospf area add disabled=no instance=backbone-v2 name=backbone-v2 add disabled=no instance=backbone-v3 name=backbone-v3 add area-id=0.0.0.66 disabled=no instance=backbone-v2 name=area-stub-v2 type=stub add area-id=0.0.0.66 disabled=no instance=backbone-v3 name=area-stub-v3 type=stub /routing ospf area range add area=area-stub-v2 cost=10 disabled=no prefix=10.177.66.0/24 add area=area-stub-v2 cost=10 disabled=no prefix=100.70.66.0/24 add area=area-stub-v2 cost=10 disabled=no prefix=100.71.66.0/24 add area=area-stub-v2 cost=10 disabled=no prefix=172.17.66.0/24 add area=area-stub-v3 cost=10 disabled=no prefix=2804:XXXX:XXXX::/48 /routing ospf interface-template add area=backbone-v2 cost=10 disabled=no interfaces=loopback networks=192.168.0.66/32 passive priority=1 add area=backbone-v3 cost=10 disabled=no interfaces=loopback networks=2804:XXXX:XXXX::/64 passive priority=1 add area=backbone-v2 cost=10 disabled=no interfaces=vlan10 networks=172.17.37.8/29 priority=1 type=ptp add area=backbone-v3 cost=10 disabled=no interfaces=vlan10 priority=1 type=ptp add area=area-stub-v2 comment="AREA STUB" cost=10 disabled=no networks=10.177.66.0/24,100.70.66.0/24,100.71.66.0/24,172.17.66.0/24 passive priority=1 type=ptp add area=area-stub-v3 comment="AREA STUB" cost=10 disabled=no networks=2804:XXXX:XXXX::/48 passive priority=1 type=ptp
That is correct! Many functions that are readily available as open source projects are being re-implemented. Not everything, though.Just look at the 7.13beta1 changelog:Am I the only one with conclusion, that MikroTik programmers are reimplementing existing code? I have such fears for years now.Code: Select all*) ovpn - improved memory allocation during key-renegotiation;
If they would be taking the original OpenVPN source code, then they won't have such problems - especially on the memory management level.
I would also say "powerdns" ;-)I would say "unbound", others maybe say "dnsmasq"
something like that really needs to be implemented ASAP.(already said a couple of time in the last months .. and sent support requests)
Old v6 command "ip route check x.y.z.k" still missing!
e.g. /ip route check 8.8.8.8 (linux equivalent "ip route get 8.8.8.8")
It's very usefull when you have many routes in your routing table and you don't want to waste your time looking for the best match (and/or make mistakes chosing the wrong one when in a hurry or under pressure!)
it should be trivial to get it done..
ip route print where x.x.x.x in dst-address
neither iscisco "show ip route x.x.x.x" is not equivalent to "ip route check".
You can already do the same as ciscos show ip route withCode: Select allip route print where x.x.x.x in dst-address
ip route print where x.x.x.x in dst-address
[admin@ROS7.11.2A] >export
/ip address
add address=10.0.0.1/24 interface=ether1 network=10.0.0.0
add address=192.168.1.1/25 interface=ether2 network=192.168.1.0
/routing ospf instance
add disabled=no name=ospf-instance-1 router-id=192.168.1.1
/routing ospf area
add disabled=no instance=ospf-instance-1 name=BB
add area-id=0.0.0.1 disabled=no instance=ospf-instance-1 name=1
/routing ospf area range
add area=1 disabled=no prefix=192.168.1.0/24
/routing ospf interface-template
add area=BB disabled=no interface=ether1
add area=1 disabled=no interface=ether2
[admin@ROS7.11.2B] >export
/ip address
add address=10.0.0.2/24 interface=ether1 network=10.0.0.0
add address=192.168.2.1/25 interface=ether2 network=192.168.2.0
/routing ospf instance
add disabled=no name=ospf-instance-1 router-id=192.168.2.1
/routing ospf area
add disabled=no instance=ospf-instance-1 name=BB
add area-id=0.0.0.2 disabled=no instance=ospf-instance-1 name=2
/routing ospf area range
add area=2 disabled=no prefix=192.168.2.0/24
/routing ospf interface-template
add area=BB disabled=no interface=ether1
add area=2 disabled=no interface=ether2
[admin@ROS7.12A] >export
/ip address
add address=10.0.0.3/24 interface=ether1 network=10.0.0.0
add address=192.168.3.1/25 interface=ether2 network=192.168.3.0
/routing ospf instance
add disabled=no name=ospf-instance-1 router-id=192.168.3.1
/routing ospf area
add disabled=no instance=ospf-instance-1 name=BB
add area-id=0.0.0.3 disabled=no instance=ospf-instance-1 name=3
/routing ospf area range
add area=3 disabled=no prefix=192.168.3.0/24
/routing ospf interface-template
add area=BB disabled=no interface=ether1
add area=3 disabled=no interface=ether2
[admin@ROS7.12B] >export
/ip address
add address=10.0.0.4/24 interface=ether1 network=10.0.0.0
add address=192.168.4.1/25 interface=ether2 network=192.168.4.0
/routing ospf instance
add disabled=no name=ospf-instance-1 router-id=192.168.4.1
/routing ospf area
add disabled=no instance=ospf-instance-1 name=BB
add area-id=0.0.0.4 disabled=no instance=ospf-instance-1 name=4
/routing ospf area range
add area=4 disabled=no prefix=192.168.4.0/24
/routing ospf interface-template
add area=BB disabled=no interface=ether1
add area=4 disabled=no interface=ether2
What makes you think mikrotik does not comply? Internet rumors? posts from 10 years ago?Well, as far as I know, the GPL license obligates, that any work based on existing GPL-licensed project must also be licensed under GPL. MikroTik doesn't comply to this and that's why in the past there were some questions about this very issue, like viewtopic.php?t=100746
Unfortunately it is not that easy. Remember you can have multiple routing tables with rules, route marking in mangle, and even VRF.cisco gives a definitive result which mirrors the routers routing decision rather then MTs version of "hey i got these routes which MIGHT could be used to route your asked DST"
a "show" cmd. to reflect the routers routing decision to the current FDB would be great.
The previous version was 7.11.2And what is your previous version? 7.11.2?from the previous version
My RB4011 runs fine in 7.12My RB4011 on firmware 7.12 reboot random from 45m to 3 ir 6 hours, on firmware 7.11.2 works fine.!!!
Can anyone help ir a clue, no messages on logs nothing .... Just reboots.
cAP ac or cAP ax? For the latter you will have to wait for v7.13 (currently beta) to be able.i can not add new cap to existed old capsMan
had the same issue beginning with 7.12rc2, the issue seems to be, as you said, that "directly" connected routes are not sent over area boundaries (lsa's of other routers are though). 7.13beta1 seems to fix it already, so I think they are aware of this but since nobody noticed the did not bother putting it in changelog (or 7.13 was branched before 7.12rc2 and is about to have that issue backported)It seems that v7.12 stable will not generate OSPF LSA type3 - “inter-area-prefix“ while v7.11.2 stable is ok.
Here are configs:
I've opened a ticket in support portal, SUP-134571Code: Select all[admin@ROS7.11.2A] >export /ip address add address=10.0.0.1/24 interface=ether1 network=10.0.0.0 add address=192.168.1.1/25 interface=ether2 network=192.168.1.0 /routing ospf instance add disabled=no name=ospf-instance-1 router-id=192.168.1.1 /routing ospf area add disabled=no instance=ospf-instance-1 name=BB add area-id=0.0.0.1 disabled=no instance=ospf-instance-1 name=1 /routing ospf area range add area=1 disabled=no prefix=192.168.1.0/24 /routing ospf interface-template add area=BB disabled=no interface=ether1 add area=1 disabled=no interface=ether2 [admin@ROS7.11.2B] >export /ip address add address=10.0.0.2/24 interface=ether1 network=10.0.0.0 add address=192.168.2.1/25 interface=ether2 network=192.168.2.0 /routing ospf instance add disabled=no name=ospf-instance-1 router-id=192.168.2.1 /routing ospf area add disabled=no instance=ospf-instance-1 name=BB add area-id=0.0.0.2 disabled=no instance=ospf-instance-1 name=2 /routing ospf area range add area=2 disabled=no prefix=192.168.2.0/24 /routing ospf interface-template add area=BB disabled=no interface=ether1 add area=2 disabled=no interface=ether2 [admin@ROS7.12A] >export /ip address add address=10.0.0.3/24 interface=ether1 network=10.0.0.0 add address=192.168.3.1/25 interface=ether2 network=192.168.3.0 /routing ospf instance add disabled=no name=ospf-instance-1 router-id=192.168.3.1 /routing ospf area add disabled=no instance=ospf-instance-1 name=BB add area-id=0.0.0.3 disabled=no instance=ospf-instance-1 name=3 /routing ospf area range add area=3 disabled=no prefix=192.168.3.0/24 /routing ospf interface-template add area=BB disabled=no interface=ether1 add area=3 disabled=no interface=ether2 [admin@ROS7.12B] >export /ip address add address=10.0.0.4/24 interface=ether1 network=10.0.0.0 add address=192.168.4.1/25 interface=ether2 network=192.168.4.0 /routing ospf instance add disabled=no name=ospf-instance-1 router-id=192.168.4.1 /routing ospf area add disabled=no instance=ospf-instance-1 name=BB add area-id=0.0.0.4 disabled=no instance=ospf-instance-1 name=4 /routing ospf area range add area=4 disabled=no prefix=192.168.4.0/24 /routing ospf interface-template add area=BB disabled=no interface=ether1 add area=4 disabled=no interface=ether2
Agreed, I've never before implemented an address list that did not take effect immediately.I'm pretty sure address lists "work" immediately. There's another "gem" with regard to firewall: new drop rules only affect new connections. Already established connectiobs are not affected. Clearing connection tracking table does the job (but drops all the rest of established connections, unrelated to the new rule) and rebooting router is one way to achieve this.
This is based on how iptables work: existing connections are in established stated what us usually handled by "established, related, (untracked)" rules before drop rules.There's another "gem" with regard to firewall: new drop rules only affect new connections
to clarify:Unfortunately it is not that easy. Remember you can have multiple routing tables with rules, route marking in mangle, and even VRF.cisco gives a definitive result which mirrors the routers routing decision rather then MTs version of "hey i got these routes which MIGHT could be used to route your asked DST"
a "show" cmd. to reflect the routers routing decision to the current FDB would be great.
Most likely the hardware did not (reliably) support it...Any idea why PoE auto was removed for L009?
You're right, but I'd be fine with the funcionality already present in ros6. More often than not in a core network you're not using strange policy-routes or magle manipulations, but you've plenty of routers & routes where you have to struggle to find the best match and follow it. When we have an issue and little time to troubleshoot these tools are life savers!For VRF, yes. But RouterOS can also policy-route depending on source address, incoming interface, or routing mark (assigned in firewall mangle rule).
This is often used for loadbalancing/failover or for overlay networks, where VRF is much too restrictive.
Nope, not mine..must be unique to your setup/environment.Router 4011 reboots on 7.12
i have opened a support ticket: SUP-134808
Back to 7.11.2
/interface bridge
add add-dhcp-option82=yes dhcp-snooping=yes name=bridge priority=0x7000 vlan-filtering=yes
/interface bridge port
add bridge=bridge interface=ether1 trusted=yes comment="Uplink to core:"
add bpdu-guard=yes bridge=bridge interface=ether2 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether3 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether4 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether5 restricted-role=yes
add bridge=bridge interface=wifi1
add bridge=bridge interface=wifi2
add bridge=bridge interface=wifi3
add bridge=bridge interface=wifi4
add bridge=bridge interface=wifi5
add bridge=bridge interface=wifi6
/interface bridge vlan
add bridge=bridge tagged=bridge vlan-ids=1
add bridge=bridge tagged=bridge,ether1,wifi1,wifi2,wifi3,wifi4,wifi5,wifi6 vlan-ids=52
add bridge=bridge tagged=bridge,ether1,wifi1,wifi2,wifi3,wifi4,wifi5,wifi6 vlan-ids=53
add bridge=bridge tagged=bridge,ether1,wifi1,wifi2,wifi3,wifi4,wifi5,wifi6 vlan-ids=666
add bridge=bridge tagged=bridge,ether1,wifi1,wifi2,wifi3,wifi4,wifi5,wifi6 vlan-ids=667
[admin@Ash - Cottage] > int bridge/port print
Flags: I - INACTIVE
Columns: INTERFACE, BRIDGE, HW, PVID, PRIORITY, PATH-COST, INTERNAL-PATH-COST, HOR
IZON
# INTERFACE BRIDGE HW PVID PRIORITY PATH-COST IN HORIZON
0 ether1 bridge yes 1 0x80 10 10 none
1 I ether2 bridge yes 1 0x80 10 10 none
2 I ether3 bridge yes 1 0x80 10 10 none
3 I ether4 bridge yes 1 0x80 10 10 none
4 I ether5 bridge yes 1 0x80 10 10 none
5 wifi1 bridge 1 0x80 10 10 none
6 wifi2 bridge 1 0x80 10 10 none
7 wifi3 bridge 1 0x80 10 10 none
8 wifi4 bridge 1 0x80 10 10 none
9 wifi5 bridge 1 0x80 10 10 none
10 wifi6 bridge 1 0x80 10 10 none
/interface bridge
add add-dhcp-option82=yes dhcp-snooping=yes name=bridge priority=0x6000 vlan-filtering=yes
/interface bridge port
add bridge=bridge interface=ether1 restricted-role=yes trusted=yes
add bridge=bridge interface=ether2 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether3 pvid=52 restricted-role=yes
add bridge=bridge interface=ether4 restricted-role=yes
add bridge=bridge interface=ether5 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=ether6 pvid=53 restricted-role=yes
add bridge=bridge interface=ether7 restricted-role=yes
add bridge=bridge interface=ether8 restricted-role=yes
add bpdu-guard=yes bridge=bridge interface=sfp-sfpplus1 restricted-role=yes
/interface bridge vlan
add bridge=bridge tagged=bridge vlan-ids=1
add bridge=bridge tagged=bridge,ether1,ether2,ether4,ether5,ether7,ether8 vlan-ids=52
add bridge=bridge tagged=bridge,ether1,ether2,ether4,ether5,ether7,ether8 vlan-ids=53
add bridge=bridge tagged=bridge,ether5 vlan-ids=200
add bridge=bridge tagged=bridge,ether1,ether2,ether5,ether7,ether8 vlan-ids=666
add bridge=bridge tagged=bridge,ether1,ether2,ether5,ether7,ether8 vlan-ids=667
[admin@Ash - Core] > int bridge/port print
Flags: I - INACTIVE; H - HW-OFFLOAD
Columns: INTERFACE, BRIDGE, HW, PVID, PRIORITY, PATH-COST, INTERNAL-PATH-COST, HORIZON
# INTERFACE BRIDGE HW PVID PRIORITY PATH-COST IN HORIZON
0 H ether1 bridge yes 1 0x80 10 10 none
1 H ether2 bridge yes 1 0x80 10 10 none
2 H ether3 bridge yes 52 0x80 10 10 none
3 H ether4 bridge yes 1 0x80 10 10 none
4 H ether5 bridge yes 1 0x80 10 10 none
5 IH ether6 bridge yes 53 0x80 10 10 none
6 H ether7 bridge yes 1 0x80 10 10 none
7 H ether8 bridge yes 1 0x80 10 10 none
8 IH sfp-sfpplus1 bridge yes 1 0x80 10 10 none
Thank you very much for that hint. I set up a mixed wave2 capsman setup with hap ax² and hap ac² and was wondering why roaming with my android phone was sometimes very slow.Hello, I am still facing the SA Query Timeout issue and some WIFi devices do not roam properly between the access points.
The workaround /interface/wifiwave2/configuration> set [find] security.connect-priority=0/1 works, but I am not sure that this is the right approach.
The IPQ-PPE switch isn't supported yet for L2HW offload.Unable to get hardware offloading working on a hAP ax3 (C53UiG+5HPaxD2HPaxD), any suggestions?
OSPF stopped exporting local areas, again :-/ Has been working fine with 7.11.2, now everything needs to go into the backbone area to be functional. Looks very much like a regression to me, as I've seen this in the past but it then got better (and now worse again *sigh*)
Unable to get hardware offloading working on a hAP ax3 (C53UiG+5HPaxD2HPaxD), any suggestions?
Status:Code: Select all/interface bridge add add-dhcp-option82=yes dhcp-snooping=yes name=bridge priority=0x7000 vlan-filtering=yes /interface bridge port add bridge=bridge interface=ether1 trusted=yes comment="Uplink to core:" add bpdu-guard=yes bridge=bridge interface=ether2 restricted-role=yes add bpdu-guard=yes bridge=bridge interface=ether3 restricted-role=yes add bpdu-guard=yes bridge=bridge interface=ether4 restricted-role=yes add bpdu-guard=yes bridge=bridge interface=ether5 restricted-role=yes add bridge=bridge interface=wifi1 add bridge=bridge interface=wifi2 add bridge=bridge interface=wifi3 add bridge=bridge interface=wifi4 add bridge=bridge interface=wifi5 add bridge=bridge interface=wifi6 /interface bridge vlan add bridge=bridge tagged=bridge vlan-ids=1 add bridge=bridge tagged=bridge,ether1,wifi1,wifi2,wifi3,wifi4,wifi5,wifi6 vlan-ids=52 add bridge=bridge tagged=bridge,ether1,wifi1,wifi2,wifi3,wifi4,wifi5,wifi6 vlan-ids=53 add bridge=bridge tagged=bridge,ether1,wifi1,wifi2,wifi3,wifi4,wifi5,wifi6 vlan-ids=666 add bridge=bridge tagged=bridge,ether1,wifi1,wifi2,wifi3,wifi4,wifi5,wifi6 vlan-ids=667
Code: Select all[admin@Ash - Cottage] > int bridge/port print Flags: I - INACTIVE Columns: INTERFACE, BRIDGE, HW, PVID, PRIORITY, PATH-COST, INTERNAL-PATH-COST, HOR IZON # INTERFACE BRIDGE HW PVID PRIORITY PATH-COST IN HORIZON 0 ether1 bridge yes 1 0x80 10 10 none 1 I ether2 bridge yes 1 0x80 10 10 none 2 I ether3 bridge yes 1 0x80 10 10 none 3 I ether4 bridge yes 1 0x80 10 10 none 4 I ether5 bridge yes 1 0x80 10 10 none 5 wifi1 bridge 1 0x80 10 10 none 6 wifi2 bridge 1 0x80 10 10 none 7 wifi3 bridge 1 0x80 10 10 none 8 wifi4 bridge 1 0x80 10 10 none 9 wifi5 bridge 1 0x80 10 10 none 10 wifi6 bridge 1 0x80 10 10 none
Similar configuration on a RB5009UG+S+ works perfectly:Status:Code: Select all/interface bridge add add-dhcp-option82=yes dhcp-snooping=yes name=bridge priority=0x6000 vlan-filtering=yes /interface bridge port add bridge=bridge interface=ether1 restricted-role=yes trusted=yes add bridge=bridge interface=ether2 restricted-role=yes add bpdu-guard=yes bridge=bridge interface=ether3 pvid=52 restricted-role=yes add bridge=bridge interface=ether4 restricted-role=yes add bridge=bridge interface=ether5 restricted-role=yes add bpdu-guard=yes bridge=bridge interface=ether6 pvid=53 restricted-role=yes add bridge=bridge interface=ether7 restricted-role=yes add bridge=bridge interface=ether8 restricted-role=yes add bpdu-guard=yes bridge=bridge interface=sfp-sfpplus1 restricted-role=yes /interface bridge vlan add bridge=bridge tagged=bridge vlan-ids=1 add bridge=bridge tagged=bridge,ether1,ether2,ether4,ether5,ether7,ether8 vlan-ids=52 add bridge=bridge tagged=bridge,ether1,ether2,ether4,ether5,ether7,ether8 vlan-ids=53 add bridge=bridge tagged=bridge,ether5 vlan-ids=200 add bridge=bridge tagged=bridge,ether1,ether2,ether5,ether7,ether8 vlan-ids=666 add bridge=bridge tagged=bridge,ether1,ether2,ether5,ether7,ether8 vlan-ids=667
Code: Select all[admin@Ash - Core] > int bridge/port print Flags: I - INACTIVE; H - HW-OFFLOAD Columns: INTERFACE, BRIDGE, HW, PVID, PRIORITY, PATH-COST, INTERNAL-PATH-COST, HORIZON # INTERFACE BRIDGE HW PVID PRIORITY PATH-COST IN HORIZON 0 H ether1 bridge yes 1 0x80 10 10 none 1 H ether2 bridge yes 1 0x80 10 10 none 2 H ether3 bridge yes 52 0x80 10 10 none 3 H ether4 bridge yes 1 0x80 10 10 none 4 H ether5 bridge yes 1 0x80 10 10 none 5 IH ether6 bridge yes 53 0x80 10 10 none 6 H ether7 bridge yes 1 0x80 10 10 none 7 H ether8 bridge yes 1 0x80 10 10 none 8 IH sfp-sfpplus1 bridge yes 1 0x80 10 10 none
have you try v 7.13.x?It seems that v7.12 stable will not generate OSPF LSA type3 - “inter-area-prefix“ while v7.11.2 stable is ok.
Here are configs:
I've opened a ticket in support portal, SUP-134571Code: Select all[admin@ROS7.11.2A] >export /ip address add address=10.0.0.1/24 interface=ether1 network=10.0.0.0 add address=192.168.1.1/25 interface=ether2 network=192.168.1.0 /routing ospf instance add disabled=no name=ospf-instance-1 router-id=192.168.1.1 /routing ospf area add disabled=no instance=ospf-instance-1 name=BB add area-id=0.0.0.1 disabled=no instance=ospf-instance-1 name=1 /routing ospf area range add area=1 disabled=no prefix=192.168.1.0/24 /routing ospf interface-template add area=BB disabled=no interface=ether1 add area=1 disabled=no interface=ether2 [admin@ROS7.11.2B] >export /ip address add address=10.0.0.2/24 interface=ether1 network=10.0.0.0 add address=192.168.2.1/25 interface=ether2 network=192.168.2.0 /routing ospf instance add disabled=no name=ospf-instance-1 router-id=192.168.2.1 /routing ospf area add disabled=no instance=ospf-instance-1 name=BB add area-id=0.0.0.2 disabled=no instance=ospf-instance-1 name=2 /routing ospf area range add area=2 disabled=no prefix=192.168.2.0/24 /routing ospf interface-template add area=BB disabled=no interface=ether1 add area=2 disabled=no interface=ether2 [admin@ROS7.12A] >export /ip address add address=10.0.0.3/24 interface=ether1 network=10.0.0.0 add address=192.168.3.1/25 interface=ether2 network=192.168.3.0 /routing ospf instance add disabled=no name=ospf-instance-1 router-id=192.168.3.1 /routing ospf area add disabled=no instance=ospf-instance-1 name=BB add area-id=0.0.0.3 disabled=no instance=ospf-instance-1 name=3 /routing ospf area range add area=3 disabled=no prefix=192.168.3.0/24 /routing ospf interface-template add area=BB disabled=no interface=ether1 add area=3 disabled=no interface=ether2 [admin@ROS7.12B] >export /ip address add address=10.0.0.4/24 interface=ether1 network=10.0.0.0 add address=192.168.4.1/25 interface=ether2 network=192.168.4.0 /routing ospf instance add disabled=no name=ospf-instance-1 router-id=192.168.4.1 /routing ospf area add disabled=no instance=ospf-instance-1 name=BB add area-id=0.0.0.4 disabled=no instance=ospf-instance-1 name=4 /routing ospf area range add area=4 disabled=no prefix=192.168.4.0/24 /routing ospf interface-template add area=BB disabled=no interface=ether1 add area=4 disabled=no interface=ether2
as said, 7.13beta1 and beta2 never had that issue. The real question is is that because they forked the 7.13 branch before 7.12rc2 (since they never noted something about ospf in the changelog of 7.13) or did they simply not mention that in the changelog hoping that nobody noticed the issuehave you try v 7.13.x?It seems that v7.12 stable will not generate OSPF LSA type3 - “inter-area-prefix“ while v7.11.2 stable is ok.
Here are configs:
I've opened a ticket in support portal, SUP-134571Code: Select all[admin@ROS7.11.2A] >export /ip address add address=10.0.0.1/24 interface=ether1 network=10.0.0.0 add address=192.168.1.1/25 interface=ether2 network=192.168.1.0 /routing ospf instance add disabled=no name=ospf-instance-1 router-id=192.168.1.1 /routing ospf area add disabled=no instance=ospf-instance-1 name=BB add area-id=0.0.0.1 disabled=no instance=ospf-instance-1 name=1 /routing ospf area range add area=1 disabled=no prefix=192.168.1.0/24 /routing ospf interface-template add area=BB disabled=no interface=ether1 add area=1 disabled=no interface=ether2 [admin@ROS7.11.2B] >export /ip address add address=10.0.0.2/24 interface=ether1 network=10.0.0.0 add address=192.168.2.1/25 interface=ether2 network=192.168.2.0 /routing ospf instance add disabled=no name=ospf-instance-1 router-id=192.168.2.1 /routing ospf area add disabled=no instance=ospf-instance-1 name=BB add area-id=0.0.0.2 disabled=no instance=ospf-instance-1 name=2 /routing ospf area range add area=2 disabled=no prefix=192.168.2.0/24 /routing ospf interface-template add area=BB disabled=no interface=ether1 add area=2 disabled=no interface=ether2 [admin@ROS7.12A] >export /ip address add address=10.0.0.3/24 interface=ether1 network=10.0.0.0 add address=192.168.3.1/25 interface=ether2 network=192.168.3.0 /routing ospf instance add disabled=no name=ospf-instance-1 router-id=192.168.3.1 /routing ospf area add disabled=no instance=ospf-instance-1 name=BB add area-id=0.0.0.3 disabled=no instance=ospf-instance-1 name=3 /routing ospf area range add area=3 disabled=no prefix=192.168.3.0/24 /routing ospf interface-template add area=BB disabled=no interface=ether1 add area=3 disabled=no interface=ether2 [admin@ROS7.12B] >export /ip address add address=10.0.0.4/24 interface=ether1 network=10.0.0.0 add address=192.168.4.1/25 interface=ether2 network=192.168.4.0 /routing ospf instance add disabled=no name=ospf-instance-1 router-id=192.168.4.1 /routing ospf area add disabled=no instance=ospf-instance-1 name=BB add area-id=0.0.0.4 disabled=no instance=ospf-instance-1 name=4 /routing ospf area range add area=4 disabled=no prefix=192.168.4.0/24 /routing ospf interface-template add area=BB disabled=no interface=ether1 add area=4 disabled=no interface=ether2
is it fixed yet?
thx
my tests showed that it is not that local areas are not exported but routes that are "local" to the router do not cross area boundaries. putting everything in one area is a possibility to workaround this.Same thing here. Nothing from local areas is exported, it doesn't work having the area configured as nssa nor default.
OSPF stopped exporting local areas, again :-/ Has been working fine with 7.11.2, now everything needs to go into the backbone area to be functional. Looks very much like a regression to me, as I've seen this in the past but it then got better (and now worse again *sigh*)
Correct. It doesn't redistribute any connected route (I tested with interface templates by interface and by network). I wonder if enabling "redistribute connected" would make it work, but our routers are in production and I cannot test it (there are many connected routes that I don't want to redistribute). I downgraded to 7.11.2 and everything went back to normal.my tests showed that it is not that local areas are not exported but routes that are "local" to the router do not cross area boundaries. putting everything in one area is a possibility to workaround this.Same thing here. Nothing from local areas is exported, it doesn't work having the area configured as nssa nor default.
Be sure card firmware up-to-date also.*) x86 - ixgbe updated driver to 5.19.6 version;
No, it works with sub-interfaces disabled.Does that mean if I want to have a 40G link on the qsfp28-1 port of a CCR2216-1G-12XS-2XQ, I have to enable all qsfp28-1-{1,2,3,4} interfaces before updating? What will be the state of those sub-interfaces when the 40G link is established?*) qsfp - use sub-interface configuration for establishing link (for 40Gbps and 100Gbps links, all sub-interfaces must be enabled);
The documented behavior (delete=remove matching, filter=remove non-matching) is the new one. Before 7.12, it worked the other way round.So is the documented behavior the old or the new one? Could you please – whichever it is – clarify the documentation?*) route - reverse community "delete" and "filter" command behavior;
Did you also upgrade the RouterBoard FW to 7.12.1?I upgraded two routers, connected together via mikrotik 5mt DAC cable. Their version was 7.11.2
1x CCR2004 16G
1x CCR1036 v3
I upgraded the first to 7.12.1
After upgrading the 2004, on the SFP port on the 1036 appeared fcs error and code error on the port.
upgraded also the 1036, it was the same.
downgraded the 2004 to 7.11.3 and the errors went away. The 1036 kept the latest version
Okay, I´m asking because I have also two 3m MT-DAC cable in use with 7.12.1, but between an CCR2004-1G-12S+2XS and a CRS326-24S+2Q+ and another CRS328-24P-4S+ with 7.12.1 without any problems. So it may be a device-specific problem...Did you also upgrade the RouterBoard FW to 7.12.1?
Of course, it is part of the standard upgrade procedure.
RouterOS upgrade, upgrade routerboot, reboot. Enjoy :-)
https://mikrotik.com/product/s_ao0005Hi, Maggiore81.
Can you create supout.rif files from both devices in the bad state and send them to support?
Just a small note, we do not make 5m DAC cables. Could you test if these errors appear when using a different DAC?
Thats an AOC. A DAC is Copper.
you are right!Thats an AOC. A DAC is Copper.
I also frequently make this error. :)
Well 7.12.1 addressed the issue for me. Time to give it a shot!It seems that v7.12 stable will not generate OSPF LSA type3 - “inter-area-prefix“ while v7.11.2 stable is ok.
Here are configs:
I've opened a ticket in support portal, SUP-134571Code: Select all[admin@ROS7.11.2A] >export /ip address add address=10.0.0.1/24 interface=ether1 network=10.0.0.0 add address=192.168.1.1/25 interface=ether2 network=192.168.1.0 /routing ospf instance add disabled=no name=ospf-instance-1 router-id=192.168.1.1 /routing ospf area add disabled=no instance=ospf-instance-1 name=BB add area-id=0.0.0.1 disabled=no instance=ospf-instance-1 name=1 /routing ospf area range add area=1 disabled=no prefix=192.168.1.0/24 /routing ospf interface-template add area=BB disabled=no interface=ether1 add area=1 disabled=no interface=ether2 [admin@ROS7.11.2B] >export /ip address add address=10.0.0.2/24 interface=ether1 network=10.0.0.0 add address=192.168.2.1/25 interface=ether2 network=192.168.2.0 /routing ospf instance add disabled=no name=ospf-instance-1 router-id=192.168.2.1 /routing ospf area add disabled=no instance=ospf-instance-1 name=BB add area-id=0.0.0.2 disabled=no instance=ospf-instance-1 name=2 /routing ospf area range add area=2 disabled=no prefix=192.168.2.0/24 /routing ospf interface-template add area=BB disabled=no interface=ether1 add area=2 disabled=no interface=ether2 [admin@ROS7.12A] >export /ip address add address=10.0.0.3/24 interface=ether1 network=10.0.0.0 add address=192.168.3.1/25 interface=ether2 network=192.168.3.0 /routing ospf instance add disabled=no name=ospf-instance-1 router-id=192.168.3.1 /routing ospf area add disabled=no instance=ospf-instance-1 name=BB add area-id=0.0.0.3 disabled=no instance=ospf-instance-1 name=3 /routing ospf area range add area=3 disabled=no prefix=192.168.3.0/24 /routing ospf interface-template add area=BB disabled=no interface=ether1 add area=3 disabled=no interface=ether2 [admin@ROS7.12B] >export /ip address add address=10.0.0.4/24 interface=ether1 network=10.0.0.0 add address=192.168.4.1/25 interface=ether2 network=192.168.4.0 /routing ospf instance add disabled=no name=ospf-instance-1 router-id=192.168.4.1 /routing ospf area add disabled=no instance=ospf-instance-1 name=BB add area-id=0.0.0.4 disabled=no instance=ospf-instance-1 name=4 /routing ospf area range add area=4 disabled=no prefix=192.168.4.0/24 /routing ospf interface-template add area=BB disabled=no interface=ether1 add area=4 disabled=no interface=ether2
The same thing happened on one of the hAP ax3, on the other hAP ac3After update to 7.12.1 my USB flash drive with containers attached to hAP AX3 became unreadable. Might just be me but thought I'd mention it in case the firmware upgrade is not cleanly unmounting the USB drive file systems. I mounted my USB flash drive on a linux system and ran fsck on it which solved the issue and I could attach it to the AX3 again.
Usually they ask supout before and after rebooted, well sometime we dont have supout when everything still running well or before we upgraded on something.Our CCR2004-16G-2S+ which ran fine with 7.11beta4 has now had two occurrences of "router was rebooted without proper shutdown by watchdog timer".
Did others see this as well? I have submitted a support ticket with supout.rif.
*) qsfp - fixed supported rates for breakout cables;MLAG again began to lose the secondary switch.
This behavior was noticed before, but it worked on 7.11.
Treat the variable by rebooting both switches until the second one becomes available.
Although this may have never been fixed...
CRS326-24S+2Q+ x2
That's unfortunate because it had been working reliably for me with a hap ax2 until I upgraded.Most likely the hardware did not (reliably) support it...Any idea why PoE auto was removed for L009?
/export file=anynameyoulike
For an upgrade from V6 to V7 my advice to you is:After 'simply' upgrading from the latest v6 to 7.12.1 (because of this: "ppc - fixed RouterOS bootup (introduced in v7.12);") on my RB850Gx2, many internal services, SSH, DNS, NTP, web config are not accessible anymore.
No DNS requests work anymore, `/ping google.com` on the router itself stopped working, clients who could DNS to 192.168.xx.1 do not get any answer anymore etc. The NTP client on the router can't get results, the System:Packages upgrades gives 'ERROR: could not resolve dns name'.
Internal services work, because there is one scenario in which it can connect: when I go from 192.168.48.xx to 192.168.48.1. Same scenario from '192.168.76.xx to 192.168.76.1' fails.
FW rules didn't change, but everything is checked extensively which a colleague running a similar config (VLAN as ports to bridges) on a rb3011.
will do... thanks.For an upgrade from V6 to V7 my advice to you is:
- Export config in V6 as RSC file
- Clear config
- upgrade to V7
- clear config once again
- import the RSC file topic by topic via terminal and fix errors
That's the most successful method to migrate your old config from V6 to V7 :-/
All other methods may work, but it could be that afterwards you have to "fight against ghosts"....
Unfortunately, this is not possible in ROS x86. Unwritten drivers. This is a very old problem.Hi guys
i am having issue in changing the L2MTU on V7.12.1 X64
Running 2 cards Intel XDA-520 and Mellanox Card dual 40Gbps all nics show up the same MTU 1500 and L2MTU 0 i cannot change the L2MTU.. is this done automatically? how can i change the L2MTU manually?
MTU.png
/ip/ssh/set host-key-type=ed25519;
That fixed it, thanks!Note that host key and public key authentication are different things. To switch the former to ed25519 use:Code: Select all/ip/ssh/set host-key-type=ed25519;
After upgrade to RouterOS v7.12, my router on x86
experiencing RX errors on 10Gb interface on Intel X520
card. Can anybody help me to solve this problem?
This problem can be solved. Go to the Interface Queues section. Select the interfaces where there are errors and change the queue type from "only-hardware-queue" to "mq-pfifo" and set the limit to 5000.After upgrade to RouterOS v7.12, my router on x86
experiencing RX errors on 10Gb interface on Intel X520
card. Can anybody help me to solve this problem?
Hiya
it looks like i am not the only one having issues then? I am running V7.12.1 stable.. just realized also... i was having queue drops and rx-erros..
queue drops increase i have fixed it using interface queues changing hardware defaul queue to multi-queue-ethernet-default..
but the RX-errors still increasing as shown on attached picture i am also using 2 slots intel x520 dae2 total 4 sfp+ ports and 1 Solarflare SFN7501 dual port sfp+
Rx-error only seems to happen on the Intel x520 cards.. the SFN running fine no erorrs..
wondering if could be and issue with the drivers on the intel x520dae2?
This problem can be solved. Go to the Interface Queues section. Select the interfaces where there are errors and change the queue type from "only-hardware-queue" to "mq-pfifo" and set the limit to 5000.
Hiya
it looks like i am not the only one having issues then? I am running V7.12.1 stable.. just realized also... i was having queue drops and rx-erros..
queue drops increase i have fixed it using interface queues changing hardware defaul queue to multi-queue-ethernet-default..
but the RX-errors still increasing as shown on attached picture i am also using 2 slots intel x520 dae2 total 4 sfp+ ports and 1 Solarflare SFN7501 dual port sfp+
Rx-error only seems to happen on the Intel x520 cards.. the SFN running fine no erorrs..
wondering if could be and issue with the drivers on the intel x520dae2?
HiThis problem can be solved. Go to the Interface Queues section. Select the interfaces where there are errors and change the queue type from "only-hardware-queue" to "mq-pfifo" and set the limit to 5000.