Community discussions

 
jansat
just joined
Topic Author
Posts: 9
Joined: Tue Jul 09, 2013 1:33 pm
Location: Netherlands

Feature request for v7.x

Sun Feb 09, 2014 9:30 pm

Need a setting in routeros and userman to change the log writing.
I have setup a hotspot and userman but when a user connect to the hotspot userman write every minut a log I want to have the possibility for some logging to change the write time to disk or usb disk.
 
User avatar
rickfrey
Trainer
Trainer
Posts: 610
Joined: Sun Feb 14, 2010 11:41 pm
Location: Van, Texas
Contact:

Re: Feature request for v7.x

Sun Feb 16, 2014 7:18 am

Directions for changing the settings for the log can be found here:
http://wiki.mikrotik.com/wiki/Manual:System/Log
Unfortunately, you can move the log to a USB device and that is documented here:
http://wiki.mikrotik.com/wiki/Manual:Store

You can move the log to a remote log server and you can use the not (!) feature (i.e. not the hotspot).
Launch your company forward with professional training!
http://rickfreyconsulting.com/product-c ... raining-2/
 
tfn220189
just joined
Posts: 5
Joined: Sun Feb 09, 2014 12:48 am

Re: Feature request for v7.x

Wed Mar 12, 2014 12:41 am

Have a chance to read more than 4096B of files using command strings
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 1805
Joined: Mon Jan 14, 2008 1:53 pm
Location: Straya
Contact:

Re: Feature request for v7.x

Wed Mar 12, 2014 1:27 am

Let me just start my broken record...

It would be great for RouterOS 7 to have:
- IPSEC Virtual Tunnel Interfaces (Like Cisco/Juniper/Fortinet/Vyatta/Ubiquiti)
- Xauth + RADIUS support
- Encrypt/IPSEC Policy action
- VRF aware PPP
- VRF aware services (WinBox, SSH, DNS)
- RIPv2 as a PE-CE protocol (RIP instances)
- Make IPv6 loopback/ospf behavior the same as Cisco/Juniper
- Equivalents of the Cisco/JunOS commands:
show ip bgp vpnv4 vrf vrf-blah-wan neighbors 172.16.95.1 advertised-routes       (Routes advertised)
show ip bgp vpnv4 vrf vrf-blah-wan neighbors 172.16.95.1 received-routes (Routes received)
show ip bgp vpnv4 vrf vrf-blah-wan neighbors 172.16.95.1 routes          (Routes inserted)
- MPLS Fast Re-Route capability
- Routing filter action "Add to Address List"

Im sure the great team at Mikrotik are going to give us at least a couple of the above features :)
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet FTCNA, FCNSP, FCT | Extreme Networks ENA
 
phil
just joined
Posts: 19
Joined: Fri Feb 15, 2013 7:27 pm

Re: Feature request for v7.x

Fri Mar 14, 2014 8:25 am

Can extend format of EOIP remote-address be a FQDN, not only IPv4?

Many thanks!!
 
User avatar
crtee
just joined
Posts: 13
Joined: Wed Nov 14, 2012 2:00 am
Location: Germany

Re: Feature request for v7.x

Fri Mar 14, 2014 9:40 am

It would be great for RouterOS 7 to have:
- IPSEC Virtual Tunnel Interfaces (Like Cisco/Juniper/Fortinet/Vyatta/Ubiquiti)
[...]
- Encrypt/IPSEC Policy action
- VRF aware PPP
- VRF aware services (WinBox, SSH, DNS)
+1 for all of those and I may add:
- Ability to create PPP interfaces in a specific VRF via RADIUS-Attribute
- full L2TP LAC functionality (for forwarding PPPoE sessions via L2TP)
- OSPFv3 for IPv6 and IPv4 address families
- maybe a longer evaluation period, 1 week or so, 24h just aren't enough sometimes for evaluation of some features.
 
User avatar
EMOziko
Member Candidate
Member Candidate
Posts: 129
Joined: Mon Aug 23, 2010 9:42 pm
Location: Georgia

Re: Feature request for v7.x

Sun Mar 16, 2014 7:29 pm

We want new versions of The Dude!!!!!!!
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 1805
Joined: Mon Jan 14, 2008 1:53 pm
Location: Straya
Contact:

Re: Feature request for v7.x

Mon Mar 17, 2014 3:54 am

