Manual:Routing/IGMP-Proxy

Summary
Internet Group Management Protocol (IGMP) proxy can be used to implement multicast routing. It
is forwarding IGMP frames and commonly is used when there is no need for more advanced
protocol like PIM.
IGMP proxy features:

The simplest way how to do multicast routing;

Can be used in topologies where PIM-SM is not suitable for some reason;

Takes slightly less resources than PIM-SM;

Ease of configuration.

On the other hand, IGMP proxy is not well suited for complicated multicast routing setups.
Compared to PIM based solutions, IGMP proxy does not support more than one upstream
interface and routing loops are not detected or avoided.
MikroTik RouterOS IGMP proxy supports IGMP version 2 (RFC 2236).

Example
To forward all multicast data coming from ether1 interface to all other interfaces, where
subscribers are connected:

You may also need to configure alternative-subnets on upstream interface - in

case if the multicast sender address is in an IP subnet that is not directly
reachable from from the local router.

/routing igmp-proxy
General configuration.

query-interval (time, 00:00:01 - 01:00:00) : how often to send out IGMP Query messages
over upstream interface

query-response-interval (time, 00:00:01 - 01:00:00) : how long to wait for responses to

an IGMP Query message

quick-leave (yes|no) : specifies action on IGMP Leave message. If quick-leave is on,

then an IGMP Leave message is sent upstream as soon as a leave is received from the first
client on the downstream interface. Use set to yes only in case there is only one subscriber
behind the proxy.

Note: use quick leave only if there is one subscriber behind the proxy

/routing igmp-proxy interface

Used to configure what interfaces will participate as IGMP proxy interfaces on router. If an
interface is not configured as IGMP proxy interface, then all IGMP traffic received on it will be
ignored.

alternative-subnets (list of IP prefixes) : by default, only packets from directly attached

subnets are accepted. This parameter can be used to specify a list of alternative valid packet
source subnets, both for data or IGMP packets. Has effect only on upstream interface.
Should be used when the source of multicast data often is in a different IP network.

interface (interface name) : RouterOS interface

threshold (integer) : minimal TTL; packets received with a lower TTL value are ignored

upstream (yes|no) : interface is called "upstream" if it's in the direction of the root of the
multicast tree. An IGMP forwarding router must have exactly one upstream interface
configured. The upstream interface is used to sent out IGMP membership requests.

/routing igmp-proxy mfc

Multicast forwarding cache (MFC) status.

group (IP address) : IGMP group address

source (IP address) : multicast data originator address

incoming-interface (interface name) : packet stream is coming in router through this

interface

outgoing-interface (interface name) : packet stream is going out of router through this
interface

Static multicast forwarding cache (MFC) entries

Since RouterOS 4.5 MFC is enabled to add static multicast forwarding rules. If a static rule is
added, all dynamic rules for that group will be ignored.
Configuration
These rules will take effect only if IGMP-proxy interfaces are configured (upstream and
downstram interfaces should be set) or these rules wont be active.

downstream-interfaces (list of interfaces) : received stream will be sent out to listed

interfaces only.

group (multicast group address) : multicast stream group address this rule applies should
be set

source (IP address) : IP address we are receiving stream from should be set

upstream-interface (interface) : interface that is receiving stream data should be set

Examples
IGMP-proxy
Will forward stream unconditionally if it comes in from ether1 with set source and will be sent out
to ether2, clients that will try to get stream on interface ether3 will not receive that stream.

MFC static entry

224.10.10.10 group will not be sent at all

Manual:IP/Firewall/Address list
Summary
Firewall address lists allow a user to create lists of IP addresses grouped together under a
common name. Firewall filter, mangle and NAT facilities can then use those address lists to
match packets against them.
The address list records can also be updated dynamically via the action=add-src-toaddress-list or action=add-dst-to-address-list items found
in NAT, Mangle and Filter facilities.

Properties

Example
The following example creates a dynamic address list of people that are connecting to port 23
(telnet) on the router and drops all further traffic from them for 5 minutes. Additionally, the address
list will also contain one static address list entry of 192.0.34.166/32 (www.example.com):

