RouterOS v6 to v7 Migration

RouterOS v6 to v7 Migration

RouterOS v7 represents a major architectural update with significant changes to configuration structures, feature implementations, and command syntax. This guide provides comprehensive coverage of migration scenarios, deprecated features, and practical examples for administrators transitioning from RouterOS v6 to v7.

Overview

RouterOS v7 introduces a completely redesigned network stack with improvements in performance, security, and feature capabilities. The transition from v6 to v7 requires careful planning and testing, as many configuration elements have been restructured or replaced. Unlike incremental updates, the v6-to-v7 migration involves fundamental changes to how RouterOS handles network interfaces, switching, routing protocols, and firewall operations.

The migration process should always begin in a laboratory environment before any production router is upgraded. Configuration files from RouterOS v6 cannot be directly imported into RouterOS v7 without modification, and certain features may require complete reimplementation. Administrators should allocate sufficient time for testing critical services including firewall rules, routing protocols, VPN tunnels, and QoS configurations.

Key Architectural Changes

RouterOS v7 introduces several fundamental architectural improvements that necessitate configuration changes. The most significant change involves the bridge implementation, which now provides hardware offloading capabilities comparable to enterprise-grade switches. The new bridge architecture supports modern switching features including STP/RSTP/MSTP, port-based VLANs with hardware acceleration, and IGMP snooping for multicast traffic optimization.

The routing table architecture has been enhanced to support larger route tables and faster lookups, essential for ISPs and enterprises with complex network topologies. OSPF and BGP implementations have been rewritten to provide better convergence times and more flexible configuration options. The firewall has been updated with improved connection tracking performance and additional match criteria for modern networking requirements.

Supported Upgrade Paths

RouterOS v7 runs on all RouterBOARD hardware that supports RouterOS v6.47 or later releases. Older devices running RouterOS v6.x releases below RouterOS v6.47 must first upgrade to an intermediate RouterOS v6.47+ version before transitioning to v7. This requirement ensures that the routerboard firmware and bootloader are compatible with RouterOS v7 requirements.

Devices with limited flash storage may encounter space constraints when upgrading to RouterOS v7. The v7 release requires approximately 20% more storage space than equivalent v6 versions. Administrators should verify available storage using /system resource print and clear unnecessary packages or files before initiating the upgrade.

Pre-Migration Preparation

Successful migration requires thorough preparation including configuration auditing, backup creation, and testing procedures. The preparation phase identifies all configuration elements that require modification and establishes a rollback strategy if issues arise during the upgrade process.

Configuration Audit

Begin by exporting your current RouterOS v6 configuration for analysis:

/export file=pre-migration-config

Review the exported configuration for elements that require special attention during migration. Pay particular attention to interface configurations using the master-port hierarchy, firewall rules referencing deprecated match conditions, and scripts or schedules that may rely on v6-specific behavior.

Create a comprehensive inventory of installed packages and enabled services:

/system package print
/ip service print detail
/ppp profile print

Backup Strategy

Create multiple backup types to ensure recovery options during migration. The binary backup preserves all settings including MAC addresses and license information:

/system backup save name=pre-migration-v6

Export a plaintext configuration script for manual reference and documentation purposes:

/export file=pre-migration-config.rsc

Store all backup files on external media or remote systems before proceeding with the upgrade. Verify backup integrity by downloading and archiving the files using FTP or SCP:

sftp [email protected]
sftp> get pre-migration-config.rsc
sftp> get pre-migration-v6.backup

Testing Environment

Replicate the production configuration in a laboratory environment running RouterOS v7. This testing phase identifies migration issues before they affect production systems. The test environment should include all routerBOARD models used in production and simulate the same network topology.

Document any behavioral differences observed between v6 and v7 implementations. Certain features may function differently despite having identical configurations, requiring adjustment of parameters or configuration restructuring.

Deprecated and Removed Features

RouterOS v7 removes or deprecates numerous features from v6. Understanding these changes is essential for successful migration planning. Features marked as deprecated continue to function but will be removed in future releases, making migration advisable even if current configurations appear functional.

Master-Port Hierarchy

The master-port hierarchy was the original method for configuring switch chip ports on RouterBOARD devices. This approach treated switch ports as separate interfaces with one port designated as the master. RouterOS v7 replaces this with a bridge-based VLAN configuration that provides superior flexibility and hardware acceleration.

The following v6 master-port configuration becomes obsolete in v7:

# RouterOS v6 - Deprecated Configuration
/interface ethernet set [find default-name=ether2] master-port=ether1
/interface ethernet set [find default-name=ether3] master-port=ether1
/interface ethernet set [find default-name=ether4] master-port=ether1
/interface ethernet set [find default-name=ether5] master-port=ether1

Replace this configuration with a bridge-based VLAN setup:

# RouterOS v7 - Modern Configuration
/interface bridge add name=bridge1 vlan-filtering=yes
/interface bridge port add bridge=bridge1 interface=ether1
/interface bridge port add bridge=bridge1 interface=ether2
/interface bridge port add bridge=bridge1 interface=ether3
/interface bridge port add bridge=bridge1 interface=ether4
/interface bridge port add bridge=bridge1 interface=ether5
/interface bridge vlan add bridge=bridge1 vlan-ids=1 tagged=ether1 untagged=ether2,ether3,ether4,ether5

Switch Chip Features

The switch chip menu structure has been reorganized under the bridge interface in RouterOS v7. The /interface ethernet switch menu no longer exists as a standalone configuration location. All switch-related settings are now accessed through /interface bridge and /interface bridge mdb for multicast database management.

The following switch chip features have been deprecated:

The switch-chip menu access for VLAN configuration has been replaced by bridge VLAN settings. Port mirroring configurations previously found under /interface ethernet switch mirror are now accessible through /interface bridge mirror. QoS mappings and traffic prioritization settings have been moved to /interface bridge and /queue trees.

The master-port property on individual Ethernet interfaces has been removed entirely. Configuration scripts referencing this property will fail during migration and must be updated to use bridge-based configurations.

Routing Protocol Changes

OSPFv2 remains available in RouterOS v7 but the configuration structure has been modified. The router-id is now configured per OSPF instance rather than globally:

# RouterOS v6 OSPF Configuration
/routing ospf instance set [find default=yes] router-id=1.2.3.4

# RouterOS v7 OSPF Configuration
/routing ospf instance add name=default router-id=1.2.3.4
/routing ospf area add instance=default name=backbone area-id=0.0.0.0

BGP configuration has been restructured to support the updated routing table architecture. The peer template configuration syntax has been modified, and certain community attribute handling has been updated to support RFC-compliant BGP communities.

Firewall Modifications

The firewall connection tracking table remains functionally similar, but several match conditions have been deprecated or renamed. The connection-bytes match condition has been replaced with packet-size for more precise traffic control:

# RouterOS v6 - Deprecated
/ip firewall filter add chain=forward connection-bytes=1000000-0 action=drop comment="Limit large downloads"

# RouterOS v7 - Modern Configuration
/ip firewall filter add chain=forward packet-size=1000-65535 action=drop comment="Limit large packets"

The psd match condition for port scan detection has been deprecated. Alternative approaches using /tool torch and custom scripts should be implemented for port scan detection requirements.

Wireless Protocol Changes

The wireless interface configuration has undergone significant changes in RouterOS v7. The mode parameter options have been updated, and certain frequency band configurations require modification for regulatory compliance.

The wmm-support parameter has been deprecated as WMM is now automatically enabled for all 802.11ac and 802.11ax interfaces. The rate-set configuration has been replaced with individual rate configurations for transmit and receive parameters.

The wireless security configuration remains largely compatible, but TKIP-only cipher suites are no longer supported for WPA2 personal and enterprise configurations. Mixed mode configurations requiring TKIP must be updated to use AES-CCMP encryption.

Interface Migration

Interface configurations require substantial modification when migrating from RouterOS v6 to v7. The transition from the master-port hierarchy to bridge-based configurations affects all switched Ethernet ports on RouterBOARD devices.

Interface Naming Conventions

Default interface names (ether1, ether2, sfp1, wlan1) remain unchanged between RouterOS v6 and v7. The naming shift is architectural, not lexical: v6 used a master-port hierarchy where slave ports appeared under a single master, while v7 places all ports as equal members of a bridge interface.

The practical impact is on scripts and address assignments. In v6, IP addresses are often applied to a physical Ethernet interface acting as master. In v7, the correct target is the bridge interface:

Context	v6 Reference	v7 Reference
LAN IP address	ether1 (master port)	bridge1
DHCP server	ether1	bridge1
Firewall in-interface	ether1 (master)	bridge1
VLAN interface	/interface vlan on ethernet	/interface bridge vlan on bridge

Scripts referencing physical interfaces by name for routing or firewall purposes may still work in v7 — but only for routed (non-switched) ports. Switched ports require updating references to their bridge.

Bridge Configuration

