New Ethernet port flap issue enquiery, PLS JOIN!

WirelessRudy · Sun Aug 07, 2011 3:49 am

My 200+ routerboards v5.6 running network has still several units that show the Ethernet port flap on more or less regular basis.
It seems MT cannot really get a grip on this issue. They can't reproduce it.

I have some ideas in where the issue might be found; ESD, or poor below standard cable connections.

The issue in my case is randomly spread over my network, but always between routerboards and 3rd party devices (laptops, PC's, Wifi routers, switches) and the log shows clearly the port flaps mainly occur during daytime.
I live in a dry climate with moderate high summer temps and a very strong day/night effect when it comes to the prevailing winds in the summer.
It looks like most of the flaps start when the winds starts to blow some hours after the sun started to climb the sky. Most flaps die soon after the winds died as well.....

99% of my CPE antenna's are not earthed since that is almost impossible to do and in the pre 5.x era never had issue with that neither.
I use in general standard non-shielded utp cable with non-shielded plugs on both ends.
I use a whole range of powershots.

Basically I should investigate and make an inventory of the network on which units have the issue and which not and combine/compare that with their physical connections to clients device, and what device they have.
This is going to be a time consuming task, the only resource I am always short of! So I am asking my fellow users with the same issue to report whatever they can on this topic with as much info as possible to help find the issue.

MT will definitely read this topic and get their findings from it, as well as we could.

So, PLEASE report your Ethernet port flap! But make it as complete as possible. Users that might have a laptop or PC directly connected to a rb will also give a Ethernet port flap if that PC/Laptop goes in hibernation. This might happen regularly and in a quick overview in the log it might show like you have a port flap issue while in fact you have not....

Some reported that they had a unit with this issue which in fact also was reported by the ´other end´ of the cable's unit. But we need to be sure what the reason is for this. There can be several reasons that make Ethernet links drop.
I have some 30% of my units with Ethernet port flaps happening within the same or max. 2-3 secs that I cannot place as being the result of client behaviour or other actions or failures. Since clients are not complaining, nor did they say to notice anything when asked I have the believe the ´port-flaps´ are merely report errors of the OS.

My ´feeling´ is that small ESD discharges might trigger the ros reporting system to produce a port disable, while in reality I the link is really broken...
If this would be the case then there are 2 solutions:
1. MT fixed the sensitivity of the ros reporting Ethernet issues.
2. I just disable the reporting of Ethernet status message in my logs. (And miss any real problems.)

Please help on this issue. I'll bet the ones having this issue get as much irritated by the filling of the logs as I am!

Ivoshiee · Sun Aug 07, 2011 9:48 am

I have that port flapping issue on my RB750G. I used ether1 for outside connection (Cisco cable modem) and there that port flapping really does drop connection and is not just a pure cosmetics. In some occasions I had over 1 hour of no Internet access. That may be some other issue as well, but even during that time there were numerous port flapping incidents.
Couple days ago I moved the cable modem to ether3 and I haven't seen any port flapping on that port. Client PC/laptop is now in ether1 and I still see port flapping there.
Note: In case of the cable modem in ether1 the line speed did come up as 1000M all the time, but now ether1 is reporting occasionally 10M and then 1000M.

All my boxes are running ROS v5.5.

Edit: Cables are standard 1,8m variants, there should be no issues with these.

WirelessRudy · Sun Aug 07, 2011 1:28 pm

I have that port flapping issue on my RB750G. I used ether1 for outside connection (Cisco cable modem) and there that port flapping really does drop connection and is not just a pure cosmetics. In some occasions I had over 1 hour of no Internet access. That may be some other issue as well, but even during that time there were numerous port flapping incidents.
Couple days ago I moved the cable modem to ether3 and I haven't seen any port flapping on that port. Client PC/laptop is now in ether1 and I still see port flapping there.
Note: In case of the cable modem in ether1 the line speed did come up as 1000M all the time, but now ether1 is reporting occasionally 10M and then 1000M.

All my boxes are running ROS v5.5.

Edit: Cables are standard 1,8m variants, there should be no issues with these.

Thanks Ivoshiee. This is the kind of report we are looking for.
By reading your post I realize that there were problems in the past with the Ethernet1/PoE port. Our port flap issue is also usually the Ether1/PoE port and we have seen other problems with these in the past. After release of v.4.x there was the issue that this port suddenly ´died´ for receive traffic, or died completely on running units for no reason. After a reboot it usually came back. (But I also had some 411's where the port died after the first initial upload of a working system by means of a script. Some of these PoE ports became unrepairable by way of software upgrade/re-installs.) This was all about a year ago.

In my central unit (with a bunch of rb's interconnected to each other, including 2 rb1000's) the issue came up every so many days and was repaired by interconnecting all routerboards and housings to daisy chain earth connection. Problems disappeared since. The problem here was obviously either ESD or current ´leakage´ over the boards and the Ethernet connector.

Anyway, you also report that the port flap really means a disconnect of the physical line.
On the other hand, your disconnect last a very long time. Where all my port flaps usually happen within the same second or the port comes back within 2-3 secs at worst.
(All according my log. Imho it makes me even more think it is merely a reporting issue than a ´real´ issue. See my first porst.)

Davis · Sun Aug 07, 2011 5:27 pm

Thanks Ivoshiee. This is the kind of report we are looking for.
By reading your post I realize that there were problems in the past with the Ethernet1/PoE port. Our port flap issue is also usually the Ether1/PoE port and we have seen other problems with these in the past. After release of v.4.x there was the issue that this port suddenly ´died´ for receive traffic, or died completely on running units for no reason. After a reboot it usually came back. (But I also had some 411's where the port died after the first initial upload of a working system by means of a script. Some of these PoE ports became unrepairable by way of software upgrade/re-installs.) This was all about a year ago.

In my central unit (with a bunch of rb's interconnected to each other, including 2 rb1000's) the issue came up every so many days and was repaired by interconnecting all routerboards and housings to daisy chain earth connection. Problems disappeared since. The problem here was obviously either ESD or current ´leakage´ over the boards and the Ethernet connector.

Anyway, you also report that the port flap really means a disconnect of the physical line.
On the other hand, your disconnect last a very long time. Where all my port flaps usually happen within the same second or the port comes back within 2-3 secs at worst.
(All according my log. Imho it makes me even more think it is merely a reporting issue than a ´real´ issue. See my first porst.)

May be you can setup some monitoring software (e.g. The Dude) to monitor these flapping links by ping each second or even more often to see whether link flapping is only a reporting issue or a real flapping.

Ivoshiee · Mon Aug 08, 2011 11:22 am

May be you can setup some monitoring software (e.g. The Dude) to monitor these flapping links by ping each second or even more often to see whether link flapping is only a reporting issue or a real flapping.

I have had Netwatch scripts set to monitor cable modem and network gateway. As soon as the ether1 was reported as down then came the message as modem host being down as well. So, that is a real problem for me and not just reporting issue.

Ivoshiee · Mon Aug 08, 2011 11:27 am

Anyway, you also report that the port flap really means a disconnect of the physical line.
On the other hand, your disconnect last a very long time. Where all my port flaps usually happen within the same second or the port comes back within 2-3 secs at worst.
(All according my log. Imho it makes me even more think it is merely a reporting issue than a ´real´ issue. See my first porst.)

That long loss of connection is just a few such ones I experienced. Usually these connectionless gaps are between 10...15 seconds. I haven't checked if these all are reporting as interface being down, but I strongly suspect that.
Edit:
Snippet from the log:

11:43:45 interface,info ether1 link down
11:43:55 interface,info ether1 link up (speed 1000M, full duplex)
11:46:19 interface,info ether1 link down
11:46:21 interface,info ether1 link up (speed 10M, full duplex)
11:46:27 interface,info ether1 link down
11:46:31 interface,info ether1 link up (speed 1000M, full duplex)
11:47:23 interface,info ether1 link down
11:47:24 interface,info ether1 link up (speed 10M, full duplex)
11:47:25 interface,info ether1 link down
11:47:28 interface,info ether1 link up (speed 1000M, full duplex)
11:47:49 interface,info ether1 link down
11:47:52 interface,info ether1 link up (speed 1000M, full duplex)
19:14:46 interface,info ether1 link down
19:14:47 interface,info ether1 link up (speed 10M, full duplex)

WirelessRudy · Mon Aug 08, 2011 1:19 pm

I called my worse effected client this morning, he has 30 to 40 Ethernet port flaps a day (during daytime, when his PC is 'on').
I asked him if he sensed any problems with disconnects but he can't really remember some...
He uses Skype regularly but never had conversations broken in the middle.

I took a close look in the log and see the ether1 link going up and down but than every time actually the connected speed changes from 10M to 100M and vice versa.
My CPE (generating these ether1 link messages) is directly by cable connected to his PC.
His PC goes into standby and later in hibernation which than would switch the Ethernet interface of the PC off...
I can't ping his PC though to see if the link really drops. Probably it is being blocked by windows firewall? (Anybody has a say about this. Is this ' default' behaviour of Windows Firewall?)

The strange thing is though that almost all his port flap log shows the link as down and again up within max. 2 secs. When it than is up it sometimes stays up several minutes up to half an hour to go down again and back up in the same 2 secs but with another speed.

Ivoshiee · Tue Aug 09, 2011 5:25 pm

I am supposed to have permanent IP from my ISP, but I can not set it static and router must ask it over DHCP. My reported long Internet loss is likely due to usage of DHCP on that interface. The port flipping happened on bad time thus the cable modem lost its MAC-IP-address registration, but Mikrotik didn't release that IP-address and Internet resumed working only after DHCP renew when DHCP client lease ran to 0 (lease expiration time is set to 2 hours).

ohara · Tue Aug 09, 2011 10:58 pm

Rudy,
based on your experience, does port flapping also occur while using passive PoE splitters to power the RB in an outdoor enclosure?

I have deployed two 5.6 RB433 recently. One on a rooftop with a 50 meters FTP cable sent down the building without fixing it to the elevation. We were planning to fix the cable the next day, but the router had been turned on anyway. The installation has undergone a stress test during the night while a severe storm passed over the area. The port was flapping for 15 minutes. Once the storm has gone the port flapping stopped. I am wondering if this was caused by the cable being smashed against the wall by the wind.

Another RB was installed on a balcony where the cable was put under a synthetic carpet. I was noticing port flaps during daytime and I came to the conclusion that the customer might have been causing the port flaps by simply walking on the balcony.

I feel that that port flaps are caused by the cable being exposed to external factors whereas the cable should always be in complete standstill. This may be layman's thinking, but still appreciate your feedback on that.

WirelessRudy · Wed Aug 10, 2011 1:48 am

Rudy,
based on your experience, does port flapping also occur while using passive PoE splitters to power the RB in an outdoor enclosure?

We use these only. But maybe an idea. I can test a unit one of these days with a power splitter/take-off in a hampered unit. This way the power will not come to the board via the utp cable but via the jack. Maybe that helps... we'll see.

I have deployed two 5.6 RB433 recently. One on a rooftop with a 50 meters FTP cable sent down the building without fixing it to the elevation. We were planning to fix the cable the next day, but the router had been turned on anyway. The installation has undergone a stress test during the night while a severe storm passed over the area. The port was flapping for 15 minutes. Once the storm has gone the port flapping stopped. I am wondering if this was caused by the cable being smashed against the wall by the wind.

Another RB was installed on a balcony where the cable was put under a synthetic carpet. I was noticing port flaps during daytime and I came to the conclusion that the customer might have been causing the port flaps by simply walking on the balcony.

I feel that that port flaps are caused by the cable being exposed to external factors whereas the cable should always be in complete standstill. This may be layman's thinking, but still appreciate your feedback on that.

All my cables are well attached to walls and roofs and masts/poles. But that is more out of tidiness and good conduct. I don't think physical movement of the utp cable would be an issue as long as the force is not driving the twisted wires apart or squeeze the copper core through the insulation against another cable. A synthetic carpet on the other hand could cause static electricity flows that can have effect on the date transport in the UTP cable. But if the flapping would have been caused by someone walking over it?? Well, everything is possible. But I think that change is relative small...

ohara · Wed Aug 10, 2011 9:11 am

Hi,

Apreciate if you could post test results. I have ordered some splitters yesterday but won't be able to conduct any tests within the next few days.

Skaught · Thu Aug 25, 2011 1:55 am

We are seeing these issues and we are the NOC for 4 different MT based ISPs in different locations across North America.

The router drops it's link down to 10mbit randomly and also refuses to link at all if we hard code both ends to 100mbit full.

We have hundreds of rb's using ethernet only that show these issues. They are connected to a mix of other RB radios, ubnt radios, network management devices, Fibre transceivers and client devices. We see the issues all over the place in a roughly random pattern. The issue is random enough that if you only had a hundred MTs in use, you may not even notice it. We see it constantly as we have so many devices deployed.

The only variable that is the same throughout is MT. These networks have all been built by different people thousands of miles apart. We thought it was issues with bad cables so we TDR'd as many as we could, and they all certified with flying colours. These are armoured cables that are properly bonded and surge suppressed if they run outside.

Our crews are Journeymen Telecom Electricians with years of experience who build to and exceed code in all workmanship. This is not an installation or ESD problem. This is not a reporting problem, the other devices report the slow link, flapping and issues. Speeds also slow to a crawl when the link drops to 10mbit.

We have the latest firmware, opened a ticket, and have sent in .rif files. No solution in sight.

elgo · Thu Aug 25, 2011 2:38 pm

post deleted, not related.

n21roadie · Thu Aug 25, 2011 3:54 pm

@Rudy have you tried powering the boards using two core cable and plug in the dc direct to test?
or put a 12v battery next to unit for test

ohara · Thu Aug 25, 2011 11:11 pm

just noticed that none of the port flapping messages appears in the remote kiwi syslog even though remote logging for 'interface' is set.

Makes kind of sense - if the connection is down then no data about it will be sent to the remote syslog. This makes troubleshooting much more difficult as one has to go into winbox logs for spotting port flaps.

Ivoshiee · Tue Aug 30, 2011 12:02 am

I've monitored my RB750G and that issue is more likely to affect ether1 (and ether2) ports - I see several port down/up and speed variation messages on those ports a day, but any port higher there is that not so frequent if any.

Note: No POE in use from ether1 is in use and ISP modem is still about 1,8 meters away on the same CAT5 cable.

jfartak · Tue Aug 30, 2011 10:32 am

I can confirm too, that RB411 (v5.6) has the same issue. Even though nothing is writen to the MK's log when this occurs, but on the switch to which is this board connected (either via PoE or non PoE port), something like this in log appears (MK is in Port

:

[474] 14:40:02 2011-06-27
"STA topology change notification."
level: 6, module: 5, function: 1, and event no: 1
---------------------------------------------------------------
[473] 14:40:00 2011-06-27
"STP port state: MSTID 0, Eth 1/8 becomes non-forwarding."
level: 6, module: 5, function: 1, and event no: 1
---------------------------------------------------------------
[472] 14:39:58 2011-06-27
"STP port state: MSTID 0, Eth 1/8 becomes forwarding."
level: 6, module: 5, function: 1, and event no: 1
---------------------------------------------------------------
[471] 14:39:55 2011-06-27
"Unit 1, Port 8 link-up 100M FD notification."
level: 6, module: 5, function: 1, and event no: 1
---------------------------------------------------------------
[470] 14:39:54 2011-06-27
"STP port state: MSTID 0, Eth 1/8 becomes non-forwarding."
level: 6, module: 5, function: 1, and event no: 1
---------------------------------------------------------------
[469] 14:39:54 2011-06-27
"Unit 1, Port 8 link-down notification."
level: 6, module: 5, function: 1, and event no: 1
---------------------------------------------------------------
[468] 14:39:29 2011-06-27
"STP port state: MSTID 0, Eth 1/8 becomes forwarding."
level: 6, module: 5, function: 1, and event no: 1
---------------------------------------------------------------
[467] 14:39:27 2011-06-27
"Unit 1, Port 8 link-up 100M FD notification."
level: 6, module: 5, function: 1, and event no: 1
---------------------------------------------------------------
[466] 14:39:22 2011-06-27
"Unit 1, Port 8 link-down notification."
level: 6, module: 5, function: 1, and event no: 1
---------------------------------------------------------------

This is weird, because if you're using any network protocols (RSTP/OSPF...) this can lead to generating "unreasoned" events in the network. Furthermore, in such scenario, the IP watdog (if configured) can trigger reboot (when link goes up and RSTP makes port reachable and forwardable).

What is even worse, this happen too on our several RB433/AH running 5.6. This is another switch log example (MK's switch port 18):

[324] 08:04:24 2011-08-30
"Unit 1, Port 18 link-up notification."
level: 6, module: 5, function: 1, and event no.: 1
---------------------------------------------------------------

[323] 08:04:18 2011-08-30
"Unit 1, Port 18 link-down notification."
level: 6, module: 5, function: 1, and event no.: 1
---------------------------------------------------------------

[322] 08:04:06 2011-08-30
"Unit 1, Port 18 link-up notification."
level: 6, module: 5, function: 1, and event no.: 1
---------------------------------------------------------------

[321] 08:03:41 2011-08-30
"Unit 1, Port 18 link-down notification."
level: 6, module: 5, function: 1, and event no.: 1
---------------------------------------------------------------

[320] 08:03:32 2011-08-30
"Unit 1, Port 18 link-up notification."
level: 6, module: 5, function: 1, and event no.: 1
---------------------------------------------------------------

Nothing found in the MK log, but the switch (other switch model, other site) logged it. As you can see, some "outages" are quite long, so we suspect (when such flap occurs), that it is causing random reboots, when IP watchdog si configured.

WirelessRudy · Tue Aug 30, 2011 2:24 pm

jfartak; maybe a strange question; you do have the logging topic "interface" enabled in the routerboards?
If not the log won't show Ethernet interface status in ROS.

jfartak · Tue Aug 30, 2011 3:24 pm

jfartak; maybe a strange question; you do have the logging topic "interface" enabled in the routerboards?
If not the log won't show Ethernet interface status in ROS.

You're right - topic "interface" was not included, so it makes a sense, that nothing was visible in the log. So I set up logging on some most problematic boards and I will check them. However, the fact, that topic was not included makes the problem revealing more harder, because only switches logs showed up what happened.

I would give you Karma - but don't know how to do it

. I had register myself today here and up to now, I was just an reader, not writer. However, this "flap problem" made me to do it

.

Really, we have about 200 RB4xx boards too in our network and as time comes, we encountered more and more random reboots (due to IP watchdog - the event was logged in MK log) and RTSP topology changes (where RSTP used) when they shouldn't be (on normal conditions - no link overloadings, attacks, power interrupts etc.). And in switch logs, we found mysterious flapping of the ethernet interface, even though cablings (factory made patch cables) were measured and eventually changed, but without success. Boards were powered by the AC/DC adaptors, not by PoE.
So I started to look over the net, if somebody other has similar problem and found quite many posts (even in our Czech ISP MK forums).

Tue Aug 30, 2011 3:25 pm

I would give you Karma - but don't know how to do it .

click on the "plus" button under his name on the left.

I had register myself today here and up to now, I was just an reader, not writer. However, this "flap problem" made me to do it .

did you also contact support? this is a community support. developers don't read everything.

jfartak · Tue Aug 30, 2011 3:53 pm

Just for completation:

What makes this problem even worse is fact, that such ethernet down/up events makes switch (that is conected to the MK) to empty its dynamic MAC entries in its table for that port. So when it happened, unicast flood in the subnetwork where this switch is "root" is inevitable, because traffic sent to the MK port before the flap, is sent then immediately to the all ports (without the uplink of course), because switch does not know the learned MACs on the MK port as before. If you have more MKs in such network (or more on the same switch), some weaker models a la RB133 etc. may not handle such traffic (CPU 100 percent) and may reboot, or inaccessible for several seconds or even minute (if watchog sent it to reboot).

This is the worst thing I am afraid of. If MK handles e.g. 10-20Mbit of traffic and decides to "close" the door, then switch sents this traffic to all ports (and eventually other MK if present) and reboot/inaccessibility avalanche is here!. Sometimes, the outage is 2-3 seconds, but from logs I posted above - some of them I found were 20-30 seconds long! So until router sends ARP request to retrieve if such host behind MK is alive, unicast flood in the subnetwork will not dismiss. Of course, some smarter swicthes can reduce unicast floods by settings thresholds, but this is just a crutch.

Such traffic spikes and unicast floods were more times a day detected in our network, just due to this problem.

jfartak · Tue Aug 30, 2011 4:00 pm

I would give you Karma - but don't know how to do it .

click on the "plus" button under his name on the left.
Ahh, thank you, I finally found it

I had register myself today here and up to now, I was just an reader, not writer. However, this "flap problem" made me to do it .
did you also contact support? this is a community support. developers don't read everything.

Up to now, not. But as it looks, I will have to

. BTW thanks for explanation - I thought, that this forum is extensively under the look of developers.

WirelessRudy · Tue Aug 30, 2011 8:01 pm

I thought, that this forum is extensively under the look of developers.

I´ll bet they follow every topic if it is interesting enough for them.... they only won't acknowledge this otherwise users will start making claims.
So if a user want to make a claim or serious report they expect you to do a lit bit more effort and make an official support request with some additional information so they than are in a better situation to administer the follow-up.
(Not meaning though this always works 100%. They are also humans...

)

WirelessRudy · Tue Aug 30, 2011 8:03 pm

Oh, thanks for the karma! You earned one too because I think this is a very helpfull report you made for these MT guys.

Ivoshiee · Wed Aug 31, 2011 9:41 pm

I've monitored my RB750G and that issue is more likely to affect ether1 (and ether2) ports - I see several port down/up and speed variation messages on those ports a day, but any port higher there is that not so frequent if any.

Note: No POE in use from ether1 is in use and ISP modem is still about 1,8 meters away on the same CAT5 cable.

It is likely not related, but that box went down on me twice today. All leds shining and all, but no ping response from any port nor traffic being processed. First measure was to change a PSU. I'll see if it will fail again or not.
Despite all that the port flapping is still the same:

18:59:44 interface,info ether1 link down 
18:59:48 interface,info ether1 link up (speed 10M, full duplex) 
19:14:00 dhcp,info server1 deassigned 192.168.21.51 from F0:DE:F1:0D:39:0F 
19:38:03 interface,info ether1 link down 
19:38:10 interface,info ether1 link up (speed 1000M, full duplex) 
19:38:10 dhcp,info server1 assigned 192.168.21.51 to F0:DE:F1:0D:39:0F 
19:59:42 interface,info ether1 link down 
19:59:46 interface,info ether1 link up (speed 10M, full duplex) 
20:04:27 interface,info ether1 link down 
20:04:34 interface,info ether1 link up (speed 1000M, full duplex) 
20:06:39 interface,info ether1 link down 
20:06:40 interface,info ether1 link up (speed 10M, full duplex) 
20:06:41 interface,info ether1 link down 
20:06:43 interface,info ether1 link up (speed 10M, full duplex) 
20:24:39 dhcp,info server1 deassigned 192.168.21.51 from F0:DE:F1:0D:39:0F 
20:50:44 interface,info ether1 link down 
20:50:51 interface,info ether1 link up (speed 1000M, full duplex) 
20:50:53 dhcp,info server1 assigned 192.168.21.51 to F0:DE:F1:0D:39:0F 
20:57:47 interface,info ether1 link down 
20:57:50 interface,info ether1 link up (speed 10M, full duplex) 
21:10:53 dhcp,info server1 deassigned 192.168.21.51 from F0:DE:F1:0D:39:0F 
aug/31 23:11:53 interface,info ether1 link down 
aug/31 23:12:00 interface,info ether1 link up (speed 1000M, full duplex) 
aug/31 23:12:01 dhcp,info server1 assigned 192.168.21.51 to F0:DE:F1:0D:39:0F 
aug/31 23:33:30 interface,info ether2 link down 
aug/31 23:33:32 interface,info ether2 link up (speed 10M, full duplex) 
aug/31 23:34:38 interface,info ether1 link down 
aug/31 23:34:40 interface,info ether1 link up (speed 10M, full duplex) 
aug/31 23:35:02 interface,info ether1 link down 
aug/31 23:52:00 dhcp,info server1 deassigned 192.168.21.51 from F0:DE:F1:0D:39:0F 
07:24:46 interface,info ether2 link down 
07:24:49 interface,info ether2 link up (speed 1000M, full duplex) 
12:31:59 interface,info ether2 link down 
12:32:00 interface,info ether2 link up (speed 10M, full duplex) 
12:56:46 interface,info ether5 link down 
12:56:48 interface,info ether5 link up (speed 100M, full duplex) 
13:03:18 interface,info ether5 link down 
13:03:20 interface,info ether5 link up (speed 100M, full duplex) 
13:18:37 interface,info ether5 link down 
13:18:38 interface,info ether5 link up (speed 100M, full duplex) 
13:28:09 interface,info ether5 link down 
13:28:11 interface,info ether5 link up (speed 100M, full duplex) 
14:34:00 interface,info ether2 link down 
14:34:03 interface,info ether2 link up (speed 1000M, full duplex) 
00:20:59 interface,info ether2 link down 
00:21:01 interface,info ether2 link up (speed 10M, full duplex) 
11:02:15 interface,info ether2 link down 
11:02:17 interface,info ether2 link up (speed 1000M, full duplex) 
13:46:40 interface,info ether2 link down 
13:46:42 interface,info ether2 link up (speed 10M, full duplex) 
13:47:32 interface,info ether2 link down 
14:06:46 interface,info ether2 link up (speed 100M, full duplex) 
14:07:24 interface,info ether2 link down 
14:07:27 interface,info ether2 link up (speed 1000M, full duplex) 
14:08:03 interface,info ether2 link down 
14:08:07 interface,info ether2 link up (speed 1000M, full duplex)

wiyat · Sat Sep 03, 2011 2:49 am

Dear
Mikrotik Forum

I apologize for my write but its 1:31am 03/89/2011.

My scenery.:

Main Router (OSPF) --- RB1000(switch)/routing --RB433AH(PtP)/bridge -- RB433AH(PtP)/bridge ---RB1100AH(PPPoE)/OSPF--- RB493AH/Bridge 5 port (where is connected 4 AP) --- RB433AH/Two Radios/Bridge---End

Ten days ago after to upgrade all our Mikrotik equipment two 5.6V we note that one AP have to many drop and disconnection and over the RB493AH I see the ether9 down/up.- On this moment we reported to Mikrotik this problem and they recommend to me that Enable/RSTP on Bridge port because they think that the problem was a Loop.

A.- I enable the RSTP but the problem continue
B.- I read it on this forum that maybe the problem was the ethernet cable (I changed) but the
problem continue
C.- I change the RB433AH on the AP and the Radios but the problem continue
D.- I change the power supply and Poe and the problem continue

You can see my graphic where you understand that every 5 or 10 minutes the AP disconnect from the RB493AH by 3 sec and after come back but this problem affect to all client that is connect on this AP.

I spoke with the MT specialist on Mexico and he recommend that we need to add the mac address of our client on the access list, at the same time I ask to Janis/Mikrotik about it and he sent me back and email recommend that we need to do this.

Well yesterday 02/09/2011 aprox 23:00PM I added the clients that connect to this AP on the access list and right now 2:00AM on 03/09/2011 I not have the flap problem on the Port9.

I dont know if the problem go but I will be post on the next 2 days if the problem is 100% is fix it..

I hope that this information help you..

Best regards

Wiyat

WirelessRudy · Sat Sep 03, 2011 1:34 pm

wiyat; I've been reading your post with interest.
It is always best to have wireless clients that are allowed to associate to AP in the access list. But that's another topic.
I find it curious that in your case putting AP's clients in its access list would solve the port flap on a router that is only attached to this AP via a Ethernet interface and cable.
I don't think one router would be influenced by another's associated clients. Lets see what happens. I've had occasions where a port flap issue disappeared only to come back after some days....

But keep us posted what your findings are. In your case it is clear your 349AH has a port flap issue and its real, since your AP looses contact when your Etherenet port 9 is down.

wiyat · Sat Sep 03, 2011 10:55 pm

Dear
Rudy

The problem is on the Firmware 2.29 that this firmware coming with any error and I dont know how I can put back to the older version of firmware on my RB433AH.

Do you know how I can do this, please specify from where I can download the before version.

We have install 50 AP RB433AH and we not have any problem on 49 equipment and only this one, the only change that I do was that I upgrade the firmware to 2.29 and after this situation I have a error on my ethernet port down/up (FLAP).

If you know how I can downgrade the firmware to the before version of 2.29 and tell me from where I can download to test right now I will be testing now.

Thank you..

WirelessRudy · Sun Sep 04, 2011 3:01 am

How to downgrade the firmware:
@adi55 wrote this:

Downgrade procedure is quite simple:
1. Download the .fwf firmware file for corresponding product firmware from http://routerboard.com/index.php?showProduct=52.
Drag&drop this file into File Window from Winbox.
2. Reboot.
3. Last operations:
from terminal window:
/system routerboard print
and check the "update-firmware" to see if the downgrade version was "seen". If it is then you will put:
/system routerboard upgrade
which, in this case will do a "downgrade" firmware.

http://forum.mikrotik.com/viewtopic.php ... 80#p259480

and the warning from @willy:

Do not downgrade the firmware to lower than the device released! Be careful! Downgrade only if you exactly know what will happen (for example device runs with this version before).

same topic.

Please let us know how you're going. It might be a solution....

Ivoshiee · Sun Sep 04, 2011 9:01 am

If that is the firmware issue then where to get 2.27 for a RB750G to test it out?

wiyat · Sun Sep 04, 2011 9:49 am

Dear
WirelessRudy and Ivoshiee

The main point is that i dont found on internet a site from where I can download the older version to download.- On Mikrotik Forum exist a topic that show how to do this but when do you go to routerboard.com the firmware file is actual 2.36.

Mikrotik.Wiki not recommend to do this "downgrade to the before version" apparently we can damage the board is better to upgrade to the last firmware version.- For this reason you dont found a older firmware version on Internet.

I have two idea:
1. Using a netinstall I try to download to the original firmware version, if this no working its ok.
2. I will be update to the 2.36 version and I hope that my problem will be correct.

At the same time I report to Mikrotik about this situation where we testing the 5.6 Roteros version and 2.29 firmware in other AP that is on production and we have the Flap problem too, automatically after to upgrade the firmware on this RB433AH the flap problem start.

Remember this is a Theory about the firmware because maybe the problem is my RB433AH that have 14 months that is working and maybe the firmware its not compatible with the chip I dont know.

I write you after that we test our solution and I hope that this work.

Thank u

Ivoshiee · Wed Sep 07, 2011 9:23 am

I haven't found a proper firmware and thus I haven't reverted the RB750G firmware, yet.

Another variant of that port flip is reported here:
http://forum.mikrotik.com/viewtopic.php?f=7&t=54790

WirelessRudy · Wed Sep 07, 2011 12:44 pm

I haven't found a proper firmware and thus I haven't reverted the RB750G firmware, yet.

Another variant of that port flip is reported here:
http://forum.mikrotik.com/viewtopic.php?f=7&t=54790

I took 4 new units in use this week, I updated to 5.6 but did not update the firmware. I'm putting them in production and will monitor them. If they don't have the port flap coming up in a week or so I will still update the firmware and see what happens then....

Ivoshiee · Wed Sep 07, 2011 2:06 pm

I haven't found a proper firmware and thus I haven't reverted the RB750G firmware, yet.

Another variant of that port flip is reported here:
http://forum.mikrotik.com/viewtopic.php?f=7&t=54790
I took 4 new units in use this week, I updated to 5.6 but did not update the firmware. I'm putting them in production and will monitor them. If they don't have the port flap coming up in a week or so I will still update the firmware and see what happens then....

Good plan for the starters.

WirelessRudy · Tue Sep 13, 2011 10:50 am

New Issue developed today!"

rb493AH running for over one year.
On Ethernet port 8 a backhaul link is connected that consist out of two in bridge mode working NanoStationM's
This link works for 8 months without issues.
Since this morning Ethernet port 8 of rb493AH started to flip on and off. This is a real one since units and customers behind that link lost their connection.

I set the Ethernet to 10Mb manual and the problem is gone although the speed is maximal 6Mb over that back-haul which is not enough!
The moment I switch the port manual to 100Mb or set negotiation to ´auto´ the port starts to flicker on and off.

Just send a support request for this one, but no ticket no. received yet.

I am going to switch units off, and back on (power cycle) to see if that might make any difference.

n21roadie · Tue Sep 13, 2011 11:23 am

Hi Rudy not sure if this of any help but i had a issue with a 493ah where on one ethernet port going to a ptp link was going down and by just disabling and few moments later re-enabling would solve the problem for hours this happened not every day but about every three days, the only entry in the log about the down time was reporting ospf route loss after trying a lot to pin point the source i traced the fault to a DHCP conflict coming back from a internal router in a household into a rb750 further down the ptp link chain, this was after ethernet from 493 to 433 wireless link to 433 (PtP) ethernet to 750 and also using nat masquerade from 10.152.x.x to 192.168.10.x ???????

WirelessRudy · Tue Sep 13, 2011 12:17 pm

OK, I took the Ethernet cable out of this flapping port 8 (All other ports are in use and all connected to as many more backhauls + one to main gateway to internet)
Waited 2 mins and put it back in. Port still flapped in 100Mb mode.

Powered rb493AH down, waited 2 mins and powered up again (all cables attached, whole network down!).
Router came up and I switched port 8 to 100Mb manual. Connected up fine.
Now, 30mins later port did not flap a single time!

Obviously their is something wrong with the software or the Ethernet driver.
Now I have to sit and wait to see what is happening.

In the meantime waiting for v5.7 that was promised last week...

Hopefully the reason for the delay is that they are still working on this issue before they bring 5.7 out. Otherwise they can start on 5.8!

MT: Ticket#2011091366000173 refers to this specific issue. If you answer to that mail I can send you 2 more supout.rif's. One at 100Mb but flapping and one after the power cycle.

(It might be an idea to have support request to have the ability to add more files to the mail. At least 2, 1 before an issue and 1 after a change/reboot/power cycle.)

wirelesswaves · Tue Sep 13, 2011 1:03 pm

I am begining to wonder if it is hardware related, you remember that I said the other day, that an AP appeared to freeze the other day, and that although I was unable to contact it over the wire, that the customers appeared unaffected.

And that was because, the AP had a second wlan interface (backhaul), so no data was physically leaving the router via its ethernet port. But within 5 mins I had customers complaining that they had lost internet, they were all connected via various AP's on the same tower, but their cables all went to a RB750, and all the traffic left the RB750 via port 2 to the backhaul within the AP mentioned above.

Rebooting all the routers by power cycling made no difference, however as soon as I physically touched the ethernet cable plugged up to port 2 on the RB750, everything sprang back into life.

I now believe that there may be a faulty batch of RJ45 connectors out there. The RJ45 connector has magnetics that are delicate and also sensitive to over-soldering, I know because I trashed one trying to remove it from the pcb, although it appeared intact, the heat had damaged the internal magnetics.

Maybe these are put in by hand and maybe on the assembly line there is a guy/gal who keeps the soldering iron on for too long. Maybe that is causing dry/oxidised joints within the RJ45 socket that appear to fail when there is temperature changes.

WirelessRudy · Tue Sep 13, 2011 4:14 pm

I am begining to wonder if it is hardware related, you remember that I said the other day, that an AP appeared to freeze the other day, and that although I was unable to contact it over the wire, that the customers appeared unaffected.

And that was because, the AP had a second wlan interface (backhaul), so no data was physically leaving the router via its ethernet port. But within 5 mins I had customers complaining that they had lost internet, they were all connected via various AP's on the same tower, but their cables all went to a RB750, and all the traffic left the RB750 via port 2 to the backhaul within the AP mentioned above.

Rebooting all the routers by power cycling made no difference, however as soon as I physically touched the ethernet cable plugged up to port 2 on the RB750, everything sprang back into life.

I now believe that there may be a faulty batch of RJ45 connectors out there. The RJ45 connector has magnetics that are delicate and also sensitive to over-soldering, I know because I trashed one trying to remove it from the pcb, although it appeared intact, the heat had damaged the internal magnetics.

Maybe these are put in by hand and maybe on the assembly line there is a guy/gal who keeps the soldering iron on for too long. Maybe that is causing dry/oxidised joints within the RJ45 socket that appear to fail when there is temperature changes.

Well, you might be true.
But it seems that I've an unreasonably big amount of this ´bad badge´ coming my way! According MT I was actually the only one having the issue to start with!

Anyway, your story sounds plausible with my limited knowledge compared to you.

But how does this relate to the fact that most port flapping units also see the issue disappear if the software is set to ´manual´ and the rate to 10Mb?

And what would be the reason most flaps happen during daytime hours while issues seem to greatly disappear overnight? Several users more or less have reported this behaviour in the forum.

Would be interesting if MT finally could shine a light on this and if they are working on the issue. So far its damn silent from their end.

trn76 · Tue Sep 13, 2011 6:02 pm

Hi everyone, I got the same problem occuring several places.

RB1100 v5.6 firm 2.30 was flipping ether1-5.
We tried various auto-negotiate on/off and speed settings, but we didnt notice any difference(no, we did not try 10Mbps, as its just wont carry the traffic).
Next, we replaced the RB1100 with a brand new one, but the issue is the same.
Tonight we are going to replace it with a new RB1200....and see what happens.
We are an ISP and this issue is serious... So I really hope MT will come up with the solution fast.

There isnt any high CPU loud (16-28%), total bw around 20-70Mbps max, and not alot of small packages...all fine really.

Here is the log from the newly replaced RB1100.....

sep/11 03:02:10 interface,info ether4 link down 
sep/11 03:02:10 interface,info ether5 link down 
sep/11 03:02:13 interface,info ether5 link up (speed 100M, full duplex) 
sep/11 03:02:14 interface,info ether1 link up (speed 1000M, full duplex) 
sep/11 03:02:14 interface,info ether2 link up (speed 1000M, full duplex) 
sep/11 03:02:14 interface,info ether3 link up (speed 1000M, full duplex) 
sep/11 03:02:14 interface,info ether4 link up (speed 1000M, full duplex) 
sep/11 09:28:16 interface,info ether3 link down 
sep/11 09:28:19 interface,info ether3 link up (speed 1000M, full duplex) 
sep/12 06:46:19 interface,info ether4 link down 
sep/12 06:46:22 interface,info ether4 link up (speed 1000M, full duplex) 
sep/12 06:46:50 route,ospf,info OSPFv2 neighbor 5.5.5.5: state change from Full to Down 
sep/12 07:33:38 interface,info ether1 link down 
sep/12 07:33:38 interface,info ether2 link down 
sep/12 07:33:38 interface,info ether3 link down 
sep/12 07:33:38 interface,info ether4 link down 
sep/12 07:33:38 interface,info ether5 link down 
sep/12 07:33:41 interface,info ether5 link up (speed 100M, full duplex) 
sep/12 07:33:42 interface,info ether1 link up (speed 1000M, full duplex) 
sep/12 07:33:42 interface,info ether2 link up (speed 1000M, full duplex) 
sep/12 07:33:42 interface,info ether3 link up (speed 1000M, full duplex) 
sep/12 07:33:42 interface,info ether4 link up (speed 1000M, full duplex) 
sep/12 10:37:11 interface,info ether3 link down 
sep/12 10:37:14 interface,info ether3 link up (speed 1000M, full duplex) 
sep/12 18:56:49 interface,info ether1 link down 
sep/12 18:56:49 interface,info ether2 link down 
sep/12 18:56:49 interface,info ether3 link down 
sep/12 18:56:49 interface,info ether4 link down 
sep/12 18:56:49 interface,info ether5 link down 
sep/12 18:56:51 interface,info ether5 link up (speed 100M, full duplex) 
sep/12 18:56:52 interface,info ether1 link up (speed 1000M, full duplex) 
sep/12 18:56:52 interface,info ether2 link up (speed 1000M, full duplex) 
sep/12 18:56:52 interface,info ether3 link up (speed 1000M, full duplex) 
sep/12 18:56:53 interface,info ether1 link down 
sep/12 18:56:53 interface,info ether2 link down 
sep/12 18:56:53 interface,info ether3 link down 
sep/12 18:56:53 interface,info ether5 link down 
sep/12 18:56:55 interface,info ether5 link up (speed 100M, full duplex) 
sep/12 18:56:56 interface,info ether1 link up (speed 1000M, full duplex) 
sep/12 18:56:56 interface,info ether2 link up (speed 1000M, full duplex) 
sep/12 18:56:56 interface,info ether3 link up (speed 1000M, full duplex) 
sep/12 18:56:56 interface,info ether4 link up (speed 1000M, full duplex) 
07:21:35 interface,info ether1 link down 
07:21:35 interface,info ether2 link down 
07:21:35 interface,info ether3 link down 
07:21:35 interface,info ether4 link down 
07:21:35 interface,info ether5 link down 
07:21:37 interface,info ether5 link up (speed 100M, full duplex) 
07:21:38 interface,info ether2 link up (speed 1000M, full duplex) 
07:21:38 interface,info ether3 link up (speed 1000M, full duplex) 
07:21:38 interface,info ether4 link up (speed 1000M, full duplex) 
07:21:39 interface,info ether2 link down 
07:21:39 interface,info ether3 link down 
07:21:39 interface,info ether4 link down 
07:21:39 interface,info ether5 link down 
07:21:41 interface,info ether5 link up (speed 100M, full duplex) 
07:21:42 interface,info ether1 link up (speed 1000M, full duplex) 
07:21:42 interface,info ether2 link up (speed 1000M, full duplex) 
07:21:42 interface,info ether3 link up (speed 1000M, full duplex) 
07:21:42 interface,info ether4 link up (speed 1000M, full duplex)

We got a PowerRouter lying around, but there isnt enough ether ports on it...but first lets see how the RB1200 handles it.

wirelesswaves · Tue Sep 13, 2011 6:20 pm

MMM MMM KKK TTTTTTTTTTT KKK
MMMM MMMM KKK TTTTTTTTTTT KKK
MMM MMMM MMM III KKK KKK RRRRRR OOOOOO TTT III KKK KKK
MMM MM MMM III KKKKK RRR RRR OOO OOO TTT III KKKKK
MMM MMM III KKK KKK RRRRRR OOO OOO TTT III KKK KKK
MMM MMM III KKK KKK RRR RRR OOOOOO TTT III KKK KKK

MikroTik RouterOS 5.6 (c) 1999-2011 http://www.mikrotik.com/

sep/10 09:16:31 interface,info ether2 link down
sep/10 09:16:33 interface,info ether2 link up (speed 100M, full duplex)
sep/10 17:55:11 system,info,account user admin logged in from xxxxxxxxxxx via winbox
sep/10 17:56:15 system,info,account user admin logged out from xxxxxxxxxx via winbox

sep/11 00:35:52 interface,info ether2 link down
sep/11 00:35:53 interface,info ether2 link up (speed 100M, full duplex)
sep/11 00:38:00 interface,info ether2 link down
sep/11 00:38:01 interface,info ether2 link up (speed 100M, full duplex)
sep/11 00:46:18 interface,info ether2 link down
sep/11 00:46:20 interface,info ether2 link up (speed 100M, full duplex)
sep/11 02:10:17 interface,info ether2 link down
sep/11 02:10:19 interface,info ether2 link up (speed 100M, full duplex)
sep/11 05:19:13 interface,info ether2 link down
sep/11 05:19:15 interface,info ether2 link up (speed 100M, full duplex)
sep/11 08:45:16 interface,info ether2 link down
sep/11 08:45:18 interface,info ether2 link up (speed 100M, full duplex)
sep/11 10:34:11 interface,info ether2 link down
sep/11 10:34:13 interface,info ether2 link up (speed 100M, full duplex)
sep/11 10:34:22 interface,info ether2 link down
sep/11 10:34:24 interface,info ether2 link up (speed 100M, full duplex)
sep/11 13:28:16 interface,info ether2 link down
sep/11 13:28:17 interface,info ether2 link up (speed 100M, full duplex)
sep/11 13:30:14 interface,info ether2 link down
sep/11 13:30:16 interface,info ether2 link up (speed 100M, full duplex)
sep/11 13:30:49 interface,info ether2 link down
sep/11 13:30:51 interface,info ether2 link up (speed 100M, full duplex)
sep/11 13:31:38 interface,info ether2 link down
sep/11 13:31:40 interface,info ether2 link up (speed 100M, full duplex)
sep/11 23:10:46 interface,info ether2 link down
sep/11 23:10:48 interface,info ether2 link up (speed 100M, full duplex)
sep/11 23:12:14 interface,info ether2 link down
sep/11 23:12:16 interface,info ether2 link up (speed 100M, full duplex)
sep/11 23:15:51 interface,info ether2 link down
sep/11 23:15:53 interface,info ether2 link up (speed 100M, full duplex)
sep/11 23:16:50 interface,info ether2 link down
sep/11 23:16:51 interface,info ether2 link up (speed 100M, full duplex)
sep/12 02:14:54 interface,info ether2 link down
sep/12 02:14:55 interface,info ether2 link up (speed 100M, full duplex)
sep/12 03:09:09 interface,info ether2 link down
sep/12 03:09:10 interface,info ether2 link up (speed 100M, full duplex)
sep/12 03:13:12 interface,info ether2 link down
sep/12 03:13:13 interface,info ether2 link up (speed 100M, full duplex)
sep/12 11:00:11 interface,info ether2 link down
sep/12 11:00:13 interface,info ether2 link up (speed 100M, full duplex)
sep/12 17:07:34 system,info,account user admin logged in from xxxxxxxxx winbox
sep/12 17:08:04 system,info,account user admin logged out from xxxxxxx via winbox

sep/12 23:37:19 interface,info ether2 link down
sep/12 23:37:21 interface,info ether2 link up (speed 100M, full duplex)
sep/12 23:54:12 interface,info ether2 link down
sep/12 23:54:14 interface,info ether2 link up (speed 100M, full duplex)
sep/12 23:59:16 interface,info ether2 link down
sep/12 23:59:18 interface,info ether2 link up (speed 100M, full duplex)
sep/12 23:59:23 interface,info ether2 link down
sep/12 23:59:24 interface,info ether2 link up (speed 100M, full duplex)
00:33:29 interface,info ether2 link down
00:33:30 interface,info ether2 link up (speed 100M, full duplex)
00:48:18 interface,info ether2 link down
00:48:20 interface,info ether2 link up (speed 100M, full duplex)
01:05:51 interface,info ether2 link down
01:05:52 interface,info ether2 link up (speed 100M, full duplex)
01:46:17 interface,info ether2 link down
01:46:18 interface,info ether2 link up (speed 100M, full duplex)
01:58:22 interface,info ether2 link down
01:58:23 interface,info ether2 link up (speed 100M, full duplex)
02:25:09 interface,info ether2 link down
02:25:10 interface,info ether2 link up (speed 100M, full duplex)
02:44:24 interface,info ether2 link down
02:44:25 interface,info ether2 link up (speed 100M, full duplex)
02:50:48 interface,info ether2 link down
02:50:49 interface,info ether2 link up (speed 100M, full duplex)
02:52:00 interface,info ether2 link down
02:52:01 interface,info ether2 link up (speed 100M, full duplex)
02:53:16 interface,info ether2 link down
02:53:17 interface,info ether2 link up (speed 100M, full duplex)
02:57:07 interface,info ether2 link down
02:57:08 interface,info ether2 link up (speed 100M, full duplex)
03:04:23 interface,info ether2 link down
03:04:25 interface,info ether2 link up (speed 100M, full duplex)
03:09:33 interface,info ether2 link down
03:09:35 interface,info ether2 link up (speed 100M, full duplex)
03:18:07 interface,info ether2 link down
03:18:09 interface,info ether2 link up (speed 100M, full duplex)
03:25:49 interface,info ether2 link down
03:25:50 interface,info ether2 link up (speed 100M, full duplex)
03:30:36 interface,info ether2 link down
03:30:38 interface,info ether2 link up (speed 100M, full duplex)
06:44:10 interface,info ether2 link down
06:44:12 interface,info ether2 link up (speed 100M, full duplex)
09:26:00 interface,info ether2 link down
09:26:02 interface,info ether2 link up (speed 100M, full duplex)
09:53:38 interface,info ether2 link down
09:53:39 interface,info ether2 link up (speed 100M, full duplex)
09:54:04 interface,info ether2 link down
09:54:05 interface,info ether2 link up (speed 100M, full duplex)
09:54:18 interface,info ether2 link down
09:54:20 interface,info ether2 link up (speed 100M, full duplex)
10:03:37 interface,info ether2 link down
10:03:39 interface,info ether2 link up (speed 100M, full duplex)
17:05:48 system,info,account user admin logged in from 192.169.5.2 via winbox
17:06:15 system,info,account user admin logged in from 192.169.5.2 via telnet

Really, what "bullshit" (from them) Dozens of us have been experiencing this problem for months, and I agree YOU and a limited amount of others have been telling them.. I suppose its OUR fault for making a silly mistake of assuming that they were going to do something about it.. I suppose the only way for them to believe it, is for us to send in our logs daily..

Above is the router (RB750) in question... Odd that the log should show sept 12 and not sept 13 as winbox does, (but then I guess thats just another bug!!!)

OOOO heres one from a client's router

MMM MMM KKK TTTTTTTTTTT KKK
MMMM MMMM KKK TTTTTTTTTTT KKK
MMM MMMM MMM III KKK KKK RRRRRR OOOOOO TTT III KKK KKK
MMM MM MMM III KKKKK RRR RRR OOO OOO TTT III KKKKK
MMM MMM III KKK KKK RRRRRR OOO OOO TTT III KKK KKK
MMM MMM III KKK KKK RRR RRR OOOOOO TTT III KKK KKK

MikroTik RouterOS 5.6 (c) 1999-2011 http://www.mikrotik.com/

sep/06 09:25:06 interface,info ether1 link down
sep/06 09:25:09 interface,info ether1 link up (speed 100M, full duplex)
sep/06 09:25:11 interface,info ether1 link down
sep/06 09:25:13 interface,info ether1 link up (speed 100M, full duplex)
sep/06 09:25:31 interface,info ether1 link down
sep/06 09:25:35 interface,info ether1 link up (speed 10M, half duplex)
sep/06 20:27:09 system,info,account user admin logged in from xxxxxx via winbox
sep/06 20:28:57 system,info,account user admin logged out from xxxxxxx via winbox
sep/07 09:51:07 interface,info ether1 link down
sep/07 09:51:10 interface,info ether1 link up (speed 100M, full duplex)
sep/07 09:51:12 interface,info ether1 link down
sep/07 09:51:14 interface,info ether1 link up (speed 100M, full duplex)
sep/07 09:51:33 interface,info ether1 link down
sep/07 09:51:35 interface,info ether1 link up (speed 10M, half duplex)
sep/07 14:16:53 interface,info ether1 link down
sep/07 14:16:56 interface,info ether1 link up (speed 100M, full duplex)
sep/07 14:16:58 interface,info ether1 link down
sep/07 14:17:00 interface,info ether1 link up (speed 100M, full duplex)
sep/07 14:17:20 interface,info ether1 link down
sep/07 14:17:23 interface,info ether1 link up (speed 10M, half duplex)
sep/08 09:31:25 interface,info ether1 link down
sep/08 09:31:28 interface,info ether1 link up (speed 100M, full duplex)
sep/08 09:31:30 interface,info ether1 link down
sep/08 09:31:32 interface,info ether1 link up (speed 100M, full duplex)
sep/08 09:31:49 interface,info ether1 link down
sep/08 09:31:52 interface,info ether1 link up (speed 10M, half duplex)
sep/08 09:53:02 interface,info ether1 link down
sep/08 09:53:15 interface,info ether1 link up (speed 100M, full duplex)
sep/08 09:53:17 interface,info ether1 link down
sep/08 09:53:19 interface,info ether1 link up (speed 100M, full duplex)
sep/08 09:53:39 interface,info ether1 link down
sep/08 09:53:42 interface,info ether1 link up (speed 10M, half duplex)
sep/08 20:53:28 interface,info ether1 link down
sep/08 20:53:31 interface,info ether1 link up (speed 100M, full duplex)
sep/08 20:53:33 interface,info ether1 link down
sep/08 20:53:35 interface,info ether1 link up (speed 100M, full duplex)
sep/08 20:53:52 interface,info ether1 link down
sep/08 20:53:55 interface,info ether1 link up (speed 10M, half duplex)
sep/08 20:58:17 interface,info ether1 link down
sep/08 20:58:30 interface,info ether1 link up (speed 100M, full duplex)
sep/08 20:58:32 interface,info ether1 link down
sep/08 20:58:34 interface,info ether1 link up (speed 100M, full duplex)
sep/08 20:58:50 interface,info ether1 link down
sep/08 20:58:53 interface,info ether1 link up (speed 10M, half duplex)
sep/08 22:52:47 interface,info ether1 link down
sep/08 22:52:50 interface,info ether1 link up (speed 100M, full duplex)
sep/08 22:52:52 interface,info ether1 link down
sep/08 22:52:54 interface,info ether1 link up (speed 100M, full duplex)
sep/08 22:53:11 interface,info ether1 link down
sep/08 22:53:14 interface,info ether1 link up (speed 10M, half duplex)
sep/09 09:21:47 interface,info ether1 link down
sep/09 09:21:50 interface,info ether1 link up (speed 100M, full duplex)
sep/09 09:21:52 interface,info ether1 link down
sep/09 09:21:54 interface,info ether1 link up (speed 100M, full duplex)
sep/09 09:22:12 interface,info ether1 link down
sep/09 09:22:15 interface,info ether1 link up (speed 10M, half duplex)
sep/10 09:12:18 interface,info ether1 link down
sep/10 09:12:20 interface,info ether1 link up (speed 100M, full duplex)
sep/10 09:12:22 interface,info ether1 link down
sep/10 09:12:24 interface,info ether1 link up (speed 100M, full duplex)
sep/10 09:12:41 interface,info ether1 link down
sep/10 09:12:44 interface,info ether1 link up (speed 10M, half duplex)
sep/11 10:42:43 interface,info ether1 link down
sep/11 10:42:46 interface,info ether1 link up (speed 100M, full duplex)
sep/11 10:42:48 interface,info ether1 link down
sep/11 10:42:50 interface,info ether1 link up (speed 100M, full duplex)
sep/11 10:43:07 interface,info ether1 link down
sep/11 10:43:11 interface,info ether1 link up (speed 10M, half duplex)
sep/12 08:42:13 interface,info ether1 link down
sep/12 08:42:15 interface,info ether1 link up (speed 100M, full duplex)
sep/12 08:42:18 interface,info ether1 link down
sep/12 08:42:19 interface,info ether1 link up (speed 100M, full duplex)
sep/12 08:42:38 interface,info ether1 link down
sep/12 08:42:41 interface,info ether1 link up (speed 10M, half duplex)
sep/12 16:48:00 interface,info ether1 link down
sep/12 16:48:03 interface,info ether1 link up (speed 100M, full duplex)
sep/12 16:48:05 interface,info ether1 link down
sep/12 16:48:07 interface,info ether1 link up (speed 100M, full duplex)
sep/12 16:48:31 interface,info ether1 link down
sep/12 16:48:33 interface,info ether1 link up (speed 10M, half duplex)
09:43:13 interface,info ether1 link down
09:43:16 interface,info ether1 link up (speed 100M, full duplex)
09:43:18 interface,info ether1 link down
09:43:19 interface,info ether1 link up (speed 100M, full duplex)
09:43:38 interface,info ether1 link down
09:43:42 interface,info ether1 link up (speed 10M, half duplex)
11:25:06 interface,info ether1 link down
11:25:11 interface,info ether1 link up (speed 100M, full duplex)
11:25:15 interface,info ether1 link down
11:25:25 interface,info ether1 link up (speed 100M, full duplex)
11:25:28 interface,info ether1 link down
11:25:30 interface,info ether1 link up (speed 100M, full duplex)
11:25:47 interface,info ether1 link down
11:25:49 interface,info ether1 link up (speed 10M, half duplex)
17:14:19 system,info,account user admin logged in from xxxxx via winbox
17:14:39 system,info,account user admin logged in from xxxxxx via telnet

[admin@MikroTik] /log>

No doubt Nomis will slate me for posting meaningless logs instead of sending in RIF's, but whats the point in sending those in, if they are going to be ignored!!

Anyhow, my point, it happens, DAY or NIGHT!!!!

Anymore logs required from the dozens of RB's doing the same thing!!!!!

fewi · Tue Sep 13, 2011 6:31 pm

I doubt this is helpful, but just because: I have around 100 RB1100s installed, they all connect to Cisco switches. Most at 1000/full auto negotiated, some at 100/full auto negotiated (as limited by the switch on the other side).

I don't have any link flaps anywhere, ever.

Slightly odd use case, though: only ether1 and ether6 are used on any of those boards. All other ports are shut down (disabled) within RouterOS.

Could this have to do with the switch chips? At a quick glance through the thread the hardware models people are having issues on all have switch chips though I may have missed some posts.

On the other hand I don't have any issues on an RB750G at home either where all ports are in use - but none of them are switched, they're all routed.

WirelessRudy · Wed Sep 14, 2011 12:03 am

I doubt this is helpful, but just because: I have around 100 RB1100s installed, they all connect to Cisco switches. Most at 1000/full auto negotiated, some at 100/full auto negotiated (as limited by the switch on the other side).

I don't have any link flaps anywhere, ever.

Slightly odd use case, though: only ether1 and ether6 are used on any of those boards. All other ports are shut down (disabled) within RouterOS.

Could this have to do with the switch chips? At a quick glance through the thread the hardware models people are having issues on all have switch chips though I may have missed some posts.

On the other hand I don't have any issues on an RB750G at home either where all ports are in use - but none of them are switched, they're all routed.

I have rb112's, 133c's, 532A's, 411's, 493AH, now the groove and the SXT. Every model has a port flap at times. Not ALL, but it is spread over all my units. 5% of my routers have it severe, 10% mild and some 30% occasional. But more than half never has the port flap issue. I don't know if the groove and the SXT as well as the older boards have switch chips but these units do have the issue.

Most of my units are not earthed nor use shielded cables. That has never been a problem but I started to think in that direction. Until this morning where my rb493AH suddenly developed the issue on one of its ports. This board is properly grounded. It is connected with a non shielded cable to a NanoStationM. Removing the cable for some time did not solve the problem. After attaching it again the problem was back. Only a ´cold reboot´ (power cycle) solved the problem. Now, for 12 hours, the board runs fine again and no more port flaps.

Now can I change that cable for a shielded one to see if the issue comes back or not. I will only know after some months. Without such cable the port didn't flap for at least 5 months. And it is a backhaul so all sorts of traffic load runs over it.

MT not replying to this topic the last days/weeks combined with the postpone of the already overdue release of v5.7 makes me only to think they must be with their hands in their hair not knowing what to do!

hopp · Wed Sep 14, 2011 12:32 am

FWIW I had a similar issue with port flapping. I added a ferrite bead on the eth cable cleared it right up. Turns out it was some UBNT 900mhz gear causing the issue for me.

WirelessRudy · Wed Sep 14, 2011 3:40 am

Update on my last port flap issue:

It happened again tonight.
This time the power cycle of my 493AH did not solve the issue. And even in 10Mb manual the port kept flapping. (Etherport

Power cycling of the NanostationLocoN also did not solve the problem.
I swapped port 8 with 9 to see if it was the port of the rb493AH. No, now port 9 developed the issue while port 8 became working normal with some other stuff connected. So, it must be an external source.

- removed the NanostationLocoN (call it NSLN) and put it on my desk. Connected it up with two non shielded cables through MT powershot with 18V adapter and hooked up to my PC. Everything OK, no port flap.
- the data cable that normally connects between my rb493AH and the powershot I now connected to my PC and the MT powershot while the short cable was still connected with POE to the NSLN Everything OK, no port flap. So that first leg of cable has no issue.
- replaced the MT 18V adapter by the original 12V UBNT adapter. Everything OK, no port flap. (Still all to my PC) So it has nothing to do with voltage.
- replaced the MT powershot to the original UBNT adapter. Port started immediately to flap again! (It not only shows on the NSLN LED, also my PC reported the port losing connection and making it again... etc.
- used a second UBNT powershot. Same issue, port started to flap again.
- Put MT powershot back in place, everything OK. no port flap.
- Put again for double check both the UBNT powershots in place. All OK. No more port flaps!!!!
- Put MT powershot back in place, all OK. No port flap.
- PUt NSLN back in mast and connected it to original last cable leg while MT powershot in use. All OK, No port flaps.
- Put UBNT powershot back in place. All OK, no port flaps...
- Put MT powershot back in place. All OK, no port flaps and after 20 mins closed everything up and went home. (Its 2 AM!)

Conclusion: I don't know any more!
What can be wrong? Maybe bad contacts in the cable connector or powershots playing up with increase/decrease in humidity due temp rise/fall? All connectors are without physical tension, in a dry ventilated place and free of insects.

I noticed that although the cable in use is a shielded one, the connectors are not. So next thing tomorrow is to replace the connectors for shielded ones. Same time put some electro cleaner at the Ethernet ports of the chain. Maybe some small corrosion took place on one of the tiny contacts?
Hope that helps.....

Keep you updated.....

(So it looks like this specific one is not so much an issue of the rb port. The port flap came from the UBNT device.)

9dollor · Wed Sep 14, 2011 6:17 am

In my central unit (with a bunch of rb's interconnected to each other, including 2 rb1000's) the issue came up every so many days and was repaired by interconnecting all routerboards and housings to daisy chain earth connection. Problems disappeared since. The problem here was obviously either ESD or current ´leakage´ over the boards and the Ethernet connector.

WirelessRudy · Wed Sep 14, 2011 10:47 am

In my central unit (with a bunch of rb's interconnected to each other, including 2 rb1000's) the issue came up every so many days and was repaired by interconnecting all routerboards and housings to daisy chain earth connection. Problems disappeared since. The problem here was obviously either ESD or current ´leakage´ over the boards and the Ethernet connector.

I've had exactly the same problem with my central unit rb1000 a year ago. Running v.4.x versions. But here the ports just stopped sending traffic out. Incoming always stayed working. Only way to solve was power cycles.
After interconnection all my 6 rb's with same daisy chain grounding and installing v5.x ROS problems solved and gone....

In general the last three years we have several problems with Ethernet ports. Several rb411's and 133C's just lost the Ethernet port. Some even during the first initial default script startup. I just threw away a stack of boards collected over the years with dead Ethernet ports.
(They were waiting for repair but in fact only collecting dust and occupying space. So I just binned them! Can't waste my time and money on these.)

Ethernet ports and the cables with their connectors are responsible for at least 85% of all problems we have on the network over all those years.

wiyat · Fri Sep 23, 2011 12:01 am

Dear
All User Affected

I correct the FLAP Problem on my Network.

Situation: Apparently the new version 5.6 and the firmware that come together with this version come with the flap problem and affect the Mikrotik Equipment RB493, RB493AH, RB433AH, RB750 Etc, the problem start on the port 8 or 1 to or 1 to 8, how you detected.

1. CPU going up to 80%
2. Drop packet (smokeping monitoring)
3. Mirkrotik Tools profile (management profile going up to 70%)

How I do.

I request to Mikrotik the old firmware of all my MIkrotik RB 750,493,433 etc and after to downgrade the firmware to 2.20 and keep the version to 5.6 the network work normal I have 10 days that I not have any problem.

I dont know what is the problem on the Firmware version but the problem its solved.

if you need any support about it please send me an email to wiyat at yahoo com spanish/english and I will be help you.

Thank You Janis and Normis..

best regards,

Wiyat
The only way to find and correct the problem is contact to Mikrotik...

zervan · Fri Sep 23, 2011 6:55 am

I'm glad to say I haven't had any issues like that with the newest ROS and firmware. However, yesterday had one of my RB750G exactly these symptoms:

1. CPU going up to 80%
3. Mirkrotik Tools profile (management profile going up to 70%

At first I didn't understand, what's wrong, but when I looked at active connections I saw many connections to my SSH port (other than 22, I've changed it) from a suspicious address from internet. I set firewall to block it and the problem was solved.

Fri Sep 23, 2011 9:01 am

thanks for the tip, zervan. others should also check if there are no attacks on your router at the time of the problem. high CPU usage is also suspicious. remember also that in v5.7 there is a DHCP server bug, where it causes high resource usage if it's on a disabled interface. this is fixed in v5.8

wiyat · Sat Sep 24, 2011 12:41 am

thanks for the tip, zervan. others should also check if there are no attacks on your router at the time of the problem. high CPU usage is also suspicious. remember also that in v5.7 there is a DHCP server bug, where it causes high resource usage if it's on a disabled interface. this is fixed in v5.8

Thank you Normis... (All RB493Ah, RB433AH, RB750, RB333 have Ros 5.6 and Old firmware and its work OK 100% ) I hope that on the 5.7 or 5.8 come with the all correction... BUT At the moment the flap problem its solved...

Zervan: if you need something about this problem please let me know and I give u my comments..

WirelessRudy · Sat Sep 24, 2011 12:52 am

(All RB493Ah, RB433AH, RB750, RB333 have Ros 5.6 and Old firmware and its work OK 100% ) I hope that on the 5.7 or 5.8 come with the all correction... BUT At the moment the flap problem its solved...

Well, YOUR flap problem is solved. But I still have it and probably many others. Its an issue in 5.4 to 5.7 minimum.

mmmigoro · Sat Sep 24, 2011 1:20 am

thanks for the tip, zervan. others should also check if there are no attacks on your router at the time of the problem. high CPU usage is also suspicious. remember also that in v5.7 there is a DHCP server bug, where it causes high resource usage if it's on a disabled interface. this is fixed in v5.8

The bug is also present if DHCP relay is enabled on a disabled interface, the CPU goes to 100% tested on 411AH and SXT.

wiyat · Sat Sep 24, 2011 6:43 pm

WirelessRudy

Example: If you have a RB493AH update with 5.6 Ros Version and Firmware 2.29 only that you need to request to Mikrotik the Firmware 2.20 and when you receive this firmware file you need to put into Files and after you need to go to Console and run the following command: sys rou up and after sys reboot.

When do you do this the new firmware version will be 2.20.

The problem is on the firmware 2.29 come with some problem but I dont know what is exactly the problem but when you downgrade your FIRMWARE your Flap problem will be correct.

Comment:
When I note that I have a Flap problem was when I upgrade the RB493AH to ROS 5.6 and I upgrade the firmware to 2.29 on this moment my FLAP problem Start.- Well I request to Mikrotik the Firmware version special to RB493AH version 2.20 and I downgrade the problem was fix it.

Do you understand..

Thank You

This is the only way to correct this problem....

wiyat · Sat Sep 24, 2011 6:44 pm

Remember you the only way to correct the problem is report to Mikrotik and they will be correct the situation.

THANK YOU MIKROTIK

NAB · Sat Sep 24, 2011 6:46 pm

The bug is also present if ...

I think I have another case which would explain what happened this morning...

I was messing about with VLANs on the home router (RB750). Added, removed and tried various things. In the course of this, a DHCP server was set up on a VLAN interface which was disabled.

Ever since then, CPU has been at 100%.

I have cleared the router out to the configuration it had before I started playing and the CPU is still at 100%.

Since then, the DNS server on the box has stopped responding a couple of times and needs

/ip dns set allow-remote-requests=no
/ip dns set allow-remote-requests=yes

to get it going again.

Not good.

wiyat · Sat Sep 24, 2011 6:50 pm

This is My Graph, if you observe we had too many days with this problem and After to downgrade the firmware the problem was solved..

Thank you

wirelesswaves · Sat Sep 24, 2011 11:51 pm

The problem is on the firmware 2.29 come with some problem but I dont know what is exactly the problem but when you downgrade your FIRMWARE your Flap problem will be correct.

Really!!!!!!!!!!!!!!!!!! see attached paintshop image of RB750 that is running ros5.6 but deliberately not upgraded from firmware 2.26 to 2.29!!

Remember you the only way to correct the problem is report to Mikrotik and they will be correct the situation.

Really!!!!!!!!!!!!!!!! According to MT, Rudy is the only one with a port flap problem!

jandafields · Sun Sep 25, 2011 12:41 am

The bug is also present if ...
I think I have another case which would explain what happened this morning...

I was messing about with VLANs on the home router (RB750). Added, removed and tried various things. In the course of this, a DHCP server was set up on a VLAN interface which was disabled.

Ever since then, CPU has been at 100%.

I have cleared the router out to the configuration it had before I started playing and the CPU is still at 100%.

Since then, the DNS server on the box has stopped responding a couple of times and needs
Code: Select all
/ip dns set allow-remote-requests=no
/ip dns set allow-remote-requests=yes
to get it going again.

Not good.

The DHCP 100% CPU issue is a bug in v5.7 only (fixed in 5.8) and has nothing to do with the port flapping issue.

Also, whatever DNS problem you have that requires a restart is probably not relevant to the port flapping issue either.

The port flapping issue is present with several versions of Mikrotik.

jandafields · Sun Sep 25, 2011 12:46 am

The problem is on the firmware 2.29 come with some problem but I dont know what is exactly the problem but when you downgrade your FIRMWARE your Flap problem will be correct.

Really!!!!!!!!!!!!!!!!!! see attached paintshop image of RB750 that is running ros5.6 but deliberately not upgraded from firmware 2.26 to 2.29!!

Remember you the only way to correct the problem is report to Mikrotik and they will be correct the situation.

Really!!!!!!!!!!!!!!!! According to MT, Rudy is the only one with a port flap problem!

You may need to go back further than 2.26 (2.20 if your device supports it).

You should report to Mikrotik support regardless of who you think that they say has the bug. The more reports, the quicker the fix!

WirelessRudy · Sun Sep 25, 2011 2:34 am

The problem is on the firmware 2.29 come with some problem but I dont know what is exactly the problem but when you downgrade your FIRMWARE your Flap problem will be correct.

Comment:
When I note that I have a Flap problem was when I upgrade the RB493AH to ROS 5.6 and I upgrade the firmware to 2.29 on this moment my FLAP problem Start.- Well I request to Mikrotik the Firmware version special to RB493AH version 2.20 and I downgrade the problem was fix it.

Well, MT never gave me this option. I "was the only one with the problem" anyway. Hence I started this topic to bring it back up on the agenda again. The issue is started with the first 5.0 and 5.1 packages. I don't know what firmware they had but basically ros5x came with an Ethernet status sensor and since the port flaps are around.
I have several support mails with them and they never gave me such option. So I don't believe the downgrade is going to be the option for me.

But if you send me the fw's to my mail rudy@marucom.es for some rb133C's, rb411's, SXT's and groove's I can start testing your statement. I don't want to wait until the week because then I have no time...

jandafields · Sun Sep 25, 2011 2:46 am

This page has firmware 2.23 and 2.36 for AR7100 units:
http://routerboard.com/RB433UAH

2.23 came out with Mikrotik 4.4, so it is way before the 5.0 version firmware.

wiyat · Sun Sep 25, 2011 2:28 pm

Hello WirelessRudy.

Its better if you request the firmware version to Mikrotik Support but please specify to them what is the firmware that you need.

Example: I request the firmware version 2.26 but not work ok, after that I downgrade to firmware 2.20 all work Fine. But the firmware that They sent to me only is for RB493AH, RB433AH.

For this reason you need send to Mikrotik Support what is the firmware that you need.

Best Regards,

Wiyat

Ivoshiee · Thu Sep 29, 2011 5:25 pm

Another one:
http://forum.mikrotik.com/viewtopic.php ... =1#p281764

zervan · Wed Oct 12, 2011 10:39 am

Today I have had a problem with ether2 on RB750G (as far as I remember, this was the second time - first time it was few months ago). I've reported it to support. Is it what you call "port flap"?

I've had an issue with my RB750G - ether2 stopped to work at all. This was not the first time.

Configuration is:
- ether1 is master port of switch;
- ether2-4 are slave ports of switch;
- ether5 is independent interface.

In the morning I've resumed (from hibernation) my computer on ether2 and I didn't have connection. I've started Wireshark to see what's wrong - there was no single packet incoming (and it should be a lot of broadcast, there are dozens of computers on network). I was not able to ping router from ether2 as well.

I tried to restart my computer - didn't help. I tried to disconnect the cable and connect back - didn't help.

I tried to turn on my other computer on ether5 and it was working there. I looked at RB750G using WinBox to see what's wrong - everything seemed to be fine, but I was not able to ping (nor arp) computer on ether2. The ether2 port was running on 1 Gbps, so I tried to set 100 Mbps manually - didn't help. Then I set auto negotiation back - but it failed - strange. So I've left it on 100 Mbps and created supout file, witch is in attachment.

I tried to remove my computer from ether2 and connect it to ether3 - it was working fine there. I tried to connect other computer to ether2 - was not working.

It means: there was problem on ether2 only, obviously.

After all I rebooted RB750G and ether2 is working again.

honzam · Wed Oct 12, 2011 5:58 pm

The same problem with rb711. Latest firmware. ROS 5.7 and 5.8. This problem occurs in more customers
2-3sec down and up

zervan · Wed Oct 12, 2011 8:03 pm

It was not the same on my router - ethernet port seemed to be "on", but was not working.

Strange thing: today afternoon I came back home, turned on computer and.. the same problem as in the morning. Why? Router is running few weeks without any change or reboot (and few months without any problem) and here are 2 issues today.

honza: Zdravím západných susedov!

WirelessRudy · Wed Oct 26, 2011 8:02 pm

Suffered from, and found reason why and cured this particular one....

After changing some in my network so suddenly a routerboard 433 that is connected by Ethernet to a rb439AH developed a very severe port flap issue.
The change in the network was 2 more hubs down the line where I hang a complete network with some 80 users on it to use this specific routerboard 433 on its way to the central. (This router also has a wireless link through which all traffic comes in).

First two days after the change nothing happened.
Third day noticed every 3-5 hours Ethernet port of the 433 dropped to immediately come back. Sometimes 5 to 6 time in a row to disappear for some hours until the next event...
Fourth day problem became severe. During the morning interval dropped to every hour roughly and in the afternoon suddenly dropped to every 5 mins....

I spend 36 hours to fight this. Tried everything. New cable, new power block. Set both connected ports to "auto rate sense" or manual, (noticed this problematic port's "auto rate sense" produced "failed" status message). The manual setting made the port flap less severe, went back from every 1-5 min to every 15-20mins...). Changed bridged routers into full routing down the line into my network. Disabled some part of the network to determine if the problem came from somewhere else. (Strange, problem disappeared if that new part of the network was disconnected from that router 1 hub away. The problem disappeared....! This same network always ran over a different router towards central and never gave problems in similar setup... When I enable this 80 user network to run again port flap just came back in all severity!)

Tried downgrade the software all the way back to 4.17NV2 wireless package. This solved the issue for exactly 12 hours and than it just came back!

Rebooting didn't help, power cycle did for an hour or so...
So update router back to 5.7. Problem still around.
Upgraded the firmware into latest v2.36, problem still around.

Since my theory still is that it has something to do with the sensitivity of the Ethernet port sensor in the software I decided to use a power splitter to split the power off the Ethernet cable so a powerless plug runs into the Ethernet 2 port and the power (14V) is delivered to the board by a jack. (I have to inform this rb433 is in a metal box, but not earthed. It is not available in that location and the board is already running fine in this role for 5 years without a single problem!)

The powersplit-off cable cured the problem it looks like! Unit is now running for 48 hours without a single port flap!

This makes me even more think the POE ethernet port of the boards are very sensitive for ESD what might trigger the port to shut down and come back up...

WirelessRudy · Wed Oct 26, 2011 8:05 pm

I've not been in the position to request the 'old' firmwares from MT like "wyiat" suggested. Also because I do not really believe it will bring salvation...
And if it would, than I would find it very strange MT up to now never replied on this one yet....

But anyway, anybody else that tried the downgrade firmwares and did it bring the solution?

jandafields · Wed Oct 26, 2011 8:29 pm

There is a new 2.37 firmware, but I don't know if it addresses this issue. Might not hurt to try it. It's in the 5.8 links that are floating around here...

sup5 · Thu Oct 27, 2011 2:12 am

Instead of a power supply use a lead-acid battery (car battery) for testing the port-flap issue.

Modern PSU might add high frequency garbage on the DC-power.

A lead acid battery delivers the best power you can get.

I could imagine, that the port-flap issue will be gone, if the routerboard is powered by a battery.

WirelessRudy · Thu Oct 27, 2011 11:12 am

Instead of a power supply use a lead-acid battery (car battery) for testing the port-flap issue.

Modern PSU might add high frequency garbage on the DC-power.

A lead acid battery delivers the best power you can get.

I could imagine, that the port-flap issue will be gone, if the routerboard is powered by a battery.

I completely agree. I would imagine the same.
Sad thing is only that this specific board already is powered by a big bank of batteries (400AH!). Since they are continuously charged the voltage at the boards is higher than the 12V nominal of the batteries so that should be ok then.
Actually I have a couple of other boards powered via battery supply and these also show a port flap occasionally.
(But than again, even the chargers are 'pulsing' so that could give a problem?)

The board with the power take off is still running so I think this is the solution for me. These PoE ports are too vulnerable. I have already had several problems with them (2% of my boards had more or less a Ethernet problem with these ports.)
Several boards had these PoE ports stop working in a way that they don't pass traffic any more while still usable for power supply or they became completely dead where the board still boots by jack and in case of 433 the other ports are still usable.

My conclusion is that the POE ports are vulnerable for ESD which can break them so I am going to avoid them from now on....

n21roadie · Mon Dec 05, 2011 11:13 am

Instead of a power supply use a lead-acid battery (car battery) for testing the port-flap issue.

Modern PSU might add high frequency garbage on the DC-power.

A lead acid battery delivers the best power you can get.

I could imagine, that the port-flap issue will be gone, if the routerboard is powered by a battery.
I completely agree. I would imagine the same.
Sad thing is only that this specific board already is powered by a big bank of batteries (400AH!). Since they are continuously charged the voltage at the boards is higher than the 12V nominal of the batteries so that should be ok then.
....

Have you tried disconnecting the charger and as suggested power the board from the battery only?

vmnx · Thu Feb 02, 2012 2:40 pm

I will write about port flapping too. Til now, I haven't real problem, 2-3 flaps a day, so be it. But now log looks like this:
14:03:31 interface,info eth1-W1 link up (speed 100M, full duplex)
14:03:41 interface,info eth1-W1 link down
14:03:43 interface,info eth1-W1 link up (speed 100M, full duplex)
14:03:51 interface,info eth1-W1 link down
14:03:54 interface,info eth1-W1 link up (speed 100M, full duplex)
14:04:08 interface,info eth1-W1 link down
14:04:11 interface,info eth1-W1 link up (speed 100M, full duplex)
14:04:23 interface,info eth1-W1 link down
14:04:26 interface,info eth1-W1 link up (speed 100M, full duplex)
14:04:32 interface,info eth1-W1 link down
.................................
eth1 is POE port on RB493AH.
I had to climb to the roof ant change cable from 1 to 7. And now every think is OK. Not a single flap. So, the problem is not in cables, not ir other end port. Problem is in POE port. 10mbps worked a lot better than 100mbps. I don't know what does it means.

EDIT: maybe the reason it started to flap, is cold? Now in east Europe is -20

Thu Feb 02, 2012 2:42 pm

the RB493 PoE port is a separately connected port. It will get different statistics and information. So it's entirely possible that you don't get bad cable report because the other ports don't report it.

honzam · Thu Feb 02, 2012 5:31 pm

If someone using this type of POE so it causes a lot of problems (down and up)
http://www.i4wifi.eu/passive-poe-injector_d1392.html

samsung172 · Thu Feb 02, 2012 9:26 pm

I have seen this a lot between rb 1xxx and rb 800 . It seems like problem show up, if use poe to the 800 and cable is not gigabit sertified. "home made" 30 meter cable (5e) give a lot of troble, while factory made short cable <5m fix issue. Problem does not show if using "old" non gigabit poe.

n21roadie · Thu Feb 02, 2012 10:49 pm

If someone using this type of POE so it causes a lot of problems (down and up)
http://www.i4wifi.eu/passive-poe-injector_d1392.html

I have used a lot of those and no problems.

vmnx · Wed Feb 08, 2012 11:51 am

1. With port 7 I don't get any packet loss.
2. RB is powered by dedicated power port, not POE.
3. cable is prebuild 0,5m.

Wed Feb 08, 2012 12:54 pm

I think that most here fail to realize that in 99% of situations with port flapping it has nothing to do with software - it is hardware.
Currently i do not have any port flapping problems in the network but this is what i have seen:

1) some hardware simply is not compatible with each other (not only MikroTik) over time it forced us to use similar equipment everywhere
2) Not shielded cables were affected by electrical cables that runs near-by can cause port flapping.
3) Cable problems - too short, too long, some cables turned out to have designated wires for data, if you use other color wire it had problems.
so we are also trying to use same Ethernet cable manufacture.
4) faulty cable connectors - testing equipment shows all OK, but problem persist - swapping it out to another manufacture solved that problem.
5) Partially blown Ethernets (usually because of grounding problems) - usually indicates some time after connection is created.
6) best one: one of our engineers have "an electric personality" - he manage to damage equipment only by touching it. So we had to "ground" him.

Only once i have seen software related problem and it was in case port flapped every time there was high data load on it.

to WirelessRuby - no offense, but it looks like you have most of the problems, maybe you use bad cables/connectors or use bad pinout for these cables, also get a electrical engineer and recheck all the grounding status on you boards. If port flapping stats after some days of deployment - congrats, most likely you have partially burned you Ethernet because of some static electricity.
Also there is a chance that you are also "an electric personality"

qverty2012 · Tue Apr 17, 2012 8:11 pm

My dear friends. I have the Mikrotik RB450g. I have connected 2 AP. 1 is Nanostation M2 and the second is AirMax Sector 2G-16-90. But i have the same problem with either3 link up/link down (in 2 sec). I have changed - power supplies, cabels. Have the same problem. Pls help me

wifiqos · Sat May 05, 2012 7:54 pm

You might be exceeding the line length for the power you need.

here is an online calculator to determine the line loss as a function of distance from the power injector to the load device. It will predict the delivered voltage after you enter the line length and the power needed by the device, and it will calculate the power loss in the CAT-5.

http://beyond-wifi.com/poe/poe-calc.html

This is an iterative calculation - note that some combinations of high power, long length and low voltage are actually mathematically in-stable - it will oscillate and your voltmeter will show you the average when in fact it is actually dropping out.

The online calculator warns of this and you can figure out the max distance, and minimum voltage you need in the POE injector.

You can do this in excel - but the online calculator saves time.

lmhandslh · Mon May 28, 2012 3:08 pm

I have the same issue RB450G, I'm using 3 as pppoe concentrators, 2 have port flapping on ports 2-4, more frequently 3 and 4, but occasionally on 2 (all happen at the same time, never on 1 or 5 on either of them). 450 is directly plugged in to battery backup no poe power, longest cable length 3' all brand new cables. What's interesting but I assume unrelated, on 1 of the 3 all running firmware 5.12 now there is no flapping issue the only difference in setup between the 3 is the one rb450g we haven't logged or visually seen the issue on is running userman for pppoe authentication, the others are using PPP Secrets to store the authentication credentials, I'm sure unrelated but an observation none the less.

I had upgraded two of the routers to 5.16 the one's using ppp secrets, and the flapping increased substantially, from 1 or 2 flaps, to 30-40 in a row, still only happened 1 or 2 times a day (I turned the PPPOE keepalive up to 60 to keep some of the customers from dropping, some still do). I have now rolled them back to 5.12, and although it still happens the frequency is significantly less. Time is hard to predict but at least happens once a day, usually twice. We have 4 Routermaxx routers running RouterOS 5.15 and have yet to see or log a port flap on any of them, all are authentication users using PPP Secrets.

Rudy your not alone.

qverty2012 · Mon May 28, 2012 3:18 pm

The same situation. Mikrotik is RB450G . I ve updated Mirkotik to 5.16. But port flapping still go on at the one of the port. I don't know how to decide this problem

Mon May 28, 2012 3:21 pm

We found one issue in our whole network with port flapping in the log file, when we inspected the situation, we found that it was caused by an old Planet switch. We replaced it with RB2011 in switch mode, and it works great since.

If you have port flapping issue - make sure you try to replace the involved devices, cables and switches. It could be caused by hardware fault, or if the device is old - maybe it was improved in a later revision. For example if you have it on RB450G, check when you bought it, and try a different one (newer) if you can.

qverty2012 · Mon May 28, 2012 3:29 pm

We found one issue in our whole network with port flapping in the log file, when we inspected the situation, we found that it was caused by an old Planet switch. We replaced it with RB2011 in switch mode, and it works great since.

If you have port flapping issue - make sure you try to replace the involved devices, cables and switches. It could be caused by hardware fault, or if the device is old - maybe it was improved in a later revision. For example if you have it on RB450G, check when you bought it, and try a different one (newer) if you can.

So you want to say that update or something else don;'t give anything results? Only need to change the Mikrotik to another model?

Mon May 28, 2012 3:40 pm

I am saying that most likely your problem is caused by cables or bad switch!

qverty2012 · Mon May 28, 2012 3:43 pm

I am saying that most likely your problem is caused by cables or bad switch!

I changed cables 3 times

stmx38 · Mon May 28, 2012 4:00 pm

We have same issue:
RB750UP(5.16) + Cisco Catalyst (c2950-i6q4l2-mz.121-13.EA1.bin)
But I thought this is a Cisco Switch issue. Issue doesn't appear on all ports of Cisco Switch. Also I noticed that this depends of wall outlets.
May be this is a ROS bug ?

Mon May 28, 2012 4:08 pm

slech
I do not want to blame any other software, however 121-13.EA was released 6 years ago [2006], (as I found on switch manufacturer web-page).

1) Do you have the same configuration on all ports of the switch?
2) Is there any difference, when Cisco switch is connected to Ether1 or Ether2-Ether5 RB750UP?

lmhandslh · Wed May 30, 2012 2:11 am

Today we swapped out our cables, checked new cables with fluke all tested clean (old ones tested clean, normis is adamant it's cable or switch, we'll take his advice and swap both). It was happening once at least every 24 hours, so far it's been 12 hours no flap.

WirelessRudy · Wed May 30, 2012 3:27 am

Well, I ever started the topic and its still there.
It is still random around on many of my installations but clients don't seem to notice so I leave it around. But since I have e-mail notification enable for such events by default on all my units (250+) I still have several units having very severe port flaps going on.
Even on brand new installations with new cables, new connectors, new CPE and new Wifi routers and all updates software and firmwares sometimes the issue is still around.
But since its not bothering anyone apart from me (when I look in my mail box filling up with the messages) I leave it as it is and might consider to switch the notification completely off...

lmhandslh · Wed May 30, 2012 4:56 am

Happened again, we tried, always worth a shot.

Ivoshiee · Thu May 31, 2012 12:10 am

We found one issue in our whole network with port flapping in the log file, when we inspected the situation, we found that it was caused by an old Planet switch. We replaced it with RB2011 in switch mode, and it works great since.

If you have port flapping issue - make sure you try to replace the involved devices, cables and switches. It could be caused by hardware fault, or if the device is old - maybe it was improved in a later revision. For example if you have it on RB450G, check when you bought it, and try a different one (newer) if you can.

Dear MT: You have seen that given issue happening on your network with your equipment - we around the world are not seeing visions after all! Despite the sentiment of your comment I sure hope you are not dismissing it as not being an issue with the ROS, because other equipment are not affected by that given problem, but Mikrotik equipment are. Even if it is cable, PoE, other vendor equipment induced issue the fact is the ROS powered ones are having real issues dealing these conditions triggering port flipping. I sure hope you will set up an laboratory experiment around your Planet switch and try to analyze what conditions are making ROS to drop and flip connections. After all that good work we see finally the ROS emerge that start to tolerate these conditions.

Thu May 31, 2012 8:15 am

RouterOS is very good at logging things, it simply informs you of more things than some other equipment. In my described situation, the same issues happened with any other device, including PCs, so was not a MikroTik only problem - it was caused by a physically broken switch!

Ivoshiee · Thu May 31, 2012 9:27 am

RouterOS is very good at logging things, it simply informs you of more things than some other equipment. In my described situation, the same issues happened with any other device, including PCs, so was not a MikroTik only problem - it was caused by a physically broken switch!

Logging is a good thing for starters, so at least some portion of error detecting it is there already, but there is a need for some additional research into the reason why it is happening. MT customers are hardly qualified enough to figure it out what incompatibility is causing MT gear to stop working. I still believe that qualification is in MT, but somehow MT does not take that issue seriously enough.

If we see a port flap issue in systems with MT gear, should we ask for a RMA replacement for those equipment? Does MT accept that issue as a reason? I doubt it.

Thu May 31, 2012 9:30 am

We need as much information as possible, if you can, send us all the equipment where you see this issue constantly, including the cable and the switch. If you can get a simple system where this is happening, say - two routers and a switch in between - you could send it to us, so we can turn it on, see the issue, and start debugging it. Email support if you are willing to arrange this.

sup5 · Thu May 31, 2012 11:49 am

Yesterday I found out, that a firmware upgrade (routerboot?) solved one of my port flapping issues.
The ethernet link between a RB1200 and a RB-SXT always lost connectivity when I tried to push data through it.
A firmware upgrade on both Rb1200 and RB-SXT solved this issue.

But I don't know if it will help with spontaneous port flapping...

coffeecoco · Thu May 31, 2012 4:13 pm

i'm just curious and throwing idea's around has anyone "manually set the duplex" and had port flap issues?

Also ethernet sends 2 sets of voltage down ethernet if i remember 5 volt = 1 and 1-2 something = 0
I have just wondered if its a lack of power delivery? OR Faulty Capacitors
If im correct the voltages are controlled by capacitors

everyone know that famous super conductor thing, well anyway half the reason ethernet is limited to 1000mb/s is because capacitors
lack the ability to make the dc voltage square off at such high speeds when it goes from 5 to 2 it dont look square, on a graph it looks like a
/ slope, and what happens is its so fast at speeds 1000mb/s that hardly anything can really make out if that was a 5v or a 2 volt, because of the slopes

they managed to make a super conductor that can square it off very good... but hey lets face it we wont see one unless you have liquid nitrogen just to cool the capacitor ( true fact)
I really am not saying this is the issue, but i see alot of other faulty equipment in my time that makes me realise capacitors have a terrible life span.
especially cheap ones.

If im correct changing the port speed to 100mb/s extends the life span of a capacitor... i think
So i took the assumption here that maybe this is related to the duplex issue maybe routerboard uses the voltages as a reference for duplex speed?!?
Or the capacitors are not healthy

I would love to here someone attempt to re soilder new capacitors to there port flapping routers to see if that fix the issue
if it did Please reply here

Anyway, you also report that the port flap really means a disconnect of the physical line.
On the other hand, your disconnect last a very long time. Where all my port flaps usually happen within the same second or the port comes back within 2-3 secs at worst.
(All according my log. Imho it makes me even more think it is merely a reporting issue than a ´real´ issue. See my first porst.)
That long loss of connection is just a few such ones I experienced. Usually these connectionless gaps are between 10...15 seconds. I haven't checked if these all are reporting as interface being down, but I strongly suspect that.
Edit:
Snippet from the log:
Code: Select all
11:43:45 interface,info ether1 link down
11:43:55 interface,info ether1 link up (speed 1000M, full duplex)
11:46:19 interface,info ether1 link down
11:46:21 interface,info ether1 link up (speed 10M, full duplex)
11:46:27 interface,info ether1 link down
11:46:31 interface,info ether1 link up (speed 1000M, full duplex)
11:47:23 interface,info ether1 link down
11:47:24 interface,info ether1 link up (speed 10M, full duplex)
11:47:25 interface,info ether1 link down
11:47:28 interface,info ether1 link up (speed 1000M, full duplex)
11:47:49 interface,info ether1 link down
11:47:52 interface,info ether1 link up (speed 1000M, full duplex)
19:14:46 interface,info ether1 link down
19:14:47 interface,info ether1 link up (speed 10M, full duplex) 

changeip · Thu May 31, 2012 7:03 pm

how many are having this issue when using the included routerboard poe injectors that come with the SXT/OmniTiks, etc? It seems the ones I had problems with were caused by the injectors being flaky. Are those wires even 24 gauge?

Ivoshiee · Fri Jun 01, 2012 9:36 am

We need as much information as possible, if you can, send us all the equipment where you see this issue constantly, including the cable and the switch. If you can get a simple system where this is happening, say - two routers and a switch in between - you could send it to us, so we can turn it on, see the issue, and start debugging it. Email support if you are willing to arrange this.

I expect it is an open invitation for all affected parties to contribute, but I'll see if I found something what classifies to your requirements. At the same time I hope that Planet switch you found, its surrounding cables, connected MT equipment and all the rest is already going through investigation and just not thrown away instead.

Fri Jun 01, 2012 9:43 am

Yes, anybody who is able to take two mikrotik routers, plug them into each other, or into a switch, and see port flapping, is welcome to pack this setup into a box, and send to us.

wirelesswaves · Fri Jun 01, 2012 10:48 am

Ok.

I can send you a log file or whatever you want from an RB493 router with ROS5.9, that is now suffering port flap issues on 1 ethernet port (4)

This router is installed at the base of a tower, attached to the router are a number of RB411AH units, each with an individual Db radio card..
All of the antenna coax cables lead down from their respective antennas and are fed from the approriate routerboard.

The Site is 99% Mikrotik, (1 old belkin router is used only by the "netwatch facility" and its power is taken from the regular mains) All other router boards are supplied via Meanwell AD155 smps with 2 x 12v 70Ah batteries....

It is not possible to tell whether the port flap issue is a problem of the RB493 or is it the RB411ah, since both units will report the same message in the log file.

Prior to this I had the same issue with a RB750 at the base of a Tower and an RB433Ah at the top.
(this was documented elsewhere on the forum)

So, portflap between 2 adjacent MT units does exist.

Nomis.. PM me if you want access into the network.

Fri Jun 01, 2012 10:50 am

Thanks, we have seen log files, but we need actual failing installation here in our testing department.

wirelesswaves · Fri Jun 01, 2012 10:52 am

attached is the file that I sent in last year regarding the same issue between the RB433AH and a RB750

(lucky I kept the Paint shop image eh!)

wirelesswaves · Fri Jun 01, 2012 10:55 am

ok.. sorry, sent another attachment before noticing that you are online.. (God you are fast today)

Well obviously I cant send in the unit, since its in use... But you can have access if you like.,

Also,,, when both units report the same thing,, what would we be sending you, the RB411 or the RB493.

How do we determine which is the unit making the problem.

Fri Jun 01, 2012 10:56 am

wirelesswaves, they are directly connected to each other (no switch)? can you bring them down (swap for other routers) and see if the same happens on the table, when only they two are connected to each other?

wirelesswaves · Fri Jun 01, 2012 11:04 am

Yes they are directly connected, all units within a metre of each other... All ethernet patch cables tied and laced together.

The RB411's all sit on 1 shelf of an enclosure. and the RB493 beside them.

There is a redundant spare RB411ah with a Db card plugged in... Its a "ready to go unit" (unpowered) and sits there as a spare incase of a failure to any other RB411.

It may be possible for me to Load into the spare RB411 a copy of the parameters from the unit attached to Port9 and then recover this RB411ah... But this is a lot of work that I will have to do after midnight.

Let me know if you want me to go ahead.

Simon

Fri Jun 01, 2012 11:09 am

The reason I am asking is that we have worked with some of the people in this thread, and we can't repeat any of the symptoms by making exact 1:1 setup. This might be hardware related, or something very specific that we can't pin down yet. This is why we would love if somebody here could get "port flapping" in a simple test network, then pack it all in a box (including all cables and power adapters), and send to us. If we could just plug it in, and see port flapping, we would finally have something to test with. So far, we have not seen this issue "in person" anywhere, we have only seen the logs.

wirelesswaves · Fri Jun 01, 2012 11:18 am

Ok,

I understand, its a very frustrating problem... Really you need the pair of units sent to you.. I cant cos I dont have a spare RB493.

If you send me a spare RB493, then I can remove a RB411 and the RB493 and send them off to you.

By the way, its only cos I was bored this morning that I followed the forum thread again and decided to log into the router at the tower base.

1: It wasn't doing this when the tower was first commissioned back last November.
2: The RB411ah attached to ether4 is being netwatched further into the network by the gateway router with 2 min intervals and a timeout of 1000.
(last netwatch sms text sent regarding this unit was on Mar23rd)...

The associated AP (rb411ah on ether4) is carrying telephone traffic, and there are NO complaints at all.

So it may be showing a "port Flap" as alarming as it may seem, but whatever the matter is, it doesnt seem to affect telephone traffic or even trigger the "netwatch"

Simon

Fri Jun 01, 2012 11:24 am

Thanks for that information. I will let you know if we need further assistance.

wolfeyes · Mon Jun 04, 2012 12:39 pm

Same problem here between Omnitik (eth1 poe) and Groove (used for backhaul).
Devices are directly connected (no switch or other intermediate device).

Flapping occurs at least ten times a day and it is very annoying cause ospf state changes on Omnitik and neighboor devices.

Also descibed here:
http://forum.mikrotik.com/viewtopic.php?f=2&t=60922

zervan · Tue Jun 05, 2012 10:51 pm

I use 3 RB SXT, each on other building's roof, all of them are powered by more powerful 24 V, 1,6 A adapter (there was standard adapter at the begining, I've changed it thinking it would be better) and are connected to UPS. The problem is that 2 of them have port flap issue. One of them is connected directly to RB750G, powered by PoE injector and has problems for a long time (from the time I've installed it). Other one is connected to RB433, powered by adapter and AFAIK it was working fine for a long time, but the problems started to appear nowadays. There are days when no disconnection is appearing, but there are also days with many disconnections. Unfortunately, I can't pack and send the setup, because data cable is going through walls. But I hope somebody would be able to do it and that Mikrotik guys will found out what's wrong.

The SXT without an issue (till now) is connected to RB250GS switch.

WirelessRudy · Tue Jun 05, 2012 11:09 pm

well, that's indeed another example. I have a rb344 where one port is connected by a 60meters cable to a netgear wifi router. Several disconnects a day, at times many per hour.
Once for test just fit a netgear switch in between. Port flap completely disappeared. Not a single flap in weeks. Removed it again and the flaps where just back....

zervan · Tue Jun 05, 2012 11:18 pm

Once for test just fit a netgear switch in between. Port flap completely disappeared. Not a single flap in weeks. Removed it again and the flaps where just back....

I was thinking about this and I will try to do it on one place (other one is problematic). At least I will know if the problem is on site of SXT (as I think) or other RB. I don't like to use unnecessary devices, but if it will help...

WirelessRudy · Tue Jun 05, 2012 11:25 pm

Well, as I wrote before, imho it is also more a notification issue from the ROS. Because none of my clients seem to notice anything happening. The call, browse, download etc. and even de ones that has many portflaps a day say their internet works like a charm. Even in asking they never seem to notice broken links so I left it.... have other things to do more urgent....

zervan · Tue Jun 05, 2012 11:52 pm

Yes, you are right. But it is a little bit worse in my situation: there are some real disconnections as well - I use Netwatch to check neighbour availability each 5 seconds and I can see that there are problems. I am confused about them - they are not always at the same time as link down problems, see attachments - Lukas (RB433) was offline for 12 minutes (and it reports that SXT was offline). So there are situations when link is up but end points cannot communicate

In fact, link down/up/down/up solved that problem. Do these problems have something in common? I don't know but I have to solve that.

rb-sxt-link-down.png

wolfeyes · Thu Jun 07, 2012 7:56 pm

well, that's indeed another example. I have a rb344 where one port is connected by a 60meters cable to a netgear wifi router. Several disconnects a day, at times many per hour.
Once for test just fit a netgear switch in between. Port flap completely disappeared. Not a single flap in weeks. Removed it again and the flaps where just back....

Same results. After putting a switch as an intermediate device between Omnitik and Groove port flapping resolved.
I can live with it until a new cable installed to utilize a none poe port of Omnitik.
(Described above as an alternative in similar thread)
It seems like a hw issue but of course I'm not sure.

honzam · Fri Jun 08, 2012 4:01 pm

Hello MT team.
We have problem with Mikrotik (rb411 and rb711) + ASUS router.
UTP cable is arbitrarily long + POE jack http://www.i4wifi.eu/EU-230V-powering-1 ... hparam=poe

There is still disconnect problem on eth cable.
Problem is with all series
http://www.asus.com/Networks/Wireless_Routers/RTN12LX/
and
http://www.asus.com/Networks/Wireless_Routers/RTN10E/

We tried different cable lengths, diferent POE injector and the problem still persists. ROS 5.17, firmware 2.38

Can you simulate it? Thanks

Fri Jun 08, 2012 4:11 pm

Hello MT team.
We have problem with Mikrotik (rb411 and rb711) + ASUS router.

What are power supply specs?
Does it happen without PoE injector?

honzam · Fri Jun 08, 2012 4:22 pm

Hello MT team.
We have problem with Mikrotik (rb411 and rb711) + ASUS router.
What are power supply specs?
Does it happen without PoE injector?

Power for routerboard is 18V 0,7A
Problem is only when is used POE injector. We try change POE for another pieces, but still disconnect.
The same POE with another router (WELL) works fine.

honzam · Tue Jun 12, 2012 11:44 pm

I have to contact support with this problem?

Wed Jun 13, 2012 9:20 am

honzam, I have done various tests with RB411 but I was not able to repeat port flapping.
Try to use shielded cable and PoE injector with metal shields around connectors. At least 2m cable should be used for PoE connection.

honzam · Wed Jun 13, 2012 10:47 am

honzam, I have done various tests with RB411 but I was not able to repeat port flapping.
Try to use shielded cable and PoE injector with metal shields around connectors. At least 2m cable should be used for PoE connection.

Hello. It is easily reproducible. Try this POE from manufacturer C&CC http://www.i4wifi.eu/EU-230V-powering-1 ... hparam=poe

and one from this ASUS http://www.asus.com/Networks/Wireless_Routers/RTN12LX/
http://www.asus.com/Networks/Wireless_Routers/RTN10E/

then it conect to rb411 or rb711. You can use any long UTP cable and the port will be flapping

Wed Jun 13, 2012 10:48 am

honzam, I have done various tests with RB411 but I was not able to repeat port flapping.
Try to use shielded cable and PoE injector with metal shields around connectors. At least 2m cable should be used for PoE connection.
Hello. It is easily reproducible. Try this POE from manufacturer C&CC http://www.i4wifi.eu/EU-230V-powering-1 ... hparam=poe

and one from this ASUS http://www.asus.com/Networks/Wireless_Routers/RTN12LX/
http://www.asus.com/Networks/Wireless_Routers/RTN10E/

then it conect to rb411 or rb711. You can use any long UTP cable and the port will be flapping

Could you please contact support directly, we would like to get from you 1:1 exact setup, including the cables and injectors.

honzam · Wed Jun 13, 2012 11:05 am

Thanks. I send it.

sup5 · Wed Jun 13, 2012 11:14 am

We found out that the PoE-Injectors included with the SXT were responsible for ethernet port flapping, too.

When we used shielded PoE-Injectors like these, the port flapping went away.

Most probably this was a grounding issue,
because the PoE injectors included with the SXT aren't grounded.

Wed Jun 13, 2012 11:20 am

Thanks for the update. Could you tell us what is the device on the other end of the injector? For example, from what honzam is writing, it looks like the Asus router is causing this.

nicholwee · Wed Jun 13, 2012 5:24 pm

Hi! I posted a new topic about weird instability of ethernet ports a while ago. It is the same problem as this. So far, it started when I declared a master port for ether2 for ether3-5. When I noticed it, I tried reverting back to my previous setup which was to bridge all ethernet ports and undeclare the master port. Reboot thrice after that.

Today is my 2nd day without the problem.

honzam · Wed Jun 13, 2012 9:03 pm

Hello. We found so the problem is NOT with routerboards !!!

Problem is with POE injector + new types of WIFI routers conected to routerboard (or any network card)

When we used shielded PoE-Injectors like these, the port flapping went away.

Yes, this is true. With these POE is no problem with ASUS and WELL routers.

I think so problem is not with schielding cables and injectors. I can simulete problem with short cables on table.
In my opinion is problem with this - POE injector have conected only 4wires and this is problem for NEW routers (ASUS, WELL)

POE which put sup5 have conected all 8 wires and there is no port flaping with this POE https://wirelessconnect.eu/images/produ ... 7383_1.png
Mark

WirelessRudy · Thu Jun 14, 2012 2:18 am

I still have port flapping with routerboard that connects to other routerboard and gets power through the standard ivory MT powershot.

Basically most of my port flapping units are powered over this MT powershot. And several of these units are not connected to any router at all, just to a PC, or a laptop, or any other make router....

But I agree it might have something to do with grounding or how currents 'leak' over the cables and connectors.
Imho it is actually the ROS that reacts to little currents/freq and interpret it as a failure where actually the link is not disconnected. Clients don't notice the port flaps. (Or it doesn't happen when data flows...)

Thu Jun 14, 2012 7:53 am

WirelessRudy, Are you using PoE injectors? Try other ones and see if this changes something.

wirelesswaves · Thu Jun 14, 2012 10:56 am

Nomis..

That Tower site I have that I told you about, I have a row of RB411AH, they are all powered by 1 commercial supply with battery backup, ALL units use the power plug and NO poe adaptor in site.

So I wouldn't pay much attention to the claims made about poe adaptors. I still have the "port flap" between MT units without poe's.

Thu Jun 14, 2012 10:58 am

Nomis..

That Tower site I have that I told you about, I have a row of RB411AH, they are all powered by 1 commercial supply with battery backup, ALL units use the power plug and NO poe adaptor in site.

So I wouldn't pay much attention to the claims made about poe adaptors. I still have the "port flap" between MT units without poe's.

Can you replicate the same situation on your desk, with just two routers? If yes, we would be interested in getting such demo setup from you, contact support please. If not, maybe there is something in your tower site that causes this?

WirelessRudy · Thu Jun 14, 2012 1:53 pm

WirelessRudy, Are you using PoE injectors? Try other ones and see if this changes something.

Yes, they all use PoE injectors. And No, they are not only the MT ones. The ones of UBNT or the new ones delivered with the grooves etc. also have the issue.

But it is not like 100% of my units are suffering from it. I would say 30-40% have a port flap now and then, were some 10% have them more regurlarly, say a couple of times a day. And 1-2% of my units (250+ in total) have it at a severe level. They at times produce port flaps every so many secons, hundreds of times a day.

I already informed in this forum months ago that 90% of ALL my port flaps happen during daytime hours. Over night it is a very rare event.
Hence my opinion it has something to do with statical electricity discharge over the utp cable that triggers the notification of the port status in ROS.
None of my clients complain about disconnects, not even the ones with the very severe port flap.

I don't know how the port status (up/down - 10/100/1000Mb) is being measured by the ROS but I do know data traffic and the power over the lines creates both electrical currents and thus electromagnetic fields that alternate with certain frequencies. It looks to me that certain frequencies or elecmag fields have an influence on the port status sensing software. I am not a technician but that is where I would start investigation.

I found several units that have the port flap issue also switching between the negotiated Ethernet speed. They sometimes switch to a lower speed and only over many minutes or hours they switch back to their higher speed.

I have to inform that none of my CPE antenna's are grounded and I don't use shielded cable or connectors.

In the end, the port flap in itself in not hampering my network performance. But it is very annoying since I have interface status reporting by e-mail enabled to see which client's interfaces are up or down. Some clients have occasional loss of connection due power cuts or otherwise. By looking in their interface status history I can sometimes see what a possible cause might be. But to be able to do so I have to run the log rule:

add action=remote disabled=no prefix="" topics=interface

and I also get the port flaps reported.
So I get a couple of hundreds of e-mail notification per day, only 1-5% is really needed, the rest is waist (=port flaps), but I can see which clients are most severely hampered by them.

zervan · Thu Jun 14, 2012 2:04 pm

I already informed in this forum months ago that 90% of ALL my port flaps happen during daytime hours. Over night it is a very rare event.

Interesting - from my point of view it happens mostly during sunny days, no matter what the temperature is. I don't have a disconnection for about a week - it is still cloudy and raining these days here.

nicholwee · Sat Jun 16, 2012 7:50 pm

Hi! One of my RB750GL is experiencing this issue also. Have tried reset to factory setting just to be sure my settings were not the culprit. I get timeouts every 4 or 6 successful pings.

Very weird as my RB450G experienced this for less than 48hours. Its been running smoothly since.

Update:
Tried setting speed to 10mbps. It is now working. Will update as soon as we change the current wiring.

tgrand · Sat Jun 16, 2012 8:51 pm

Has anyone with this problem simply tryed to recompress the pins on the cat5 connectors?
Have seen many a cable test good then not be able move current, and all the time having to do with loosed pins on the cat5 ends.

coffeecoco · Sun Jun 17, 2012 5:42 pm

I already informed in this forum months ago that 90% of ALL my port flaps happen during daytime hours. Over night it is a very rare event.
Interesting - from my point of view it happens mostly during sunny days, no matter what the temperature is. I don't have a disconnection for about a week - it is still cloudy and raining these days here.

Pattern!!
Also I want to know has ANYONE tried changing the capacitors on the board?

I understand that heat can make caps faulty unless ive been explained wrong

wirelesswaves · Thu Jul 12, 2012 2:57 pm

Any further news on this issues? 45 circumstances of port flap on one AP since 10.25 this morning. On one occasion the port flap was so repetitive that it triggered "netwatch" on a 5s timeout!!!

Gazza · Tue Jul 24, 2012 5:12 pm

So now that I have around 50 clients spread across 6 base stations with 3 Internet feeds using OSPF, with clients linking in using station-wds so I can use PPPoE servers on adjacent routers to my Internet feeds, I can say I have been monitoring the "port flaps" and can rule out some theories and also offer a possible short fix solution.

First off, from what I've read and from trying stuff myself, I can say that changing cables and ends is not a solution, although I would make sure you have ruled this out in the first step to diagnosing the problem. If you have multiple cables running up a tower to multiple RB's, then once taking care of your routing, swap the cables around to see if the problem moves to a different RB or follows it on the port. If it follows, it's the RB, if not, it's the cable and or connectors.

I have port flaps on clients and base stations, one base station port flap in particular seems to have been cured by turning off Auto-Negotiation and setting it to 10Mbps. This is from an RB750 at the base connected to a Sextant at the top using my own flavour of PoE injector.

I had tried swapping cables, ports and ends but it kept happening, now for the last 5 days the link has stayed up by forcing it to connect at 10Mbps. Fortunately I use this link only for monitoring part of my network. Although it can and will route all traffic from one of my Internet feeds through to another should the closest fail.

In this case I would say the problem is with the Sextant because the logs show it drops out for a second or 2, the port light on the RB750 also goes out, but the power stays up, so it's the Sextant that is reporting ether1 down.

While spending months monitoring this, I have deduced that when the link drops, OSPF goes into panic mode causing an OSPF storm across the network because this link is central in my network.

I have also noticed on a few occasions, that when I access this Sextant through the Dude, the link would fail either a few seconds just before, or just after I log in. Now, because this is a link into the centre of my network, my Dude would never be stable showing all links as up, I normally only use the ping and http services for clients and ping, router, mikrotik, telnet and dns services on my backhaul routers and when it's not stable I get orange everywhere.

In cases where the link would drop rapidly, OSPF would drop the adjacency and cause a storm across the network. To stop this from happening, I would disable the OSPF instance on the router showing the ether1 down log for a few, maybe 5 seconds, then enable it again and the descriptor would announce the link exchange state, so any wrong state messages would disappear and OSPF would return to normal.

All my connected routers are using OSPF and my clients are mainly holiday Villas where they remove the electric key card when leaving thus switching off the electric, so at all times of day, OSPF is being updated with clients connecting and disconnecting. This in itself does not cause an OSPF storm, by which I mean where many adjacent routers cycle through: invalid sequence, discarding packet, MD5 auth failed, exchange and 2-way to init or down states causing all connected routers to continually update adjacency status to the point the network becomes slow due to the amount of OSPF traffic.

FYI I am using a bridged network with RSTP enabled and when there's no backhaul problems, it works perfectly. I have been at a client trying to diagnose this very problem where they are connected in using an SXT connected to an indoor TP-Link and using PPPoE to dial in.

They connect to the first replied AC which is one hop from the Internet feed, so the routes go from client to PPPoE server (AC), to Internet. Now whenever the port flaps, because of the timing, the PPPoE session stays alive and does not cause interference or down time for the client.

If the port flaps successively, like 2 or 3 times within seconds of eachother, then OSPF announces the link as down, but the PPPoE session stays up so long as OSPF sorts itself out before the PPPoE session becomes stale. During this time the clients still has Internet connectivity.

To prove this client's cable and connections were fine, I pulled a 1GB FTP test file across the connection in around 20 minutes without it dropping once, then after returning home and checking the logs, it had dropped out twice in the 10 minutes after I left. There's no rhyme or reason to the port flap, except I believe it's a software initiated drop and doesn't seem to be related to hardware, power supplies or PoE injectors.

Possible causes:

PoE adapters/injectors
Power supplies
Interference
Cables
Connectors
ROS versions or firmware

In my opinion and testing none of these alter the port flap, it remains as random as it always is, although I would say that when lots of different traffic (Routing/UDP/TCP) is going across it, it is more likely to happen than at night for example when there's very little of any traffic. I even thought of temperature since at the moment we are having around 40-45 degrees C during the days, but still no pattern is emerging.

Possible solutions:

Run a 5 second script to search the logs and watch for the common messages denoting ether1 down and OSPF failure messages, then disable the OSPF instance for 5 seconds and re-enable it to make it autonomous for large networks where you can't monitor it 24/7.

Allow MikroTIK access to your most problematic router so they can check it while it's happening and perform whatever covert operations they want to find the cause. Supout etc.

MikroTIK guys, you need to understand there's a lot of posts on this problem, so you cannot bury your heads in the sand by asking us to recreate it so you can diagnose it, if we knew how to recreate it, then we'd know how to cure it.

Choose someone like WirelessRudy and gain access to one of his problem routers and monitor it yourselves. We spend enough time trying to run businesses and keep our networks running and our customers happy to then spend more time waiting for our network to fail just so you can try and fix it.

I am sure this is a software problem as already suggested and I think OSPF and possibly the ethernet negotiation scripts are "too sensitive" to small changes in electrical changes on the ports.

I'm a mechanic/engineer/software programmer/general dogs body by trade and I can do things with my hands better than most, but I can't be arsed to continue spending hours reading through pointless posts on this forum from people with exactly the same problem. You need to experience this for yourselves and the only way you can do that is spend time monitoring it yourselves.

I'm sure WirelessRudy can give you access to a router you may only need to monitor for an hour or 2 before it happens, so when it does, you can just update this forum thread with solutions not more questions or requests for more information.

I'm getting fed up with feeling like so many others have said before, a "beta-tester for your software".

Your products and software have become the lifeblood of many people on this forum, it is their livelihoods, a lot like me have spent all their money and time creating something based on your products, please re-pay that devotion to your products by devoting 2 hours to finally see what we are talking about and don't keep asking us to recreate it.

As a mechanic I used to have customers coming to me with a problem that wouldn't happen when they turned up at the garage, but I would then give them another car and use it for a day or two so it would happen when I was using it, this was sometimes the only way I could actually solve a problem, rather than telling them to come back if/when it happens it again.

WirelessRudy is right by creating this thread a whole year ago, but you are no closer to a fix. Please, I cannot keep wasting my time reading this forum in the hope problems have actually been fixed, I need to know that for each thread that is opened, a solution is given within a few posts, not 100's and you guys need to understand that with your help, a LOT OF NETWORKING GURUS using your products would be on your side and help you to iron out problems, maybe even offer to be beta-testers to help you push your product forward.

So from now on, I will only check this forum thread for a solution, IE, I will only look at the last post which should be the solution, not yet another customer complaining about your software or lack of commitment to fix it or another request for people to recreate it.

Gain access to a router that is doing it and monitor it until it happens, then fix it and post the solution.

Regards to you all,

Gary

Ivoshiee · Wed Jul 25, 2012 12:33 am

toni17 · Thu Jul 26, 2012 4:33 pm

We need a solution of port flapping , this problem is getting all my investments down. All day long i stay at my computer and looking for the port to flapp or 10Mbps . I'm stressed . A fast soluttion PLEASE

Ivoshiee · Fri Jul 27, 2012 12:21 am

We need a solution of port flapping , this problem is getting all my investments down. All day long i stay at my computer and looking for the port to flapp or 10Mbps . I'm stressed . A fast soluttion PLEASE

I amafraid that nothing will happen too soon. I've implemented multiple links and OSPF on affected systems, at the moment I can cope with that issue.

Aug · Fri Jul 27, 2012 5:17 am

Not affecting me anywhere, but will put in my input as it may help.
All my AP's and backhauls are RB411AH or RB433AH. (about 50 total) Running UTP cable from POE-24i or directly from battery to variety of dumb switches, trendnet, cisco, maybe even a d-link.
Routes are all static. No RIP or OSPF.
Clients are a variety of RB411, Ubuquiti Bullets, Tranzeo, and smartBridge(omg).
ROS versions range from 3.28 to 5.18

routerboarda · Fri Jul 27, 2012 9:50 am

Hi,
i can see port flapping on my new RB2011L (v5.19 Fw2.41) one port connected with an 3m Cat6 Cable to an APC(Network)PowerDistributer going up and down every few seconds for hours.

regards

stmx38 · Wed Aug 01, 2012 4:13 pm

My precedent post
We changed our old Cisco Switch to new one - Dell Power Connect 2724
And ...

honzam · Wed Aug 01, 2012 5:10 pm

My precedent post
We changed our old Cisco Switch to new one - Dell Power Connect 2724
And ...

Before, with Cisco no problem?

stmx38 · Wed Aug 01, 2012 5:11 pm

Sorry for mistake
Good ports:
eth3 - Dell is on
eth2 - HP Printer

Flapping ports:
eth4 - Cisco IP Phone SPA303
eth5 - Cisco IP Phone SPA504G

stmx38 · Wed Aug 01, 2012 5:14 pm

Before, with Cisco no problem?

My precedent post is about issue with Cisco.
But now I can't say anything about old port connection plan.
Now I see the issue with 2 Cisco IP Phone.

ohara · Wed Aug 01, 2012 10:13 pm

As soon as I connect Host3 to RB751G eth1 on RB433 starts flapping several times a day - weird.

EDIT: even if Host3 is turned off, but power cord remains plugged in I see port flapping on RB433. Only if I unplug the lan cable from Host3 there is completely no port flapping on the RB433 - unbelievable but true.

WirelessRudy · Thu Aug 02, 2012 2:02 am

Not affecting me anywhere, but will put in my input as it may help.
All my AP's and backhauls are RB411AH or RB433AH. (about 50 total) Running UTP cable from POE-24i or directly from battery to variety of dumb switches, trendnet, cisco, maybe even a d-link.
Routes are all static. No RIP or OSPF.
Clients are a variety of RB411, Ubuquiti Bullets, Tranzeo, and smartBridge(omg).
ROS versions range from 3.28 to 5.18

Have you set "/system logging" on for the topic "interface"? Its not by default and if not you will see no notification of the port flap.

My network is similar as yours although my clients are mainly routerboards.

Aug · Thu Aug 02, 2012 4:00 am

@WirelessRudy

Have you set "/system logging" on for the topic "interface"? Its not by default and if not you will see no notification of the port flap.

No, I didn't.
Guess that was why it didn't bother me.

Now I'm going to have to set it and have a look.

pljubas · Thu Aug 30, 2012 9:39 am

This is just to join group with eth port flap problem...

I have it present at three different setups:
1. RB433L and SXT: 10-20 times a day, mostly during the day, SXT is incoming link and when eth flaps, 433L is not reachable, flap lasts for couple of seconds. Connected with less than 2m cat6 utp with just poe for sxt in-between
2. RB433L and SXT: similar occuarance, mostly during the day, SXT is incoming link and when eth flaps, 433L is not reachable, flap lasts for couple of seconds. Connected with less than 2m cat6 utp with just poe for sxt in-between
3. RB433 and Omnitik: this one is more severe, 50+times a day, flap last for even few hours... OmniTik is sending out to clients, and, unfortunately, no link to them during flap...

At the same time, I have 6 other setups that work flawlessly:
1-2. RB433 and Omnitik, not a single flap in 4 months
3. RB433 and SXT, not a single flap in 4 months
4-5-6. RB433 and RB411AR, all ok

All RB devices with 5.19 ROS, and 2.41 FW.

The worst thing is that they are 300+ km away from me.

I can only suspect on PoE.

Best regards to all...

pljubas · Tue Sep 11, 2012 2:32 pm

RESOLVED!

I've changed PoE at three locations, not a single flap in 3 days...

Best regards, Petar

NetworkPro · Mon Oct 08, 2012 10:22 am

I didnt read 100% of this thread but do you guys protect the port from interference on the frequencies Ethernet and GigabitEthernet operate on?

I would not expect stable behaviour unless shielded cable is used (may not be grounded I think not to create a path for any lightning) as well as the board itself in a metal box that is grounded...

On towers people use fiber as best practice.

WirelessRudy · Mon Oct 08, 2012 11:35 am

I didnt read 100% of this thread but do you guys protect the port from interference on the frequencies Ethernet and GigabitEthernet operate on?

I would not expect stable behaviour unless shielded cable is used (may not be grounded I think not to create a path for any lightning) as well as the board itself in a metal box that is grounded...

On towers people use fiber as best practice.

The issue is that on older ROS versions this 'port flap' never existed. Even if the software was not able to detect it, such kind of problem started to arise after version 4.xx software.
And in 80% the cases its virtual problem anyway since the software detects it but the client doesn't notice it at all.

I found in the last years the Ethernet ports are the Achilles anyway of the routerboard product line. I hardly have issue with routerboards but when we do, its 95% because the Ethernet port stops working, or becomes very 'flappy'. I have brand new boards that after the first initial boot become completely inaccessible because the Ethernet port dies. Send some boards back for RMA and some were fixed and some just replaced.

But I do agree that shielding cables might work better. But only if the plugs also are shielded and since 95% of my routerboards don't have earthed ethernet leads (from board to casing) this is going a bit of an issue to achieve. And I also fear that such setup might draw lightning strikes towards the CPE's so I am not sure....
On overall we have 10% of the boards replaced on a yearly base and the plain replacement works out cheaper than to upgrade my whole network.
Off course are all the replacements done by new rb711's or Groove and they seem to have less issues with 'port flapping'.

Regarding 'fibre' in the towers, I haven't seen anyone doing such in my country. Most providers use ubnt or MT and they have ample stuff to work with fibre. But than again, Spain is on more fields not the most enhanced country in the world!

NetworkPro · Mon Oct 08, 2012 11:54 am

Interference may come from, let's say - someone testing new digital TV transmitter - and can cause discrepancy of the Ethernet such that lower level software decides to flap the port.

It was not noticed before because for example that lower level code may be just dropping frames rather than flapping the port (if such code exists in software at all in this case, I haven't asked. I assume because someone mentioned they upgraded firmware to solve such flaps.)

Shielded cable may not be grounded and may have non-shielded plugs - it should still protect sufficiently- I was led to believe by someone from the industry long ago.

If you use fibre - that is an expensive upgrade of existing stuff. It should be cheaper than copper for new installs nowadays if you have trained guys that can work with it properly. There is this company in Sofia called Eurolan they can supply fibre stuff including nice gigabit SFPs for RB2011.

And if a port becomes damaged in some way - I replace the RouterBOARD - I had this happen ONCE.

It is hard for MikroTik to "own" this issue "until resolved" because suppliers own hardware issues and installers own shielding issues.

lyxnafis · Mon Oct 08, 2012 2:05 pm

As I posted to another thread, teamspeak triggered the eth problem on my case...

NetworkPro · Mon Oct 08, 2012 2:10 pm

lol I do not believe - an application triggering port flap ?

Can you reproduce it every time to be sure that the app causes it? (With its specific packets probably)

lyxnafis · Mon Oct 08, 2012 2:46 pm

lol for sure but, I'm not going to try reproducing the problem cause is very fckng annoying.
Fact is that I never had the problem' it appeared when teamspeak 3 was installed and disappeared after uninstalling....
coincidence? maybe...
No time to go deeper but, what happens if teamspeak, while streaming, produces RTP packets that exceed MTU?
can RB handle?

NetworkPro · Mon Oct 08, 2012 3:28 pm

Nice one. I have to test this and sniff it to be able to know for sure.

I have faith in MikroTik such that such silly problem should not f. with the RouterBOARD.

jonmansey · Thu Oct 11, 2012 8:09 pm

I big "me too" on this. ethernet port problems are killing my business reputation for reliable service. and a big +1 to previous poster Gazza. This along with the wlans stopping randomly, its seriously making me doubt if mikrotik kit is "carrier grade" any more, or is it just cheap home electronics that needs to be turned off and on again when it stops working. do i need to be looking at ubiqiti?

here are my findings
Ethernet ports just quit
ethernet ports go in to a hard looped-back mode where every packet that goes out comes right back in.
ethernet ports will only negotiate 10bT full when the other end device is 100bt capable
cables replaced, connectors re-crimped, POEs replaced, no change
the issue was never a problem before something like the middle of v4's life
affects all types of RB, powerpc or mipsbe, 1000, 1100, 433, 450G, 711, 751
as wirelessrudy noted, flapping gets worse when its windy

its hard to reproduce on the bench yes, but from the number of people affected, hard to deny there is a real issue here.

NetworkPro · Thu Oct 11, 2012 9:02 pm

I read page 1 and 3 of this thread.

I had most port flaps and issues in my experience due to RJ45 plug being smaller than the port or the port being too deep for the plug to have 100% contact every time. Such patch cables I destroyed fully and chucked in the bin. I never bought cheap patch cables and RJ45 plugs anymore.

In my life I have recrimped (or re-pressed alredy crimped plug) almost every hand-crimped cable I or someone else crimped because the cheap RJ45 plugs just fall apart, stop working due to a reasone that is hidden to the eye.

Some times I replace the device(s) on both sides of cable and the problem goes away.

Sometimes I replaced the cable!

Did you guys replace the devices or the cable itself already !?

You should be able to pin this down to a single component.

P.S. you see thins on RouterBOARDs because RouterBOARDs now after v5 TELL YOU ABOUT it unlike most other devices in the network

The problem may have been there all along.

P.S. 2 I read page 2 - Normis said same thing about replacing devices on one or both ends.

WirelessRudy · Fri Oct 12, 2012 12:16 am

Imho it has to do with the ethernet ports of the boards coming out since about a year or too AND with indeed halfway software v.4.xx family.

The latter is simple to explain, before the ROS simply did not even have a notification option for failing ports.... so than it looks like it didn't exist.

My experiences:
- Ethernet ports are 75% reason for failing routerboards. Some fail right out of the box first time boot.... some even beyond repaid. Some after a reset were able to use.
- Has several occasion that CPE running for years suddenly lost their Ethernet port. In different levels. Some boards just lost IP connectivity, but where still able to communicate on mac level. (Special older boards like 133C3 boards). Some boards were visible in 'neighbor' but now way connecting to them either by mac or IP level. Sometimes a board even manages to get a ip query from a client PC solved but become unreachable after that.
- ALL new rb711 series boards I have I can only boot up the first time when I disconnect the utp cable between the power-shot and the switch. I used to works like that for years but now a new rb711 just won't boot if it is having a LAN connection to a Ethernet device (laptop, switch) Only immediately after I disconnect the cable from a Ethernet connected device the boards boots. After the first initial boot I have no more problems booting. This happens ONLY on rb711 boards.
- After some thunderstorms lately I had a bunch of boards that lost all Ethernet connectivity. 2 out of 4 were brought back to live only after a full hardware reset. The other two are lying in my bin now, they boot, radio works but Ethernetport is completely out of use. No netinstall nothing....
- Recently found also some boards unable to access by the port when fit on a mast with high ESD (all fully grounded, board, radio, ports etc.). Back on my desk they work fine. Groove in same place has no problem whatsoever.
- Had a cpe working for years fine, suddenly developed a severe port flap. Changed connectors, power shot, power adapter, nothing. Upgraded some ros versions, downgraded etc. changed all kinds of settings, auto negotiate, manual, 10mb, 100mb. still the same. Best results with 10mb though but it still happened. Finally took another CPE and put it on the same cable and adapter etc. and problem is gone, Failing cpe in my house on a 'test' stand (aimed at some remote tower) and not a single port flap anymore....!

My conclusion is as it has been in the past. The hardware/software of the Ethernet ports on rb's are poorly designed, weak, cheap or whatsoever.

If I am to leave MT as my home provider of devices than its the Ethernet port driving me to it. (But to change my whole network now into the bloody ubnt crap..... that's anther story...)

NetworkPro · Fri Oct 12, 2012 7:03 am

The described flapping is rare so that hardware Quality Assurance did not even think of doing such test or they can't even reproduce such harsh environment to do such test.

So the statement "poorly designed/cheap" is not one I would use because this problem exists on the competition's ~20-times the price boxes.

Let's think again what's the difference between the place where the described board had flapping and your home. For example the device on the other end of the cable and its port.

djdrastic · Fri Oct 12, 2012 11:30 am

While I really respect you NetworkPro for the quality information you have published both on these forums and on the MTK Wiki , I have to agree with Rudy as I've seen the exact same things as well.I do think some of the flapping port issues , like some have noted do not affect connectivity at all and I would guess it's a software related issue that incorrectly detects the link as down.

In fact a couple of years ago we saw the exact same thing but with Netgear ADSL Routers namely the ports would eventually not continue to work unless you forced the connection at 10Mbps Half Duplex Mode.After months and months of fighting with Netgear they figured out that due to bad ventilation and cooling in their housings , the ethernet ports would themselves get damaged from overheating while placed horizontally and not vertically on their supplied stands.If you turned off the router for a long time and switched it on it would initially autoneg at 100 and as the router would heat up ports would flap like crazy until no connectivity was available.

Wireless to the routers still worked flawlessly as well as the DSL Port worked perfectly.

NetworkPro · Fri Oct 12, 2012 12:00 pm

Thank you.

I trust MikroTik have their up/down detection right.

Netgear example is hardware issue.

Good post still every case is specific.

I can agree that if you put electronic components in a plastic sealed box and overheat them (in the sun included) then anything on the PCB may become damaged.

Regards.

lyxnafis · Tue Oct 16, 2012 11:20 am

Update:
It looks like Teamspeak as well as some other traffic were just triggering the port flap.
The problem was firmware 2.29 that I had so far.
Took the router down replaced old 560 μF capacitors with new 680μF and updated to firmware 2.41.
Note that I took the risk of updating to RB411's 2.41 while routerboard site for my RB411A provides firmware v 2.20.
At troubleshooting and frustration time I, also, noticed that ethernet flapping was synced with wireless interface L2 MTU that was going from 2290 to 1500 and back.
I think Mikrotik should stay away from Microsoft's tactics of everyday updating and release only after extensive and thorough testing.

NetworkPro · Tue Oct 16, 2012 11:31 am

So after you did this you do not have more port-flap?

Please do a sniff of the traffic that you believe might have caused an issue and send it to support. Thank you.

loginsistemas · Wed Mar 06, 2013 12:54 am

Hi all.

No news for this issue?

I have serious trouble with it.

honzam · Wed Mar 06, 2013 9:39 am

Hi all.

No news for this issue?

I have serious trouble with it.

What devices, what routerOS? What type of cable and lenght?

NetworkPro · Wed Mar 06, 2013 9:52 am

topic is exhausted - replace things

Ivoshiee · Wed Mar 06, 2013 9:55 pm

topic is exhausted - replace things

?

WirelessRudy · Thu Mar 07, 2013 12:40 am

topic is exhausted - replace things
?

I agree.

It's still around, just had a rb333 with v5.24 having a mountain of port drops (real ones). I didn't know what to do with it so decided to just install de software one more time. (5.24 over 5.24) and see, since than not had one flap yet.... 18 hours now.....

I still see it around everywhere in my network. So the issue still exists, and like I've said before, it probably has something to do with the drivers or the monitoring of the the ethernet port status.

The Ethernet ports are the achillesheel of rb's anyway, if something goes broke it is usual the ethernet port......
(Units running for years suddenly after a simple reboot lost their ethernetport... some brandew units lots them too just after the first initital change in the config.....)

So, the topic is "exhausted" in a way that no derfinite solution has seen the light yet....

NetworkPro · Thu Mar 07, 2013 6:58 am

What solution? You want to replace components on the PCB now?

Ubnt had the tough cable + plugs I think for similar reasons.

So your question is - how to measure, to be sure that the reason is outside the RB such as electrical?

WirelessRudy · Thu Mar 07, 2013 7:06 pm

I don't know! I am not a technician nor a board designer.
Start with it would be nice MT would acknowledge the problem, which so far they've never done because they "can't reproduce it".

The fact is simple, under 3.x family and before the issue didn't exist and/or on old boards it hardly exists.
I still have rb112's and 133c's in my network and they hardly ever fail the ether ports. Its special the 4xx series that have the problems and I've had a couple groove's with failing ethernet port.

The port flap comes in different flavours. Most I call "virtual" because although I see them in the log, the client never seems to notice them. Traffic just flows.

Recently I came across a chap that plays with electronics for a hobby and showed him some boards with failed ethernet. He straight away could see that the used cheap 'capacitors' (?) were blown and replaced them by some better quality ones. Board works fine after that.

So, how come these capacitors blow? Sometimes just in the middle of doing its work (transporting data) after months, or years of no problem?

I see what I see (and I'm not the only one!),don't ask me to solve it. MT should do.....

But in reality I learned to live with it. Port flapping exists. I just ignore it and when the client complains I change the unit (not the cable etc.) and the problem dissapears....
Problematic unit is used somewhere else and mostly also without problems any longer. Weird but a fact....

NetworkPro · Thu Mar 07, 2013 9:07 pm

OK sounds good.

There may be packet-loss when it happens, are you testing by pinging with a fast ping (decreased "timeout" value) ?

WirelessRudy · Fri Mar 08, 2013 1:19 am

OK sounds good.

There may be packet-loss when it happens, are you testing by pinging with a fast ping (decreased "timeout" value) ?

That's actually a good suggestion!

Never thought about that. All I did is run a standard 1sec ping and watch the log. But like I said, it hasn't had my attention lately.
That rb333 on the other hand, still shows not a single drop, almost 48 hours now..
Just a simple remote re-install of the software packages..... ..

Requium · Fri Mar 08, 2013 4:07 am

We have the same problem here on Bolivia with SXT and 411, i tried to connect them to an omnitik on a 45m tower but start to flap the ethernet ports so i decided to test them on my office, i have test the connection from 411 to eth2 of the omnitik and from SXT-G to eth3 omnitik, and they worked like 12h, so i decided to test them on the tower, we build a enegy box (We used a shielded cable 12 AWG with grounding kit to deliver AC to the top of the tower because we tought that the problem was energy), so before we tried to get it up, we tried the cable for AC and the stability of the ports, They all work for 2h!, so we were decided, we lift the cable up, the equipment, and do the installation, when we plug it up, port flapping started

, so we have an idea, replacing the omnitik switching ports with a TP-Link switch, i saw the port flapping stoped from the omnitik to the switch (100M connection link), the problem was on the SXT and the 411, they still are doing port flapping :/ (Tested with ping), so tomorrow we are trying to change the UTP cable used to connect the omnitik to the SXT and the 411 with an STP certificated cable, the only variable that i couldnt simulate on the office was maybe the noise from the other cables (Feeders) from FM and AM equipments on the tower, or any AC cable that its generating a electromagnetic field affecting the UTP.

Conclussion: Doing the test on a Lab, they work great, doing the connection on the outdoor it start to fail :/, so we are plenty sure that is not a problem from mikrotik, we are working too to find where is the variable affecting the ethernet ports.

If you have any suggestions to test them, they are welcome.

Sorry for my english.

BR
Requium

NetworkPro · Fri Mar 08, 2013 5:30 am

Decent explanation.

When doing such things, you do realize that shielding would create a path to ground that you have to manage, right?

Any "dirty" electrical currents that travel through that should not be let to interfere with the Ethernet stuff - usually this means - managing to NOT create that path to ground

Not letting the current flow through what you just added to the tower.

(please do not electrocute someone or some equipment, take it easy and safe)

lambert · Fri Mar 08, 2013 7:23 am

so we have an idea, replacing the omnitik switching ports with a TP-Link switch, i saw the port flapping stoped from the omnitik to the switch (100M connection link),

So the SXT, 411, omnitik, and TP-Link is at the top of the tower? How long is the cable between the omnitik and the TP-Link?

the problem was on the SXT and the 411, they still are doing port flapping :/ (Tested with ping), so tomorrow we are trying to change the UTP cable used to connect the omnitik to the SXT and the 411 with an STP certificated cable, the only variable that i couldnt simulate on the office was maybe the noise from the other cables (Feeders) from FM and AM equipments on the tower, or any AC cable that its generating a electromagnetic field affecting the UTP.

On a commercial broadcast tower, every ethernet cable needs to be shielded, the shield grounded, and of a length which is not a harmonic of the broadcast frequency. You are likely dealing with induced RF on the ethernet cables. Ferrite beads on the ethernet cables might be helpful. There is a school of thought which says you only want to ground the shield at one end to avoid creating a ground loop. But that may only apply on long runs. Getting ethernet right on a broadcast tower can be challenging.

wolfeyes · Fri Mar 08, 2013 11:10 am

Some notes/conclusions regarding port flapping experience. By all means networks and other implementations have their own peculiarities but let me quote on what noticed here so far:

a) Port flapping is very annoying and cause ospf states changing between neighbors whenever occurs, affecting network traffic.

b) Many devices tested so far, RB750, RB751, RB450G, RB1100AH, RB433, RB433AH, RB711, SXT, SXT HP, Sextant, Omnitik & Groove.

Problem occurs only for Omnitik & Groove devices or to any other device connected to them.
i.e. Individual 433 (connected to any other device) never faces any problem but 433 with a connected groove or omnitik suffers from port flapping.

c) It's no matter of elder devices or capacitors. Even a brand new 433 connected to a groove produce port flapping.

Lately had a significant progress after replacing a plain utp cable connecting a RB433UAH to Groove with shielded FTP.
With the old utp cable port flapping occurred at least once per day and for an interval of 1-2 hours (complete mesh).
Now after cable replacement followed by the appropriate grounding port flapping has been disappeared for a month now!

OK, I know many will claim that even they have already changed plain utp with shielded, they still face the problem.
In my case worked.
BUT! I cross fingers to do so, because port flapping occurred unexpectedly 8 months after this new implementation was fresh installed.

I believe it's quite early to have a settled conclusion.

Finally for omnitik, a good technique which produced great results is to isolate eth1 poe port just used for supplying power to the device, whilst data passed from any other none poe port.

Requium · Fri Mar 08, 2013 3:04 pm

so we have an idea, replacing the omnitik switching ports with a TP-Link switch, i saw the port flapping stoped from the omnitik to the switch (100M connection link),
So the SXT, 411, omnitik, and TP-Link is at the top of the tower? How long is the cable between the omnitik and the TP-Link?

the problem was on the SXT and the 411, they still are doing port flapping :/ (Tested with ping), so tomorrow we are trying to change the UTP cable used to connect the omnitik to the SXT and the 411 with an STP certificated cable, the only variable that i couldnt simulate on the office was maybe the noise from the other cables (Feeders) from FM and AM equipments on the tower, or any AC cable that its generating a electromagnetic field affecting the UTP.
On a commercial broadcast tower, every ethernet cable needs to be shielded, the shield grounded, and of a length which is not a harmonic of the broadcast frequency. You are likely dealing with induced RF on the ethernet cables. Ferrite beads on the ethernet cables might be helpful. There is a school of thought which says you only want to ground the shield at one end to avoid creating a ground loop. But that may only apply on long runs. Getting ethernet right on a broadcast tower can be challenging.

About the lenght of the switch to the 411 and SXT are 2 meters, to the omnitik is 1 meter.

About the tower, yeah i realise that, but the strange thing is that i have a 45 meters UTP cable connected to the omnitik ethernet port 2 for Testing LAN from the floor and it doesnt flap, it has 100M link and its passing around Feeders and AC and DC cables from others equipments, strange? yeah i think so too.

Like i said, the problem appears on the SXT and the 411, the omnitik is healthy connected to the switch, who is creating the port flapping is the 411 and the SXT :/ dunno why, i will try the STP solution on the 411 and SXT and post the results.

BR
Requium

wirelesswaves · Fri Mar 08, 2013 7:22 pm

May have just stumbled on the problem.

I have 2 rb433ah on same tower... Their ports Ether2 are interconnected with 1M of cable (externally)

However, both units are supplied by POE injectors across ports Ether1.

Both POE injector devices, LAN's are not used..

Over the last week the Port flap at this site has become worse, until today the situation became dire.. The ports were down for periods of up to 2min at a time..

I was connected via one of the WLAN, so was able to watch the port disconnecting infront of my eyes. The site owner is an IT engineer and was at home... I called him and asked if he had a spare ethernet cable.. He wwent to the cabinet and connected across both th eLAN ports on the POE injectors.

I moved the IP addresses of each unit from ether2 across to ether1 and all port problems went away.

The other day I happened to take a look at a badly crimped RJ45 connector that I had made off under a looking glass.. I was concerned over pin8, the machine wasnt crimping properly.

At the same time I spotted that the new plug and its metal fingers looked aged.. And underneath the magnifier I could see that the finger surfaces looked pitted.

Here read this. http://rj45s.com/Gold_Plating_Problems.html

And now I am wondering if the cheap 12cent RJ45 connectors may have been one of those bad cheap imports, with minimal or even NO plating.

Anyone know of a distributor in Europe that can guarantee high quality connectors.

NetworkPro · Fri Mar 08, 2013 7:42 pm

http://www.rdm.com/en/co/products/produ ... logie.aspx

WirelessRudy · Sat Mar 09, 2013 1:30 am

Who said this topic was 'exhausted'?

WirelessRudy · Sat Mar 09, 2013 1:49 am

So, when we start looking at the connectors... what about the quality of the interfaces used?
I'll bet each manufacturer here also squezes the total cost of production, probably resulting in low, or none-standard plated interfaces? Who tells? Does MT has any specs for these?

I always felt that the Ethernet RJ-45 (and probably its brothers and sisters too) are the achillesheel of each network instalation. 90% of the problems we have are these connectors. They become corroded, dirty of let loose of the cables and the process of fitting them needs a skill and is at best annoying... (and look at your fingers after a day of splicing, stretching and fitting these tiny little bastards into their plugs...)

Some I know glue the connectors into the interface.
We sometimes tape them in.
In many instalations the power shots for the client CPE are lying on the floor in the dirt and are moved around every household sweep. Actually I am surpriced most the the connections actually keep working.....

Yes, you can do a high quality install with the best equipments you can find and fit boxes on the wall shielded from dust and water. But since the 'war on getting the client' is basically fought on price level, most providers will look for an quick and easy as possible solution. The problems arise later when the client already made several payments....

I think the whole RJ-45 concept is a poor one. The problem with a widely accepted and used standard is that no one will be tempted to put another, better thus deerer, system in the market....

Requium · Sat Mar 09, 2013 3:55 pm

Well, the results with an STP cable were the same :/, port flaping, so we tried to connect another omnitik to the omnitik (port 2 to all ports of the other omnitik), it works on all ports with 100 Mbps, so its a problem with the SXT an 411, the strange thing that i dont test it on the site is to connect the SXT or the 411 to the port 1 "poe", we have 2 sites with Omnitik and SXT connected to port 1 without port flapping :/, so getting this to the problem its like a problem with the switch connection or the ports that work with the switch, port 2 3 4 and 5, dunno why it fail at 45m height with 1 port equipment (SXT and 411).

I will try to test the ethernet options :/ with MDIX, but i think that is more hardware than software :/,

PD: Flaping stoped changing both ethernet speed to 10M and disabling auto-negotiation, :/ doing bw-test doesnt even get 10M, at 9.5Mbps its start to disconnect, at least now i can enter to the 411G.

PD2: Noticed that both equipments gygabit ethernet has the problem, i will try to replace them with 100mbit equipments :/ .

BR
Requium

NetworkPro · Sat Mar 09, 2013 7:07 pm

Sorry I am unsubscribing from this topic. Good luck to all.

Requium · Sun Mar 10, 2013 10:21 am

Doing some tests,the results on my case is noise, 00:16:00 Am the port stop flapping and start to traffic 100Mb until now 04:16:00 am, doing a bandwidth test is a 100Mbps Full duplex on UDP, so maybe its an RF noise to the cable or connector:/ FM transmissions ended at 00:00:00 on the tower, same time when port started to react, so the solution maybe is getting a better shielded cable or maybe try to replace ethernet connector on 411G.

some bibliography for those who maybe have the same port flapping problem
http://sewelldirect.com/articles/utp-vs-stp-cable.aspx
BR
Requium

wolfeyes · Mon Apr 29, 2013 3:31 pm

Some notes/conclusions regarding port flapping experience. By all means networks and other implementations have their own peculiarities but let me quote on what noticed here so far:

a) Port flapping is very annoying and cause ospf states changing between neighbors whenever occurs, affecting network traffic.

