Theory, Laboratories and Exercises For Mikrotik RouterOS

1.
Basic routing
1. Routing classification
2. RouterOS routing components
3. Default route
4. Connected Routes
5. Static routing
6. Labs
7. Summary questions
2. Advanced static routing
1. Types of load balancing
2. Equal Cost Multi Path (ECMP)
3. Administrative distance (distance)
4. Check-gateway-option
5. Routing policies
6. Life time (time to live - TTL)
7. Scope
8. Types of routes
9. Preferred source
3. OSPF: Open Shortest Path First
1. Dynamic routing
2. OSPF
3. OSPF for RouterOS
4. Common problems of an OSPF installation and comparisons
4. BGP: Border Gateway Protocol
1. How BGP works
2. BGP with Mikrotik RouterOS
5. 802.1q
1. The 802.1q standard
2. VLAN on RouterOS
3. RouterOS /32 and IP addresses unnumbered IP
6. Tunnel
1. Virtual Private Network
2. Tunnel
3. IP-in-IP
4. EoIP
5. IPsec
6. IPsec/XAuth
7. MPLS
7. Useful schemes and tables
1. Block diagram of packet flow
2. Differences between Cisco IOS and Mikrotik RouterOS
1. Basic routing
1. Routing classification
2. RouterOS routing components
3. Default route
4. Connected Routes
5. Static routing
6. Labs
2. Advanced static routing
1. Types of load balancing
2. Equal Cost Multi Path (ECMP)
3. Administrative distance (distance)
4. Check-gateway-option
5. Routing policies
6. Life time (time to live - TTL)
7. Scope
8. Types of routes
9. Preferred source
3. OSPF: Open Shortest Path First
1. Dynamic routing
2. OSPF
3. OSPF for RouterOS
4. Common problems of an OSPF installation and comparisons
4. BGP: Border Gateway Protocol
1. How BGP works
2. BGP with Mikrotik RouterOS
5. 802.1q
1. The 802.1q standard
2. VLAN on RouterOS
3. RouterOS /32 and IP addresses unnumbered IP
6. Tunnel
1. Virtual Private Network
2. Tunnel
3. IP-in-IP
4. EoIP
5. IPsec
6. IPsec/XAuth
7. MPLS
7. Useful schemes and tables
1. Block diagram of packet flow
2. Differences between Cisco IOS and Mikrotik RouterOS
After the second edition of the book "Theory, laboratories and exercises for
Mikrotik RouterOS" (actually only in italian language) some readers asked
to extend the work to other key topics of Mikrotik's RouterOS system. This
booklet was born starting from this request and sorting out my notes on
advanced routing, it wants to deepen the main themes of routing through the
lens of the RouterOS system exploration used in Mikrotik products. At the
same time, this book aims to be a concrete preparation for the Mikrotik
Certified Routing Engineer (MTCRE) exam even through the analysis of
real cases in which advanced routing is a fundamental and decisive tool. If
you want you can tweet tagging @vittore. Due to the complexity of the
topics I had to left out some guidelines that had helped me in the first book:
in almost all the laboratories of this book more than one router is needed
and the laboratories are not located at the end of each chapter but have been
moved in useful points to reinforce the knowledge just acquired.
This text is a work-in-progress. All suggestions are welcome. If you have
directions, write to [email protected] . A special thanks goes to my
colleagues who have sacrificed themselves in trying all the exercises.
Basic routing
«Second star to the right, ...and straight on till morning!» Edoardo Bennato
Routing is the basis of the network functionality implemented by level 3

entities (OSI) and allows two nodes A and B, not directly connected, to
communicate each other through the collaboration of other nodes placed on
a path in the network that connects A and B.
Routing.
The task of the network layer is therefore the transmission of packets
between two arbitrary hosts, which in general are not directly connected,
that is they do not have a direct connection between them. In the ISO / OSI
model, the network layer software is present in all the nodes of the network,
while that of the higher levels is present only in the terminal nodes. In
detail, the functions of the network layer are:
Forwarding , or receiving a packet on a port, storing it and re-

transmitting it on another.
This function is present in all the nodes of the network and can involve
the use of different connection level protocols.
Fragmentation: if a received packet is too large for the network on
which it is to be transmitted, the network layer divides it into
fragments and takes care of reassembling the received fragments at the
time of delivery.
Routing: to determine the path for data transmission over the network.
In most cases this function is dynamically performed using special
algorithms, which analyze network conditions, routing tables, service
priority and other secondary elements.
Congestion control: to have the possibility of giving a higher priority
to the most critical data.
Purpose of routing: connecting networks.
Routing is necessary when the network starts to become complex; If we
want:
to be able to monitor and better manage the network;

make the network more secure as firewall filters become simpler and
more complete;
to improve performance by concentrating broadcast traffic only in each
subnet / network;
to connect together public IP networks;
to connect different Wide Area Netwok (company, provider, ...).
The principle on which IP routing is based is very simple: send packets on

the shortest path to the destination. The calculation is performed in a
distributed way by the routers through an exchange of information among
them; in the table of each router possesses and it is indicated the direction
the packet must take, only the next router on the path (next hop) is
indicated, not the entire path. This approach exploits the property of graphs
according to which even the sub-paths of a minimum path are minimal.
Routing classification
Routing, ie the process for forwarding packets from a network to other
networks can be done using:
Static routing - In this case the administrators perform the routing

manually defining each network and its destination gateway and
repeating this operation for each router present in all the connected
networks.
Dynamic routing - In this case the administrators make only a simple
configuration in which the dynamic routing function is enabled on
each router and the routers automatically search for the routes and the
best gateway from all the connected networks.
Classification of dynamic routing protocols

routing-protocols
RouterOS routing components

The router keeps the routing information in two separate spaces:
RIB (Routing Information Base) - is the routing table

FIB (Forwarding Information Base) - is the forwarding table
Router Information Base (RIB)
rib The routing table is a table of data that in a specific router lists all the
known routes to certain networks. For each route the metric that represents
the cost that is spent along this route is indicated. The routing table consists
of:
all routes collected by dynamic routing protocols;

all paths for the connected networks, that is for the interfaces directly
connected to the router;
each additional route manually added (static routes).
In RouterOS the routing table can be displayed using menu IP > Route >
List .
Routing table (RIB)

The routing table is used:
to filter the routing information of all routing protocol types;

to calculate and choose the best route for a certain network;
to create and update the forwarding table (see section fib );
to distribute routing information using dynamic routing protocols.
For each entry in the routing table there are letters indicating the route
status according to the abbreviations shown in the table table:route-flag :
Labe
Property Description
l
disabled X The route is disabled ie it is not used.
active A The route is used to forward packets.
dynamic D The route was created by the software automatically.
It will not be exported and cannot be modified
directly.
connected C Connected route.
statica S Static Route.
rip r Created through the RIP protocol.
bgp b Created through the BGP protocol.
ospf o Created through the OSPF protocol.
mme m Created through the MME protocol.
blackhole B Do not consider packets addressed to this route and
do not notify anyone of the action.
unreachabl
U Do not consider packages addressed to this route but
e
notify the situation with an ICMP message.
prohibited P Do not consider packets addressed to this route but
notify the situation with an ICMP message.
Labels that can be associated with a route
table:route-fla g
Forwarding Information Base (FIB)
fib Routing tables (RIB) are generally not used directly for packet
forwarding; the data present in the RIB are used to generate smaller and
specific tables called forwarding tables: Forwarding Information Base
(FIB). A forwarding table contains only the path selected by the routing
algorithm to continue routing the packet to its destination. This path is often
in the form of a cache in compressed or precompiled format, in a format
optimized for archiving and searching for the specific hardware of the
router. In Cisco devices this component is called Cisco Express Forwarding
(CEF). Then the forwarding table:
is the product of the routing table after it has been filtered;

it's a cached copy;
all active routes are in the main table;
if routing markings are not used all default routes will be in main (see
below to understand this step)
there is only one hidden implicit rule ("catch all" rule) that uses the
main table for all target searches.
How RIB and FIB tables are used
FIB uses the following package information to determine its destination:
sourcing address,
destination address,
source interface,
possible marking of routing,
ToS (type of service) - field currently not used by the IPv4 protocol -
not used by RouterOS in the routing rules, but part of the search key in
the routing cache.
The possible routing decisions are:
receive packet locally

discard the packet (silently or by sending an ICMP message to the
sender of the packet)
send the packet to a specific IP address on a specific interface
The results of the routing decision are remembered in the routing cache
(FIB) to improve forwarding performance. When another packet with the
same source address, destination address, source interface, routing mark
and ToS is routed, the cached results are used. This also allows the
implementation of load balancing by connection (per-connection load
balancing) via ECMP routes, since the values used to look up the entry in
the routing cache are the same for all the packets belonging to the same
connection and going in the same direction.
Forwarding Information Base (FIB)
If there is no routing entry in the cache for a packet then this is created by
executing a routing decision according to the following process:
it is checked whether the package should be delivered locally (the

destination address is the router address),
implicit routing rules are processed,
routing rules added by the user are processed,
implicit catch-all rule that searches for the destination in the main
routing table is processed
if all the previous steps fail then the return result is "unreachable
network".
Rules that do not match the current packet are ignored. If the rule has a drop
or unreachable action then this is returned as a result of the routing decision
process. If the action is the search, the destination address of the packet is
searched for in the routing table specified in the rule. If search fails (there is
no route that matches the destination address of the packet), then the FIB
proceeds to the next rule. Otherwise:
if the path type is blackhole, prohibited or unreachable, then it returns

this action as a result of the routing decision;
if it is a connected route or a route that has indicated an interface as a
gateway value, then it returns this interface and the destination address
of the packet as a result of the routing decision;
if this route has the IP address as the gateway value, then it returns this
address and the associated interface as a result of the routing decision;
if this route has more than one value of nexthop, then it returns one of
them in round robin mode.
The result of this routing decision is stored in the new routing cache entry.
Notice how a routing decision is returned from the indicated process which
can be:
IP address of nexthop interface

point-to-point interface
local delivery
to discard
ICMP prohibite d
ICMP unreachable host
ICMP network unreachable
Interoperability between RIB and FIB
Default route
The route with destination address 0.0.0.0/0 applies to all destination
addresses. This path is called the default route and indicated router is called
the default gateway. If the routing table contains an active default route then
the routing table search will always be successful. To use an analogy is like
traveling in a city and finding a road sign indicating "all directions".
Connected Routes
Connected routes are automatically created for each IP network that has at
least one interface connected to it (as specified in the IP address
configuration). RIB keeps track of the status of the connected routes but
does not change them. For each connected route there is an ip address so
that:
the dst-address network of the connected route is equal to the network

of the ip address
the netmask of the dst-address of the connected route is equal to the
netmask of the ip address
the pref-src of the connected route is the same as the ip address
the interface of the connected route is the same as the interface
Correspondence between addresses and connected routes.
We saw that every time we add an IP address on a valid interface (active
interface) a connected route is automatically created. It should be noted
that if there are two IP addresses coming from the same subnet and from
the same interface there will be only one path connected. For this it is
important not to place two IP addresses of the same subnet on two different
interfaces, because it will confuse the RIB. For the same reason it is
suggested that if an interface has multiple IP addresses on the same subnet,
only the first address is indicated with the complete netmask while the
others will be indicated with the netmask / 32.
As described at the beginning of the chapter in MikroTik RouterOS
dynamic routes and static routes are possible. The former are created
automatically when an IP address is added to an interface or through
routing information obtained from specific protocols such as RIP, OSPF and
BGP. Static routes are routing information entered manually by the user
(network administrator) to define a specific route. The default route is an
example of a static route.
Static routing
Static routes are added by creating an entry in the RIB and defining a static
route to route packets. The destination network and router (gateway) to be
used for this destination is indicated. The gateway can be:
IP address,
the interface.
Remember that if Dst-address indicates 0.0.0.0/0, all IPs on the internet are
included and a default route is created.
Adding a static route

The following parameters are available when adding a static route:
destination;
destination address and netmask;
0.0.0.0/0 if it is a default route.
gateway:
the IP address of the gateway, must be the IP address of a subnet
with IP installed on one of the router interfaces;
the gateway in the form of an interface: it is used when the IP
gateway is unknown or is dynamic, for example in the case of a
point-to-point or serial connection.
pref source:
the source IP address of the packet that will leave the router,
usually it is the IP address installed on the interface where the
gateway is located.
distance:
it is used for route calculation and route selection;
value is between 0 and 255
by default the value is decided on the routing protocol used:
connected routes: 0
static routes: 1
eBGP: 20
OSPF: 110
RIP: 120
MME: 130
iBGP: 200
note that a distance of 255 means "rejected".
scope and target scope:
used for nexthop recursive lookup (see section scope on page
scope ).
Labs
Before carrying out the following laboratories make sure you have
answered correctly to the summary questions on the page domande-1 .
Static routing - guided
Simple static routing

This laboratory allows you to recreate the network infrastructure of figure
routing-statico-semplice and to verify the correctness of your answers.
target
1. restore factory router configuration (without default);

2. connect the laptops between the participants based on the topology
above;
3. enter the following configuration in router R1:
{R1}
/ip address
add address=10.10.20.1/24 interface=ether1
network=10.10.20.0
network=10.10.10.0
network=11.11.11.0
/ip route add distance=1 dst-address=0.0.0.0/0
gateway=11.11.11.1
/system identity set name=R1
4. enter the following configuration in router R2:

{R2}
/ip address
network=11.11.11.0
network=22.22.22.0
/ip route
add distance=1 dst-address=0.0.0.0/0 gateway=22.22.22.2
The laboratory is correctly executed if it is possible to ping between the two

laptops and both can reach the 22.22.22.2 interface with the ping command.
Static routing - without help
Simple static routing

This laboratory allows you to recreate the network infrastructure of figure
routing-statico-semplice-2 without help.
Network with static routing
routing-statico-semplice-2
Run the following operations independently:
1. restore router configuration (without default);

2. connect the laptops between the participants based on the topology
above;
3. performs static routing on each router as shown in the diagram.
The lab runs correctly if you can ping the three laptops.
Labs solutions
{R1}
/ip address
add address=192.168.1.1/24 interface=ether1 network=192.168.1.0
/ip route
{R2}
/ip address
/ip route
{R3}
/ip address
/ip route
Summary questions
domande-1
1. The default distance value for a static route is:

1. 255
2. 1
3. 10
4. 0
2. The following routes are present in the routing table:
0 dst=192.168.1.0/24 gateway=192.168.1.1
1 dst=192.168.1.0/25 gateway=192.168.1.2
Which gateway will be used to reach the 192.168.1.5 ip?

1. Both, half of the traffic through 192.168.1.1 and the other half
through 192.168.1.1
2. Through 192.168.1.1
3. Through 192.168.1.2
4. The required route is not present in the routing table
3. The default distance value for a connected route is:
1. 255
2. 1
3. 10
4. 0
4. Can a route have the D and S flags at the same time?
1. Yes
2. No
5. Can a route have the A, C and S flags at the same time?
1. Yes
2. No
6. The following routes are present in the routing table:
0 dst=192.168.1.0/24 gateway=192.168.1.1 distance=10
1 dst=192.168.1.0/25 gateway=192.168.1.2 distance=20
Which gateway will be used to reach the 192.168.1.5 ip?

1. Both, half of the traffic through 192.168.1.1 and the other half
through 192.168.1.1
2. Through 192.168.1.1
3. Through 192.168.1.2
4. None because the distance is >= 10
7. Remembering that the gateway routers must always be in the subnet of
an IP interface of the router to answer the following questions with
reference to figure routing-statico-semplice :
Network with static routing

routing-statico-semplice
1. On laptop A, what is the IP gateway on the 11.11.11.0/24
network?
2. On laptop A, what is the IP gateway for the network is
22.22.22.0/24?
3. On laptop A, what is the IP of the default gateway?
4. In R1, what is the IP gateway on the 22.22.22.0/24 network?
5. In R1, what is the IP of the default gateway?
6. On R2, what IP gateways need to be set up to reach laptop
networks?
Solutions
Advanced static routing
«Friend, from there on sooner or later somewhere we will come» Jovanotti
One of the peculiarities of the TCP/IP protocol and specifically of IP

routing is the ability to route packets on different routes in order to divide
the load and make the structure tolerant to failures. We talk about load
balancing when distributing workloads over two or more network
connections to maximize throughput, minimize response time and avoid
overloading. We talk about fail over when redundancy is added to paths to
maintain the connection even when the main connection is interrupted: for
example, if the first link is interrupted, the backup path on the second or
third link will be automatically enabled.
Types of load balancing

RouterOS provides different methods for load balancing:
load balancing per packet:

load division based on the packet (packet 1 through the gateway
a, packet 2 through the gateway b);
use of the Mikrotik function called interface bonding ;
load balancing per connection:
load distribution based on the connection such as connection 1 via
gateway a, and connection 2 via gateway b;
use of the Mikrotik function called NTH (see
http://bit.ly/2VGGx9t );
load balancing by address pair on the single connection:
ECMP and PCC (Peer Connection Classified) functions ;
traffic selection based on connection and source and destination
IP address from the connection itself;
custom load balancing.
Equal Cost Multi Path (ECMP)

The Equal Cost Multi Path technique, literally "multiple paths of equal
cost", allows the router to have more than one gateway for the same
destination network. Each gateway entered in this context will be selected
according to a round-robin algorithm based on the source and destination
address pair. Note that the same gateway can be repeated several times. In
order to configure correctly the ECMP load balancing it is necessary to
insert the routes as shown in fig ecmp-add-routes and also if the router uses
a src-NAT masquerade to the outside it is important to remember to set the
masquerade on all the interfaces involved in the balanced routing as in
figure ecmp-add-masquerade . With ECMP all reachable nexthop gateways
are copied to the FIB and used for packets forwarding.
ECMP - step 1
ecmp-add-routes
ECMP - step 2
ecmp-add-masquerade
Lab
ecmp
Three routers and two PCs are required for this laboratory.
ECMP
The objective of this laboratory is to understand how to add static routes
that have the same destination but different gateways in order to achieve a
simple balancing of the ECMP type output load. The objective is to carry
out the configuration of figure ecmp-lab1 . Specifically, the two PCs must
be able to surf the internet using the two routers R2 and R3, a situation that
can be verified using the trace command performed by the two PCs.
ECMP - lab
ecmp-lab1
1. Once connected the routers and the PCs as in figure ecmp-lab1

proceed with the loading of the following configurations; pay
particular attention to the configuration of the R1 router.
The configurations are shown in the order in which they have to be
performed.
{R2}
/ip address
network=192.168.12.0
/ip dhcp-client add disabled=no interface=ether1
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
{R3}
/ip address
network=192.168.13.0
/ip firewall nat
{R1}
/interface bridge add fast-forward=no name=bridge-lan
/interface bridge port
add bridge=bridge-lan interface=ether1
/ip address
network=192.168.12.0
network=192.168.13.0
add address=192.168.1.1/24 interface=bridge-lan
network=192.168.1.0
/ip pool add name=lan ranges=192.168.1.100-192.168.1.200
/ip dhcp-server
add address-pool=lan disabled=no interface=bridge-lan
name=lan
/ip dhcp-server network
add address=192.168.1.0/24 dns-server=8.8.8.8
gateway=192.168.1.1 \
netmask=24
#
# Relevant part for this laboratory
#
/ip firewall nat
/ip route add distance=1 gateway=192.168.13.3,192.168.12.2
2. From the first PC execute the command ping 8.8.8.8 and then
analyze the result of the command trace 8.8.8.8 (or tracert, or
traceroute depending on the platform used).
Note the address of the second router passed to reach the server
8.8.8.8.
PC-1> ip dhcp
IP 192.168.1.199/24 GW 192.168.1.1
PC-1> ping 8.8.8.8

84 bytes from 8.8.8.8 icmp_seq=1 ttl=57 time=29.995
ms
ms
ms
ms
PC-1> trace 8.8.8.8

trace to 8.8.8.8, 8 hops max, press Ctrl+C to stop
1 192.168.1.1 7.092 ms 1.321 ms 0.351 ms
2 192.168.12.2 12.790 ms 1.035 ms 1.095 ms
3. From the second PC run the command ping 8.8.8.8 and then analyze
the result of the command trace 8.8.8.8 (or tracert, or traceroute
depending on the platform used).
Note the address of the second router passed to reach the server
8.8.8.8.
PC-2> ip dhcp
IP 192.168.1.198/24 GW 192.168.1.1
PC-2> ping 8.8.8.8

ms
ms
ms
ms
PC-2> trace 8.8.8.8

trace to 8.8.8.8, 8 hops max, press Ctrl+C to stop
1 192.168.1.1 0.513 ms 0.215 ms 0.298 ms
2 192.168.13.3 1.923 ms 0.655 ms 0.556 ms
ecmp-domanda Application for further information. \\ The laboratory
could have been simplified, that is if we had used only one PC could we
have noticed the use of the two balanced routes? Answer. \\ No. Because
the results of the routing decision are cached, packets with the same source
address, destination address, source interface, routing markup, and ToS are
always sent to the same gateway. This means that one connection will use a
single link in each direction since ECMP routes implement load balancing
by connection. If it is necessary to achieve load balancing by packet and
not by connection, see the technique called interface bonding . So to notice
the effect of this type of balancing you need to have connections that are
distinguished by source address or destination address or source interface
or routing marking or ToS.
Application for further information. \\ What happens if one of the
gateways stops working? Is PC connection to the internet still working?
If the gateways have different traffic capacities it is possible to set the same
gateway several times for the same destination. For example if there are two
gateways and the link A has a capacity of 64k and the Link B has a capacity
of 32k we can proceed with the following calculation: We calculate the
proportions of the communication channels: 64k:32k=2:1 We calculate the
total of the communication channel: A+B=3 Three gateways will be
indicated, twice the gateway A link and once the gateway B link will be
indicated.
Administrative distance (distance)

The administrative distance (distance ) is used to choose the best route
when there are two or more different routes or there are different routing
protocols towards the same destination. The distance value is a value that
can be set from 0 to 255. If the distance value is not set then it is determined
based on the routing protocol:
Distanc
Type of route
e
Connected routes 0
Static Routes 1
eBGP 20
OSPF 110
RIP 120
MME 130
iBGP 200
The smaller distances will have priority in the selection of routing tables.
Lab
distance
Distance
The aim of this workshop is to understand how the distance value affects
the selection of the active route.
1. Start from the diagram and the configurations of ecmp laboratory.

2. Remove from the R1 router ECMP route.
{R1}
/ip route add distance=1 gateway=192.168.13.3,192.168.12.2
3. Add to R1 these routes:

{R1}
/ip route add distance=1 gateway=192.168.12.2
/ip route add distance=2 gateway=192.168.13.3
4. From the two PCs the output paths are analyzed with the command
trace or equivalent.
5. Disconnect the cable that connect router R1 to router R2.
6. From the two PCs the output paths are analyzed with the command
trace or equivalent.
"Check-gateway" option
check-gateway RouterOS provides a gateway control mechanism that runs
in the background. Periodically (every 10 seconds) the gateway is checked
by sending an ICMP echo request (ping) or an ARP request (arp); if no
response is received from the gateway within 10 seconds, the request
expires (timeout). After two timeouts the gateway is considered
unreachable. Vice versa, for a gateway considered unreachable, after
receiving a reply again, the gateway is considered reachable and the timeout
counter is restored.
It is important to note that if the Check-Gateway function is activated for a
route then all routes with the same gateway will undergo the same control.
Lab
check-gateway
Check-gateway
The objective of this laboratory is to understand how the control
mechanism of the router vitality (check-gateway) affects the selection of
the active route.
1. Start from the scheme and configurations of the distance laboratory.

2. On router R1 modify route by adding the Check-Gateway method
indicated as shown in the figure:
Check-Gateway
3. Check that the routes are correct:
Active route with two reachable routers.

4. From the two PCs analyze the output paths with the command trace
or equivalent.
5. Disconnect the cable connecting the R1 router with the R2 router.
6. Wait at least 20 seconds.
7. From the two PCs analyze the output paths with the command trace
or equivalent.
8. On R1 check that the routes are correct:
Active route with router R1 not reachable.

9. Compare the active route before and after removing the connection
cable.
Routing policies
When the decision to forward the package uses additional information, such
as the source address of the package, it is called a "routing policy". The
routing policy is implemented through lists from which the different routing
tables are selected based on destination address, source address, source
interface and a possible routing marking. To do this it is necessary to mark
the traffic and then assign it to a specific routing table. The package
marking for a specific routing table is managed by the firewall (IP >
Firewall > Mangle ) and can concern the single packet or the entire
connection. For performance reasons we prefer to mark the first packet of a
connection and then mark the entire connection accordingly: in this way the
firewall will use a smaller amount of CPU for management. The second
step for a routing policy is the creation of specific routing tables for heavy
traffic. By default, the router uses the main routing table but you can create
additional routing tables and configure the router to use a specific table. To
do this you can act on two sides:
1. IP > Route > Rules

2. IP > Firewall > Mangle > Route-mark
Using IP > Route > Rules you can specify the use of a routing table based
on some parameters (see figure policy-routing-rule ) such as:
destination address,
marking the route in the package,
destination interface.
Adding a rule in routing policy

policy-routing-rule
Routes can be assigned to a specific routing table by setting the routing-
mark property of the individual route with the name of the routing table.
Note that the routing tables have their name as a reference for use and are
automatically created when there is some reference to them in the
configuration: for example if you create a marking rule (IP > Firewall >
Mangle ) that refers to the marking of the "ISP3" route then in the routes
(IP > Routes ) you will find the reference to the ISP3 routing table.
Routing mark
Routing marking takes place using what is available in the window that can
be accessed via the IP > Firewall > Mangle menu. To drive more specific
traffic through a route, it must be identified before it goes through the
routing process. In the appendix, on page packet-flow , it is schematized
how packets pass through RouterOS. To achieve this we need to act at
different points depending on the type of traffic we want to intercept and
mark:
for the traffic that passes through the router the prerouting chain is
used;
for the traffic coming from the router and out of the router the output
chain is used;
You need to be very careful at this stage because each packet can only have
one routing sign. Furthermore, if there is at least one route that uses the
routing mark for a specific traffic then the main routing table will be
ignored.
Lab
Routing mark
The objective of this laboratory is to understand how the routing marking
mechanism works: ICMP traffic will have to use R3 router while the
remaining traffic will have to pass through R2 router.
Routing mark - lab
ecmp-lab-routing-mark
To better analyze the effect of this configuration we have to use to a small
stratagem that we will later use also for other laboratories of this text. Two
routers connected to internet will be used but with queues that reduce the
available bandwidth to very low values (1k) in order to immediately detect
the desired effect. Probably that it is necessary to modify the value 1 k with
a higher value (32k or 64k) in the case in which on the PCs from which the
test is performed there is background traffic (updates of windows,
Dropbox, ...).
1. Once connected the routers and the PCs as in figure ecmp-lab-routing-

mark proceed with the loading of the following starting configurations.
For logical and operational simplicity, the configurations of the two R2
and R3 routers used as laboratory controls are loaded first. {R2}
/ip address
network=192.168.12.0
/ip firewall nat
#
# Setting the queue with 1k / 1k limitation
#
/queue simple add target=0.0.0.0/0 max-limit=1k/1k
{R3}
/ip address
network=192.168.13.0
/ip firewall nat
#
# Setting the queue with 1k / 1k limitation
#
/queue simple add target=0.0.0.0/0 max-limit=1k/1k
{R1}
/interface bridge add fast-forward=no name=bridge-lan
/ip address
network=192.168.12.0
network=192.168.13.0
add address=192.168.1.1/24 interface=bridge-lan
network=192.168.1.0
/ip pool add name=lan ranges=192.168.1.100-192.168.1.200
/ip dhcp-server
add address-pool=lan disabled=no interface=bridge-lan
name=lan
add address=192.168.1.0/24 dns-server=8.8.8.8
gateway=192.168.1.1 \
netmask=24
/ip firewall nat
2. Before proceeding, check the correct queues set operation. For this
reason, from one of the two PCs, generate internet traffic (http, https,
ftp, ...) and check that the queue of the R2 router goes from green to
red in Queue > Simple .
Queue limited to 1k / 1k with no traffic passing through the R2 router
Queue limited to 1k / 1k with traffic passing through the R2 router

3. Now we will only act on the R1 router, the following indications refer
to this router if not explicitly specified.
In IP > Firewall > Mangle we add the routing marking for ICMP
packets:
Routing marking for ICMP packets

4. We add the two routes:
Routes to add on R1
Final routing result
5. On one of the two PCs generate ICMP traffic using the ping 8.8.8.8
command.
It is suggested to generate traffic using both PCs or use the command
options to generate a flow greater than 1kbps, for example with ping
8.8.8.8 -l 1000 -t .
6. Notice how ICMP traffic flows through router R3 (see queue status)
while the remaining traffic, for example http, flows through router R2.
Real case
Bill has a Mikrotik router with an ADSL line provided by the ISP1 provider
that connects the clients of his network to internet. Bill adds a second
ADSL line with ISP2 provider and wants this to be only for some specific
users, VIPs who are paying a little extra money for better speed, as the
current connection with ISP1 is clogged by the traffic of others users.
Solution
The solution use the following logic:
1. Two lists of IP addresses are created and the IPs of the VIP or
NORMAL users are added.
2. Two traffic marking rules (mangle) are added to mark the packets
generated by VIP and NORMAL users.
3. Two default routes are specified with the appropriate routing marks
and gateways.
4. Add the NAT rules.
# Adding IP addresses on interfaces
#
/ip address
add address=192.168.2.1/24 disabled=no interface=LAN
network=192.168.2.0
add address=192.168.5.1/24 disabled=no interface=WAN1

network=192.168.5.0
add address=192.168.6.1/24 disabled=no interface=WAN2
network=192.168.6.0
# Creation of two address lists

# In this case we add only
# an address for each list
#
/ip firewall address-list
add address=192.168.2.6 disabled=no list=VIP_USERS_LIST
add address=192.168.2.7 disabled=no list=NORMAL_USERS_LIST
# Marking of traffic coming from specific addresses

#
/ip firewall mangle
add action=mark-routing chain=prerouting new-routing-
mark=wan1_user \
passthrough=no src-address-list=VIP_USERS_LIST
add action=mark-routing chain=prerouting new-routing-
mark=wan2_user \
passthrough=no src-address-list=NORMAL_USERS_LIST
# Creation of marked traffic routes

#
/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 \
gateway=192.168.5.2 routing-mark=wan1_user scope=30 target-
scope=10
add disabled=no distance=2 dst-address=0.0.0.0/0 \
gateway=192.168.6.2 routing-mark=wan2_user scope=30 target-
scope=10
# NAT for Internet access

#
/ip firewall nat
add action=masquerade chain=srcnat disabled=no src-
address=192.168.2.0/24
For more details see the article https://goo.gl/uDx2Dy .

Life time (time to live - TTL)
TTL is a field in the IP header of the data packet that establishes how long
the packet can circulate on the network. The value of this field will warn the
router if the packet should be forwarded to the next router (router nexthop)
or discarded. The default TTL value is 64 (8 bits) and is reduced by one
each time a router is crossed, just before the decision to forward the packet.
The router will not advance the packet if received TTL is 1 (see figure ttl ).
Using the TTL in the ICMP

ttl
The usefulness of this function becomes evident if you imagine a situation
in which a loop in a router chain is created by mistake or failure. The TTL
can also be used to determine the number of routers a packet goes through.
For example, the traceroute command, present in many operating systems,
uses TTL to determine approximately the path between two hosts. First a
packet with TTL = 1 is sent to the destination host: this packet is obviously
discarded by the first router, which signals its coordinates to the sender with
the ICMP message. Subsequently a packet with TTL = 2 is sent, which is
discarded by the second router that is thus identified. The operation is
repeated until the destination host is reached.
Scope
scope The check gateway mechanism, described in section check-gateway
on page check-gateway , can detect connection problems only in the nearest
router. If the problem occurs after the nearest gateway, the gateway check
cannot detect it. To overcome this drawback and to efficiently select the
next router to which to forward the traffic, techniques can be used that
define the scope (scope) of the routing itself. The search for the nexthop is
part of the path selection process: the routes installed in the FIB must have
an interface associated with each gateway address, in this way the gateway
address is directly accessible via this interface. The expression recursive
search of the nexthop means the search for the gateway and the interface to
use to follow the route even if there is a gateway not directly connected to
the router. This is due to the fact that some routes (eg IBGP) may have a
gateway address that is located at different hops from this router. To install
these paths in the FIB it is necessary to find the address of the gateway that
can be reached directly (an immediate nexthop), which will be used to reach
the gateway address of this route.
The search for nexthop is performed only in the main routing table even
for routes with a different routing marking.
During this search it is necessary to limit the series of paths that can be used
to search for immediate nexthops; this result is obtained using the scope and
target-scope properties.
Routes that have the interface name as a gateway value are not used
for nexthop search.
If the route has both an interface and an active IP address nexthop then
the nexthop with the interface is ignored.
Routes with scopes greater than the maximum accepted value are not
used for the nexthop search: in fact each route specifies the maximum
scope value accepted for its nexthops in the target-scope property. The
default value of this property allows the search for nexthop only
through connected paths, with the exception of iBGP routes which
have a wider default value and can therefore search for nexthop also
via iBGP and static routes. For the scope and target scope defaults, see
figure default-scope-target-scope .
Scope and target scope default values

default-scope-target-scope
In summary the interface and the immediate nexthop are selected based on
the result of the nexthop search with the following logic:
If the most specific active route detected finds a connected route, then
the interface of this connected route is used as a nexthop interface and
this gateway is marked as reachable.
Since the gateway is directly reachable through this interface (which is
exactly what connected route means) then the gateway address is used
as an immediate nexthop address.
If the most specific identified active path finds that nexthop has
already been resolved, the immediate nexthop address and interface
are copied from that nexthop and this gateway is marked as recursive.
If the most specific detected active route finds an ECMP route then the
first unreachable of that route is used gateway.
If the search finds no route then this gateway is marked as unreachable
.
Example
Simple resolution of recursive nexthop - step 1

simple-nexthop-lookup-step-1
Simple resolution of recursive nexthop - step 2

simple-nexthop-lookup-step-2
Nexthop 10.2.0.1 is resolved through a connected route, the state is

reachable (figure simple-nexthop-lookup-step-1 );
Nexthop 10.3.0.1 is resolved recursively through a route 10.3.0.0/16
(figure simple-nexthop-lookup-step-2 );
Recursive state is set and uses 10.2.0.1 as an immediate nexthop value
installed in the FIB.
Carefully analyzing figure default-scope-target-scope we see how the path

can respond to nexthop only through another route that has a range less than
or equal to the target scope, ie the maximum accepted scope value. This
mechanism can be used:
to monitor, through the ping command, a gateway that is not directly

connected to the router;
combined with iBGP (on this we will return later talking about the
BGP protocol and its two variants iBGP and eBGP).
Real case
Suppose we have several WAN links and we want to monitor if the internet
is accessible through each one. The problem can be anywhere. If the ADSL
modem does not work, check-gateway with ping is clearly the solution (and
no problem); but what happens if the modem is active and the telephone
line is not working? Or if one of the ISPs has a problem in it, then
traceroute only shows a few hops - and then it stops ... Some people use the
NetWatch tool to monitor remote locations; others use scripts to ping
remote hosts periodically and consequently disable routes or in some other
way modify routing behavior. But the RouterOS features allow us to have a
solution to these problems only by using \ip routes , no scripting and
netwatch.
Example
Suppose we have two uplinks GW1 and GW2 . These can be the ADSL
modem address (like 192.168.1.1 and 192.168.2.1) or PPP interface
addresses (like pppoe-out1 and pptp-out1). Then we have some routing
rules that for example specify that all outgoing traffic is marked with the
marks ISP1 (which goes to GW1) and ISP2 (which goes to GW2). What
interests us is to monitor host1 via GW1 and host2 via GW2; where host1
and host2 can be some popular Internet sites, like Google, Yahoo, etc. First
of all, routes are created for these hosts via the corresponding GW1
gateway using a scope = 10:
/ip route
add dst-address=Host1 gateway=GW1 scope=10
These paths will be resolved recursively and will be active only if host N is
reachable by ping. Similarly, routes are created for these hosts via the
corresponding GW2 gateway using a scope = 10:
/ip route
For more details on this technique, see the article https://goo.gl/mYofKP .

We can simplify by stating that the scope and the target-scope can be used
to change the result in the resolution of the nexthop; in fact we remember
that normally nexthops can be solved only through the routes that are on the
link. The ability to set both the scope and the target-scope of nexthops is a
powerful function and as such can be easily abused. It is possible to create
loops in the resolution of the nexthop. If a logical cycle occurs in the
routing table, RouterOS will not hang, but will simply stop to eventually
solve the problem later. Here is the example of a simple loop with three
unconnected routes that resolve each other:
/ip route add
dst-address=1.1.1.0/24 gateway=2.2.2.2 scope=10 target-
scope=10
scope=10
scope=10
which produces the following situation:

[admin@R3] > /ip route print
Flags: X - disabled, A - active, D - dynamic,
C - connect, S - static, r - rip, b - bgp, o - ospf,
B - blackhole, U - unreachable, P - prohibit
# DST-ADDRESS PREF-SRC G
GATEWAY DISTANCE
IN
TERFACE
0 S 1.1.1.0/24 2.2.2.2 1
1 S 2.2.2.0/24 3.3.3.3 1
2 S 3.3.3.0/24 1.1.1.1 1
Types of routes
There are types of routes that are used to block the network or a destination
address with different behaviors:
Blackhole: it blocks and does not inform anyone of the operation.

Prohibit: it blocks and sends a prohibited ICMP administrative error
message (type 3 code 13).
Unreachable: it blocks and sends error messages of the unreachable
ICMP host (type 3 code 1).
Lab
Tipi di rotte
The aim of this workshop is to understand the use of different types of
routes.
Types of routes - lab

route-type-lab
1. Once connected the routers and the PCs as in figure route-type-lab
proceed with the loading of the following configurations:
{R1}
/ip address add address=192.168.1.1/24 interface=ether1
/ip route
add dst-address=192.168.3.0/24 gateway=12.12.12.2
{R2}
/ip route
add distance=1 dst-address=192.168.1.0/24
gateway=12.12.12.1
gateway=23.23.23.3
{R3}
/ip route
gateway=23.23.23.2
2. Assign the respective static ip addresses indicated in figure route-type-

lab to the two PCs.
3. From the first PC execute the command ping 192.168.3.2 and then
analyze the result of the command.
4. In router R2 change the type of route as follows and after each change
repeat the previous ping analyzed the result of the command:
{R2}
/ip route add
# Second test
dst-address=192.168.3.0/24 gateway=23.23.23.3
type=blackhole
# Third test
dst-address=192.168.3.0/24 gateway=23.23.23.3 route-
type=prohibit
# First test
dst-address=192.168.3.0/24 gateway=23.23.23.3 route-
type=unreachable
Using route:
{R2}
/ip route add dst-address=192.168.3.0/24
gateway=23.23.23.3
You get:
PC-1> ping 192.168.3.2
ms
ms
ms
ms
ms
Using route:
{R2}
/ip route add dst-address=192.168.3.0/24 type=blackhole
You get:
PC-1> ping 192.168.3.2
192.168.3.2 icmp_seq=1 timeout
Using route:
{R2}
/ip route add dst-address=192.168.3.0/24 type=prohibit
You get:
PC-1> ping 192.168.3.2
*12.12.12.2 icmp_seq=1 Communication administratively
prohibited
prohibited
prohibited
prohibited
prohibited
Using route:
{R2}
type=unreachable
You get:
PC-1> ping 192.168.3.2
*12.12.12.2 icmp_seq=1 Destination host unreachable
Preferred source
pref-src The pref-src property, which can be used when writing a static
route, indicates which of the local IP addresses has to be used for packets
originating locally and sent via this route. It is important to consider that:
the value of this property has no effect on forwarded packets;

if the value of this property is set to IP address which is not the local
address of this router, the path will be inactive;
if the pref-src value is not set, for packets originating locally sent using
this route one of the local addresses connected to the output interface
will be chosen that correspond to the destination prefix of the route.
Typically this property is used when we want to manage the traffic of an
uplink and a downlink. Consider the following example:
[admin@MikroTik] > /ip address print
# ADDRESS NETWORK BROADCAST INTERFAC
E
0 10.1.0.3/16 10.0.0.0 10.1.255.255 ether1
1 10.2.0.3/16 10.0.0.0 10.2.255.255 ether2
[admin@MikroTik] > /ip route print

# DST-ADDRESS PREF-
SRC GATEWAY DISTANCE INTERFACE
0 A
S 0.0.0.0/0 10.1.0.1 1 e
ther1
10.2.0.1
ether2
1
ADC 10.1.0.0/16 10.1.0.3 0
ether1
2
ADC 10.2.0.0/16 10.2.0.3 0
ether2
Packets with destination address 10.1.1.1 will be forwarded using the

connected route (number 1) through the ether1 interface to the host
with address 10.1.1.1.
Packets with destination address 10.50.0.1 will be forwarded using the
static route (number 0) through the ether2 interface to the gateway
10.1.0.1 or through the ether2 interface to the gateway 10.2.0.1.
Locally originating packets with destination address 10.100.0.1 will be
forwarded using the static route (number 0) through the ether1
interface to the gateway 10.1.0.1 or through the ether2 interface to the
gateway 10.2.0.1 .
Locally originating packets with destination address 10.2.1.1 will be
forwarded using the connected route (number 2) through the ether2
interface to the host with address 10.2.1.1 using the source address
10.2.0.3.
As previously mentioned, if the route has not set the pref-src property then
the source address of a locally originated packet is selected from the router's
local addresses:
this local address is assigned to the output interface;
the gateway is corresponding to this local address.
So, in this example, if a locally originated packet is sent to the 10.1.0.1

gateway then the local address 10.1.0.3 will be chosen because:
the address 10.1.0.3 is assigned to the output interface of this route

(ether1);
the 10.1.0.1 gateway is inside the 10.1.0.0/16 network.
Summary questions
domande-2
1. The default value for a static target-scope route is:

1. 255
2. 1
3. 10
4. 0
2. If you activate the Check-gateway function for a route then all routes
with the same gateway will they undergo the same control?
1. Yes
2. No
3. To drive traffic that is more specific through a
route with routing-mark, should traffic be identified before or after the
routing process?
1. Before
2. After
4. Does the pref-src property indicate which of the IP addresses are
preferred as a destination for a gateway?
1. Yes
2. No
5. In the ECMP protocol configuration, can the same gateway be
repeated several times for the same destination?
1. Yes
2. No
6. With ECMP only the nexthop gateway with the lowest IP is copied to
the FIB?
1. Yes
2. No
7. With ECMP if the router uses an external src-NAT masquerade it is not
necessary to indicate a masquerade for each address.
1. Yes
2. No
8. ECMP realizes the load balancing:
1. For connection.
2. By source address.
3. By destination address.
Solutions
1. 10.
2. Yes.
3. Before (see the diagram on page packet-flow ).
4. No, the property pref-src indicates which of the local IP addresses is to
be used for packets originating locally and sent via a specific route.
5. Yes.
6. No, all reachable nexthop gateways are copied to the FIB.
7. No, you must indicate all the addresses to which the masquerade acts.
8. by connection. See the in-depth questions on page ecmp-domanda .
OSPF: Open Shortest Path First
«And at this mad speed maybe only a round dance will save us...» Edoardo
Bennato
Dynamic routing
Advanced routing uses static and dynamic routing protocols (see figure
routing-protocols on page routing-protocols ); routers that use static type
protocols manage a routing table created and updated manually by the
network administrator, while routers using dynamic protocols provide by
themselves to create and update this table by finding information at other
dynamic routers and on all of their segments. Dynamic routers contain
constantly updated information on possible routes through the network, as
well as information on bottlenecks and connection interruptions. This
information allows them to find the most efficient way, available at a given
time, to forward a data packet to its destination. The networks are grouped
in Autonomous system (AS), that is in groups of routers and networks
controlled and managed by a single entity. AS are identified by a global
number, univocal, assigned by the same authority that issues the internet
addresses. Routers that route messages within the same AS are called
interior router or internal router , while those that route messages between
different AS are called exterior router .
Definitions for large routing networks

In the case of intradomain routing, the internal routers must know only the
network segments belonging to the same AS, therefore it is not necessary
that they keep information on the external networks; they only send to the
border routers those packets destined out. This organization has
considerable advantages, since it considerably reduces the size of the
routing tables because the external networks are not directly present in these
tables except through the border router, which will think how to reach the
required destinations. Moreover, another benefit concerns the router itself,
which will have to bear a lower workload, making the network more
efficient. In the case of intradomain routing, the border router must
necessarily keep track of both the internal networks belonging to its own
AS and the other border ruoter. In addition, these border routers are also
responsible for translating protocols that the various AS can use. Over time,
dynamic routing protocols have chosen different mathematical approaches;
we recall the most widespread :
routing protocols based on distance vector;

routing protocols based on link state.
Distance vector routing protocols
This type of approach is based on the fact that each router keeps track of the
distance and direction (vector ) of all possible destinations within the
internetwork. The way in which the distances present in the routing tables
can be calculated depend on different characteristics of the communication
such as:
Delay. It refers to the time it takes for a packet to be sent along a

connection. This parameter may depend on both the transmission
speed of the physical medium used and the congestion on the link.
Band. The greater the band assigned to a certain connection, the lower
the value attributed to the distance.
Hop count. This variable takes into account the number of routers a
packet must pass to get to the desired destination.
Load. It refers to the use of the hardware resources of a network, in
fact if a router is not able to correctly process the information due to its
limited computing capacity, an alternative route will be chosen.
In first instance, the router itself will detect which networks are directly
connected to it, assigning a zero distance in routing table. Then it will pass
its table to neighboring routers, ie those connected to it. Each table will then
be replicated to all adjacent routers at 60 second intervals. From this it
follows that this kind of protocols doesn't allow to have a knowledge of the
network in its entirety, but only of the successive jumps (next hop) that will
allow to forward the packets to the final destination.
Routing protocols based on link state
Link state based protocols have a different approach than distance vector
based protocols to collect the information needed to perform dynamic
routing and to calculate routes to be added to routing tables. An important
feature of these protocols is to maintain a complete view of the network
topology, ie each router is aware of the existence of any other router on the
network and how they are connected to each other, for this result a network
map is built. Link state protocols are based on the concept of "distributed
map": all the nodes have a copy of the map of the network, which is
regularly updated. The link state protocol maintains a complex database to
store topology information, which is used to calculate routes to possible
destinations. In this database each record represents a link in the network.
With this information, each node can easily calculate the shortest path from
itself to all other nodes. Since all the nodes contain the same database and
run the same route-generation algorithm, the paths are consistent and no
loops occur. To do this, each router uses an SPF algorithm (shortest path
first ): the shortest path among the possible for a given destination is
chosen. This algorithm is also known as the Dijkstra algorithm. This allows
each router to identify the routes by creating a tree structure representing
the network and having the router itself as root.
OSPF
OSPF stands for Open Shortest Path First. This routing protocol is based on
link state technology, unlike RIP which is based on the distance vector
algorithm. In OSPF there is a distributed database, a flooding procedure and
an adjacency definition. OSPF belongs to the IGP class and therefore
operates internally in each Autonomous System (AS). The protocol
exchanges LSA messages (Link State Advertisement), literally
"announcement on the status of the link", with all those routers belonging to
the same AS, being of the link state type, uses the SPF algorithm to
calculate the shortest route to each destination. Furthermore, since the
Internet is made up of many AS, sometimes quite large and not easily
manageable, OSPF offers the possibility of dividing the AS into numbered
areas, (called OSPF areas and identified by a number of 32 bits called area-
id) each of which is formed from one or more networks. This means that the
topology and the details inside a certain area are not visible outside it. Each
AS has a backbone area (backbone) called Area 0, which has the purpose of
communicating the different areas belonging to the same AS. Within each
area, each router maintains the same database created with the exchange of
LSA messages, calculates the minimum path by itself, towards each other
routers belonging to the same area, including the router that is connected to
the backbone ("area-border routers" ABR). As described in figure ospf-
definizioni there must be at least an ABR in each area, to connect it to the
backbone. The ABRs maintain numerous databases, one for each area to
which they belong and each area includes a set of IP subnets. In addition to
ABRs, we can still distinguish 2 types of routers:
Internal routers : these are the routers that manage the traffic within
the same area
Autonomous System Boundary Routers (ASBR) : they are gateways
for external traffic and convert paths in the OSPF domain learned by
other protocols such as BGP and EIGRP.
We can also subdivide the routes into three types:
Intra-area : in this case the source router knows the minimum path to
the destination router, thanks to the database that has been built;
Inter-Area : the total path can be divided into three stages, the first
concerns the search for a route from the source to the backbone, the
second from the backbone to the destination area, and the third to the
destination router inside of the previously identified area.
Inter-Autonomous system : in this case Border router routers will be
designated, which allow connections to be made between different
ASs, using an EGP protocol.
Each area behaves like an independent network; the database includes only
the link status of the area, the flooding protocol stops at the borders of the
area and the routers calculate only the routes within the area. The cost of the
routing protocol is thus proportional to the format of the area and not to that
of the network. Thanks to hierarchical subdivision, it is possible both to
reduce the routing traffic exchanged between the nodes of the OSPF
network, and to reduce the size of the routing tables of the routers within
each individual area. Furthermore, the convergence time of the OSPF
protocol is reduced since the routers will have to apply the Dijkstra
algorithm on a smaller graph and therefore with a smaller CPU and,
consequently, in less time. The AS routers periodically send to their
neighbors (every 10 seconds in the case of local networks), or in
correspondence with topological changes in the network, "Hello" packets,
which have the task of verifying which of the directly connected routers, is
active. In this phase, each router will acquire a knowledge of its neighbors
and build a "partial" map of the network containing the topological
information. The OSPF routers communicate via the OSPF protocol, which
is directly encapsulated in IP (protocol type = 89) and is, in turn, composed
of 3 sub-protocols:
Hello : it is used to verify the effectiveness of the links. The routers of

the ASs that communicate with the OSPF routing protocol periodically
send to their neighbors (every 10 seconds in the case of local
networks), or in correspondence with topological changes in the
network, "Hello" packets, which have the task of verifying which,
among the directly connected routers, is active. In fact, "Hello" packets
are only transmitted between neighboring and never propagated nodes.
Exchange : when two OSPF routers establish the connection on a
point-to-point link, they must synchronize their databases. The initial
synchronization takes place via the "exchange" protocol, while the
flooding protocol follows to keep the databases synchronized. The
Exchange protocol is asymmetric; the first step of the protocol consists
in selecting a "master" and a "slave" and only then the two routers will
exchange the description of their databases.
Flooding : it is used to spread (the forwarding process) to the whole
network the new status of a link.
These updates are sent, via the "Link State Update" packet, in the
event of a link status change when a timer expires (normally 60 min).
IGP, EGP e OSPF
As introduced at the beginning of the chapter in the case of intradomain

routing, the internal routers must know only the network segments
belonging to the same AS, therefore it is not necessary that they keep
information on external networks; they simply send packets destined for the
outside to border routers. This organization has considerable advantages as
it considerably reduces the size of the routing tables since the external
networks are not directly present in this table except through the border
router, which will think how to reach the requested destinations. In addition,
another benefit: precisely the router itself, which will have to bear a lower
workload, making the network more efficient. In the case of intradomain
routing, the border router must necessarily keep track of both the internal
networks belonging to its own AS, and the other border ruoter. In addition
they are also responsible for the "translation of the protocols" in the case in
which the various ASs use different routing protocols.
Routing definitions for extended networks routing

ospf-definizioni
Due to the different responsibilities that lie intradomain routing and
interdomain routing, we can classify routing protocols into:
Interior Gateway Protocol (IGP) used for intradomain routing.

Within this category there is a further subdivision based on the chosen
mathematical logic:
Distance Vector: RIP, IGRP
Link state: OSPF
Hybrid: EIGRP
Exterior Gateway Protocol (EGP) used for interdomain routing: BGP.
How OSPF works
Now we are ready to face the OSPF protocol. Let's summarize what has
been described so far:
Open Shortest Path First (OSPF) is a dynamic routing protocol

included in the IGP protocols category (Interior Gateway Protocol) to
operate within the same AS.
OSPF has the ability to link-state (detection of the status of each link)
and uses Dijkstra's algorithm to find the optimal routing path.
OSPF is able to maintain, manage and
distribute routing information among networks even if the network
topology changes in a dynamic way.
It use the protocol IP (layer3) number 89 .
Area
OSFP areas
aree
The OSPF protocol allows routers to be grouped into sets called area . Each
area makes a separate copy of the routing algorithm, which means that each
area has its own link-state database and the corresponding shortest path
tree. The structure of an area is invisible to other areas, this knowledge
isolation makes the protocol more scalable because the calculation of
routing table requires less CPU resources and routing traffic is reduced.
However, the multi-area settings create further complexity and for this
reason it is not advisable to separate the areas with less than 50 routers even
if the maximum number of routers in an area mainly depends on the CPU
power that is available for the calculation of the routing table. Each area is
identified by a unique area-id within an AS. In each AS there must always
be an area with area-id = 0.0.0.0 (the backbone). This special area, the
backbone literally "backbone", always contains all the boundary routers of
the area and is responsible for the distribution of routing information
between non-backbone areas. Given this particular role the backbone area
must be contiguous, ie there must not be any disconnected segments;
however, it is not necessary for the area border routers to be physically
connected to the backbone: the connection to it can be simulated using a
virtual connection. The topic will be covered in the section virtual-link on
page virtual-link through a specific laboratory. Therefore a network with
active OSPF protocol is initially identified as Area 0. In the case of network
expansion, other areas adjacent to area 0 can be created, with values in the
range 0-4294967295. A group of areas generates an autonomous OSPF
system (OSPF Autonomous System). Some abbreviations used by the
protocol:
IR (Internal Router) - these are the routers built into an area.

ABR (Area Border Router) - is a router that connects an area with
another area.
ASBR (Autonomous System Boundary Router) - is a router located
on the border of an AS (router more external than the AS) with the
task of being the bridge among the routers of the AS of other
networks.
ASBR can also be a router that is a member of the OSPF protocol it
acts as OSPF bridge routing with other routing protocols like RIP,
BGP etc ...
The OSPF routers establish and maintain a relationship with the neighbors,
technically called adjacency or contiguity. After initialization or after some
change in routing, a router with active OSPF generates announcements,
called LSA (Link State Advertisement ), containing topological information
about the network. Through a process called flooding, announcements are
exchanged with all the routers on the network. As soon as a router receives
the LSAs, it creates a Link-State Database on which it applies the Dijkstra
SPF (Shortest Path First) algorithm to create a network topology tree, or
more simply a network map. Each router creates a Link-State Database and
builds its SPF tree starting from the same link-state information; however
each one generates its own view of the network topology, different from
that created on the other routers. Initially, each router identifies itself as the
root of the tree; then, starting from this root, the algorithm identifies the
shortest path for each destination, with its cost. Schematically, each router
with OSPF must:
find out the address of each nearby router;

measure the cost of reaching each nearby router;
send a message to all the routers spreading the acquired information;
calculate, locally, the minimum path to every other router using the
SPF algorithm developed by Dijkstra.
Discovery of neighbors
To know the entire topology of a network, each router sends a Hello packet
to all the available point-to-point connections and receives their answer,
from the directly connected routers, their identifier, called Router ID. The
time that elapses between sending two Hello packets is regulated by the
Hello Interval field, by default 10" on Ethernet networks and point-to-point,
30" on serial links in Multiaccess networks such as Frame Relay. The
maximum time a router waits for the Hello Packet is regulated by the Dead
Interval field, by default 40" on Ethernet networks and on point-to-point
serial links, 120" on Multiaccess networks such as Frame Relay, therefore
quadruple values compared to Hello Interval. To calculate the connection
cost with neighboring routers, an Echo packet is used with which the time
required to obtain a response is measured. Before reaching the "perfect"
knowledge of neighbors, called textit{neighbor adjacency}, the router goes
through various state changes. The full state, and therefore the adjacency
neighbor between two routers, is only possible if all the following
conditions are met:
The routers have different IDs;

Hello Interval is the same (by default 10" on Ethernet networks and
point-to-point serial links, 30" on Multiaccess networks such as Frame
Relay);
the Dead Interval is the same (maximum time in seconds that the Hello
Packet is expected, four times the value compared to the Hello
Interval)
the belonging Area is the same (typically Area 0);
the network is the same (ie the routers communicate at IP level and
agree on the subnet mask)
To learn more about the OSPF protocol, see also the documents:
Cisco OSPF Design Guide: http://bit.ly/2VC7kUn

Simulation of a network with OSPF Routing in Cisco Packet Tracer:
http://bit.ly/2VyUiHs
Election of Designated Router
elezione-dr In point-to-point links, apart from the conditions listed, there

are no problems to establish adjacencies, since by definition only two
routers can be present on the link. Conversely, in a multiaccess network, or
in a network segment where multiple routers are connected, a router can
reach full status only with a designated router (DR, Designated Router ) or
a designated backup router (BDR, Backup Designated Router ). The
purpose of having a DR designated router and a BDR backup router is to
reduce the number of transmitted updates, unnecessary traffic flow and
processing overhead; routers can only accept updates from the DR. In each
network segment there can be only one DR and only one BDR. All other
routers take on the role of DROther (other than the DR) and must have a
connection with the DR and the BDR. When a link does not work, the
router with this information sends the update to the DR using the multicast
address 224.0.0.6; in turn the DR is in charge of distributing the change to
all the other OSPF routers, always in multicast, but to the address 224.0.0.5.
In addition to reducing the number of updates sent over the network, this
process ensures that all routers receive the same information at the same
time and from a single source. The DR maintains its role until a possible
failure: if the DR fails, the BDR takes its place, and a new BDR will be
elected. The DR may fail because the OSPF process stops or restarts, or
because its LAN interface becomes "down". Within the network, the router
with the highest ID is elected DR, the second highest is elected BDR. The
router ID is nothing but an IP address, chosen in this way:
setting it by command (router-ID command) on the router;

if no value is set manually by the administrator, the highest IP address
configured on the loopback interfaces is used;
if no loopback interface is configured, the highest IP address on the
active physical interfaces is used.
{Exercise} Consider the network of figure dr .
For each router determine the respective router id.

For each subnet determine the designated routers (DR).
Example of calculation of router id and designated router.

dr
{Solution}
Router id
Router Router ID
R1 192.168.10.5
209.165.201.
R2
1
R3 10.1.10.1
R4 192.168.10.3
R5 192.168.10.5
209.165.201.
R6
2
Designated router
Network Router
10.1.10.0 R2
10.1.13.0 R4
10.1.16.0 None
10.1.19.0 R1
209.165.201. None
0
{Solution with Mikrotik} The solution of the previous paragraph is correct
using theory and if are used Cisco routers, if Mikrotik routers are used the
result changes:
/interface bridge add name=loopback
/ip address add address=192.168.10.5 interface=loopback
/routing ospf instance set redistribute-connected=as-type-1
numbers=0
/routing ospf network add network=10.1.10.0/24 area=backbone
[admin@R1] > /routing ospf neighbor print

0 instance=default router-id=10.1.13.2 address=10.1.16.1
interface=ether3
priority=1 dr-address=10.1.16.2 backup-dr-address=10.1.16.1
state="Full"
state-changes=5 ls-retransmits=0 ls-requests=0 db-
summaries=0
adjacency=2m51s

interface=ether2
state="Full"
summaries=0
adjacency=3m4s

interface=ether2
state="Full"
summaries=0
adjacency=3m24s

interface=ether2
state="Full"
summaries=0
adjacency=3m36s

numbers=0
/routing ospf network add network=209.165.201.0/27
area=backbone
[admin@R2] /routing ospf> neighbor print

0 instance=default router-id=209.165.201.2
address=209.165.201.2
interface=ether1 priority=1 dr-address=209.165.201.2
backup-dr-address=209.165.201.1 state="Full" state-changes=6
ls-retransmits=0 ls-requests=0 db-summaries=0
adjacency=2m36s

interface=ether2
state="Full"
summaries=0
adjacency=4m53s

interface=ether2
state="Full"
summaries=0
adjacency=5m13s

interface=ether2
state="Full"
summaries=0
adjacency=5m26s

numbers=0

interface=ether1
state="2-Way"
summaries=0

interface=ether1
state="Full"
summaries=0
adjacency=5m32s

interface=ether1
state="Full"
summaries=0
adjacency=5m32s

numbers=0

interface=ether1
state="2-Way"
summaries=0

interface=ether1
state="Full"
summaries=0
adjacency=5m32s

interface=ether1
state="Full"
summaries=0
adjacency=5m32s

numbers=0

interface=ether1
state="Full"
summaries=0
adjacency=5m33s

numbers=0
area=backbone
[admin@R6] /routing ospf neighbor> print

interface=ether1
priority=1 dr-address=209.165.201.2 backup-dr-
address=209.165.201.1
state="Full" state-changes=4 ls-retransmits=0 ls-requests=0
db-summaries=0
adjacency=3m39s
Metric
OSPF calculates the cost of the metric based on the bandwidth and speed of
a specific connection. The equation used to calculate the cost of an OSPF
connection is: Cost = 100.000.000 / bandwidth of the link in bps The results
of this equation, applied to some connection types, are shown in the table
table:metrica .
Link bandwidth in Cos
Interface type
bps t
Fast ethernet e
100.000.000 1
oltre
Ethernet 10.000.000 10
E1 2.048.000 48
Metric
table:metrica
OSPF for RouterOS

In this and in the following sections the concepts presented up to now
relating to OSPF will be described according to the terminology and logic
of RouterOS. The general configuration of OSPF is found under Routing >
OSPF > Instance and provides the following parameters (see figure istanza
):
router-id: (Default: 0.0.0.0) the ID of the OSPF router. If not specified,

OSPF uses the lowest IP address configured on an active interface .
Redistribute Default Route: distribute the default route. This option is
used or activated only on the ASBR router
Redistribute Connected Routes: redistribute the connected routes, or
routes to directly accessible networks.
Redistribute Static Routes: redistribute static routes.
Redistribute RIP Routes: redistribute the routes deriving from RIP.
Redistribute BGP Routes: redistribute the routes deriving from BGP.
On the redistribution of routes see also the section redistribute-type on page

redistribute-type .
OSPF parameters.
istanza
The next step, after setting the parameters of the OSPF instance, is to define
all areas indicating for each one an identifier called area-id. To add an area
use item Routing > OSPF > Areas (figure add-area ). Area 0 or backbone
area is the area in which one or more ABRs are combined to exchange
routing information coming from other areas (see figure ospf-definizioni).
Each non-backbone area must be connected directly to the backbone area.
The backbone area is also a transit area for outgoing or incoming traffic to
the AS. An area that is not directly connected to the backbone area can be
connected to the backbone area using Virtual Link. The networks that make
up an area are declared using item Routing > OSPF > Network (figure
add-network ). OSPF will be enabled on all interfaces that have at least one
address that falls within this range. Note that for this check we indicate the
subnet while for point-to-point interfaces we indicate the address of the
remote endpoint.
Starting setup
Adding an area.
add-area
Adding a network connected to the area.
add-network
Lab
Aree e network OSPF
The objective of this laboratory is to create a simple OSPF configuration
divided into three areas.
OSPF - areas management

area-lab
1. We connect the routers as in figure area-lab .

2. We configure the ip addresses on the two PCs and on the interfaces of
the three routers:
{R1}
/ip address add interface=ether1 address=192.168.1.1/24
{R2}
{R3}
3. We check PC addresses by doing three different pings:

From PC-1:
PC-1> ping 192.168.1.1
84 bytes from 192.168.1.1 icmp_seq=1 ttl=64 time=2.634 ms
PC-1> ping 12.12.12.1

PC-1> ping 12.12.12.2

From PC-2:
PC-2> ping 192.168.3.1
PC-2> ping 23.23.23.3

PC-2> ping 23.23.23.2

4. Notice how the last ping fails because the necessary routes for packet
transit are missing.
5. For this we check the routing tables on R1, R2 and R3:
R1:
Flags: X - disabled, A - active, D - dynamic, C -
connect, o - ospf
# DST-ADDRESS PREF-
SRC GATEWAY DISTANCE
0
ADC 12.12.12.0/24 12.12.12.1 ether2
0
1
ADC 192.168.1.0/24 192.168.1.1 ether1
0
R2:
connect, o - ospf
# DST-ADDRESS PREF-
0
ADC 12.12.12.0/24 12.12.12.2 ether1
0
1
ADC 23.23.23.0/24 23.23.23.2 ether2
0
R3:
connect, o - ospf
# DST-ADDRESS PREF-
0
ADC 23.23.22.0/24 23.23.23.3 ether2
0
1
ADC 192.168.2.0/24 192.168.3.1 ether1
0
6. Configure ospf instances to redistribute the connected routes on R1,

R2 and R3 (the following command must be given on all routers) :
{R1, R2, R3}
numbers=0
7. For each router we define the ospf areas of which the router is a part;
the backbone area is already present by default on all routers:
{R1}
/routing ospf area add name=area-1 area-id=0.0.0.1
{R2}
{R3}
8. For each router we add the networks on which OSPF will operate and
associate them with the respective area:
{R1}
/routing ospf network add network=192.168.1.0/24 area=area-
1
area=backbone
{R2}
area=backbone
area=backbone
{R3}
/routing ospf network add network=192.168.3.0/24 area=area-
2
area=backbone
9. Notice how the routing tables have changed:

R1:
connect, o - ospf
# DST-ADDRESS PREF-
0
ADC 12.12.12.0/24 12.12.12.1 ether2
0
1
ADo 23.23.23.0/24 12.12.12.2
110
2
ADC 192.168.1.0/24 192.168.1.1 ether1
0
3
ADo 192.168.3.0/24 12.12.12.2
110
R2:
connect, o - ospf
# DST-ADDRESS PREF-
0
ADC 12.12.12.0/24 12.12.12.2 ether1
0
1
ADC 23.23.23.0/24 23.23.23.2 ether2
0
2
ADo 192.168.1.0/24 12.12.12.1
110
3
ADo 192.168.3.0/24 23.23.23.3
110
R3:
connect, o - ospf
# DST-ADDRESS PREF-
0
ADo 12.12.12.0/24 23.23.23.2
110
1
ADC 23.23.23.0/24 23.23.23.3 ether2
0
2
ADo 192.168.1.0/24 23.23.23.2
110
3
ADC 192.168.3.0/24 192.168.3.1 ether1
0
10. To confirm the correct operation of our network we can try the two
pings that failed first or the ping between the two PCs:
PC-1> ping 12.12.12.2
PC-1> ping 192.168.3.2

As a summary we report the final configurations of the routers. {R1 -

final configuration.}
/ip address
/routing ospf
add area area-id=1.1.1.1 name=area-1
/routing ospf instance
set redistribute-connected=as-type-1 numbers=0
/routing ospf network
add area=area-1 network=192.168.1.0/24
add area=backbone network=12.12.12.0/24
{R2 - final configuration.}

/ip address
/routing ospf area
add area-id=1.1.1.1 name=area-1
{R3 - final configuration.}

/ip address
/routing ospf area
Loopback interface
loopback As we previously analyzed if the router-id is 0.0.0.0 then the

router will use one of the router's IP addresses as a router-id. A good
practice is to set up a virtual loopback network interface and use that ip
address as a router-id; in fact if the OSPF router-id lives on a physical
interface and this is disconnected then this IP is no longer announced
by the OSPF protocol. To create a loopback interface in RouterOS you
proceed by creating a bridge with no associated port and then
assigning the IP address to the bridge. For example, referring to the
router R1 of figure area-lab it is possible to proceed in this way: {R1}
/routing ospf instance set 0 router-id=1.1.1.1
Virtual link
virtual-link As indicated in RFC 2338 which describes the OSPF

protocol, the backbone area must be contiguous with all areas.
However, it may be necessary to define the areas in such a way that the
backbone is no longer contiguous. In this case, the system
administrator must restore backbone connectivity by configuring
virtual connections. The virtual connection can be configured between
two routers through a common area called the transit area, one of
which must be connected to the backbone. Virtual connections belong
to the backbone and the protocol treats two routers connected by a
virtual connection as if they were connected by an unnumbered point-
to-point network. It should be remembered that the virtual connection
must be set on both routers.
Lab
lab-virtual-link
Virtual link between areas
The objective of this laboratory is to connect areas not adjacent to the
backbone area through a virtual link.
OSPF - Virtual link

area-virtual-link
1. We connect the routers as in figure area-virtual-link and as usual

we configure the ip addresses on the two PCs and on the
interfaces of the three routers.
2. During configuration we also add the loopback interface for each
router.
3. As for the previous laboratory, we activate the OSPF instance,
define the associated areas and networks .
{R1 - starting setup.}
/ip address
network=192.168.1.0
network=12.12.12.0
add address=1.1.1.1 interface=loopback network=1.1.1.1
/routing ospf area add area-id=1.1.1.1 name=area-1
set numbers=0 redistribute-connected=as-type-1 router-
id=1.1.1.1

/ip address
network=12.12.12.0
network=23.23.23.0
/routing ospf area
id=2.2.2.2

/ip address
network=23.23.23.0
network=192.168.3.0
/routing ospf area
id=3.3.3.3
4. As can be seen, on the R2 router, OSPF has not collected the area-
3 area routes as it is not connected to the backbone area:
C - connect, S - static, r - rip, b - bgp, o - ospf, m
- mme,
# DST-ADDRESS PREF-
0
ADo 1.1.1.1/32 12.12.12.1
110
1
ADC 2.2.2.2/32 2.2.2.2 loopback
0
2
ADC 12.12.12.0/24 12.12.12.2 ether1
0
3
ADC 23.23.23.0/24 23.23.23.2 ether2
0
4
ADo 192.168.1.0/24 12.12.12.1
110
5. Create a virtual link as in figure area-virtual-link-add :
OSPF - Virtual link

area-virtual-link-add
6. Double-check the routes on router R2:
[admin@R2] /routing ospf> /ip route print
- mme,
# DST-ADDRESS PREF-
0
ADo 1.1.1.1/32 12.12.12.1
110
1
ADC 2.2.2.2/32 2.2.2.2 loopback
0
2
ADC 12.12.12.0/24 12.12.12.2 ether1
0
3
ADC 23.23.23.0/24 23.23.23.2 ether2
0
4
ADo 192.168.1.0/24 12.12.12.1
110
5
ADo 192.168.3.0/24 23.23.23.3
110
7. As can be seen, area-3 is now connected and the backbone is

correctly receiving routes from the area.
For other interesting examples on the basic functionalities of OSPF see

the link http://bit.ly/2VIISRA .
DR e BDR
As introduced in the section elezione-dr , in each area a Designated

Router (DR) and a Backup Designated Router (BDR) will be
automatically chosen in order to collect and disseminate LSAs, thus
reducing traffic and processing times. Furthermore, the BDR will
replace DR if an error occurs. As you can see in figure dr-bdr-routeros
in RouterOS tab Routing > OSPF > Interfaces provides information
on whose routers are DRs and BDRs.
DR and BDR in RouterO
dr-bdr-routeros
Neighbors State
Using the Routing > OSPF > Neighbors menu, you can view the
status of nearby routers (figure neighbors-state ).
Neighbors State
neighbors-state
The possible states are:
Down : no Hello packet was received from the neighbor.

Attempt : applies only to NBMA zones. The status indicates that
no recent information was received from the neighbor.
Init : Hello packet received from the neighbor but bidirectional
communication is not established (its Router ID is not listed in the
Hello packet).
2-way : two-way communication has been established. DR and
BDR elections occur during this state, routers create adjacencies
based on whether the router is DR or BDR, the link is either
point-to-point or a virtual link.
ExStart : routers attempt to establish the initial sequence number
used to exchange packet information. The router with higher ID
becomes the master and starts the exchange.
Exchange : routers exchange database description packages.
Loading : in this state the information on the status of the actual
connection is exchanged. The link-state request packets are sent
to neighbors to request any new LSAs found during Exchange
status.
Full : adjacency is complete, neighboring routers are completely
adjacent. LSA information is synchronized between adjacent
routers. Routers only reach full status with DR and BDR except
for point-to-point connections .
Link State Advertisement
In the link type protocols state the packets sent by a router and that
allow the construction of the network map, once received by the
various routers of the network, are called Link State Packet (LSP):
packet of the state of the connections. Each LSP can contain multiple
Link State Advertisement (LSA) message on the status of the links,
which disseminate information on the status of links such as traditional
LSPs but are not packets. LSAs are generated by each router of the AS
depending on the skills assigned to it. There are five types of LSAs:
1. Type 1 - Router LSA : information on the routers adjacent to

those who generate the LSA
2. Type 2 - Network LSA : generated by designated routers to
describe the LAN to which the designated is connected
3. Type 3 - Summary LSA : generated by the area border router to
communicate the reachability of the other areas to the internal
routers
4. Type 4 - AS boundary router LSA : generated by the area
border router to announce the reachability of an AS boundary
router
5. Type 5 - AS external LSA : generated by an AS boundary router
to announce destinations outside the routing domain.
LSAs are propagated through a Link State Update package which can
contain more than one ad, but each propagated only one forward hop.
Conversely, to guarantee the reliability of the propagation process it is
good that the acknowledgments are retransmitted one at a time
(although they can also be grouped together) in a packet of the Link
State Acknowledgment type. One of the typical elements of the
propagation process is also the Retrasmission List which, in each
router, takes into account the received LSAs that have not yet been
acknowledged. Each interface will therefore have a specific
retransmission list appropriately set taking into account the speed of
this interface. This information is visible using the Routing > OSPF >
LSA menu (see figure lsa ).
Link State Advertisement

lsa
For a discussion of the topic, see the link http://bit.ly/2VzOIo9 .
Types of networks
If you have worked almost exclusively with Ethernet networks, it will

take some time to understand the concepts of non-broadcast networks.
Dynamic routing protocols, particularly OSPF, require familiarity with
all types of L2 topologies. This OSPF configuration parameter is
available in Routing > OSPF > Instance . OSPF addresses three
network classes (as listed in section 1.2 of RFC 2328): point-to-point,
broadcast and non-broadcast.
Point-to-Point
This is by far the simplest type of network and the easiest starting
point for understanding other topologies. A point-to-point network is a
connection between exactly two points (or routers). A packet sent by
one of the routers will always have exactly one recipient on the local
link.
Point-to-Point
Broadcast
Point-to-point connections do not adapt well to all situations, a much

more efficient way to connect a large number of devices is to
implement a multiaccess segment; that is, a segment that can be
accessed from multiple end points. An Ethernet segment is an example
of such a network.
Broadcast
broadcast
In Ethernet networks a single packet transmitted by a device can be
multiplied by the medium (in this case an Ethernet swith) so that every
other end point receives a copy. This is advantageous not only for the
resulting bandwidth savings but also because this facilitates the
automatic discovery of neighbors. In the example shown in figure
broadcast , R1 can multicast (a transmission destined only to certain
recipients) of a Hello OSPF message on the entire segment, knowing
that all the other OSPF routers connected to the segment will receive it
and will reply with your own multicast message. As a result, neighbors
can quickly identify and form adjacencies without first knowing the
addresses. OSPF routers on a multiaccess segment will elect a
designated router (DR) and a designated backup router (BDR) with
which all non-designated routers will form an adjacency. This is to
ensure that the maintained number of adjacencies does not grow too
much; a segment containing ten routers would require 45 connections
to form a mesh, but only 17 when there is a DR and a BDR.
Non-Broadcast
Unfortunately, not all multiaccess technologies support broadcast

transmissions. Frame relay and ATM are probably the most common
examples of non-broadcast transport, which require the configuration
of individual permanent virtual circuits (PVC) between the end points.
Non-Broadcast
non-broadcast
Note that in the frame relay topology shown in figure non-broadcast ,
R1 must prepare and transmit a single package for each destination it
wishes to reach. In addition to being inefficient in terms of bandwidth,
this limitation requires the router to know the addresses of its
neighbors before it can communicate with them. OSPF can operate on
a non-broadcast network in two non-broadcast (NBMA) or point-to-
multipoint multi-access modes. Each of these topologies addresses the
absence of transmission capacity from a different perspective. {Non-
Broadcast Multi-Access (NBMA)} An NBMA segment emulates the
typical function of a broadcast network. Each router on the segment
must be configured with the IP address of each of its neighbors. The
OSPF Hello packages are then transmitted individually as unicast
packages to each adjacent neighbor. As in a real broadcast network, a
DR and BDR are elected to limit the number of formed adjacencies. It
is important to remember that in an NBMA network it is necessary to
specify the neighbors manually (see figure add-nbma ).
AAdd a NBMA neighbor

add-nbma
{Point-to-Multipoint} A point-to-multipoint configuration looks for
the solution to the limitation of non-broadcast networks trying to
emulate the transmission capacity of a broadcast network, in fact, it
tries to organize the PVCs in a collection of point-to-point networks.
The Hello packets still have to be replicated and transmitted
individually to each neighbor, but the multipoint approach offers two
distinct advantages: the presence of DR and BDR is not required and
the emulated point-to-point links can occupy a common subnet. It
should be noted that all the routers connected to a non-broadcast
network must be manually configured to recognize this common
subnet.
{l c c c c}
Allows
Hello Requires
more
defaul neighbor than two
Use DR
t s host
and comman into
Tipo di interfaccia time
BDR? d subnet?
Broadcast Yes 10 No Yes
Point-to-point No 10 No No
Non-broadcast (NBMA) Yes 30 Yes Yes
Point-to-multipoint No 30 No Yes
Point-to-multipoint non
No 30 Yes Yes
broadcast
Loopback No - - No
Summary of network types.
OSPF Redistribute Type
redistribute-type When OSPF exports routing information from

external autonomous systems (AS), includes a cost or external metric
in the route. OSPF supports two types of external metrics: type 1
(type-1 or E1) and type 2 (type-2 or E2). The difference between the
two metrics is how OSPF calculates the cost of the route. Type 1
external metrics are equivalent to the link-state metric, where the cost
is equal to the sum of the internal costs plus the external cost. This
means that external type 1 metrics include the external cost for the
destination and the cost to reach the AS border router. Type 2 external
metrics use only the external cost for the destination and ignore the
cost to reach the AS border router. By default, OSPF uses the external
type 2 metric. Both external type 1 and type 2 metrics may be present
in the AS at the same time. In this case, type 1 external metrics always
take precedence. Type 1 external routes are always preferred over
external type 2 routes. When all paths are external type 2 paths, the
routes with the smaller type 2 metric announced are always preferred.
We can say that OSPF type 1 routes are designed to reflect the actual
cost along the route from the point of redistribution to the destination.
In general (except for some very special cases), type 1 routes are
preferred over type 2, which do not directly reflect the end-to-end cost
from the point of redistribution to the destination.
Lab
type-1-2 Start from the final configuration produced by the previous

laboratory on page lab-virtual-link . In the first phase a static route will
be added on the R1 router and the redistribution will be configured
with Type-1. We will see how the metric propagates up to router R3.
Subsequently the distribution metric will be changed with Type-2 to
verify the cost change.
Type-1 and Type-2
The goal of this workshop is to understand the influence of the type of
redistribution in the final calculation of the metric.
OSPF - Virtual link

area-virtual-link
1. We connect the routers as shown in figure area-virtual-link and

we continue with the configuration left at the end of the previous
laboratory.
2. On the R1 router we create a static route:
{R1}
gateway=192.168.1.2
3. Set the OSPF instance of router R1 to redistribute the static route

with Type-1 metric:
{R1}
/routing ospf instance set redistribute-static=as-type-
1 numbers=0
4. On router R3 see the propagated route metric (Routing > OSPF

> Routes ):
Type-1
type-1
5. Set the OSPF instance of router R1 to redistribute the static route
with Type-2 metric:
{R1}
/routing ospf instance set redistribute-static=as-type-
2 numbers=0
6. On router R3 see the propagated route metric (Routing > OSPF

> Routes ):
Type-2
type-2
7. Note the change in the cost associated with the route.
Types of areas
An OSPF network is divided into areas. They are non-overlapping

logical groups of routers whose information can be summarized with
respect to the rest of the network. Different types of "special" areas are
defined:
Backbone - Area 0 (default 0.0.0.0) : Responsible for the

distribution of routing information between non-backbone areas.
All other areas must be connected to area 0 .
Standard area : it is a sub-area of Area 0. This area accepts the
intra-area LSA and the inter-area LSA of each ABR connected to
area 0.
Stub area : this area does not accept LSAs from external routes
whether it is another area through ABR or ASBR.
Not-so-stubby area (NSSA) : stub Area that has an external path
that is assigned by another area.
Standard area
Standard area
The following LSAs are propagated:

routers
router
Area stub
Stub area
Stub Area refers to those types of areas that do not receive external
routes. External routes will then be defined and distributed by another
routing protocol. Thus, the stub area needs to relegate to a default
route the exchange traffic with routes outside the belonging domain.
routers
Totally stub area
Totally stub area

A totally stubby area is similar to a stub area, however this area does
not allow for summary routes other than external routes. The only way
traffic leaves the area is a default route that is the only Type-3 LSA
announced in the area. When there is only one route to exit the area,
fewer routing decisions must be made by the route processor, with less
use of system resources.
This is the Cisco version of the NSSA. For more details see the link
http://bit.ly/2VucxxA .
1. Type 1 - Router LSA : LSA Router: information on the routers

adjacent to those who generate the LSA
Not-So-Stubby Area
Area Not-So-Stubb y
Also identified as NSSA, a not-so-stubby area is a type of stub area
that can import external AS routes and send them to the backbone, but
cannot receive such external AS routes from the backbone or other
areas. The following LSAs are propagated:

router
5. Type 7 – NSSA external link : it is the information given by the
ASBR to be on an NSSA
Passive interfaces
When using OSPF, two things will occur: All interfaces that have IP
addresses within a network will send LSA announcements. Hello
OSPF packets are sent on these interfaces. In large ISPs and corporate
networks, some routers at the distribution level often have a large
number of interfaces, for example on the edge of the WAN. A common
practice on such routers is to enable routing processes on a network
interval corresponding to different interfaces. While this technique
facilitates the routing protocol configuration, enabling indiscriminate
routing on more or all interfaces can increase the chances of entering
unauthorized routing peers. Furthermore, the exchange of unnecessary
routing protocols increases the CPU overhead on the router. For this
reason it is sometimes not desirable to send OSPF Hello packets on
certain interfaces. This functionality is obtained by putting the specific
interface in passive mode (figure interface-passive ).
Passive interface
interface-passive
Cost
All OSPF interfaces have a cost, which is a routing metric used in the
calculation of the link state. Paths with lower total metrics are
preferred to those with higher path metrics. By default, OSPF assigns a
default cost metric of 1 to any link faster than 100 Mbps. This means
that all interfaces faster than 100 Mbps have the same default cost
metric of 1. Having the same default metric may not be a problem if all
the interfaces are running at the same speed but if the interfaces
operate at different speeds, you may notice that the traffic is not routed
on the faster interface because OSPF addresses packets equally
through the different interfaces. For example, if the routing device has
Fast Ethernet and Gigabit Ethernet interfaces with OSPF, each of these
interfaces has a default cost metric of 1. There is an interesting thread
in the Mikrotik forums where through a script it is suggested to set the
cost of each interface based on the speed of the interface:
http://bit.ly/2VxVDOG .
Redundancy
When an OSPF link is added it will detect it and be added to the

available routes. If there is a network with multiple gateways on the
same interface and with the same cost then load balancing will be
used. If one of the interfaces has a higher cost one of the links will be
the main one while the others will become failover links.
Common problems of an OSPF installation

and comparisons
We close the chapter on OSFP suggesting the excellent presentation of
Kevin Myers at MUM USA 2018 which focuses on the most common
problems in an OSPF installation and their related solutions:
http://bit.ly/2VAwOlh Also for some OSPF case studies see the link
http://bit.ly/2Qq0v4J . In the appendix from page cisco-routeros-ospf
there are a series of tables that compare commands and configurations
between the Cisco IOS implantation OSPF and the Mikrotik RouterOS
implementation.
Summary questions
domande-3
1. In an infrastructure with OSPF the external routes are imported as

Type-2.
In this case the routing policy is implemented taking into
account the sum of the external and internal metrics?
1. Yes
2. No
2. In an area there are always two designated routers and at least one
backup designated router?
1. Yes
2. No
3. The backbone area (area 0) is only necessary if there are at least
two adjacent areas.
1. Yes
2. No
4. In a network based on link-state routing protocols, does each node
contain the same database?
1. Yes
2. No
Solutions
1. No.
Only Type-1 routes include internal metrics. Type 2 external
metrics use only the external cost for the destination and ignore
the cost (metric) to reach the AS border router. On this see the
two figures on page type-1 which summarize the result of the
laboratory type-1-2 .
2. No, only one DR and one BDR.
3. No. The backbone area always exists.
4. Yes. It is precisely this characteristic combined with the fact of
executing the same routing generation algorithm that ensures that
the paths are consistent and no loops occur.
BGP: Border Gateway Protocol
{«Give me hope in better time \\ with open eyes but no borders...»} Pooh
How BGP works

Border Gateway Protocol (BGP) is an EGP-type routing protocol (see the
routing classification in figure routing-protocols on page routing-protocols )
used to connect multiple routers belonging to distinct autonomous systems.
It is therefore an inter-AS routing protocol, although it can also be used
among routers belonging to the same AS (in which case it is indicated by
the iBGP name, Interior Border Gateway Protocol), or among connected
routers via an additional AS that separates them (eBGP, External Border
Gateway Protocol). BGP is the main routing protocol that currently
connects the Internet in a decentralized way, not dependent on a single
node. This protocol only exchanges routing information, does not show the
network topology and is used to exchange routing information among large
networks (AS) as described in figure bgp-network .
A BGP network.
bgp-network
The choice of routing is based on the most specific prefix and on the
shortest distance (AS path). RouterOS supports BGPv4 as defined in RFC
1771. We can say that the BGP protocol is the "language" with the AS we
talked to each other exchanging routing information and making all
destinations reachable. It works by managing a table of prefixes (IP
networks), which provide information on the reachability of different
networks among multiple autonomous systems. It is a path-indicating
protocol that does not use technical metrics (for example, it does not
consider bandwidths) but makes routing decisions based on specific
policies. The motivation that drives an organization to use the BGP protocol
to exchange its routes on the internet is the need to have a multihomed
network. A multihomed network means a network that purchases transit to
the internet from multiple top level providers (or even multiple links with
the same provider) and that must guarantee accessibility from the outside of
its services, through a set of public IP addresses. In fact, in a standard
situation without the use of the BGP protocol, every link to the internet will
be equipped with its IP addressing class, which cannot be shared with other
links (see figure multihomed-network-wo-bgp ). It is therefore clear that by
publishing a service, for example a server hosting a website, on the IP
address that can be reached directly from the specific link, when the link
falls, that service will be unreachable by other networks.
Multihomed network without BGP.
multihomed-network-wo-bgp
Instead, using the BGP protocol to propagate its own class of IP addresses
on the Internet, the addresses themselves will be reachable via any link to
which the routes have been propagated (see figure multihomed-network-w-
bgp ).
Multihomed network with BGP.

multihomed-network-w-bgp
In the BGP protocol the adjacent ASs, called peers, establish route
exchange sessions through an appropriate router configuration. Sessions use
the TCP protocol to exchange information. It is important to note that all
routers within an AS that participate in routing via BGP must be connected
according to a fully connected topology (full-mesh); that is, each router
must be a peer of all the others. This poses problems relating to the ability
to be skilled, so solutions such as route-reflections and confederations can
be implemented. The topic will not be discussed here, as it is necessary only
in large AS. As mentioned before, BGP is a protocol based on path-vector,
which means that the best path to reach a given destination is mainly based
on the number of AS among source and destination. For example, in
choosing between the following two paths, the first one will be chosen even
if with a smaller bandwidth prepend:
AS100 → AS 200 → AS 300 → AS 400
AS100 → AS 105 → AS 106 → AS 107 → AS 400
However, it is possible to use some tricks to determine the preferred route.

An example is the so-called "AS prepending", which basically consists of
injecting the AS number several times into the AS path. Going back to the
previous routes, if the number 2 link has greater transmission capacity, I can
"force" the transit through it by announcing my AS (400) several times.
Note therefore that link 1 is longer than 2, so it will be used as a second
choice.
AS100 → AS 200 → AS 300 → AS 400 → AS 400 → AS 400

AS100 → AS 105 → AS 106 → AS 107 → AS 400
This "trick" will be used in lab bgp-lab2 on page bgp-lab2 . It is important

to note that the protocol does not pay attention to the transmission channels
so it requires the use of channels that are as similar as possible. It is added
that the BGP protocol is valid both for IPv4 routing and for IPv6 routing.
What you can do with BGP
They range from a simple multi-homed network to two providers to

networks peering with other partners or customer networks, through a
private peering or through a public peering at an IXP (Internet Exchange
Point) (ex: MIX-IT). Obviously, thanks to the selection of the vector path
link, each customer who has to reach the provided services will use the path
with the shortest length. An example:
provider A provides internet services and buys internet transit from B

and C;
provider A acquires customer Z, which connects to the internet via D
and needs very low latency times to service A.
It is evident in this case that a direct peering with D would
considerably shorten the path of the packets between A and Z.
What can't be done with BGP

Precisely because the protocol is link-vector, the physical media on which
the packets will pass cannot be considered in any way.
Criticalities and requirements
To propagate your routes on the internet via BGP, you need to be a

recognized Autonomous System (from RIPE in the European case) and
have your own class of public IP addresses. The lowest purchasable
allocation is one / 24, or 256 IP addresses, called PI (Provider Indipendent).
However, it is very difficult to obtain the allocation of a class of this type,
as it is necessary to meet certain requirements that are difficult to complete.
It is much easier to get larger networks, such as one / 22 (4 networks / 24),
called PA (Provider Allocatable). This is because in the various internet
routers we prefer to avoid propagating routes that have a prefix greater than
or equal to 24, as they would too much fragment the routing table of the
various routers. It is then extremely easy to obtain the allocation of a class /
32 of IPv6 addresses (which is 128 bits long: there would therefore be a
huge number of allocable subnets). Note that it is possible to propagate Ipv6
routes only if the transit providers support Ipv6 itself.
BGP with Mikrotik RouterOS

At MUM 2013 in Zagreb, Wardner Maia gave a talk entitled "BGP Filtering
with RouterOS", whose slides can be found at the link http://bit.ly/2VpYf14
. In the first part of his speech he made a valid introduction to the BGP
protocol useful for those wishing to further investigate the protocol. In the
following pages we will discuss only two simple basic configurations
through the laboratories.
Lab
Two routers and two PCs are required for this laboratory.
Simple BGP communication between two ASs.
The goal of this laboratory is to create a simple configuration in which two
routers belonging to different AS communicate the routes of their
knowledge to each other.
Simple BGP communication between two ASs.
bgp-lab1
1. Connect the routers as shown in fig bgp-lab1 .

2. We configure the R1 router :
[admin@MikroTik] > /system identity set name=R1
[admin@R1] > /ip address add interface=ether1
address=192.168.1.1/29
[admin@R1] > ip dhcp-server setup
Select interface to run DHCP server on
dhcp server interface: ether1 Select network for DHCP addresses dhcp
address space: 192.168.1.0/29 Select gateway for given network
gateway for dhcp network: 192.168.1.1 Select pool of ip addresses
given out by DHCP server addresses to give out: 192.168.1.2-
192.168.1.6 Select DNS servers dns servers: Select lease time lease
time: 10m
3. We check that the PC-1 has obtained a valid ip address and is able to
communicate with R1:
PC-1> ping 192.168.1.1
4. We also proceed with the R2 configuration:

[admin@MikroTik] > /system identity set name=R2
address=192.168.2.1/29
[admin@R2] > ip dhcp-server setup
Select interface to run DHCP server on
dhcp server interface: ether1
Select network for DHCP addresses
dhcp address space: 192.168.2.0/29

Select gateway for given network
gateway for dhcp network: 192.168.2.1

Select pool of ip addresses given out by DHCP server
addresses to give out: 192.168.2.2-192.168.2.6

Select DNS servers
dns servers:
Select lease time
lease time: 10m
5. Also in this case we check the ip address correct assignment to PC-2

and the communication with R2:
PC-2> ping 192.168.2.1
6. Now let's configure the connection that allows the two routers to
communicate with each other:
address=192.168.100.1/30

address=192.168.100.2/30
7. From R2 we control communication with R1:

[admin@R2] > /ping 192.168.100.1
SEQ HOST SIZE TTL
TIME STATUS
0 192.168.100.1 56 64
10ms
1 192.168.100.1 56 64 2ms
2 192.168.100.1 56 64 0ms
3 192.168.100.1 56 64 1ms
4 192.168.100.1 56 64 0ms
5 192.168.100.1 56 64 0ms
6 192.168.100.1 56 64 0ms
7 192.168.100.1 56 64 1ms
8 192.168.100.1 56 64 0ms
8. Now we have connected all the infrastructure but clearly PC-1 cannot
reach the 192.168.2.0/30 subnet:
PC-1> ping 192.168.2.6
*192.168.1.1 (ICMP type:3, code:0, Destination network
unreachable)
unreachable)
unreachable)
unreachable)
9. Let's go on to configure BGP on R1 :

