X86_64 ROS - 64bit Mikrotik

exe · Mon Jan 09, 2017 3:58 am

Is there some insights when 64bit version of x86 can be released? Date ?

We cannot use CHR as there will be enough resources for our routers and we have issue with memory low or leak on quad channel motherboards.

Mikrotik should inject 64bit kernel into x86 6.37.3 version fast and fix some issues which appear after that ... We know it is complicated, but in our opinion x86 is useless and mikrotik should switch to x86_64bit asap.

Mon Jan 09, 2017 7:39 am

I am afraid that mikrotik focuses on chr mainly and I am expecting they will stop x86 support one day.

cheeze · Mon Jan 09, 2017 8:45 am

I as well wish we had X86_64 on the bare metal installs. I *hate* the overhead that a VM adds...albeit I will admit a lot of times it's less than 5% total overhead costs. So for what it's worth one can get 95% of the throughput of a VM. The problem I have is how to start a VM automagically if the system has a power failure. That and how to isolate out the local system from being accessible and only allowing the VM to be accessible.

Eh, it is what it is.

Mon Jan 09, 2017 5:55 pm

Hypervisors start the VMs normally after the boot. Even vmware workstation does it if you switch the machines to shared ones. The selection of the hypervisor is on you.

irico · Mon Jan 09, 2017 6:13 pm

On Hyper-V you can configure auto start, too.

docmarius · Mon Jan 09, 2017 9:13 pm

Running the 32bit version bare metal on 64bit capable processors actually brings no penalties except memory addressing limit at 4GB. In some conditions it can even be faster (e.g. reading unaligned bytes, which happens often in network protocols on content dissection).
On the other hand, on 64bit you will get the dude server...

FezzFest · Tue Jan 10, 2017 1:18 am

RouterOS x86 is limited to 2GB of RAM, not even 4GB.

exe · Thu Jan 12, 2017 1:30 am

CHR do not offer satisfactory setup in our case in term of resources, install process and stability. We already tried. Also, there is issue if you use 10G interfaces. In x86 mikrotik every 10G card can have ALL Cores of CPU for processing. So if you use CPU with 8 cores, all 8 can process every such 10G NIC. If you use CHR, you have only one core per 10G NIC, which is terrible in performance. That is WHY, 64bit version of mikrotik is needed asap.

As 32bit offer possibility to use up to 4GB of RAM it will be maybe satisfactory, but 2GB which mikrotik see with 32bit version is very low, especially if there is more full bgp routing tables.
We see some strange memory leak also, but hopefully mikrotik support will handle it. Possible it is related to quad channel motherboard.

Anyway we need x86_64bit version asap. They should stop x86 and switch to x86_64bit.

gallysoft · Fri Jan 13, 2017 7:16 pm

CHR do not offer satisfactory setup in our case in term of resources, install process and stability. We already tried. Also, there is issue if you use 10G interfaces. In x86 mikrotik every 10G card can have ALL Cores of CPU for processing. So if you use CPU with 8 cores, all 8 can process every such 10G NIC. If you use CHR, you have only one core per 10G NIC, which is terrible in performance. That is WHY, 64bit version of mikrotik is needed asap.

As 32bit offer possibility to use up to 4GB of RAM it will be maybe satisfactory, but 2GB which mikrotik see with 32bit version is very low, especially if there is more full bgp routing tables.
We see some strange memory leak also, but hopefully mikrotik support will handle it. Possible it is related to quad channel motherboard.

Anyway we need x86_64bit version asap. They should stop x86 and switch to x86_64bit.

I totally agree with you.

Daniele

Muqatil · Sat Jan 14, 2017 1:44 pm

CHR main advantages are the drivers.
X86 Mikrotik has a lot of problems with Hardware compatibilities which CHR resolves using virtual interfaces.
X64 Mikrotik would have the same problems.

exe · Mon Jan 16, 2017 3:50 am

CHR main advantages are the drivers.

Unfortunatelly, main disadvantage of CHR is performance at all and performance if you use 10G interfaces. We tested and with 10G CHR is not capable to do anything serious. On the other hand, x86 is capable to do it perfect in term of performance except limit of 2GB RAM.

X86 Mikrotik has a lot of problems with Hardware compatibilities which CHR resolves using virtual interfaces.
X64 Mikrotik would have the same problems.

We do not have issues with X86 except RAM and some memory leak. When RAM is limited to 2GB, you cannot have full routing table peering with more ISPs.

X64 will solve ALL THIS at once.

Mon Jan 16, 2017 9:10 am

We tested and with 10G CHR is not capable to do anything serious

What problems did you see? Have you contacted support about it?

chubbs596 · Mon Jan 16, 2017 1:35 pm

+1 for X86_64

I would also prefer to run this on Bare metal rather than VM,

What real advantage do we get from CHR apart from more that 2GB of ram? I have not seen Fastpath or anything like that? We Run Proxmox / KVM and tried with virtio interface and vmxnet3.

hiphin · Tue Jan 17, 2017 11:14 am

+1 for X86_64

keep VM, but also give X86_64

exe · Wed Jan 18, 2017 1:00 pm

Code: Select all
We tested and with 10G CHR is not capable to do anything serious
What problems did you see? Have you contacted support about it?

Normis, we contacted support regarding issue in x86 with quad channel motherboard and ram leak. Last response by support was on 27.12. We also send supout files after that and no response.

Main issue with CHR is that is not capable to process 10G NIC with more than one core of CPU. We will send you pictures to support email as we already done it.

Drend · Mon Jan 23, 2017 3:46 am

+1 for X86_64
we need it urgent too as CHR is not satisfied in terms of nic performance

mrakdk · Mon Jan 30, 2017 1:04 pm

I just found this excellent topic.

We need x64 ASAP. Not possible to use 10G Nic with CHR with high performance mikrotik router. X86 not enough memory for bgp peers. Mikrotik help us.

hashbang · Mon Jan 30, 2017 4:03 pm

Looks like I have the same problem

http://forum.mikrotik.com/viewtopic.php?f=15&t=117306

SystemErrorMessage · Sun Feb 12, 2017 1:00 am

I also find myself not using virtualisation either. While i use a routerboard rather than x86, routerOS on TILE is 64 bit being able to address large amounts of RAM.

On x86 theres so much hardware that there is the issue of driver support however when it comes to linux, driver support isnt an issue if you could add drivers to it yourself rather than MT's closed policy of not letting anyone mess with the linux bit of routerOS. In the past there were utilities that allowed you to use windows drivers for wifi NICs on linux as well.

