Thanks,
RB5009 ok and can finally see temp.

{
:put [/system/routerboard/get model]
:foreach id in=[/system health find] do={
	:local health "$[/system health get $id]"
	:put "$health"
}
}

Thanks,
RB5009 ok and can finally see temp.

Can you post the output of this command, Just to see what info a RB50090 gives out:

Code: Select all

{
:put [/system/routerboard/get model]
:foreach id in=[/system health find] do={
	:local health "$[/system health get $id]"
	:put "$health"
}
}

That's cool and all but ROS7 is a non-starter for me without BFD support. Will we ever see BFD implemented is ROS7?

The Wireguard IPv6 peer bug is also still present on this version.

*) lte - added basic information support for Telit LM960 and LM940 in MBIM mode;

Re: RouterOS version 7.2rc1
Can somebody shed some light on the following new features ?
*) winbox - added support for "Tool/Speedtest" menu;

Re: RouterOS version 7.2rc1
Can somebody shed some light on the following new features ?
*) winbox - added support for "Tool/Speedtest" menu;

The /tool/speed-test now has a UI in winbox in the "Tools" menu:

The Wireguard IPv6 peer bug is also still present on this version.

RB5009
When I make a SpeedTest on TCP protocol, I get around 950-980Mbit..But when I make UDP I get only 15-3Mbit..Is it my fault?

Unfortunately the issue with RB5009 DHCPv6-PD over pppoe on tagged ethernet link is not fixed

*) ipsec - added hardware acceleration support for CCR2116;

*) bgp - do not export default BGP values;

After upgrade from 7.1 a statically configured /ip ipsec identity was gone and the corresponding IPsec tunnel was down until I re-added it.

Edit: it turns out that the same happens when 7.1 is rebooted, I seldomly reboot so did not notice that.

Amm0:
Thanks for reply and made a test.
I am new MK user, so sometimes I don't know, if I made a mistake, or it's a bug..

Unfortunately the issue with RB5009 DHCPv6-PD over pppoe on tagged ethernet link is not fixed

*) l3hw - fixed HW offloaded routing when using 7 or more VLAN interfaces;

*) l3hw - fixed bonding source MAC address;

*) l3hw - improved system stability when using 7 or more VLAN interfaces;

*) ospf - fixed distance if "originate-default" is set to "always";

*) ospf - fixed neighbor stuck in ExStart;

*) ospf - improved logging;

*) ospf - improved overall stability;

*) ospf - improved stability for very large LSDB;

*) ospf - improved stability when DR goes down;

*) ospf - improves stability when handling looped back OSPF packets;

*) route-filters - fixed possible address list race condition and memory leak;

*) upgrade - improved 404 error handling when checking for new versions;

- "Old style" routing filters add (like v6), not only syntax - VERY IMPORTANT!!!

7.2rc1 killed L2 connection on all my SFP+ fiber modules on a CRS317 to servers and switches. DAC cable works though. Downgrade to 7.1.1 resolved it.

This version broke communication between a crs318 and a crs317 with a SFP+ 10Gbase-T adapters (same adapter type on both ends). It works fine with 7.1 and 7.1.1.

- "Old style" routing filters add (like v6), not only syntax - VERY IMPORTANT!!!

Why is this "very important"? I really can't see them doing this. The new syntax borrows some of the best bits from Cisco IOS-XR syntax with their if-then-else statements and Juniper-style JSON-like braces.

And at the same time, loses the best bits from ROS and Winbox style syntax/UI.

*) ovpn - added SHA2 authentication algorithm support;

Where should find this checkBox?

Good to see lots of bugs fixed. This needs to be the priority, not new features.
Functional parity with v6 should be the objective now (Sorry to anyone who is waiting for Docker to come back)

Just bumping the following
EAP-TLS: viewtopic.php?t=180713
IPv6:viewtopic.php?t=181350

The more I dig through the routing filter features in v7, I keep finding more and more ways to reduce the number of filter rules by a great deal compared to v6.