[admin@R1] > routing bgp instance set 0 router-id=1.1.1.1
as=111
[admin@R1] > routing bgp peer add remote-
address=192.168.100.2 \
remote-as=222
10. We expose the known network and verify the routing table:
[admin@R1] > routing bgp network add network=192.168.1.0/29
[admin@R1] > ip route print

C - connect, S - static, r - rip, b - bgp, o - ospf, m -
mme,
# DST-ADDRESS PREF-
0
ADC 192.168.1.0/29 192.168.1.1 ether1
0
1
ADC 192.168.100.0/30 192.168.100.1 ether2
0
11. Let's go on to configure BGP on R1:

[admin@R2] > routing bgp instance set 0 router-id=2.2.2.2
as=222
address=192.168.100.1 \
remote-as=111
[admin@R2] > routing bgp network add network=192.168.2.0/29
12. We expose the known network and verify the routing table:
[admin@R1] > ip route print interval=1s
mme,
# DST-ADDRESS PREF-
0
ADC 192.168.1.0/29 192.168.1.1 ether1
0
2
ADb 192.168.2.0/29 192.168.100.2
20
1
ADC 192.168.100.0/30 192.168.100.1 ether2
0
13. As you can see, the route known from AS111 has been transferred via
BGP.
14. Similarly the AS111 received the routes known and exhibited by the
AS222:
mme,
# DST-ADDRESS PREF-
0
ADb 192.168.1.0/29 192.168.100.1
20
1
ADC 192.168.2.0/29 192.168.2.1 ether1
0
2
ADC 192.168.100.0/30 192.168.100.2 ether2
0
15. Now the routers are aware of the entire infrastructure and the ping
from PC-1, which had previously failed in step 8., now reaches the
goal:
PC-1> ping 192.168.2.6
Lab
bgp-lab2
Three routers and a PC are required for this laboratory.
Simple multihomed BGP infrastructure.
The goal of this laboratory is to create this configuration that can be
used for sharing the load between ISPs or an ISP as the main and
other ISPs as backup links.
Simple multihomed BGP infrastructure.

