Community discussions

 
Samot
Member Candidate
Member Candidate
Posts: 109
Joined: Sat Nov 25, 2017 10:01 pm

Re: v6.44.3 [stable] is released!

Wed May 01, 2019 4:34 pm

6.44.x have many bugs! far from stable, it breakdown 5G wifi.
And what bugs are those? Just saying it has "many bugs" isn't insightful or helpful at all. If it has many bugs please list them so the developers and others can be aware of them and try to replicate them in order to prove they are bugs. You've opened two threads about this already and they are just as insightful. You say there are numerous bugs and your 5G doesn't work but you've failed to provide any real substance of information and data.

So what are we exactly looking for and supposed to do about this? What type of configuration did you have? Anything special? Just a flat network?
 
gpuser
just joined
Posts: 3
Joined: Thu May 02, 2019 8:13 pm

Re: v6.44.3 [stable] is released!

Thu May 02, 2019 8:28 pm

Hello,

anyone experienced issue with cpu temperature after last upgrade?

I upgraded my device (CCR1036-12G-4S) from 6.42.3 to 6.44.3, and after that CPU temperature increase exponentially, I attach a screen

Image

Image

Thanks
Best Regards
 
pe1chl
Forum Guru
Forum Guru
Posts: 5830
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.44.3 [stable] is released!

Thu May 02, 2019 9:04 pm

I upgraded my device (CCR1036-12G-4S) from 6.42.3 to 6.44.3, and after that CPU temperature increase exponentially, I attach a screen
What does the CPU load show?
Also, your inlet air temperature seems to be 62C, maybe something else has failed?
 
gpuser
just joined
Posts: 3
Joined: Thu May 02, 2019 8:13 pm

Re: v6.44.3 [stable] is released!

Thu May 02, 2019 9:25 pm

Hi,
I attach CPU Graph, it does not seems changed

Image

Image

I tried to disable all drop firewall rules but problem persists

Any idea what could cause high temperature?

Regards
 
godzillante
just joined
Posts: 15
Joined: Tue Jul 25, 2017 1:07 pm

Re: v6.44.3 [stable] is released!

Fri May 03, 2019 10:54 am

Also, your inlet air temperature seems to be 62C, maybe something else has failed?
Hi,

are you 100% sure that it refers to 'inlet' air temp and not some different sensors on the routerboard? Because the room can't be at 62°C (144°F)... unless their office is located in hell :mrgreen:
 
pe1chl
Forum Guru
Forum Guru
Posts: 5830
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.44.3 [stable] is released!

Fri May 03, 2019 12:38 pm

That is why I think they need to do some research. Either the cabinet is cooking or something else has failed (like a failed airconditioner or rack fan).
In my experience, the temperature sensor on a CCR indicates only a little more than inlet air temperature, maybe it is a sensor on the motherboard that is close to the air pulled in.
(the fans blow the hot air outward so the cool air flows in through some vents and over the motherboard)
 
gpuser
just joined
Posts: 3
Joined: Thu May 02, 2019 8:13 pm

Re: v6.44.3 [stable] is released!

Fri May 03, 2019 6:19 pm

Thank you for your response. We're still investigating about problem to find the root cause.

However room temperature is around 22°C. On the same rack there are others mikrotik devices with a device temp around 30°C and CPU temp 45-50°C, so we have excluded external causes at the moment.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5830
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.44.3 [stable] is released!

Fri May 03, 2019 6:47 pm

Yes, 30C in a rack in a room at 22C is the normal situation for a CCR.
CPU is always around 50C, I think the fans are regulated towards that target.
(of course it can be higher when fans are at full speed)
 
ddff
just joined
Posts: 12
Joined: Sun Dec 02, 2012 9:23 pm

Re: v6.44.3 [stable] is released!

Fri May 03, 2019 8:37 pm

Evening, gents!

Did an upgrade to this version, but now I can't seem to be able to log on it anymore. Not via webfig nor Winbox 3.18.
Don't remember if I left on SSH access, but even if so that doesn't respond as well. Any tips?
 
pe1chl
Forum Guru
Forum Guru
Posts: 5830
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.44.3 [stable] is released!

Fri May 03, 2019 10:27 pm

You tried connecting to the MAC address?
 
sindy
Forum Guru
Forum Guru
Posts: 3811
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.44.3 [stable] is released!

Fri May 03, 2019 11:05 pm

Or, if it doesn't work either, maybe you have a serial port on the device or can connect an USB to serial converter to it and use command line to check and fix the configuration?
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
ddff
just joined
Posts: 12
Joined: Sun Dec 02, 2012 9:23 pm

Re: v6.44.3 [stable] is released!

Sat May 04, 2019 12:17 am

Yes, I tried both- IP and MAC, neither works. Just gives me a connection timeout, doesn’t get to login screen. Router works fine, VPN as well, just can’t access it, Winbox finds it in neighbour search, but that is basically it. I was thinking to use JTAG cable or at least hard reset, but it is really hard to get to the router as it is in remote location. So I wanted to check what other options I have.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5830
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.44.3 [stable] is released!

Sat May 04, 2019 11:06 am

When it is at a remote location, of course you need to try the MAC access local at that location. E.g. from a server machine that is connected to the LAN side of the router.
When that is not available, you probably need to go there with a laptop.
Bring the "netinstall" program (downloaded from the website), an uptodate set of packages (those you require for the router), and your recent backup of the configuration (that you make regularly, especially before doing an upgrade).
Then you can do a hard-reset and be back up in reasonable amount of time, when local attempts to access it fail as well.
(of course you try the MAC and serial access locally, or even via the LCD screen if it has one)

Another thing to do when using the routers with more than 16MB flash that are currently sold (e.g. CCR but even RB2011 or old RB750): partition the device!
When you go to the partition menu you can make 2 partitions (it will reboot), then copy part0 to part1 before every upgrade, and when something goes wrong it is possible to make the router switch to part1 by powercycling it during its startup sequence, and it boots your previous version. You can also switch to part1 and reboot remotely, e.g. when a new update does not work well, so you can go back operating to the previous working version. This is especially convenient when your router is on a remote site, it has saved me before when updates were released that corrupted the storage.
(when a new version works OK and/or when major changes have been made to the configuration it is best to always re-do the copy, especially when the site has unreliable power, or else you may suddenly find the router running the old version after some glitch in the power)
 
