RouterOS v5.7 released

Thank you for recent release and addressing a lot of issues we had with 5.6.

A few months ago I asked if it would be possible to add back the ability to sort by port in the Torch. Back then I thought I was all by myself but now if I search on port sort, I see a lot more people complaining about the loss of this function.

A lot of “strange” activity can’t always be detected by a smart script or a config, which is why we also scan our network routers manually, especially when the maps report packet loss or unusual traffic.

THe ability to sort by port (both for src and dst) allows us to reveal viruses, aggressive and encrypted P2P, a stuck process that tries to go to Adobe, etc. etc.

Would it be possible to add this function back to the Winbox GUI?
What was the reasoning in taking it out?

What kind of problems?

I have problems with the dns server. This is the second time this week that my Mikrotik RouterOS 5.7 Core DNS stopped responding.

I try ping google from console and I get IP DNS error or something like that. I reboot the rb1200 and works fine for a few more days.

This never happened to me with OS 5.6. I’m using google’s dns (8.8.8.8 & 8.8.4.4).

Does anyone have any idea of what could be the problem?

Thank you.

Google’s DNS server itself had problems ?

When it happened to me I just put in another DNS server.

I’m testing with my ISP DNS now, but if the DNS server is the problem shouldn’t be solved by rebooting the rb1200.

OH yes it can.
Your server stores dns resolves in a cache. If this was a piece of date coming from the google dns server you cache has the faulty data. When you reboot your router the cache gets flushed and new data needs to be used. If now this new data is ok the router works fine, for as long as it takes to get the wrong data from google again…

When I had the problem I tried flushing the dns cache in the rb1200. It gets empty and it doesn’t take any more request so I continue without browsing…

From my experience there is a problem with ROS’ built-in DNS resolver when cache size is set to value bigger than 8192 kB.
With different versions of ROS there was same problem, no response from DNS cache.
Also max. UDP packet size should be increased to value bigger than default 512 bytes (4096-8192).

HTH,

Why would the DNS packet be so big?

ROS v5.7 doesn’t print and export IPv6 addresses of BGP peers:

/routing bgp peer print
Flags: X - disabled, E - established 
 #   INSTANCE        REMOTE-ADDRESS                                 REMOTE-AS  
 0   default         (unknown)                                      12345

There is the same problem with export. IPv6 adresess are always assigned as (unknown). WinBox shows IPv6 addresses correctly without any problems.

Because to allow support for DNSSEC packet size allowed should be a minimum of 4096

The second issue is related to the packet size. The authors of the DNSSEC standard realized that there might be a potential problem with TCP queries. TCP puts a higher burden on the DNS servers. (TCP is much more expensive to process than UDP.) To avoid too much TCP traffic, the authors made the EDNS0 extension mandatory for DNSSEC. EDNS0 is a standard that among other things allows a client to signal that it is capable of receiving DNS replies over UDP that are larger than the previous limit of 512 bytes. Some firewalls are not aware of the fact that the EDNS0 standard allows for larger packets and they block any DNS packet larger than the previous limit. Other firewalls allow for the large packets by default, whereas a few vendors require the firewall to be manually configured to do so. Any device in the path that does packet inspection in the application layer must be aware of the EDNS0 standard to be able to make a correct decision whether to forward the packet or not.

Source: http://www.circleid.com/posts/operational_challenges_when_implementing_dnssec/

This happens on 4.x versions for OpenDNS servers 208.67.220.220 and 208.67.222.222 and for Google DNS servers too.
The particular routerboard for DNS resolving runs HotSpot and is a gateway for the network, ROS 4.17.
One thing I noticed is that you CAN ping the IP address, for ex.208.67.220.220 from the DNS resolver routerboard, but you CAN’T ping the same IP address from the inside of the network, for ex. from client who is authenticated on the HotSpot and Skype running, you get an answer from the DNS resolver routerboard: “destination host unreachable”.

I’ve noticed this problem with earlier versions starting from 4.5 (don’t sure for earlier versions) and only a reboot fixes it. Hope this will shred more light on this problem.

So I should make a script that checks ping to google.com and reboot the router automatically or is there another way?

What is Mikrotik’s opinion in this matter?

The legend is: while reading ip address: could not get answer from dns server

I’m putting the dns cache back to 1024k, I had it at 10240k for more caching.

I’ll let you guys know if it happends again.

if you where running 5.7 maybe you could send supout.rif, in case we could find out more about the problem you encountered.

ROS 5.7, firmware v. 2.36. I Have the problem - RB435G at random times(it may be one hour or one day) freezes ethernet interfaces to pass ip traffic, interface at that time says that “link ok”(i use 1G connection with different devices at different places, ~8 BOARDS with PC and board-to-board connections, most time of all its freezes at 2 RB435g’s with bridge functions- wireless interface bridged with ethernet, not matter with which - ether1 or ether2 or ether3), wireless interface at the same time work properly and i can access the board via wireless, after rebooting board its’ all right for a random time. A guess i have similar problem with the same topics - http://bugs.mikrotik-routeros.com/view.php?id=15, http://forum.mikrotik.com/viewtopic.php?f=1&t=55021&start=50, http://forum.mikrotik.com/viewtopic.php?f=0&t=55021&p=282149&hilit=435G#p282149, http://forum.mikrotik.com/t/rb-493g-lockups/50695/1 etc.

Only one solution is to turn off or on /interface Ethernet switch set 0 switch_all_ports=yes or no, after that routerboard starts to transmit data. But i don’t use hardware switch for boards, no master or slave interfaces, only program switch for bridging Ethernet iface with wireless, Don’t know exact what the problem is, power supply is good, cables is good(at first time we think that the cables cat5e was caused the problem for 1G connection, and than replaced them to cat7 cables - have the same issue).
A hope for some assistance, it’s not suitable to downgrade software or firmware on boards to avoid similar problems with configuration - a can’t to stop transmission through that link cause they are situated on commercial towers and it’s not real to get the boards directly.
Anyone suggest?
My opinion - it’s a firmware trouble of RB435G at a side of Ethernet sensitivity, may be i’m wrong.
I hope the MTIK team to help.
Thanks

MikroTik gigabit ports have trouble from time to time.

RB450G different 5x versions different boards
RB250GS firmware 1.6

Auto-negotiation issues? Some sort of additional instability?

Hi,

i have some troubles with this version:
on RB450G: high CPU usage (DHCP package) - i`m using vlans, so DHCP server is connected to vlan, not ethernet directly.
on all boards (and all 5x versions, i think):

  • DNS package - when i remove static record, this one persist in memory until router is rebooted.
  • Graphs: are completly deleted, when RB is rebooted.
    so, i`m waiting for next version of RouterOS.

I love how MikroTik are improving on features like the Sniffer. The new filters are awesome.

My home RB450G was running 5.7 since it was released and just today it made me a problem (apart from DNS issues I thought were due to 8.8.8.8 being down)

The problem was that in Profile tool I could see sniffing making close to 100% CPU so I took a supout for support, rebooted, put in the latest unreleased 5.8 in the share subfolder and rebooted again.

Now testing with share 5.8 from the 12th.

Cheers.

Esp. saving to a file and then load the dump in wireshark is a great feature which helped a lot already.