bgp-lab2
Suppose the local Internet registry has two networks / 24: 10.1.1.0/24
and 10.1.2.0/24 and our AS is 30. The first network will have been
used for workstations on our corporate network. Part of the other
network will also be used for workstations and another part will be
reserved for servers. At present our company has only one server with
address 10.1.2.130 The goal is to announce our networks assigned to
BGP peers and use only one provider as the main link, the ISP2
connection is for backup only.
1. Connect the routers as shown in fig bgp-lab2 .

2. We load the basic configuration without BGP operations into the
R1, R2 and R3 routers :
{R1}
/ip address
network=192.168.1.0
{R2}
/ip address
network=192.168.2.0
{R3}
/ip pool
add name=dhcp_pool0 ranges=10.1.1.2-10.1.1.254
/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no
interface=ether3 name=dhcp1
/ip address
network=192.168.1.0
network=192.168.2.0
network=10.1.1.0
network=10.1.2.0
network=10.1.2.128
add address=10.1.1.0/24 gateway=10.1.1.1

[admin@R1] > routing bgp instance set 0 as=10
address=192.168.1.2 remote-as=30

address=192.168.2.2 remote-as=30
5. Let's go on to configure BGP on R3 :

address=192.168.1.1 \
remote-as=10 name=isp1
address=192.168.2.1 \
remote-as=20 name=isp2
6. We show the known networks:

[admin@R3] > routing bgp network add
network=10.1.1.0/24 synchronize=no
[admin@R3] > routing bgp network add
network=10.1.2.0/24 synchronize=no
7. We verify the routing table on R1 and R2:

- mme,
# DST-ADDRESS PREF-
0
ADb 10.1.1.0/24 192.168.1.2
20
4
ADb 10.1.2.0/24 192.168.1.2
20
1
ADC 192.168.1.0/24 192.168.1.1 ether1
0

- mme,
# DST-ADDRESS PREF-
0
ADb 10.1.1.0/24 192.168.2.2
20
4
ADb 10.1.2.0/24 192.168.2.2
20
1
ADC 192.168.2.0/24 192.168.2.1 ether1
0
8. Now we will always act on R3 router. The next step is to specify

which routing filter chains will be used, in fact we want to
exclude all the routes not included in our AS:
/routing bgp peer
set isp1 in-filter=isp1-in out-filter=isp1-out
set isp2 in-filter=isp2-in out-filter=isp2-out
in-filter is for input prefixes (reception) while out-filter is for

advertised prefixes.
9. After the chains have been specified, we accept the networks and
throw away everything else because we are not transit suppliers.
As known, one of the BGP attributes that influence the best route
selection is the length of the AS path, the shorter the more
preferred AS path. So we want ISP2 to be just backup, we will
use BGP to increase the length of the AS path to force incoming
traffic through ISP1. Output filters to ISP1:
/routing filter
# We accept our networks
add chain=isp1-out prefix=10.1.1.0/24 action=accept
# We discard everything else
add chain=isp1-out action=discard
Output filters to ISP2 (note the increase in the path as described

on page prepend ):
/routing filter
# We accept our networks and prefix the AS route three
times
set-bgp-prepend=3
set-bgp-prepend=3
# We discard everything else
add chain=isp2-out action=discard
10. Furthermore, we do not need ISP1 routes because the default

route is to use outbound traffic via ISP1 and leave ISP2 as a
backup:
/routing filter
add chain=isp1-in action=discard
add chain=isp2-in action=discard
/ip route
add gateway=192.168.1.1 check-gateway=ping
add gateway=192.168.2.1 distance=30 check-gateway=ping
Useful links
For more laboratories on the BGP protocol the following links can be
consulted:
802.1q
vlan
{«Oh, when the saints go marching in \\ Oh, when the saints go marching in
\\ Lord, how I want to be in that number»} Gospel tradizionale statunitense
IEEE 802.1Q is a standard that allows multiple VLAN virtual networks to

