How many of us suffer from this?
30% of rb's have the Ethernet port flap on a regular base. All > 5.4version.
Like the disconnect issue MT says they can't reproduce, but it is definitely there....
Please report this issue to MT and this forum.

It can't be I am the only one......

Not sure if my recent issue was ether port flapping or just port lock up as i had a ptp 433ah (os5.5) which i was monitoring with the dude and i could not open with winbox tried mac-telnet and after trying to establish a connection telnet would disconnect, the 433 is connected to a 493ah (os3.30) i disabled the port which the 433 was coming into the 493 and enabled it then my 433 was accessible again,

Rudy - If MT say once again they cannot reporoduce this issue could i suggest you post a screenshot of "port flapping" and if users experiencing this issue would list which board(s) is effected, maybe MT is trying to reproduce on the wrong board or it may require a combination of interconnected boards to reproduce??

I can say again, none of our other customer experience these problems. Even on this forum you are the only one who has this problem after we fixed it in v5.4

Check your cables, switches and other devices. The problem is not in the routerboard or routeros.

I can say again, none of our other customer experience these problems. Even on this forum you are the only one who has this problem after we fixed it in v5.4

Check your cables, switches and other devices. The problem is not in the routerboard or routeros.

Well, I have about 40 units with the problem. These are not even touched for months and before 5.x they didn't have the issue.
So now you are saying suddenly all these connections are bad....

And there are others with the same issue. They only gave up reporting or nagging about it since you guys ignore the issue.
I send you a support about it with 4 different routers .rif's and the log files showing the issue and I don't even get any reply on it.

I think you should do a better job in this one....

Absolutely not true... I am still getting port flapping issues, even with ros5.4.

If you want I will send you screan shots of it. And FYI it is now happening 3,4 or even 6 times a day..


Regards

Simon

send us supout.rif files from v5.5, we don't have any open tickets regarding this. if there is a problem, let us know!

screen dump attached

Here's another one

This does not help at all. It has zero value to anyone. Send us debug logs and supout.rif files so we can fix the problem. Also, you have v5.4 not v5.5

Nomis, the RB433 connected to port 2 of the rb750 is using ROS5.5, the RB750G is using ROS5.4.

You said it was fixed in ROS5.4!

Ticket#2011061766000064 This ticket already is created 17 of June.

The 30th of June I send you guys an e-mail with suppout.rif's of 4 different routers with their log files.
We have been communicating about it. Don't tell me you can't trace it!

These were all running 5.4 a version previously claimed it has not such an issue...

1. Do any of you use Wireless in the affected routers? How about if you turn it off in one of them?
2. Do the clients see any issue at all? Could this be only a log-related issue? It's possible that there is no port flapping, just the status is misreported.

Ticket#2011061766000064 This ticket already is created 17 of June.

The 30th of June I send you guys an e-mail with suppout.rif's of 4 different routers with their log files.
We have been communicating about it. Don't tell me you can't trace it!

These were all running 5.4 a version previously claimed it has not such an issue...

I see it has been answered.

I am going to upgrade the two units of the screen dumps above to 5.6. I'll let you know how it goes!

Here you can see that an RB750 is affected

The latest pre-release of v5.6 is available at support. It has additional wireless debug info. If the ethernet flapping issue is connected to Nv2 disconnects, you should upgrade to todays pre-release and send us supout.rif files when Nv2 disconnects.

wirelesswaves, do you read my posts? please answer my questions and stop posting the images.

Rudy - can i ask is all of your MT network using only one OS (eg 5.5), i ask this because i don't appear to suffer from this port flapping and i have at present any MT board using NV2 @ 5.5 and all boards not using NV2 @ 3.30, this appears to be working for me on a routed ospf network?

1. Do any of you use Wireless in the affected routers? How about if you turn it off in one of them?
2. Do the clients see any issue at all? Could this be only a log-related issue? It's possible that there is no port flapping, just the status is misreported.

Ok, we finally got your attention...

1. Yes, all units are units with wireless.
2. Yes, I already reported in both my mails to you guys as well on several post on this forum that it indeed seems the clients doesn't notice. People claim they can have skype calls for long times and never noticed line disconnects (they would definitely notice if the connection would brake!).
Indeed I even mentioned it could be merely a misreporting issue of the latest ros versions.
On the other hand, it can also be it just doesn't happen when data traffic is running over the port. (Hence the client won't notice, since when he is using the network it might not happen.)