alejosalmon
just joined
Posts: 23
Joined: Sun May 31, 2015 3:02 pm

Re: v6.44.3 [stable] is released!

Sat May 04, 2019 8:17 pm

Mikrotik please add support for Sxtsq ac US version equipment .Thanks
 
banan
just joined
Posts: 2
Joined: Sun Feb 11, 2018 11:45 pm

Re: v6.44.3 [stable] is released!

Mon May 06, 2019 8:10 pm

Problem with FreePBX and 6.44.3 - don't allow to register on external sip account
version 6.43.14 fix the problem
 
cdemers
Member Candidate
Member Candidate
Posts: 184
Joined: Sun Feb 26, 2006 3:32 pm
Location: Canada
Contact:

Re: v6.44.3 [stable] is released!

Tue May 07, 2019 3:58 am

I'm using 6.44.3 with freepbx without any issues.


Sent from my SM-A520W using Tapatalk

 
LeftyTs
Frequent Visitor
Frequent Visitor
Posts: 71
Joined: Thu Nov 03, 2016 2:39 am
Location: Athens, Greece
Contact:

Re: v6.44.3 [stable] is released!

Tue May 07, 2019 4:20 am

Problem with FreePBX and 6.44.3 - don't allow to register on external sip account
version 6.43.14 fix the problem
You should check and review your firewall rules
 
LeftyTs
Frequent Visitor
Frequent Visitor
Posts: 71
Joined: Thu Nov 03, 2016 2:39 am
Location: Athens, Greece
Contact:

Re: v6.44.3 [stable] is released!

Tue May 07, 2019 4:26 am

Hello,

anyone experienced issue with cpu temperature after last upgrade?

I upgraded my device (CCR1036-12G-4S) from 6.42.3 to 6.44.3, and after that CPU temperature increase exponentially, I attach a screen
Thanks
Best Regards
Check your fans. I don't have any problems with the upgrades in a few of CCR1036s. Sounds more like a fan failure. Check if both fan RPMs are around 4000 or so.

PS: Just noticed your fans are WAY too high. It seems more like a configuration (ROS?) issue. If you have the luxury to do so, you could reset all to factory defaults and check if everything works ok. If yes then while monitoring slowly just start adding things up.
Last edited by LeftyTs on Wed May 08, 2019 2:25 am, edited 2 times in total.
 
SJB
just joined
Posts: 12
Joined: Sat Mar 16, 2019 7:56 pm

Re: v6.44.3 [stable] is released!

Tue May 07, 2019 11:52 pm

Hi there, I’m about to setup load balancing on a routerboard running 6.44.3
Is anyone aware if load balancing works under this OS version. I’ve read there have been some issues on previous versions in the past.
Thank you.
 
sindy
Forum Guru
Forum Guru
Posts: 3811
Joined: Mon Dec 04, 2017 9:19 pm

Re: v6.44.3 [stable] is released!

Wed May 08, 2019 12:43 am

Is anyone aware if load balancing works under this OS version. I’ve read there have been some issues on previous versions in the past.
There is a dedicated topic on that but the OP never came back with the answers to my questions.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
LeftyTs
Frequent Visitor
Frequent Visitor
Posts: 71
Joined: Thu Nov 03, 2016 2:39 am
Location: Athens, Greece
Contact:

Re: v6.44.3 [stable] is released!

Wed May 08, 2019 1:33 am

Hi there, I’m about to setup load balancing on a routerboard running 6.44.3
Is anyone aware if load balancing works under this OS version. I’ve read there have been some issues on previous versions in the past.
Thank you.
I am using 2 load balanced routers in 2 different locations (PCC load balancing) and none of them had any issues so far. This is a very general question though. There are a few ways to setup load balancing. Which one are you referring to?

https://wiki.mikrotik.com/wiki/Load_Balancing
 
pe1chl
Forum Guru
Forum Guru
Posts: 5830
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.44.3 [stable] is released!

Wed May 08, 2019 10:54 am