share the same physical connection without losing information between one
device and another. Virtual LAN technology allows segmenting the
broadcast domain of a LAN, dividing it into multiple virtual LANs, isolated
one from each other, but sharing the same physical infrastructure. There are
two ways to create a Virtual LAN:
port tagged VLAN: the switch assigns a VLAN to ports;

IP/MAC tagged VLAN: the switch associates a VLAN with an IP /
MAC address.
This last method guarantees greater security, because one is sure of the
belonging of a specific host to a Virtual LAN; while in the first method, by
simply changing the physical interface, the host is assigned to another
VLAN. In this chapter we will analyze the VLANs realized with the
method that labels the ports of the connection device (port tagged VLAN).
VLANs can also be useful in order to restrict access to resources without
having to change the physical topology of the network. VLANs operate at
level 2 (the Data Link Layer) of the ISO / OSI Stack. The VLANs are
defined inside the switch, through a name and an ID (VID: VLAN
Identificator), this with range 0-4095. To manage multiple VLANs on the
same physical structure, the switch must be able to perform functions of:
Ingress : understand the VLAN from which the frame comes;

Forwarding : to understand the destination port of the frame, based on
the destination VLAN ;
Egress : transmit the frame so that its VLAN membership is correctly
interpreted by other possible switches.
At this point it is useful to pay attention to the used terms, in fact different
switch and router manufacturers use different terms to indicate the same
type of ports. The table table:terms on page table:terms shows the most
common matches. In the VLAN context, the term trunk or core denotes a
network connection transposing multiple VLANs, identified by labels
(called tag ) inserted in their packets. Trunks must be connected to ports
that analyze the tags, the tagged-port , of a VLAN-enabled device: often
these are switch-switch or switch-router connections.
The 802.1q standard

802.1q is the name of the encapsulation protocol used in the trunking
process in Ethernet networks. The 802.1q protocol does not follow the
encapsulation logic but is implemented by adding 4 bytes (32 bits) in the
Ethernet header (figure frame ).
A 802.1q packet
frame
In the 4 added bytes we have:
The first modified 2 bytes concern the tag protocol identifier (TPID)
.
This contains the EtherType tag which is changed to 0x8100, a number
that highlights the new frame format.
The next 2 bytes concern the tag control information (TCI) (also
called VLAN Tag) divided as follows:
user_priority : This 3-bit field can be used to indicate a priority
level for the frame.
The use of this field is defined by the IEEE 802.1p standard.
CFI : 1-bit field that indicates whether the MAC addresses in the
frame are in canonical form.
VID : 12-bit field indicating the ID of the VLANs, which can
thus be up to 4096 (ie 2^{12}).
Of the 4096 possible VLANs, VLANs 0, 1 and 4095 are reserved.
The 802.1q introduces among other things two new protocols:
GVRP: Generic VLAN Registration Protocol - allows switches to

dynamically negotiate which VLANs to manage on a trunk;
MSTP: Multiple Spanning Tree Protocol - evolution of the Spanning
Tree Protocol adapted to the 802.1q context.
Ports types
The ports of a switch can be access, used to connect hosts, or trunks, used
for uplinks among switches or among switches and routers. The trunk is
therefore a link that allows the transport of frames belonging to different
VLANs. Here we have to highlight a very important concept: the frames
run in 802.1q format only on the trunk ports. When forwarded to hosts or
hosts on access ports, the VLAN tag is deleted and the frame format returns
to that of the Ethernet standard. Summarizing what has been explained so
far, in a switch we find two types of ports:
1. Edge ports, (Cisco terminology: access; HP terminology: untagged)

- packets passing through an edge (or access) port do not have a
VLAN tag. In fact on these are connected PCs and devices that know
nothing about VLANs. These are the ports that insert the VLAN tag to
the incoming traffic on the port and remove the VLAN tag from
outgoing traffic to the hosts.
2. Core Ports (Cisco Terminology: Trunk; HP Terminology: tagged)
- a core port is able to receive "tagged" packets, and on these ports
only devices capable of interpreting VLAN tags, such as switches,
routers and firewalls compatible with the 802.1q protocol, can be
connected. These are the ports where traffic travels with the VLAN
tag, which is then left unchanged.
Generi
Cisco HP What it does
c term
Insert the VLAN tag (hence tag) to incoming
Acces Untagge
Edge traffic on the port and remove the VLAN tag to
s d
outbound traffic (directed to hosts).
These are the ports where traffic travels with the
Core Trunk Tagged
VLAN tag, which is then left unchanged.
Comparison of the VLAN terms used by the various producers
table:terms
VLAN on RouterOS
vlan-simple To understand how RouterOS manages VLANs, consider the
diagram in figure lab-vlan1 .
The simplest use of VLANs

lab-vlan1
On router R1, the ether1 network card behaves like a connection (trunk)
that carries the two VLANs up to router R2. This will create two new vlan
type interfaces. On each of these interfaces will be active two dhcp servers
that release the IP addresses related to each of the three VLANs. The router
R2 behaves like a switch with VLAN: it will take the vlan through the trunk
ether1 interface and will route it to the ether2 interfaces for the vlan10 and
ether3 for the vlan20. In RouterOS the management of VLANs passes
through the bridge and interface management menus. Note that the R2
router configuration does not contain any IP address: the router will behave
like a switch operating only at L2 level. The following are the final
configurations of the two routers: {R1}
#
# Definition of vlan and core link (trunk)
#
/interface vlan
add interface=ether1 name=vlan10 vlan-id=10
/ ip pool
add name=vlan10 ranges=10.10.10.100-10.10.10.200
/ip dhcp-server
add address-pool=vlan10 disabled=no interface=vlan10
name=vlan10
name=vlan20
/ip address
add address=10.10.10.1/24 interface=vlan10 network=10.10.10.0

add address=10.10.10.0/24 netmask=24
{R2}
#
# Definition of core port (trunk)
#
/interface vlan
#
# Definition of bridges for edge ports
#
/interface bridge
add fast-forward=no name=bridgevlan10
#
# Vlan extraction from bridges
#
add bridge=bridgevlan10 interface=vlan10
add bridge=bridgevlan20 interface=ether3
Lab on trunk propagated among switches
trunk-lab
Three routers and at least one PC are required for this laboratory.
VLAN
The aim of this workshop is to learn how to propagate a trunk among
different switches.
VLAN - lab on trunk propagated among switches

lab-vlan3
The network infrastructure to be configured is that of figure lab-vlan3 . The
peculiarity of the laboratory is the propagation of the trunk from router R2
to router R3. In particular see the configuration of the R2 router and the use
of the bridgevlan1030 bridge and its ports. {R1}
/interface vlan
/ip pool
/ip dhcp-server
name=vlan10
name=vlan20
name=vlan30
/ip address
{R2}
/interface bridge
add name=bridgevlan1030
/interface vlan
add interface=bridgevlan1030 name=vlan10 vlan-id=10
/interface bridge vlan
add bridge=bridgevlan1030 tagged=ether3,ether4 vlan-ids=10,30
{R3}
/interface bridge
/interface vlan
Lab
Two routers and at least one PC are required for this laboratory.
VLAN
The goal of this workshop is to start handling VLANs in RouterOS using
the WinBox interface.
VLAN - lab
lab-vlan2
The network infrastructure to be configured is that of figure lab-vlan2 . On
the router R1, in the network cards ether1, ether2 and ether3 three dhcp
servers are active which release the IP addresses related to each of the three
VLANs. The R2 router behaves like a switch with VLAN.
1. First of all, new interfaces are created by indicating the VLAN ID.
Each VLAN interface refers to a physical interface that determines the
trunk.
2. The process is repeated for each VLAN:
3. Subsequently, bridge type interfaces are created which will be useful
for configuring the access/untagged ports.
4. Among the ports of each switch there will always be the vlan
concerned and the ethernet NIC:
5. At this point, we need to configure the three dhcp servers with their
pools.
Remember that ip addresses and dhcp servers must be anchored to the
respective bridge interfaces.
6. The following are the final configurations of the two routers:
{R1}
/interface vlan
/interface bridge
/ip address
add address=10.10.10.1/24 interface=bridgevlan10
network=10.10.10.0
network=10.20.20.0
network=10.30.30.0
/ip pool
/ip dhcp-server
add address-pool=vlan10 disabled=no interface=bridgevlan10
name=vlan10
name=vlan20
name=vlan30
7. Note that the R2 router configuration contains no IP address:

the router will behave like a switch operating only at L2 level. {R2}
/interface bridge
/interface vlan
8. To verify the correct functioning of the created network infrastructure,

just check the IP address that each PC gets depending on the port to
which it is connected.
For further examples see the link http://bit.ly/2Fje2dp which also includes a
detailed explanation.
Comparison of configurations
In this chapter we have repeatedly mentioned brands like Cisco and HP, for
completeness in the next two pages we report in synopsis the R2
configurations of the laboratory of figure lab-vlan1 on page lab-vlan1 is the
R2 configurations of the laboratory of figure lab-vlan3 on page lab-vlan3
comparing what happens in Mikrotik RouterOS, in HP and in Cisco IOS.
Mikrotik RouterOS
/interface vlan
add interface=ether1 name=vlan10 \
vlan-id=10
add interface=ether1 name=vlan20 \
vlan-id=20
/interface bridge
add fast-forward=no \
name=bridgevlan10
name=bridgevlan20

add bridge=bridgevlan10 \
interface=vlan10
interface=vlan20
interface=ether3
interface=ether2
HP
vlan 10
name "vlan10"
untagged 1
tagged 3
exit
vlan 20
name "vlan20"
untagged 2
tagged 3
exit
Cisco IOS
vlan database
vlan 10
vlan 20
exit
configure terminal
interface FastEthernet1/2
switchport mode access
switchport access vlan 10
!
!
switchport mode trunk
switchport trunk allowed vlan all
!
Mikrotik RouterOS
/interface bridge
name=bridgevlan10
name=bridgevlan20
add name=bridgevlan1030
/interface vlan
add interface=bridgevlan1030 \
name=vlan10 vlan-id=10
interface=vlan10
interface=vlan20
interface=ether1
interface=ether2
interface=ether4
interface=ether3
/interface bridge vlan
tagged=ether3,ether4 \
vlan-ids=10,30
HP
vlan 10
name "vlan10"
untagged 1
tagged 3-4
exit
vlan 20
name "vlan20"
untagged 2
tagged 3
exit
vlan 30
name "vlan30"
tagged 3-4
exit
Cisco IOS
vlan database
vlan 10
vlan 20
vlan 30
exit
configure terminal
!
!
!
!
Important note on performance
Many MikroTik devices have built-in switch chips that typically have the
ability to perform VLAN switching at the hardware level, which means that
wire-speed performance can be achieved using VLANs if an appropriate
configuration method is used. The configuration method changes between
different models. For configuration examples that follow the hardware
specifications, see the link http://bit.ly/2Fg8jVu .
RouterOS /32 and IP addresses unnumbered IP

Reading the literature on VLANs often the unnumbered IP expression is
encountered. This is an IP /32 address that allows you to enable IP
processing on an interface without assigning it an explicit IP address. We
can approximate this by stating that an interface with an unnumbered IP
"borrows" the IP address of another interface already configured on the
router, which preserves the network and the address space. To learn more
about the subject, refer to the article available at the link
http://bit.ly/2FhTT6y . The question that arises is: why use an address /32
and not just configure an IP address on the interface? To answer this
question we must immerse ourselves in the past. At the beginning of the
Internet, the subnet masks with variable length, ie the VLSM numbering
(Variable Length Subnet Mask) were not available and this was particularly
annoying when using classful routing protocols such as RIP v1 and IGRP,
the predecessor of EIGRP. With the VLSM numbering the smallest subnet
that could be used was /24. Imagine what a waste when using public IP
addresses. IP unnumbered was created to solve this problem so as not to
waste entire subnets /24 on point-to-point interfaces: the IP unnumbered
mechanism borrows an IP address from another interface so as not to have
to configure one on the point-to-point interface. Nowadays we have
multiple alternatives: we can use VLSM and create subnets /30 without
wasting many IP addresses; or we can use private IP addresses, if our
network allows it. It follows that we no longer need unnumbered IP as in
the past. However, it can be useful if you want to quickly set up a point-to-
point connection without worrying about IP addresses and finding a suitable
subnet. RouterOS offers the possibility of using the address with a network
mask of /32 for example in a point-to-point tunnel with addresses and this
offers the same functionality as the unnumbered IPs of other manufacturers.
Unnumbered IP
unnumbered
In the infrastructure of figure unnumbered there are two routers R1 and R2,
each of which is part of the networks 10.22.0.0/24 and 10.23.0.0/24
respectively. The following configurations using IP unnumbered are used to
connect these routers using VLANs as carriers: {R1}
/interface vlan add interface= ether2 vlan-id=10 name=vlan10
/ip address add address=10.22.0.1/32 interface=vlan10
network=10.23.0.1
/ip route add gateway=10.23.0.1 dst-address=10.23.0.0/24
{R2}
/interface vlan add interface=ether2 vlan-id=10 name=vlan10
/ip address add address=10.23.0.1/32 interface=vlan10
network=10.22.0.1
/ip route add gateway=10.22.0.1 dst-address=10.22.0.0/24
Summary questions
domande-4
1. Is it possible to create a configuration where VLANs and PPTP

interfaces coexist in a bridge?
1. Yes
2. No
2. Is it possible to create a wireless point-to-point network where the
connection among the two antennas behaves like a VLAN trunk?
1. Yes
2. No
Solutions
1. Yes. On this see the interesting speech "VLAN in MikroTik" by

Mohammed Khomeini Bin ABU at MUM 2013, in particular from
slide 13 (http://bit.ly/2Qz3Xdg)
Yes. On this see http://bit.ly/2QvImTb which shows the complete
configuration of a typical use case.
Tunnel
{«Come on and take a low ride with me girl \\ on the tunnel of love»} Dire
Straits
Virtual Private Network

The term VPN identifies a Virtual Private Network. They allow the
exchange of data among company offices spread over the territory and
represent a service of greater interest for Business customers. It is said that
the network is private as it allows private communications among company
sites, in the same way as a physical private network (eg routing and
addressing schemes are maintained) It is said that the network is virtual
because the connections are virtual and not physical. The physical support
network is public and not private, but resource management and security
techniques are such as to "virtualize" it as if it were private. As an example,
a university institute can activate a VPN to allow its students to consult
from home publications for which they have subscribed; as long as the user
has the VPN service activated, all his requests pass through the institution's
servers, as if the connection were made locally, thus obtaining access to
reserved subscription services; at the same time the user is also subjected to
the policies of the manager who can for example encrypt or not the server-
user connection or inhibit some protocols such as P2P or access to internet
sites inserted in a black list.
Virtual Private Network.

vpn
There is a necessary condition within the same VPN addressing must be
unique. A VPN can be implemented at any of the ISO / OSI levels, for
example:
1. Layer 1. Physical VPN, for example with a DDC (Digital Direct

Circuit), the "old" dedicated lines.
2. Layer 2. VPN data link, for example ATM PVC or the VLANs
described in the previous chapter.
3. Layer 3. VPN network like IPsec, tunneling,.. .
4. Layer 4. Transport-level VPN like TLS.
At present, the term VPN is generally referred to as a layer 3 network

infrastructure. We can identify two modes of data transport:
1. Overlay: the public network offered by the ISP offers only transport
functions and the routing information is exchanged only among
company sites.
In this case the topology (logical and physical) is composed of point-
to-point links defined by the customer (customer). If we consider these
point-to-point links we can identify a "superimposed" network (lett.
Overlay) to the physical network.
2. Peer-to-peer: the public network offered by the ISP also exchanges
routing information with the company sites.
In this case the logical topology is defined by the customer, the
physical topology that realizes the logical topology, is decided by the
provider according to specific traffic engineering criteria in its
network.
On Peer-to-Peer VPN, where routing takes place on a layer composed of

both entities residing in the company and entities residing in the ISP, we
will return to this later talking about MPLS (see section mpls starting from
page mpls ). In this first part we will devote ourselves to the VPN overlays
that are generally implemented on the public internet network. In this case
the communications security must be realized ent-to-end, as one cannot
trust in a secure transport network; for this reason the reference model
envisages the creation of secure tunnels between the VPN end-points.
Tunnel
The term tunneling refers to a techniques set for which a protocol is
encapsulated in a protocol of the same level or higher level to realize
particular configurations. The security of the communication is obtained
through the encryption of the data that are inserted inside the tunnel and the
authentication of the end-points. The data packets are modified upon
sending by adding a header that will allow you to go through the tunnel;
subsequently, when they reach the destination, at the end of the tunnel, the
header will be removed returning the original package. Often the terms
"tunnel" and "VPN" are used interchangeably, but it is not a correct
approach. Protocols defining tunnels:
IPIP – IP Tunnel
EoIP – Ethernet Over IP
VLAN – Virtual Lan
MPLS – Multi Protocol Label Switching
Gre Tunnel
Protocols defining VPN:
PPPoE – PointToPointProtocol Over Ethernet

PPTP – PointToPoint Tunnel Protocol
L2TP – Layer 2 Tunnel Protocol
OpenVPN – Open Virtual Private Network
IPSec – IP Security
SFTP – Secure Socket Tunnel Protocol
In this text we will address:
IPIP – IP Tunnel - page ipip

EoIP – Ethernet Over IP - page eoip
VLAN – Virtual Lan - page vlan
MPLS – Multi Protocol Label Switching - page mpls
IPSec – IP Security - page ipsec
RouterOS provides different types of tunnels and VPNs: PPTP, L2TP,

PPPoE, EoIP, SSTP, OpenVPN, etc. The types that can be used are visible
in the list of virtual interfaces (see figure vpn-list ).
List of available virtual interfaces.
vpn-list
Chapter 8 of the book "Theory, laboratories and exercises for Mikrotik
RouterOS" is dedicated to the main VPN protocols (see
https://amzn.to/2Qm4S0L ), so the common protocols like PPTP and
PPPoE will be omitted in the following sections. to investigate more
complex protocols such as IPsec and MPLS. For an analysis on which
VPN use in your network infrastructure it is recommended to refer to the
talk of Andis Arins at the MUM Europe of Ljubljana of March 25, 2016:
http://bit.ly/2Qjloi1 .
IP addresses on point-to-point networks
In general, to connect 2 devices we will use IP with a minimum of subnet

/30, where there will be 2 usable hosts, for example:
Network Broadcast
Usable addresses
address address
172.16.1.1-
172.16.1.0/30 172.16.1.3
172.16.1.2
In Mikrotik, these needs can be met using the IP /32 subnet or the single IP:
it is an IP address addressing system for two directly connected devices.
Since it uses only 2 IP addresses, there is no transmission address, but the
network IP must be set manually with a remote IP address. The most
obvious example is the implementation of a PPTP VPN. In the Secret tab of
the PPTP server the local and remote address parameters use IP /32:
After the PPTP tunnel is created, a new IP address will be displayed on both
sides of the router with subnet /32. Comparing the server side and the client
side of the VPN we note the different position of the IP address:
In addition to the VPN service, point-to-point addressing can be applied

manually to the installation of 2 directly connected devices. This method is
widely used by ISPs with the goal of an efficient use of the public IP. For
example, an ISP could assign the IP address 222.152.211.0/30 to the client.
The ISP will use an IP taken from the subnet /30 interval as a gateway, so
the client will have only one address that can be installed on the device.
However, with the concept of point-to-point addressing, the IP
222.152.211.0/30 will be completely available to the client and this
provides the client with two IP addresses. How could the ISP do not
"waste" IP addresses? Here is the solution.
Point-to-point topology with /32 addressing.

Addresses to be set in the two routers in IP > Addresses :
Point-to-point addressing.
Static route to be set on R1 towards router R2. This route has the point-to-
point address as gateway:
For the R2 router we use the description on page loopback about the
loopback interface. In this case the IP address is installed on the fictitious
bridge interface, ie the bridge was created without any bridge port assigned.
At this point proceed in the configuration as usual, the only changes
concern the NAT settings and the default gateway that must take into
account the exit address from the router:
NAT configuration of the R2 router
NAT settings are made so that the client can access the internet. According
to the above, internet access is made through the public IP, not through the
point-to-point IP, so the address must be forced, ie it must be 222.152.211.1,
when the client packet leaves the router:
R2 default gateway configuration

To obtain this "forcing" we use the Pref-Source property, studied on page
pref-src , so that when the packet exits the router it is used as IP
222.152.211.1.
IP-in-IP
ipip The IP-in-IP tunneling implementation, also briefly referred to as IPIP,
on MikroTik RouterOS complies with RFC 2003; many routers, including
Cisco and Linux, support this protocol. The IPIP tunnel is a simple protocol
that encapsulates IP packets in a tunnel between two routers. The IPIP
tunnel interface appears as an interface below the list of interfaces but it is
not possible to insert the IPIP interface as a port in a bridge. The protocol
adds the following possibilities to a network infrastructure:
it can be used to transport intranets through the internet;

it can be used instead of source routing .
IP-in-IP encapsulation.
IP_in_IP_Encapsulation
To encapsulate an IP packet in another IP packet (see figure
IP_in_IP_Encapsulation ), an external header is added with the SourceIP,
the entry point of the tunnel and the destination, the exit point of the tunnel.
While doing this, the internal packet is not modified (except the TTL field,
which is decremented). The Do not Fragment and Type Of Service fields
are copied to the external package. If the packet size is larger than the path
MTU then the packet is fragmented during encapsulation because the
external header must be included. Upon arrival at destination the package
will be reassembled.
GRE vs IPIP
The encapsulation of generic routing (GRE) and IP-in-IP (IPIP) are two
rather similar tunneling mechanisms that are often confused. IP-in-IP
encapsulation is exactly what it seems: one IP packet encapsulated within
another (see figure ipip_encapsulation ). The external header protocol field
is set to 4 for IPv4 or 41 for IPv6.
IPIP encapsulation.
ipip_encapsulation
The GRE (defined in RFC 2784 and updated by RFC 2890) goes one step
further than IP-in-IP, adding an additional header inside and outside the IP
headers (see figure gre_encapsulation ).
GRE encapsulation.
gre_encapsulation
This addition allows the GRE protocol to:
encapsulate any level three protocol (with respect to IP only);

adds an additional checksum (which is not useful for TCP / IPv4);
specify a key for the tunnel;
apply packet sequencing.
On the other hand these features have an additional cost of overhead; in

cases where GRE functionality is not required, IPIP is a good choice.
Lab
IPIP tunnel
The objective of this laboratory is to realize the infrastructure of figure
ipip2 starting from that of figure ipip .
IPIP tunnel.
ipip
1. Connect the routers as shown in fig ipip .
2. We configure the R1, R2 and R3 routers for basic connectivity:
{R1}
/ip address
{R2}
/interface bridge add name=bridge1
/interface bridge port add
interface=ether1 bridge=bridge1
/ip address
add address=10.10.10.30/24 interface=bridge1
{R3}
/ip address
3. We check the connection from router R1 to R3:

[admin@R1] > /ping 10.10.10.31
SEQ HOST SIZE TTL
TIME STATUS
0 10.10.10.31 56 64
18ms
1 10.10.10.31 56 64
2ms
2 10.10.10.31 56 64
2ms
3 10.10.10.31 56 64
6ms
4 10.10.10.31 56 64
2ms
sent=5 received=5 packet-loss=0
4. We create the tunnel by acting on the routers R1 and R3:

{R1}
/interface ipip add name=ipip local-address=10.10.10.30 \
remote-address=10.10.10.31
/ip address add address=192.168.200.1/30 interface=ipip
{R3}
/interface ipip add name=ipip local-address=10.10.10.31 \
/ip address add address=192.168.200.2/30 interface=ipip
5. We check the connection from router R3 to R1 but using the ip

addresses of the tunnel :
[admin@R3] > /ping 192.168.200.1
SEQ HOST SIZE TTL
TIME STATUS
0 192.168.200.1 56 64 9ms
1 192.168.200.1 56 64 3ms
2 192.168.200.1 56 64 4ms
6. We modify the infrastructure by connecting the two PCs as in figure

ipip2 .
Tunnel IPIP con routing.

ipip2
7. We modify the configuration of R1 and R3 for basic connectivity:
{R1}
/ip address
/ip pool
/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no interface=ether2
name=dhcp1
{R3}
/ip address
/ip pool
/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no interface=ether2
name=dhcp1
PC-1> ping 192.168.1.1
PC-2> ping 192.168.2.1
10. Check if the PC-1 can reach PC-2:

PC-1> ping 192.168.2.1
unreachable)
unreachable)
unreachable)
unreachable)
unreachable)
11. As expected, PC-1 does not reach PC-2.