The main reason why i dont use virtualisation is because the overhead of virtualisation is huge on memory performance, not for CPU performance rather. Since i use my servers for things like game servers, compilations and for massive parallisation virtualisation would hurt performance significantly as memory performance is needed for moving data between other things like GPUs, 10G NICs and such. On routing performance if you look at the CCR1072 it seems that memory performance does effect routing performance as well as shown on the benchmarks. For routing memory performance does matter when you are moving data at speeds significantly proportional to memory bandwidth. This means that if you are using DDR3 dual channel for a 1Gb/s connection, using virtualisation wont hurt but at 10Gb/s it can.

on x86, using a 64 bit OS is faster than a 32 bit OS, this is because of the extensions that allow multiple data to be processed at the same time. So by using 64 bits your instructions will be bigger but will still be fed into the CPU the same rate as if you used a 32 bit OS with 32 bit length data. So using 8 or 16 bit data on 64 bit x86 does not incur any penalty as x86 is a very complex instruction set with extended instructions to accelerate larger data processing focusing on IPCs. On GPUs however using 16 bit integers are slower than using 32 floats with the exception of nvidia's pascal architecture and on AMD before GCN using 16 bit floats, not integers was faster than 32 bit floats.

I really think MT needs to look into how the linux distros get their drivers. A lot of vendors will willingly write drivers for routerOS as it uses linux as long as the difference isnt great. I suspect that part of the problem is that a number of drivers require libraries that routerOS will not include in its OS. a 64 bit routerOS for x86 will really be beneficial and people who see routerOS for the first time prefer trying it out on x86 in an office environment rather than buying a routerboard as they have servers laying around.

patrick7 · Sun Feb 12, 2017 2:13 am

It sounds hard, but I think the only reason is "they don't want". As far as I know there is no technical reason why x86 only accepts 2GB. It just let sell CCRs better.

krzysztof · Fri Feb 17, 2017 3:12 am

Architecture x86_64 bit

It works very well and efficiently.
I don't know why Mikrotik not given officially as a start.
I know about the x86_64 bit stabel since May 2016 years
There are several important settings to work, but mikrotik nothing reports about them.

[admin@MikroTik] /system resource> print
uptime: 1h37m39s
version: 6.38.1 (stable)
build-time: Jan/13/2017 05:51:35
free-memory: 23.0GiB
total-memory: 23.5GiB
cpu: Intel(R)
cpu-count: 24
cpu-frequency: 3066MHz
cpu-load: 59%
free-hdd-space: 462.0GiB
total-hdd-space: 462.1GiB
write-sect-since-reboot: 680
write-sect-total: 680
architecture-name: x86_64
board-name: x86
platform: MikroTik
-------------------------------------
Regards,
Krzysztof Pawluk
krzysztof@pawluk.org

janisk · Fri Feb 17, 2017 11:45 am

It sounds hard, but I think the only reason is "they don't want". As far as I know there is no technical reason why x86 only accepts 2GB. It just let sell CCRs better.

there is a reason why RouterOS on x86 supports only 2GB - the speed of memory addressing. With high/low setups you would lose 5 to 10% of performance.

SystemErrorMessage · Sun Feb 19, 2017 7:40 am

It sounds hard, but I think the only reason is "they don't want". As far as I know there is no technical reason why x86 only accepts 2GB. It just let sell CCRs better.
there is a reason why RouterOS on x86 supports only 2GB - the speed of memory addressing. With high/low setups you would lose 5 to 10% of performance.

It is entirely dependent on the memory controller. In the past that may be so when extended memory support wasnt available. From the last decade every PC has extended memory support in the controller itself allowing for more than 4GB of ram to be addressed in 32 bit mode especially if the CPU is a 64 bit architecture as there wont be any performance penalty in that case.

Besides even if it isnt true and you get performance penalty, not having enough ram will cause even more performance issues.

exe · Fri Feb 24, 2017 10:15 am

Architecture x86_64 bit

This is CHR or ?

It sounds hard, but I think the only reason is "they don't want". As far as I know there is no technical reason why x86 only accepts 2GB. It just let sell CCRs better.
there is a reason why RouterOS on x86 supports only 2GB - the speed of memory addressing. With high/low setups you would lose 5 to 10% of performance.

5-10% it's not a problem at all. I doubt this will be the case but as we have 1-20% load on x86 it will not be an issue. On the other hand, 2GB of RAM which ROS see, is a big PROBLEM.

As SystemErrorMessage said, nowadays memory controllers are very fast, so we will not lose any of performance.

Fri Feb 24, 2017 3:05 pm

nowadays memory controllers are very fast, so we will not lose any of performance.

You will, in fact. And that is a well known fact. Memory controller won't help you when it comes to a twice as large pointer size.

Having said that, I don't think it's a real reason why RouterOS x64 does not exist outside of the CHR world.

SystemErrorMessage · Sat Feb 25, 2017 7:57 pm

5-10% penalty from memory is if you use registered/buffered ram for those using large amount of ram. So unless you plan to have more than 80GB of ram this doesnt matter. The memory controller will work at the same speed relatively regardless of the amount of ram for the memory controller on the CPU. Since it is on the CPU it is so fast with very fast bus to the CPU that the amount of memory, pointer sizes and such dont matter.

Look at the x86 architecture now, the memory controller will be just as fast regardless of memory size as for a 64 bit CPU, the pointer size will also be 64 bits. This isnt trying to use extended memory on a 32 bit system where extra processing is added to the controller.

you say 5-10% less memory performance. Lets take a typical dual channel memory system, you have 2x1GB vs 2x4GB, both have the same frequency, timings, etc. Will addressing all the 8GB really make it slower? I mean if the ram bandwidth is 32GB/s does it matter how much memory because im pretty sure even with extra load that memory controller is still gonna work at 32GB/s limited by the ram itself and not the controller.

As i said not having enough RAM is a bigger performance killer than an insignificant difference in ram speed from having more ram if such even exists.

krzysztof · Sun Feb 26, 2017 1:13 am

nowadays memory controllers are very fast, so we will not lose any of performance.
You will, in fact. And that is a well known fact. Memory controller won't help you when it comes to a twice as large pointer size.

Having said that, I don't think it's a real reason why RouterOS x64 does not exist outside of the CHR world.

You write not truth.
Mikrotik X64 work very well on the X86 platform.
I have such of a platform

