Community discussions

 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 1239
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

Re: Feature requests

Fri Jul 26, 2019 11:35 am

any poe-command (even print command) causes error in script if HW doesn't have poe-out interfaces...

Can you post the command that fails? There may be a solution to test for poe interface before command is run.
 
How to use Splunk to monitor your MikroTik Router

MikroTik->Splunk
 
 
pe1chl
Forum Guru
Forum Guru
Posts: 5564
Joined: Mon Jun 08, 2015 12:09 pm

Re: Feature requests

Fri Jul 26, 2019 12:12 pm

any poe-command (even print command) causes error in script if HW doesn't have poe-out interfaces...
Can you post the command that fails? There may be a solution to test for poe interface before command is run.
A workaround for this was already found in another topic.
 
mkx
Forum Guru
Forum Guru
Posts: 2605
Joined: Thu Mar 03, 2016 10:23 pm

Re: Feature requests

Fri Jul 26, 2019 1:24 pm

Need feature to detect if device have poe-out interfaces - now any poe-command (even print command) causes error in script if HW doesn't have poe-out interfaces...

I don't know how to script it, but possibility is available already: /interface print where type=pppoe-out
BR,
Metod
 
pe1chl
Forum Guru
Forum Guru
Posts: 5564
Joined: Mon Jun 08, 2015 12:09 pm

Re: Feature requests

Fri Jul 26, 2019 1:47 pm

Need feature to detect if device have poe-out interfaces - now any poe-command (even print command) causes error in script if HW doesn't have poe-out interfaces...
I don't know how to script it, but possibility is available already: /interface print where type=pppoe-out
pppoe has no relation to poe!
 
mkx
Forum Guru
Forum Guru
Posts: 2605
Joined: Thu Mar 03, 2016 10:23 pm

Re: Feature requests

Fri Jul 26, 2019 1:51 pm