12. On R1 and R3 we add the necessary static routes that use the IPIP
tunnel:
{R1}
gateway=192.168.200.2
{R3}
gateway=192.168.200.1
13. Check if the PC-1 can reach PC-2:

PC-1> ping 192.168.2.1
14. As expected, communication is now successful .

15. Note that the connection is made through the IPIP tunnel and PC-1 has
no knowledge of the internal infrastructure,
for example of R2:
PC-1> ping 10.10.10.100
EoIP
eoip
How the protocol works

Ethernet over IP (EoIP) is a MikroTik RouterOS protocol that creates an
ethernet tunnel between two routers over an IP connection. The EoIP tunnel
can be created over IPIP tunnels, PPTP tunnels or any other connection
capable to carry the IP protocol. When the bridging function is enabled, all
ethernet traffic is part of a bridge in the same way as a physical Ethernet
interface and a cable between the two routers (with bridging enabled). In
fact, the EoIP protocol encapsulates the Ethernet frames in GRE packets (IP
protocol number 47) and sends them to the remote side of the EoIP tunnel.
Lab
Tunnel EoIP
eoip-lab with a dhcp server between the two external routers.
Tunnel EoIP.
eoip-lab
1. Connect the routers as shown in fig eoip-lab .

2. We configure the R1, R2 and R3 routers for basic connectivity :
{R1}
/ip address
{R2}
/ip address
{R3}
/ip address
3. We check the connection from router R1 to R3:

[admin@R1] > /ping 10.10.10.31
SEQ HOST SIZE TTL
TIME STATUS
0 10.10.10.31 56 64
18ms
1 10.10.10.31 56 64
2ms
2 10.10.10.31 56 64
2ms
3 10.10.10.31 56 64
6ms
4 10.10.10.31 56 64
2ms
4. We create the tunnel operating on routers R1 and R3:

{R1}
/interface eoip add name=eoip local-address=10.10.10.30 \
remote-address=10.10.10.31 tunnel-id=0
{R3}
/interface eoip add name=eoip local-address=10.10.10.31 \
remote-address=10.10.10.30 tunnel-id=0
5. Still on R1 and R3 we create a bridge and insert ether2 and the

endpoint of the EoIP tunnel among the ports:
{R1}
/interface bridge port add interface=ether2 bridge=bridge1
/interface bridge port add interface=eoip bridge=bridge1
/ip address
{R3}
/interface bridge port add interface=ether2 bridge=bridge1
/interface bridge port add interface=eoip bridge=bridge1
/ip address
6. On the R1 router we create a DHCP server that provides the ip

addresses to our two LANs:
{R1}
/ip pool
/ip dhcp-server
add address-pool=dhcp_pool0 disabled=no interface=bridge1
name=dhcp1
7. We check that the PC-1 and PC-2 have obtained a valid ip address and
are able to communicate with each other:
PC-1> show ip
NAME : PC-1
IP/MASK : 192.168.200.198/24
PC-2> show ip
NAME : PC-2
IP/MASK : 192.168.200.197/24
PC-1> ping 192.168.200.197

84 bytes from 192.168.200.197 icmp_seq=1 ttl=64
time=2.266 ms
time=4.836 ms
time=1.444 ms
time=1.636 ms
time=1.546 ms
IPsec
ipsec
IPsec (IP SECurity) is a family of IETF protocols aimed at making the

communications that use IP protocol more secure. It rests directly on the IP
protocol at the ISO / OSI 3 level; it can be implemented directly through
specific hardware, or via software: in the case of hardware
implementations, it will be completely transparent to the machine,
applications and operating system, while in the case of software
implementation, the operating system must be modified. IPsec was first
developed within the IPv6 standard and later incorporated into IPv4. The
main protocols that make up IPsec are described in the following RFCs:
RFC 2401 : Security Architecture for the Internet Protocol

RFC 2402 : IP Authentication Header
RFC 2406 : IP Encapsulating Security Payload (ESP)
RFC 2409 : The Internet Key Exchange (IKE)
The issues that affect IPv4 and that IPsec tries to overcome are:
Integrity : although each IP packet has a control of

integrity through a checksum (CRC), the used algorithms are very
weak and not sufficient to guarantee the packets integrity; therefore the
recipient cannot be sure that the packet that receives is identical to the
one sent and that is not been modified, voluntarily or not, during the
journey.
Authenticity : anyone can send a packet by placing the IP number of
another host as the sender (source) (this is usually called spoofing)
therefore the receiver (recipient), using only the data present in the IP
headers, cannot be sure of who is the sender of the packet.
Confidentiality : the whole packet, and the data (payload) carried in it,
are in readable form, so anyone that can intercept (also know as
sniffing) the packet can read the content.
IPsec uses the following communication strategies:
Mutual authentication before and during communications.

Confidentiality through the encryption of IP traffic.
IP traffic integrity as edited traffic is refused.
To obtain these three results, it adopts the following protocols:
AH (Authentication Header): provides integrity, authentication,

protection from
replay attacks.
ESP (Encapsulating Security Payload): provides confidentiality in
addition to AH.
IKE (Internet Key Exchange): protocol for secure exchange of
cryptographic keys.
IPsec does not define the specific security algorithm (encryption, ...) to be
used but provides a way to indicate which algorithm is chosen, allowing
the use of the algorithms most suited to the needs of the moment. For
example, integrity is normally controlled using the MD5 or SHA
algorithm, while encryption is often done using DES.
We must distinguish two modes of operation of IPsec:
1. the case in which IPsec is used between two hosts that are the traffic
extreme points, called transport mode. In this case L4 datagrams are
encapsulated.
2. all other cases (router-router, computer-router etc.) where at least one
of the two extremes is not the final destination of the traffic (Gateway),
called tunnel mode; in this case the
gateway sends and receives traffic to and from the final recipient using
the usual IP protocol. In this case the entire L3 packet is encapsulated.
The most significant logical difference between the two modes is that in the
second case in the packet carried by IPsec there must be both an indication
of the gateway and of the final non-IPsec recipient, while in the first case
the latter is not necessary. All communications between the two hosts
connected by an IPsec tunnel and identified by their IPv4 address must pass
via IPsec: therefore if a host receives a non-IPsec IPv4 packet with an IP
address of an IPsec partner, it must discard it. It should be noted that each
tunnel is unidirectional, so to communicate the two hosts must establish two
tunnels, one for each direction. The IPsec initialization procedure is called
IKE (Internet Key Exchange), we will discuss some details of which later.
Once the procedure has been successfully completed, two Security
Association (SA) are created, which are the collection of all the parameters
that characterize the two IPsec tunnels that connect the two hosts; in
practice, the SA uniquely identifies the tunnels. At this point, finally, host
A, using the appropriate SA, transforms the original package into an IPsec
package and sends it to B. B, also having the two SAs, can transform the
IPsec package in the original package. Then, similarly, B can respond to A.
After the initial phase of tunnel creation (IKE), IPsec finally begins to
exchange data between the two hosts. For this operation two protocols are
available: Authentication Header (AH) and Encapsulating Security Payload
(ESP). It should be noted that AH does not offer confidentiality, ie the data,
the payload, are not encrypted, while ESP allows the data to be encrypted.
On the other hand, AH also guarantees the integrity of the packet IP Header
(with the exception of some parts that can be changed as discussed below),
while ESP guarantees the integrity only of the payload of the IP packet.
Putting together the two transmission modes (Tunnel and Transport) with
the two IPsec Protocols (AH and ESP), we obtain the four main types of
data packets created and transported by IPsec. Since the initialization phase
is slow and complicated, we therefore have that an IPsec tunnel is created
and remains active for a certain period of time, whether there is traffic or
not. When the time expires, if there is no traffic the tunnel is closed or the
SAs are regenerated. We have said that each SA can be associated with
different security features and that it takes two SAs to have complete
protection of a two-way channel, to manage this you use two local IPsec
databases that store the necessary information:
SAD (SA Database): lists the active SAs and specifies their
characteristics for each SA:
Sequence number counter (32 bit)
AH information (algorithms, keys, validity time,...)
ESP information (algorithms, keys, validity time,,...)
Lifetime of SA: time or numbers of bytes after which the SA
must be replaced or terminated
IPsec mode: transport or tunnel
SPD (Security Policy Database): contains the security policies to be
applied to the different types of communication, ie it specifies which
services must be offered to the different types of IP traffic, such as:
All traffic to 192.168.2.1 must be protected by ESP in transport
mode using DES
All FTP traffic (TCP, port 20) to 192.168.2.2 must be protected
by ESP in tunnel mode using 3DES
All traffic to 192.168.2.3 must not be protected.
Therefore SPD consists of policy entries with, for example, one or
more selectors that specify the IP traffic managed by this entry, from
the indication whether the matching traffic must be discarded, bypass
IPsec or be subjected to IPsec processing.
How IPsec works - dispatch

ipsec-send
How IPsec works - reception with AH
ipsec-receive-ah
IPsec on RouterOS
First of all it should be noted that in RouterOS to activate IPsec process

there must be traffic that corresponds to an IPsec criterion. What should I
configure?
Configure phase 1: it is the phase that generates the SAs that will be
used later to encrypt all the traffic:
using the IP > IPsec > Peers entry it is necessary to add a new
peer indicating the address of the other IPsec point, the shared
password to start the generation of the certificates and if the
packets must be encapsulated inside a UDP packet to traverse the
NATs;
indicate the encryption and authentication algorithms that will be
used;
indicate the DPD values (Dead Peer Detection) to automatically
detect any timeouts.
Configure phase 2: this phase tells the router what to encrypt and
which one to use:
using the IP > IPsec > Policies entry you define the traffic to be
encrypted, for example by indicating the source address or the
recipient, ...
using the IP > IPsec > Policies Proposals entry, you indicate to
the router which algorithm to use for encryption and the hash
function to be used for phase 2.
By referring to the phases of IPsec communication we can summarize the

RouterOS commands in the following groups:
/ip ipsec peer - defines the settings for phase 1 for IPsec peers;
/ip ipsec policy - defines which traffic to process and how to
process it;
/ip ipsec proposal - defines the encryption and algorithms to use.
Hint. To enable the specific log for IPsec use the command: \\ /system
logging add topics=ipsec
Now we are ready to set up a simple site-to-site IPsec VPN. For the two
configurations that follow refer to the infrastructure in figure ipsec-site-to-
site .
Simple site-to-site IPsec VPN

ipsec-site-to-site
Tunnel mode
# Define peer (Phase 1)
/ip ipsec peer
add address=2.2.2.2/32
dh-group=modp2048
dpd-interval=10s
dpd-maximum-failures=3
encalgorithm=aes-256
hash-algorithm=sha512
secret=superSecret
# Define policy (Phase 2)
/ip ipsec policy
add dst-address=10.2.2.0/24
sa-dst-address=2.2.2.2
sa-src-address=1.1.1.1
src-address=10.1.1.0/24
tunnel=yes
# IPsec tunnel traffic
# don't be into NAT
/ip firewall nat
add action=accept chain=srcnat
dst-address=10.2.2.0/24

# Define peer (Phase 1)
/ip ipsec peer
dh-group=modp2048
dpdinterval=10s
encalgorithm=aes-256
secret=superSecret
# Define policy (Phase 2)
/ip ipsec policy
sa-dst-address=1.1.1.1
sa-src-address=2.2.2.2 s
rc-address=10.2.2.0/24
tunnel=yes
# IPsec tunnel traffic
# don't be into NAT
/ip firewall nat
add action=accept chain=srcnat
Transport mode
# Configurazione IPsec
/ip ipsec peer
dh-group=modp2048
dpdinterval=10s
enc-algorithm=aes256
secret=superSecret
/ip ipsec policy
protocol=gre
# Tunnel GRE per il traffico
/interface gre
add clamp-tcp-mss=no
dont-fragment=inherit
keepalive=10s,3 mtu=1400
name=gre-tunnel1
# routing
/ip address
interface=gre-tunnel1
/ip route
add distance=1
gateway=10.255.0.2

# IPsec setup
/ip ipsec peer
dh-group=modp2048
dpdinterval=10s
enc-algorithm=aes256
secret=superSecret
/ip ipsec policy
protocol=gre
# Tunnel GRE ready fro traffic
/interface gre
add clamp-tcp-mss=no
dont-fragment=inherit
keepalive=10s,3 mtu=1400
name=gre-tunnel1
# routing
/ip address
interface=gre-tunnel1
/ip route
add distance=1
gateway=10.255.0.1
IPsec/XAuth
At MUM 2018 in Berlin, Tomas Kirnak gave an interesting talk on the
IPsec / XAuth protocol often called "Cisco IPsec". The talk slides are
available at the link http://bit.ly/2RlSeEg while a detailed description of the
protocol is available at the link http://bit.ly/2RmuWOD . VPNs are often
used by network administrators to remotely manage customer networks,
other times there are requests from some user who has to work from remote
locations or from companies that need access to manage some equipment.
In summary we can say that often the required configuration is client-to-site
with the client located behind a NAT network. There are many options that
can be used to offer the customer these opportunities:
PPTP (very insecure )

SSTP
OpenVPN
L2TP / IPSec
IPSec Xauth mode-config
IKEv2
The choice of IPsec / Xauth mode-config is very interesting because it:
is supported by almost all operating systems, including mobile,

it's not TCP-based,
supports keys, certificates and shared password,
the router automatically sends the route configuration to the client (in
this way you can limit what the client sees of the destination network),
of the dns (so the client can resolve local names), ...
there are free software to further simplify client configuration.
As a first step it is necessary to prepare the configuration that will
subsequently be sent to the clients. Most of the configuration is
automatically deduced from what is set in the peer and in its profile. By
setting peer configuration generate-policy=port-strict the IPsec
policies are automatically generated.
IPsec/XAuth - configuration to send to clients

IPsec/XAuth - Peer profile
IPsec/XAuth - Peer - General
IPsec/XAuth - Peer - Advanced
Definiamo come cifrare il traffico:

IPsec/XAuth - Policy proposal
Aggiungiamo un utente:
IPsec/XAuth - adding a user

Below i is the resulting final configuration for the router that will accept the
connection and provide the configuration to the clients:
# Setup XAuth in mode-config

/ip pool
add name=vpn-admins ranges=10.10.10.10-10.10.10.20
/ ip ipsec mode-config
add address-pool=vpn-admins name=vpn-admins
split-include=10.4.11.0/24,192.168.0.0/24 static-
dns=1.2.3.4
system-dns=no
# Define peer
/ip ipsec peer profile
add dpd-interval=10s dpd-maximum-failures=3
enc-algorithm=aes-256,3des
hash-algorithm=sha512 name=vpn-admins
/ip ipsec peer

add address=0.0.0.0/0 auth-method=pre-shared-key-xauth
generate-policy=port-strict mode-config=vpn-admins
passive=yes
secret=thisIsSuperSecret
# Adding user
/ip ipsec user
add name=username password=password
# Define how to crypt traffic

/ip ipsec proposal
set [ find default=yes ] auth-algorithms=sha256
enc-algorithms=aes-128-cbc pfs-group=modp2048
Now all that remains to do is to configure the client. In this case we show
the client configuration for OSX, for other clients like Microsoft Windows
or Android see the document http://bit.ly/2C9S2xn . To configure the Apple
OSX VPN client:
1. Go to System Preferences > Network