RouterOS v7 uses bridge interfaces for all layer-2 switching functionality. Each bridge provides VLAN filtering, STP/RSTP/MSTP support, and hardware offloading for compatible switch chips. Creating a bridge requires explicit VLAN filtering configuration for tagged and untagged traffic:

# Create a simple bridge for basic switching
/interface bridge add name=bridge-main vlan-filtering=no

# Add all Ethernet ports to the bridge
/interface bridge port add bridge=bridge-main interface=ether1
/interface bridge port add bridge=bridge-main interface=ether2
/interface bridge port add bridge=bridge-main interface=ether3
/interface bridge port add bridge=bridge-main interface=ether4
/interface bridge port add bridge=bridge-main interface=ether5

# Configure hardware acceleration
/interface bridge switch set switch1 route-forwarding-slowdown=5

VLAN Configuration

VLAN tagging configuration has been consolidated under the bridge interface. Each VLAN is defined with its VLAN ID and tagged or untagged port membership:

# Configure bridge with VLAN filtering
/interface bridge add name=bridge-vlan vlan-filtering=yes

# Add ports to bridge
/interface bridge port add bridge=bridge-vlan interface=ether1
/interface bridge port add bridge=bridge-vlan interface=ether2
/interface bridge port add bridge=bridge-vlan interface=ether3

# Define VLAN 10 for management network
/interface bridge vlan add bridge=bridge-vlan vlan-ids=10 tagged=ether1 untagged=ether2,ether3

# Define VLAN 20 for guest network
/interface bridge vlan add bridge=bridge-vlan vlan-ids=20 tagged=ether1 untagged=ether3

IP Address Migration

IP address configurations remain compatible between RouterOS versions but should be reviewed for proper interface assignments. Bridge interfaces replace physical Ethernet interfaces for IP addressing in switched environments:

# RouterOS v6 - IP on physical interface
/ip address add address=192.168.1.1/24 interface=ether1

# RouterOS v7 - IP on bridge interface
/ip address add address=192.168.1.1/24 interface=bridge-main

DHCP server and client configurations follow similar migration patterns. Verify that DHCP server interfaces reference the correct bridge or VLAN interface after migration.

Firewall Migration

Firewall rule migration requires attention to deprecated match conditions and syntax changes. Most common firewall configurations transfer successfully with minor modifications.

Filter Rule Migration

Review each firewall filter rule for deprecated match conditions:

# Migrated firewall filter configuration
/ip firewall filter add chain=input action=accept protocol=tcp dst-port=22 src-address-list=ssh-allowed comment="SSH access from approved sources"
/ip firewall filter add chain=forward action=drop connection-state=invalid comment="Drop invalid connections"
/ip firewall filter add chain=forward action=accept connection-state=established,related comment="Allow established connections"

NAT Rule Migration

NAT configurations transfer with minimal changes. Verify that out-interface references use correct interface names:

# Migrated NAT configuration
/ip firewall nat add chain=srcnat out-interface=ether1 action=masquerade comment="Masquerade outbound traffic"
/ip firewall nat add chain=dstnat in-interface=ether1 protocol=tcp dst-port=80 action=dst-nat to-addresses=192.168.1.10 comment="Port forward HTTP to internal server"

Address List Migration

Address lists function identically in RouterOS v7 and can be transferred without modification:

# Address list configuration
/ip firewall address-list add list=blocked address=10.0.0.0/8 comment="Private address space"
/ip firewall address-list add list=blocked address=172.16.0.0/12 comment="Private address space"
/ip firewall address-list add list=blocked address=192.168.0.0/16 comment="Private address space"

Routing Migration

Routing protocol configurations require structural modifications for RouterOS v7 migration. Both OSPF and BGP configurations must be updated to use the new instance-based structure.

New FIB Model

RouterOS v7 separates the Routing Information Base (RIB) from the Forwarding Information Base (FIB). The RIB holds all routes from all protocols; the FIB holds only the routes that are actively installed into the forwarding plane for packet processing.

In v6, all routing tables implicitly participated in forwarding. In v7, a routing table only installs routes into the FIB when explicitly declared with the fib flag:

# Without fib: routes are computed but NOT used for forwarding
/routing table add name=analysis-table

# With fib: routes ARE installed into the forwarding plane
/routing table add name=ISP2-IP fib

This design allows running routing protocol calculations or policy analysis in isolated tables without affecting production forwarding. It also means that any custom routing table referenced by a mangle rule or policy rule must include the fib flag, or traffic will not be forwarded.

Policy Routing Changes

RouterOS v7 introduces significant changes to policy-based routing. In v6, routes with routing marks worked automatically, but v7 requires explicit routing table declaration:

# RouterOS v7 - Explicitly declare routing tables
/routing table add name=ISP1-Fiber fib
/routing table add name=ISP2-IP fib

The routing-mark parameter in /ip route has been replaced with routing-table:

# RouterOS v6 - Deprecated
/ip route add gateway=192.168.6.1 routing-mark=ISP2-IP
/ip route add gateway=pppoe-Fiber routing-mark=ISP1-Fiber

# RouterOS v7 - Modern Configuration
/ip route add gateway=192.168.6.1 routing-table=ISP2-IP
/ip route add gateway=pppoe-Fiber routing-table=ISP1-Fiber

Policy routing in v7 also supports /routing rule as an alternative to mangle for steering traffic into specific tables:

# Route traffic from a specific subnet via ISP2 table
/routing rule add src-address=10.10.10.0/24 action=lookup table=ISP2-IP

When using mangle rules for policy routing, ensure NAT rules specify the correct out-interface for each WAN:

# NAT rules must match the policy routing interface
/ip firewall nat add chain=srcnat out-interface=pppoe-Fiber action=masquerade
/ip firewall nat add chain=srcnat out-interface=ether2-IP action=masquerade

OSPF Migration

The OSPF configuration transforms from a global instance to named instances:

# RouterOS v7 OSPF Configuration
/routing ospf instance add name=ospf-main router-id=1.2.3.4 redistribute=connected,static
/routing ospf area add instance=ospf-main name=backbone area-id=0.0.0.0
/routing ospf area add instance=ospf-main name=area1 area-id=0.0.0.1

# Add interfaces to OSPF
/routing ospf interface-template add area=backbone networks=192.168.0.0/16

BGP Migration

BGP configurations use a similar instance-based approach:

# RouterOS v7 BGP Configuration
/routing bgp instance add name=bgp-main as=65001 router-id=1.2.3.4

# Configure peers
/routing bgp peer add name=peer1 instance=bgp-main remote-address=10.0.0.2 remote-as=65002
/routing bgp network add network=192.168.0.0/24

VPN Migration

VPN configurations generally transfer successfully between RouterOS versions, but certificate-based VPNs require verification of certificate compatibility.

IPsec Migration

IPsec configurations remain largely compatible:

# IPsec peer configuration
/ip ipsec peer add address=0.0.0.0/0 name=remote-peers exchange-mode=ike2

# IPsec identity
/ip ipsec identity add peer=remote-peers auth-method=pre-shared-key secret="your-shared-secret"

# IPsec proposal
/ip ipsec proposal add name=default enc-algorithms=aes-256-gcm,aes-128-gcm

# IPsec policy
/ip ipsec policy add src-address=192.168.1.0/24 dst-address=10.0.0.0/24 sa-src-address=public-ip sa-dst-address=remote-peer-ip tunnel=yes action=encrypt

PPTP and L2TP Migration

PPTP remains available in RouterOS v7 but is deprecated for security reasons. L2TP with IPsec is recommended for VPN deployments requiring compatibility with existing configurations:

# L2TP server configuration
/interface l2tp-server server set enabled=yes use-ipsec=yes

# L2TP user
/ppp secret add name=vpn-user password=secure-password service=l2tp

Common Migration Scenarios

The following scenarios represent typical migration situations and their resolution approaches.

Simple Router Migration

A basic router with NAT and firewall rules requires minimal modification:

# Pre-migration configuration analysis
/export

# Configuration modifications needed:
# 1. Remove master-port references
# 2. Create bridge if using switch ports
# 3. Update firewall for deprecated match conditions
# 4. Verify IP addressing on correct interfaces

/interface bridge add name=bridge1 vlan-filtering=no
/interface bridge port add bridge=bridge1 interface=ether1
/interface bridge port add bridge=bridge1 interface=ether2
/interface bridge port add bridge=bridge1 interface=ether3
/ip address add address=192.168.88.1/24 interface=bridge1
/ip dhcp-server network add address=192.168.88.0/24 gateway=192.168.88.1
/ip firewall nat add chain=srcnat out-interface=ether1 action=masquerade
/ip firewall filter add chain=forward action=accept connection-state=established,related
/ip firewall filter add chain=forward action=drop connection-state=invalid
/ip firewall filter add chain=input action=accept protocol=tcp dst-port=22

Managed Switch Migration

A router configured as a managed switch requires comprehensive bridge configuration:

# Managed switch configuration for RouterOS v7
/interface bridge add name=switchbridge vlan-filtering=yes