[admin@MikroTik] /system resource> print
uptime: 1h37m39s
version: 6.38.1 (stable)
build-time: Jan/13/2017 05:51:35
free-memory: 23.0GiB
total-memory: 23.5GiB
cpu: Intel(R)
cpu-count: 24
cpu-frequency: 3066MHz
cpu-load: 59%
free-hdd-space: 462.0GiB
total-hdd-space: 462.1GiB
write-sect-since-reboot: 680
write-sect-total: 680
architecture-name: x86_64
board-name: x86
platform: MikroTik
-------------------------------------
Regards,
Krzysztof Pawluk

cheeze · Sun Feb 26, 2017 1:25 am

nowadays memory controllers are very fast, so we will not lose any of performance.
You will, in fact. And that is a well known fact. Memory controller won't help you when it comes to a twice as large pointer size.

Having said that, I don't think it's a real reason why RouterOS x64 does not exist outside of the CHR world.
You write not truth.
Mikrotik X64 work very well on the X86 platform.
I have such of a platform

[admin@MikroTik] /system resource> print
uptime: 1h37m39s
version: 6.38.1 (stable)
build-time: Jan/13/2017 05:51:35
free-memory: 23.0GiB
total-memory: 23.5GiB
cpu: Intel(R)
cpu-count: 24
cpu-frequency: 3066MHz
cpu-load: 59%
free-hdd-space: 462.0GiB
total-hdd-space: 462.1GiB
write-sect-since-reboot: 680
write-sect-total: 680
architecture-name: x86_64
board-name: x86
platform: MikroTik
-------------------------------------
Regards,
Krzysztof Pawluk

Where did you get an x64 build of RouterOS that is not CHR and that is natively working on bare metal?

Mine looks like this:

                   uptime: 3w6d2h8m41s
                  version: 6.38.1 (stable)
               build-time: Jan/13/2017 05:51:35
              free-memory: 1735.3MiB
             total-memory: 1893.8MiB
                      cpu: Intel(R)
                cpu-count: 4
            cpu-frequency: 2666MHz
                 cpu-load: 0%
           free-hdd-space: 73.1GiB
          total-hdd-space: 73.3GiB
  write-sect-since-reboot: 4978130
         write-sect-total: 4978130
        architecture-name: x86
               board-name: x86
                 platform: MikroTik

exe · Thu Mar 02, 2017 3:54 am

It seems that krzysztof manually changed architecture-name: x86 to architecture-name: x86_64 only in post.

sasskass · Fri Mar 03, 2017 5:45 am

Think Mikrotik must change the licensing policy...

Please ask a little fee for the upgrade, rather to ignore the x86

Lets do x86 upgrade for some awsome fee, but you still earn a very big profit and the most important -

Respect from Your patriots.

Now Your are loosing them...

So Mikrotik let the x86_64 come out..

Kind Regards

Aleksnder

Fri Mar 03, 2017 10:30 am

Use CHR, it is free and has 64bit support

exe · Sun Mar 05, 2017 2:06 am

Normis, please explain then how CHR can use all CPU PCI-E Lanes and be equal in performance to X86 especially with 10G interfaces?

cheeze · Sun Mar 05, 2017 6:48 am

I got an idea Normis.

How about this.

Eventually deprecate the x86 installation. Then go to something like The Yocto Project and build a very lean Linux VM hypervisor but only for a singular VM, the CHR VM. Make it a completely automated installation and have it setup as a baseline Linux/KVM with one CHR host.

That way there's always a stable, sustainable, and really fast hypervisor/CHR host. As well as a completely separated and uninterrupted RouterOS installation that can be tuned without having to constantly add tons and tons of drivers. Then one can let the Linux kernel to add drivers and said drivers for said devices can be imported to the CHR through the VM hypervisor as generic interfaces.

It almost seems like a triple win. Really lean VM host + non-changing RouterOS/CHR environment + abstraction of all device drivers as generic interfaces that can be further optimized.

The *ONLY* thing that would need to happen is that there *needs* to be better 10Gb/sec optimizations between CHR and the hardware so that one can actually achieve those data rates.

Chupaka · Mon Mar 06, 2017 12:46 am

It seems that krzysztof manually changed architecture-name: x86 to architecture-name: x86_64 only in post.

he also 'changed' free- and total-memory

now just look at 'Extra packages' links in Download page. this .zip contains everything including 'system' package (which contains the kernel, I believe

)

X86 link:
https://download2.mikrotik.com/routeros ... 6.38.3.zip

CHR link:
https://download2.mikrotik.com/routeros ... 6.38.3.zip

now find the difference

so seems like 'x86_64' is just a flag somewhere in the file system

by the way, I have old good RouterOS virtual machine which was installed when no CHR existed:

[admin@TestPlace] > system resource print 
                   uptime: 1w1d2h51m41s
                  version: 6.39rc38 (testing)
               build-time: Feb/24/2017 08:46:35
              free-memory: 21.7MiB
             total-memory: 88.4MiB
                      cpu: Intel(R)
                cpu-count: 1
            cpu-frequency: 2933MHz
                 cpu-load: 0%
           free-hdd-space: 58.8MiB
          total-hdd-space: 99.2MiB
  write-sect-since-reboot: 394778
         write-sect-total: 394778
        architecture-name: x86_64
               board-name: x86
                 platform: MikroTik

in some early v6 versions there was a checkbox under 'System -> Resources -> Hardware' for enabling 64-bit mode. looks like they removed it and created the CHR as a separate system

Chupaka · Mon Mar 06, 2017 1:21 am

let's have an experiment. starting with this:

[admin@MikroTik] > sys resource pr
                   uptime: 3m32s
                  version: 6.30rc20
               build-time: Jun/12/2015 14:48:23
              free-memory: 231.6MiB
             total-memory: 249.7MiB
                      cpu: Intel(R)
                cpu-count: 2
            cpu-frequency: 2933MHz
                 cpu-load: 0%
           free-hdd-space: 73.4MiB
          total-hdd-space: 99.1MiB
  write-sect-since-reboot: 514
         write-sect-total: 514
        architecture-name: x86
               board-name: x86
                 platform: MikroTik

upgrade it to v6.31:

[admin@MikroTik] > sys resource print 
                   uptime: 55s
                  version: 6.31
               build-time: Aug/14/2015 15:42:51
              free-memory: 233.8MiB
             total-memory: 250.0MiB
                      cpu: Intel(R)
                cpu-count: 1
            cpu-frequency: 2933MHz
                 cpu-load: 0%
           free-hdd-space: 65.6MiB
          total-hdd-space: 99.1MiB
  write-sect-since-reboot: 614
         write-sect-total: 614
        architecture-name: x86
               board-name: x86
                 platform: MikroTik

(look at 'cpu-count: 1' - probably, that's the reason why download links for that version don't work)