2. Press on the + symbol at the bottom left
3. Create a Cisco IPsec VPN and assign the name you prefer
4. Enter the following parameters
1. address: (indicate the IP of the IPsec VPN server)
2. user: username
3. pass: password
5. Click on advanced and as a pre-shared key use thisIsSuperSecret.
MPLS
mpls The idea behind the MPLS protocol (Multi Protocol Label Switching )
is to forward packets based on a label instead of the destination IP address.
This approach produces faster searches in the forwarding table since the
label can be used as an index instead of the longest prefix matching and also
allows a more refined control of the traffic. The idea behind the MPLS
protocol (Multi Protocol Label Switching) is to forward packets based on a
label (label) instead of the destination IP address. This approach produces
faster searches in the forwarding table since the label can be used as an
index instead of the longest prefix matching and also allows a more refined
control of the traffic. The MPLS protocol was created in response to the
problems that the network was encountering in its development in the early
1990s. Among these we have the complexity of routing, the use of different
technologies that are difficult to integrate like IP and ATM and scalability
problems. MPLS solves these problems in a simple and effective way: it
places itself between the data of the second level protocol and those of the
third level protocol, adding its own header, which contains a label in which
all the necessary information for routing are defined of the package. In this
way the data of the third level protocol are transparent to the routers of the
network; thanks to MPLS I can therefore use the same router to pass
different protocol packets, even if it is typically used with IP type packets.
MPLS completely separates the control component (communication
between nodes and update routing tables) and the component that realizes
the actual routing of the packets based on the routing tables, called
forwarding component. The heart of an MPLS network is formed by a set
of routers capable of routing packets solely through the content of the
MPLS labels. These routers are called LSRs (Label Switch Routers), which
form together an area called the MPLS backbone as exemplified in figure
mpls-dominio .
Multi Protocol Label Switching (MPLS) domain.
mpls-dominio
However, the packets start from the users' routers without MPLS header,
but only with the protocol data of the third level. We will have special
routers located at the border of the MPLS backbone that add the MPLS
label based on the data of the third level and route the packet to the
backbone. On the other hand, normal LSRs usually do not use the third
level protocol header. The path followed by a packet through multiple LSRs
is called LSP (Label Switched Path ).
MPLS packet.
mpls-label
Now a bit of routing theory: in a connectionless network, like the IP
network, the path followed by a packet between the source and the
destination is determined by the composition of elementary and
independent routing operations performed by the routers that are traversed
from the package. Each router chooses the next router to which re-launch
the packet. This choice is performed by examining the header of the packet
and accessing a updated routing table by using a routing protocol. This is
the Router Information Base (RIB) table introduced on page rib . The
choice of the next-hop operated by a router can be modeled as the
concatenation of two distinct functions:
1. the subdivision of the set of packages to be re-launched in a series of

distinct subsets, called FEC (Forwarding Equivalent Class );
2. the association of a FEC to a specific next-hop.
According to this model, the packets belonging to the same FEC will be
relayed by a router to the same nexthop. In particular, in an IP network, a
router will classify two packets, which carry two different destination
addresses A and B, as belonging to the same FEC if in the routing table of
the router there is an X prefix for which this prefix represents the greatest
correspondence length (longest match ) for both addresses A and B. In this
view, each router executes, independently of the others, its packet
classification in FEC and therefore two packets that are classified as
belonging to the same FEC in a router can belong to different FECs in
another router. The MPLS protocol acts differently: as defined in RFC 3031
the MPLS protocol assigns a FEC to a package once and for all, at the time
when the package enters an MPLS network. The FEC assigned to the
package is encoded in a label , of short and fixed length, transported in the
header of the package 6 itself. When the router through which the packet
has entered an MPLS network raises the packet, the packet itself assigns to
the packet the value of the label that will be used by the next router to carry
out the switching. When a packet enters a router, the label is used as an
index for direct access to a table that will contain the value of the next-hop
and the value of the new label. The old label is replaced with the new one
and the package is sent back to the next router. It should be emphasized that
once a packet has been assigned a label, the packet is switched by
examining the label exclusively without taking into account the value of the
other fields of the IP header.
Label Switching Router (LSR) and label definition mode
In the previous section the concept of FEC has been defined as a set of IP
packets that must be treated by a router in the same way, for example that
must be re-launched towards the same next-hop and belonging to the same
class of service. In MPLS every FEC is assigned a label that will be used by
the routers to perform the packet switching function. A router that supports
the MPLS technique is called the Label Switching Router (LSR) and the
type of switching is generally referred to as label switching. An MPLS
network domain is thus formed by a set of LSRs connected directly to each
other. The incoming traffic to an MPLS domain can come either from
networks external to the domain, such as for example local user networks,
or from traditional IP routers belonging to IP network sections that do not
support MPLS technology as illustrated in figure mpls-dominio . An LSR
that connects an MPLS domain with other nodes that are outside the
domain is called Edge LSR, while an LSR that is connected only to other
LSRs is called Core LSR. A label is therefore a fixed-length identifier that
is used to identify a FEC. A label has local validity, this means that the
association between FEC and a specific value of a label is valid only on one
section of the network, the same FEC can therefore be identified by
different labels on different sections of the network.
LSP tunnel
A Label Switched Path can be used to create tunnels within IP networks. If

an IP tunnel is made using an MPLS LSP then the LSP is called the LSP
Tunnel. There are two types of tunnel LSPs:
1. hop-by-hop routed LSP tunnels are implemented by

hop by hop routed LSP, these tunnels follow the paths indicated by the
routing protocols within the MPLS domain and are indicated with the
term Uniform Model LSP;
2. explicit routed LSP tunnels are implemented by explicitly routed LSP,
therefore, the paths followed by these LSPs in the MPLS domain may
be different than those indicated by the routing protocol and decided
on the basis of considerations and alternative strategies, these tunnels
are indicated with the term Pipe Model LSP.
For the purposes of this text our introduction to the MPLS protocol stops
here. For those wishing to learn more, we recommend the excellent
dispensation produced by Marco Listanti of the INFOCOM Department of
the "La Sapienza" University of Rome available at the link
http://bit.ly/2F0SrFl . An interesting talk was presented at the MUM 2009
in Prague entitled "MikroTik RouterOS Introduction to MPLS" which
included the MPLS protocol with Mikrotik products. The slides are
available at the link http://bit.ly/2GRW1Eq .
VPLS (Virtual Private LAN Service)
Those familiar with the services that Service Providers offer on their IP +
MPLS networks will know that one of the most interesting of these is the
VPLS (Virtual Private LAN Service) service, which is a Multipoint-to-
Multipoint service that allows emulation of LAN Ethernet on an IP + MPLS
network. From a logical point of view, the VPLS service can be seen as a
service that allows emulating Ethernet switches. For example, connecting N
geographically dispersed routers with a VPLS service is equivalent to
connecting the routers locally to an Ethernet switch with straight-through
cables. The CE (Customer Edge), that is the customer's devices that
interface with the CE Service Provider network,, can be any device that
generates tagged and/or untagged Ethernet frames (Ethernet or Host routers
or switches), and the connection among the CE and the ISP network routers
(PE router) can be in any technology (ex. Ethernet back-to-back, Ethernet
over SONET / SDH using GFP encapsulation, Ethernet over ATM using
AAL5 (RFC 2684), etc. ). The service model is very similar to the classic
L3VPN service on IP + MPLS networks, with the substantial difference that
between L3VPN sites IP packets are transported and the ISP network
participates in inter-site routing, while between VPLS sites Ethernet frames
are exchanged (tagged or untagged). This theoretically allows the exchange
of Level 3 packages that are not IP, although this is actually no longer
considered an important advantage of VPLS, since all applications are
based on the TCP/IP architecture. From a physical point of view, the
operating model is similar to that of the L3VPN, with some substantial
differences. For each client, the virtual L2 instances called VSI (Virtual
Switch Interface) are created on the PEs where the sites are certified. Each
VSI can be seen as a set of two elements: a MAC table (usually referred to
as VFI, Virtual Forwarding Instance), and a set of physical or logical
Ethernet interfaces that form a broadcast domain (usually referred to as a
Bridge Domain). The CE access interfaces on the PE (attachment circuit)
are associated with the appropriate VSI via configuration. The VSIs must
emulate all the ethernet switch functions:
Flooding: send to all other VSIs of the same VPLS the frames with
destination MAC addresses Broadcast, or Multicast or Unicast but
unknown (the so-called BUM traffic, Broadcast-Unknown-Unicast-
Multicast).
MAC address learning: automatically create associations (MAC, Port).
MAC address limiting: set a limit to the number of associations (MAC,
Port)
present in a VFI.
MAC Address aging: assign a life time to each entry in the VFI.
Loop prevention: avoid the Broadcast Storm phenomenon.
Recall that in switched ethernet networks, this function is performed
by the Spanning Tree protocol.
Forwarding: use of the entries created to forward LAN / VLAN traffic.
For each VPLS, a complete pseudowire mesh is created between the PEs
where the VPLS sites are attested; a pseudowire emulates a point-to-point
connection within which it is possible to carry any Level 2 frames, in this
case Ethernet frames. The reason why you need a complete pseudowire
mesh is related to the transport of BUM traffic, ie to Broadcast, Unknown-
Unicast and Multicast traffic.
Architecture for performance testing.
vpn-test
But MPLS and VPLS are also interesting for small architectures as they are
very efficient. If we consider the architecture of figure vpn-test using
RB1000 RouterBoard as hardware then the table table:tunnel-performance
that collects the performance tests highlights the winning protocols.
64 byte pps 512 byte pps
Bridge 414.000 359.000
MPLS 410.000 358.000
VPLS 332.500 301.000
Routin
236.000 229.700
g
EoIP 190.000 183.900
Performance test.
table:tunnel-performance
MPLS and VPLS using Mikrotik RouterOS
Remember that in order for the MPLS menu to be present, the MPLS
package must be installed and active as shown in fig mpls-package .
MPLS package.
mpls-package
Lab
For this laboratory, two routers with a wireless interface and two PCs are
required.
VPLS tunnel
mpls-tunnel using MPLS. This approach has the following advantages:
the VPLS tunnel is about 60 faster and with less overload than an
EoIP tunnel, \item in WDS bridges with 802.11n protocol the speed is
limited by the protocol but not in the MPLS case.
VPLS tunnel using a radio bridge.
mpls-tunnel
For educational convenience this laboratory is available in two versions:
through the graphical interface of WinBox or through the terminal
commands.
{Using WinBox}
1. Set up the radio link as usual with a WDS bridge.

2. As a first step, enable LDP (Label Distribution Protocols) on both
routers using the menu MPLS > MPLS > LDP Interface > LDP
Setting :
3. Using the MPLS > MPLS > LDP Interfaces menu, add the interface
to be used for VPLS connections. The transport address can be empty.
4. After a few seconds check the status of the LDP connectivity in MPLS
> MPLS > LDP Neighbor :
D=Dynamic, O=Operational
5. Add a new VPLS interface using the MPLS > VPLS > VPLS menu.
The address to indicate in the remote peer field is the ip address of the
other end of the radio link:
6. After a few seconds, check how the status of the LDP connectivity was
changed in MPLS > MPLS > LDP Neighbor menu:
D=Dynamic, O=Operational, T = Transport, V=VPLS Active

7. Create a bridge interface and add the vpls and ether1 interface to the
ports.
8. Check for proper operation by pinging between clients .
{Using terminal commands}
1. We load the configurations on the AP router and then on the router

station:
{AP}
/system identity set name=AP
# Configuration of the wireless access point (AP)

/interface wireless
set wlan1 disabled=no ssid=MPLS frequency=5180 band=5ghz
mode=bridge
# Configuration of IP address
/ip address
add address=172.16.0.1/30 interface=wlan1
# Enable LDP
/mpls ldp
set enabled=yes lsr-id=172.16.0.1 transport-
address=172.16.0.1
/mpls ldp interface
add interface=wlan1
# Setup VPLS tunnel

/interface vpls
add name=vpls1 remote-peer=172.16.0.2 vpls-id=1:1
disabled=no
# Add bridge and ports

add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=vpls1
{station}
/system identity set name=station
# Configuration of the wireless access point (station)

/interface wireless
set wlan1 disabled=no ssid=MPLS band=5ghz mode=station
# Configuration of IP address
/ip address
add address=172.16.0.2/30 interface=wlan1
# Enable LDP
/mpls ldp
set enabled=yes lsr-id=172.16.0.2 transport-
address=172.16.0.2
/mpls ldp interface
add interface=wlan1
# Setup VPLS tunnel

/interface vpls
add name=vpls1 remote-peer=172.16.0.1 vpls-id=1:1
disabled=no
# Add bridge and ports

add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=vpls1
2. Check the correct working:

[admin@AP] /mpls ldp neighbor> print
Flags: X - disabled, D - dynamic, O - operational,
T - sending-targeted-hello, V - vpls
# TRANSPORT LOCAL-TRANSPORT
PEER ADDRESSES
0 DOTV
172.16.0.2 172.16.0.1 172.16.0.2:0 172.16.0.2
[admin@AP] /mpls forwarding-table print

Flags: L - ldp, V - vpls, T - traffic-eng
# IN-LABEL OUT-
LABELS DESTINATION INTERFACE
0 expl-null
1 V 18 vpls1
3. Check that the VPLS tunnel is correctly established:

[admin@AP] /interface vpls> monitor vpls1 once
remote-label: 17
local-label: 18
remote-status:
transport-nexthop: 172.16.0.2
imposed-labels: 17
4. Check for proper operation by pinging between clients.
If you want to go deeper into the topic always the excellent Tomas Kirnak
at MUM 2013 gave a talk entitled "MPLS for ISPs - PPPoE over VPLS
MPLS, VPLS, PPPoE" whose slides are available at link
http://bit.ly/2VrgCCB .
Useful schemes and tables
«...with the same shoes walking on different roads or with different shoes on
a single road.» Fiorella Mannoi a
Block diagram of packet flow

packet- flow
Differences between Cisco IOS and Mikrotik
RouterOS
Generic routing
Cisco IOS Mikrotik RouterOS

Per Src. and Dst. Address
FIB load Per Src. and Dst. Address Pair or
Pair (Flush every 10
Balancing Per-Packet
minutes)
Equal Add only one route by
Add multiple routes to same
CostMulti mentioning multiple
destination with same distance, but
Path gateways in the same
different gateway
(ECMP) route.
Disabled by default, can
Recursive
manually enable by
nexthop Enabled.
route’s Target Scope
lookup
parameter.
Route Implicit deny at the end of each Implicit permit at the end
filtering filtering component (access-list, of filtering component
behavior prefix-list, filterlist, route-map… (Routing Filters)
etc.).
OSPF
cisco-routeros-ospf Router ID Link Cost OSPF Timer Stub Area Route

Filtering Advertising Loopback interface into OSPF
Mikrotik
Cisco IOS RouterO
S
Highest active Loopback IP,
Lowest active
then Highest active Interface IP
interface IP
Fixed Cost 10 for
Vary depends on Link BW Ref. BW (bps) / any links,
Link BW (bps) Default Ref. BW is 100Mbps changeable in
OSPF interface
configuration
Vary depends on network type “broadcast”
and “point-topoint”, Hello interval is 10,
Dead interval is 40 For “nbma”, Hello
interval is 30, Dead interval is 120 &Fixed
Hello interval 10, and Dead interval 40,
changeable in OSPF interface configuration.
\textbf{When changed network type,
intervals are not changed!}
Behaves like
Totally Stubby
Type 3 LSAs are advertised into Stub Area Area in IOS by
by default, unless configured as Totally default. Enable
Stubby Area “Inject Summary
LSAs” option if
want to advertise
Type 3 LSAs into Stub Area
Use “distribute-list” command to
permit/deny routes to be
Use “Routing
Filters” to
permit/deny
installed into RIB routes to be
installed into RIB,
but can filter only
Type 5 LSAs
By default, subnet mask of the interface By default, exact
route is forced to be /32 Set the interface subnet mask is
network type as “point-to-point” to advertise advertised, no
exact subnet mask action
required
Cisco IOS command Mikrotik RouterOS command
show ip ospf neighbor routing ospf neighbor print
show ip ospf interface routing ospf interface print
show ip ospf1 routing ospf instance print detail
show ip ospf database routing ospf lsa print
show ip route ospf ip route print where ospf=yes
show ip ospf rib routing ospf route print
show ip ospf border-routers routing ospf area-border-router print
show ip ospf border-routers routing ospf as-border-router print
Cisco(config)#router ospf1 routing ospf instance
Cisco(config-router)#router-id /routing ospf instance set 0 router-
203.0.113.1 id=203.0.113.2
/routing ospf network add
Cisco(config-router)#network
area=backbone
203.0.113.1 0.0.0.0 area 0
network=203.0.113.2/32
/routing ospf network add
Cisco(config-router)#network
area=backbone
203.0.113.128 0.0.0.7 area 0
network=203.0.113.128/29
Cisco(config-router)#interface /routing ospf interface add dead-
GigabitEthernet0/0 interval=4s
Cisco(config-if)# ip ospf network hello-interval=1s interface=ether1
point-to-point
Cisco(config-if)# ip ospf dead-
network-type=point-to-point
interval 4
Cisco(config-if)# ip ospf hello-
interval 1
MPLS
Cisco IOS Mikrotik RouterOS

Multi Path con
No, only first gateway will
Label
Yes be used in MPLS forwarding
Distribution
table (MFIB)
Protocol (LDP)
MPLS Fast Link Protection (~50ms)
Not supported
Reroute Node Protection
6PE, 6VPE, L3VPN
MPLS
(Unicastand Multicast), L3VPN (Unicast), VPLS
Applications
AToM, VPLS
Possible on P routers and Only possible on PE routers,
MPLS QoSwith
PE routers by utilizing P routers will not apply any
EXP bit
Modular QoS CLI (MQC) policy to MPLS packets

Theory, Laboratories and Exercises For Mikrotik RouterOS

Uploaded by

Copyright:

Available Formats

Theory, Laboratories and Exercises For Mikrotik RouterOS

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Theory, Laboratories and Exercises For Mikrotik RouterOS

Uploaded by

Copyright:

Available Formats

1.

Routing is the basis of the network functionality implemented by level 3

Forwarding , or receiving a packet on a port, storing it and re-

to be able to monitor and better manage the network;

The principle on which IP routing is based is very simple: send packets on

Static routing - In this case the administrators perform the routing

Classification of dynamic routing protocols

RouterOS routing components

RIB (Routing Information Base) - is the routing table

Router Information Base (RIB)

all routes collected by dynamic routing protocols;

Routing table (RIB)

to filter the routing information of all routing protocol types;

Forwarding Information Base (FIB)

is the product of the routing table after it has been filtered;

How RIB and FIB tables are used

FIB uses the following package information to determine its destination:

The possible routing decisions are:

receive packet locally

it is checked whether the package should be delivered locally (the

if the path type is blackhole, prohibited or unreachable, then it returns

IP address of nexthop interface

the dst-address network of the connected route is equal to the network

Adding a static route

Static routing - guided

Simple static routing

1. restore factory router configuration (without default);

4. enter the following configuration in router R2:

The laboratory is correctly executed if it is possible to ping between the two

Static routing - without help

Simple static routing

1. restore router configuration (without default);

1. The default distance value for a static route is:

Which gateway will be used to reach the 192.168.1.5 ip?

Which gateway will be used to reach the 192.168.1.5 ip?

Network with static routing

One of the peculiarities of the TCP/IP protocol and specifically of IP

Types of load balancing

load balancing per packet:

Equal Cost Multi Path (ECMP)

1. Once connected the routers and the PCs as in figure ecmp-lab1

PC-1> ping 8.8.8.8

PC-1> trace 8.8.8.8

PC-2> ping 8.8.8.8

PC-2> trace 8.8.8.8

Administrative distance (distance)

1. Start from the diagram and the configurations of ecmp laboratory.

3. Add to R1 these routes:

1. Start from the scheme and configurations of the distance laboratory.

Active route with two reachable routers.

Active route with router R1 not reachable.

1. IP > Route > Rules

Adding a rule in routing policy

1. Once connected the routers and the PCs as in figure ecmp-lab-routing-

Queue limited to 1k / 1k with traffic passing through the R2 router

Routing marking for ICMP packets

The solution use the following logic:

add address=192.168.5.1/24 disabled=no interface=WAN1

# Creation of two address lists