b) Many devices tested so far, RB750, RB751, RB450G, RB1100AH, RB433, RB433AH, RB711, SXT, SXT HP, Sextant, Omnitik & Groove.

Problem occurs only for Omnitik & Groove devices or to any other device connected to them.
i.e. Individual 433 (connected to any other device) never faces any problem but 433 with a connected groove or omnitik suffers from port flapping.

c) It's no matter of elder devices or capacitors. Even a brand new 433 connected to a groove produce port flapping.

Lately had a significant progress after replacing a plain utp cable connecting a RB433UAH to Groove with shielded FTP.
With the old utp cable port flapping occurred at least once per day and for an interval of 1-2 hours (complete mesh).
Now after cable replacement followed by the appropriate grounding port flapping has been disappeared for a month now!

OK, I know many will claim that even they have already changed plain utp with shielded, they still face the problem.
In my case worked.
BUT! I cross fingers to do so, because port flapping occurred unexpectedly 8 months after this new implementation was fresh installed.
I believe it's quite early to have a settled conclusion.

Finally for omnitik, a good technique which produced great results is to isolate eth1 poe port just used for supplying power to the device, whilst data passed from any other none poe port.

As expected.... too good to be true. After replacing plain utp with shielded, we had a period with stabilization.
However latest 15 days, port flapping is back again.
What again noticed is that Grooves and Omnitik are the usual suspects.
It's too bizarre, it's too annoying.....