Over time they can probably make better GUI helpers for constructing such rules, so that you don't have to type out a lot of different filter rules from the CLI.

I still have a problem with SFP+ port negotiation on RB5009UG+S+IN with AOC-STGN-I2S(X520-DA2).

openvpn notworking in v7.2rc1

For the convenience of winbox management, our colleagues also ask to add it

I still have a problem with SFP+ port negotiation on RB5009UG+S+IN with AOC-STGN-I2S(X520-DA2).

Need more information, please open a support ticket and send a supout.rif file. Also specify what kind of SFP modules are you using.

openvpn notworking in v7.2rc1

Need more information, please open a support ticket and send a supout.rif file.

And at the same time, loses the best bits from ROS and Winbox style syntax/UI.

It is probably way more efficient in terms of CPU cycles to be able to use if - then - else syntax. Any OR or ELSE conditions before would have required more rules, and therefore more loops for handling each route, and that ends up meaning higher CPU usage when loading routes from peers, slower convergence, and all of the things we want to avoid.

Huawei apparently has a similar if-then-else structure: https://support.huawei.com/enterprise/e ... ute-filter
And the BIRD routing daemon also has an if-then-else syntax for filters, although it is closer to traditional programming there.

The more I dig through the routing filter features in v7, I keep finding more and more ways to reduce the number of filter rules by a great deal compared to v6.

Over time they can probably make better GUI helpers for constructing such rules, so that you don't have to type out a lot of different filter rules from the CLI.

I understand that the explanation given for ditching the very-much intuitive and usable v6 filters for the new non-user friendly syntax is performance gains, but they could have abstracted that away from the end user and kept the same UI that many of us know and love.
It's not like they haven't done it before specifically for BGP when they used Quagga under the hood.
MikroTik has managed to abstract pretty much all Linux functionality with their superior UI and CLI, and they can't find a solution to this?

It works for me without any issues from RouterOS, Linux and Windows clients.

I understand that the explanation given for ditching the very-much intuitive and usable v6 filters for the new non-user friendly syntax is performance gains, but they could have abstracted that away from the end user and kept the same UI that many of us know and love.
It's not like they haven't done it before specifically for BGP when they used Quagga under the hood.
MikroTik has managed to abstract pretty much all Linux functionality with their superior UI and CLI, and they can't find a solution to this?

When looking at the entire BGP configuration, it seems to me there was a new developer assigned to this task who has a different opinion on how these things should look. [...]

I think Mikrotik's holiday video has a clue: "Do you want to discuss BGP?" ... "No".

I think Mikrotik's holiday video has a clue: "Do you want to discuss BGP?" ... "No".

Maybe Viktors is the BGP developer? Eva certainly isn't, she works in the logistics department and is not interested in BGP...

This version broke communication between a crs318 and a crs317 with a SFP+ 10Gbase-T adapters (same adapter type on both ends). It works fine with 7.1 and 7.1.1.

Ditto, killed all my Fiber Mall SFP-10G-T-CI-80m units. Works on 7.1.1.

I still have a problem with SFP+ port negotiation on RB5009UG+S+IN with AOC-STGN-I2S(X520-DA2).

Need more information, please open a support ticket and send a supout.rif file. Also specify what kind of SFP modules are you using.

openvpn notworking in v7.2rc1

Need more information, please open a support ticket and send a supout.rif file.

Give us the ability to write the rules the same way as before and compile them into the new format under the hood in order to achieve the better performance the new syntax provides.

As it stands now, the usability aspect of it all, to me, defeats any performance benefits.

In all my routers and routers I know, there is a 1:1 correspondence between v6 and v7 rules (exactly the same number of rules required).

Of course this has been made much more complicated by using this new syntax. Remember there also is no GUI helper for constructing scripts.

For the convenience of winbox management, our colleagues also ask to add it

Everything that made BGP on ROS great, is gone.