go to System -> Resource -> Hardware - check 'Allow x86-64' (in WinBox. can't find it in CLI). reboot

and voila!.. oops, 'architecture-name: x86'

no worry, just upgrade to the latest version:

[admin@MikroTik] > /sys resource print 
                   uptime: 1m24s
                  version: 6.38.3 (stable)
               build-time: Feb/07/2017 09:52:42
              free-memory: 200.2MiB
             total-memory: 221.8MiB
                      cpu: Intel(R)
                cpu-count: 2
            cpu-frequency: 2933MHz
                 cpu-load: 0%
           free-hdd-space: 66.5MiB
          total-hdd-space: 99.2MiB
  write-sect-since-reboot: 708
         write-sect-total: 708
        architecture-name: x86_64
               board-name: x86
                 platform: MikroTik

sasskass · Mon Mar 06, 2017 1:40 am

Hi

CHR is not ASIC as Cisco or Juniper.. So making x64 will do Your product flexible to hw bugs, as they are common suffering on CHR-s and every other type of RB-s

Then You will have a lot of betatesters whome you are not responsible of - Buy now your are testing with loosing them.

For me - im tied to be a neverending alphatester!

Kind Regards

Aleksander

hyperpaccket · Mon Mar 06, 2017 6:14 am

I am a big mikortik user and run RouterOS almost network wide.

I have no interest in my core routers being virtual machines and have build x86 machines (so I can get a good mix of 10GBE ports and 1GBE ports) to serve as our routers.

It surely cannot be hard to port the CHR to an ISO that we can install on bare metal.

exe · Wed Mar 08, 2017 3:35 am

Chupaka !!!! Check this!

What I do... I downgraded our test router to 6.31 and enabled x64:

mikrotik-x64-6.31.jpg

Then upgrade to 6.38.1:

mikrotik-x64-6.38.1.jpg

It seems that krzysztof told us the true!!!!

Chupaka · Wed Mar 08, 2017 4:15 am

Just like I said

Now you may press 'Thumb up' on my post and get back to studying 64-bit version

exe · Wed Mar 08, 2017 4:24 am

We installed on our production router, all 16G RAM at work right now

Plenty of traffic! Do you think it will be stable?

cheeze · Wed Mar 08, 2017 5:11 am

Whoa whoa whoa.....what?

Access Denied on the 'tik website

krzysztof · Mon Mar 27, 2017 2:49 am

X86_64 - This is super secret.

RouterOS X86_64 with BGP works around 200-300% faster than CCR1036 and CCR1072.
It is important to turn off Hyper-threading!

X86_64 works just fine with the platforms where intel is on the motherboard is very important!

For example, the X86_64 works well with the HP DL180G6 plus 2 x Intel® Xeon® Processor X5675 (12M Cache, 6 x 3.06 GHz, 6.40 GT / s)

CCR1036 and CCR1072 for BGP do not differ in performance.
In RouterOS for BGP uses only one core! That's why X86_64 is so powerful.

Normis please do not liquidate X86_64.
Without X86_64 our computer networks will not work well.

Regards
Krzysztof Pawluk

exe · Mon Mar 27, 2017 1:31 pm

It is important to turn off Hyper-threading!

Why to turn off Hyper-threading? It works perfect with hyper threading so far.

krzysztof · Thu Mar 30, 2017 12:30 am

The BGP process needs the whole core.

RouterOS does not know that there are virtual cores and will allocate calculations to the cores which are already burdened by another process.
When you don't turn off Hyper-threading you will slow down BGP by to 50%.
This rule applies to BGP because it doesn't split into multiple cores.

Regards
Krzysztof Pawluk

PCT2015 · Sat May 27, 2017 11:55 pm

hi, all is a good topics

Somebody upgrade to 6.39 on x86 ? ,
About HT, off on, have a some test or % about CPU load, whit BGP peer fulltable ?

I have version 6.37.1 , in x86 HP server, lic lvl6, whit a NIC silicom 6 ports10GB.
have 4 full table peers, and have the same problem memory limited on 2gb., when on motherboard have 8gb

This upgrade is 100% secure to fix the problem for memory?
Whit version are most stable whit x86_64 6.38.3 or 6.38.5 ?

thanks

doneware · Tue May 30, 2017 4:57 pm

go to System -> Resource -> Hardware - check 'Allow x86-64' (in WinBox. can't find it in CLI). reboot

the similarly looking CLI place is /system/hardware which has the "multi-cpu" setting, but mine is on routeros 6.36.2 and does not show the x86_64 neither in CLI nor in winbox.

doneware · Tue May 30, 2017 5:04 pm

strangely the mikrotik archive download page returns "access forbidden" when trying to download the x86 npk. maybe just a coincidence. or the 32bit conspiration

https://download2.mikrotik.com/routeros ... 6-6.31.npk

<Error>
<Code>AccessDenied</Code>
<Message>Access Denied</Message>
<RequestId>95339A20FCD18B9F</RequestId>
<HostId>
NICSBK5w5In3gA4SCT1M1fQR0rIaJ4q7eUQ6JCHBZ1x04//VEn+8qpGHR/AMJiiI+zsUtESCfzA=
</HostId>
</Error>

Chupaka · Tue May 30, 2017 6:27 pm

Just as I said

PCT2015 · Wed May 31, 2017 9:10 pm

Just as I said

you are right, ... 1000%

Only works whit a valid license key..!!

Takv · Fri Jun 09, 2017 11:41 am

Testing x86_64 architecture in AMD A10-7680K with 4GB DDR3 1333 mhz and working so far.

The "secret" works. Updated to 6.39.2. Just one problem: the internal speaker (motherboard speaker for bios sounds, etc) dont work.

Looking for a fix of that.

No problems except that.

From v6.31, check the x86_64 box, reboot, voila! -> Upgrade, Done!

I'll post the further experience.

Mirror: http://mirror.poliwangi.ac.id/mikrotik/6.31/

karwos · Tue Jul 25, 2017 7:29 pm

Guys is there any real *benefit* from running CHR in x86_64 native environment?
I know VM puts some overhead, but c'mon, that's not 2006, It's 2017 when most of hardware, including CPUs and NICs have hardware virtualization support.
Overhead is small nowadays, I am running two BGP servers and they are just work perfect in CHR.
Plus, you can also monitor your CPU/mem usage, and add some additional , low-priority tasks like DDOS monitoring or anything you like, and mirorr all traffic inside VM kernel, no need to occupy switch space.

Plus you just dump your VM image for backup/restore schemas. I think VM is *correct* future, unless you forward really huge amount on traffic, but then you already need specialised routing or MPLS asic for that ...
Also you just use vmxnet3 driver (if not passthroughing), and don't care about underlaying hardware in most of cases.

I just think that there's just more advantages than disadvantages of this way.

my 2 cents.

gdo · Wed Jul 26, 2017 1:08 am

Think Mikrotik

Chupaka · Wed Jul 26, 2017 10:39 am

I am running two BGP servers and they are just work perfect in CHR.

what traffic do you have on them?

BGP without full view works perfect on any RB hardware

Kreacher · Wed Jul 26, 2017 11:45 am

Hello to all,

I was ready this thread very carefully and also "between the lines" and must now please enter that discussion about the x86_64Bit, because there are some things
about that must be spoken if you are talking about MikroTik and x86_64Bit. (Only in my opinion)

I company rules, from who given, dictated or written, all employees of a company should and must follow! And this is surely not on at MikroTik in Latvia so,
because we all have wishes, demands and/or needs that could be "easily" solved out by a x86_64Bit router software, it means that this must be not seen
on both ends of that discussion. And yes, I respect the standing point of MikroTik Latvia and perhaps their partners or suppliers, but for sure it will be fine
to get in deeper zone of this forum thread. At first I want to say thanks to MikroTik to give us a forum and podium to discuss this out and that freely and on
the other side because I really know many of us are in business contact with MikroTik and their complete product portfolio and being not only home users.

But then money comes into the game play and the company MikroTik must also see what they will get from their clients and customers, for sure it sounds
nice to get hands on a MikroTik RouterOS x86_64Bit version, but is it worth to play then with the whole company security? Who gives them a promise that
only one copy will be used or if someone will be installing one system and copy it over and over and over only with one License code? What is then? Who
cares then on their business and an their income or plain on their money? For sure getting hands on a copy will be fine but how many users will then trade
over P2P networks this registered copy then?

I personally think x89_64Bit would be a really hammer smashing into the whole market and many router and firewall vendors must find then a way to answer
that! This could be a game changer, a cash cow and many things more for Mikrotik and for sure also us. But please also think on the other side of the business!

At this moment you will be able to see many changes in the market, AES-NI support here and there, Intel´s QuickAssist (QAT) is out and drivers are there for
Linux, DPDK (enabled software) could be transporting more then 3x the amount of IP packets then normal, and this using the same platform for sure. Multi-CPU
core usage and HT technology will be then doing the rest to get closer and come to a really routing champion device. HotLava is producing multi Port NICs with
original Intel Chipsets and that will lets gain up the entire port density of many routers for sure.

As for the memory lag and speed, this must be given both, the speed and amount must be matching right to that units, but with 64Bit no problem the most of us are
thinking. I mean really if there is not enough amount of RAM you can get surely into pain, but on the other side if the RAM is to low clocked the entire router system
can be saturated and you will be owning a freezing or lacking router then! Getting or producing huge packet losses or packet drops will be the result of that behaviour.

At this time we will see many existing and new platforms on the market for any kind of suitable cases and segments, all four areas will be served and sorted by only one
platform, for home playground, over SOHO market, entering the Pro area and ending up the enterprise zone. This could be a game changer for many of us. mSATAs and
SSDs will be able to hold big user manager DBs and/or TheDUDE Server instalments.

Home environments:
Helor Intel Celeron 1037U (dual core)
Jetway NF9HG-2930 (Quad core)
Plain routing, OpenVPN

PC Engines APU2C4 (Quad core)
Plain routing, IPsec (AES-NI)

SOHO market:
Jetway JNF592-Q170
Qotom bare bones
ASUS Q87T mini-ITX
Higher demand routing, AES-NI (IPsec) and OpenVPN

Pro´s area:
Supermicro C2358, 2558 and 2758 Series
Advanced routing, AES-NI, Intel QAT, Multi-Core CPUs

Enterprise area:
Supermicro Intel Xeon D-1513N3, 1523N3, 1533N3,1543N3 and 1553N3
Advanced and enhanced routing, AES-NI, QAT, DPDK and Multi-Core CPUs

Virtual (Multi-Router) VM installations:
Lanner FW-8995 and FW-8996
Many router instances on one device with many ports

Unleashing the full potential and power of Lintechs PowerRouter v3 or the OcmaConnect Routers should be also fine to see what is going on that site.

All can be feet with a regular Linux Kernel and drivers are out mostly or nearly for all devices such as NICs and other things. For sure it might be nice to see a 64Bit
platform from RouterOS, perhaps not at these days but in the near future would be glad to hear about, because there are many things that will be able to realize with
MikroTik´s RouterOS. And with an watching eye to an ARM Fork or support it would be nice to see RouterOS on SolidRun ClearFog Base or Pro boards or on the
TurrisOmnia routers too.

Chupaka · Wed Jul 26, 2017 12:07 pm

Who gives them a promise that only one copy will be used or if someone will be installing one system and copy it over and over and over only with one License code? What is then? Who cares then on their business and an their income or plain on their money? For sure getting hands on a copy will be fine but how many users will then trade over P2P networks this registered copy then?

Well, License fees are very small MikroTik's income part compared to RouterBoards sales

So actually nothing will happen to the business =)

karwos · Wed Jul 26, 2017 5:48 pm

I am running two BGP servers and they are just work perfect in CHR.
what traffic do you have on them?

BGP without full view works perfect on any RB hardware

total ~800k routes
CHR 6.37.5
vmxnet3 driver and PVSCSI driver
Connection tracking ON, few queue trees, 1k simple queues, couple of firewall rules (filter and mangle)

current traffic 850 - 900mbit, usage for each core:
core 1 - 990mhz
core 2 - 1241mhz
core 3 - 1322mhz
core 4 - 727mhz

Total 4280MHz out of between 16800MHz and 17600MHz avaiable (total 25% usage)

Stats for 300-350mbit of traffic:
core 1 - 615mhz
core 2 - 1678mhz
core 3 - 542mhz
core 4 - 386mhzz

Total 3221MHz out of between 16800MHz and 17600MHz avaiable (total 19% usage)

If using carefull delta-estimates, this machine would be able to route total between 5GBit and 6GBit of traffic, in current configuration
Suits for me

If Mikrotik would implement SR-IOV would be also significant less I guess, also add Vmware guest tools would be helpfull.

Kreacher · Wed Jul 26, 2017 11:47 pm

Well, License fees are very small MikroTik's income part compared to RouterBoards sales

And there for I was speaking from a total game Play changer!
- Linux Kernel and drivers are easily to get hands on and from the vendors side they will often be there
- Intel´s QAT Linux driver is ready to use for compression the data packet flow (both end situation)
- IBMs TPM SDK is OpenSource TMP Modules can be used for signing License IDs
- DPDK is there from Intel (netmap-fwd) speeds up to 3x the TCP/IP packet flow
- AES-NI as the integrated VPN Hardware support (IPSec)
- Intel NICs comes with good Linnux driver support
- FreeRadius, OpenLDAP and Tripwire Server integration
(ok license fees must be paid than)

Ok fairly the entire RouterOS must be written new, and this will be a real bunch of work, but what is then of this will be done?
You sell then license fees more then other things I guess, or am I wrong with that meaning? But my only concern was to think
about the entire licenses cheating by installing that in a VM and safe the money for that. Do you mean really that this will be
not a disaster for all the hard work of recoding and testing? Ok for sure this can really be.

guilhermeramires · Sat Aug 05, 2017 4:00 pm

But the one million dollars question is: This workaround to get x86_64 working on version 638.7 makes the system really works on 64 bits or its just a flag and fake data read?
If yes, I need to remember Janisk reply about memory addressing speed loss and consider that it does not worth if you do not need to use more than 2GB.

Chupaka · Mon Aug 07, 2017 12:29 pm

I need to remember Janisk reply about memory addressing speed loss and consider that it does not worth if you do not need to use more than 2GB.

as I can see, Janis was talking about PAE on x86 (32-bit) speed loss, not about 64-bit speed

PortalNET · Fri Nov 03, 2017 2:40 am

Hi boys

i have some doubts regarding the x86-64 architecture...

but first things first, is it just me or there seems to have a bug on all versions of mikrotik x86 that cannot read RAM memory available correctly? or is it just some versions or Memory RAM modules that does not display it correctly?

i installed mine 6.39.3 bugfix with 4GB ram hyperfury ddr3 1333mhz , and on memory only detected 1886mb memory..

then i uploaded the all package 6.31 x86 to folder and hit downgrade on system packages and installed 6.31 version.

went on system resources hardware and enabled multi-cpu and also hit tab x86-64 architecture... and my RAM memory reading on the mikrotik went up from 1886Mb to 3663MB total memory.. ok that seems a more realistic number of the memory insterted so i shutdown the PC, and plugged in another 4GB memory module with total 8GB ram, and rebooted the machine but still only detects 3663MB ram.

upgraded it back up to 6.39.3 bugfix version.. and readings on RAM now still 3663MB prior to the 1886MB intially...

aldo on system resources print i now get x86-64 architecture showing on the CPu..

  uptime: 12m
                  version: 6.39.3 (bugfix)
               build-time: Oct/12/2017 11:24:56
              free-memory: 3615.3MiB
             total-memory: 3663.0MiB
                      cpu: AMD
                cpu-count: 4
            cpu-frequency: 3817MHz
                 cpu-load: 0%
           free-hdd-space: 462.0GiB
          total-hdd-space: 462.1GiB
  write-sect-since-reboot: 2000
         write-sect-total: 2000
        architecture-name: x86_64
               board-name: x86
                 platform: MikroTik

Anyways i did further testings such as bandwith testings i wanted to check the internal cores max speed with all 4cpus available

so first bandwitdh test showed 13.5Gbps on UDP but only one CPU is used topped at 100% all other 3 cpus at 0% workload showing running only on 25% capacity

i did a second test on TCP mode and bandwidth test showed max troughput of 22.4Gbps again 2 cores only used leaving other 2 cores at 0% workload showing on mikrotik 50%

i am wondering if there is any limitation of the cores... because load is not sync , is there a way to distribute load on the 4 cpu cores?

doneware · Sun Feb 18, 2018 8:49 pm

i run x86_64 on an older server, "loaded" with ram. the main idea is to be able to host KVM VMs. it worked quite reasonably with just one VM running.

[bat@cloudtik] /system logging> /sys reso print 
                   uptime: 3d5h38s
                  version: 6.41.1 (stable)
               build-time: Jan/30/2018 10:26:14
              free-memory: 22.0GiB
             total-memory: 23.4GiB
                      cpu: Intel(R)
                cpu-count: 16
            cpu-frequency: 2266MHz
                 cpu-load: 0%
           free-hdd-space: 3663.5MiB
          total-hdd-space: 3766.4MiB
  write-sect-since-reboot: 484656
         write-sect-total: 484656
        architecture-name: x86_64
               board-name: x86
                 platform: MikroTik

now i have some more, but they just get all stopped suddenly, and i don't know why this happens. the VMs have 512MB-1024GB RAM each, and some negligible amount of hard disk image hosted on HDDs. so far i wasn't able to correlate this issue with any event, and i'm curious whether anyone may faced similar issues. The VMs use virtIO networking, each of them has its dedicated virtual ethernet that is routed (e.g. not part of any bridge).

Cal5582 · Wed Feb 28, 2018 5:08 pm

So ive been able to get this working, but i am unable to select wireless frequencies on my mikrotik wireless cards when x64 is enabled but if i revert back to 32 bit it works fine. It acts as if it cannot find the scan lists for my country. any suggestions?

nostradamus · Tue Mar 13, 2018 7:50 am

So ive been able to get this working, but i am unable to select wireless frequencies on my mikrotik wireless cards when x64 is enabled but if i revert back to 32 bit it works fine. It acts as if it cannot find the scan lists for my country. any suggestions?

the same issue with yours, it seems wireless not working under 64bit, my card chipset is QCA9380

Cal5582 · Wed Mar 14, 2018 5:19 pm

I'm using a QCA9880 R11e-5HacT for my 5 Ghz.

DanielJB · Fri Mar 30, 2018 8:05 am

there is a reason why RouterOS on x86 supports only 2GB - the speed of memory addressing. With high/low setups you would lose 5 to 10% of performance.

The cost of PAE is way lower on modern x86 processors, since they have such large TLBs (as are optimised for much larger datasets with 4KB pages), and all the processors are highly-optimised for the larger pointer size used in PAE anyway. I suspect Mikrotik don't enable x86-64 kernel by default as they are using an older kernel with vendor drivers that have some build/integration issues, so PAE may be a good lifeline until RouterOS v7.

So, just enable PAE for now. It's a big win for many cases, not only since the kernel can optimally size many network related hashtables, but also because there is less pressure (therefore page reclaimation) on various pools.

Finally, going CHR means lower uptime, as there is more configuration, performance overhead and patching for security issues due to the VM host. For maximum single-stream throughput on critical infrastructure, I cannot wait to recommend native x86-64 RouterOS.

Cal5582 · Tue May 01, 2018 5:44 pm

looking under the wireless package file it looks like the file structure is the same for 32 bit and 64 bit drivers as far as i can tell and theres even a 64 bit driver file so im confused as to why wireless is disabled for 64 bit router os. i mean i can go back to 32 bit, but with ddr3 being so cheap secondhand theres really no reason not to use 8 gigs of ram. I use this in kind of a homelab setting to test changes before they ever get implemented so i know im not the typical user, it just seems strange to have 90% of the functionality already implemented and hidden behind a simple flag and not use it when even atom boards have been 64 bit for the last 8 years or so.

Cal5582 · Thu Sep 06, 2018 6:20 pm

just wanted to note, that other than wireless this seems to work. currently using 6.42.7 and capsman with a few caps to cover the wireless issue.

samrock · Sun Sep 09, 2018 1:33 am

+1 for official support of this....

Wish I would have noticed this thread sooner.. I just spun up an new x86 on a Dell PE1950, Guess I need to go downgrade it and smash the x64 box!!

jmginer · Mon Sep 24, 2018 12:30 pm

+1 for native implementation to allow +2GB RAM in x86

Takv · Tue Jan 29, 2019 11:44 pm

+1 for native x86_64 implementation

enzain · Wed Jan 30, 2019 10:45 am

Need x64 os and EFI support now ...

rzirzi · Tue Feb 05, 2019 8:03 am

Need x64 os and EFI support now ...

EFI or AHCI disk support at x86 - PLEASE!

nishadul · Mon Feb 11, 2019 12:30 pm

It seems that krzysztof manually changed architecture-name: x86 to architecture-name: x86_64 only in post.
he also 'changed' free- and total-memory

now just look at 'Extra packages' links in Download page. this .zip contains everything including 'system' package (which contains the kernel, I believe )

X86 link:
https://download2.mikrotik.com/routeros ... 6.38.3.zip

CHR link:
https://download2.mikrotik.com/routeros ... 6.38.3.zip

now find the difference

so seems like 'x86_64' is just a flag somewhere in the file system

by the way, I have old good RouterOS virtual machine which was installed when no CHR existed:
Code: Select all
[admin@TestPlace] > system resource print 
                   uptime: 1w1d2h51m41s
                  version: 6.39rc38 (testing)
               build-time: Feb/24/2017 08:46:35
              free-memory: 21.7MiB
             total-memory: 88.4MiB
                      cpu: Intel(R)
                cpu-count: 1
            cpu-frequency: 2933MHz
                 cpu-load: 0%
           free-hdd-space: 58.8MiB
          total-hdd-space: 99.2MiB
  write-sect-since-reboot: 394778
         write-sect-total: 394778
        architecture-name: x86_64
               board-name: x86
                 platform: MikroTik
in some early v6 versions there was a checkbox under 'System -> Resources -> Hardware' for enabling 64-bit mode. looks like they removed it and created the CHR as a separate system

Hello,
ROS X86 6.38.3 is supported 64 bit?

Chupaka · Mon Feb 11, 2019 2:39 pm

Using that 'hack' - yes

Takv · Wed Mar 27, 2019 9:32 pm

Waiting to see Mikrotik staff come and says something ·"official".

Come'on Mikrotik! Bring us the official support! You have nothing to lose!

Steveocee · Wed Mar 27, 2019 11:02 pm

I can’t see them doing it..... they’ve previously been very vocal that you should run CHR if you don’t want to use a routerboard.

Takv · Thu Mar 28, 2019 5:29 pm

Its not "me or many" who wants not to use routerboards, it's the limitations of VM about 10Gbps, 40Gbps fiber modules, not needed usage overhead and the extra costs of HyVs. Why I need to use a VM if I can use a PC by my own to do the job? Why to depend in other OS to have the intended OS running? Undesired OS updates ruins the uptime, and also aggregates the extra security measures to avoid supporting OS become vulnerable to attacks.

We use routerboards, we love it, but in the Core we need the upgradeability and brute force from PC's.

marlow · Fri Apr 05, 2019 11:59 pm

Its not "me or many" who wants not to use routerboards,

Unfortunately the customer is not always King. At least in this scenario.

Either way ... thank you for those above, who have pointed out, how to get around this issue.

uptime: 57s
version: 6.43.14 (long-term)
build-time: Apr/02/2019 09:12:23
free-memory: 31.3GiB
total-memory: 31.4GiB
cpu: Intel(R)
cpu-count: 8
cpu-frequency: 2992MHz
cpu-load: 0%
free-hdd-space: 461.5GiB
total-hdd-space: 461.6GiB
write-sect-since-reboot: 3600
write-sect-total: 3600
architecture-name: x86_64
board-name: x86
platform: MikroTik

And those 3 GHz come by 8 physical cores

... in the form of 2 x quad core Xeon CPUs.

# CPU LOAD IRQ DISK
0 cpu0 0% 0% 0%
1 cpu1 0% 0% 0%
2 cpu2 0% 0% 0%
3 cpu3 0% 0% 0%
4 cpu4 0% 0% 0%
5 cpu5 0% 0% 0%
6 cpu6 0% 0% 0%
7 cpu7 0% 0% 0%

and that with 4x 10gig interfaces with SFP+ cage and 2x GigE on a box with hardware raid1 on 2 SSDs and a nice and tidy level6 license.

/M

rzirzi · Fri Apr 12, 2019 7:31 am

+1 for X86_64

GuJack20 · Sun Jul 19, 2020 8:06 pm

Hello guys

thanks for this informative and very useful thread.

Can you point out some models of NICs with 2+ SFP+ cages that you know that are recognized by and work great with 64bit?
Also some 40gbit SFP just for testing, but the 10gbit ones are enough for production in our everyday work.

Regards

jmginer · Sun Jul 19, 2020 8:10 pm

Hello guys

thanks for this informative and very useful thread.

Can you point out some models of NICs with 2+ SFP+ cages that you know that are recognized by and work great with 64bit?
Also some 40gbit SFP just for testing, but the 10gbit ones are enough for production in our everyday work.

Regards

We use FSCOM nics and transceivers working perfect with Proxmox v6

GuJack20 · Sun Jul 19, 2020 10:36 pm

Hello guys

thanks for this informative and very useful thread.

Can you point out some models of NICs with 2+ SFP+ cages that you know that are recognized by and work great with 64bit?
Also some 40gbit SFP just for testing, but the 10gbit ones are enough for production in our everyday work.

Regards
We use FSCOM nics and transceivers working perfect with Proxmox v6

Thanks for the reply. But I was thinking about bare metal.

rextended · Sat Jun 05, 2021 5:36 pm

search tag # install routeros x86_64 ENABLE_X86_64

For enable 64 bit on RouterOS x86 installation
(obviously installed on 64 bit hardware with more than 4GB of ram)

"simply"

remove hard disk and connect it on another linux PC
OR
use a bootable USB with linux (ubuntu setup for example) for access on ext3 internal storage

and on folder /system/rw

"simply" create empty file named

ENABLE_X86_64

warning: all uppercase, with _ and NO SPACES (with right -rw-r--r--)

put back the hard disk,

start RouterOS (x86_64 still not active),

put this on terminal (for "touch" and update the hardware preferencies on boot ramdisk):

/system hardware set multi-cpu=no
:delay 2s
/system hardware set multi-cpu=yes

you see two times the message on terminal:

ros code

echo: system,info,critical New hardware settings will take effect after the reboot
echo: system,info,critical New hardware settings will take effect after the reboot

reboot RouterOS,

now x86_64 is active.

:)

