Route invalid after reboot

RouterOS General
1

Hi,

the route for the management VRF on a separated interface gets red/invalid after every reboot, making it impossible for me to manage the device unless I NAT myself in and deconfigure the narrowed down IP allow lists for all the management services. Disabling and re-enabling the route fixes it and everything works as expected until the next reboot.

The router has three legs:

  • one WAN facing (192.168.31.45/30, eth1), connected to a WAN DMZ of my hardware firewall - main default route goes there
  • one LAN facing (192.168.31.41/30, eth2-4/bridge), connected to a LAN DMZ of my hardware firewall - routes to internal networks 192.168.25.0/24 and 192.168.26.0/24 point there
  • one MGMT interface (192.168.31.61/30, eth5), connected to a Management DMZ of my hardware firewall - default route for the mgmt VRF, only intended for management purposes - this one gets invalid after reboot

This is my configuration (hEX, ROS 7.2, issue was already there with 7.1.1):

/interface bridge
add admin-mac=12:34:56:78:9A:BC auto-mac=no comment=defconf name=bridge protocol-mode=none
/interface list
add comment=defconf name=WAN
add comment=defconf name=LAN
/ip pool
add name=SSTP-VPN-Pool ranges=10.21.25.2-10.21.25.100
/ip vrf
add interfaces=ether5 name=mgmt
/port
set 0 name=serial0
/ppp profile
add dns-server=192.168.25.1,192.168.26.1 local-address=10.21.25.1 name=SSTP-VPN-Profile only-one=yes remote-address=SSTP-VPN-Pool use-compression=yes use-encryption=required
use-upnp=no
/interface bridge port
add bridge=bridge comment=defconf ingress-filtering=no interface=ether2
add bridge=bridge comment=defconf ingress-filtering=no interface=ether3
add bridge=bridge comment=defconf ingress-filtering=no interface=ether4
/ip neighbor discovery-settings
set discover-interface-list=LAN
/ipv6 settings
set disable-ipv6=yes max-neighbor-entries=8192
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
/interface sstp-server server
set authentication=mschap2 certificate=certificate-request.cer_0 default-profile=SSTP-VPN-Profile enabled=yes pfs=yes tls-version=only-1.2
/ip address
add address=192.168.31.41/30 interface=bridge network=192.168.31.40
add address=192.168.31.45/30 interface=ether1 network=192.168.31.44
add address=192.168.31.61/30 interface=ether5 network=192.168.31.60
/ip dns
set allow-remote-requests=yes servers=192.168.25.1,192.168.26.1
/ip firewall address-list
add address=10.21.25.2-10.21.25.100 list=SSTP-VPN-Client-Pool
add address=192.168.25.0/24 list=MY25-LAN
add address=192.168.26.0/24 list=MY26-LAN
/ip firewall filter
add action=drop chain=input src-address-list=SSTP-VPN-blocked
add action=accept chain=input comment=“defconf: accept established,related,untracked” connection-state=established,related,untracked
add action=drop chain=input comment=“defconf: drop invalid” connection-state=invalid
add action=accept chain=input comment=“defconf: accept ICMP” in-interface=!all-ppp protocol=icmp
add action=accept chain=input comment=“defconf: accept to local loopback (for CAPsMAN)” dst-address=127.0.0.1
add action=drop chain=input comment=“defconf: drop all not coming from LAN” disabled=yes in-interface-list=!LAN
add action=drop chain=input comment=“drop all input from ppp” in-interface=all-ppp
add action=fasttrack-connection chain=forward comment=“defconf: fasttrack” connection-state=established,related hw-offload=yes
add action=accept chain=forward comment=“defconf: accept established,related, untracked” connection-state=established,related,untracked
add action=drop chain=forward comment=“defconf: drop invalid” connection-state=invalid
add action=accept chain=forward comment=“accept from ppp MY25-Access list to MY25-LAN” dst-address-list=MY25-LAN in-interface=all-ppp out-interface=bridge src-address-list=
MY25-Access
add action=accept chain=forward comment=“accept from ppp MY26-Access list to MY26-LAN” dst-address-list=MY26-LAN in-interface=all-ppp out-interface=bridge src-address-list=
MY26-Access
add action=drop chain=forward comment=“drop all forward from ppp” in-interface=all-ppp
/ip route
add disabled=no dst-address=0.0.0.0/0 gateway=192.168.31.46 pref-src=192.168.31.45
add check-gateway=ping disabled=no dst-address=192.168.0.0/16 gateway=192.168.31.42 pref-src=192.168.31.41
add check-gateway=ping disabled=no distance=1 dst-address=0.0.0.0/0 gateway=192.168.31.62@mgmt pref-src=192.168.31.61 routing-table=mgmt suppress-hw-offload=no vrf-interface=ether5
/ip service
set telnet disabled=yes vrf=mgmt
set ftp disabled=yes
set www vrf=mgmt
set ssh vrf=mgmt
set www-ssl certificate=certificate-request.cer_0 disabled=no tls-version=only-1.2 vrf=mgmt
set api disabled=yes vrf=mgmt
set winbox vrf=mgmt
set api-ssl disabled=yes vrf=mgmt
/ppp aaa
set use-radius=yes
/radius
add address=192.168.25.1 service=ppp src-address=192.168.31.41

