[secops] mgmt VRF routing

[Bart Kus]

I think I figured out mgmt VRF routing.  It's a little more complicated 
than our existing routing.  Here's the template I came up with tonight:

# Portal actions:
# Make sure a 10.44.#.0/24 is allocated for the site involved.
# Make sure a 10.44.32.#/30 is allocated for the PtP involved.
# Make sure a 10.44.48.#/32 is allocated for the router involved.

# SnoDEM.Haystack example:
/interface vlan
add interface=ether1 name=ether1.mgmt vlan-id=1044
add interface=wlan1 name=wlan1.mgmt vlan-id=1044
/interface bridge
add name=loopback0.mgmt
/ip route vrf
add interfaces=loopback0.mgmt,ether1.mgmt,wlan1.mgmt routing-mark=mgmt
/ip address
add address=10.44.48.0/32 interface=loopback0.mgmt
add address=10.44.1.10/24 interface=ether1.mgmt
add address=10.44.32.1/30 interface=wlan1.mgmt
/routing filter
add action=accept chain=mgmt prefix=10.44.0.0/16 prefix-length=16-32
add action=accept chain=mgmt prefix=0.0.0.0/0
add action=reject chain=mgmt
/routing ospf instance
# Use the loopback0.mgmt IP for router-id.
add in-filter=mgmt name=mgmt out-filter=mgmt 
redistribute-connected=as-type-1 router-id=10.44.48.0 routing-table=mgmt
/routing ospf area
add instance=mgmt name=mgmt
/routing ospf network
add area=mgmt network=10.44.48.0/32  # Is this a RouterOS bug? Should 
not need to be configured.
add area=mgmt network=10.44.1.0/24
add area=mgmt network=10.44.32.0/30
# mgmt VRF OSPF interfaces will be added dynamically, no need to configure.

# Haystack.SnoDEM example:
/interface vlan
add interface=ether1 name=ether1.mgmt vlan-id=1044
add interface=wlan1 name=wlan1.mgmt vlan-id=1044
/interface bridge
add name=loopback0.mgmt
/ip route vrf
add interfaces=loopback0.mgmt,ether1.mgmt,wlan1.mgmt routing-mark=mgmt
/ip address
add address=10.44.32.2/30 interface=wlan1.mgmt
add address=10.44.0.11/24 interface=ether1.mgmt
add address=10.44.48.1 interface=loopback0.mgmt
/routing filter
add action=accept chain=mgmt prefix=10.44.0.0/16 prefix-length=16-32
add action=accept chain=mgmt prefix=0.0.0.0/0
add action=reject chain=mgmt
/routing ospf instance
add in-filter=mgmt name=mgmt out-filter=mgmt 
redistribute-connected=as-type-1 router-id=10.44.48.1 routing-table=mgmt
/routing ospf area
add instance=mgmt name=mgmt
/routing ospf network
add area=mgmt network=10.44.48.1/32  # Is this a RouterOS bug? Should 
not need to be configured.
add area=mgmt network=10.44.32.0/30
add area=mgmt network=10.44.0.0/24
# mgmt VRF OSPF interfaces will be added dynamically, no need to configure.

# Invariants on PtPs, can be configured blindly:
/interface vlan
add interface=ether1 name=ether1.mgmt vlan-id=1044
add interface=wlan1 name=wlan1.mgmt vlan-id=1044
/interface bridge
add name=loopback0.mgmt
/ip route vrf
add interfaces=loopback0.mgmt,ether1.mgmt,wlan1.mgmt routing-mark=mgmt
/routing filter
add action=accept chain=mgmt prefix=10.44.0.0/16 prefix-length=16-32
add action=accept chain=mgmt prefix=0.0.0.0/0
add action=reject chain=mgmt

I left enough address space between 10.44.0.0/24 -> 10.44.31.0/24 for 32 
sites with contiguous allocation.  I'll be perma-routing my home to this 
network, so I've allocated 10.44.64.0/24 for that.  Any other admins can 
allocate above 64 if they want to have a local allocation in the mgmt 
VRF.  We lose OSPF passwords with the dynamic interfaces.  Not sure how 
much of a hole that opens up.  Easily retrofitted if it becomes a 
problem though.

This syntax is for RouterOS v6, v7 will be slightly different.

Any thoughts on the potential RouterOS bug, or in general about this 
design before we stamp it out everywhere?

--Bart