v7.1beta6 [development] is released!

[mrz]

try [find type=“A”]

[rextended]

On CACHE type can be:
A AAAA CNAME MX NS SRV TXT
:put [:len [/ip dns cache find where type=A]]
:put [:len [/ip dns cache find where type=AA]]
:put [:len [/ip dns cache find where type=AAA]]
:put [:len [/ip dns cache find where type=AAAA]]
type AAA and AA does not exist, right?
but are accepted…


On STATIC all type are set and searchable except for “A” (with or without quotes are useless)
unsearchables value are: A
valid searchable values are: AAAA CNAME FWD MX NS NXDOMAIN SRV TXT


the only way to find type A is exclude everything else:
:put [/ip dns static find where type!=AAAA and type!=CNAME and type!=FWD and type!=MX and type!=NS and type!=NXDOMAIN and type!=SRV and type!=TXT]
or exclude any item with type set:
:put [/ip dns static find where !type]

[anthonws]

Is there any known issue with Traffic Flow in beta6? It looks like I can’t get any netflow info into logstash (and I have checked everything in terms of config, FW, etc.)

If no one has an idea, I will open a support case to check if it really is an issue in MT or not.

Cheers,
anthonws.

Replying to myself for broader awareness and ask for hints

After adding another target to Traffic Flow (v9), I could confirm that indeed the issue is that date is showing up as 1970… Hence why I was seeing no data in Kibana… I just had to look into the Index Mapping to see why…
I confirmed with nfcapd and nfdump that date is showing up as 1970-01-01.

Can anyone confirm is they see the same with beta6?

Thanks,
anthonws.

[Amm0]

How does that actually work? I presume you rely on the ECMP only for the first packet of each connection to be routed to a random external connection, and then the connection tracking (NAT table) will force all the other traffic out of the chosen interface?
Otherwise it would only be useful for UDP traffic where a single UDP exchange constitutes the entire connection (DNS, NTP etc).

AFAIK ECMP depends on connection tracking (and NAT too here). While not privy to the internals, I assume ECMP the same as unweighted PCC. So yeah ECMP works better with both a greater number and diversity of connections with different IP/ports, & ideally shorter in length - stuff like dozens of devices browsing the web generates a fair amount of connections to various different place, or BitTorrent of common file, will show the Mikrotik “sharing” connections in my experience.

For TCP/flow control, ECMP essentially relies on the each connected devices’ TCP congestion control algorithm to limit the rate (which is may also not be necessarily fair to all), which works (although almost certainly want a queue on mikrotik side in practice). Obviously each connection is limited by the speed of the selected LTE interface for each individual connection. e.g. ECMP != bonding. Now the typical side-effect of ECMP selection is that for long lived connections, the Mikrotik connection tracking will continue to use the same, but say potentially “slower connection” until either the interface or connection drops.

I would consider ECMP mostly to balance traffic over two links (e.g. VPN tunnels) where both ends are under my control and no NAT is involved.
Is there any advantage of using ECMP in your scenario, vs the “standard” solution of setting up route marking via some form of per-connection classification (based on IP+port or N’th matchers)?

Since v7 is still beta was trying to just test ECMP using “regular LTE”, In v6, we use ECMP with PBR a lot, but still use some firewall filters and marking stuff. I used a VLAN here for example only - since if you use ECMP in the main routing table, you’d almost certainly need to do at least connection and route marking, which add to a minimal example of it working & HOW a connection/packet found it’s way to a route table is different thing. A VLAN-based subnet + PBR was easier than /ip/firewall/manage rules,…

Now, for disclaimer on my approach, for production use, since you can’t always avoid masquerade since WAN IP of LTE isn’t always deterministic, thus able to

 action=src-nat

, you have to use firewall marking to counter the side-effect of

action=masquerade

potentially “leaking” packets if an LTE interface goes up/down. If you take a look at page 23-27 of from '17 MUM titled “‘holy war’ against masquerade” https://mum.mikrotik.com/presentations/EU17/presentation_4058_1490948376.pdf - it will clarify my summary).[/i]

[Jotne]

On STATIC all type are set and searchable except for "A" (with or without quotes are useless)

Not sure what you mean.
For me

 :put [/ip dns cache find where type="A"]

This only gets type "A" record, NOT "AAAA"

 :put [/ip dns cache find where type="AAAA"]

This only gets type "AAAA" records.

[pe1chl]

AFAIK ECMP depends on connection tracking (and NAT too here). While not privy to the internals, I assume ECMP the same as unweighted PCC. So yeah ECMP works better with both a greater number and diversity of connections with different IP/ports, & ideally shorter in length - stuff like dozens of devices browsing the web generates a fair amount of connections to various different place, or BitTorrent of common file, will show the Mikrotik “sharing” connections in my experience.