Need feature to detect if device have poe-out interfaces - now any poe-command (even print command) causes error in script if HW doesn't have poe-out interfaces...
I don't know how to script it, but possibility is available already: /interface print where type=pppoe-out
pppoe has no relation to poe!
Aargh ... suits me for not being careful enough when reading :-(
BR,
Metod
 
pe1chl
Forum Guru
Forum Guru
Posts: 5564
Joined: Mon Jun 08, 2015 12:09 pm

Re: Feature requests

Sat Jul 27, 2019 11:04 am

Please allow for multiple DNS resolver instances (with independently configured external servers, static entries, and cache).
The current single DNS resolver could just be 1 item in a list, to which others can be added.
These resolvers could be tied to internal interfaces using an interface list or they could listen on one or more addresses specified in their entry, whatever is more convenient.

Reason: you may want to use a different DNS service, like OpenDNS or another DNS with filtering capabilities, for your guest network.
Or you may want to have LAN systems resolve via a local DNS resolver like Windows Server and have the guest network only use internet DNS.
 
msatter
Forum Guru
Forum Guru
Posts: 1176
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: Feature requests

Sat Jul 27, 2019 12:31 pm

Able to disable dynamic DNS servers when using an IKEv2 connection to a VPN provider as NordVPN. This to have only the manual entered DNS server receiving requests and no fallback to the dynamic provided DNS servers of the VPN provider.
Two RB760iGS (hEX S) in series. One does PPPoE and both do IKEv2.
Running:
RouterOS 6.46Beta / Winbox 3.19 / MikroTik APP 1.3.1
Having an Android device, use https://github.com/M66B/NetGuard/releases (no root required)
 
msatter
Forum Guru
Forum Guru
Posts: 1176
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: Feature requests

Tue Aug 13, 2019 11:04 am

Using Address Lists not only with IP address and Domain Name but also with the ASN number.

Never found a way to block in routing incoming traffic using ASN and I had to fallback on generating my own Address List to filter those IP ranges out.
Two RB760iGS (hEX S) in series. One does PPPoE and both do IKEv2.
Running:
RouterOS 6.46Beta / Winbox 3.19 / MikroTik APP 1.3.1
Having an Android device, use https://github.com/M66B/NetGuard/releases (no root required)
 
pe1chl
Forum Guru
Forum Guru
Posts: 5564
Joined: Mon Jun 08, 2015 12:09 pm

Re: Feature requests

Tue Aug 13, 2019 11:14 am

The AS number is only directly available when the router has a full BGP routing table from internet.
When you are just connected using a static default route to internet (i.e. typical endpoint on a single ISP) the AS number is not available.
The cost to lookup the AS number is high to very high (depending if you use some special DNS service or the basic WHOIS method) so it cannot be done on every packet.
There would have to be a very clever cache of AS numbers corresponding to recent traffic, and it probably would work only when a dedicated service was set up for this purpose.
I know that a DNS service that can do this does exist, but I don't think they will be very happy when many MikroTik routers start using this for one out of 100 packets they receive.

Maybe for this special case where you want to block a certain AS number a special service could be setup that returns the subnets advertised by that AS number in the format required to load them into an address list. One of those people that sell blocklists here on the forum could do that, if they had BGP routing to internet (which I don't think they do right now).
 
msatter
Forum Guru
Forum Guru
Posts: 1176
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: Feature requests

Tue Aug 13, 2019 1:28 pm

Thanks pe1chl. I had yesterday some kind of only sync requests on ports 80 and 443 from serveral different AS numbers fom Dutch, Lituania, Ukrain and China sourced server/service providers.

I blocked in 12 hours almost 50 000 connections in RAW, now it is quiet again.
Two RB760iGS (hEX S) in series. One does PPPoE and both do IKEv2.
Running:
RouterOS 6.46Beta / Winbox 3.19 / MikroTik APP 1.3.1
Having an Android device, use https://github.com/M66B/NetGuard/releases (no root required)
 
pe1chl
Forum Guru
Forum Guru
Posts: 5564
Joined: Mon Jun 08, 2015 12:09 pm

Re: Feature requests

Tue Aug 13, 2019 7:34 pm

I have seen that as well. This is a DDoS amplification: those SYN packets are not really coming from the servers or even AS that you think, but they are spoofed by the DDoS operator.
The idea is that for every SYN they send to you, you will send a number of SYN ACK packets to the address that they spoofed, and thus to the addresses of that service provider.
As they do this for many websites the "return traffic" of unidentified SYN ACK packets to that provider can be large and be used as an attack, while the websites used in the amplification note little.
So the addresses you are trying to block are not the abusers but the victims. You might block legitimate visitors doing this, although it is unlikely.

It is not really necessary do do anything about this, it is not an attack on your system and as long as you don't send an unreasonable number of SYN ACK to an incoming SYN, your system should not be overwhelmed with traffic or lingering connections. If necessary you can reduce the number of retries, e.g. like this:

echo 2 > /proc/sys/net/ipv4/tcp_synack_retries

(to change the default from 5 to 2 in Linux)

Of course the REAL problem is that ISP's are not doing source address filtering. When everyone applied source address filters to the networks they host or serve to endusers, this attack would not be possible.
 
Fesiitis
just joined
Posts: 8
Joined: Tue Sep 13, 2016 10:24 am
Location: Latvia, Riga

Re: Feature requests

Thu Aug 15, 2019 7:24 pm

I'm waiting for ike2 support for eap as responder. Hope this feature will be added soon, since support for this as initiator was added in v6.45.1 update.
 
ursy
just joined
Posts: 10
Joined: Thu Apr 04, 2019 1:46 pm

Re: Feature request: IEEE 1588 support

Mon Aug 19, 2019 4:54 pm

RouterOS includes limited (S)NTP support for syncing clocks. For many applications (e.g. in telecoms and industry) more time precision is required. Protocol IEEE 1588-2008 (aka PTP, IEEE1588v2) is used for this. It would be a great benefit if Mikrotik devices would support IEEE 1588 and function as transparent clock, better yet boundary clock. Maybe some of the built-in switch chips already support for IEEE1588 timestamping in hardware.

You find some information about IEEE 1588 here:
https://www.endruntechnologies.com/pdf/PTP-1588.pdf
https://www.endace.com/ptp-timing-whitepaper

This forum already had some discussion about IEEE 1588:
viewtopic.php?f=1&t=70793&p=534801&hili ... 88#p534801
viewtopic.php?f=1&t=87471&p=465496&hili ... 88#p465496
viewtopic.php?f=1&t=79304&p=421858&hili ... 88#p421858
viewtopic.php?f=21&t=121198&p=605388&hilit=1588#p605388

Of course one has to have a grandmaster clock accessible to make use of IEEE 1588. Mikrotik devices only could transport PTP packets better, if supported.
Hello Muetzekoeln,

The topic is very interesting for me and I would need some clarifications from your topic:

1. Is any Mikrotik device supporting IEEE1588?
2. Is there any Mikrotik equipment which can be considered "transparent switch"? Im interested in particular about RB1100AH and heX-mini
If this is possible, then how can I enable this function?
3. When you are mentioning "IEEE1588 timestamping in hardware", you refer to a dedicated hardware inside of Mikrotik that can send sync packets or 1PPS output signal?
4. Can "Boundary Clock" be implement on Mikrotik?
5. How can I enable Mikrotik to transport PTP packets? Is this a default option? If yes, how the ptp packets are recognized/isolated?


Thank you in advance!
 
mkx
Forum Guru
Forum Guru
Posts: 2605
Joined: Thu Mar 03, 2016 10:23 pm

Re: Feature requests

Mon Aug 19, 2019 5:15 pm

Answer to questions 1,2,4 and 5 is: No.

Variation of answer to question 2: most decent switches/routers are good enough as a (single?) step in otherwise fully IEEE1588-compliant path if they are lightly loaded so that delay jitter is really low. This way the additional constant delay due to active devices can be attributed to constant path delay (just think of it as being some 500km longer). Namely: the big thing about IEEE1588 (as compared to NTP) is to get around the delay jitter which kills precision of normal NTP. And delay jitter is there due to active devices doing buffering, not due to changing speed of light in fibre.

Answer to question 3 is: probably your understanding of IEEE1588 concept is not right. The Ptp-aware switches need HW support for timestamping ... because IEEE1588 requires very precise knowledge of delay imposed by device on PtP packet passing by. Which means the following steps done in hardware:
  1. add ingress timestamp to a packet immediately after it is received by ingress port (before it hits any cache or processing queue)
  2. get precise estimation of egress timestamp for that packet (which needs to take into account all remaining processing and cache waiting time)
  3. calculate delay from the above timestamps and adjust the PtP header.

So to enable IEEE1588, device needs HW support for the timestamping and currently none of Mikrotik's gear has it (or it has it exposed).

And the procedures above have nothing to do with 1PPS.
BR,
Metod
 
pe1chl
Forum Guru
Forum Guru
Posts: 5564
Joined: Mon Jun 08, 2015 12:09 pm

Re: Feature requests

Mon Aug 19, 2019 5:40 pm

The relevant question of course is: how often will it happen that installations with strict requirements like IEEE1588 will use equipment from MikroTik?
Will it lead to a lot of new sales when MikroTik switches do support IEEE1588?
IMHO there are LOTS of things missing from MikroTik switches, and IEEE1588 is only one of them.
It would require quite a lot of work to bring the switches up-to-par against enterprise switch offerings, and maybe it would not be very effective because it likely takes a lot of time before people that normally buy enterprise switches from the wellknown manufacturers would consider MikroTik as a less expensive but equally capable alternative.
 
ursy
just joined
Posts: 10
Joined: Thu Apr 04, 2019 1:46 pm

Re: Feature requests

Mon Aug 19, 2019 5:47 pm

Answer to questions 1,2,4 and 5 is: No.

Variation of answer to question 2: most decent switches/routers are good enough as a (single?) step in otherwise fully IEEE1588-compliant path if they are lightly loaded so that delay jitter is really low. This way the additional constant delay due to active devices can be attributed to constant path delay (just think of it as being some 500km longer). Namely: the big thing about IEEE1588 (as compared to NTP) is to get around the delay jitter which kills precision of normal NTP. And delay jitter is there due to active devices doing buffering, not due to changing speed of light in fibre.

Answer to question 3 is: probably your understanding of IEEE1588 concept is not right. The Ptp-aware switches need HW support for timestamping ... because IEEE1588 requires very precise knowledge of delay imposed by device on PtP packet passing by. Which means the following steps done in hardware:
  1. add ingress timestamp to a packet immediately after it is received by ingress port (before it hits any cache or processing queue)
  2. get precise estimation of egress timestamp for that packet (which needs to take into account all remaining processing and cache waiting time)
  3. calculate delay from the above timestamps and adjust the PtP header.

So to enable IEEE1588, device needs HW support for the timestamping and currently none of Mikrotik's gear has it (or it has it exposed).

And the procedures above have nothing to do with 1PPS.
Thank you very much MKX,

Still I want to ask you about 1PPS signal.
1. Is there any component/hardware (eg: GPS) of a Mikrotik equipment which can provide to the other LAN equipment such kind of signal (1PPS)?
2. I have a heX router (NTP client) which is synchronized to a RB1100AH (NTP server). Directly connected to heX, there is a gear who can generate/provide 1PPS signal. Can I combine the NTP clock and 1PPS signal to provide a precise clock for a different equipement, either mikrotik or any other brand?

Thank you again
 
mkx
Forum Guru
Forum Guru
Posts: 2605
Joined: Thu Mar 03, 2016 10:23 pm

Re: Feature requests

Mon Aug 19, 2019 9:37 pm

Still I want to ask you about 1PPS signal.
1. Is there any component/hardware (eg: GPS) of a Mikrotik equipment which can provide to the other LAN equipment such kind of signal (1PPS)?
2. I have a heX router (NTP client) which is synchronized to a RB1100AH (NTP server). Directly connected to heX, there is a gear who can generate/provide 1PPS signal. Can I combine the NTP clock and 1PPS signal to provide a precise clock for a different equipement, either mikrotik or any other brand?
1. No idea. If I have to choose, then I'd hesitantly choose a yes.
2. If you use NTP (which is the most precise timing protocol supported by mikrotik) to propagate the time, then I don't think you gain much by using 1PPS source ... Precission gain will have order of magnitude of milliseconds and that's also order of magnitude of precission obtainable using NTP over lightly congested IP connections.
BR,
Metod
 
pe1chl
Forum Guru
Forum Guru
Posts: 5564
Joined: Mon Jun 08, 2015 12:09 pm

Re: Feature requests

Mon Aug 19, 2019 9:55 pm

2. If you use NTP (which is the most precise timing protocol supported by mikrotik) to propagate the time, then I don't think you gain much by using 1PPS source ... Precission gain will have order of magnitude of milliseconds and that's also order of magnitude of precission obtainable using NTP over lightly congested IP connections.
I have an application which requires accuracy of ~10us and I generally use NTP for "coarse" time (~1ms) and then connect 1PPS from a GPS receiver directly to the PC for the
accurate sync (using chrony).
 
mkx
Forum Guru
Forum Guru
Posts: 2605
Joined: Thu Mar 03, 2016 10:23 pm

Re: Feature requests

Mon Aug 19, 2019 10:05 pm

2. If you use NTP (which is the most precise timing protocol supported by mikrotik) to propagate the time, then I don't think you gain much by using 1PPS source ... Precission gain will have order of magnitude of milliseconds and that's also order of magnitude of precission obtainable using NTP over lightly congested IP connections.
I have an application which requires accuracy of ~10us and I generally use NTP for "coarse" time (~1ms) and then connect 1PPS from a GPS receiver directly to the PC for the
accurate sync (using chrony).
That makes sense. I was wondering about combining NTP (for coarse estimation) with 1PPS (for precission) in a RB device and then propagating the time to "end users" via LAN but not using IEEE1588.
BR,
Metod
 
pe1chl
Forum Guru
Forum Guru
Posts: 5564
Joined: Mon Jun 08, 2015 12:09 pm

Re: Feature requests

Mon Aug 19, 2019 11:21 pm

That is likely not accurate enough to achieve such results. I connect the 1PPS to the DCD input of an old-style RS232 port (with UART on the bus, not via USB) and I achieve jitter like 3-5us.
This is possible because the edge of the 1PPS pulse directly generates an interrupt in the UART, and in the interrupt handler the nanosecond timestamp is read and put in a queue for processing by the kernel.
Such results are difficult to achieve without similar timestamping on the network interface (as is required for IEEE1588).
 
ursy
just joined
Posts: 10
Joined: Thu Apr 04, 2019 1:46 pm

Re: Feature requests

Tue Aug 20, 2019 11:31 am

Hi PE1CHL,

I'm using also a NTP server in a hEX combined with an external 1PPS signal generator. The NTP client is a unix machine which is synchronized with the hEX NTP server and via internal bus is fetching 1PPS signal. I'm to calculate the jitter.
1. Is there a way to combine the NTP with 1PPS inside of any Mikrotik gears conducting to a very accurate clock, as @MKX was wondering?
2. With your topic you want to say that the accuracy difference NTP+1PPS versus IEEE1588 is insignificant?
3. If in the future I decide to use a PTP/IEEE1588 grandmaster server and broadcast/unicast the clock via a VLAN, will this process of tagging/untagging have a big impact on the accuracy of the clock?

Thank you!
 
ursy
just joined
Posts: 10
Joined: Thu Apr 04, 2019 1:46 pm

Re: Feature requests

Tue Aug 20, 2019 11:45 am

Still I want to ask you about 1PPS signal.
1. Is there any component/hardware (eg: GPS) of a Mikrotik equipment which can provide to the other LAN equipment such kind of signal (1PPS)?
2. I have a heX router (NTP client) which is synchronized to a RB1100AH (NTP server). Directly connected to heX, there is a gear who can generate/provide 1PPS signal. Can I combine the NTP clock and 1PPS signal to provide a precise clock for a different equipement, either mikrotik or any other brand?
1. No idea. If I have to choose, then I'd hesitantly choose a yes.
2. If you use NTP (which is the most precise timing protocol supported by mikrotik) to propagate the time, then I don't think you gain much by using 1PPS source ... Precission gain will have order of magnitude of milliseconds and that's also order of magnitude of precission obtainable using NTP over lightly congested IP connections.
Hi Mkx,
I have the answer to the question:
"Is there any component/hardware (eg: GPS) of a Mikrotik equipment which can provide to the other LAN equipment such kind of signal (1PPS)?"

According to wiki (https://wiki.mikrotik.com/wiki/Manual:System/GPS):
Note: The time is not stratum 1 as RouterBOARD devices do not have PPS implemented
 
mkx
Forum Guru
Forum Guru
Posts: 2605
Joined: Thu Mar 03, 2016 10:23 pm

Re: Feature requests

Tue Aug 20, 2019 12:10 pm

1. Is there any component/hardware (eg: GPS) of a Mikrotik equipment which can provide to the other LAN equipment such kind of signal (1PPS)?

1. No idea. If I have to choose, then I'd hesitantly choose a yes.

According to wiki (https://wiki.mikrotik.com/wiki/Manual:System/GPS):
Note: The time is not stratum 1 as RouterBOARD devices do not have PPS implemented

I knew that. The reason for my hesitation is this: many (but not all) GPS modules have 1PPS output enabled and then it's up to hardware and software implementation if that 1PPS signal is available/used or not. MT devices don't use 1PPS signal, but if GPS modules are general enough, they might have 1PPS signal available and it might be possible to make that signal available to some 3rd device (as in your use case). It would require hardware modification though.
BR,
Metod
 
pe1chl
Forum Guru
Forum Guru
Posts: 5564
Joined: Mon Jun 08, 2015 12:09 pm

Re: Feature requests

Tue Aug 20, 2019 12:13 pm

Hi PE1CHL,
I have no practical experience with PTP. Some years ago I needed clocks on a couple of servers very accurately synced for a co-channel FM transmitter network we were building.
What I had available was professional GPSDOs with 10 MHz and 1 PPS output, and of course the network (which happens to be MikroTik-routed but that is not significant).
The GPSDOs were of different types. I wrote some software to get the current time out of them but some were so old that they could not provide correct date (due to GPS week rollover) and on some sites we did not own the GPSDO so we could only tap the 10 MHz and 1 PPS via distribution amplifiers and not the (usually RS232) time info.

So what I did was like this:
- install chrony on the involved servers (Linux of course, when you run Windows servers there is no point in all of this...)
- configure external time servers for the basic time synchronization to within 10ms (usually within 1ms).
- connect 1 PPS hardware signal to RS232 DCD input via a suitable pulse stretcher and line driver (not really required with all GPSDOs, some already deliver 100ms pulse which is fine)
- load "ldattach 18 /dev/ttyS0" to input the PPS signal to the kernel pps device
- configure "refclock PPS /dev/pps0 refid PPS" into chrony to use PPS signal

This results in chrony status like this:
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
#* PPS                           0   4   377    16   +719ns[ +834ns] +/- 4782ns
^- lpk.pi2nos.ampr.org           1   9   377   104   +106us[ +111us] +/-  244us
^- pi2nos.ampr.org               1  10   377   672   +915us[ +938us] +/- 2275us
^- pi3goe.ampr.org               1  10   377   931    +95us[ +109us] +/- 5718us
So local PPS time distribution is simply as a discrete signal not via the network (PTP/IEEE1588). See it as a coax with BNC connectors running between the racks.
The majority of equipment is synchronized "just" with NTP, only the critical servers that control the transmitters (1 server per site) are wired up to the PPS.
 
mkx
Forum Guru
Forum Guru
Posts: 2605
Joined: Thu Mar 03, 2016 10:23 pm

Re: Feature requests

Tue Aug 20, 2019 12:36 pm

2. With your topic you want to say that the accuracy difference NTP+1PPS versus IEEE1588 is insignificant?
3. If in the future I decide to use a PTP/IEEE1588 grandmaster server and broadcast/unicast the clock via a VLAN, will this process of tagging/untagging have a big impact on the accuracy of the clock?

2. In IEEE1588 deployment there are different profiles. Perhaps the most stringent profiles are ITU-T G.8275.1 and G.8275.2 Telecom Profiles, which require accuracy of under a micro-second. I don't think this kind of precision is possible using off-the-shelf hardware and external 1PPS source. Most of real-life implementations (e.g. LTE base station network) require less stringent synchronization with precision of 1-10 micro seconds and in such cases the "home brewn" 1PPS solution gives adequate results. One needs to beware that profile requirements are one thing while IEEE1588 network actual performance is another thing, usually elements of such network are performing even better as the profile requirements are about end-2-end performance (from master clock to client across all boundary clocks) and in worse-case scenario jitter of individual nodes on the path accumulates.

3. Process of tagging/untagging might add considerable jitter (if done in software as per bridge vlan filtering) or only slight jitter (if done by switch chip). But as mentioned before: all active gear under non-trivial load adds to jitter in RTT and the only way to eliminate that is that equipment adds highly precise information about delay of each individual PTP packet to packet itself ... PTP gear doesn't introduce lower jitter per-se, it just can measure the packet delay with high precission.

There's actually another NTP problem that PTP addresses: non-symmetrical path delay. NTP allows measuring round-trip-delay and client then can only assume that RTT is symmetrical (same in both directions) to set own absolute time. If the delay is not symmetrical (either due to asymmetrical connection speed/load with buffering or due to asymmetrical routing or any other reason), then this can cause some systematic offset in times. PTP is more or less broadcast solution where master clocks broadcast time, border clocks add delay information to those packets (both constant connection delay as well as dynamic "fly-by" delay) and clients can calculate accurate absolute time. Feedback from client to master clock is not strictly necessary.
In LAN environments, where link speeds are likely symmetrical and links are rarely congested, this NTP phenomenon is not a big problem.
BR,
Metod
 
killersoft
Member Candidate
Member Candidate
Posts: 134
Joined: Mon Apr 11, 2011 2:34 pm
Location: Victoria, Australia
Contact:

Re: Feature requests

Thu Aug 22, 2019 9:12 am

Please add IEEE 802.1AE AKA MACSEC to Router & SwitchOS.
MIT, BIT, ITIL, CERT IV Electronics.
 
User avatar
normis
MikroTik Support
MikroTik Support
Topic Author
Posts: 24077
Joined: Fri May 28, 2004 11:04 am
Location: Riga, Latvia

Re: Feature requests

Thu Aug 22, 2019 9:15 am

Please add IEEE 802.1AE AKA MACSEC to Router & SwitchOS.
This is already done in v7
No answer to your question? How to write posts
 
huntermic
newbie
Posts: 35
Joined: Wed Oct 26, 2016 3:42 pm

Re: Feature requests

Thu Aug 22, 2019 12:27 pm

Please add IEEE 802.1AE AKA MACSEC to Router & SwitchOS.
This is already done in v7
There is no v7
 
msatter
Forum Guru
Forum Guru
Posts: 1176
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: Feature requests

Thu Aug 22, 2019 12:36 pm

Please add IEEE 802.1AE AKA MACSEC to Router & SwitchOS.
This is already done in v7
There is no v7
There is as you can see at the top of this page:

BETA Testing and Feature Suggestions for the next RouterOS release (ROS v7)
Two RB760iGS (hEX S) in series. One does PPPoE and both do IKEv2.
Running:
RouterOS 6.46Beta / Winbox 3.19 / MikroTik APP 1.3.1
Having an Android device, use https://github.com/M66B/NetGuard/releases (no root required)
 
huntermic
newbie
Posts: 35
Joined: Wed Oct 26, 2016 3:42 pm

Re: Feature requests

Thu Aug 22, 2019 12:42 pm

Please add IEEE 802.1AE AKA MACSEC to Router & SwitchOS.
This is already done in v7
There is no v7


There is as you can see at the top of this page:

BETA Testing and Feature Suggestions for the next RouterOS release (ROS v7)

Yep, i missed that part...…
 
pe1chl
Forum Guru
Forum Guru
Posts: 5564
Joined: Mon Jun 08, 2015 12:09 pm

Re: Feature requests

Thu Aug 22, 2019 4:33 pm

Please add IEEE 802.1AE AKA MACSEC to Router & SwitchOS.
This is already done in v7
Maybe you can put a topic here of those features that are already done in v7?
Then it would be easy for people to check before making a request. And also keep us happier while we are waiting for it.
 
msatter
Forum Guru
Forum Guru
Posts: 1176
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: Feature requests

Thu Aug 22, 2019 5:41 pm

There is a page in the Wiki, which is empty, that could be used for feature request to be implement and implemented in v6 or v7:

http://wiki.mikrotik.com/wiki/MikroTik_ ... e_Requests
Two RB760iGS (hEX S) in series. One does PPPoE and both do IKEv2.
Running:
RouterOS 6.46Beta / Winbox 3.19 / MikroTik APP 1.3.1
Having an Android device, use https://github.com/M66B/NetGuard/releases (no root required)

Who is online

Users browsing this forum: No registered users and 11 guests