It does not seem impossible to keep the old method (with all the different fields that are implicitly ANDed together) in addition to this new "rule=" method, and then have the code internally create a rule from the traditional matching fields and use that.
(it would likely be a bit more difficult to handle this completely inside winbox, i.e. derive the traditional user interface from the rule that is currently in place)

Everything that made BGP on ROS great, is gone.

Most people hated BGP on RouterOS v6 when it came to performance handling full tables, forcing them to move to other platforms. I wouldn't say that BGP on RouterOS was ever seen as "great".

For smaller or internal networks that didn't use full tables, it was great. It did the job despite its stupid bugs.

That's why I said 'compile' them into the new format under the hood.

That is, the code be smart enough to take all 'traditional' rules and simplify them into whatever format and number of them it needs to be as performant as possible. Not being able to even see the new rule syntax.
Like what a good compiler does when you have stupid code and it translates it as efficiently as possible to machine code.
You don't see if your dead code is included or not in your compiled binary. A good/smart compiler will ditch that automatically.

ie: ditch the new rule syntax.

Oh my god, are you getting paid by MikroTik?

In all my routers and routers I know, there is a 1:1 correspondence between v6 and v7 rules (exactly the same number of rules required).

One big change is the ability to use address-lists now in BGP filter rules. So for bogon filtering, instead of having a rule for each bogon prefix you wish to filter (of which there will be around 20-25), you can use a bogon-prefixes address list with a single filter rule. So, you eliminate at least 19 filter rules this way if you do bogon filtering in BGP. This is just one example of where the new format is improved over the old one. After getting used to the new format and the new features it has, I'm sure we will find many other new ways of reducing the rule count.

There was one really serious bug in v6 route filtering that bit us multiple times. The order of the rules shown in the GUI was not true. You had to do an /export from the command line to make sure that the rule order was the same as seen in the GUI. Otherwise you could think that what you set up was just fine and meanwhile it was in a completely different order than you thought it was. The GUI completely lied to us on multiple occasions about the order of rules and caused major issues.

Really??? I have NEVER seen that in all my use of RouterOS over the years! Are you sure you did not inadvertently click on a table header to sort the rules e.g. by Chain name? THEN it indeed is wrong, and until now (it was fixed in 7.1.1 and 7.2rc1) this thing was happening in v7 because the # column was not there.

The only scenario where I could imagine that kind of things happening is when two different persons (or two winbox sessions operated by the same person) each are making additions to the routing filters.

Does this mean that PPPoE "auto" MTU is no longer tied to the underlying ethernet interface MTU -20 Bytes of MikroTik "headers"?

ATA is unable to register with my VoIP provider, I get "Register Failed: No Response From Server" error on my ATA. Packet capture indicates packets being sent but nothing coming back.

Note this is on an x86 machine. Works on Router OS 6.49.2, doesn't work on any of the 7.x.x series routeros versions including 7.2rc1. I followed the configuration guide here to setup the router https://help.mikrotik.com/docs/display/ ... figuration

I've gone as far as completely disabling the firewall to see if that would work and it changes nothing, sip helper has also been disabled.

I'll admit I'm very new to routeros, I'm either missing something in my config or there's something up with the 7.x.x versions as 6.49.2 allows the ATA to register.

• Unlikely, but possible, the ATA is using IPv6. If so, that's enabled by default, so the IPv6 firewall would come into play. But you'd see those in the packet traces.
• Since your on X86, obviously all the network drivers etc have changed – while these shouldn't matter, the once in a while do in these kinds of problems. Do you have a hardware Mikrotik you can try your configuration with V7 on with say one ATA?

OSPF 100% broken after update.

Not seeing neighbors anymore.

OSPF 100% broken after update.

Not seeing neighbors anymore.

Check if you use authentication ..
In my case this was the problem, neighbor is ros6
I just remove it .. for me this was not requirements (legacy config) so i did not do future tests