- Ability to create PPP interfaces in a specific VRF via RADIUS-Attribute
- full L2TP LAC functionality (for forwarding PPPoE sessions via L2TP)
- OSPFv3 for IPv6 and IPv4 address families
- maybe a longer evaluation period, 1 week or so, 24h just aren't enough sometimes for evaluation of some features.
Haha, great minds. I should have been more specific on the PPP stuff, yes there should be support for specifying which VRF via a RADIUS VSA.

Im all for the longer eval period, but Mikrotik should introduce and enforce support contracts so they can make some money off RouterOS. They could offer 3 months support with each RouterBoard purchased and then require a valid support contract per device to be able to download updates, and to log tickets. Just like Cisco, Juniper, Fortinet do.

This would allow them to hire more developers, more support staff, and generally kick more ass.
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet FTCNA, FCNSP, FCT | Extreme Networks ENA
 
enc
just joined
Posts: 16
Joined: Sun Feb 09, 2014 8:30 pm

Re: Feature request for v7.x

Wed Mar 19, 2014 1:24 pm

Interfaces für IPSEC-Tunnels. So that the IN-Interface in the Firewall-rules is not the WAN-Interface and we could better match the ipsec-traffic
 
User avatar
dfroe
newbie
Posts: 33
Joined: Sun Feb 23, 2014 2:37 am
Location: Germany

Re: Feature request for v7.x BGP advertise-inactive

Thu Mar 20, 2014 12:59 am

BGP option like Juniper "advertise-inactive".
At the moment it is not possible to advertise learned BGP routes to other BGP neighbors if that particular route is not in the active routing table because it is overriden by OSPF with better administrative distance.
Other bgp impementations (Cisco, Fortinet, Quagga) always advertise all learned BGP routes unless they are explicitly filtered out.
This advertise-inactive option is vital for setups where you run OSPF and iBGP within your AS and redistribute BGP into OSPF.
 
szastan
newbie
Posts: 32
Joined: Sat Aug 06, 2011 7:44 pm
Location: Gdansk, Poland
Contact:

Re: Feature request for v7.x BGP advertise-inactive

Thu Mar 20, 2014 1:08 pm

BGP option like Juniper "advertise-inactive".
At the moment it is not possible to advertise learned BGP routes to other BGP neighbors if that particular route is not in the active routing table because it is overriden by OSPF with better administrative distance.
Other bgp impementations (Cisco, Fortinet, Quagga) always advertise all learned BGP routes unless they are explicitly filtered out.
This advertise-inactive option is vital for setups where you run OSPF and iBGP within your AS and redistribute BGP into OSPF.
+1, apart from that, in my opinin MikroTik should complement its BGP implementation, for example on displaing routing paths. Without that, operators wouldn't be happy to put CCR's in core.
 
maxspeed
just joined
Posts: 15
Joined: Mon Dec 17, 2012 3:19 am

Re: Feature request for v7.x

Mon Mar 24, 2014 1:45 pm

Hi,

It would be a must for mikrotik products ....

please could you add 6RD (ipv6 rapid deployment) available for many ISP :-)

Thank you

maxspeed
 
User avatar
NathanA
Forum Veteran
Forum Veteran
Posts: 787
Joined: Tue Aug 03, 2004 9:01 am

Re: Feature request for v7.x

Tue Mar 25, 2014 6:37 am

Im all for the longer eval period, but Mikrotik should introduce and enforce support contracts so they can make some money off RouterOS. They could offer 3 months support with each RouterBoard purchased and then require a valid support contract per device to be able to download updates, and to log tickets. Just like Cisco, Juniper, Fortinet do.
I strongly, strongly disagree. Although things are far from perfect in MikroTik land and there are clearly some shortcomings with the current support infrastructure and things they could do to improve it, I would argue that the fact that MikroTik doesn't do business "just like Cisco (*gak!*), Juniper, Fortinet do" is exactly one of the reasons why they already "kick ass". Mandatory support contracts would remove one of MikroTik's core competitive advantages. MikroTik should not aspire to be like Cisco (gag me with a spoon), but rather to disrupt Cisco's own business model and perhaps eventually make them irrelevant.

