It would sure be convenient when there was some way to configure, per routing table, that all “connected” routes are to be inserted in that table too (like they are in main).
I think that would solve this issue, but it is also useful when you want to redistribute those routes in a routing protocol.
hEX S upgraded from 7.2.1 to 7.3 and now /ip/ssh> print throwing out: error - contact MikroTik support and send a supout file (2)
Same when exporting config: #error exporting /ip/ssh
Initially set:
strong-crypto: yes
host-key-size: 4096
Even when reverting to strong-cryto: no and host-key-size: 2048 (default values) - same thing.
On 7.2.1 all smooth.
Have another RB4011 running on 7.3 without any issues and all fine with /ip/ssh settings - so it seems to be a phenomenon on hEX S only.
Zerotier no longer gets an IP address?
twamuc - Could you please provide supout file to support@mikrotik.com? Generate a file after you have noticed such an error while running v7.3.
Strange Works fine on my hex S.
Hi,
It’s kind of complicated, but I did find the following.
/ip firewall mangle
add action=mark-routing chain=prerouting comment=International \
dst-address-list=!nice new-routing-mark=Cloudflare passthrough=yes \
src-address-list=private-lokal
/routing rule
add action=lookup disabled=no dst-address=0.0.0.0/0 routing-mark=Cloudflare \
table=Balifiber
Because there is a Cloudflare entry in ip route (for 0.0.0.0/0 shown below) the above rule is
overridden I think.
Perhaps
new-routing-mark=balifibre-mark in mangle (instead of Cloudflare)
routing-mark=balifibre-mark in routing rule
Also need balifibre-mark in /routing table
/ip route
add disabled=no distance=2 dst-address=0.0.0.0/0 gateway=wireguard1 pref-src=\
0.0.0.0 routing-table=Cloudflare scope=30 suppress-hw-offload=no \
target-scope=10
add check-gateway=ping comment=Balifiber disabled=no distance=1 dst-address=\
0.0.0.0/0 gateway=192.168.254.254 pref-src=0.0.0.0 routing-table=\
Balifiber scope=30 suppress-hw-offload=no target-scope=10
Yes that is exactly how it should work, mangle has the highest priority
- you are marking traffic with “cloudflare”
- and there is a route in the “cloudflare” table
- routing decision picks the forwarding path from the cloudflare table
If you remove the default route from “cloaudflare” table so that nexthop cannot be resolved in that table, then routing decision will move to the next adjustments: route rules.
just finished an automated testing on this very topic, and the results look pretty disappointing.
500 subsequent runs, each one separated by a device reboot. RA messages are sent every 5 seconds. after the device successfully gets a v4 address using DHCP the code waits 10 extra seconds to see whether SLAAC is successful or not (verified by a periodic ping from the same subnet)
root@l4s:~# grep -c v6 log.mtikslaactest.10s
500
root@l4s:~# grep v6 log.mtikslaactest.10s | grep -c 'v6 is OK'
132
root@l4s:~# grep v6 log.mtikslaactest.10s | grep -c 'slaac failed'
368
am I the only one who wants to use this feature?
Hi @mrz
few question then, is this routing logic change after ROS 7.2.1 because i dont see in changelog, in ROS 7.2.1 with conflicting mangle and routing rule like that in my config routing rule solve the problem, but i dont see that in ROS 7.3, even i add a static destination route in ip route still it routing to mangle first, i thought ip route is the highest priority i mean it is has the lower cost route
@MT, have you worked on the PIM-Routing? I see nothing in the cangelog.
In a random Wireshark-Scan, I see the IGMP-Querier is working (from the ROS7.3 device) and sending IGMP Membership Queries.
This happended also with <=ROSv7.2.x but after a few minutes it totally hang up…
Have not tested yet if the actual Multicast-Routing is working too.
ROSv7.2.3 (IGMP Querier not working, a few spikes but no continuous frames):
ROSv7.3 (continuous IGMP-Frames (the wwwww at the bottom of the graph), which - I suspect - are the Queries from the Querier):
[quote=andmar post_id=938445 time=1654764596 user_id=163724]
Since 7.2.2 my Chateau 5G was losing LTE connection few hours after reboot. Same problem with 7.2.3.
Locking cells, selecting bands or network didn’t change the outcome.
With 7.3 the issue is getting worse: without cell lock I noticed a frantic LTE cells switch during operation and again the frequent complete loss of LTE connection.
I tried also a clean installation of RouterOS with netinstall but no way.
Downgrading RouterOS to 7.2.1 restores the situation back to normal
I opened a ticket with support, enabled LTE logging and sent support file.
The support answer is worst than useless, they wrote to check APN and if my data plan is valid…
Anyone with same nightmare?
[/quote]
Another Chateau 5G owner here, I’m not seeing the issues you mention, I’m connecting to 3 UK, bands n78, b28, b3, b1, b20 + b32.
DOM/DMM at my RB760iGS still not wirk with ROS7 (but with ROS6 no problem)
i also have RB4011iGS+, CRS328-24P-4S+Cloud Router Switch, CRS112-8P-4S-IN Cloud Router Switch, hEXs RB760iGS, hEX PoE RB960PGS from 7.2.3 to 7.3 is still reporting ports flaps and all of these are work as bridge only but also RB5009UG reporting ports flaps and it’s connected with ISP and all other MT device that I mention connected to RB5009UG so I decided to downgrade to 7.2.3
Okay does anyone else have the following issue?
I am using two Mikrotik Audience’s, both running 7.3 with WiFi Wave 2.
It seems as though the wave two interface cannot pass traffic when it is on a bridge. I will try to explain with a breakdown.
Audience 1: Standard Router Config (Ether1 is DHCP Client, all other interfaces in Bridge)
Audience 2:(Standard AP Config, all interfaces in bridge)
When I add Aud2:WIFi3(backhaul) to the bridge on Aud2, no traffic traverses the backhaul between the two audiences. However, if I just add a DHCP client to the Aud2:WiFi3 interface, it gets a lease just fine. It seems as though Wave 2 has some problems with Bridge->Bridge connections.
OpenVPN works in UDP-mode, but with very slow speed. Dont know why. Playing with settings on client side - no luck for now…
7.3 upgrade still breaks x86-64 installation to bootloop state… Very bad…
At least on the CRS328, there’s a bug in the software leading to this. 7.4beta2 has the “fix” (disabling a core) and I’ve been running it for 3 days with no port flaps on SFP+ links. I was having flaps every few minutes ever since 7.x with these devices, which I was able to make better by disabling all disk-activity possible (no more graphing/lease storage/etc) to hourly or so. 7.4beta2 and I’ve had no flaps since installation. I’m letting it run until next week and if there’s still no flaps, then it’s “fixed”, even if it means a core is disabled. It’s absolutely wild it took over 6 months to fix something causing port flaps on many CRS328s (confirmed by many forum members) when it’s such an important function of a switch (link stability) but hey, at least it seems better with the beta.
Not sure on your other devices.
Hi,
I think the way it is doing it now does make some sense. In the example you are route marking the packet, and
telling it to use gateway x.x.x.x if it has that route mark. It now does exactly that, and nothing more.
I believe the change was related to VRF’s. Previously if your customer paying you for use of a VRF had a device with an IP address that was the same as any of the IP addresses on your router(s), you couldn’t (easily?) route packets to that device. This seems likely to work now.
Hiya,
I upgraded both my RB4011 and my parents RB3011 last night from 7.2.3 to 7.3 and the dhcp client no longer receives and address from Virgin media.
I have eth1 as the upstream internet facing interface with dhcp client on it nothing out of the ordinary. I could see traffic on the external interface so as a stop gap I gave them both static IP’s and static default routes (the last IP’s they had before upgrading) and its working again.
Ideally it would be nice to have dhcp working again for the internet facing interfaces - god knows what must have changed to stop the dhcp working as I’ve upgraded these things for 3 + years no problems and never had to downgrade.
Cheers!
Jon.
@Tenyun: I use the same switch with 7.3, but I have no problems with my 10 and 40GBit SFP connections. I use the following SFP+ modules:
- BROCADE 57-0000075-01
- MikroTik S+85DLC03D
- MikroTik S+DA0001
- MikroTik XS+DA0003
- MikroTik S+RJ10
- HP J9150A-C
For the QSFP+ connections I use (even with autonegotiation on): - FS QSFP-AO25
All run without problems.
what happened to Zerotier? I can’t see it anymore, seems to have gone from the interface and cant see in CLI ? My VPNs are down. 