But that is not a property of the new format! It is a capability of the new filter implementation!
Adding address lists would have been possible in the old format as well. Look at the firewall rules, there you have support for address lists without having to write an iptables rule yourself.
Now I certainly recognize the problem that in these statements it is inconvenient that there always is a separate column for literal addresses and address lists, for explicitly named interfaces and interface lists, etc.

But that is not a property of the new format! It is a capability of the new filter implementation!

Somewhat. However we are able to do things like "if dst-address is in bogons-list OR dst-address is in rfc1918-list then reject", which saves another rule.

I would also say that most simple MikroTik users are not using BGP. Even at the WISP level, many smaller WISPs simply NAT everything

*) poe - update PoE firmware only on devices that support it;

Oh my god, are you getting paid by MikroTik?

No, I'm not, but I don't have to make routing filter changes that often. And my friend who does have to work with BGP routing filters all the time is super excited by the new MikroTik format and loves it compared to the RouterOS v6 format. So in one ear I am hearing existing MikroTik users complaining about the new format, and in the other ear hearing "finally! it is about time that MikroTik did this! Their old format was terrible, this is so much better"

view [
   backdrop silver
   text right "Text to greet:"
   wish: field 100x20 return
   button "Greet" [
       print ["Wishing you a" wish/text]
   ]
]

What I actually think is, that you don't understand the issue at hand people here are trying to point out.

So - the last thing you need is some nerd in your team, who thinks that the more syntax looks like the BrainF*ck language mixed with some crazy Regexp rules, the better. There should be imo more thoughts put into all of this, abstractions created and compiled down to whatever the underlying engine needs.

Updated my hap ac2 both routeros and routerboard firmware.
Any news on wifiwave2 drivers for the ac2 as of yet?

No, I suppose I don't understand the issue. To me these look just like if/then conditions from Javascript or PHP programming, for simple rules at least. If (conditions are met) { do (x) }. I don't find them that complicated. Certainly more complicated than before, but not that complicated. It is like reading Javascript or PHP code and I am quite comfortable with that.

Updated my hap ac2 both routeros and routerboard firmware.
Any news on wifiwave2 drivers for the ac2 as of yet?

Unfortunately, it may not happen. Please see the requirements at https://help.mikrotik.com/docs/display/ ... quirements .

The issue is not the "if (conditions) { action }" syntax, but the fact you need to learn (or lookup) keywords to use in the conditions and action all the time.
In v6 there is autocompletion or gui dropdown lists. When you want to filter on some network or some community value, you just read along the different matching conditions in the GUI or you press TAB in the CLI, you see them and you select the correct one.
In v7 you need to know or find out that you need to write "dst == 1.2.3.0/24" or "dst in 10.0.0.0/8 && dst-len in 8-32" or "bgp-communities includes 1:2" or "bgp-as-path 1234$" for example. And note the syntax and operators are different for all cases.
That introduces a learning curve that mostly wasn't there in v6.

Tested on CHR
This script crashes the router.

Code: Select all

:for e from 1 to 300 do={
/ip firewall mangl add action=mark-packet chain=postrouting  new-packet-mark=$e
}
/queue tree add parent=global packet-mark=test

Did that work on v6?

This not crash an X86 (running on a VmWare Workstation), it takes it down completely and router will not come back up again.
So DO NOT RUN this on a production router.

also 33 adresses in firewall - addresses list crash router

also 33 adresses in firewall - addresses list crash router

I have 1631 items in my firewall address list (32 definition items, some of them being DNS names expanding to many addresses).

I have 1631 items in my firewall address list (32 definition items, some of them being DNS names expanding to many addresses).

confirmed on arm and x86. i can make a video

There likely is a maximum number of packet marks, and it could be like 256 or so. Maybe the software forgets to check that limit when adding a new one. I never stresstested that.

In Linux, packet mark is a 32-bit value but it is possible to AND it with a MASK before comparing it with a value.