Usually when people refer to "there are load balancing issues in this version", what they really mean is "I had a configuration that was incorrect but worked on version X, but no longer works on version X+1", and then proceed to blame version X+1, rather than their incorrect configuration, for it.
Usually this is because version X+1 had more support for fast path (fasttrack), and therefore it fasttracked their traffic (which version X did not do), and they do not realize that fasttracking breaks those configurations.
Once you remove the fasttrack and fast path, it normally works OK.
(of course you need a router that can handle the load-balanced traffic without using fasttrack, so don't get a hAP mini to use as your corporate load balancer!!)
 
SJB
just joined
Posts: 12
Joined: Sat Mar 16, 2019 7:56 pm

Re: v6.44.3 [stable] is released!

Wed May 08, 2019 2:47 pm

Is anyone aware if load balancing works under this OS version. I’ve read there have been some issues on previous versions in the past.
There is a dedicated topic on that but the OP never came back with the answers to my questions.
Given a remote area with no cable connections I need to go through the air.
The idea is to setup 2 x LHG lte dishes together with 1 x Wimax, so actually 3 x Wan.
If it wasn’t for a fixed ip adres I’d drop the Wimax as unreliable on connection.
As I read from all the response, setting up PCC load balance with 3 x static IP should work, providing making sure not to add default routing in the interfaces and disabling fasttracks?
 
SJB
just joined
Posts: 12
Joined: Sat Mar 16, 2019 7:56 pm

Re: v6.44.3 [stable] is released!

Wed May 08, 2019 2:52 pm

PCC method with 3 x Wan with static IP’s on a HEX.
It’s not really the amount of users (2-3 ) but to cope with varying unreliable down/up speeds. So basically I’m trying to spread the risk of bring down and/ or having low speeds.
 
andriys
Forum Guru
Forum Guru
Posts: 1179
Joined: Thu Nov 24, 2011 1:59 pm
Location: Kharkiv, Ukraine

Re: v6.44.3 [stable] is released!

Wed May 08, 2019 2:56 pm

SJB, please start a new thread and keep this one strictly for the 6.44.3 version related discussions.
 
rzirzi
Member
Member
Posts: 378
Joined: Mon Oct 09, 2006 2:33 pm

Re: v6.44.3 [stable] is released!

Thu May 09, 2019 8:09 am

I have NO IPSEC configuration, but at ROS 6.44.3 export file is:
#error exporting /ip ipsec mode-config
#error exporting /ip ipsec peer
#error exporting /ip ipsec policy group
#error exporting /ip ipsec profile
#error exporting /ip ipsec proposal

BUG, BUG, BUG
 
User avatar
docmarius
Forum Guru
Forum Guru
Posts: 1219
Joined: Sat Nov 06, 2010 12:04 pm
Location: Timisoara, Romania
Contact:

Re: v6.44.3 [stable] is released!

Thu May 09, 2019 9:38 am

Those are only comments in your export and will be ignored...
There are some default template entries in IPsec which the system probably expects NOT to be missing (e.g. the default policy template, default proposal, default group, default profile, default mode-profile), and can not be normally deleted.
So it's more like 'maybe cosmetic bug', not "BUG BUG BUG'.
/ip ipsec mode-config
set [ find default=yes ] name=request-only responder=no
/ip ipsec policy group
set [ find default=yes ] name=default
/ip ipsec profile
set [ find default=yes ] dh-group=modp1024 dpd-interval=2m dpd-maximum-failures=5 enc-algorithm=aes-128,3des hash-algorithm=sha1 lifetime=1d name=default nat-traversal=no proposal-check=\
    obey
/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha1 disabled=no enc-algorithms=aes-256-cbc,aes-192-cbc,aes-128-cbc lifetime=30m name=default pfs-group=modp1024
/ip ipsec policy
set 0 disabled=no dst-address=::/0 group=default proposal=default protocol=all src-address=::/0 template=yes
/ip ipsec settings
set xauth-use-radius=no
Torturing CCR1009-7G-1C-1S+, RB450G, RB750GL, RB951G-2HnD, RB960PGS, RB260GSP, OmniTIK 5HnD and NetMetal 922UAGS-5HPacD + R11e-5HnD in my home network.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5830
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.44.3 [stable] is released!

Thu May 09, 2019 11:50 am

There are some default template entries in IPsec which the system probably expects NOT to be missing (e.g. the default policy template, default proposal, default group, default profile, default mode-profile), and can not be normally deleted.
Maybe it can be done like this (I did not try):
- remove security package
- maybe reset-configuration (to be sure there is no ipsec configuration)
- add security package again (e.g. after discovering it also does SSH)
Now there is no config for the ipsec defaults and it could be they are not re-created because no default config build is done anymore

I do know that it is an issue with the IPv6 package.
IMHO a package that finds itself newly installed/enabled should run its default-configuration script and tell the admin it did that, similar to the way the router initially builds default config and asks if this is to be accepted or removed.
Without that, e.g. the IPv6 package does not populate the firewall when installed/enabled.
It could be that this bug (indeed a cosmetic bug, not very fatal) results from the same design issue.
 
LeftyTs
Frequent Visitor
Frequent Visitor
Posts: 71
Joined: Thu Nov 03, 2016 2:39 am
Location: Athens, Greece
Contact:

Re: v6.44.3 [stable] is released!

Thu May 09, 2019 12:43 pm

I have NO IPSEC configuration, but at ROS 6.44.3 export file is:
#error exporting /ip ipsec mode-config
#error exporting /ip ipsec peer
#error exporting /ip ipsec policy group
#error exporting /ip ipsec profile
#error exporting /ip ipsec proposal

BUG, BUG, BUG
If I recall it correctly, these "errors" appeared a couple of ROS versions ago if you did an upgrade with the DHCP package disabled. Try enabling the dhcp package if you have it disabled. These "errors" should be gone after that.
 
Marino
Frequent Visitor
Frequent Visitor
Posts: 53
Joined: Sun Jun 14, 2015 7:26 pm

Re: v6.44.3 [stable] is released!

Thu May 09, 2019 8:25 pm

I have NO IPSEC configuration, but at ROS 6.44.3 export file is:
#error exporting /ip ipsec mode-config
#error exporting /ip ipsec peer
#error exporting /ip ipsec policy group
#error exporting /ip ipsec profile
#error exporting /ip ipsec proposal

BUG, BUG, BUG
Same at my configuration: CHR on KVM. First it appears after a reboot on 6.44 firmware. I upgraded to 6.44.2 and restored a backup. All fine until I upgraded to 6.44.3. All IPSec configs and default templates gone again. I couldn't change the IPsec configuration either. I had to downgrade to 6.43.14 and restored an old backup.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5830
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.44.3 [stable] is released!

Thu May 09, 2019 8:37 pm

Did you restore a backup made on a lower version? Should not do that, because sometimes configuration structure is changed and the conversion is only made during the upgrade.
So the new version will not be able to handle the old configuration.
This is even mentioned in some of the release notes...
 
Marino
Frequent Visitor
Frequent Visitor
Posts: 53
Joined: Sun Jun 14, 2015 7:26 pm

Re: v6.44.3 [stable] is released!

Thu May 09, 2019 9:58 pm

Did you restore a backup made on a lower version? Should not do that, because sometimes configuration structure is changed and the conversion is only made during the upgrade.
So the new version will not be able to handle the old configuration.
This is even mentioned in some of the release notes...
For version 6.44 and 6.44.2 I restored a backup made with that version. For 6.43.14 an older one, made with some 6.43 version.
 
isoppo
just joined
Posts: 1
Joined: Thu Apr 04, 2019 8:29 pm

Re: v6.44.3 [stable] is released!

Thu May 09, 2019 11:10 pm

Is there someone else having Radius Timeout issues, like me and this guy: viewtopic.php?t=146485&start=50#p722261 -?

We were running on 6.43.4 across the board.
I upgraded our RouterOS gear due to the IPv6 soft lockup fixes provided on 6.44.2. That's when we started experiencing these Radius Timeout issues.

The only way to get around that is to reboot the router. Disabling/Enabling Radius options doesn't help.

When it happens, the Radius Server's IP address is still reachable, but no packets from the affected router are received on the server side.

I've noticed this only on our busiest routers (CCRs). RB3011 and other models, with less PPPoE clients, didn't behave this way yet.

Sample from a CCR-1036-8G-2S+:
Image
(Link: https://imgur.com/a/zOAWZ4K)


Edit: Even though the issue started on 6.44.2, I'm on 6.44.3 right now, facing exactly the same.
 
LeftyTs
Frequent Visitor
Frequent Visitor
Posts: 71
Joined: Thu Nov 03, 2016 2:39 am
Location: Athens, Greece
Contact:

Re: v6.44.3 [stable] is released!

Fri May 10, 2019 11:17 am

In a couple of CRS326 switches I have the exact same problem for a few months now. Ports that appear to have high rx-overlows in interface ethernet statistics, for some strange reason after a certain time become unresponsive. Before v6.44 if I was disabling and re-enabling the problem port, it would come back to life. Now I have to reboot the whole switch. Ticket id 2018122022004844
 
Fedes
just joined
Posts: 7
Joined: Sat Jun 30, 2012 7:51 am

Re: v6.44.3 [stable] is released!

Fri May 10, 2019 9:58 pm

Hello,

Can I ask why was the sfp-led removed from rb2011 system/leds menu?

*) rb2011 - removed "sfp-led" from "System/LEDs" menu;

I was kinda using this.

Thanks,
 
buzzlightyear
just joined
Posts: 1
Joined: Sat May 11, 2019 7:43 pm

Re: v6.44.3 [stable] is released!

Sat May 11, 2019 7:50 pm

6.44.3 is not stable in my opinion. Upgraded my RB433 three days ago, and ever since I had MAJOR wifi stability issues, it would just dropout. Reboot would help temporarily, and not always.

I've downgraded to 6.42.12, which is what I had before, and all issues disappeared.
 
mikeeg02
just joined
Posts: 10
Joined: Fri Mar 30, 2018 2:28 am

Re: v6.44.3 [stable] is released!

Mon May 13, 2019 6:52 pm

I upgraded our system to 6.44.3 a few weeks ago. My "hub" router is a rb1100AHx4 dude edition that runs also the dude. After a few weeks of running, the routeros and http services on every device that utilized them timed out. Ping, and the other dude services worked, as well as the ospf and mpls services that are running. Thats all the router is doing, no firewall filtering, etc as its all private backhaul. I noticed cpu utilization on cpu2 "unclassified" was running maxed out. Tried stopping the dude and a few other tricks, but couldnt get it to stop. Rebooted and usage is back down to almost nothing. Anyone have any idea what the "unclassified" service might have been? Nothing in the log looked out of place.

usage.png
You do not have the required permissions to view the files attached to this post.
 
CuninganReset
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Mon May 02, 2016 7:49 pm

Re: v6.44.3 [stable] is released!

Thu May 16, 2019 1:39 pm

Hello.

I think Router OS V6.44.X has introduced an issue with the GPS package.
Since I upgraded to 6.44.X (2 or 3) the latitude and longitude values of the GPS are 32 characters long rather than the normal length.

I am using the GPS to send information to a webpage using the GPS example but now it is failing because of the new length, new characters are read as "NULL"
Captura3.PNG
Captura4.PNG
I have tracked the issue and it is related to the size of "latitude" and "longitude" in the RouterOS 6.44
Here with RouterOS 6.44.3 you can see the length is 32.
Captura.PNG
Here with RouterOS 6.43.2 you can see the length is 16.
Captura2.PNG
You do not have the required permissions to view the files attached to this post.
 
User avatar
eworm
Member
Member
Posts: 393
Joined: Wed Oct 22, 2014 9:23 am
Location: Oberhausen, Germany
Contact:

Re: v6.44.3 [stable] is released!

Thu May 16, 2019 2:10 pm

Hello.

I think Router OS V6.44.X has introduced an issue with the GPS package.
Since I upgraded to 6.44.X (2 or 3) the latitude and longitude values of the GPS are 32 characters long rather than the normal length.
Already fixed in latest beta version, will be available in stable soon.
Manage RouterOS scripts and extend your devices' functionality: RouterOS Scripts
 
Jipp
just joined
Posts: 1
Joined: Mon Aug 13, 2018 8:49 am

Re: v6.44.3 [stable] is released!

Mon May 20, 2019 4:38 pm

We are having issues with the R11e-2HPnD wireless module on RBM33G.
R11e-2HPnD is not identified in the 6.44.3 release?
Not showing in interfaces.
If we downgrade everything is honkydory.

Anyone else having issues with wlan modules or is it just this combo ?
 
anuser
Member
Member
Posts: 397
Joined: Sat Nov 29, 2014 7:27 pm

Re: v6.44.3 [stable] is released!

Tue May 21, 2019 10:18 pm

Just rebooted a CCR1036 with v6.44.3. Well the switch it is attached to says that all interfaces plus 1x LACP are up. But I cannot ping the CCR from it, on none of the interfaces.
 
CuninganReset
Frequent Visitor
Frequent Visitor
Posts: 60
Joined: Mon May 02, 2016 7:49 pm

Re: v6.44.3 [stable] is released!

Wed May 22, 2019 11:48 pm

Thanks!
Hello.

I think Router OS V6.44.X has introduced an issue with the GPS package.
Since I upgraded to 6.44.X (2 or 3) the latitude and longitude values of the GPS are 32 characters long rather than the normal length.
Already fixed in latest beta version, will be available in stable soon.
 
anuser
Member
Member
Posts: 397
Joined: Sat Nov 29, 2014 7:27 pm

Re: v6.44.3 [stable] is released!

Thu May 23, 2019 12:11 am

Enabling FastPath handler on CCR1036 kills VRF performance (some kbit/s of throughput). After disabling FastPath, I get full routing performance back.
 
anuser
Member
Member
Posts: 397
Joined: Sat Nov 29, 2014 7:27 pm

Re: v6.44.3 [stable] is released!

Tue May 28, 2019 1:42 pm

I´m currently "watching" an Apple client (C8:3C:85:33:B3:10). The phone connects itself automatically to one specific cAP ac. What can I see repeatedly:

- The client connects to wifi successfully
- The DHCP server shows the MAC of the client. Within "DHCP Lease" windows I can see the status which is "offered".
- "Expires After" is couting down from 00:00:31 seconds to 0.
- Inbetween that time frame the client disconnects and reconnects.
- For some few seconds (~5), within the "DHCP Lease" window, it shows "bound"
- After that it changes from "bound" to "DHCP Lease" again.
- The whole process repeats now for over 10 minutes while writing this message.

Looking at the "DHCP Server" => "Leases" window and sort it by "offered status", I currently see the about 8 "...iPhone" with the same behaviour, i.e. they reoccur within the list saying "offered" over and over. Those iPhone don´t use the same access point as the Apple device above, but also some other cAP ac running 6.44.3 code.

Update 1:
- Within "DHCP Lease" windows activated "Make Static" => No change
- Within static DHCP lease windows: I changed step by step: "Lease Time", hit "Usr Src. MAC Address", changed "Insert Queue Before" to bottom => No change
Update 2:
- I downgraded another cAP ac to 6.43.16 which is next to the cAP ac from above and deacitvated both radios on the the cAP ac with version 6.44.3 => the Apple client connected to the cAP ac with 6.43.16, the status within "DHCP lease" is now on bound for over 20 minutes.
- I deactivated both radios one cAP ac mentioned above
Update 3:
The client changed the building. It is now on another cAP ac with 6.44.3. The client obviously works and is producing traffic.
 
selin19
just joined
Posts: 1
Joined: Tue May 28, 2019 3:51 pm
Contact:

Re: v6.44.3 [stable] is released!

Tue May 28, 2019 3:56 pm

I have just upgraded an hAP AC 2 `RBD52G-5HacD2HnD` from `6.44.2` to `6.44.3` and for some reason my iPhone 5s doesn't seem to "detect" the 5GHz wireless network which worked just fine before upgrading.
 
MartijnVdS
Frequent Visitor
Frequent Visitor
Posts: 93
Joined: Wed Aug 13, 2014 9:36 am

Re: v6.44.3 [stable] is released!

Tue May 28, 2019 4:10 pm

I have just upgraded an hAP AC 2 `RBD52G-5HacD2HnD` from `6.44.2` to `6.44.3` and for some reason my iPhone 5s doesn't seem to "detect" the 5GHz wireless network which worked just fine before upgrading.
Maybe the AP is still in "DFS wait" mode, checking if there's radars on the frequency it/you chose?
 
pe1chl
Forum Guru
Forum Guru
Posts: 5830
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.44.3 [stable] is released!

Tue May 28, 2019 7:31 pm

I´m currently "watching" an Apple client (C8:3C:85:33:B3:10).
What is your DHCP lease time? I think some versions of Apple firmware do not like very short lease times. Set it to 1 day or higher.
 
Fedes
just joined
Posts: 7
Joined: Sat Jun 30, 2012 7:51 am

Re: v6.44.3 [stable] is released!

Tue May 28, 2019 7:36 pm

Hi,

I know this is not critical, but wanted to know the reason for this change, since it was a good visual aid:

*) rb2011 - removed "sfp-led" from "System/LEDs" menu;