Here's the thing: enterprise support sucks. And we all know it, so why do we enable businesses to practice this sleazy model by rolling over for them instead of challenging it at the customer level (vote with your wallets, people) and at the business level (as MikroTik, thankfully, seems to be doing)? The reason why it sucks is because it lumps in bug reporting and bug fixing with "how do I use your product?" type questions, even though these two types of support tickets are fundamentally different things. Now, I know why most of these companies do it: it is an additional (and often lucrative) revenue stream, it locks the customer in even more, and 90% of the time, people who think they've found a bug are wrong and are just being idiots and not using the product correctly, so these companies might as well charge everybody for support and assume most tickets are not going to be defect reports to start with. Also, companies like Cisco et al. make 99% of their sales to enterprises that need their product in order to even run their business (ISPs, etc.), so it's worth it to them to pay whatever it takes to ensure that Cisco is responsive to them and their needs.

But as a customer, it makes me livid when companies do this, because it essentially penalizes customers who have been legitimately impacted by an actual software bug. It essentially amounts to extortion. Now of course end-users are responsible for their own idiocy, so, sure: go ahead and charge customers to answer their non-defect-related tickets. That's fair game. But charging me, the customer, to fix your own error? That's low. Bug fixes should be free: I bought and paid for this product that you advertized as being able to do X, Y, and Z, but Y is broken because of something wrong that your engineers did and which got shipped because of a lack of sufficient testing and QA on your part, and you're telling me that I now need to pay an additional sum on top of what I already paid in order to gain access to the update that fixes the problem and which actually makes feature Y usable? Where I come from, that's called "bait and switch", and if I bought your product specifically because it had feature Y in it, then you can bet I'm going to be mad as hell when a company responds this way. It also pisses me off to no end when a company tells me that I need to have a paid support contract in place in order to talk to anyone, even if what I'm doing is trying to help both them and myself by demonstrating to them a defect in their own product. You're going to charge ME for the privilege of telling you about YOUR mistake? I don't think so.

MikroTik doesn't pull this kind of crap, and it's one of the reasons why I continue to find myself an advocate for them and their products even when we hit rough patches (and, believe me: we have had our share of them). In fact, not only is MikroTik good about not doing this very thing, but they take the exact opposite approach: they often reward people who report legitimate issues! Imagine that! The last time I found a bug, I spent a good deal of time (hours) replicating the problem in a lab environment, putting together an absolute minimum config that the bug can be reproduced with along with a detailed description of the symptoms, the underlying problem, and how to reproduce the issue, and sent that to MikroTik support, and after they verified my findings, they rewarded me with a gratis RouterOS license key! Now that's a class act! (Oh, and they didn't try to charge me for the fix they developed for the problem, either.)
This would allow them to hire more developers, more support staff, and generally kick more ass.
I have no problem with MikroTik making money, or wanting to find additional ways to make money. In fact, I very much want them to make money and grow their staff and generally be successful and keep on "kicking ass": after all, given how much we use their product, it's in my interest that they be successful, since when they are successful, we are also successful. However, enforcing mandatory support contracts for any kind of communication with your staff or access to any software updates is absolutely not the right way to increase revenue, nor is it a way to endear yourself to me.

There are a lot of legit not-scummy-and-yet-untapped ways of making additional money that I can think of for MikroTik to pursue. Some of them seem painfully obvious to me, and I have to think that these ideas have also occurred to MikroTik but that they have decided not to pursue them for one reason or another. Here are a couple of off-the-top-of-my-head examples:

1) Start charging people again for major version upgrades (e.g., 6.x -> 7.x). I actually have no problem with this: I should be paying for new features. It's just the minor point-releases within a given series (6.1 -> 6.2) that I have a problem with being charged for, since 99% of these are strictly maintenance/bugfix releases. I think that officially, it is MikroTik's policy that you can only upgrade so far before you need to pay for a new license, but ever since they switched from the time-based licenses (remember those?) to the version-based ones, which happened around the end of the 2.9.x series, they have (to my knowledge) never enforced this licensing policy: every time (and I mean EVERY time) we have upgraded to the next major version on a router where the "upgradeable-to" field of the license says that this should be the last major version series we can use, after the upgrade has finished, that number has ALWAYS gone up. So ever since the 2.8.x days have passed, we have never needed to purchase new licenses on any of our routers to upgrade to the next major version that I can remember. I think it is crazy-generous of MikroTik to do this, and I don't take it for granted, and I'm surprised it has gone on for this long, to be honest.