The only router I have, a rb439AH which is not having any wireless cards has also the issue. Not that regular, but on all its 9 ports is see at times port flaps. And all attached units are routerboards again. All wired.

Rudy - can i ask is all of your MT network using only one OS (eg 5.5), i ask this because i don't appear to suffer from this port flapping and i have at present any MT board using NV2 @ 5.5 and all boards not using NV2 @ 3.30, this appears to be working for me on a routed ospf network?

My whole network (approx. 250 units) is rb with 5.4 running. I am only slowly upgrading units with issues to 5.5 and now 5.6.
New units also get 5.5 and since 2 days 5.6.
Firmware upgrade everywhere.

Rudy - can i ask is all of your MT network using only one OS (eg 5.5), i ask this because i don't appear to suffer from this port flapping and i have at present any MT board using NV2 @ 5.5 and all boards not using NV2 @ 3.30, this appears to be working for me on a routed ospf network?

My whole network (approx. 250 units) is rb with 5.4 running. I am only slowly upgrading units with issues to 5.5 and now 5.6.
New units also get 5.5 and since 2 days 5.6.
Firmware upgrade everywhere.

Like i said using those two OS works for me, you could test on one to check if this will work for you, looks like a lot of work upgrading firmware everywhere, especially when MT say they cannot reproduce the issue,

The two SXT units upgraded are now running for 1hr and 15 mins with the new v5.6 and one unit shows already two port flaps and the other one..... see what happens the rest of the day...

Rudy, like I explained before.

In my opinion and with the tests that I have done, it is definitely NOT "just a logging issue"

Dont you remember me telling you on the phone that I had just received an email and sms text from my gateway router which was running "netwatch", that it had lost contact with the next router further up the line!!!

When I investigated the problem, I noticed in the log of one of those machines that there had been SO MANY consecrative "port flaps" in one elongated session, that it had actually caused "netwatch" to trigger! thus sending out an email and sms text from the gateway router!!

In response to Nomis, How would I know which machine it is wireless or otherwise, the RB433 (wireless AP) is connected to the RB750, when the RB750 port flaps, then so does the RB433, or it could be the other way around, ie, when 1 flaps, it causes a notification in the log of the attached machine!

Again an indication that it is a "real event" and not some false logging!

OK, one SXT unit is now 6 hours up and no more port flaps.
The other SXT is also 6 hours up after the upgrade to 5.6 and the log shows the following:

Jul/26/2011 14:57:19 ether1 link down (I saw it happening, it stayed down. So this
client probably disconnected or switched off his PC)
Jul/26/2011 19:55:33 ether1 link up (speed 100M, full duplex)
Jul/26/2011 19:55:37 ether1 link down
Jul/26/2011 19:55:38 ether1 link up (speed 100M, full duplex)
Jul/26/2011 19:55:45 dhcp1 deassigned 192.168.50.225 from xx:xx:xx:xx:xx:xx
Jul/26/2011 19:55:56 dhcp1 assigned 192.168.50.225 to xx:xx:xx:xx:xx:xx
Jul/26/2011 20:05:04 ether1 link down
Jul/26/2011 20:05:06 ether1 link up (speed 100M, full duplex)

So, the port actually flaps the moment there is an actual connection. Even before IP addresses are exchanged.....

I'll monitor these units futher. It is now getting dark and usually port flaps don't happen during night time hours. (Yes, I know, how strange...)

Hmm I encounter the same problem, but between old RB333 with 3.30 and new one RB 433 with 5.5. Port flaps, tommorow I'll try replace RB 333 with new one 433. I hope it solve the problem.

While I am in the boat with everyone else with the wireless disconnects, I have yet to find any port flapping issues on my network (~800 CPE) that appeared as a result of RouterOS upgrades.

The network is a mix of RB112, RB133, RB532, RB333, RB600, RB411, RB433. I am also running a mix of v4.1x, v5.2, and v5.5 (I skipped v5.3/v5.4), approx 3/5 of the network is running v5.x

In the screenshots posted it shows the ethernet port connecting and disconnecting, I have had this issue BUT it was a result of ESD to the ethernet port. Whenever this issue occured I would turn Auto-Negotiation off, enable 10 Mbps and typically the port would make a connection, sometimes I could get it to make a connection at 100 Mbps by forcing 100 Mbps. However its only for testing once a connection is established I do a simple 1000 ping at 20 ms timeout test on the ethernet port. A working port should have 0 lost packets, typically ESD damaged ports will see 5-10% loss.