Thanks!
 
anuser
Member
Member
Posts: 397
Joined: Sat Nov 29, 2014 7:27 pm

Re: v6.44.3 [stable] is released!

Tue May 28, 2019 10:46 pm

I´m currently "watching" an Apple client (C8:3C:85:33:B3:10).
What is your DHCP lease time? I think some versions of Apple firmware do not like very short lease times. Set it to 1 day or higher.
DHCP lease time is 8 hours and 10 minutes. Shouldn´t this be enough...? As mentioned before. The problem was gone when I changed RouterOS version to 6.43.16 on the cAP ac only
 
SolarClint
just joined
Posts: 4
Joined: Tue May 28, 2019 1:32 am

Re: v6.44.3 [stable] is released!

Wed May 29, 2019 1:12 am

We are trying to upgrade to 6.44.3 from 6.29. I can download the file and it is in the files window. It will not install. I have tried to reboot 5 or 6 times and still nothing. Any advice?
 
User avatar
AlainCasault
Trainer
Trainer
Posts: 609
Joined: Fri Apr 30, 2010 3:25 pm
Location: Laval, QC, Canada
Contact:

Re: v6.44.3 [stable] is released!

Wed May 29, 2019 1:22 am

We are trying to upgrade to 6.44.3 from 6.29. I can download the file and it is in the files window. It will not install. I have tried to reboot 5 or 6 times and still nothing. Any advice?
Look at the log. It should tell you why. Usually, you've chosen files for the wrong architecture.