But what I can see is @pe1chl is right on - limit is 256. But no crash, ROS flags it as a "bad packet mark"

/queue tree add parent=global packet-mark=test

But what I can see is @pe1chl is right on - limit is 256. But no crash, ROS flags it as a "bad packet mark"

After creating so many new packet marks, this is the part which crashes the router:

Code: Select all

/queue tree add parent=global packet-mark=test

[when you hit the 256 limit] ROS flags newly added ones as invalid. [Even] if you get below the 256 limit, you need to update/re-add them – once bad, they stay bad in my limited test.

What I don't know is if >256 packet-marks limit is expected or not for V7. When you say this "worked in V6", did you mean "it didn't crash" - e.g. under V6 did you run it using >256 packet-marks and had queues running traffic through them?

Needing 256 unique packet marks in total seems a bit excessive - why do you really need so many? There may be a way to reduce this.

Needing 256 unique packet marks in total seems a bit excessive - why do you really need so many? There may be a way to reduce this.

May be there is a better way but i'm using it for shaping each user traffic separately based on their monthly usage. Also for traffic shaping based on 'Connection bytes' for every connection.

After adding 33th address, cpu load and memory leak starts, when memory runs out, the router crashes

https://youtu.be/Yi5_QShkT0Y

Hi,

High CPU on mAPLite:

Only IKEv2 + Cake.

V7rc2: 100%
V7.1.1: 8%

Regards,

Quick overview 7.2rc1: (ac2, comparison on the same hw with v6!)
1. Drastic speed drop (200m optics drop to 120m), cpu does not show load
2. Instability (every now and then (say every 10 minutes) the connection drops by a few seconds)
3.Netflow does not work

The same symptoms are on 7.1.1. version.

Got sudden static routes table crash on 7.2rc1: not displayed both remotely and from local console, telnet command /ip/route/print just hangs, effectively some routes do work, others don't. Router reboot did help.

1.routing table need to go back as in ros6....having problem with load balancing PCC & Failover
2.speed test 150mbps become 75mbps in 7.1.1 & 7.2rc1
3.pppoe clients not working low speed & peer not responding
4.A lot more bugs in the software it have a rebooting problem
Conclusion i have to send all my mikrotik back to 6.48.6 long term...ros7 is not ready a lot more work needed on it.

1.routing table need to go back as in ros6....having problem with load balancing PCC & Failover
2.speed test 150mbps become 75mbps in 7.1.1 & 7.2rc1
3.pppoe clients not working low speed & peer not responding
4.A lot more bugs in the software it have a rebooting problem
Conclusion i have to send all my mikrotik back to 6.48.6 long term...ros7 is not ready a lot more work needed on it.

OpenVPN udp mode is unusable, connects (from another mikrotik 7.1.1, 7.2rc1, or ovpn client) and after a while it gives the error of the screenshot


Captura.JPG

1.routing table need to go back as in ros6....having problem with load balancing PCC & Failover
2.speed test 150mbps become 75mbps in 7.1.1 & 7.2rc1
3.pppoe clients not working low speed & peer not responding
4.A lot more bugs in the software it have a rebooting problem
Conclusion i have to send all my mikrotik back to 6.48.6 long term...ros7 is not ready a lot more work needed on it.

1. PCC and failover should both be working fine, but there are some changes in RouterOS v7 with the way policy routing works and the way recursive routing works that may require you to change things.
2. RouterOS v7 has no more route caching, in routerOS v6 this artificially boosted speedtest results and bulk downloads. This will not be coming back, so this change will be permanent. If your issue is to do with route caching you may have to make other config changes to try to regain this speed.
3. PPPoE clients are working for other people, although there are issues on certain devices when the PPPoE client is on a VLAN
4. You haven't even indicated what device you have

OpenVPN udp mode is unusable, connects (from another mikrotik 7.1.1, 7.2rc1, or ovpn client) and after a while it gives the error of the screenshot


Captura.JPG