Emro Batmok Ot Meok

jspool · Sun Jun 06, 2021 7:42 pm

Personally I think that real performance will be reached when Mikrotik adopts VPP and DPDK. I use Mikrotik CHR and CCR for core routing and use TNSR for edge routing as the VPP and DPDK are impressive to say the least. The BGP performance is crazy good and it ends up being able to do about 10Gbps per core. Obviously this depends on the hardware but I have a Dell R440 with a E-2288G and two Mellanox 10G cards (soon to be 40G) and its set and forget. You can use it on bare metal or virtualized. I had a mild DDOS of 5Gbps and the TNSR was routing away and the CHRs and CCRs were tapping out. Now I will say the learning curve from Mikrotik to TNSR is quite a challenge but worth it if you are into the performance. If Mikrotik chooses to go down the VPP and DPDK then that will be a game changer.

Caribetech · Tue Jun 08, 2021 1:48 pm

Before update

Later update 6.31 to 6.47

Server Dell Tower 7910
2 CPU Xeon

rextended · Tue Jun 08, 2021 3:16 pm

6.45 to 6.47?
Or 6.45 to 6.31 to 6.47?
Or you create the file as I have described?

sbhokray · Tue Mar 01, 2022 6:27 pm

my doubt, after enabling the X86_X64 checkbox will it just show the architecture name as X86_X64 for namesake, or, it becomes truly a X64 based system.

