Yes - I agree totally your experience with IGMP snooping on bridges at least downstream. Main router is ccr1016, feeding 3 x downstream crs125 switches, 1 x 8 port switch, a dell centos7 server using two more CCR ethernets with VMs, DNS, FTP, etc on it as well. All off different ethers on the CCR for our LAN. A simple single bridge on the CCR with ether 1 (WAN) routed not a part of the bridge. Rest of ethers 2 to 7 are on a single bridge.
On the CCR as well as CRS, no VLANs at all simply everything is on a simple layer 2 bridge on each device. Yet after a day of enabling IGMP snooping on the CCR and the CRS-125's all my DLNA started (both wired and wireless devices) began to drop randomly stop and drop streams during playing (never ever had this) and then the DLNA devices start disappearing from the list of available DLNA servers.
I disabled IGMP snooping only on all the downstream devices, 3 x crs125, and the 3 x 951g using as wireless access points (come off the crs125 anyway), but left IGMP snooping enabled on the CCR.
As soon as I did this all the issues wen't away.
I tried then adding PIM on the CCR and CRS but as soon as IGMP snooping is on DLNA breaks. Once a device disappears from the DLNA list, disable and re-enable the ether, reboot the actual client and DLNA server, remove the ethers physically, no difference the device never shows up as a DLNA server, or the client can't see any. But its working you can https, or ftp, just the DLNA. Only a reboot of the actual crs switch resumes DLNA again until it stops.
There's definitely an issue with IGMP snooping. Over a week solid now without IGMP snooping no DLNA issues.
Here is a lengthy discussion: http://forum.mikrotik.com/t/rc-solved-ros-wireless-feature-request-wireless-access-list/111579/1
Basically, in a wireless access-list you can specify a signal range required to establish/maintain a connection. Bugs in the client radio, bugs in the AP radio, or actual signal changes will cause a client to be disconnected from the AP when the calculated signal strength goes out of that range. This sounds good in theory, but in practice this happens for certain clients regardless of their distance to the AP (likely a bug in radio firmware.) Because the offending clients only exceed this signal range for a small number of frames at a time, the new access-list default in 6.41 is to allow a client to be out of signal range for 10 seconds before the rule is triggered.
In my experience, using a signal range of -120..120 (or not specifying a signal range at all) in the access list still results in both “too strong” and “too weak” events that disconnect clients. The “allow-signal-out-of-range” keeps these clients connected to the AP while still preventing low-signal clients from initially connecting. Unfortunately, this change didn’t get implemented in caps-man when it was put into /interface wireless access-list.
If my present rule allows -80..120 and rejects -120..-81 ; what are the precise rules i want for the new option? mind pasting the lines? I suppose the involved lines should go above my present rules right?
and Dear MT, please make this possible for capsman, I’ve been having these connect/disconnect issues for a very very long time.. and never ever knew what the problem was.
I think this is what the documentation should say (just guessing for min-max time):
allow-signal-out-of-range (always | time [0s..1d]; Default: 10s)
Ignore signal-range in this rule for the specified time period.
This seems to be working for me:
/interface wireless access-list
print
# For the "allow connections" rule allow 10 seconds of out-of-range signal:
set 1 allow-signal-out-of-range=10s
This may result in clients being able to connect for 10 seconds even though they are too far away. Is there a way to prevent this? These clients will take up a large portion of the AP’s time/bandwidth through re-transmissions and a low symbol rate. A different solution to this problem is to throw out the “outlier” (less than -120dBm, greater than +120dBm) signal strength readings and average the signal level over a given number of “valid” frames. It adds complication when accepting a new client and creates additional memory requirements, but may result in a more desirable AP behavior. It would be really nice to be able to see the averaged signal strength for this type of rule in the debug logs… but now I’m running off the rails into “feature-request” territory. Strods, is there a better place for this discussion? I assume that the “missing from caps-man in 6.42rc” belongs here, but talking about how to use the feature should be discussed somewhere else.
Changes since previous release:
*) bridge - fixed interface list moving in “/interface bridge port” menu;
*) bridge - fixed hw-offload disabling for Mediatek and Realtek switches when STP/RSTP configured;
*) bridge - fixed hw-offload disabling when adding a port with “horizon” set;
*) bridge - fixed repetitive port “priority” set;
*) bridge - fixed situation when packet could be sent with local MAC as dst-mac;
*) crs1xx/2xx - added BPDU value for “ingress-vlan-translation” menu “protocol” option;
*) crs3xx - hide deprecated VLAN related settings in “/interface ethernet switch port” menu;
*) dhcpv4-server - fixed framed and classless route received from RADIUS server;
*) dhcpv6-client - added info exchange support;
*) dhcpv6-client - added support for options 15 and 16;
*) dhcpv6-server - added DHCPv4 style user options;
*) ike1 - do not accept “mode-config” reply more than once;
*) ike2 - delay rekeyed peer outbound SA installation;
*) ipsec - properly update IPsec secret for IPIP/EoIP/GRE dynamic peer;
*) kidcontrol - added initial support for “/ip kid-control” feature (CLI only);
*) lte - do not add DHCP client on LTE modems that doesn’t use DHCP;
*) lte - fixed DHCP client adding for MF823 modem;
*) mac-ping - fixed duplicate responses;
*) modem - added initial support for AC340U;
*) ppp - allow to override remote user PPP profile via “Mikrotik-Group”;
*) ppp - changed default value of “route-distance” to 1;
*) quickset - show “G” flag for guest users;
*) radius - added warning if PPP authentication over RADIUS is enabled;
*) radius - increase allowed RADIUS server timeout to 60s;
*) snmp - allow also IPv6 on default public community;
*) snmp - fixed SNMP for W60G interfaces;
*) tile - improved stability in high throughput HW accelerated IPsec setups (“/system routerboard upgrade” required);
*) tr069-client - added “DownloadDiagnostics” and “UploadDiagnostics”;
*) webfig - added support for proper default policies when adding script or scheduler job;
*) webfig - fixed bridge port sorting order by name;
*) winbox - added possibility to delete SMS from Inbox;
*) winbox - allow to open bridge host entry;
*) winbox - allow to specify “to-ports” for “action=masquerade”;
*) winbox - do not show “hw” option on non-ethernet interfaces;
*) winbox - do not show VLAN related settings in switch port menu on CRS3xx boards;
*) winbox - fixed “/tool e-mail send” attachment behaviour;
*) winbox - improved stability when using trackpad scrolling in large lists;
*) wireless - fixed frequency-monitor/sniffer/snooper; (introduced in v6.42rc);
*) wireless - fixed nv2 (introduced in v6.42rc);
*) wireless - updated “Czech Republic” country 5.8 GHz frequency range;
If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.
I checked to override with Radius remote user PPP profile (“Mikrotik-Group” attribute) - it works fine.
This is a nice feature that some people where asking for a long time. Now we can define several profiles and set different values there, such as speed per profile, queue type, different pool and then using Radius server say where PPPoE customer belongs.
There is one important option in PPPoE profile - Parent.
The question is how to setup the parent for Simple Queue correctly ? PPPoE queue of customer has a target pppoe-test@connect, what should be set to the Parent target ? Remember that it should be set there before any customer connects, because parent is a static queue.
The option is to set 0.0.0.0/0, but then, we can have only one parent per router, because if I add second parent, the 0.0.0.0/0 of previous one will take the whole traffic.
Here is an example, we have two parents, Regular and Business. There are two PPP server profiles, when customer is from business - he is set to Business profile and put under Business Parent Queue.
Picture -
Why this is nice to implement - because we can add Simple Queue to parents and according to Janis presentation, it should bring better performance on CCR routers with thousands of Simple queues.
Ok, guys, I have found the answer on my previous question.
Final solution is not that automated as I wanted, but still better than nothing.
Instead of setting 0.0.0.0 to profiles we should do following :
Define different IP pool for profile. For example 192.168.101.0/24 - regular users, 192.168.250.0/24 - business users.
To parent I can set the range that corresponds to the pool. So, Business Parent queue Target = 192.168.250.0/24. Regular Parent Queue Target = 192.168.101.0/24.
I can define the speed limits for Plans inside PPP profile, or Radius can send it as Mikrotik-rate-limit attribute.
When PPPoE clients connect, Radius answers with “Mikrotik-Group” = business or “Mikrotik-Group” = regular and Queue is set under correct Partner.
Partner queue can have a Speed limitation - this will provide contention scenario, or Partner can be “unlimited”, then Simple Queues will be just well balanced on CCR cores.
Tested in a SXT in “station-bridge” in production connected to a Sextant in “ap-bridge” mode and was lost tomorrow need to go physically to the tower to downgrade by ethernet… the SXT client is in Wireless-Protocol=nv2-nstreme, changed the Sextant AP to NV2 or Nstreme and no connect… In rc5 was the same and by the changelog this solve wireless problems and i take the risk… NOT SOLVED!
tomorrow need to go physically to the tower to downgrade by ethernet… the SXT client is in Wireless-Protocol=nv2-nstreme, changed the Sextant AP to NV2 or Nstreme and no connect… In rc5 was the same and by the changelog this solve wireless problems and i take the risk… NOT SOLVED!