Cheers

ESD has been a bit of my suspicion.
Argument pro:
- port flaps happens mainly during daytime. Usually it is windy and dry here during that.
After sunset wind almost always dies and it becomes more humid.

Argument contra:
- The wheater pattern and the physical installation of CPE's are in some cases already 5 years old. But the whole port flap issue only submerged this spring. Never had it before.

Imho it could be that the new ros has more sensitive reporting routine so issues that never where shown (they could still be there) are now suddenly surfacing...

If ESD is the culprit, I'll guess I have to live with it. Most CPE's are impossible to connect to ground and replacing cable for shielded ones is not an option since we still need a proper ground at the power-shot location. Even the houses in general are very poorly grounded so not so much to do about? But any suggestions are welcome!

If ESD is the culprit, I'll guess I have to live with it.

Have you considered roll back to previous version at least on some affected units? I mean version before disconnect problem appeared.

If ESD is the culprit, I'll guess I have to live with it.

Have you considered roll back to previous version at least on some affected units? I mean version before disconnect problem appeared.

so EDS knows which version you are running? be reasonable.

You're probably right. I've tried with auto negotation off (10Mbps rate, half/full) - doesn;t help Tried diffrent ports - no effect. There's more. Eth ports in "suspected" RB333 worked so far normal, but the were connected to some PC. I wanted connect two RB and effect is miserable...

If ESD is the culprit, I'll guess I have to live with it.

Have you considered roll back to previous version at least on some affected units? I mean version before disconnect problem appeared.

so EDS knows which version you are running? be reasonable.

normis, wake up. I wrote this:

Imho it could be that the new ros has more sensitive reporting routine so issues that never where shown (they could still be there) are now suddenly surfacing...

This is version dependent, if true.

normis, wake up. I wrote this:

my answer was to petrn who suggested downgrading, in a direct reply to your ESD assumption

normis, wake up. I wrote this:

my answer was to petrn who suggested downgrading, in a direct reply to your ESD assumption

In that case your remark is still not right.

If I would roll back to a version where the issue is not around it could well mean that it is because that previous version is not as sensible to notice the ESD disconnect? Most disconnects happen within the same second. Maybe due an ESD discharge the status reporting of the port becomes erroneous for a split second and now the new version picks that up to report the port being down? Previous versions weren't sensitive enough to notice such short lived disconnects and thus never mentioned them in the logs.
This would also explain why clients themselves hardly notice anything. It lasts too short to break a data connection.

One of you guys already stated yourself that indeed the reporting of the latest ROS could be the issue, and not so much the actual event.
In other words, ESD CAN cause the disconnects but previous versions didn't notice this, where the new ROS does. So yes, an ESD triggered event CAN have an relation with the ROS version.

To come back on the ESD possibility itself:
I find it very strange that 90% of the port flaps on my network seem to disappear after darkness. They start again next morning when the sun really start to climb on the horizon. I am sure the port status reporting is not aware of time So how do we explain this?
The only possible reason imho can be ESD and the reporting of it.
The weather here is almost everyday the same: sunrise, getting warmer, getting hot and wind picks up somewhere in the morning due sea/land effect, wind grows stronger during afternoon and half an hour after the sun went down in the evening wind dies and temperature starts to drop which would increase air humidity which then reduces ES build ups. 95% of the time in summer overnight there is no wind and relative cool with high humidity so that would than explain that I hardly see the issue then?
This micro climate has been the same for years, can it be the new ROS version are just better in picking up little disturbances on the ethernet port status, or just more accurate in reporting little disturbances?

previous versions didn't log ethernet activities at all. the events probably happened just the same, and RouterOS noticed it just the same, but there was no log entry.

this was only added in v5.1 or v5.2. maybe you had this problem forever, you will never find out by downgrading, as in older versions there is simply no ethernet logging.

previous versions didn't log ethernet activities at all. the events probably happened just the same, and RouterOS noticed it just the same, but there was no log entry.

this was only added in v5.1 or v5.2. maybe you had this problem forever, you will never find out by downgrading, as in older versions there is simply no ethernet logging.

Don't you think Skype users will notice disconnections, as they probably do now?

probably

according to the bug reporters above, they don't

previous versions didn't log ethernet activities at all. the events probably happened just the same, and RouterOS noticed it just the same, but there was no log entry.