Sent from my cell phone. Sorry for the errors.

___________________________
Alain Casault, Eng.
If I helped you, let me know!
 
pe1chl
Forum Guru
Forum Guru
Posts: 5830
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.44.3 [stable] is released!

Wed May 29, 2019 10:11 am

We are trying to upgrade to 6.44.3 from 6.29. I can download the file and it is in the files window. It will not install. I have tried to reboot 5 or 6 times and still nothing. Any advice?
That is not advisable! You have not updated for so many years that it cannot be expected to be a smooth process.
It is better to investigate what is configured, make a /export so you have complete notes, and then netinstall the new version and start from scratch.
 
Kindis
Member Candidate
Member Candidate
Posts: 248
Joined: Tue Nov 01, 2011 6:54 pm

Re: v6.44.3 [stable] is released!

Wed May 29, 2019 1:40 pm

We are trying to upgrade to 6.44.3 from 6.29. I can download the file and it is in the files window. It will not install. I have tried to reboot 5 or 6 times and still nothing. Any advice?
That is not advisable! You have not updated for so many years that it cannot be expected to be a smooth process.
It is better to investigate what is configured, make a /export so you have complete notes, and then netinstall the new version and start from scratch.
I would say the same but if they want to try it out (make propper backup and export before attempting) test the following upgrade patch

6.30.1
6.34.5
6.40.9
6.42.9
6.43.16

I'm not saying this will work without issues but will give you a better odds at making it :-)
 
mlenhart
Frequent Visitor
Frequent Visitor
Posts: 83
Joined: Mon Oct 30, 2017 11:30 pm

Re: v6.44.3 [stable] is released!

Wed May 29, 2019 9:58 pm

BUG REPORT

Hello,

I would like to report a wrong Last Link Down Time showed in Winbox.
This issue has been seen on WW Dish, and hAP AC.
Time is in future, which is impossible.
Please see attached screenshot: https://paste.pics/5OJ84
 
Thulgar
just joined
Posts: 1
Joined: Wed Jun 20, 2018 10:39 am

Re: v6.44.3 [stable] is released!

Thu May 30, 2019 8:54 am

BUG REPORT

Hello,

I would like to report a wrong Last Link Down Time showed in Winbox.
This issue has been seen on WW Dish, and hAP AC.
Time is in future, which is impossible.
Please see attached screenshot: https://paste.pics/5OJ84
You didn't show the time in winbox (next to the Uptime). Your MK probably has wrong time settings.
 