2) Offer support contracts for premium, PRIORITY support, but don't require them of anybody or make having one mandatory to access software updates you are entitled to/licensed for (minor point-upgrades). If MikroTik offered this, believe it or not, we would be first in line to buy! I have no problem with the concept of paying extra for priority/front-of-the-line support, with guaranteed rapid response and faster ticket turnaround times (or even prioritizing my defect reports and fixes above defect reports filed by people who don't have a priority support contract); I just have a problem with feeling like I'm being coerced into paying somebody to correct their own errors. Several years back, there were a couple of show-stopping RouterOS bugs that we were being severely impacted by and which caused us to lose a lot of goodwill with our own customers on account of the network instability that they caused. We filed ticket after ticket, but responses were slow to come and the problems weren't really being addressed in a timely manner. I understand why today MikroTik can't prioritize our needs above those of other customers when they don't have such a product, but if some customers are willing to pay extra to be helped first, I don't think that's something that MikroTik should ignore. There is a legitimate need for that kind of thing, and companies that can't afford the downtime caused by a software defect absolutely will go to Cisco instead because they will be able to get that kind of support from them (the one advantage to that model).

MikroTik actually used to have a paid support contract option SEVERAL years ago, and it even included support by telephone! But for unknown reasons that they never (to my knowledge) bothered to explain, they got rid of it. It was called the Extended Support Program (ESP), and they killed it around the time they started their certification program...now they just point you at certified MikroTik consultants in your area instead if you need "same-day support", but of course certified consultants don't have greater access to the engineering teams to file bug reports with than I do already as a regular customer. So having certified consultants is not really a sufficient replacement for this program. I'd love it if MikroTik were to bring back the ESP, or something like it.

-- Nathan
 
kellogs
Member Candidate
Member Candidate
Posts: 114
Joined: Sun Jan 04, 2009 10:55 am

Re: Feature request for v7.x

Tue Mar 25, 2014 2:07 pm

multi core bgp
"show ip bgp route" command and process it faster than the current one
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 23946
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: Feature request for v7.x

Tue Mar 25, 2014 2:24 pm

Thanks for the great post, Nathan!

As for the ESP program. We don't outsource our support staff, so when people called us, they were calling our Latvian office, not some guys in a 3rd world country. We decided that questions are much quicker answered if we have the config in front of us, and when the customer has summarized his issues. The average phone call took more than an hour. Not many people could be helped with this approach.
No answer to your question? How to write posts
 
nosovk
Frequent Visitor
Frequent Visitor
Posts: 63
Joined: Wed Jan 25, 2012 11:25 am
Location: Ukraine
Contact:

Re: Feature request for v7.x

Tue Apr 15, 2014 2:10 pm

It would be good to upgrade linux kernel, to have betetter support on VMware ESXi, and to start work in HyperV.
Nowdays we often connect offices via vpn+ospf, but there is no WINS server support in ROS to connect samba shares seamless between offices.
Аренда Програмного обеспечения
https://www.CloudZZ.com
Микротики на Украине оптом
mikrotik.kharkov.ua
 
Zorro
Long time Member
Long time Member
Posts: 676
Joined: Wed Apr 16, 2014 2:43 pm

Re: Feature request for v7.x

Wed Apr 16, 2014 3:52 pm

MacSec and SecureID support in RouterOS for future products with compatible interfaces/PHY.
as mainstream "a must" L2 security thing for both copper and wireless interfaces.
 
timteka
just joined
Posts: 3
Joined: Wed Dec 14, 2011 11:41 am

Re: Feature request for v7.x

Fri Apr 18, 2014 2:10 pm

Firewall based url filtering - the only thing I lack in Mikrotiks.
Up to 36 cores with plenty of RAM and still the need to have Squid for that. Are you kidding on me? :-)
 
andersonlich
Frequent Visitor
Frequent Visitor
Posts: 55
Joined: Thu Feb 26, 2009 1:05 pm

Re: Feature request for v7.x

Tue May 06, 2014 12:50 pm

i hope release v7.x it will be support for:
# RFC 4818, was RFC-ietf-radext-delegated-prefix-05.txt
ATTRIBUTE Delegated-IPv6-Prefix 123 ipv6prefix


:)
 
FernandoSuperGG
newbie
Posts: 42
Joined: Fri Sep 06, 2013 6:51 pm

Re: Feature request for v7.x

Thu May 08, 2014 1:17 am

Allow grouping/categorization of stuff (NAT rules, static routes, etc) in WinBox for better organization. Searching for specific rules in middle of dozens/hundreds takes a lot of time (with the risk of picking up the wrong one). Rule comments only worsens the situation.
 