this was only added in v5.1 or v5.2. maybe you had this problem forever, you will never find out by downgrading, as in older versions there is simply no ethernet logging.

From reading this thread it appears to me that new logging of Ethernet activity has as normis says has only now make us aware of this now,
As MT is not been able to reproduce issues like NV2 disconnects which unfortunately customers do complain about could MT make available on request a very detailed logging script with as many as practical wireless logging items (etc.) and perhaps users will flag something from this, unless MT have pin-pointed where the issue is on these NV2 disconnects and are confident of a fix?

we already have done this, the v5.6 pre-release includes much more detailed wireless debug log, so we can find problems more quickly. but don't compare the Nv2 problem (which we have identified) with this ethernet problem (only 2-3 people have found this).

we already have done this, the v5.6 pre-release includes much more detailed wireless debug log, so we can find problems more quickly. but don't compare the Nv2 problem (which we have identified) with this ethernet problem (only 2-3 people have found this).

No normis i was not comparing the problems but i was highlighting was use more detailed logging and it good to read v5.6 has this.

we already have done this, the v5.6 pre-release includes much more detailed wireless debug log, so we can find problems more quickly. but don't compare the Nv2 problem (which we have identified) with this ethernet problem (only 2-3 people have found this).

Normis, on the disconnect topic, can you please shine some light what you guys did identify? We, as ´nagging´ Charlie testers would be interested what was found and how it was solved?

did you send your new files for the latest v5.6 build I gave you?

I've got an RB1100 and sporadically get drops on one of the ports... The port is running DHCP and PPPoE Servers... Funny thing is it never happend before, until the 5.5 update...

ether8 link down
ether8 link up (speed 1000M, full duplex)

Gonna revert back to 5.4 this evening unless there's a newer version with the fix... Any input would be appreciated.

Tim

I've got an RB1100 and sporadically get drops on one of the ports... The port is running DHCP and PPPoE Servers... Funny thing is it never happend before, until the 5.5 update...

ether8 link down
ether8 link up (speed 1000M, full duplex)

Gonna revert back to 5.4 this evening unless there's a newer version with the fix... Any input would be appreciated.

Tim

Can i ask when you say "get drops on one of the ports... " is this traffic drops or the log saying interface info has changed?

did you send your new files for the latest v5.6 build I gave you?

Which files do you mean? II don't understand the question...

did you send your new files for the latest v5.6 build I gave you?

Which files do you mean? II don't understand the question...

I think normis was asking did you sent to support the new wireless debug logs generated from v5.6.

Can i ask when you say "get drops on one of the ports... " is this traffic drops or the log saying interface info has changed?

Yes, "interface info" in the log shows the interface going down and then up again.

Can i ask when you say "get drops on one of the ports... " is this traffic drops or the log saying interface info has changed?

Yes, "interface info" in the log shows the interface going down and then up again.

Then what you encountering is a logging notification issue of the ethernet port, other posters have said connected client's are not effected when the issue occurs, can you conduct a bandwidth test across the effected unit and check if there is a drop in throughput when this happens

did you send your new files for the latest v5.6 build I gave you?

Which files do you mean? II don't understand the question...

I think normis was asking did you sent to support the new wireless debug logs generated from v5.6.

Ok, but off topic here. Anyway, my answer would be "No" since after installing v5.6 on troubled networks and units I have no regular disconnection units more. I have disconnects but they are related to works on 2 of my towers, power cuts etc. so it is a bit hard to identify if I still have units disconnection as result of the NV2 interference option. Since I also changed some other network's frequencies and now plus the new ROS my problems with disconnects seems to have disappeared greatly. So for the moment I have nothing to send them.

I started this new Eth. port flapping topic because the disconnect issue seems to be solved now greatly. I just moved on to the next issue..

Then what you encountering is a logging notification issue of the ethernet port, other posters have said connected client's are not effected when the issue occurs, can you conduct a bandwidth test across the effected unit and check if there is a drop in throughput when this happens

Thanks but all our PPPoE clients get disconnected, so I'm pretty sure it's the port going down and then up again. Connected clients using DHCP would probably not notice a port going up and down whereas a PPPoE connection would take a few moments longer while the PPPoE server restarts on the interface.