I saw the exact same behaviour with 7.1 and some of the earlier betas.. reverted back to TCP OpenVPN for stability.

whole bunch of 'zzz_gw recvd P_DATA packet, dropping' log entries and no traffic passing over the session, killing the session and letting it reconnect would fix it until it randomly occurred again.

Try enabling the "disconnect-notify" parameter for the OVPN interface. It is possible that the tunnel is down, but traffic is still sent over the tunnel.

Anyone else with Tilera CPU (Cloud Core Router) experiencing higher CPU and Memory usage on 7.2rc1? I already generated a supout and bug report.

@bruins0437, YES after upgrading my CCR1009 to 7.2.rc1 my CPU went nuts ..... I do have many address lists that in total number over 49 thousand entries ... @Grant believes that address lists are the issue .... perhaps .... but under version 7.1.1 my CPU is normal very seldom above 1% in any core ....

These addresses can be temporarily disabled

socks5 now ok in 7.2rc1 is, but 7.1.1 still problem

socks5 now ok in 7.2rc1 is, but 7.1.1 still problem

Why do you ask about this here? What is fixed is clear that its fixed for 7.2rc1. Not anything is mention about this in 7.1.1 thread.

These addresses can be temporarily disabled

These addresses can be temporarily disabled

I don't like the fact that I have to disable those for the memory leak to not occur, but I disabled the scheduler tasks, cleared out the dynamic addresses, and upgraded back to 7.2.rc1. After reboot CPU and memory were stable. So yes, my issue was also linked to the memory leak bug with the address lists.

SFPs won't work on a CRS317 with 7.2rc1, flapping all the time and no connection.
Using Cisco 10G-SR on both ends.

Works fine on 7.1.1

ATA can register in v6.49.2 without any problems. With V7 everything else on my network works as expected. My setup is a PPPoE internet connection for home use, I followed Mikrotik's first time configuration guide (https://help.mikrotik.com/docs/display/ ... figuration) doing a clean install for each version I tried out.

SFPs won't work on a CRS317 with 7.2rc1, flapping all the time and no connection.
Using Cisco 10G-SR on both ends.

Works fine on 7.1.1

Also noticed that with mellanox, finsair and blade 10GB sfp+.
I'm rebuilding my home network with a RB5009 at the "core".
Funny enough, I had to downgrade back to 7.1.1 only the CRS305 and the CRS 326 24G SFP+.
The Optics work with RB5009 and 7.2rc1
for what it's worth

I saw the exact same behaviour with 7.1 and some of the earlier betas.. reverted back to TCP OpenVPN for stability.

whole bunch of 'zzz_gw recvd P_DATA packet, dropping' log entries and no traffic passing over the session, killing the session and letting it reconnect would fix it until it randomly occurred again.

Try enabling the "disconnect-notify" parameter for the OVPN interface. It is possible that the tunnel is down, but traffic is still sent over the tunnel.

I've been having an up/down loop with an RBM33G/RBM11G and LM960A18. The modem is running on MBIM mode and has exhibited this behavior with every release we've tried (7.1RC6 and up).

Current firmware is 32.00.008, and Verizon 32.00.128, but it's also behaved this way with past versions.

:put ([/interface/lte/monitor [find running] once as-value]->"session-uptime")
04:41:21

[user@MT] > /port/print 
Columns: NAME, CHANNELS, BAUD-RATE
#  NAME  CHANNELS  BAUD-RATE
0  usb3        10       9600

[user@MT] > /system/resource/usb print detail 
Flags: I - inactive 
 0   device="2-1" vendor="Telit Wireless Solutions" name="LM960A18" serial-number="6c85ca51" vendor-id="0x1bc7" device-id="0x1041" 
     speed="5000" usb-version=" 3.10" 

 1   device="1-0" vendor="Linux 5.6.3 xhci-hcd" name="xHCI Host Controller" serial-number="xhci-hcd.0.auto" vendor-id="0x1d6b" 
     device-id="0x0002" speed="480" ports=1 usb-version=" 2.00" 

 2   device="2-0" vendor="Linux 5.6.3 xhci-hcd" name="xHCI Host Controller" serial-number="xhci-hcd.0.auto" vendor-id="0x1d6b" 
     device-id="0x0003" speed="5000" ports=1 usb-version=" 3.00"
 