Fil0sOFF
just joined
Posts: 2
Joined: Thu Nov 28, 2013 10:24 am

Re: Feature request for v7.x

Sun May 11, 2014 11:59 pm

Please add ND Proxy support (RFC 4389) in v7.
It is the essential feature for ipv6 users.
 
radman3000
just joined
Posts: 9
Joined: Thu Nov 01, 2012 11:49 am

Re: Feature request for v7.x

Mon May 12, 2014 2:35 pm

Policy Based Routing for IPv6.

Seriously how is this missing?
 
AlexS
Member Candidate
Member Candidate
Posts: 257
Joined: Thu Oct 10, 2013 7:21 am

Re: Feature request for v7.x

Tue May 13, 2014 5:25 am


2) Offer support contracts for premium, PRIORITY support, but don't require them of anybody or make having one mandatory to access software updates you are entitled to/licensed for (minor point-upgrades). If MikroTik offered this, believe it or not, we would be first in line to buy! I have no problem with the concept of paying extra for priority/front-of-the-line support, with guaranteed rapid response and faster ticket turnaround times (or even prioritizing my defect reports and fixes above defect reports filed by people who don't have a priority support contract); I just have a problem with feeling like I'm being coerced into paying somebody to correct their own errors. Several years back, there were a couple of show-stopping RouterOS bugs that we were being severely impacted by and which caused us to lose a lot of goodwill with our own customers on account of the network instability that they caused. We filed ticket after ticket, but responses were slow to come and the problems weren't really being addressed in a timely manner. I understand why today MikroTik can't prioritize our needs above those of other customers when they don't have such a product, but if some customers are willing to pay extra to be helped first, I don't think that's something that MikroTik should ignore. There is a legitimate need for that kind of thing, and companies that can't afford the downtime caused by a software defect absolutely will go to Cisco instead because they will be able to get that kind of support from them (the one advantage to that model).

-- Nathan
Yes, yes

It would be good to upgrade linux kernel, to have betetter support on VMware ESXi, and to start work in HyperV.

yes yes yes yes please please please, there is an open source package, just compile against your source tree. and support vmxnet3.

Then I can get my 10G
 
EnigmAX
just joined
Posts: 5
Joined: Tue May 20, 2014 9:49 pm

Re: Feature request for v7.x

Mon May 26, 2014 4:12 pm

Hi,

It would be a must for mikrotik products ....

please could you add 6RD (ipv6 rapid deployment) available for many ISP :-)

Thank you

maxspeed
I've sent an e-mail to support@mikrotik.com asking for more information.
The official reply I got was:
from: MikroTik support [Janis Krumins] <support@mikrotik.com>
date: Fri, May 23, 2014 at 3:34 PM

Hello,

currently RouterOS does not support 6rd. It is not scheduled anytime soon.

Regards,
Janis Krumins
 
nexgenappliances
just joined
Posts: 1
Joined: Wed May 28, 2014 4:49 am

Re: Feature request for v7.x

Wed May 28, 2014 4:52 am

+1 to the kernel upgrade. We need support for Intel i210 network interfaces!
 
marrold
Member
Member
Posts: 406
Joined: Wed Sep 04, 2013 10:45 am

Re: Feature request for v7.x

Thu May 29, 2014 4:02 am

Mikrotik should introduce and enforce support contracts so they can make some money off RouterOS. They could offer 3 months support with each RouterBoard purchased and then require a valid support contract per device to be able to download updates, and to log tickets. Just like Cisco, Juniper, Fortinet do.

This would allow them to hire more developers, more support staff, and generally kick more ass.
I would genuinely consider this if it was affordable.
I'm a SIP / VoIP engineer. Feel free to ask questions...
 
presianbg
just joined
Posts: 7
Joined: Mon Jun 02, 2014 7:38 am

Re: Feature request for v7.x

Wed Jun 04, 2014 4:00 pm

My suggestion for the future release is that :

OpenVPN client whith options for only certificate authentication. Many Linux OpenVPN servers are based only on certificates.

GOOD LUCK AND CHEERS !
 
infused
Member
Member
Posts: 305
Joined: Fri Dec 28, 2012 2:33 pm

Re: Feature request for v7.x

Wed Jun 11, 2014 12:27 pm

I disagree that enterprise support sucks.

Support can make or break your business. I'm willing to bet that if you are this way inclined, your business is rather small.