Some of the units that had the disconnection issue also had the port flap issue.
After the upgrade to v5.6 the disconnections are mostly gone, but the port flap issue is still there.
I have to monitor this for some days to come, I'm out of the country anyway for some days so don't have too much time to do this.
During this the network is not ´touched´ so and disconnects that would still occur the next days are therefore more easy to identify if it is NV2 related or not.
At the same time I can see what can be done with the port flap issue. I will set some problem units to manual auto speed setting on the Ethernet port and see if that helps.

I had the port flapping issue on a 433ah ROS 5.3
the customer was complaining of webex and ftp dropping.
I upgraded to ROS 5.5 and the flapping stopped.

just my 2cents
~Ken

Back at base and checked the units with the Ethernet port flapping issue.
These units were upgraded to 5.6 last week but to no result on this issue. Still tenths to over hundred port flaps per day...
On one unit I disabled the auto rate negotiation to fixed 100M, also to no result. Same amounts of Ethernet port failures per day.....
I´m going to set that unit to 10M now, see what it is doing over the next days.....

As previously mentioned I don't appear to have a Ethernet port flapping issue but what I did encounter on a ptp link using 5.5/5.4 was on the Ethernet side of PtP was partial loss of connectivity where I could not login with winbox but sometimes Mac-telnet in and now I have unchecked “default authenticate” on wireless which after two days has stopped this issue so far, all of this has me asking questions how robust is MT routerboards and can they be effected by connected devices and I have updated an old post about a laptop which will not allow any connected board to reboot, http://forum.mikrotik.com/viewtopic.php?f=2&t=48122

As previously mentioned I don't appear to have a Ethernet port flapping issue but what I did encounter on a ptp link using 5.5/5.4 was on the Ethernet side of PtP was partial loss of connectivity where I could not login with winbox but sometimes Mac-telnet in and now I have unchecked “default authenticate” on wireless which after two days has stopped this issue so far, all of this has me asking questions how robust is MT routerboards and can they be effected by connected devices and I have updated an old post about a laptop which will not allow any connected board to reboot, http://forum.mikrotik.com/viewtopic.php?f=2&t=48122

why do you post on this topic then?

Well, that unit mentioned at the beginning of this topic was set last night to 10Mb duplex fixed.
Nothing happened overnight (Clients PC is obviously switched off) but from 9 AM this morning the port started to flap again.....
Conclusion: The port flapping has nothing to do with the auto rate negotiation of the Ethernet port. What a pity!

I am going to look at another unit with the issue (I have now some 40 units out of 250 identified that shows the port flapping in their logs. But only 3 or 4 do it more then 10 times a day. 2 of these some 30-50 times a day. Almost all only during daytime hours.)
This other unit now connects to a 3rd party wifi router. I am going to put a rb150 in-between and play with all the Ethernet settings to see if I can stop the port flapping. For the interested: stay tuned!

As previously mentioned I don't appear to have a Ethernet port flapping issue but what I did encounter on a ptp link using 5.5/5.4 was on the Ethernet side of PtP was partial loss of connectivity where I could not login with winbox but sometimes Mac-telnet in and now I have unchecked “default authenticate” on wireless which after two days has stopped this issue so far, all of this has me asking questions how robust is MT routerboards and can they be effected by connected devices and I have updated an old post about a laptop which will not allow any connected board to reboot, http://forum.mikrotik.com/viewtopic.php?f=2&t=48122

why do you post on this topic then?

Normis I am quite sure if you talk to a senior engineer who has learned hard from experience about fault finding, they will inform you always to keep an open mind about technical issues which you cannot reproduce on the test bench and don’t rule out anything until you have investigated fully any issues and dismiss only when you are totally sure there is no relationship between issues?

As previously mentioned I don't appear to have a Ethernet port flapping issue but what I did encounter on a ptp link using 5.5/5.4 was on the Ethernet side of PtP was partial loss of connectivity where I could not login with winbox but sometimes Mac-telnet in and now I have unchecked “default authenticate” on wireless which after two days has stopped this issue so far, all of this has me asking questions how robust is MT routerboards and can they be effected by connected devices and I have updated an old post about a laptop which will not allow any connected board to reboot, http://forum.mikrotik.com/viewtopic.php?f=2&t=48122

why do you post on this topic then?

Normis I am quite sure if you talk to a senior engineer who has learned hard from experience about fault finding, they will inform you always to keep an open mind about technical issues which you cannot reproduce on the test bench and don’t rule out anything until you have investigated fully any issues and dismiss only when you are totally sure there is no relationship between issues?