As seen in the output of the last print command, two new dynamic entries appeared in the
address list (marked with a status of 'D'). Hosts with these IP addresses tried to initialize a telnet
session to the router and were then subsequently dropped by the filter rule.

Manual:IP/Firewall/L7
Summary
layer7-protocol is a method of searching for patterns in ICMP/TCP/UDP streams.

L7 matcher collects the first 10 packets of a connection or the first 2KB of a connection and
searches for the pattern in the collected data. If the pattern is not found in the collected data, the
matcher stops inspecting further. Allocated memory is freed and the protocol is considered
as unknown. You should take into account that a lot of connections will significantly increase
memory and CPU usage. To avoid this, add regular firewall matchers to reduce amount of data
passed to layer-7 filters repeatedly.
Additional requirement is that layer7 matcher must see both directions of traffic (incoming and
outgoing). To satisfy this requirement l7 rules should be set in forward chain. If rule is set
in input/prerouting chain then the same rule must be also set inoutput/postrouting chain,
otherwise the collected data may not be complete resulting in an incorrectly matched pattern.
Example L7 patterns compatible with RouterOS can found in l7-filter project page.
You can also download a script with a list of common protocols here (only for RouterOS v3), just
run Import command with this file.

Warning: In some cases when layer 7 regular expression cannot be performed,

RotuerOS will log topic=firewall, warning with an error message stating the problem
in the message

Warning: Layer 7 matcher is case insensitive

Properties

Examples

Simple L7 usage example

First, add Regexp strings to the protocols menu, to define strings you will be looking for. In this
example we will use pattern to match rdp packets.

Then, use the defined protocols in firewall.

As you can see before l7 rule we added several regular rules that will match known traffic thus
reducing memory usage.

L7 in input chain
In this example we will try to match telnet protocol connecting to our router.

Note that we need both directions that is why we need also l7 rule in output chain that sees
outgoing packets.

Youtube Matcher
Note: When user is logged in youtube will use HTTPS, meaning that L7 will not be able to much this traffic.
Only unencrypted HTTP can be matched.

Manual:IP/Firewall/Mangle
Summary
Mangle is a kind of 'marker' that marks packets for future processing with special marks. Many
other facilities in RouterOS make use of these marks, e.g. queue trees, NAT, routing. They
identify a packet based on its mark and process it accordingly. The mangle marks exist only
within the router, they are not transmitted across the network.
Additionally, the mangle facility is used to modify some fields in the IP header, like TOS (DSCP)
and TTL fields.

Properties
Tab

Menu specific commands

Tab

Basic examples

Change MSS
It is a well known fact that VPN links have smaller packet size due to incapsulation overhead. A
large packet with MSS that exceeds the MSS of the VPN link should be fragmented prior to
sending it via that kind of connection. However, if the packet has DF flag set, it cannot be
fragmented and should be discarded. On links that have broken path MTU discovery (PMTUD) it
may lead to a number of problems, including problems with FTP and HTTP data transfer and email services.
In case of link with broken PMTUD, a decrease of the MSS of the packets coming through the
VPN link solves the problem. The following example demonstrates how to decrease the MSS
value via mangle:

Marking packets
Marking each packet is quite resource expensive especially if rule has to match against many
parameters from IP header or address list containing hundreds of entries.
Lets say we want to

mark all tcp packets except tcp/80 and match these packets against first address list

mark all udp packets and match them against second address list.

Setup looks quite simple and probably will work without problems in small networks. Now multiply
count of rules by 10, add few hundred entries in address list, run 100Mbit of traffic over this router
and you will see how rapidly CPU usage is increasing. The reason for such behavior is that each
rule reads IP header of every packet and tries to match collected data against parameters
specified in firewall rule.
Fortunately if connection tracking is enabled, we can use connection marks to optimize our setup.

Now first rule will try to match data from IP header only from first packet of new connection and
add connection mark. Next rule will no longer check IP header for each packet, it will just
compare connection marks resulting in lower CPU consumption.
Additionally passthrough=no was added that helps to reduce CPU consumption even more.