I have checked the BGP configuration. I see its a little different from the v6 but I still can’t find how to configure
the route-targets. Please can you assist me on the how to.
Look at /routing/bgp/vpn menu:
https://help.mikrotik.com/docs/pages/viewpage.action?pageId=328220#id-/routing/bgp-/routing/bgp/vpn
Wanted to use /routing/filter to set distance and check-gateway on DHCP Client injected routed. The filter rules have do this in V6, but can’t make it work in v7rc7.
Pretty sure it me, but not sure why this doesn’t work using the new rule syntax:
/routing filter rule add chain=dynamic-in disabled=no rule="if (distance==1) { set gw-check icmp; accept }"
And seems like I have a “dynamic-in” chain:
/routing/filter> chain/print
Flags: I - inactive; D - dynamic
0 D name="dynamic-in"
But it’s not changing the “check-gateway” as shown /ip/route. Tried with and without the “accept”. Also tried using “check-gateway” just in case it was a bug in the docs… Although it pretty confusing to using “gw-check”, as said in the docs, to set a property named “check-gateway”). In V6, the tab completion allows me to know if attributes were “correct”… but obviously you can’t “hit tab” in the rule= part of “routing filter rules” to fill in the right name, so very hard to which name right…so tried both in a few different combos. Nothing seems to change the DHCP Client’s dynamicly-created default routes settings.
There is no built-in connected-in or dynamic-in chains in ROS v7.
Fair enough, using the filter rules was kinda weird for this in V6.
But, what’s the workaround for V7 to set distance on DHCP client route? Didn’t try crossfig to see what happens, would that convert this?
We use the dynamic-in filter rule in our V6 configs, so when then upgrade, that could be very problematic since the routing order may change after upgrade…
You should closely watch your filter rules after upgrade anyway. They are converted to a completely different syntax, and we do not know if the converter can handle all possible cases.
(I did my conversion under v7.1rc5 and it was a mess, many rules were deleted without any trace. I would think the least they could do is convert them into a comment)
I’ll try what happens with v7.1rc7, on my other router.
The converter wasn’t finished yet in rc5. RC7 should convert all the filters and if some parameter cannot be converted, the comment is added and all the rules in the chain with an error becomes inactive.
I noticed that the v7 Routing Protocol Status has apparently been updated with the feature status in v7.1 stable.
https://help.mikrotik.com/docs/display/ROS/v7+Routing+Protocol+Status
Implying a stable release may be only days away now.
Well it has mainly been deletions of info… actually it was nice to see the feature status of the previous version(s) so you could easily see what has improved and can be tested again.
Now there isn’t even a column for v7.1rc7 anymore so we cannot know what the feature status is right now (is likely the same as already shown).
Confluence tracks the page history, so at least you can have a look at the old page with v7.1rc6:
Maybe now Mikrotik van start with device specific fixed already in V6. Like th RB4011 not able to maintain a MTU of 1500 on a PPPoE connection through the SPF interface. It now reaches a MTU 1492.
My RB4011 have no problem on PPPoE with MTU 1540 when using the SFP+ port.
I use a router-in-a-stick configuration, as the switch on the RB4011 is useless
Why is it useless?
… in fact the switch in the 4011 is the rare exception in MikroTik routers that can actually switch VLANs while configured as a bridge…
Strange because it is stated that PPPoE is max 1500:
The header uses six bytes and the ID two. Then the MTU behind the PPPoE should be 1508. I have to use VLAN and that adds 4 bytes and the SPF sets at 1598 or so.
My 4011 is also only doing the connection plus VPN. What are your setting for over 1500? Mine drops after a few seconds from 1500 to 1492.
I have 1500 byte MTU on a 4011 with PPPoE connection running over a VLAN on ether1.
ether1 has MTU 1592, the VLAN has MTU 1588, the PPPoE is configured with MTU 1500, and remains at that.
The SFP+ has MTU 1598 so should be able to do that as well.
Remember not all ISPs support it! The fact you can configure it on the router does not mean it will work, as the ISP may force MTU 1492 anyway.
If I use an ether port then it works but then I have to put the NTU in the fiber path. In V6 it was fixed. Before the fix I had to restart the SPF after fours seconds to upgrade to a MTU of 1500. That trick does not work anymore in V7.
ppp-max-payload=1514
<mru 1500>
And switching back:
data len 1492 is normal in mikrotik logs for the lcp echo request & reply with a rfc4638 compliant pppoe.
That’s also what I see in my logs.
ppp-max-payload is 1500 though.
And resulting mtu/mru is 1500.
Thank you for your replies. I know the issue needs more investigation from my end, as it is application specific (Windows 2016 does not have this issue, just Windows 2012 R2). The auto-tuning parameter did not help (unless it requires a reboot, but in my experience netsh is activated immediately). Thanks for your efforts.
In testing /interface/detect-internet with r7.1rc7, I noticed it creates a DHCP client automatically. This was a surprise to me that “Detect Internet” added a persisted DHCP client, with an un-configurable “default-route-distance=1” – as such, it takes over as default route when during Internet Detect’s process. Maybe it did this V6, but our dynamic-in filter rules would caught the distance and prevent a DHCP client from setting a route at distance=1, so I wouldn’t have noticed.
Now, the DHCP client created by “Detect Internet” does have a comment with a clue what’s happening “;;; internet detect”:
/ip/dhcp-client/print
Flags: X, I, D - DYNAMIC
Columns: INTERFACE, USE-PEER-DNS, ADD-DEFAULT-ROUTE, STATUS, ADDRESS
# INTERFACE USE-PEER-DNS ADD STATUS ADDRESS
0 X vlan-internet-in no no
;;; internet detect
1 D vlan-internet-in yes yes bound 10.11.12.13
This DHCP client seems to persist, until you set internet-interface-list=“none”. The interface is a VLAN that does goes to a DMZ-type network. While that VLAN interface does have DHCP available from a different host, I didn’t expect Detect Internet to turn into Use Internet from DHCP on this particular interface.
Maybe this correct behavior. But not what’s document. The “Help” docs states for WAN (which is a prerequisite for Internet state):
Any L3 tunnel and LTE interfaces will initially have this state. Layer 2 interfaces can obtain this state if:
- an interface has an active route to 8.8.8.8 in main routing table.
- an interface can obtain (or has obtained) an address from DHCP (does not apply if DHCP server is also running Detect Internet on the DHCP server interface).
__
It doesn’t say “will obtain a DHCP address for you if needed”. The two bullets weren’t clear
if help==\[*\] then {&& or ||, (", or" | &)} else '\;-\)'
.
The config used isn’t mine – it’s what the Mikrotik iPhone smartphone (advertised at top 
) adds when some user enables it in the app:
/interface/detect-internet> export
# dec/01/2021 15:04:08 by RouterOS 7.1rc7
# model = RBD25GR-5HPacQD2HPnD
/interface detect-internet
set detect-interface-list=all internet-interface-list=WAN
So the config here isn’t my choice. And reconfiguring it in the app looked like a bad idea since it didn’t match the CLI, so didn’t try to tap the checkmark:
/interface/detect-internet> print
detect-interface-list: all
lan-interface-list: none
wan-interface-list: none
internet-interface-list: WAN
The full config is same as I posted here, which is largely my V7 test platform: http://forum.mikrotik.com/t/using-wifiwave2-to-bridge-two-audience-wirelessly-thoughts-4-address-mode/153357/1