Following this logic, you could post this problem in all other topics. Make a separate topic about your problem, and let us decide if this problem is similar to some other problem. This topic is about excess logging about ethernet status. you have wireless problems. Completely different things.

..........................
Following this logic, you could post this problem in all other topics. Make a separate topic about your problem, and let us decide if this problem is similar to some other problem. This topic is about excess logging about ethernet status. you have wireless problems. Completely different things.

Normis Can i ask how do assume when i said the issue i had with ethernet side of the ptp link where i could not login to the board using 5.4/5.5 was "wireless problem" all indications to me it was ethernet connectivity issue and not wireless?,

Yes you maybe correct it may not have had any thing in common with port flapping issue apart from using the same software version and in the distant future when we look back at issues like port flapping and may have discovered it was only caused by just "X" but until then <?>,


Remember MT keeps telling us they cannot reproduce some of the issues and as such MT are at a disadvantage as they do not know first hand if the "hotfix" will work but release for select users to test,


Would it not be a more serious problem for MT if no feedback what so ever was posted on the forum but just endless emails direct to support demanding a fix for every issue, as in life technical issues are not a simple black or white but a lot of grey area sometimes, if it was simple - issues would be quickly addressed - right?

not all ethernet problems should be posted here. you are hijacking other people's thread. make your own thread for your own problem.

not all ethernet problems should be posted here. you are hijacking other people's thread. make your own thread for your own problem.

Sorry Rudy for hijacking the thread but as you have also experienced Normis brings out the best in us?

I too am having port flapping on my RB750G since upgrading from 5.0beta to 5.5. I am using 4 ports. Three of the ports are dropping then resuming. It is not false logging as I went to the log to work out why I was getting VOIP silence periods of around 10 - 20 seconds.

Looking at the log it appears that three ports drop (2 WAN ports and the production LAN port which would be 99% of traffic) at exactly the same time then come back up again. I am sure this is not an Ethernet issue. I.E. Nothing to do with negotiation, etc.

I think something else is happening and the port flapping is the symptom, not the cause. Problem is if I turn on debug logging, my IPSEC logging makes it too hard to monitor other things.

I have tried various log topics, but so far nothing that shows any errors.

On my system, they go down at around every 14 minutes, then come straight back up. It takes about 10 - 20 seconds for things to normalise and traffic to flow again.

Graphing shows not memory, CPU, or other resource issues.

Happy to send whatever for analysis.

Mark

make a supout.rif file with v5.6 at the time the problem occurs.

v5beta5 didn't have ethernet stats logging, so maybe you had this issue all along, just didn't see it in the logs.

I think I have almost homed in on this problem for my situation.

I swapped out my RB750G for my RB450G today. No problems initially, but then I set about making the changes I had made on the RB750G just before it started to play up (coincidentally the same day I upgraded the firmware).

My config is 2 x WAN connections. One is ADSL2+, the other is a new 5Mb/S symmetrical Ethernet. Currently I route all VOIP and video conferencing traffic over the new quality connection and everything else over ADSL. This includes mail, web, IPSEC tunnels (3 remote endpoints and 5 policies on one of those), etc.

I use policy routing to get the traffic from my VOIP and VC devices to use the second gateway. Ergo I have a second routing table with a single default route via my Ethernet service.

I have one queue tree on the ADSL.

I configured a new queue tree on the BDSL ready to move services across. At this point I am confident the router was still stable.

Now we get to the funny part.

I wanted to move one of my IPSEC tunnels across to the new connection.

So I created a static route to my remote site via the Ethernet connection. I then modified the IPSEC policies to use the IP address of the Ethernet as the source and of course I changed the far end as well. So far so good. I could see my traffic flowing through the correct queues in my queue tree, etc, but then after about 15 minutes all the interfaces went down and came back up. They did this every 15 minutes or so from that point on.

I then deleted the queue tree to see how it would go and the problem persisted. All that was left now was the IPSEC and static route. I am convinced it is something to do with the IPSEC. At this point I had to leave the office so I just restored to the backup I did before I started making changes. I then checked the logs 6 hours later and not a single flap.

So, I reckon this could be repeatable and maybe the reason some are having this issue and not others could be because the flapping is a symptom of some other problem.

In ROS 5.6 on RB433AH/RB433 i have ethernet is hang up. help when I disabled and enabled ethernet.