IMO Mikrotik need to offer some type of enterprise support. Otherwise it makes products like their 'carrier grade' products worthless.
Thanks for the great post, Nathan!

As for the ESP program. We don't outsource our support staff, so when people called us, they were calling our Latvian office, not some guys in a 3rd world country. We decided that questions are much quicker answered if we have the config in front of us, and when the customer has summarized his issues. The average phone call took more than an hour. Not many people could be helped with this approach.
That's why you charge for it and hire more people.

VMware and Cisco ring me in a matter of minutes if it's a critical failure. Hours if it's just high priority.

I couldn't run my business without this, why is why Mikrotik is not really used within our core, only at customer sites.

Don't get me wrong. I love the gear, it just needs better support. Generally it takes Mikrotik two weeks to come back to me with a support request. The answer is pretty much always "update to the newest version". Then I never get a response back. That's fine when I'm not paying for support, but there needs to be an option.
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 23946
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: Feature request for v7.x

Wed Jun 11, 2014 12:35 pm

Such things take time. You want us to grow from a 100 people company to Microsoft in a matter of weeks.
No answer to your question? How to write posts
 
infused
Member
Member
Posts: 305
Joined: Fri Dec 28, 2012 2:33 pm

Re: Feature request for v7.x

Wed Jun 11, 2014 12:44 pm

Not at all...

It would just be nice to know it's on the cards somewhere down the line. Mikrotik are getting in to Juniper and Cisco territory now with the CCR's. It seems only fitting.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 1805
Joined: Mon Jan 14, 2008 1:53 pm
Location: Straya
Contact:

Re: Feature request for v7.x

Wed Jun 11, 2014 12:50 pm

Such thinks take time. You want us to grow from a 100 people company to Microsoft in a matter of weeks.
Nobody expects that (well maybe a few people)

Changing the whole company overnight is not possible, but maybe incremental steps towards a better support model will keep people happy.
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet FTCNA, FCNSP, FCT | Extreme Networks ENA
 
User avatar
normis
MikroTik Support
MikroTik Support
Posts: 23946
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: Feature request for v7.x

Wed Jun 11, 2014 1:31 pm

Of course we always keep improving in all areas. It's only a question of "how" we will improve, not "if" :)
No answer to your question? How to write posts
 
User avatar
docmarius
Forum Guru
Forum Guru
Posts: 1209
Joined: Sat Nov 06, 2010 12:04 pm
Location: Timisoara, Romania
Contact:

Re: Feature request for v7.x

Wed Jun 11, 2014 8:15 pm

It's only a question of "how" we will improve, not "if" :)
Normis, that last statement is fit for a corporate motto.
Torturing CCR1009-7G-1C-1S+, RB450G, RB750GL, RB951G-2HnD, RB960PGS, RB260GSP, OmniTIK 5HnD and NetMetal 922UAGS-5HPacD + R11e-5HnD in my home network.
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 1805
Joined: Mon Jan 14, 2008 1:53 pm
Location: Straya
Contact:

Re: Feature request for v7.x

Wed Jun 11, 2014 9:54 pm

It's only a question of "how" we will improve, not "if" :)
Normis, that last statement is fit for a corporate motto.
+1

:)
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet FTCNA, FCNSP, FCT | Extreme Networks ENA
 
pilman
just joined
Posts: 1
Joined: Sun Nov 07, 2010 4:15 pm

Re: Feature request for v7.x

Fri Jun 13, 2014 6:02 pm

1. RouterOS 64Bit version for x86

2. Powerfull Web Proxy ( HTTPS and Video Caching)
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 2944
Joined: Tue Feb 25, 2014 12:49 pm
Location: Capalbio, Tuscany, Italy

Re: Feature request for v7.x

Fri Jun 13, 2014 8:33 pm

1. RouterOS 64Bit version for x86

2. Powerfull Web Proxy ( HTTPS and Video Caching)

1 :lol: not 64bit version for x86, but 64bit for 64bit...
64bit for what do more than x86? Memory limit 2GByte (RouterOS) or 4GByte (x86) is not sufficent for work...?

2 use squid or other, actual model of routerboard are not good for proxy, but for routing...
I made some research about caching on HTTPS, on my country (and I think obviously some others) are illegal because you broken SSL security and the users and the destination server do not know that...
I'm Italian, not English. Sorry for my imperfect grammar.
 
andlommy
just joined
Posts: 21
Joined: Tue Feb 12, 2013 12:14 am

Re: Feature request for v7.x

