Server ccr 1036 works well
And a number in bridge hosts
As in the picture
Suddenly a large drop in the number happens
As in the picture
the problem that occur lead to a substantial drop in speed for a period not exceeding 30 seconds.
Then things get back to normal and back to figure out the height and speed to what it was
As in the picture
The problem is repeated often during the day and lead to bad performance of the network
Server type ccr 1036 works with dma radius
Hi Hazardsy
First a quick note, something like this may get better / quicker support if posted in another section (unless its specifically an issue with the current RC etc)
Can you take a look on the bridge tab (in the bridge window) and check the protocol column:
- If it is set to none then feel free to move on to the next part
- If it is set to STP or RSTP (the default for new bridges) you issue may relate to receiving STP BPDU’s on the port leading to the table being flushed and everything having to flood the interface / perform discovery again
Next, if you could explain a little more what your bridge is doing / used for that would be really useful to help look further. You mentioned RADIUS which makes me think authentication (PPP or otherwise) can help understand the traffic expected and not expected on the port. Also including software version, routerboot version, what packages are installed etc can help immensely.
Also sometimes things like either BPDU’s or timeouts aren’t considered as errors or warnings but normal parts of the system working as expected. It is always a good idea to check the log however at the time this happens to see if anything is logged. Also sometimes adding a specific topic to logging can help immensely, in this case maybe not so helpful as I can’t see topics for STP or Bridge.
Regards
Alexander
verison of server 6.30.4
also i have a problem in verison 6.36 and 6.37 I try every verison
Do you have the Remote Desktop Connection by one of the following programs :
team viewr or any desk
Hi Mate
Do you really need RSTP on this system? as in what are the ports connected to?
Also if you really do need the RSTP and this is your split horizon because it is core then tweaking the priority on that bridge would help with calculations and bridge efficiency.
If it is safe for your deployment to disable it please can you turn it off and see if the issue stops [EDIT: turn protocol from RSTP to none]?
My CCR 1036’s in the field are running on the Bugfix release 3.34.6 which has been a generally very good release for the parts of the system I am using currently. so my practical experience with 6.30.4 is not so great with any oddities.
Just some other routine checks, have you installed any routerboot updates when available?
I have the team viewer free version on my machine for helping out family with their computers, through work I have access to go to assist.
Regards
Alexander
my friend
i do that
bridge >>> stp >> protoclol mode to none
note :
the bridge optain all ether without ether 1
ether 1 is in for ineternet
bridge is the out
now
ether 2 conected with rocket m5
ether 3 with switch ubnt
all ether from 4 to 11 every one with rocket
ether 12 with dma radius manager
now after i do what you say
the problem is finish >> but can you explan for me
Hi hazardsy
If Ether12 is your RADIUS Manager does it even need to be in the bridge? possibly better to have that out of the bridge and have RADIUS system inside the system directly connect to the RADIUS manager, also if your end users need to connect to it you can then route them to it on the ports required for their work.
If turning the Protocol Mode over to none has solved the issue it was most likely caused by BPDU’s from being received onto the bridge and causing the Mikrotik (who wasn’t expecting to see that BPDU from thinking there had been a network change that required a change in the network topology.
When a bridge receives traffic destined for another device if the MAC Address is in the forwarding table then the traffic flows out the designated interface for the path to that MAC address.
If there is no entry in the forwarding table for that address then the bridge will flood the traffic out of all interfaces to ensure it gets to its destination and the bridge then learns over time where MAC addresses can be found on the network and builds up the table.
With (R)STP, multiple connections may exist between bridges which would normally cause a loop of traffic that could saturate the network and cause issues. However if there was a failure then all the traffic would fail to pass between those devices. By using spanning tree there can be two or more connections between bridges and the system will decide to stop traffic flowing over all but one of them to ensure communication still goes ahead. If that link should go away for any reason then a “network topology change” is highlighted and bridges drop their tables and check to keep all but one valid paths between bridges blocked to prevent loops but keep the network operating.
Two critical decisions to be made is where is the root bridge. The root bridge is the “core” of the network so this should be the most central / best connected bridge. The “network topology change” applies to any change in the network between the bridge in question and the root bridge.
When the change happens the bridge then flushes the forwarding table (so if a path changes the traffic goes to the new interface) and the path needs to be calculated and all MAC Addresses learned anew.
Considering you are using split horizon bridging you have minimised the risk of any loop at this point.
Regards
Alexander
in the first ether 12 = dma radius manager .. in bridge
for self registering
then i’m testing my network now for 24 hour
thanks man
i will say to you what happened >>