[user@MT] > /interface/lte/at-chat [find running] input="AT#FIRMWARE"
  output: HOST FIRMWARE  : 32.00.005_1
          MODEM FIRMWARE : 4
          INDEX  STATUS     CARRIER  VERSION         TMCFG  CNV       LOC
          1                 Generic  32.00.115       1025   empty     1
          2      Activated  Verizon  32.00.124       2020   empty     2
          3                 ATT      32.00.144       4021   empty     3
          4                 TMUS     32.00.153       5004   empty     4
          OK

Verizon aggressively shuts down a connection for Invalid outbound packets. Now that I've disabled those, everything is rock solid.

Is anyone having issues with IPv6 connection tracking?

I set up some basic filters:

Code: Select all

/ipv6 firewall filter
add action=jump chain=forward in-interface=pppoe-out1 jump-target=INT1-in
add action=accept chain=INT1-in connection-state=established,related,untracked
add action=drop chain=INT1-in connection-state=invalid

I check the connection table... it's only tracking input connections it seems:

Code: Select all

/ipv6/firewall/connection/print 
Flags: S - SEEN REPLY; A - ASSURED
Columns: PROTOCOL, SRC-ADDRESS, DST-ADDRESS, TCP-STATE, TIMEOUT
#    PROTOCOL  SRC-ADDRESS                DST-ADDRESS                TCP-STATE    TIMEOUT  
0 SA tcp       fe80::b0fd:9ea6:2b78:91b4  fe80::de2c:6eff:fe28:e3c1  established  23h59m59s

This is after trying some IPv6 ping tests, some web browser tests... nothing seems to get added to the table. As a result, all traffic hits the drop rule (see config).

This problem is present on 7.1.1 and 7.2rc1.

Is anyone having issues with IPv6 connection tracking?

I set up some basic filters:

Code: Select all

/ipv6 firewall filter
add action=jump chain=forward in-interface=pppoe-out1 jump-target=INT1-in
add action=accept chain=INT1-in connection-state=established,related,untracked
add action=drop chain=INT1-in connection-state=invalid

I check the connection table... it's only tracking input connections it seems:

Code: Select all

/ipv6/firewall/connection/print 
Flags: S - SEEN REPLY; A - ASSURED
Columns: PROTOCOL, SRC-ADDRESS, DST-ADDRESS, TCP-STATE, TIMEOUT
#    PROTOCOL  SRC-ADDRESS                DST-ADDRESS                TCP-STATE    TIMEOUT  
0 SA tcp       fe80::b0fd:9ea6:2b78:91b4  fe80::de2c:6eff:fe28:e3c1  established  23h59m59s

This is after trying some IPv6 ping tests, some web browser tests... nothing seems to get added to the table. As a result, all traffic hits the drop rule (see config).

This problem is present on 7.1.1 and 7.2rc1.

Do you use queues? Queues break the IPv6 connection tracking in probably all v7.1 releases and cause the traffic to be marked as invalid.

I don't have these issues in my RB4011. Above it was mentioned it can be triggered by having many address-list entries.

Not saying you have to see it but ...
I saw that CPU issue on Hex (with approx 50 entries total in 2 address-lists, that's hardly classified as many) and on a stupid mAP Lite (ZERO entries).
Went back to lower version and problem went away. Instantly.
So the only differentiating factor was ROS version.

I receive roughly 950-980Mbit when I do a SpeedTest on TCP protocol. However, when I use UDP, I only get 15-3 Mbit. Is it because of me?

Any idea on what the status of being able to specify direction on a cake queue is?