What am I doing wrong? VRF still not so much separating? I thought this was heavily improved with ROS 7.x…

Thanks!

2

bump
got nobody an idea? i still wasn’t able to solve this issue. is this more likely a bug or more likely a misconfiguration?
is this even the way VRFs were meant to be used? basically I wanted to have a completely separated management interface, that’s all…

3 
add check-gateway=ping disabled=no distance=1 dst-address=0.0.0.0/0 gateway=192.168.31.62@mgmt pref-src=192.168.31.61 routing-table=mgmt suppress-hw-offload=no vrf-interface=ether5

Could you try disable the check-gateway=ping on this route to see if it makes a difference to the route showing red on boot?

4

first i thought it was solved but then I realized I had NATted myself into the device and the route was still red/invalid after the reboot. So no, unfortunately this didn’t solve the issue.

Maybe we can track this down by analyzing what factors RouterOS takes into account in the decision path whether a route is invalid or not? Unfortunately I don’t know much about that.

5

Hello azzurro,

Did you open a ticket regarding this?

I think We are facing same problem. When you configure routes they became up, but after reboot they started as Inactive.
Disable and reenable the route made them to work again (other routes are removed from output):

 [] > ip/route/print
Flags: D - DYNAMIC; X, I, A - ACTIVE; c, s, y - COPY
Columns: DST-ADDRESS, GATEWAY, DISTANCE
#     DST-ADDRESS     GATEWAY              DISTANCE
0  Is 0.0.0.0/0       192.0.2.62@internet
[] > ip/route/set numbers=0 disabled=yes
[] > ip/route/set numbers=0 disabled=no
[] > ip/route/print
Flags: D - DYNAMIC; X, I, A - ACTIVE; c, s, y - COPY
Columns: DST-ADDRESS, GATEWAY, DISTANCE
#     DST-ADDRESS     GATEWAY              DISTANCE
0  As 0.0.0.0/0       192.0.2.62@internet         1

Route is defined by:

/ip route add disabled=no dst-address=0.0.0.0/0 gateway=192.0.2.62@internet routing-table=internet vrf-interface=ether2

I got reproduced the problem in chr lab; in 8 of 9 routers it is needed to disable the route and then enable it again, ont 9th router it worked fine and it is not needed to do that, but all of them had equivalent configuration.

Best Regards,

Diego

6

nope, i did not open a ticket about this - did you?

7

7.3beta33 has a fix for this, i have confirmed with my device that the issue has gone away!

8

I worked also on my lab. Thanks for sharing.

Best Regards,

Diego