Same problem here, traffic stops for few seconds. Log show same as reported.
SOmetimes traffic stops completely and i need disable enable eth.
Affected units are mipsbe sw versions 5.4 and up on my side.

Jan

Same problem here, traffic stops for few seconds. Log show same as reported.
SOmetimes traffic stops completely and i need disable enable eth.
Affected units are mipsbe sw versions 5.4 and up on my side.

Jan

What does the log say, also are you using OSPF?

Ether link down
ether link up

No i dont use ospf , just static routes. Seems i see the issue only on 493 and 493AH boards..


Jan

How many of us suffer from this?
30% of rb's have the Ethernet port flap on a regular base. All > 5.4version.
Like the disconnect issue MT says they can't reproduce, but it is definitely there....
Please report this issue to MT and this forum.

It can't be I am the only one......

The problem is that it takes few hours, maybe days to reproduce it.
But i have it present on 5 RB493AH's and one 493.

Seems it is caused by various things. It is not really a flapping port as such. Flapping ports don't usually just disable then re-enable with a corresponding log entry. Flapping ports are usually the result of a problem with the Ethernet connection to the remote device.

I know I can make the problem we all seem to have here happen very frequently. My situation is that I have two wan ports. One is default, the other controlled by policy routes. If I create IPSEC tunnels on my default interface, then add an IPSEC tunnel to my second interface, ALL interfaces will drop (internal and external) and resume every few minutes. The event is logged.

I have tested on RB750G, RB750GL and RB450 and all the same outcomes.

I have been having some of the same issues and for what it's worth, this is what I have experienced.

I just replaced two failing RB433AH boards that were a year old due to swollen leaking caps. The new boards were shipped with 5.4 my old boards were running 4.5. These boards are setup as a WDS bridge and are linked together with a 6" jumper between port 3 on each board. When they were first turned on, everything was fine, but about a day later, eth3 starts disconnecting and reconnecting. This was verified by the fact that the link to the remote site that the second board is feeding would loose connectivity and I could watch the port register and unregister every few seconds. Somtimes it would disconnect for several hours. A reboot would not bring them back up. Also this would happen during daylight hours and would go away during the night. I upgraded to 5.6 and did not see any difference. I downgraded both boards to 4.17 and for the last 24 hours have had no disconnects at all even during the day. I will let you know if I see anymore in the next few days.

Thanks,

Frank

good post fbbeale, thanks. Hope MT takes all this info within their search for the issue.
But ros versions lower than 5.x don't have the interface status reporting option build into the logs if I remember well.
Meaning that even if you would have the same issue, in 4.x is just ain't reporting. But in your case you would be able to see the traffic die every time it happens.

Yesterday a customer of me came in his house after some months (so his antenna has been updated and the logging message regarding interface enabled) and he switched his own stuff on (wifi router)
In about 24 hours I got over 3700 (!) port flap messages from him...

He has a 133C bases RIC antenna.
I have not spoken to him yet about his experience but it must almost for sure he suffered from it.
When looking in the Ethernet interface I see nothing else than that the port is connecting and disabling in an endless sequence.
So I tried some settings:
Switched off ´auto negotiation´ but left speed at 100Mb. No change. flap-flap-flap-flap etc.
Switched 100Mb to 10Mb, port got enabled and stayed like that. No flap.
Switched ´auto negotiation´ back on and port started to flap again continuously.
So, set the port back to ´manual´ and for hours it is still up and seen no more flap.

Played with duplex/simplex but that doesn't seem to make any difference in both configs.

I am not able to make a supout.rif. When I do this router-board crashes. I tried 4 times.
Tomorrow I am replacing this unit for a rb711 based CPE and see what he has hanging on his antenna.
Than, at my desk I can also do some more tests with this unit.

Keep you posted but this should also give some more finger pointing?

good post fbbeale, thanks. Hope MT takes all this info within their search for the issue.
But ros versions lower than 5.x don't have the interface status reporting option build into the logs if I remember well.
Meaning that even if you would have the same issue, in 4.x is just ain't reporting. But in your case you would be able to see the traffic die every time it happens.

Well looks like the OS verison for me was not the problem after all. Port flapping was back today after the sun came up and it started getting warm outside. As the day got warmer, the interface finally would not connect at all. I sent my climber up the tower with a another new board and a can of component cooling spray. I watched the interface while connected to the POE below which was not having any problems. As soon as he gave a short burst of spray to the ethernet controller chip, ether3 reconnected and ran until it warmed up again. We repeated the test again, same results so we replaced the board and no more problems so far. So for me, I am 100% sure my problem is hardware. If it happens with the new board, again, then I think there must be a bunch of bad controller chips out there somewhere. Outside air temp today was about 80 degrees fahrenheit.