# Trunk port to upstream router
/interface bridge port add bridge=switchbridge interface=ether1
/interface bridge vlan add bridge=switchbridge vlan-ids=1,10,20,30 tagged=ether1

# Access ports for devices
/interface bridge port add bridge=switchbridge interface=ether2
/interface bridge vlan add bridge=switchbridge vlan-ids=10 untagged=ether2

/interface bridge port add bridge=switchbridge interface=ether3
/interface bridge vlan add bridge=switchbridge vlan-ids=10 untagged=ether3

/interface bridge port add bridge=switchbridge interface=ether4
/interface bridge vlan add bridge=switchbridge vlan-ids=20 untagged=ether4

/interface bridge port add bridge=switchbridge interface=ether5
/interface bridge vlan add bridge=switchbridge vlan-ids=30 untagged=ether5

Router-on-a-Stick Migration

A router handling inter-VLAN routing requires proper bridge VLAN configuration:

# Router-on-a-stick configuration
/interface bridge add name=vlan-router vlan-filtering=yes

# Trunk port
/interface bridge port add bridge=vlan-router interface=ether1
/interface bridge vlan add bridge=vlan-router vlan-ids=10,20,30 tagged=ether1

# Internal interfaces
/interface bridge port add bridge=vlan-router interface=ether2
/interface bridge vlan add bridge=vlan-router vlan-ids=10 untagged=ether2

/interface bridge port add bridge=vlan-router interface=ether3
/interface bridge vlan add bridge=vlan-router vlan-ids=20 untagged=ether3

# VLAN interfaces for routing
/ip address add address=10.0.10.1/24 interface=vlan10
/ip address add address=10.0.20.1/24 interface=vlan20

# DHCP servers for each VLAN
/ip dhcp-server network add address=10.0.10.0/24 gateway=10.0.10.1
/ip dhcp-server network add address=10.0.20.0/24 gateway=10.0.20.1

Post-Migration Verification

After completing the migration, systematically verify all router functions to ensure proper operation.

Interface Verification

Confirm that all interfaces are operational and have correct link status:

/interface bridge port print
/interface bridge vlan print
/interface print
/ip address print

Firewall Verification

Verify that firewall rules are active and processing traffic:

/ip firewall filter print
/ip firewall nat print
/ip firewall connection print

Routing Verification

Confirm that routing protocols have established adjacencies and routes are installed:

/ip route print
/routing ospf neighbor print
/routing bgp peer print

Service Verification

Test all enabled services including DHCP, DNS, and VPN tunnels:

/ip dhcp-server lease print
/ip dns cache print
/ip ipsec remote-peers print

Rollback Procedure

If critical issues arise during or after migration, the following rollback procedure restores RouterOS v6 functionality.

Emergency Rollback

Use Netinstall to restore RouterOS v6 if the router becomes inaccessible:

1. Download the RouterOS v6 .npk file for your device architecture
2. Use Netinstall software to format and reinstall RouterOS
3. Restore configuration from pre-migration backup
4. Verify all services function correctly before returning to production

Netinstall LED Indicators

During the Netinstall process, the router’s LEDs indicate the current status:

LED Behavior	Status
All LEDs flash rapidly	Netinstall mode active, waiting for client
User LED blinks slowly	TFTP request in progress
User LED on (solid)	RouterOS installation in progress
All LEDs flash 3 times	Installation complete, rebooting

Note

LED patterns may vary slightly by RouterBOARD model. The user LED is typically the primary activity indicator during Netinstall.

Configuration Restoration

Restore the v6 configuration from the exported script:

/import pre-migration-config.rsc

Best Practices

Follow these practices to ensure successful RouterOS v6 to v7 migrations.

Planning Phase

Allocate sufficient time for testing all critical functions before production migration. Create detailed migration checklists specific to your network configuration. Document all non-standard configurations and custom scripts requiring updates.

Testing Phase

Maintain a laboratory environment mirroring the production configuration. Test all firewall rules, routing protocols, VPN tunnels, and QoS configurations. Verify that bandwidth tests and latency measurements meet performance requirements.

Execution Phase

Perform migrations during maintenance windows with minimal production impact. Have rollback plans prepared before initiating changes. Monitor router resources and logs during and after migration.

Documentation Phase

Update network documentation to reflect RouterOS v7 configurations. Archive v6 configuration scripts for reference. Document any behavioral differences observed between versions.

Related Resources

• RouterOS v7 Documentation
• Bridge Configuration
• Upgrade Guide
• Getting Started Overview
• System Administration