Sat Jun 28, 2014 12:14 pm

I know what the answer for this is going to be, but it's just to show that the issue is not getting anywhere even if you pretend it does not exist and people still need it.

OpenVPN version update
OpenVPN support for UDP
OpenVPN support for LZO

In openWRT running in MetaRouter it's way too slow
 
sinisa
just joined
Posts: 6
Joined: Sun Apr 17, 2011 12:46 am

Re: Feature request for v7.x

Fri Jul 18, 2014 8:37 pm

I know what the answer for this is going to be, but it's just to show that the issue is not getting anywhere even if you pretend it does not exist and people still need it.

OpenVPN version update
OpenVPN support for UDP
OpenVPN support for LZO

In openWRT running in MetaRouter it's way too slow

+1000 for UDP


Best regards,
Siniša
 
iluvar
newbie
Posts: 29
Joined: Sat Aug 04, 2012 9:31 am

Re: Feature request for v7.x

Sat Jul 19, 2014 9:25 am

MSTP
 
User avatar
ojsa
Member Candidate
Member Candidate
Posts: 181
Joined: Tue Jan 27, 2009 8:53 pm
Location: Norway

Re: Feature request for v7.x

Sat Jul 19, 2014 1:17 pm

I haven't read all suggestions, but a simple way of filtering the log view on routeros would be nice. A way to only see a curtain PREFIX f.ex from the logfile while its running.

in linux something like this.

tail -30f /var/log/syslog | grep -i FW-DROP-LOG-PREFIX1

or even better to see several things

tail -30f /var/log/syslog | egrep -i 'FW-DROP-LOG-PREFIX2|FW-DROP-LOG-PREFIX3'
Network professional - Certified MTCNA, MTCWE MTCTCE, MTCRE, MTCUME and MTCINE. - Wiki Profile
 
23q
Frequent Visitor
Frequent Visitor
Posts: 51
Joined: Thu Sep 02, 2010 2:54 pm
Location: Ukraine

Re: Feature request for v7.x

Sun Jul 20, 2014 11:40 am

 
User avatar
kometchtech
Member Candidate
Member Candidate
Posts: 194
Joined: Sat Jun 15, 2013 4:25 am
Location: Japan
Contact:

Re: Feature request for v7.x

Fri Jul 25, 2014 10:12 pm

We were also wrote below, please support IPv6 environment in Japan.
I am not even able to get for a hand to the user without this.

http://forum.mikrotik.com/viewtopic.php ... 88#p438726

We understand that it's a special situation, but please realize whether.

After that, I want you to also update the Kernel as SDN future measures.
And I want you to correspond to OpenvSwitch and OpenFlow1.3. OpenFlow is now very popular in Japan, to be able to use OpenFlow in CCR and cost-effective, because you can appeal strongly to the user.

Best regards.
Last edited by kometchtech on Fri Jul 25, 2014 10:18 pm, edited 1 time in total.
--
Routerboard Users Group JP
http://www.rb-ug.jp/
CCR1009-8G-1S-1S+, RB750Gr3, CRS226-24G-2S+, RB850Gx2, RB960PGS, CRS317-1G-16S+,
RB2011UAS, CRS125-24G-1S, RB962UiGS-5HacT2HnT, CRS212-1G-10S-1S+, RB3011UiAS
 
User avatar
kometchtech
Member Candidate
Member Candidate
Posts: 194
Joined: Sat Jun 15, 2013 4:25 am
Location: Japan
Contact:

Re: Feature request for v7.x

Fri Jul 25, 2014 10:15 pm

Please add ND Proxy support (RFC 4389) in v7.
It is the essential feature for ipv6 users.
+1

This function is mandatory in IPv6 environment in Japan.
--
Routerboard Users Group JP
http://www.rb-ug.jp/
CCR1009-8G-1S-1S+, RB750Gr3, CRS226-24G-2S+, RB850Gx2, RB960PGS, CRS317-1G-16S+,
RB2011UAS, CRS125-24G-1S, RB962UiGS-5HacT2HnT, CRS212-1G-10S-1S+, RB3011UiAS
 
cheeze
Member Candidate
Member Candidate
Posts: 146
Joined: Tue Jul 31, 2012 7:44 am

Re: Feature request for v7.x

Sat Jul 26, 2014 5:10 am

MPLS TE Fast Re-Route
MPLS TE Link Protection
MPLS TE Link-Node Protection
MPLS TE behavior similar to Cisco Class Based Tunnel Selection
MPLS TE Diffserv-Aware tunnels