Frank

Hi there

I am experiencing ether port flapping on all ethernet ports on a routerboard 435G OS ver 6.1, firmware version 3.07

I have tried upgrading to 6.4, firmware version is still the same 3.07.

Any advice?

firmware downgrade maybe? any ideas where I can locate version 3.02 or earlier?

Firmware downgrade did not fix the problem. Routeros downgrade did not fix the problem.

Yesterday a customer of me came in his house after some months (so his antenna has been updated and the logging message regarding interface enabled) and he switched his own stuff on (wifi router)
In about 24 hours I got over 3700 (!) port flap messages from him...

He has a 133C bases RIC antenna.
I have not spoken to him yet about his experience but it must almost for sure he suffered from it.
When looking in the Ethernet interface I see nothing else than that the port is connecting and disabling in an endless sequence.
So I tried some settings:
Switched off ´auto negotiation´ but left speed at 100Mb. No change. flap-flap-flap-flap etc.
Switched 100Mb to 10Mb, port got enabled and stayed like that. No flap.
Switched ´auto negotiation´ back on and port started to flap again continuously.
So, set the port back to ´manual´ and for hours it is still up and seen no more flap.

Played with duplex/simplex but that doesn't seem to make any difference in both configs.

I am not able to make a supout.rif. When I do this router-board crashes. I tried 4 times.
Tomorrow I am replacing this unit for a rb711 based CPE and see what he has hanging on his antenna.
Than, at my desk I can also do some more tests with this unit.

Keep you posted but this should also give some more finger pointing?

I have had not a single RB133 showing this without an external problem. Last release we
put on this board was 5.6. Newer releases does not work for us due to memory/cpu.
So your crashing with supout.rif might be a problem of this weak boards.

I guess there is a problem with the cabling. We had this effects with water going into the
screwing. Horizontal Screwings are a design flaw in my eyes. They have to be sealed with
tape.

I would try to get rid of the rb133 boards. SXT Lite's are cheap/dualpol and way faster.

..........................................................
would try to get rid of the rb133 boards. SXT Lite's are cheap/dualpol and way faster.

Had to stop using SXT's in our climate too much water ingress.

..........................................................
would try to get rid of the rb133 boards. SXT Lite's are cheap/dualpol and way faster.

Had to stop using SXT's in our climate too much water ingress.

I see. You're from Ireland. I guess water comes from all directions ).
We've no problems with SXT so far.

..........................................................
would try to get rid of the rb133 boards. SXT Lite's are cheap/dualpol and way faster.

Had to stop using SXT's in our climate too much water ingress.

I see. You're from Ireland. I guess water comes from all directions ).
We've no problems with SXT so far.

Venturi effect?

Hi. It's an old topic... but I have port flapping issue on my RB750GL board.

02:10:45 interface,info Tunnel6-PMH link down
02:10:47 interface,info ether5-master link up (speed 100M, full duplex)
02:10:47 interface,info Tunnel6-PMH link up
12:33:04 interface,info ether5-master link down
12:33:04 interface,info Tunnel6-PMH link down
12:33:06 interface,info ether5-master link up (speed 100M, full duplex)
12:33:06 interface,info Tunnel6-PMH link up
15:28:57 interface,info ether5-master link down
15:28:58 interface,info Tunnel6-PMH link down
15:28:58 interface,info ether5-master link up (speed 100M, full duplex)
15:28:58 interface,info Tunnel6-PMH link up
15:47:28 interface,info ether5-master link down
15:47:28 interface,info Tunnel6-PMH link down
15:47:30 interface,info ether5-master link up (speed 100M, full duplex)
15:47:30 interface,info Tunnel6-PMH link up
17:03:10 interface,info ether5-master link down
17:03:11 interface,info Tunnel6-PMH link down
17:03:12 interface,info ether5-master link up (speed 100M, full duplex)
17:03:12 interface,info Tunnel6-PMH link up

etc...
Board is in temperature and humidity controlled room, running ROS 6.27-mipsbe. (Tunnel is an EOIP tunnel to other MT board.)

What to do, what to check ?

Best regards: Xen