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)
+1 for all of those and I may add: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)
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.- 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.
+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.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.
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.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 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.This would allow them to hire more developers, more support staff, and generally kick more ass.
Yes, yes
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
It would be good to upgrade linux kernel, to have betetter support on VMware ESXi, and to start work in HyperV.
I've sent an e-mail to support@mikrotik.com asking for more information.Hi,
It would be a must for mikrotik products ....
please could you add 6RD (ipv6 rapid deployment) available for many ISP
Thank you
maxspeed
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
I would genuinely consider this if it was affordable.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.
That's why you charge for it and hire more people.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.
Nobody expects that (well maybe a few people)Such thinks take time. You want us to grow from a 100 people company to Microsoft in a matter of weeks.
Normis, that last statement is fit for a corporate motto.It's only a question of "how" we will improve, not "if"
+1Normis, that last statement is fit for a corporate motto.It's only a question of "how" we will improve, not "if"
1. RouterOS 64Bit version for x86
2. Powerfull Web Proxy ( HTTPS and Video Caching)
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
+1Please add ND Proxy support (RFC 4389) in v7.
It is the essential feature for ipv6 users.
BIG +1 from me on these two.- Ability to create PPP interfaces in a specific VRF via RADIUS-Attribute
- full L2TP LAC functionality (for forwarding PPPoE sessions via L2TP)
+1000000I 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
I need this too for easy VPN from Windows Phone 8.1IKEv2 for IPSec
AKA IPSEC VTI (Virtual Tunnel Interface) support.2. Routed based vpn ipsec0 klips with libreswan. Better control over vpn traffic.
+1Just to name some missing "features" / bugs in IPv6.
- IPv6 bgp recursive next-hop. This is a must for any redundant IPv6 service provider backbone! static routes are no alternative!
- ipv6 blackholing - there must be a way to blackhole the prefix I announce to my upstreams. I simply don't want any TTL exceeded and routing loops! unreachable routes are no alternative!
- efficient ipv6 routing table lookups on cli (e.g. /ipv6 route print where dst-address=8.8.8.0/24)
- testing of ipv6 functions and protocols prior to release! basic stuff like VRRP working in one release and then totally unusable in the next release.... come on...
FYI this feature already exists.I would strongly suggest that you add a "Test config for x seconds" function that brings config back to where it was before applying it.
It's necessary for production equipment when (we all aggree on this) some times certain configs seem to work in test benches but out in the field they totally don't. So having something like:
Wireless station working at 20-40mhz width:
/interface wireless set wlan1 channel-width=20/40/80mhz-Ceee test-time=1m
Which would reset to previous config if something goes wrong. I mean.. this station could be 50 km away.
Virtual interfaces....
By this I mean the ability to have the following scenario:
ISP equipment --- rj45 ---> ether1 mikrotik
Now I would like to have several dhcp clients with different MAC addresses to be able to obtain more than one IP address
+1 for the apply changes for X seconds.I need Skins for Winbox, just like Webfig. And a Test Button, for apply changes during X seconds.
+1 for the apply changes for X seconds.I need Skins for Winbox, just like Webfig. And a Test Button, for apply changes during X seconds.
More precisely like a Safe mode but with a custom timeout.
Exactly+1 for the apply changes for X seconds.I need Skins for Winbox, just like Webfig. And a Test Button, for apply changes during X seconds.
More precisely like a Safe mode but with a custom timeout.
Sounds like "commit confirmed X" on JunOS. If you dont do another "commit" within "X" minutes it will automagically roll back the config changes.
Hi, I don't understand what you mean by "some kind of trend"Virtual interfaces....
By this I mean the ability to have the following scenario:
ISP equipment --- rj45 ---> ether1 mikrotik
Now I would like to have several dhcp clients with different MAC addresses to be able to obtain more than one IP address
will be great but, mikrotik its not the only brand who has that limitation because dhcp is mostly used to give access to clients its some kind of trend and too specific scenario to address
+1 for 6rd support .
My isp only supports that at this point and I don't want a tunnel service like HE.
Regards
I would like this expanded for both IPv4 and IPv6, lookups on my BGP routers take minutes to complete.efficient ipv6 routing table lookups on cli (e.g. /ipv6 route print where dst-address=8.8.8.0/24)
It is like you read my mind!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
Mikrotik-ipv6-address-list radius attributes please. This is the only thing blocking us from ipv6 deployment to user, as we used it to separate QoS between users.
+1yes yes!
Mikrotik-IPv6-Address-List
IPv6-Framed-Route - RFC6911
IPv6-Delegated-Prefix - RFC4818
+1 for us too!yes yes!
Mikrotik-IPv6-Address-List
IPv6-Framed-Route - RFC6911
IPv6-Delegated-Prefix - RFC4818
Mikrotik-ipv6-address-list radius attributes please. This is the only thing blocking us from ipv6 deployment to user, as we used it to separate QoS between users.
It is like you read my mind!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
Also add MPLS TE Auto-Tunnel
I also requested to Mikrotik support that they implement RFC7130 https://tools.ietf.org/html/rfc7130 for BFD + Bonding(LAG), this runs a BFD session per bond member, and can detect problems with packet flow via an individual link in a bond. This is very useful when you are running a Leaf/Spine switch architecture between routers and there is a problem with packet flow via one path, the bond + LACP to the Mikrotik will stay up, yet a path beyond the direct LACP link may have a problem and currently this would go unnoticed and cause issues.
RFC7130 aims to prevent such situations.
While you can achieve this withI 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'
/log print follow where message~"^prefix1|^prefix2"
+1 for me too+1 for us too!yes yes!
Mikrotik-IPv6-Address-List
IPv6-Framed-Route - RFC6911
IPv6-Delegated-Prefix - RFC4818
Mikrotik-ipv6-address-list radius attributes please. This is the only thing blocking us from ipv6 deployment to user, as we used it to separate QoS between users.
Make it 5 Gbps.Single connection routing @ 2 Gbps on 1036 and up.
I second this requestNEED HTTPS WITH PROXY
I agree. Please finish existing feature before adding new ones.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
all of those can be put in place using scripting and ros api right nowTR-069
For auto provision , remote real time diagnostics, quick fast mass upgrades, quick fix roll outs and general monitoring .
all of those can be put in place using scripting and ros api right nowTR-069
For auto provision , remote real time diagnostics, quick fast mass upgrades, quick fix roll outs and general monitoring .
you're right, it's not TR-069. scripting is a lot more powerful stuff.all of those can be put in place using scripting and ros api right nowTR-069
For auto provision , remote real time diagnostics, quick fast mass upgrades, quick fix roll outs and general monitoring .
But it's still not TR-069 isn't it . Scripting is per device , and time consuming . Consider managing thousands of RouterBoard , Scripting is good if you have a few CPE , but when your talking about mass deployment you need TR-069, no help desk is going to take a support call and put a customer on hold while you script something up .
That is just re-inventing the wheel. Why develop new ecosystem when one already exists . ISP already have TR-069 asset in the business and interfaced with OSS/BSS systems, re-inventing (home-brew) is not feasible.TR-069
you're right, it's not TR-069. scripting is a lot more powerful stuff.
of course it needs a head start of coding, it's not something out of the box. but auto-provisioning can be
done using different approaches.
no one stops us to actually create a similar environment/ecosystem with ROS scripting, to provide the same
look & feel as TR-069. if you need it right now, let's make one. when you have to deal with 1000s of devices
it (the home-brew approach) will be a lot more efficient than doing everything manually while waiting for MTIK to implement TR-069
BTW, i would not compare the average TR-069 governed CPE feature set to something that ROS offers right now.
fair enoughAt the end of the day , this is a feature request , end user should have the option to choose what best fits the network and business. TR-069 is my feature request for V7.
/ip firewall mangle
add action=mark-connection chain=prerouting comment="WAN1 FWD" in-interface=ppp-WAN1 new-connection-mark=wan1_conn passthrough=no
add action=mark-routing chain=prerouting comment="WAN1 FWD" connection-mark=wan1_conn new-routing-mark=to_wan1 passthrough=no
add action=mark-connection chain=prerouting comment="WAN2 FWD" in-interface=ppp-WAN2 new-connection-mark=wan2_conn
add action=mark-routing chain=prerouting comment="WAN2 FWD" connection-mark=wan2_conn new-routing-mark=to_wan2 passthrough=no
add action=mark-connection chain=input comment="WAN1 IN OUT" in-interface=ppp-WAN1 new-connection-mark=wan1_conn
add action=mark-routing chain=output comment="WAN1 IN OUT" connection-mark=wan1_conn new-routing-mark=to_wan1 passthrough=no
add action=mark-connection chain=input comment="WAN2 IN OUT" in-interface=ppp-WAN2 new-connection-mark=wan2_conn
add action=mark-routing chain=output comment="WAN2 IN OUT" connection-mark=wan2_conn new-routing-mark=to_wan2 passthrough=no
/ip route
add check-gateway=ping distance=2 gateway=ppp-WAN1 routing-mark=to_wan1
add check-gateway=ping distance=3 gateway=ppp-WAN2 routing-mark=to_wan2
add check-gateway=ping comment=MAIN distance=1 gateway=10.1.0.1
add distance=1 dst-address=10.0.0.11/32 gateway=eth6_WAN1
add distance=1 dst-address=10.0.0.12/32 gateway=eth7_WAN2
Your problem is that the connection-marking rules need to also have the criteria: connection-mark=no-mark... and when I tried to set up routing mark for address 10.1.0.1, the route fails.
Could you help me please?
These functions need definitely. And they need not only to us but also to you - mikrotik team, for that would have a more competitive product and a more extensive sales geography. I think when you had MUM tour in Asia have often been asked about the ISIS protocol. Oh Asians very love itMPLS 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
ISIS is very common in large provider networks the world over. It will be great to see ISIS support in RouterOS.I think when you had MUM tour in Asia have often been asked about the ISIS protocol. Oh Asians very love it
+1The very simple feature we need right now is: ability to delete bgp communitied from prefix by rege. Cisco like:
route-map xxx permit 10
match ....
set comm-list XXXX delete
Don't we already have IGMP support?+1 for IGMP snooping support.
Much needed for IPTV in Russia!
Can you post the exact rules? Yes, we do have IGMP proxy and it should be enough in most cases. Some people refuse to try it, so a complete example would be nice, to make it easier.Don't we already have IGMP support?+1 for IGMP snooping support.
Much needed for IPTV in Russia!
Just over the weekend I managed to configure IPTV box with IGMP proxy, and 2 firewall rules (one to allow IGMP, another to allow UDP to specific subnets used by my provider)
I fail to see why.There is this small, not-well-known but very useful tool called "etckeeper" for Linux, which automatically commits all changes you do on your configuration to the version-control-system of your choice (git, svn...). An implementation of that for MikroTik would be interesting because it will save time required for setting up other ways of automated backups.
Can you post the exact rules? Yes, we do have IGMP proxy and it should be enough in most cases. Some people refuse to try it, so a complete example would be nice, to make it easier.Don't we already have IGMP support?+1 for IGMP snooping support.
Much needed for IPTV in Russia!
Just over the weekend I managed to configure IPTV box with IGMP proxy, and 2 firewall rules (one to allow IGMP, another to allow UDP to specific subnets used by my provider)
> /routing igmp-proxy export compact
# aug/02/2016 17:58:59 by RouterOS 6.35.4
# software id = ADSD-BZLV
#
/routing igmp-proxy
set quick-leave=yes
/routing igmp-proxy interface
add alternative-subnets=0.0.0.0/0 interface=vlan12 upstream=yes
add interface=bridge-lan
> /ip firewall filter export compact
# aug/02/2016 17:59:54 by RouterOS 6.35.4
# software id = ADSD-BZLV
#
/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=established,related
add action=drop chain=Attacks comment="Drop connections FROM blacklisted hosts" src-address-list=blacklist
add action=drop chain=Attacks comment="Drop connections TO blacklisted hosts" dst-address-list=blacklist
add chain=input comment="Allow Established and Related" connection-state=established
add chain=forward connection-state=established,related disabled=yes
add action=drop chain=input comment="Drop INVALID" connection-state=invalid
add action=drop chain=forward connection-state=invalid
add chain=output comment="Allow LAN" src-address-list=INTERNAL
add chain=input comment=SUPPORT src-address-list=support
add chain=input comment="Allow VPN's" protocol=gre
add chain=input comment=PPTP dst-port=1723 protocol=tcp
add chain=input comment=L2TP dst-port=1701 protocol=udp
add action=reject chain=input comment="prevent ping" disabled=yes in-interface=vlan12 protocol=icmp reject-with=icmp-admin-prohibited
add chain=input comment="Allow Ping" log=yes log-prefix="PING_ " protocol=icmp
#add action=add-dst-to-address-list address-list=MEO-IGMP address-list-timeout=1w3d chain=input comment="IGMP (iptv)" protocol=igmp
add chain=input comment="IGMP (iptv)" protocol=igmp
add chain=input comment="UDP (iptv)" protocol=udp src-address-list=MEO-IPTV
add chain=forward protocol=udp src-address-list=MEO-IPTV
add action=drop chain=input comment="Drop Everything else" log-prefix=DROP_
> /ip firewall address-list export
# aug/02/2016 18:04:28 by RouterOS 6.35.4
# software id = ADSD-BZLV
#
/ip firewall address-list
# ... other stuff ...
add address=194.65.46.0/23 list=MEO-IPTV
add address=10.173.0.0/16 list=MEO-IPTV
add address=213.13.16.0/21 list=MEO-IPTV
But for first v7 need any Ether RING protocol : ITU-T G.8032 Ethernet Ring Protection Switching (ERPS) there is also EAPS(like extreme networks), EPSR(allied telesis)Multi Core BGP to speed up receiving a full BGP routing table
A very important feature.Multi Core BGP to speed up receiving a full BGP routing table
I'm sure that will never happen, as it would open the door to breaking into RouterOS...Hello! I would really like to see in a future version of the RouterOS possible to install Metarouter to external storage such as a USB-flash. It is very important for hAP AC owners, where the free HDD space is very small.
Secure Routerboot is already available - maybe that is what you wanted?Please add some type of device / tracking protection.
That when thief will steal it, it will have some code with ability to track, even after hard reset or with remote code activation,
to work in the way as apple icloud lock - unusable without code.
No, Secure Routerboot does not protect the hardware at all. It only protects the configuration. You can easily reset the router if it has Secure Routerboot and it erases the configuration and then you can use it like it is brand new.Secure Routerboot is already available - maybe that is what you wanted?Please add some type of device / tracking protection.
That when thief will steal it, it will have some code with ability to track, even after hard reset or with remote code activation,
to work in the way as apple icloud lock - unusable without code.
UDP was already confirmed for RouterOS v7, no need to keep requesting it. Buy a nice bottle of champagne with long expiration date and be ready!UDP support
Hopefully the change will just be "update the OpenVPN binary to the most recent release".it would be real shame to end up with "please add <some still missing OpenVPN feature>" thread(s) after RouterOS v7 gets out.
Currently true, but we will implement a specific second interval for the reset, so that it will be impossible to reset, unless you know that it is triggered between the 85th and 90th secondNo, Secure Routerboot does not protect the hardware at all. It only protects the configuration.
So, you have to know the number within a 5 second range? Up to 300 seconds, divided by 5 = 60. So, worst case scenario is that someone could reset it with 60 tries, and most likely within 30 tries.Currently true, but we will implement a specific second interval for the reset, so that it will be impossible to reset, unless you know that it is triggered between the 85th and 90th secondNo, Secure Routerboot does not protect the hardware at all. It only protects the configuration.
Maybe not stolen, but reused by a competitor... giving the competitor an advantage because they don't have to provide one.Who really suffers by devices being regularly stolen? I have not ever heard of it.
That will probably be not a professional competitor, but merely a bunch of hobbyists.Maybe not stolen, but reused by a competitor... giving the competitor an advantage because they don't have to provide one.
I suggest you look at RANCID, it does what you've described. Works for me, as well as with much other network equipment.There is this small, not-well-known but very useful tool called "etckeeper" for Linux, which automatically commits all changes you do on your configuration to the version-control-system of your choice (git, svn...). An implementation of that for MikroTik would be interesting
I have IGMP proxy and still feel the need of IGMP snooping to reduce network bandwidth efficiently and simplify configuration.Can you post the exact rules? Yes, we do have IGMP proxy and it should be enough in most cases. Some people refuse to try it, so a complete example would be nice, to make it easier.Don't we already have IGMP support?+1 for IGMP snooping support.
Much needed for IPTV in Russia!
Just over the weekend I managed to configure IPTV box with IGMP proxy, and 2 firewall rules (one to allow IGMP, another to allow UDP to specific subnets used by my provider)
I think what is meant is the "trick" to have a much much longer beacon interval on 2.4 than on 5 GHzIt was always possible to use the same ssid for different wlans.
I think you have chosen the wrong OS. When you want bash scripting and other open access to the Linux system, you should install OpenWRT or another compact Linux system.I wish standard bash ( or another command processor ) scripting interface.
Scripting in mikrotik and debugging scripts for mikrotik is horrible.
Sorry but it is just true. I spoken about that with many many colleagues and every single man have this wish for new mikrotik. Please, please consider this. Please.
+1 This is so needed in the industry. Mikrotik would dominate the always on VPN for mobile devices if they had a VPN that fully supported IKEv2.IKEv2 for IPSec
FYI IKEv2 was just added to 6.38 Release Candidates. See http://wiki.mikrotik.com/wiki/Manual:IP ... 2_RSA_auth for config info.+1 This is so needed in the industry. Mikrotik would dominate the always on VPN for mobile devices if they had a VPN that fully supported IKEv2.IKEv2 for IPSec
Check the changelo of latest rc.+1 This is so needed in the industry. Mikrotik would dominate the always on VPN for mobile devices if they had a VPN that fully supported IKEv2.IKEv2 for IPSec
Great news! I look forward to a stable version that we can offer to customers.Check the changelo of latest rc.+1 This is so needed in the industry. Mikrotik would dominate the always on VPN for mobile devices if they had a VPN that fully supported IKEv2.IKEv2 for IPSec
http://forum.mikrotik.com/viewtopic.php ... 00#p566926
+1 on both of these, I was toying with the idea of switching my wireless infrastructure over to MikroTik, but until there's a DHCPv6 server which does host addressing I'll be putting that on the back-burner.- Working DHCPv6 server for single adresses,
...
- DHCPv6 DNS advertiesment support
when this option will be implemented?Currently true, but we will implement a specific second interval for the reset, so that it will be impossible to reset, unless you know that it is triggered between the 85th and 90th secondNo, Secure Routerboot does not protect the hardware at all. It only protects the configuration.
+1DHCP Lease assignment based on received DHCP Option 82 Info (this one is the most important)
I am in desperate need of ISIS... specifically Shortest Path Bridging (SPB)
Or some way to Dynamically route Large TE tunnels down multiple smaller ones.
Here is our problem. We are a WISP and we run MPLS and TE tunnels between sites. We use multiple connections between sites and utilize them with TE tunnels. The problem is that it does not balance well when the sites are needing lots of bandwidth and have many smaller connections. Here is an example.
Lets say site A has 4 connections to it:
1gb path 2 hops
100mb path 2 hops
100mb path 3 hops
200mb path 4 hops
Site A uses 350mbps and it is reserved in the TE tunnel. Great all is working well... until something happens to the 1gb link and it goes down.
When the 1 gb connection goes down the TE tunnel will fail and all of the traffic will then go down the 100mb 2 hops path. the other 2 links will not be used at all and the site will be crippled by lack of bandwidth. It has the bandwidth available but no way to use it.
Option 1: have some way to dynamically route Large TE tunnels down multiple smaller ones.
Option 2: Use multiple TE tunnels using BGP signaled VPLS and throw them all into a bridge that has ISIS and Shortest Path Bridging (SPB) breaks traffic up to allow multiple paths to the same site.
Option 3 (current option) Use multiple TE tunnels using BGP signaled VPLS and throw them all into a bonded interface. write a script that monitors the interface and add back changed VPLS interfaces. They are all dynamically made so when something changes they break out of the bonded interface. Then add the bonded interface into a bridge. You may need to add Nx addresses on both sides to use the fail detection on the interfaces in the bonding to make sure traffic doesn't go down a dead interface. then add another custom script to move the IP addresses to follow the dynamically created interfaces to ensure correct fail over....
Option 3 is not cool.
We really need option 1 or 2
/interface ethernet switch vlan set [find vlan-id=10] ports+=ether1
/interface ethernet switch vlan set [find vlan-id=11] ports-=ether3,ether4
+1Force sending of DHCP options to clients
+1+1DHCP Lease assignment based on received DHCP Option 82 Info (this one is the most important)
must have!
I believe in Mikrotik)
IS-IS would be amazing. The ability to manage more than one routed protocol inside a single routing protocol that does not rely on the protocol it is routing for communication seems like a self evident great idea to me - but i don't have to code it and I get that building ISO/CLNS likely isn't straightforward. Nevertheless, it would significantly change the simplicity of any medium to large sized routed network. Managing OSPF2/3 pretty much stinks as a general rule and does not scale to large sizes like IS-IS does.
Segment routing via IS-IS TLV would be even more amazing. SR is a game changer - but it's dependent on the TLV or IPv6 implementation to function.
nb
I am in desperate need of ISIS... specifically Shortest Path Bridging (SPB)
Or some way to Dynamically route Large TE tunnels down multiple smaller ones.
Here is our problem. We are a WISP and we run MPLS and TE tunnels between sites. We use multiple connections between sites and utilize them with TE tunnels. The problem is that it does not balance well when the sites are needing lots of bandwidth and have many smaller connections. Here is an example.
Lets say site A has 4 connections to it:
1gb path 2 hops
100mb path 2 hops
100mb path 3 hops
200mb path 4 hops
Site A uses 350mbps and it is reserved in the TE tunnel. Great all is working well... until something happens to the 1gb link and it goes down.
When the 1 gb connection goes down the TE tunnel will fail and all of the traffic will then go down the 100mb 2 hops path. the other 2 links will not be used at all and the site will be crippled by lack of bandwidth. It has the bandwidth available but no way to use it.
Option 1: have some way to dynamically route Large TE tunnels down multiple smaller ones.
Option 2: Use multiple TE tunnels using BGP signaled VPLS and throw them all into a bridge that has ISIS and Shortest Path Bridging (SPB) breaks traffic up to allow multiple paths to the same site.
Option 3 (current option) Use multiple TE tunnels using BGP signaled VPLS and throw them all into a bonded interface. write a script that monitors the interface and add back changed VPLS interfaces. They are all dynamically made so when something changes they break out of the bonded interface. Then add the bonded interface into a bridge. You may need to add Nx addresses on both sides to use the fail detection on the interfaces in the bonding to make sure traffic doesn't go down a dead interface. then add another custom script to move the IP addresses to follow the dynamically created interfaces to ensure correct fail over....
Option 3 is not cool.
We really need option 1 or 2
Already possible
- Telnet to other port than 23 (testing if a port is alive)
The file for that is rather large, 600K for the file used by nmap, 1300K for the file used by wireshark.[*]MAC address vendor in IP scan results, like https://macvendors.com/
Already possible:[*]Telnet to other port than 23 (testing if a port is alive)
The file for that is rather large, 600K for the file used by nmap, 1300K for the file used by wireshark.[*]MAC address vendor in IP scan results, like https://macvendors.com/
Maybe it could be done in an optional package.Already possible:[*]Telnet to other port than 23 (testing if a port is alive)
/system telnet 1.2.3.4 port=80
In general the MikroTik solution is not for those that want "one click solutions". The advantage is that with MikroTik you have a lot more flexibility, the disadvantage is that it requires some insight and experience from you (although in the case of PCC there are ready-to-use examples for the simple case of two equal internet connections).I have seen lots of post and hell lot of documents available on web for PCC load balancing. But all these documents dont have the one click deployment solution. I mean its great to learn something new but sometimes GUI with one click solution is better for a production environment.
I have seen Mikrotik team has done a tremendous job in developing the ROS. But still, as I believe and I am sure there are lots like me believes that this WAN load balancing is still missing from ROS.
RFC6830-6836, please!Locator Id Separation (LISP) support
m2mDNS server for Chromecast/Bonjour/ZeroConfig across VLANs.
WiFi networks are too big to have all the available devices all bridged to the LAN.
Would be nice to then firewall what devices are discoverable.
Which functionality can you enable/configure in SwOS that can not be done in ROS?I hope full SwOS function are merged into RouterOS
The only sensible part of this wish is "letsencrypt support for SSL certificates" ...A solution like ha proxy in router os v7 would be usefull I like to run multiple ssl sites behind my mikrotik router on 1 public ip and lets encrypt support to automaticly secure them with ssl
While I did not make this request and do not need such functions, I would say that my CCR routers have so much CPU, crypto accel and RAM capacity that is sitting unused that it would certainly be worth it to load them with something like this, e.g. when the webserver itself gets a little overloaded by the crypto.PC hardware is much better suited to run such service than average xMIPS/ARM deployed in RBs. Not to mention additional RAM needed by this functionality (it needs to keep list of active connections if load-ballancing functionality of haproxy is used). Plus all encryption/decryption (not sure if that can/will be offloaded to HW on units that have such hardware).
Apparently we have different definition of expensive... I think our CCR1009's are quite cheap.I'd say that such an expensive hardware (as CCRs are)
I agree with that! But talking to MikroTIk staff it became clear to me that nothing is to be expected in that department.I think devs' time would be better used when implementing full feature set for IPv6 ... for example.
Perhaps not ... but we might have different perspectives. Me, for example, I associate CCRs with decent LAN size which deserves some dedicated boxes to do some things ... such as dedicated server for http/https and in this case CCR should do routing and firewalling. On the other hand I expect to see budget hardware (hEX/hAP) to do stuff where it is sensible to join different tasks on small number of devices.Apparently we have different definition of expensive... I think our CCR1009's are quite cheap.I'd say that such an expensive hardware (as CCRs are)
also here ... for securing IoT over VLANs, etc.m2mDNS server for Chromecast/Bonjour/ZeroConfig across VLANs.
WiFi networks are too big to have all the available devices all bridged to the LAN.
Would be nice to then firewall what devices are discoverable.
Log interface traffic counter to a syslog server. There you can see it number or you can graph it if you like.Monthly traffic per interface. Dont tell me about graphing. Its not fine for me.
It may be that he has one of those ISPs that have "limited bundle of traffic". Some other routers offer an optionLog interface traffic counter to a syslog server. There you can see it number or you can graph it if you like.Monthly traffic per interface. Dont tell me about graphing. Its not fine for me.
See link in my signature on how to set up Splunk (syslog server) to log MikroTik Routers.
This is the conundrum of IPv6 - the "no one is asking for it" line is the weakest excuse for not deploying IPv6. 99.999% of customers won't ask for it, nor should they. If it is done correctly they'll never even notice they are using it. Operators don't deploy it because vendor implementations are incomplete. IPv6 deployment is quite profound in mobile and smartgrid networks, and (at least in the US), nearly all major providers offer it (Comcast, ATT, Spectrum, etc.) and the content has been there for years. If Mikrotik would implement feature parity with IPv4 then the bar is further lowered.Apparently we have different definition of expensive... I think our CCR1009's are quite cheap.I'd say that such an expensive hardware (as CCRs are)
I agree with that! But talking to MikroTIk staff it became clear to me that nothing is to be expected in that department.I think devs' time would be better used when implementing full feature set for IPv6 ... for example.
Apparently most of their customers are not interested in IPv6.
Yes i agree with you. There is no major concentration to IPv6 Modules from Mikrotik Team.This is the conundrum of IPv6 - the "no one is asking for it" line is the weakest excuse for not deploying IPv6. 99.999% of customers won't ask for it, nor should they. If it is done correctly they'll never even notice they are using it. Operators don't deploy it because vendor implementations are incomplete. IPv6 deployment is quite profound in mobile and smartgrid networks, and (at least in the US), nearly all major providers offer it (Comcast, ATT, Spectrum, etc.) and the content has been there for years. If Mikrotik would implement feature parity with IPv4 then the bar is further lowered.Apparently we have different definition of expensive... I think our CCR1009's are quite cheap.I'd say that such an expensive hardware (as CCRs are)
I agree with that! But talking to MikroTIk staff it became clear to me that nothing is to be expected in that department.I think devs' time would be better used when implementing full feature set for IPv6 ... for example.
Apparently most of their customers are not interested in IPv6.
If we put even 1/8 of the effort into doing v6 as we did painting over the rusty carcas of ipv4 we would have been done a decade ago. Come on, Mikrotik, this is fundamental stuff.
nb
That is probably the biggest problem in IPv6 adaptation! When you do it correctly, nobody notices it. When you make a mistake, people complain that things thatThis is the conundrum of IPv6 - the "no one is asking for it" line is the weakest excuse for not deploying IPv6. 99.999% of customers won't ask for it, nor should they. If it is done correctly they'll never even notice they are using it.
Do you have any experience with that in practice, or is it only a proposal?But if you have a network so important it need 2x isp's, you could probably send that email and ask one of the isp's for a PI space as well. with ipv6 PI space, announced by the isp's or announced via a privateAS bgp should be the default solution for a small multihomed network, since the address space is so abundant, getting PI space is an email or 2 away. and not the problem it was on ipv4.
Very interesting, can you share some details about Rancid and Mikrotik backup?I suggest you look at RANCID, it does what you've described. Works for me, as well as with much other network equipment.There is this small, not-well-known but very useful tool called "etckeeper" for Linux, which automatically commits all changes you do on your configuration to the version-control-system of your choice (git, svn...). An implementation of that for MikroTik would be interesting
+1BGP option like Juniper "advertise-inactive".
+1A solution like ha proxy in router os v7 would be usefull I like to run multiple ssl sites behind my mikrotik router on 1 public ip and lets encrypt support to automaticly secure them with ssl
/interface wireless access-list
add mac-address=01:01:01:01:01:01 private-pre-shared-key=testvlan1
add mac-address=02:02:02:02:02:02 private-pre-shared-key=testvlan105 vlan-id=105 vlan-mode=use-tag
/interface wireless access-list
add mac-address=00:00:00:00:00:00 private-pre-shared-key=testvlan1
add mac-address=02:02:02:02:02:02 private-pre-shared-key=testvlan105 vlan-id=105 vlan-mode=use-tag
/interface wireless access-list
add mac-address=00:00:00:00:00:00 private-pre-shared-key=testvlan1
add mac-address=00:00:00:00:00:00 private-pre-shared-key=testvlan105 vlan-id=105 vlan-mode=use-tag
/code]
Damn... patent... that's why you can't have a toilet that flush properly or a saw that can saw without being over complicated these days...You are aware that this feature is patented by Ruckus?
WIFI multiple PSK ACL with wildcard MAC.
Here Engenius description on that. Ruckus also have something similar and I think Meraki also do so...
https://www.engeniustech.com/mypsk-a-ne ... porations/
Here discussion about the issue on the forum
viewtopic.php?p=913911&hilit=dpsk#p913911
Basic idea is to have a single SSID and allow multiple PSK and assigned VLAN based on PSK used. That is use in hotel or nursing home application where device does not always play well with WPA2-Enterprise (RADIUS). Basic idea, each room have it's own PSK on a single SSID and VLAN are assign based on PSK used, so device on same "room" can communicate with each other. Alexa, ChromeCast, Tablet...
Right now wifi ACL allow for (almost) that, but MAC need to be know. Also a "wildcard" MAC is allowed, but only the first one is evaluated. Need to have multiple wildcard, if first failed, check the next...
This is working
This is also workingCode: Select all/interface wireless access-list add mac-address=01:01:01:01:01:01 private-pre-shared-key=testvlan1 add mac-address=02:02:02:02:02:02 private-pre-shared-key=testvlan105 vlan-id=105 vlan-mode=use-tag
But this is not, and that is requieredCode: Select all/interface wireless access-list add mac-address=00:00:00:00:00:00 private-pre-shared-key=testvlan1 add mac-address=02:02:02:02:02:02 private-pre-shared-key=testvlan105 vlan-id=105 vlan-mode=use-tag
Code: Select all/interface wireless access-list add mac-address=00:00:00:00:00:00 private-pre-shared-key=testvlan1 add mac-address=00:00:00:00:00:00 private-pre-shared-key=testvlan105 vlan-id=105 vlan-mode=use-tag /code] [/quote]