Chupaka · Tue Mar 01, 2022 7:42 pm

At least, more RAM is available after the "conversion"

sbhokray · Tue Mar 01, 2022 11:47 pm

At least, more RAM is available after the "conversion"

agreed, but have you seen ram utilizations above 2gb from the total ram shown after the conversion?
am on the CHR installed on del power edge r710 on top of hiper-v. so far so good. touching around 535Mbps at the cost of 35% CPU. I configured 8 cores to the Mikrotik. is this kind of CPU load ok for such configuration?
am not looking at the X86 setup cause I know this will come to end soon by Mikrotik.

Wed Mar 02, 2022 12:12 am

Question:

I pretty much only use CHRs for my core routers and bandwidth shaper and BGP and NAT444 ( 60-thousand lines of NAT configuration for ports per live IP address for my CGN networks ).

Is an x86 with X86_X64 enabled any faster or slower than a CHR doing the same thing ?

sbhokray · Wed Mar 02, 2022 12:48 am

Question:

I pretty much only use CHRs for my core routers and bandwidth shaper and BGP and NAT444 ( 60-thousand lines of NAT configuration for ports per live IP address for my CGN networks ).

Is an x86 with X86_X64 enabled any faster or slower than a CHR doing the same thing ?

your post caught my attention. I am trying to implement nat444[CGNAT]. followed the guide on Mikrotik.
the problem is, few of my clients had no Internet and the things were good for other clients.
as that was an production server, I haad no time to take the coomfigaration print to share.
I will be greatly thankful if you can guide me on this.