mlenhart
Frequent Visitor
Frequent Visitor
Posts: 83
Joined: Mon Oct 30, 2017 11:30 pm

Re: v6.44.3 [stable] is released!

Fri May 31, 2019 9:10 am

BUG REPORT

Hello,

I would like to report a wrong Last Link Down Time showed in Winbox.
This issue has been seen on WW Dish, and hAP AC.
Time is in future, which is impossible.
Please see attached screenshot: https://paste.pics/5OJ84
You didn't show the time in winbox (next to the Uptime). Your MK probably has wrong time settings.
Will this convince you it´s a bug ?
2nd hAP ac - 6_44_3.JPG
You do not have the required permissions to view the files attached to this post.
 
pe1chl
Forum Guru
Forum Guru
Posts: 5830
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.44.3 [stable] is released!

Fri May 31, 2019 11:13 am

That wrong time is a "known problem" that was introduced several versions ago, not with this version.
It likely is already on the list of things to fix.
 
User avatar
Cha0s
Forum Veteran
Forum Veteran
Posts: 901
Joined: Tue Oct 11, 2005 4:53 pm

Re: v6.44.3 [stable] is released!

Fri May 31, 2019 12:45 pm

That wrong time is a "known problem" that was introduced several versions ago, not with this version.
It likely is already on the list of things to fix.
Also I believe it's a winbox bug and not a ROS bug. CLI shows the correct times.
IIRC deleting the session on winbox also shows the correct times (until the next login using a previous session).
 
amojak
just joined
Posts: 8
Joined: Sat Nov 10, 2018 9:10 pm

Re: v6.44.3 [stable] is released!

Fri May 31, 2019 2:38 pm

hi,

no mention of a recent routing bug we have experienced. Simple static routes stop working, to restore them you disable/re-enable them. Had this happen twice on two routers with 6.44.1 on them.

One occurred after a power cycle, the other for no apparent reason at all.

Has the dev team come across this at all ?

Thanks
 
pe1chl
Forum Guru
Forum Guru
Posts: 5830
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.44.3 [stable] is released!

Fri May 31, 2019 7:18 pm

no mention of a recent routing bug we have experienced. Simple static routes stop working, to restore them you disable/re-enable them. Had this happen twice on two routers with 6.44.1 on them.
Never seen that, likely there are more circumstances particular to your installation.
You should provide a supout.rif to support in such cases.
 
o4korez
just joined
Posts: 1
Joined: Sat Jun 01, 2019 11:14 pm

Re: v6.44.3 [stable] is released!

Sat Jun 01, 2019 11:21 pm

Hi,

I know this is not critical, but wanted to know the reason for this change, since it was a good visual aid:

*) rb2011 - removed "sfp-led" from "System/LEDs" menu;

Thanks!
+, removed a very useful feature. wonder why
 
Beone
Member Candidate
Member Candidate
Posts: 243
Joined: Fri Feb 11, 2011 1:11 pm

Re: v6.44.3 [stable] is released!

Sun Jun 02, 2019 12:27 am

Hi,

we are awaiting solution/response from helpdesk team already since march 2019.

