Filter Wizard
Filter Wizard
Section titled “Filter Wizard”The Filter Wizard provides a graphical interface for configuring routing filters in RouterOS. It simplifies the creation and management of filter rules that control which routes are accepted, modified, or rejected by dynamic routing protocols. This wizard is available through both Winbox and WebFig, offering an intuitive way to build complex filter chains without manually constructing filter expressions.
Routing filters are essential for network administrators who need to control route propagation, implement routing policies, and prevent unwanted routes from affecting network behavior. The Filter Wizard abstracts the complexity of filter syntax while providing full access to all filter capabilities. Whether you are implementing route redistribution policies, filtering incoming BGP updates, or controlling OSPF route advertisement, the wizard guides you through the configuration process with sensible defaults and helpful descriptions.
Understanding Routing Filters
Section titled “Understanding Routing Filters”Routing filters operate on routes exchanged by dynamic routing protocols, allowing you to examine and modify route attributes before making routing decisions. Each filter consists of match conditions that determine which routes the filter applies to, and actions that specify what should happen to matching routes. The filter wizard presents these concepts in a structured workflow that helps you build correct filter configurations without requiring deep knowledge of filter syntax.
Filters work by examining routes as they enter or exit the routing table through BGP or OSPF. When a route is received from a peer, it passes through the inbound filter chain where you can accept, reject, or modify the route and its attributes. Similarly, before advertising routes to peers, they pass through outbound filters where you can control what information is shared. This bidirectional control enables sophisticated routing policies including route redistribution between protocols, BGP community tagging, AS-path manipulation, and traffic engineering through route attribute modification.
The filter chain concept organizes related filters into named groups that can be referenced by routing protocol configurations. Each chain contains an ordered list of filter rules that are evaluated sequentially, with the first matching rule determining the outcome. This evaluation model means that filter order is critical—specific filters should precede general filters, and any filter that matches all traffic should be placed last as a catch-all. The wizard interface helps visualize this order and makes it easy to reorder filters as your policy evolves.
Accessing the Filter Wizard
Section titled “Accessing the Filter Wizard”The Filter Wizard is accessible through both Winbox and WebFig interfaces. In Winbox, navigate to the Routing menu, then select Filter to open the routing filter configuration window. The wizard button within this window launches the guided configuration process. In WebFig, access the same functionality through the Routing > Filter menu, where the wizard option is prominently displayed.
Upon launching the wizard, you begin by selecting the filter chain you want to work with. If you are creating a new filter rule, you can either add it to an existing chain or create a new one. Existing chains are automatically populated based on your current routing filter configuration, showing all chains that have been defined for BGP and OSPF instances. The chain selection determines the context in which your filter will operate, including which routing protocol reference it.
The instances can wizard interface is designed to guide you through filter configuration step by step, presenting options in a logical order that mirrors the filter evaluation process. Each screen focuses on a specific aspect of filter configuration—chain selection, matching conditions, actions, and attribute modifications. You can navigate back and forth through these screens to refine your configuration before applying it. The wizard validates your choices as you progress, preventing configurations that would result in syntax errors or contradictory settings.
Configuration Properties
Section titled “Configuration Properties”The Filter Wizard exposes all routing filter properties through its interface, organized into logical groupings that simplify configuration while maintaining full functionality.
Chain Configuration
Section titled “Chain Configuration”The chain property specifies the name of the filter chain that this rule belongs to. Chains are named containers that group related filter rules together, allowing you to apply different policies to different routing protocol instances or peers.
| Property | Value | Description |
|---|---|---|
| chain | string (mandatory) | The name identifier for this filter chain. Chain names must be unique within the routing filter configuration and should follow naming conventions that indicate their purpose or scope. |
Chain names should be descriptive and follow a consistent naming convention across your router configuration. Common patterns include using prefixes that identify the protocol or purpose, such as bgp-inbound, bgp-outbound, ospf-redistribute, or descriptive names like filter-customers or block-spam-routes. The chain name is referenced when attaching filters to BGP or OSPF instances, so choose names that make the relationship clear.
Address Family Identifier
Section titled “Address Family Identifier”The AFI (Address Family Identifier) property specifies which address family the filter applies to. This is particularly important in dual-stack environments where you may need different filtering behavior for IPv4 and IPv6 routes.
| Property | Value | Description |
|---|---|---|
| afi | ip | ipv6 | l2vpn | vpnv4 | vpnv6 | l2vpn-cisco | The address family for route matching. Use ip for IPv4 routes, ipv6 for IPv6 routes, and the VPN variants for VRF and MPLS VPN route filtering. |
When configuring filters for BGP sessions that carry multiple address families, you must create separate filter rules for each AFI. The address family selection determines what route attributes are available for matching and modification. For example, IPv4 filters can match on prefix lists containing IPv4 addresses, while IPv6 filters work with IPv6 prefix lists. VPN address families (vpnv4, vpnv6, l2vpn) are used when filtering routes in VRF contexts or MPLS VPN environments where route distinguishers and route targets are relevant.
BGP AS-Path Matching
Section titled “BGP AS-Path Matching”The BGP AS-Path property allows matching routes based on their Autonomous System path sequence. This is one of the most powerful filtering capabilities for BGP, enabling you to filter based on which ASes a route has traversed.
| Property | Value | Description |
|---|---|---|
| bgp-as-path | string (regexp) | Regular expression pattern to match against the BGP AS-Path attribute. Supports standard POSIX regex syntax for flexible pattern matching. |
The AS-Path matcher uses regular expressions to examine the AS sequence in BGP update messages. Common patterns include matching specific AS numbers anywhere in the path using .*65001.*, matching routes that originated in a specific AS using _65001$, or matching routes from direct neighbors using ^65001_. The expression .* matches any sequence of AS numbers, ^ anchors to the beginning (recent ASes), and $ anchors to the end (originating AS). Well-known communities can be combined with AS-Path matching for sophisticated filtering policies.
BGP Community Matching
Section titled “BGP Community Matching”The BGP community property enables filtering based on BGP communities attached to routes. Communities are tags that BGP peers use to signal routing policy intent.
| Property | Value | Description |
|---|---|---|
| bgp-community | list of communities | List of BGP communities to match, expressed as well-known names or in as:number format. Supports exact matching and extended community matching. |
BGP communities follow the format as:number where both components are 16-bit values. Well-known communities include no-export (do not advertise to external peers), no-advertise (do not advertise to any peer), internet (default route), and graceful-shutdown (route is being gracefully shut down). The filter can match routes that contain any or all of the specified communities, depending on the matching mode selected in the wizard.
BGP Extended Communities
Section titled “BGP Extended Communities”Extended communities extend the basic community concept with additional community types for VPN and other specialized applications.
| Property | Value | Description |
|---|---|---|
| bgp-ext-community | list of ext-communities | Extended communities expressed as raw integers or in type:value format. Types include rt (route-target) and soo (site-of-origin). |
Extended communities are primarily used in MPLS VPN environments for controlling route import and export across VRFs. Route targets (RT) in the format 65001:100 specify which VRFs should import a route, while site-of-origin (SoO) identifies the originating site to prevent routing loops in multi-homed scenarios.
Filter Actions
Section titled “Filter Actions”The action property specifies what happens when a route matches the filter conditions. RouterOS supports several actions that determine the fate of matching routes.
| Action | Description |
|---|---|
| accept | Accept the route into the routing table (or advertise it if outbound). This is the default action for routes that match all conditions. |
| drop | Discard the route silently. The route is not added to the routing table and no BGP withdrawal is sent. |
| reject | Discard the route and send a BGP reject notification to the peer. Used when you want to explicitly refuse a route while signaling the rejection. |
| modify | Modify route attributes and continue evaluating subsequent filters in the chain. This action allows attribute changes while preserving the ability for later filters to act on the route. |
When configuring actions, consider that drop and reject both prevent routes from being processed, but they differ in their effect on BGP session state. A reject action generates a BGP notification that may cause the peer to log the rejection, while drop silently discards the route without notifying the peer. The modify action is particularly useful when you want to add communities or modify AS-Path before accepting the route, combining attribute manipulation with normal route processing.
Match Conditions
Section titled “Match Conditions”The Filter Wizard provides comprehensive match conditions that examine route attributes to determine which routes a filter applies to. These conditions can be combined using AND logic within a single rule, with multiple rules in a chain evaluated sequentially until a matching rule is found.
Prefix Matching
Section titled “Prefix Matching”Prefix matching examines the network address and prefix length of routes to determine matches. You can specify exact prefixes, prefix ranges, or use prefix lists for more sophisticated matching.
| Property | Value | Description |
|---|---|---|
| prefix | string | Network prefix in CIDR notation, optionally with prefix length matching operators. |
Prefix matching supports several operators: an exact prefix match uses 192.168.0.0/24, matching routes with prefix length within a range uses 192.168.0.0/24{20,28}, and matching routes shorter than a given prefix uses 192.168.0.0/24-. Prefix lists are preferred over inline prefix specifications for complex matching requirements because they can be reused across multiple filters and are easier to manage at scale.
Routing Protocol Matching
Section titled “Routing Protocol Matching”You can filter routes based on their origin or the protocol through which they were learned.
| Property | Value | Description |
|---|---|---|
| protocol | bgp | ospf | connected | static | rip | The routing protocol from which the route was learned. Useful for filtering redistributed routes. |
Protocol matching is particularly important in redistribution scenarios where you want to apply different policies to routes learned from different sources. For example, you might want to filter out specific connected routes before redistributing them into BGP, or prevent certain static routes from being advertised to OSPF neighbors.
Route Type Matching (OSPF)
Section titled “Route Type Matching (OSPF)”OSPF-specific route types can be matched to apply different policies to intra-area, inter-area, and external routes.
| Property | Value | Description |
|---|---|---|
| ospf-type | intra-area | inter-area | external-1 | external-2 | OSPF route type for targeted filtering of external and internal routes. |
OSPF external routes are further divided into type-1 (E1) and type-2 (E2) based on how their metric is calculated. Type-1 routes include both the external cost and the internal cost to the ASBR, while type-2 routes use only the external metric. This distinction matters when you have multiple ASBRs advertising the same prefix and want to prefer routes through a specific path.
Interface Matching
Section titled “Interface Matching”Routes can be filtered based on the interface on which they were received or will be advertised.
| Property | Value | Description |
|---|---|---|
| in-interface | interface name | The input interface for inbound route filtering. |
| out-interface | interface name | The output interface for outbound route filtering. |
Interface matching is useful when you have multiple connections to the same neighbor or want to apply different policies based on the physical path. For example, you might want to accept routes from a primary uplinks interface while being more restrictive about routes received from backup connections.
Common Use Cases
Section titled “Common Use Cases”The Filter Wizard excels at simplifying common routing policy scenarios that network administrators encounter regularly. These use cases demonstrate practical applications of routing filters with step-by-step guidance on configuring them through the wizard.
Filtering Incoming BGP Routes
Section titled “Filtering Incoming BGP Routes”When establishing BGP peering sessions, you often want to filter the routes your neighbor advertises to prevent unwanted routes from entering your routing table. Common reasons include preventing route leakage, blocking RFC 1918 address space, and implementing customer peering policies. Through the wizard, you create a new filter rule, select the appropriate chain for inbound filtering, specify match conditions such as prefix lists or BGP communities, and set the action to either accept or drop based on your policy. The wizard’s prefix list builder helps create the exact prefix matches you need without requiring manual prefix list syntax.
Tagging Outbound Routes with Communities
Section titled “Tagging Outbound Routes with Communities”BGP communities provide a powerful mechanism for signaling routing policy intent to upstream providers or downstream customers. When advertising routes, you may want to tag them with communities that indicate customer type, traffic engineering preferences, or route origin. The wizard makes this straightforward by allowing you to add community attributes as a filter action while continuing to accept the route. You can add multiple communities in a single filter action, and the wizard validates community format to prevent configuration errors. This capability is essential for implementing complex peering agreements that rely on community-based signaling.
Controlling OSPF Route Redistribution
Section titled “Controlling OSPF Route Redistribution”When redistributing routes into OSPF from other sources, you typically want to apply filters that prevent problematic routes from being advertised as OSPF external routes. This includes filtering out multicast addresses, loopback addresses, and very small prefixes that would generate excessive LSAs. The wizard’s OSPF-specific match conditions make it easy to target the right routes, while the action configuration determines whether routes are admitted as external type-1, external type-2, or blocked entirely. You can also modify route metrics during redistribution to implement traffic engineering through OSPF cost adjustment.
Preventing Route Flap instability
Section titled “Preventing Route Flap instability”BGP route flap damping can reduce the impact of unstable routes on your network, but it requires careful configuration to avoid suppressing legitimate route changes. The Filter Wizard provides access to damping parameters including half-life, suppress penalty, and maximum suppress time. By applying damping selectively to specific prefixes or through community-based rules, you can protect your BGP session from flapping neighbors while maintaining normal processing for stable routes. The wizard’s damping configuration screen explains each parameter and provides recommended values based on your network topology.
Essential Commands
Section titled “Essential Commands”The following table provides quick reference to the filter wizard properties and their CLI equivalents for advanced users who need to transition between GUI and command-line configuration.
| Wizard Property | CLI Path | CLI Property |
|---|---|---|
| Chain Name | /routing/filter/rule | chain |
| Action | /routing/filter/rule | action |
| Address Family | /routing/filter/rule | afi |
| BGP AS-Path | /routing/filter/rule | bgp-as-path |
| BGP Community | /routing/filter/rule | bgp-community |
| BGP Ext-Community | /routing/filter/rule | bgp-ext-community |
| Prefix Match | /routing/filter/rule | prefix |
| Protocol Match | /routing/filter/rule | protocol |
| OSPF Type | /routing/filter/rule | ospf-type |
| Interface Match | /routing/filter/rule | in-interface/out-interface |
Troubleshooting
Section titled “Troubleshooting”Filter configuration issues often manifest as unexpected route propagation or routing table contents that differ from your intentions. When filters are not working as expected, begin by verifying that filters are attached to the correct chains and that those chains are referenced by the appropriate BGP or OSPF instances. Use the routing monitor functionality to observe routes as they are processed by filters, watching for the filter chain name to confirm that routes are being evaluated as expected.
Common configuration errors include syntax mistakes in regular expressions for AS-Path matching, incorrect community formats that fail validation, and prefix specifications that match more or fewer routes than intended. The wizard validates basic syntax but cannot detect logical errors such as filters that match all routes and have incorrect actions. When troubleshooting, temporarily simplify filters to minimum configurations and add complexity incrementally while testing after each change.
Filter order problems are particularly insidious because they may produce correct results initially but fail after configuration changes that alter evaluation order. The wizard displays the complete filter chain in evaluation order, making it easy to identify rules that should be reordered. Remember that evaluation stops at the first matching rule, so any filter that accepts all remaining traffic must be the last rule in the chain.
Related Topics
Section titled “Related Topics”- Route Selection and Filters - Overview of routing filter concepts and route selection mechanisms
- Routing Filter - Detailed routing filter configuration including rule syntax and advanced features
- BGP Configuration - BGP protocol configuration including peer setup and attribute control
- OSPF Configuration - OSPF protocol configuration and redistribution settings
- Policy Routing - Advanced routing policy implementation using routing marks and rules
- Routing Protocol Overview - Summary of all routing protocols supported by RouterOS
Additional Resources
Section titled “Additional Resources”- BGP Filter Configuration - Official MikroTik documentation for BGP filtering
- OSPF Routing Filter - Official MikroTik documentation for OSPF filtering
- BGP Communities and Extended Communities - Comprehensive guide to BGP community usage
- Routing Filter Reference - Complete RouterOS routing filter property reference