MPLS Segment Routing extensions to OSPF/ISIS

ISIS

Multicast separation of RPF table calculation into individual routing table and all things involved with that
Multicast BSR fixes
Multicast Anycast-RP
Multicast MSDP

64-bit for x86

Fast-Path indicator on each interface. Which traffic handlers are enabled or not enabled.

Graceful Restart for OSPF/BGP/PIM/ISIS (if ever implemented)

BGP multicast address family

Cisco IP SLA/Juniper RPM functionality

LLDP and LLDP-MED with integration into SNMP
 
adrianlewis
just joined
Posts: 11
Joined: Tue Oct 14, 2014 6:09 pm

Re: Feature request for v7.x

Thu Oct 16, 2014 6:22 am

- Ability to create PPP interfaces in a specific VRF via RADIUS-Attribute
- full L2TP LAC functionality (for forwarding PPPoE sessions via L2TP)
BIG +1 from me on these two.

CCR Update presentation from MUM US '14 suggests improvements (complete rewrite?) to VRFs which sound like my other main request so hopefully with this effort we'll see VRFs given better support with regards to RADIUS VSAs.

Just need a bit more effort with L2TP to make it work better with Mikrotik customers that buy wholesale PPPoE/PPPoA DSL services from aggregators delivered as L2TP.
 
elgrandiegote
newbie
Posts: 38
Joined: Tue Feb 05, 2013 6:02 am
Location: Buenos Aires, Argentina

Re: Feature request for v7.x

Sun Nov 16, 2014 8:52 pm

I know what the answer for this is going to be, but it's just to show that the issue is not getting anywhere even if you pretend it does not exist and people still need it.

OpenVPN version update
OpenVPN support for UDP
OpenVPN support for LZO

In openWRT running in MetaRouter it's way too slow
+1000000
 
User avatar
nz_monkey
Forum Guru
Forum Guru
Posts: 1805
Joined: Mon Jan 14, 2008 1:53 pm
Location: Straya
Contact:

Re: Feature request for v7.x

Mon Nov 17, 2014 12:47 am

DHCP/RADIUS Improvements

- Use dhcp.dictionary for DHCP-Radius

- On DHCP renew check "running" settings against returned VSA's. If any VSA's have changed then update/add/remove relevant FIB/Queue/AddressList entries. On RouterOS 5/6 entries are added on a Request, then during renews only additional VSA's are actioned, any updated/removed ones are not reflected in the running configuration of the router.

- When running redundant DHCP servers/gateways (Authoritative Delay/Delay Threshold/VRRP), allow the option to have BOTH Authoritive and Non-Authoritive DHCP insert running settings from VSA's, this will allow the primary to fail and have the secondary take over with the same FIB/Queue/AddressList entries. Currently this does not work, if the primary DHCP Server/Gateway fails the Backup will become Master but none of the VSA settings will exist, and due to the above issue will never be created, causing a potential lack of service when running from the Backup router due to lack of FIB entries, or potential other issues due to lack of Queues or Address-List entries.

- Make default behavior of RADIUS VSA's on RouterOS compliant with RFC2865
http://thebrotherswisp.com/ | Mikrotik MTCNA, MTCRE, MTCINE | Fortinet FTCNA, FCNSP, FCT | Extreme Networks ENA
 
conecting
newbie
Posts: 26
Joined: Sat Jul 12, 2014 11:38 pm

Re: Feature request for v7.x

Tue Nov 18, 2014 3:17 pm

Zero handoff roaming between capsman units,
Also wolud love to see load balancing also between bands from 2,4ghz to 5ghz as on aruba networks becouse now I have to buy really expensive Aruba acess points to do this.
 
riaanmaree
Frequent Visitor
Frequent Visitor
Posts: 66
Joined: Thu Aug 31, 2006 10:42 pm
Location: Johannesburg, South Africa
Contact:

Re: Feature request for v7.x

Fri Nov 21, 2014 12:06 am

I also vote for more Radius-Attributes/Replies such as:
- local-address
- dns-server
- VRF/routing-table
 
Glaster
just joined
Posts: 1
Joined: Wed Nov 26, 2014 1:24 am

Re: Feature request for v7.x

Wed Nov 26, 2014 1:27 am

IKEv2 for IPSec

Who is online

Users browsing this forum: No registered users and 1 guest