[Ticket#2019030922002071] CAP not correctly forwarding tagged vlan traffic towards wired network

Quite often, the CAPs arent forwarding DHCP offers anymore towards the clients, resulting in loss of network connectivity.
Just a reprovision resolves this for awhile until it happens again...

We see this in 6.42.x, 6.43.x and even 6.43.x

We have sent multiple debug traces to support without any feedback except with "upgrade to 6.44.3" and as we can confirm, also that release is broken.

I'm pretty sure it has todo with new bridging implementation as 6.39.3 doesn't have this issue. (however most recent delivered devices cannot be downgraded to that release anymore).

Can you please look at this case which impacts/involves more then 5000 access-points
 
anuser
Member
Member
Posts: 397
Joined: Sat Nov 29, 2014 7:27 pm

Re: v6.44.3 [stable] is released!

Wed Jun 05, 2019 9:37 pm

[Ticket#2019030922002071] CAP not correctly forwarding tagged vlan traffic towards wired network
Interesting, let´s quote myself:
I´m currently "watching" an Apple client (C8:3C:85:33:B3:10). The phone connects itself automatically to one specific cAP ac. What can I see repeatedly:

- The client connects to wifi successfully
- The DHCP server shows the MAC of the client. Within "DHCP Lease" windows I can see the status which is "offered".
- "Expires After" is couting down from 00:00:31 seconds to 0.
- Inbetween that time frame the client disconnects and reconnects.
- For some few seconds (~5), within the "DHCP Lease" window, it shows "bound"
- After that it changes from "bound" to "DHCP Lease" again.
- The whole process repeats now for over 10 minutes while writing this message.

Looking at the "DHCP Server" => "Leases" window and sort it by "offered status", I currently see the about 8 "...iPhone" with the same behaviour, i.e. they reoccur within the list saying "offered" over and over. Those iPhone don´t use the same access point as the Apple device above, but also some other cAP ac running 6.44.3 code.

Update 1:
- Within "DHCP Lease" windows activated "Make Static" => No change
- Within static DHCP lease windows: I changed step by step: "Lease Time", hit "Usr Src. MAC Address", changed "Insert Queue Before" to bottom => No change
Update 2:
- I downgraded another cAP ac to 6.43.16 which is next to the cAP ac from above and deacitvated both radios on the the cAP ac with version 6.44.3 => the Apple client connected to the cAP ac with 6.43.16, the status within "DHCP lease" is now on bound for over 20 minutes.
- I deactivated both radios one cAP ac mentioned above
Update 3:
The client changed the building. It is now on another cAP ac with 6.44.3. The client obviously works and is producing traffic.
=> I have 2 CCR1036 running with CAPSMAN forwarding mode. I have >200 cAP ac / wAP ac / ... on each CCR. I don´t know how many times I changed settings for VLAN, bridges, MTUs. I have one CCR + cAP running 6.43.16 completely, the other CCR + cAP are running 6.44.3. The "solution" I mentioned above wasn´t one. Still the same problem. I´m looking for a solution, too.
 
redbullsteve
just joined
Posts: 17
Joined: Wed Feb 02, 2011 12:37 am

Re: v6.44.3 [stable] is released!

Wed Jun 05, 2019 11:20 pm

[Ticket#2019030922002071] CAP not correctly forwarding tagged vlan traffic towards wired network
Interesting, let´s quote myself:
I´m currently "watching" an Apple client (C8:3C:85:33:B3:10). The phone connects itself automatically to one specific cAP ac. What can I see repeatedly:

- The client connects to wifi successfully
- The DHCP server shows the MAC of the client. Within "DHCP Lease" windows I can see the status which is "offered".
- "Expires After" is couting down from 00:00:31 seconds to 0.
- Inbetween that time frame the client disconnects and reconnects.
- For some few seconds (~5), within the "DHCP Lease" window, it shows "bound"
- After that it changes from "bound" to "DHCP Lease" again.
- The whole process repeats now for over 10 minutes while writing this message.

Looking at the "DHCP Server" => "Leases" window and sort it by "offered status", I currently see the about 8 "...iPhone" with the same behaviour, i.e. they reoccur within the list saying "offered" over and over. Those iPhone don´t use the same access point as the Apple device above, but also some other cAP ac running 6.44.3 code.

Update 1:
- Within "DHCP Lease" windows activated "Make Static" => No change
- Within static DHCP lease windows: I changed step by step: "Lease Time", hit "Usr Src. MAC Address", changed "Insert Queue Before" to bottom => No change
Update 2:
- I downgraded another cAP ac to 6.43.16 which is next to the cAP ac from above and deacitvated both radios on the the cAP ac with version 6.44.3 => the Apple client connected to the cAP ac with 6.43.16, the status within "DHCP lease" is now on bound for over 20 minutes.
- I deactivated both radios one cAP ac mentioned above
Update 3:
The client changed the building. It is now on another cAP ac with 6.44.3. The client obviously works and is producing traffic.
=> I have 2 CCR1036 running with CAPSMAN forwarding mode. I have >200 cAP ac / wAP ac / ... on each CCR. I don´t know how many times I changed settings for VLAN, bridges, MTUs. I have one CCR + cAP running 6.43.16 completely, the other CCR + cAP are running 6.44.3. The "solution" I mentioned above wasn´t one. Still the same problem. I´m looking for a solution, too.
Glad it is not just me, I have the same issue effecting 1000's of units, if you disable the CAP and enable everything works again for a period of time and stops again.

I have raised tickets with support to get Zero reply so a reply saying upgrade is further than I have got. I hope this gets resolved soon as its been going on for months.
 
Beone
Member Candidate
Member Candidate
Posts: 243
Joined: Fri Feb 11, 2011 1:11 pm

Re: v6.44.3 [stable] is released!

Fri Jun 07, 2019 3:01 am

[Ticket#2019030922002071] CAP not correctly forwarding tagged vlan traffic towards wired network
Glad it is not just me, I have the same issue effecting 1000's of units, if you disable the CAP and enable everything works again for a period of time and stops again.

I have raised tickets with support to get Zero reply so a reply saying upgrade is further than I have got. I hope this gets resolved soon as its been going on for months.

Zero reply from support except upgrade to XXX (having same issues), provided them full packet capture and supouts when its happening showing the DHCP offer gets up to the LAN uplink on the CAP but isnt forwarded to the wireless client.
 
anuser
Member
Member
Posts: 397
Joined: Sat Nov 29, 2014 7:27 pm

Re: v6.44.3 [stable] is released!

Fri Jun 07, 2019 9:30 pm

Glad it is not just me, I have the same issue effecting 1000's of units, if you disable the CAP and enable everything works again for a period of time and stops again.
I have raised tickets with support to get Zero reply so a reply saying upgrade is further than I have got. I hope this gets resolved soon as its been going on for months.
How many times a day do you provision your cAP devices?
 
whatever
Member Candidate
Member Candidate
Posts: 100
Joined: Thu Jun 21, 2018 9:29 pm

Re: v6.44.3 [stable] is released!

Tue Jun 11, 2019 7:20 pm

[Ticket#2019030922002071] CAP not correctly forwarding tagged vlan traffic towards wired network
Glad it is not just me, I have the same issue effecting 1000's of units, if you disable the CAP and enable everything works again for a period of time and stops again.

I have raised tickets with support to get Zero reply so a reply saying upgrade is further than I have got. I hope this gets resolved soon as its been going on for months.

Zero reply from support except upgrade to XXX (having same issues), provided them full packet capture and supouts when its happening showing the DHCP offer gets up to the LAN uplink on the CAP but isnt forwarded to the wireless client.
Did you try setting multicast helper to full? This fixed some LAN to WiFi problems I was experiencing..
 
anuser
Member
Member
Posts: 397
Joined: Sat Nov 29, 2014 7:27 pm

Re: v6.44.3 [stable] is released!

Fri Jun 14, 2019 9:35 am

Did you try setting multicast helper to full? This fixed some LAN to WiFi problems I was experiencing..
I have multicast helper activated since I needed IPv6 for CAPSMAN forwarding. This doesn´t fix the problem with "dhcp offering lease...for...without success"
 
djerodrigues
just joined
Posts: 2
Joined: Wed Jan 10, 2018 1:27 am

Re: v6.44.3 [stable] is released!

Sat Jun 15, 2019 11:35 pm

HI all!

I have some PWR-LINE AP units, and upgraded to v6.44.3.

Issues:
- There is no PWR-LINE interface in the terminal / command line !!!
Can't configure or check configuration/status (done with WinBox)

- When setting "PLC CCO Selection Mode", it will always show as "auto".

- When setting "Network Key" or "Network Password", it will always show as empty.

- Can't downgrade at Winbox with "Downgrade" button. At command line it works fine.


Tks...
 
oldcrow
just joined
Posts: 19
Joined: Sun Jul 15, 2018 11:04 am

Re: v6.44.3 [stable] is released!

Sun Jun 16, 2019 6:03 am

Hi all

upgraded to hAP ac2 to 6.44.3(stabe) and it does not remember which ethernet is attached to WAN/LAN on restarts, Defaults back to ether1 (POE in port so not available for internet modem). Addresses and routes similarly default to ether1 on reboot.

cheers
chris
 
oldcrow
just joined
Posts: 19
Joined: Sun Jul 15, 2018 11:04 am

Re: v6.44.3 [stable] is released!

Mon Jun 17, 2019 8:46 am

Hi all

mea culpa as per usual. turns out seeing 0.0.0.0/0 and changing it to fixed ip in QuickSet not a great idea. It is what changed ether1 back to being WAN port. My apologies for not picking up my error.

regards
Oldcrow
 
pe1chl
Forum Guru
Forum Guru
Posts: 5830
Joined: Mon Jun 08, 2015 12:09 pm

Re: v6.44.3 [stable] is released!

Mon Jun 17, 2019 11:51 am

Ah, the usual problem with QuickSet...
It has been requested many times to have some feature to make QuickSet readonly (either manually or even automatically after changes outside QuickSet have been made) but it is not picked up by MikroTik.
Now, QuickSet remains a ticking timebomb in routers with non-default configuration...
 
bbs2web
Member Candidate
Member Candidate
Posts: 198
Joined: Sun Apr 22, 2012 6:25 pm
Location: Johannesburg, South Africa
Contact:

Re: v6.44.3 [stable] is released!

Sat Jun 22, 2019 10:41 am

We have identified an issue with IP neighbour discovery packets, specifically Cisco Discovery Packets (CDP), being transmitted when ports are members of a bridge and spanning tree has detected the port as an alternate path towards the root bridge. Whilst STP correctly disables forwarding it still transmits CDP messages which are then bridged by the remote routers. We presume this to be due to CDP using the same destination multicast MAC address that Spanning Tree Protocol (STP) messages use, namely 01:00:0C:CC:CC:CC.

Network structure:
  • 3 sites with VPLS tunnels bridged between them, classic A B C triangle.
  • Router A has lower STP bridge priority (0x7000), so it becomes the root bridge
  • RSTP correctly sets one of the redundant VPLS bridge ports as alternate and disables learning and forwarding

Problem:
Bridge correctly drops all traffic on the alterative path port, except packets destined to the multicast address 01:00:0C:CC:CC:CC, used by STP and CDP.
I presume this to be so that the bridge can still process STP messages and unblock the port when necessary. The problem comes in that CDP neighbour discovery packets are still transmitted out the port which is in a non-forwarding state. This causes intermittent connectivity problems as remote bridges temporarily learn the path to the source MAC from the path/port which is in a non-forwarding mode.

Sample log message, showing MAC of blocked interface being received back on working port:
jun/20 23:57:16 interface,warning vpls-vlan2000-A: bridge port received packet with own address as source address (02:0f:f1:63:85:ea), probably loop

Expected behaviour:
Do not transmit CDP neighbour discovery packets out of a port when disabled by spanning tree protocol.


Configuration shows two VPLS interfaces, from ‘B’ to ‘A’ and ‘C’:
/interface vpls
  add disabled=no mac-address=02:0F:F9:48:BD:CA name=vpls-vlan2000-A remote-peer=192.168.255.1 vpls-id=1:22000
  add disabled=no mac-address=02:0F:F1:63:85:EA name=vpls-vlan2000-C remote-peer=192.168.255.3 vpls-id=3:22000


Router B’s bridge configuration, running RSTP:
/interface bridge
  add name=bridge-vlan2000
/interface bridge port
  add bridge=bridge-vlan2000 interface=vpls-vlan2000-A
  add bridge=bridge-vlan2000 interface=vpls-vlan2000-C


Spanning Tree correctly sets the ‘vpls-vlan2000-C’ interface's role as alternative-port, thereby disabling learning and forwarding:
[davidh@B] > /int bridge port print stats where bridge=bridge-vlan2000
Flags: X - disabled, I - inactive, D - dynamic, H - hw-offload
 0     interface=vpls-vlan2000-A bridge=bridge-vlan2000 priority=0x80 path-cost=10 internal-path-cost=10
       edge=auto point-to-point=auto learn=auto horizon=none auto-isolate=no restricted-role=no
       restricted-tcn=no pvid=1 frame-types=admit-all ingress-filtering=no unknown-unicast-flood=yes
       unknown-multicast-flood=yes broadcast-flood=yes tag-stacking=no bpdu-guard=no trusted=no
       multicast-router=temporary-query fast-leave=no status=in-bridge port-number=1 role=root-port
       edge-port=no edge-port-discovery=yes point-to-point-port=no external-fdb-status=no
       sending-rstp=yes learning=yes forwarding=yes root-path-cost=10 
       designated-bridge=0x7000.02:3A:EF:BC:95:B8 designated-cost=0 designated-port-number=2 

 1     interface=vpls-vlan2000-C bridge=bridge-vlan2000 priority=0x80 path-cost=10 internal-path-cost=10 
       edge=auto point-to-point=auto learn=auto horizon=none auto-isolate=no restricted-role=no 
       restricted-tcn=no pvid=1 frame-types=admit-all ingress-filtering=no unknown-unicast-flood=yes 
       unknown-multicast-flood=yes broadcast-flood=yes tag-stacking=no bpdu-guard=no trusted=no 
       multicast-router=temporary-query fast-leave=no status=in-bridge port-number=2 role=alternate-port 
       edge-port=no edge-port-discovery=yes point-to-point-port=no external-fdb-status=no 
       sending-rstp=yes learning=no forwarding=no root-path-cost=20 
       designated-bridge=0x8000.02:57:0E:3C:25:0E designated-cost=10 designated-port-number=2


6.44 made changes to transmit bond and bridge slave port information out via MNDP, CDP and LLDP, this is when the behaviour started. This also changes the previous behaviour in that these neighbour discovery packets are transmitted not just from the bridge itself, but additionally all slave ports. Herewith an example, showing the remote interface as being bridge-vlan2000/vpls-vlan2000-C:
[davidh@B] > /ip neighbor print detail 
 0 interface=vpls-vlan2000-A,bridge-vlan2000 mac-address=02:0F:F1:63:85:EA 
   identity="B" platform="MikroTik" version="6.44.3 (stable)" unpack=none age=9s
   interface-name="bridge-vlan2000/vpls-vlan2000-C" system-caps="" system-caps-enabled=""


Temporary work around:
  • Create an interface list called 'vpls' and add all VPLS interfaces to this list
  • Set IP neighbour discovery to use all interfaces except those in the 'vpls' interface list
 
User avatar
emils
MikroTik Support
MikroTik Support
Topic Author
Posts: 494
Joined: Thu Dec 11, 2014 8:53 am

Re: v6.44.3 [stable] is released!

Mon Jul 01, 2019 10:14 am

New version 6.45.1 has been released in stable RouterOS channel:

viewtopic.php?f=21&t=149786

Who is online

Users browsing this forum: No registered users and 19 guests