Thank you! Back to 6.18 again...pbr3000, we will try to figure out what is the problem with the address-list. Thank you for the feedback.
Ehm, no. As a brave man, I decided to try fresh ROS 6.22 on my home router (I often misuse it for various testing, its physical reachability is big advantage ). Same simple config as last time with 6.21.1. First impression was good, both routes were reported as reachable:*) 6to4 tunnel fixed;
0 A S dst-address=2000::/3 gateway=::192.88.99.1%6to4 gateway-status=::192.88.99.1%6to4 reachable distance=1 scope=30 target-scope=10 1 ADC dst-address=2002::/16 gateway=6to4 gateway-status=6to4 reachable distance=0 scope=10 2 ADC dst-address=2002:d5d3:xxxx:80::/64 gateway=internal gateway-status=internal reachable distance=0 scope=10Unfortunately, nothing was reachable from LAN. Why? Because no matter what I tried to connect to, router was returning ICMPv6 destination unreachable (type 1, code 0). Also all attempts to ping external IPv6 address directly from router failed with "no route to host". So it says it has routes, but internally it does not seem to really have them.
And with every release it is another part, That is my definition of beta. Wasted 4h yesterday with a problem where aNah....
Version 6 isn't beta. It's just that some parts of it are still not working quite as well as they need to be....
What about the new feature diskAnd with every release it is another part, That is my definition of beta. Wasted 4h yesterday with a problem where aNah....
Version 6 isn't beta. It's just that some parts of it are still not working quite as well as they need to be....
ethernet port did not work when removing it out of a bridge.
Here are RouterOS commands for it.What about the new feature disk
From Winbox I do not see any drives. Looking on the Files menu I see a folder called Disk1.
How can I create folders on a drive for e.g. WebProxy or logging?
#WebProxy:
/ip proxy set cache-path=disk1/web-proxy1
#Logging:
/system logging action set disk disk-file-name=disk1/log
#User-Manager:
/tool user-manager database set db-path=disk1/user-manager
The ticket is still open and solution has not been found. Sergejs asked for logs and he is still looking into this problem. The issue will be solved, when ticket is closed, and you will be notified about this problem.I have problems in address-lists and dhcp from 6.19 and all higher versions later. I submitted a report of the problem (Ticket#2014110466000984) to the v6.21.1. I tested the new version 6.22 right now and surprise: nothing has changed.
I have heard people talk here in "BugOS" to refer to "RouterOS" and tend to agree with them, unfortunately.
If you have packet loss in all versions, maybe there is some sort of hardware problem? if you have the chance, try another machine or at least other NICWhat about this problem?
http://forum.mikrotik.com/viewtopic.php?f=2&t=86119
please clarify what you mean by this?After update my RB2011 radio is very loud...
please make a supout.rif file and email it to support. when did this issue start?CCR series still have problems with randomly rebooting.
No, we have packet loss only on version 6.8-6.22.Versions 6.5-6.7 works stable. After 20-30 minutes MT start drops packet on all interfaces. In log file we see next message "105 (no buffer space available)". We try start VM on next servers:If you have packet loss in all versions, maybe there is some sort of hardware problem? if you have the chance, try another machine or at least other NICWhat about this problem?
http://forum.mikrotik.com/viewtopic.php?f=2&t=86119
Please make a supout.rif file at the moment of the packet loss and send to support.No, we have packet loss only on version 6.8-6.22. After 20-30 minutes MT start drops packet on all interfaces. In log file we see next message "105 (no buffer space available)". We try start VM on next servers:If you have packet loss in all versions, maybe there is some sort of hardware problem? if you have the chance, try another machine or at least other NICWhat about this problem?
http://forum.mikrotik.com/viewtopic.php?f=2&t=86119
1. Supermicro X8DTT 12CPUs x 2.4 GHz Processor Type Inter(R) Xeon(R) CPU E5645 @ 2.40GHZ
Intel Corporation 82576 Gigabit Network Connection
2.HP Proliant DL380p Gen8 16 CPUs x 2.593 GHz Processor Type Inter(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz
Broadcom Corporation NetXtreme II BCM5710 10G
Last month we buy CCR1036-8G-2S+, but his work very terribly.
Ok, clear.Here are RouterOS commands for it.What about the new feature disk
From Winbox I do not see any drives. Looking on the Files menu I see a folder called Disk1.
How can I create folders on a drive for e.g. WebProxy or logging?Code: Select all#WebProxy: /ip proxy set cache-path=disk1/web-proxy1 #Logging: /system logging action set disk disk-file-name=disk1/log #User-Manager: /tool user-manager database set db-path=disk1/user-manager
Now "Disks" menu shows only additionally mounted drives and allows formatting them. Local drive is what you see in the File List and you can use it for the same services by changing the path: "/web-proxy1"; "/log"; "/user-manager"Ok, clear.Here are RouterOS commands for it.What about the new feature disk
From Winbox I do not see any drives. Looking on the Files menu I see a folder called Disk1.
How can I create folders on a drive for e.g. WebProxy or logging?Code: Select all#WebProxy: /ip proxy set cache-path=disk1/web-proxy1 #Logging: /system logging action set disk disk-file-name=disk1/log #User-Manager: /tool user-manager database set db-path=disk1c
But how come I can't see my local drive/disk?
On the old situation (system/stores -> disk tab) there is a system disk.
Now there is nothing, unless there is a USB drive inserted.
I can understand how this looks, but please remember that tens of thousands of users upgraded without a single issue. The problems posted here are quite unique and affect only people with specific configurations.Reading all these comments, only hours after releasing a 3rd version in less then 2 months makes me suspicious. I'm skipping this version too.... Is it 22nd in a row already or 24th? Anyway, skipped whole v6 version. One dissapointment after another.
About CCR. Still problem with QOS(PCQ) low bandwith. 550 Mbit/s traffic(testing in production) and all CCR's CPU goes about 78-100%(all 36 cores). 2 years ago CCR can skip only 250 Mbit/s and works only 2 core(100%) and after 1 hour goes crash.Please make a supout.rif file at the moment of the packet loss and send to support.
What problems do you have with the CCR, you did not say
Wait, isn't "no buffer space available" the same message we saw when there was a bug with the PPP driver filling up the kernel route cache? In cursemipn's other thread that he linked to, he mentions his router runs a PPPoE server with hundreds of clients. He also mentions that he has no problems with 6.7 and his problems start with 6.8. RouterOS 6.8 was the version that included the large PPP driver rewrite, and for several versions after that, MikroTik had to fix tons of PPP bugs that 6.8 introduced. The kernel route cache memory leak was fixed for most PPP interfaces on 6.13, but maybe MikroTik missed one that still exists.No, we have packet loss only on version 6.8-6.22.Versions 6.5-6.7 works stable. After 20-30 minutes MT start drops packet on all interfaces. In log file we see next message "105 (no buffer space available)".If you have packet loss in all versions, maybe there is some sort of hardware problem? if you have the chance, try another machine or at least other NICWhat about this problem?
http://forum.mikrotik.com/viewtopic.php?f=2&t=86119
Why do you assume we don't have complex configs on our core network? I'm just being cautious. Also reading soo many negative comments on ALL V6 release threads including this one, makes me a bit worried about my decision to implement your routers in our network. All you need to do is release a STABLE version where all declared features work. Random rebooting of CCR's isn't what I had in mind and these device can be used for core network but I'm glad we are not using them.I can understand how this looks, but please remember that tens of thousands of users upgraded without a single issue. The problems posted here are quite unique and affect only people with specific configurations.Reading all these comments, only hours after releasing a 3rd version in less then 2 months makes me suspicious. I'm skipping this version too.... Is it 22nd in a row already or 24th? Anyway, skipped whole v6 version. One dissapointment after another.
Nov/13/2014 12:39:32 interface,info ether1-gateway link down
Nov/13/2014 12:39:32 interface,info ether2-local-master link down
Nov/13/2014 12:39:32 interface,info ether3-local-slave link down
Nov/13/2014 12:39:34 interface,info ether2-local-master link up (speed 100M, full duplex)
Nov/13/2014 12:39:36 interface,info ether1-gateway link up (speed 1G, full duplex)
Nov/13/2014 12:39:50 interface,info ether3-local-slave link up (speed 100M, full duplex)
Nov/13/2014 13:07:32 interface,info ether1-gateway link down
Nov/13/2014 13:07:32 interface,info ether2-local-master link down
Nov/13/2014 13:07:32 interface,info ether3-local-slave link down
Nov/13/2014 13:07:34 interface,info ether2-local-master link up (speed 100M, full duplex)
Nov/13/2014 13:07:36 interface,info ether1-gateway link up (speed 1G, full duplex)
Nov/13/2014 13:07:51 interface,info ether3-local-slave link up (speed 100M, full duplex)
I did not say complex, I said specific. There are many ISPs running on this version now without any issues, with complext configs.Why do you assume we don't have complex configs on our core network? I'm just being cautious. Also reading soo many negative comments on
we have statistics how many devices have upgraded. I don't want to argue about this, please let us concentrate on the remaining issues here. Let us discuss the release rather than nitpickIt's because others are not beta testers unlike us.
Yes, you said specific not complex. But still, every major company has some specific configs and if your routers are constantly having bugs and with each new version new bugs, it is hard to say, not to worry, especially because I'm already worring the whole time v6 is out. I will wait for 6.23 but regarding previous experiences nothing will change. Some old bugs will be fixed and some new will be implemented simply because you DON'T TEST your software. When you get a critical mass of unsatisfied customers it will be a different story.I did not say complex, I said specific. There are many ISPs running on this version now without any issues, with complext configs.Why do you assume we don't have complex configs on our core network? I'm just being cautious. Also reading soo many negative comments on
Most people having prolems are in this forum, you can see how many there are, less than 10.
We are addressing all those remaining issues, please don't worry.
The rules have changed recently. There're no more upgrade limits existing.The other thing is licencing... we bought many routers (mostly 411xx) when v4 was the current version and they are upgradable to v6.x. It can be quite hard for me to accept claim that v6 will be stable before v7 comes out.
I didn't know that. Thanks for info.The rules have changed recently. There're no more upgrade limits existing.The other thing is licencing... we bought many routers (mostly 411xx) when v4 was the current version and they are upgradable to v6.x. It can be quite hard for me to accept claim that v6 will be stable before v7 comes out.
Sure. Please concentrate on error corrections and prevent creating new ones. I am telling this repeatedly for years already and each new update still brings new errors. But on the other way I can say that generally speaking the 6 is more usable for me than 5 and even many last versions made me problems I am not thinking about going back to 5.we have statistics how many devices have upgraded. I don't want to argue about this, please let us concentrate on the remaining issues here. Let us discuss the release rather than nitpickIt's because others are not beta testers unlike us.
Nov/13/2014 12:39:32 interface,info ether1-gateway link down
Nov/13/2014 12:39:32 interface,info ether2-local-master link down
Nov/13/2014 12:39:32 interface,info ether3-local-slave link down
Nov/13/2014 12:39:34 interface,info ether2-local-master link up (speed 100M, full duplex)
Nov/13/2014 12:39:36 interface,info ether1-gateway link up (speed 1G, full duplex)
Nov/13/2014 12:39:50 interface,info ether3-local-slave link up (speed 100M, full duplex)
Nov/13/2014 13:07:32 interface,info ether1-gateway link down
Nov/13/2014 13:07:32 interface,info ether2-local-master link down
Nov/13/2014 13:07:32 interface,info ether3-local-slave link down
Nov/13/2014 13:07:34 interface,info ether2-local-master link up (speed 100M, full duplex)
Nov/13/2014 13:07:36 interface,info ether1-gateway link up (speed 1G, full duplex)
Nov/13/2014 13:07:51 interface,info ether3-local-slave link up (speed 100M, full duplex)
Nov/13/2014 13:13:46 interface,info ether1-gateway link down
Nov/13/2014 13:13:46 interface,info ether2-local-master link down
Nov/13/2014 13:13:46 interface,info ether3-local-slave link down
Nov/13/2014 13:13:48 interface,info ether2-local-master link up (speed 100M, full duplex)
Nov/13/2014 13:13:49 interface,info ether1-gateway link up (speed 1G, full duplex)
Nov/13/2014 13:14:04 interface,info ether3-local-slave link up (speed 100M, full duplex)
Nov/13/2014 13:31:05 interface,info ether1-gateway link down
Nov/13/2014 13:31:05 interface,info ether2-local-master link down
Nov/13/2014 13:31:05 interface,info ether3-local-slave link down
Nov/13/2014 13:31:07 interface,info ether2-local-master link up (speed 100M, full duplex)
Nov/13/2014 13:31:09 interface,info ether1-gateway link up (speed 1G, full duplex)
Nov/13/2014 13:31:23 interface,info ether3-local-slave link up (speed 100M, full duplex)
Then you have not been here long enough.i have yet to see them just simply ignore a genuine bug report which provided enough resources to actually replicate/solve the problem.
no point in arguing. if you work in software development for a while, you would understand tickets filed that effect only a small subset of users take the backseat to show-stopping issues (like if the router stops passing traffic or something). you can look at any major software project's bug tracking system for examples -- even something huge like the apache webserver (some tickets date back 5+ years).I could give you many ticket IDs which show differently...
Be careful, if you push a bit more of the boys mikrotik they erase his post, as did mine.Yes, you said specific not complex. But still, every major company has some specific configs and if your routers are constantly having bugs and with each new version new bugs, it is hard to say, not to worry, especially because I'm already worring the whole time v6 is out. I will wait for 6.23 but regarding previous experiences nothing will change. Some old bugs will be fixed and some new will be implemented simply because you DON'T TEST your software. When you get a critical mass of unsatisfied customers it will be a different story.I did not say complex, I said specific. There are many ISPs running on this version now without any issues, with complext configs.Why do you assume we don't have complex configs on our core network? I'm just being cautious. Also reading soo many negative comments on
Most people having prolems are in this forum, you can see how many there are, less than 10.
We are addressing all those remaining issues, please don't worry.
The other thing is licencing... we bought many routers (mostly 411xx) when v4 was the current version and they are upgradable to v6.x. It can be quite hard for me to accept claim that v6 will be stable before v7 comes out. These routers cannot be upgraded to v6 because of constant connect/disconnect issues over PPTP VPN. It is unstable. Period. I've been reading this forum for more then 6 years now and I have seen many answers from MT staff like, please wait for version xx.xx for this bug to be fixed. Always the same. No, the only right thing for me is to worry. Upgrading at this stage to any v6 is a no-no.
Normis have deleted my post for speaking the truth.Update to this version cost me a lot of troubles!
I wish you could hear the bad words that went out here....
In every 10-30 minutes all physical (eth) ports are flapping (turning down and up again) and break down connections to 14 our local servers... very nice, I'm feeling like lab rat
This is today's log (interfaces only):
--------------------------------------------------
I changed the router to another downgraded to RouterOS 6.20.... problem fixed.Code: Select allNov/13/2014 12:39:32 interface,info ether1-gateway link down Nov/13/2014 12:39:32 interface,info ether2-local-master link down Nov/13/2014 12:39:32 interface,info ether3-local-slave link down Nov/13/2014 12:39:34 interface,info ether2-local-master link up (speed 100M, full duplex) Nov/13/2014 12:39:36 interface,info ether1-gateway link up (speed 1G, full duplex) Nov/13/2014 12:39:50 interface,info ether3-local-slave link up (speed 100M, full duplex) Nov/13/2014 13:07:32 interface,info ether1-gateway link down Nov/13/2014 13:07:32 interface,info ether2-local-master link down Nov/13/2014 13:07:32 interface,info ether3-local-slave link down Nov/13/2014 13:07:34 interface,info ether2-local-master link up (speed 100M, full duplex) Nov/13/2014 13:07:36 interface,info ether1-gateway link up (speed 1G, full duplex) Nov/13/2014 13:07:51 interface,info ether3-local-slave link up (speed 100M, full duplex) Nov/13/2014 13:13:46 interface,info ether1-gateway link down Nov/13/2014 13:13:46 interface,info ether2-local-master link down Nov/13/2014 13:13:46 interface,info ether3-local-slave link down Nov/13/2014 13:13:48 interface,info ether2-local-master link up (speed 100M, full duplex) Nov/13/2014 13:13:49 interface,info ether1-gateway link up (speed 1G, full duplex) Nov/13/2014 13:14:04 interface,info ether3-local-slave link up (speed 100M, full duplex) Nov/13/2014 13:31:05 interface,info ether1-gateway link down Nov/13/2014 13:31:05 interface,info ether2-local-master link down Nov/13/2014 13:31:05 interface,info ether3-local-slave link down Nov/13/2014 13:31:07 interface,info ether2-local-master link up (speed 100M, full duplex) Nov/13/2014 13:31:09 interface,info ether1-gateway link up (speed 1G, full duplex) Nov/13/2014 13:31:23 interface,info ether3-local-slave link up (speed 100M, full duplex)
But please, never ever relase another poorly tested version as STABLE again!!!!!
I don't mean that post in some bad way... but my problems after upgrade to this version had a very huge fu*king effect. There are 70 employees working from many different locations on 14 our servers via VPN and all of them was disconnected almost every 15 minutes!Normis have deleted my post for speaking the truth.Update to this version cost me a lot of troubles!
I wish you could hear the bad words that went out here....
In every 10-30 minutes all physical (eth) ports are flapping (turning down and up again) and break down connections to 14 our local servers... very nice, I'm feeling like lab rat
This is today's log (interfaces only):
--------------------------------------------------
I changed the router to another downgraded to RouterOS 6.20.... problem fixed.Code: Select allNov/13/2014 12:39:32 interface,info ether1-gateway link down Nov/13/2014 12:39:32 interface,info ether2-local-master link down Nov/13/2014 12:39:32 interface,info ether3-local-slave link down Nov/13/2014 12:39:34 interface,info ether2-local-master link up (speed 100M, full duplex) Nov/13/2014 12:39:36 interface,info ether1-gateway link up (speed 1G, full duplex) Nov/13/2014 12:39:50 interface,info ether3-local-slave link up (speed 100M, full duplex) Nov/13/2014 13:07:32 interface,info ether1-gateway link down Nov/13/2014 13:07:32 interface,info ether2-local-master link down Nov/13/2014 13:07:32 interface,info ether3-local-slave link down Nov/13/2014 13:07:34 interface,info ether2-local-master link up (speed 100M, full duplex) Nov/13/2014 13:07:36 interface,info ether1-gateway link up (speed 1G, full duplex) Nov/13/2014 13:07:51 interface,info ether3-local-slave link up (speed 100M, full duplex) Nov/13/2014 13:13:46 interface,info ether1-gateway link down Nov/13/2014 13:13:46 interface,info ether2-local-master link down Nov/13/2014 13:13:46 interface,info ether3-local-slave link down Nov/13/2014 13:13:48 interface,info ether2-local-master link up (speed 100M, full duplex) Nov/13/2014 13:13:49 interface,info ether1-gateway link up (speed 1G, full duplex) Nov/13/2014 13:14:04 interface,info ether3-local-slave link up (speed 100M, full duplex) Nov/13/2014 13:31:05 interface,info ether1-gateway link down Nov/13/2014 13:31:05 interface,info ether2-local-master link down Nov/13/2014 13:31:05 interface,info ether3-local-slave link down Nov/13/2014 13:31:07 interface,info ether2-local-master link up (speed 100M, full duplex) Nov/13/2014 13:31:09 interface,info ether1-gateway link up (speed 1G, full duplex) Nov/13/2014 13:31:23 interface,info ether3-local-slave link up (speed 100M, full duplex)
But please, never ever relase another poorly tested version as STABLE again!!!!!
If I say that I agree with you it will delete this?
have you set MTU for 6to4 tunnel to value suggested by HE (check configuration example)6to4 tunnel NO fixed !!!
Router OS 6.22 Router OS 6.19 (6to 4 work OK)
[janiskr@MikroTIk] /ipv6 route> print
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable
# DST-ADDRESS GATEWAY DISTANCE
0 A S ::/0 2001:db8:beef:bee::1 1
1 ADC 2001:db8:beef:bee::/64 he-tb 0
2 ADC 2001:db8:beef:beef::/64 lo 0
[janiskr@MikroTIk] /ipv6 route> /ping [:resolve ipv6.google.com]
HOST SIZE TTL TIME STATUS
2a00:1450:400f:804::1003 56 53 53ms echo reply
2a00:1450:400f:804::1003 56 53 54ms echo reply
sent=2 received=2 packet-loss=0% min-rtt=53ms avg-rtt=53ms max-rtt=54ms
[janiskr@MikroTIk] /ipv6 route> /interface 6to4 print
Flags: X - disabled, R - running
# NAME MTU ACTUAL-MTU LOCAL-ADDRESS REMOTE-ADDRESS KEEPALIVE DSCP
0 R he-tb 1280 1280 a.b.c.s e.f.g.h inherit
Flags: X - disabled, R - running, D - dynamic
0 ;;; IPTunel to Ferro
name="ipip1" mtu=1480 actual-mtu=1480 local-address=80.XX.YY.ZZ remote-address=87.XX.YY.ZZ keepalive=10,3 dscp=0 clamp-tcp-mss=no dont-fragment=no
3 S ;;; Route to Ferro
dst-address=192.168.8.0/24 pref-src=192.168.2.1 gateway=ipip1 gateway-status=ipip1 unreachable distance=1 scope=30 target-scope=10
+1 -- too many people in this thread seem to be blindly upgrading critical infrastructure without any prior testing in their environment and then are surprised when something unexpected happens. If 6.18 works best for you, good, stay on it until a newer release works best for you.Why upgrade that critical router before testing by yourself on other non critical place ?
I first upgrade my home MT router everything working then update non critical part of network and after that update critical part of network. I know people using today 2.9.27 or 3.30 or 4.17 or 5.26 or 6.22 and there are happy with that version.
Don't upgrade before testing on other non critical place.
RouterBoard have option to make partition make two partition one for testing other with working system tested before is something wrong happens just switch back to tested working system.
http://wiki.mikrotik.com/wiki/Manual:Partitions
If is something very very important upgrade must me planed, tested, prepared with replaced device ready to replace.... upgrading critical part of network without precise planing is crazy. It is nice button upgrade just to try sorry but on some places I can afford that luxury.
Event testing do not help. This week I moved an ethernet interface out of a bridge on a RB1200 with 6.15 and gave it a new IP. This device ran since upgrade without problem. The port looks like it works but do not forward any traffic. Using another port works then with this IP. Testing/sniffing took me 4h with driving. Now I put a second IP on the second working port -> RB1200 reboots with kernel fault ...+1 -- too many people in this thread seem to be blindly upgrading critical infrastructure without any prior testing in their environment and then are surprised when something unexpected happens. If 6.18 works best for you, good, stay on it until a newer release works best for you.Why upgrade that critical router before testing by yourself on other non critical place ?
I first upgrade my home MT router everything working then update non critical part of network and after that update critical part of network. I know people using today 2.9.27 or 3.30 or 4.17 or 5.26 or 6.22 and there are happy with that version.
Don't upgrade before testing on other non critical place.
RouterBoard have option to make partition make two partition one for testing other with working system tested before is something wrong happens just switch back to tested working system.
http://wiki.mikrotik.com/wiki/Manual:Partitions
If is something very very important upgrade must me planed, tested, prepared with replaced device ready to replace.... upgrading critical part of network without precise planing is crazy. It is nice button upgrade just to try sorry but on some places I can afford that luxury.
I administer around 200 Mikrotik devices all of version 5.26. I live with Mikrotiks from version 2. Currently I have stopped buying additional devices, because of all this mess around version 6. I want stable version because I do not want to be tester of RouterOS. I also develop software in team of 20 people, but what I see here is very sad from customer's point of view. I have also one experience with support - I have sent ticket wihout response from support. Support started to response right after my complaints in this forum. I would like Mikrotik to rethink their strategy, because current status is IMHO unsustainable.Support Request Instructions
When contacting us at support[at]mikrotik.com:
Make sure that you have the latest version of the RouterOS. If you don't have it, upgrade your router to the latest version and check if the problem still persists!
... And for me other special button: "take my chance" that randomly selects one of 6.x versions and immediately installs it.... Hahaha... Why not have some fun?Maybe MT need to add some more functionality to Update menu - version selection with pros and cons (known bugs); there can be also some test/alpha/beta/stable etc selection, so everyone could decide Update or not to update and which version to update? Just suggestion..
/system ntp client set enabled=yes
/system ntp client set enabled=yes
failure: IP address of NTP server is missing
have you set MTU for 6to4 tunnel to value suggested by HE (check configuration example)6to4 tunnel NO fixed !!!
Router OS 6.22 Router OS 6.19 (6to 4 work OK)
Code: Select all[janiskr@MikroTIk] /ipv6 route> print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable # DST-ADDRESS GATEWAY DISTANCE 0 A S ::/0 2001:db8:beef:bee::1 1 1 ADC 2001:db8:beef:bee::/64 he-tb 0 2 ADC 2001:db8:beef:beef::/64 lo 0 [janiskr@MikroTIk] /ipv6 route> /ping [:resolve ipv6.google.com] HOST SIZE TTL TIME STATUS 2a00:1450:400f:804::1003 56 53 53ms echo reply 2a00:1450:400f:804::1003 56 53 54ms echo reply sent=2 received=2 packet-loss=0% min-rtt=53ms avg-rtt=53ms max-rtt=54ms [janiskr@MikroTIk] /ipv6 route> /interface 6to4 print Flags: X - disabled, R - running # NAME MTU ACTUAL-MTU LOCAL-ADDRESS REMOTE-ADDRESS KEEPALIVE DSCP 0 R he-tb 1280 1280 a.b.c.s e.f.g.h inherit
So, your advantage is to wait for others to find the failures of that specific versions. If everybody thinks like you, MT will always fail with every customer (ISP).We normally wait 3-5 releases before upgrading. We have another unit on standby with the same config incase anything goes wrong. We also test it on another piece of identical hardware before upgrading.
Do you also have statistics how many devices were downgraded? I'm just asking because from cca v6.7 most of my upgrades goes like:we have statistics how many devices have upgraded. I don't want to argue about this, please let us concentrate on the remaining issues here. Let us discuss the release rather than nitpickIt's because others are not beta testers unlike us.
There are now definitely more than 10. And much more out there who have no idea about any forum or support or they simply gave up already. I certainly don't blame them.Most people having prolems are in this forum, you can see how many there are, less than 10.
I completely agree with everything you just said. However, at the same time, if you DO upgrade *because* the new version fixes a problem that you have been having, but it introduces a new problem in another area, then you are stuck between a rock and a hard place.MY GOD - to all the whingers - if a current or older version is working for you - DO NOT UPGRADE.
ONLY UPGRADE IF THE NEW VERSION FIXES A PROBLEM OR INTRODUCES A NEEDED FEATURE.
As any good net-ops team will do though - you should test your config in the lab before pushing out to live.
That's not my problem.So, your advantage is to wait for others to find the failures of that specific versions. If everybody thinks like you, MT will always fail with every customer (ISP).We normally wait 3-5 releases before upgrading. We have another unit on standby with the same config incase anything goes wrong. We also test it on another piece of identical hardware before upgrading.
Bingo! Exactly! (Sorry for the redundancy) And there is more in my case: I have two CCR1036 in lab to test the new versions. Get the production backups and restore to the test units and all works fine. Upgrade the production units gave me instant bricked routers.I completely agree with everything you just said. However, at the same time, if you DO upgrade *because* the new version fixes a problem that you have been having, but it introduces a new problem in another area, then you are stuck between a rock and a hard place.MY GOD - to all the whingers - if a current or older version is working for you - DO NOT UPGRADE.
ONLY UPGRADE IF THE NEW VERSION FIXES A PROBLEM OR INTRODUCES A NEEDED FEATURE.
As any good net-ops team will do though - you should test your config in the lab before pushing out to live.
I am currently in this situation right now with two different routers (both with different problems): if I stick with an older version, there is a particular bug in both cases that is a constant headache both for me and for my customer to deal with, but if I upgrade to a version that fixes that particular bug, then an entirely new regression is introduced. So I'm darned if I do and darned if I don't. There is no one version out there that gives me a bug-free experience in either case; if there was, I would run it. And I think that is what most people are frustrated with: the number of new regressions that keep getting introduced whenever they do an upgrade (often at the suggestion of MikroTik support) in order to fight off a past regression. We are forced to choose the lesser of 2 evils.
-- Nathan
The problem is, not everything is in the change log. Like the changes to multi core support.read the changelog - if you don't need a feature/fix, don't upgrade if your setup is working fine. If you do, well, report problems back in a non-whiny way with the data necessary for MT to actually fix your problem. make sure you have a backup of your Know-Good config BEFORE you attempt an upgrade. And be ready to downgrade if you do run into trouble.
Even so, don't whine about it -- do something helpful.The problem is, not everything is in the change log. Like the changes to multi core support.read the changelog - if you don't need a feature/fix, don't upgrade if your setup is working fine. If you do, well, report problems back in a non-whiny way with the data necessary for MT to actually fix your problem. make sure you have a backup of your Know-Good config BEFORE you attempt an upgrade. And be ready to downgrade if you do run into trouble.
Where was I whining?Even so, don't whine about it -- do something helpful.The problem is, not everything is in the change log. Like the changes to multi core support.read the changelog - if you don't need a feature/fix, don't upgrade if your setup is working fine. If you do, well, report problems back in a non-whiny way with the data necessary for MT to actually fix your problem. make sure you have a backup of your Know-Good config BEFORE you attempt an upgrade. And be ready to downgrade if you do run into trouble.
I have absolutely no issues with my CCR's and high cpu usage with DNS like others are saying (so multi core support is just fine for me) If I did, I would submit a supout to support and let them debug the issue. That would help me, and it would help others with the same issue.
Simply whining doesn't solve anything.
i have Metal 2SHPn after this update the CCQ 71/50 % before the upgrade 100/100 %What's new in 6.22 (2014-Nov-11 14:46):
*) new RouterBOOT firmware for Metal 2SHPn to improve wireless stability;
.
Which CCR? I have 4x CCR1009-8G-1S-1S+ and 2x CCR1016-12G, all running 6.22, none of them rebooting.CCR series still have problems with randomly rebooting.
did you try to format the disk? maybe the files do actually exist, but are marked as "deleted" by some other OS951G-2HnD with 6.22
What the hell?
I inserted USB flash drive (8Gb), formatted it (FAT32) and got a mess in files.
Cannot delete any of those files (because they don't exist obviously)
Also I don't know how to walk throught the directory structure in webfig ...
I noticed this too!.951G-2HnD with 6.22
What the hell?
I inserted USB flash drive (8Gb), formatted it (FAT32) and got a mess in files.
Cannot delete any of those files (because they don't exist obviously)
Also I don't know how to walk throught the directory structure in webfig ...
This can be argued. Home routers usually don't have as complex settings as company routers do. And it is almost never the most commong router thing that is not working but somethung more specific but still very important.Why upgrade that critical router before testing by yourself on other non critical place ?
I first upgrade my home MT router everything working then update non critical part of network and after that update critical part of network. I know people using today 2.9.27 or 3.30 or 4.17 or 5.26 or 6.22 and there are happy with that version.
Don't upgrade before testing on other non critical place.
RouterBoard have option to make partition make two partition one for testing other with working system tested before is something wrong happens just switch back to tested working system.
http://wiki.mikrotik.com/wiki/Manual:Partitions
If is something very very important upgrade must me planed, tested, prepared with replaced device ready to replace.... upgrading critical part of network without precise planing is crazy. It is nice button upgrade just to try sorry but on some places I can afford that luxury.
Yes, I've tried to format several times it while plugged in the router. And it shows 100% ok and bunch of these files.did you try to format the disk? maybe the files do actually exist, but are marked as "deleted" by some other OS951G-2HnD with 6.22
im have same problem -(I have problems in address-lists and dhcp from 6.19 and all higher versions later. I submitted a report of the problem (Ticket#2014110466000984) to the v6.21.1. I tested the new version 6.22 right now and surprise: nothing has changed.
I have heard people talk here in "BugOS" to refer to "RouterOS" and tend to agree with them, unfortunately.
Confirmed, address display for /tool torch is somehow messy (src-address is 192.168.230.1, dst-address not shown). The display within Winbox is ok.
[admin@MikroTik] > /tool torch interface=WAN dst-address=0.0.0.0/0
MAC-PROTOCOL SRC-ADDRESS TX RX TX-PACKETS RX-PACKETS
ip 2.4kbps 1840bps 2 2
2.4kbps 1840bps 2 2
[admin@MikroTik] > /tool torch interface=WAN src-address=0.0.0.0/0
MAC-PROTOCOL TX RX TX-PACKETS RX-PACKETS
ip 4.2kbps 920bps 2 1
4.2kbps 920bps 2 1
[admin@MikroTik] > /tool torch interface=WAN src-address=0.0.0.0/0 dst-address=0.0.0.0/0
MAC-PROTOCOL SRC-ADDRESS TX RX TX-PACKETS RX-PACKETS
ip 192.168.230.1 4.6kbps 920bps 2 1
4.6kbps 920bps 2 1
/interface ethernet switch port> print stats
name: ether2-skybox ether3-tv ether4-ap ether5-trunk switch1-cpu
driver-rx-byte: 0 0 0 1 359 887 146
driver-rx-packet: 0 0 0 6 157 431
driver-tx-byte: 0 0 0 7 683 300 763
driver-tx-packet: 0 0 0 8 133 653
rx-bytes: 0 0 0 0
rx-too-short: 0 0 0 0
rx-64: 0 0 0 0
rx-65-127: 0 0 0 0
rx-128-255: 0 0 0 0
rx-256-511: 0 0 0 0
rx-512-1023: 0 0 0 0
rx-1024-1518: 0 0 0 0
rx-1519-max: 0 0 0 0
rx-too-long: 0 0 0 0
rx-broadcast: 0 0 0 0
rx-pause: 0 0 0 0
rx-multicast: 0 0 0 0
rx-fcs-error: 0 0 0 0
rx-align-error: 0 0 0 0
rx-fragment: 0 0 0 0
rx-overflow: 0 0 0 0
tx-bytes: 0 0 0 0
tx-64: 0 0 0 0
tx-65-127: 0 0 0 0
tx-128-255: 0 0 0 0
tx-256-511: 0 0 0 0
tx-512-1023: 0 0 0 0
tx-1024-1518: 0 0 0 0
tx-1519-max: 0 0 0 0
tx-too-long: 0 0 0 0
tx-broadcast: 0 0 0 0
tx-pause: 0 0 0 0
tx-multicast: 0 0 0 0
tx-underrun: 0 0 0 0
tx-collision: 0 0 0 0
tx-excessive-collision: 0 0 0 0
tx-multiple-collision: 0 0 0 0
tx-single-collision: 0 0 0 0
tx-excessive-deferred: 0 0 0 0
tx-deferred: 0 0 0 0
tx-late-collision: 0 0 0 0
/interface ethernet> print stats
name: ether1-gateway ether2-skybox ether3-tv ether4-ap ether5-trunk
driver-rx-byte: 7 288 415 796 0 0 0 1 361 018 164
driver-rx-packet: 8 072 759 0 0 0 6 165 323
driver-tx-byte: 831 390 476 0 0 0 7 692 641 941
driver-tx-packet: 5 676 361 0 0 0 8 143 470
rx-bytes: 0 0 0 0
rx-too-short: 0 0 0 0
rx-64: 0 0 0 0
rx-65-127: 0 0 0 0
rx-128-255: 0 0 0 0
rx-256-511: 0 0 0 0
rx-512-1023: 0 0 0 0
rx-1024-1518: 0 0 0 0
rx-1519-max: 0 0 0 0
rx-too-long: 0 0 0 0
rx-broadcast: 0 0 0 0
rx-pause: 0 0 0 0
rx-multicast: 0 0 0 0
rx-fcs-error: 0 0 0 0
rx-align-error: 0 0 0 0
rx-fragment: 0 0 0 0
rx-overflow: 0 0 0 0
tx-bytes: 0 0 0 0
tx-64: 0 0 0 0
tx-65-127: 0 0 0 0
tx-128-255: 0 0 0 0
tx-256-511: 0 0 0 0
tx-512-1023: 0 0 0 0
tx-1024-1518: 0 0 0 0
tx-1519-max: 0 0 0 0
tx-too-long: 0 0 0 0
tx-broadcast: 0 0 0 0
tx-pause: 0 0 0 0
tx-multicast: 0 0 0 0
tx-underrun: 0 0 0 0
tx-collision: 0 0 0 0
tx-excessive-collision: 0 0 0 0
tx-multiple-collision: 0 0 0 0
tx-single-collision: 0 0 0 0
tx-excessive-deferred: 0 0 0 0
tx-deferred: 0 0 0 0
tx-late-collision: 0 0 0 0
Very clever, but you really think that I didn't test new version before I upgrade a critical router?Why upgrade that critical router before testing by yourself on other non critical place ?
I first upgrade my home MT router everything working then update non critical part of network and after that update critical part of network. I know people using today 2.9.27 or 3.30 or 4.17 or 5.26 or 6.22 and there are happy with that version.
Don't upgrade before testing on other non critical place.
RouterBoard have option to make partition make two partition one for testing other with working system tested before is something wrong happens just switch back to tested working system.
http://wiki.mikrotik.com/wiki/Manual:Partitions
If is something very very important upgrade must me planed, tested, prepared with replaced device ready to replace.... upgrading critical part of network without precise planing is crazy. It is nice button upgrade just to try sorry but on some places I can afford that luxury.
Why do you the update of a critical router not during a maintenance windows? Even a tiny configuration change to a critical router i would only do during a maintenance windows having an implementation- and a rollback-plan. So if it is not working i roll back. For systems that are critical i have spare hardware. Those hardware is also be used for tests in the lab.
Very clever, but you really think that I didn't test new version before I upgrade a critical router?
I have tested it on 3 other Routerboards... there is all ok, but on this very important router it ***** everything.
So next time please try to think before post some stupidity
Steen, you are a partner of Mikrotik?Hello Folks!
60% of our devices successfully updated to RoS6.22, rock solid for a week: rb333, rb411,rb433,rb600,rb750,crs and ccr. Remaining will be taken upcoming weekend.
+1Very clever, but you really think that I didn't test new version before I upgrade a critical router?Why upgrade that critical router before testing by yourself on other non critical place ?
I first upgrade my home MT router everything working then update non critical part of network and after that update critical part of network. I know people using today 2.9.27 or 3.30 or 4.17 or 5.26 or 6.22 and there are happy with that version.
Don't upgrade before testing on other non critical place.
RouterBoard have option to make partition make two partition one for testing other with working system tested before is something wrong happens just switch back to tested working system.
http://wiki.mikrotik.com/wiki/Manual:Partitions
If is something very very important upgrade must me planed, tested, prepared with replaced device ready to replace.... upgrading critical part of network without precise planing is crazy. It is nice button upgrade just to try sorry but on some places I can afford that luxury.
I have tested it on 3 other Routerboards... there is all ok, but on this very important router it ***** everything.
So next time please try to think before post some stupidity
Very clever, but you really think that I didn't test new version before I upgrade a critical router?
I have tested it on 3 other Routerboards... there is all ok, but on this very important router it ***** everything.
So next time please try to think before post some stupidity
Please upgrade the RouerBoard firmware to v3.19 and check if the situation gets better.Have 2SHPn as well.
All the sudden the past two versions and even RC23 are all causing SSID not to be broadcasted or allow attaching UNTIL REBOOT...
This is happening now very very very often... Had to ROLL BACK TO LAST V.5 to gain stability of SSID/RADIO broadcasting..
2SHPn IS NOT FIXED, STILL LOOSING SSID/RADIO (I do not have CPU 50/100 issue.., Clients just cannot connect and do not see SSID)
Pretty much this. You need to duplicate the device. As much as a pain in the ass that is to do. We don't even make changes to our core routers during business hours, let alone any upgrade.Why do you the update of a critical router not during a maintenance windows? Even a tiny configuration change to a critical router i would only do during a maintenance windows having an implementation- and a rollback-plan. So if it is not working i roll back. For systems that are critical i have spare hardware. Those hardware is also be used for tests in the lab.
Very clever, but you really think that I didn't test new version before I upgrade a critical router?
I have tested it on 3 other Routerboards... there is all ok, but on this very important router it ***** everything.
So next time please try to think before post some stupidity
If i'm afraid something breaks i do a real test:
1. Export the config from the live system.
2. Replace the IPs with the ones from the test range. Just a search/replace with a text editor.
3. Import the new config into the test/spare device.
4. Do the planned change/upgrade on the test device.
Over all i agree that MT can improve the testing before they release a version. Some bugs are visible without a special config and should be found by doing basic tests.
I have problem with Intel Corporation 82576 Gigabit Network card after upgrade to: 6.15, 6.19, 6.22 MT lost 2-5% packet on this interface. 5.26 works fineNo, we have packet loss only on version 6.8-6.22.Versions 6.5-6.7 works stable. After 20-30 minutes MT start drops packet on all interfaces. In log file we see next message "105 (no buffer space available)". We try start VM on next servers:What about this problem?
http://forum.mikrotik.com/viewtopic.php?f=2&t=86119If you have packet loss in all versions, maybe there is some sort of hardware problem? if you have the chance, try another machine or at least other NIC
1. Supermicro X8DTT 12CPUs x 2.4 GHz Processor Type Inter(R) Xeon(R) CPU E5645 @ 2.40GHZ
Intel Corporation 82576 Gigabit Network Connection
RB433UAHWhat's new in 6.23rc7 (2014-Nov-25 08:26):
*) files - allow to move files between different disks in winbox;
*) dhcpv4 server - fix adding address lists;
*) dhcpv4 server - make radius classless static route tag as dhcp vendor specific;
*) smb - fixed HDD used/free space reporting
*) made powerpc metarouters work again (were broken in v6.22);
*) disks - fixed fat32 formatting where some bogus files with strange names were created
(to delete existing files reformatting is needed);
*) disks - fixed problem where some of USB disks were not recognized;
*) fetch - allow checking certificate trust without crl checking;
*) userman - fix more web session problems when user uses
customer and administrator interfaces at the same time;
*) snmp - fix external storage info reporting;
*) snmp - fix bulk walk problem introduced in v6.20;
*) fix tunnels - keep keepalive disabled for existing tunnels when upgrading;
*) fix tunnels - mtu for eoip tunnels was not allowed
to be set less than 1280 since 6.20;
*) using routing-marks could lead to tunnel loop detection to turn off tunnels;
What kind of configuration was deleted? Give a few examples what was lostUpgrading Omnitik from 5.24 to 6.13 works fine.
But after that, upgrade from 6.13 to 6.22 delete all my wlan1 configuration, exactly in the same way that 5.26 to 6.14.....
6to4 tunnel NO fixed !!!
Router OS 6.22 Router OS 6.19 (6to 4 work OK)
6to4 tunnel NO fixed !!!
Router OS 6.22 Router OS 6.19 (6to 4 work OK)
Hi miszak,
I have same problems; you can post the ipv6 configuration?
for me, working only with version 6.15; have some problems with 6.20.
Thanks.
/ip address add address=AA.BB.CC.DD/24 interface=ether1 /ip route add gateway=AA.BB.CC.GG /interface 6to4 add local-address=AA.BB.CC.DD mtu=1480 name=6to4 /ipv6 address add address=2002:AABB:CCDD::1/16 advertise=no interface=6to4 /ipv6 route add distance=1 dst-address=2000::/3 gateway=::192.88.99.1%6to4Reset config:
/system reset-configuration run-after-reset=6to4bug.rscAnd then try to ping some IPv6 address:
[admin@MikroTik] > /ping address=2002:ca0c:1dea::1 count=1 HOST SIZE TTL TIME STATUS 2002:59b9:e186::1 104 64 0ms hop limit exceeded sent=1 received=0 packet-loss=100% [admin@MikroTik] > /ping address=2a02:610:7501:1000::2 count=1 HOST SIZE TTL TIME STATUS no route to host sent=1 received=0 packet-loss=100%This is how it looks on 6.22, pinging other 6to4 address fails with "hop limit exceeded", native one fails with "no route to host". It works fine on 6.19 and lower.
Same problem i have, sometimes ....Upgrading Omnitik from 5.24 to 6.13 works fine.
But after that, upgrade from 6.13 to 6.22 delete all my wlan1 configuration, exactly in the same way that 5.26 to 6.14.....
My thoughts exactly.Steen, you are a partner of Mikrotik?Hello Folks!
60% of our devices successfully updated to RoS6.22, rock solid for a week: rb333, rb411,rb433,rb600,rb750,crs and ccr. Remaining will be taken upcoming weekend.
Or you're a lucky guy.
*) dhcpv4 server - fix adding address lists from radius;
Please try to install RouterOS v6.23rc10 and test if the issue is fixed as we have fixed only issue regarding 802.11ac driver.Wireless clients randomly stop transmitting when connected to R11e-5HacD. Only fix is to disconnect and reconnect. Tested Yoga 3 Pro, iPad mini, Macbook pro, Apple tv, Netgear PTV3000, and Droid turbo. Also tried all the latest betas with the same results.
(the card is in a 912UAG-2HPnD)
Try, test and report back! LOLPlease try to install RouterOS v6.23rc10 and test if the issue is fixed as we have fixed only issue regarding 802.11ac driver.Wireless clients randomly stop transmitting when connected to R11e-5HacD. Only fix is to disconnect and reconnect. Tested Yoga 3 Pro, iPad mini, Macbook pro, Apple tv, Netgear PTV3000, and Droid turbo. Also tried all the latest betas with the same results.
(the card is in a 912UAG-2HPnD)
Everyone, I believe .EDIT: I have 2 more 750UPs I could setup in a lab environment and see if I couldn't reproduce the issue. Anyone interested?
Please provide more detailed info on this problem to support@mikrotik.com and include a support output file.Hi.
When I update link to 6.22 witch wirelessfp my link loss packet randomly downgrade to 6.12 no problem.
So far so good. No interface lockups but still to early to call it.Please try to install RouterOS v6.23rc10 and test if the issue is fixed as we have fixed only issue regarding 802.11ac driver.Wireless clients randomly stop transmitting when connected to R11e-5HacD. Only fix is to disconnect and reconnect. Tested Yoga 3 Pro, iPad mini, Macbook pro, Apple tv, Netgear PTV3000, and Droid turbo. Also tried all the latest betas with the same results.
(the card is in a 912UAG-2HPnD)
Hello!After upgrading to 6.22 I am getting warnings for "transmit loop detected, downing interface for 60 seconds" just as described in the logs. This is with a GRE tunnel that between two mikrotiks that was working before.
The tunnel is from one location with 2 internet providers to another location with a single internet provider. The first location has 2 tunnels setup with difference source addresses but the same destination address and the second location with the same source address but 2 different destination address. One of the tunnels works fine but the second is now useless. It was setup with a route to prefer our favored internet provider and to failover to the second if the primary's link failed.
What exactly is the loop detection supposed to do?
Hello!After upgrading to 6.22 I am getting warnings for "transmit loop detected, downing interface for 60 seconds" just as described in the logs. This is with a GRE tunnel that between two mikrotiks that was working before.
The tunnel is from one location with 2 internet providers to another location with a single internet provider. The first location has 2 tunnels setup with difference source addresses but the same destination address and the second location with the same source address but 2 different destination address. One of the tunnels works fine but the second is now useless. It was setup with a route to prefer our favored internet provider and to failover to the second if the primary's link failed.
What exactly is the loop detection supposed to do?
I had the same problem, and found reason of problem. In my case transmit loop detection was triggered because i used route-mark for making routing decision. After i've made static routes for my gre destinations - problem disappeared.
/interface 6to4
add clamp-tcp-mss=no comment="Hurricane Electric IPv6" \
local-address=<Static Public IPv4 Address> mtu=1280 name=sit1 remote-address=\
<Server IPv4 Address>
/ip neighbor discovery
set sit1 comment="Hurricane Electric IPv6"
/ipv6 address
add address=<Client IPv6 Address> comment="IPv6 Gateway" interface=sit1
add address=<Routed /64> comment="IPv6 Network 1" interface=\
ether2-master-local
add address=<Routed /64>1 comment="IPv6 Network 2" interface=\
ether5-slave-local
/ipv6 firewall filter
add chain=input comment="Allow established connections" connection-state=\
established
add chain=input comment="Allow related connections" connection-state=related
add chain=input comment="Router Allow IPv6 ICMP" protocol=icmpv6
add chain=forward comment="Router Allow IPv6 ICMP" protocol=icmpv6
add chain=input comment="Allow UDP" protocol=udp
add chain=forward comment="Allow HTTP" dst-address=\
<server web>/128 dst-port=80 protocol=tcp
add action=log chain=input disabled=yes in-interface=sit1
add action=drop chain=input comment="Drop everything else"
add chain=forward comment="Allow any to internet" out-interface=sit1
add chain=forward comment="Allow established connections" connection-state=\
established
add chain=forward comment="Allow related connections" connection-state=\
related
add action=drop chain=forward
add action=log chain=output disabled=yes log-prefix="[DROP IPv6] " \
out-interface=sit1
/ipv6 firewall mangle
add action=change-mss chain=forward in-interface=sit1 new-mss=1220 protocol=\
tcp tcp-flags=syn tcp-mss=1221-65535
add action=change-mss chain=forward new-mss=1220 out-interface=sit1 protocol=\
tcp tcp-flags=syn tcp-mss=1221-65535
/ipv6 nd
set [ find default=yes ] advertise-dns=yes hop-limit=64
/ipv6 route
add distance=1 gateway=<Server IPv6 Address>
/ipv6 route
add dst-address=::/0 gateway=<Server IPv6 Address>