Ok, I do run a v6 load balancing configuration (unfortunately only IPv4 as v6 cannot do this for IPv6) but I have setup the PCC using only source address as the classifier, as I am not sure that every service on the internet is able to handle the changing source IP well. There are about 500 users on that network and I cannot rely on them reporting problems they have with certain sites or apps, and I do not want a buzz “the network is not working well” going around and coming back to me via management 3 months later.
Of course with 500 users it does not really matter that they are statically mapped to one connection each, that would be more important when you have a small number of users.
In fact I do a 1/4-3/4 mapping in PCC because (due to v6 limitations) all IPv6 traffic goes over one of the connections, that one gets 1/4 of the IPv4 users, and the other one gets 3/4 of the users. That about balances the traffic evenly.

Still, doing it via ECMP is an interesting approach. Do you ever see problems due to the random changeovers between the connections within a single user “session” with websites etc?

[mfrey]

try [find type=“A”]

Same result.

@Jotne: I think what rextended meant was that you can find cache entries with type=“A” and type=A, but the same does not work for static entries.

[rextended]

On STATIC all type are set and searchable except for "A" (with or without quotes are useless)

Not sure what you mean.

Exact, as yourself quoted, I mean STATIC, not cache...

[vfreex]

Hi,

Another minor issue with l3 hw I found is updating next-hop in an existing static route doesn’t take effect. A workaround could be turning that route off and on again.

[gdanov]

Is there any known issue with Traffic Flow in beta6? It looks like I can’t get any netflow info into logstash (and I have checked everything in terms of config, FW, etc.)

If no one has an idea, I will open a support case to check if it really is an issue in MT or not.

Cheers,
anthonws.

Replying to myself for broader awareness and ask for hints

After adding another target to Traffic Flow (v9), I could confirm that indeed the issue is that date is showing up as 1970… Hence why I was seeing no data in Kibana… I just had to look into the Index Mapping to see why…
I confirmed with nfcapd and nfdump that date is showing up as 1970-01-01.

Can anyone confirm is they see the same with beta6?

Thanks,
anthonws.

I also had my date “reset” after the upgrade. But because the LTE interface wouldn’t work (no other WAN for me) I don’t know if this was interim issue or general one with NTP or whatever…anyhow I downgraded due to the LTE problem.

[anthonws]

I also had my date “reset” after the upgrade. But because the LTE interface wouldn’t work (no other WAN for me) I don’t know if this was interim issue or general one with NTP or whatever…anyhow I downgraded due to the LTE problem.

Thanks for sharing!
Reported bug (SUP-51582).

Cheers,
anthonws.

[raimondsp]

Hi,

Another minor issue with l3 hw I found is updating next-hop in an existing static route doesn’t take effect. A workaround could be turning that route off and on again.

Hey there,

We reproduced the reported issue and are working on the fix. Thanks for the feedback!

[sinisa]

Hello Mikrotik,

can we expect UPS package for v7?

Thanks and Best Regards…

[ivicask]

Anyone can tell me what is this?I only use this router (HEX) for wireguard and nothing else, first time i see this messages and thats only after beta 6

[pe1chl]

Those messages are related to IPv6 on your local network. Unfortunately they do not include enough info to hunt down what device is causing them.
(there should be a MAC address or IPv6 address in those messages…)

[ivicask]

Those messages are related to IPv6 on your local network. Unfortunately they do not include enough info to hunt down what device is causing them.
(there should be a MAC address or IPv6 address in those messages…)

Yeah i figured it already and disabled IPV6 as we dont use it at all.

[Amm0]

LTE/MBIM with CHR on KVM/QEMU using v7.1beta6 issues…

I can get MBIM modems working with CHR v7 on KVM, however I have to use “USB Redirection” (via spicevmc). But I want to “passthrough” the USB device so it’s there with CHR starts up. In v6 CHR with PPP mode same modem is passthrough just fine.

In fact, if is passthrough, it literally hangs CHR, no network, no console input is accepted - have to hard reset the VM. Removing the passthrough-ed MBIM modem from CHR’s VM config fixes the hang. USB Redirection works fine however and seem stable (BUT that method doesn’t survive a reboot, since the MBIM modem is for remote management, not ideal)

Curious if anyone else has tried CHR with MBIM on v7?

Related issues with CHR - haven’t tried on other hypervisors, but v7.1beta6 doesn’t seem to support the VM client tools scripts anymore - shutdown/restart from QEMU host seem to be ignored - which really slows down host restarts.

[pavelion]

Does anyone else have had problem with upgrading Chateau LTE?

I am not able to upgrade brand new device shipped with 7.1beta4 (http://forum.mikrotik.com/t/v7-1beta5-development-is-released/147722/187).

Now 7.1beta6 cannot be installed neither using /system/package/update nor uploading the package to the device and rebooting.

[infabo]

Netinstall should work. https://help.mikrotik.com/docs/display/ROS/Netinstall

[pqatsi]

Hello!

Using hAP ac^2 with this ROS Version apparently is only possible if using backup firmware. Normal boot goes into a boot loop since at least beta4.