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

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?

..........................
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.

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

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