kraker · Fri May 03, 2013 8:32 pm

We already ground everything at one of our tower but still have port flap issue.cables cat6 sftp good connectors good wires for grounding... every points are checked at two times.rb1100ah ports goes to 100mb every 10 minutes....

tgcnet · Wed May 15, 2013 4:58 am

I have same problem here 4 rbs in production any cables with a maximum of 2 meters, power supply 24v 1 amp each, all in straight power connector DC, and yet several link down link up during the day and night. rbs two 750, one 450 and one rb rb 450g anbos with the same problem .. : (Any solution?? :/

Ivoshiee · Wed May 15, 2013 9:03 am

I have same problem here 4 rbs in production any cables with a maximum of 2 meters, power supply 24v 1 amp each, all in straight power connector DC, and yet several link down link up during the day and night. rbs two 750, one 450 and one rb rb 450g anbos with the same problem .. : (Any solution?? :/

I see this issue daily and it is affecting my network. Only time will tell if the MT will address that (to their non-existent) issue. One way is to migrate away from the MT-MT equipment combinations and have the MT-other_vendor-MT setup instead, but it is just an hack - the fixing must be done at the MT side.

coffeecoco · Wed May 15, 2013 10:50 am

I think this is a weakness in poor capacitors chineese capacitors are not very tolerant

I dare one of u who face this issue replace the caps with quality ones on the board its harmless

5 bucks says im onto something here

tgcnet · Thu May 16, 2013 8:04 pm

image :/

TonyJr · Mon Jun 10, 2013 3:22 pm

Had ether1 on my RB493G start doing this on Friday. Power is supplied by a POE switch via ubiquiti instant 802.3af outdoor adapter to ether1.

I installed a second wifi card to the 493G Thursday evening, so this could be the cause of the problem.

Anyway to cut a long story short, I managed to solve the problem by turning off auto-negotiate port speed/duplex on both the RB and switch. Forced it to 100 Full Duplex and no more flapping occurs.

Hopefully this will help someone else if they have the same problem.

randallr · Tue Jul 16, 2013 9:10 pm

I've been fighting ethernet issues for more than a year. I've got tons of 750's at towers, bridged. The problem I see is a port will drop to 10mbps. I can turn auto-neg off/on and it comes back up at 100, and runs fine. In fact, I put a script in every one to check every hour, and if it's rate is 10, then reset the auto-neg.,
At first, I thought it was CAT5 problems, so I'd go replace it. Many were unshielded and was replaced with shielded. It really seems like it would get worse.
A month ago, I had a customer with redundant BH's (411AH), connected to a 750 running RSTP. It seemed like when the wind would blow, the ports would keep dropping to 10mbps. I went and ran 2 new runs of CAT5, and 2 new BH's(metal5). All 4 ports would then start doing it randomly, but almost always on windy days for sure.
A couple of weeks ago, the 750 died, and the customer stuck a generic switch in it's place. All 4 BH's have remained stable since.
My theory is perhaps it's voltage. This particular site is running on 27vdc. On some of our towers, I've moved the 750's to 13.5vdc, and it seems to be much better.
Could voltage closer to the 750's limit be the problem?

welan · Sat Jul 27, 2013 12:35 pm

Same issue here. Up, down, up down. Very annoyed. I have only good memories of 3.30, then just troubleshooting.