Wed Mar 02, 2022 3:22 am

Question:

I pretty much only use CHRs for my core routers and bandwidth shaper and BGP and NAT444 ( 60-thousand lines of NAT configuration for ports per live IP address for my CGN networks ).

Is an x86 with X86_X64 enabled any faster or slower than a CHR doing the same thing ?
your post caught my attention. I am trying to implement nat444[CGNAT]. followed the guide on Mikrotik.
the problem is, few of my clients had no Internet and the things were good for other clients.
as that was an production server, I haad no time to take the coomfigaration print to share.
I will be greatly thankful if you can guide me on this.

Re: ... I will be greatly thankful if you can guide me on this. ...

Some questions related to your wanted build of a Mikrotik NAT444 configuration.
- What Mikrotik ( physical hardware or virtual CHR ) are you using ?
- How many CGN networks are you wanting to have a NAT444 configuration work with
- What size is your CGN network(s) - aka /21 or ./22 or /23 or /24 ( note - My network has twelve /21 ( 100.64.x.y/21 ) CGN network and each /21 in my use used eight live IP addresses.
- How many live un-used Internet IPs do you have available for your NAT444 ?

Based on your answers , and some additional questions later asking what actual IPs you have , I might be able to message or email you a paste and go NAT444 configuration that is pre-configured for your use.

North Idaho Tom Jones

sbhokray · Sun Mar 06, 2022 9:55 pm

your post caught my attention. I am trying to implement nat444[CGNAT]. followed the guide on Mikrotik.
the problem is, few of my clients had no Internet and the things were good for other clients.
as that was an production server, I haad no time to take the coomfigaration print to share.
I will be greatly thankful if you can guide me on this.
Re: ... I will be greatly thankful if you can guide me on this. ...

Some questions related to your wanted build of a Mikrotik NAT444 configuration.
- What Mikrotik ( physical hardware or virtual CHR ) are you using ?
- How many CGN networks are you wanting to have a NAT444 configuration work with
- What size is your CGN network(s) - aka /21 or ./22 or /23 or /24 ( note - My network has twelve /21 ( 100.64.x.y/21 ) CGN network and each /21 in my use used eight live IP addresses.
- How many live un-used Internet IPs do you have available for your NAT444 ?

Based on your answers , and some additional questions later asking what actual IPs you have , I might be able to message or email you a paste and go NAT444 configuration that is pre-configured for your use.

North Idaho Tom Jones

first, thank you so much for the help.
1. its an CHR7.1.3 on hiper-v.
2. I have total 3 CGN networks.
3. all are /24 networks[100.122.0.0/24, 100.123.0.0/24, 100.126.0.0/24]
4. for now, I have only 1 gateway IP address to use.

ros code

Who is online