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.
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.
- 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}
/system identity set name=R2
/ip address
add address=192.168.12.2/24 interface=ether2 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}
/system identity set name=R3
/ip address
add address=192.168.13.3/24 interface=ether3 network=192.168.13.0
/ip dhcp-client add disabled=no interface=ether1
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
{R1}
/system identity set name=R1
/interface bridge add fast-forward=no name=bridge-lan
/interface bridge port
add bridge=bridge-lan interface=ether1
add bridge=bridge-lan interface=ether5
/ip address
add address=192.168.12.1/24 interface=ether2 network=192.168.12.0
add address=192.168.13.1/24 interface=ether3 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
add action=masquerade chain=srcnat out-interface=ether2
add action=masquerade chain=srcnat out-interface=ether3
/ip route add distance=1 gateway=192.168.13.3,192.168.12.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
84 bytes from 8.8.8.8 icmp_seq=2 ttl=57 time=22.312 ms
84 bytes from 8.8.8.8 icmp_seq=2 ttl=57 time=22.312 ms
84 bytes from 8.8.8.8 icmp_seq=2 ttl=57 time=22.312 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
- 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
84 bytes from 8.8.8.8 icmp_seq=1 ttl=57 time=24.320 ms
84 bytes from 8.8.8.8 icmp_seq=2 ttl=57 time=24.227 ms
84 bytes from 8.8.8.8 icmp_seq=3 ttl=57 time=22.744 ms
84 bytes from 8.8.8.8 icmp_seq=4 ttl=57 time=23.995 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:
Type of route
|
Distance
|
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
Three routers and two PCs are required for this laboratory.
Distance
The aim of this workshop is to understand how the distance value affects the selection of the active route.
- Start from the diagram and the configurations of ecmp
laboratory.
- Remove from the R1 router ECMP route.
{R1}
/ip route add distance=1 gateway=192.168.13.3,192.168.12.2
- 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
- From the two PCs the output paths are analyzed with the command trace
or equivalent.
- Disconnect the cable that connect router R1 to router R2.
- 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
Three routers and two PCs are required for this laboratory.
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.
- Start from the scheme and configurations of the distance
laboratory.
- On router R1 modify route by adding the Check-Gateway method indicated as shown in the figure:
- Check that the routes are correct:
Active route with two reachable routers.
- From the two PCs analyze the output paths with the command trace
or equivalent.
- Disconnect the cable connecting the R1 router with the R2 router.
- Wait at least 20 seconds.
- From the two PCs analyze the output paths with the command trace
or equivalent.
- On R1 check that the routes are
correct:
Active route with router R1 not reachable.
- 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:
-
IP
> Route
> Rules
-
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
Three routers and two PCs are required for this laboratory.
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.
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, ...).
- 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}
/system identity set name=R2
/ip address
add address=192.168.12.2/24 interface=ether2 network=192.168.12.0
/ip dhcp-client add disabled=no interface=ether1
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
#
# Setting the queue with 1k / 1k limitation
#
/queue simple add target=0.0.0.0/0 max-limit=1k/1k
{R3}
/system identity set name=R3
/ip address
add address=192.168.13.3/24 interface=ether3 network=192.168.13.0
/ip dhcp-client add disabled=no interface=ether1
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
#
# Setting the queue with 1k / 1k limitation
#
/queue simple add target=0.0.0.0/0 max-limit=1k/1k
{R1}
/system identity set name=R1
/interface bridge add fast-forward=no name=bridge-lan
/interface bridge port
add bridge=bridge-lan interface=ether1
add bridge=bridge-lan interface=ether5
/ip address
add address=192.168.12.1/24 interface=ether2 network=192.168.12.0
add address=192.168.13.1/24 interface=ether3 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
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether2
add action=masquerade chain=srcnat out-interface=ether3
- 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
- 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
- We add the two routes:
- 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
.
- 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:
- Two lists of IP addresses are created and the IPs of the VIP or NORMAL users are added.
- Two traffic marking rules (mangle) are added to mark the packets generated by VIP and NORMAL users.
- Two default routes are specified with the appropriate routing marks and gateways.
- 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
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.
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:
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
add dst-address=Host2 gateway=GW2 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
add dst-address=Host1 gateway=GW2 scope=10
add dst-address=Host2 gateway=GW2 scope=10
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
dst-address=2.2.2.0/24 gateway=3.3.3.3 scope=10 target-scope=10
dst-address=3.3.3.0/24 gateway=1.1.1.1 scope=10 target-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
INTERFACE
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
Three routers and two PCs are required for this laboratory.
Tipi di rotte
The aim of this workshop is to understand the use of different types of routes.
- Once connected the routers and the PCs as in figure route-type-lab
proceed with the loading of the following configurations:
{R1}
/system identity set name=R1
/ip address add address=192.168.1.1/24 interface=ether1
/ip address add address=12.12.12.1/24 interface=ether2
/ip route
add dst-address=192.168.3.0/24 gateway=12.12.12.2
{R2}
/system identity set name=R2
/ip address add address=12.12.12.2/24 interface=ether1
/ip address add address=23.23.23.2/24 interface=ether2
/ip route
add distance=1 dst-address=192.168.1.0/24 gateway=12.12.12.1
add distance=1 dst-address=192.168.3.0/24 gateway=23.23.23.3
{R3}
/system identity set name=R3
/ip address add address=23.23.23.3/24 interface=ether1
/ip address add address=192.168.3.1/24 interface=ether2
/ip route
add distance=1 dst-address=192.168.1.0/24 gateway=23.23.23.2
- Assign the respective static ip addresses indicated in figure route-type-lab
to the two PCs.
- From the first PC execute the command ping 192.168.3.2
and then analyze the result of the command.
- 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
84 bytes from 192.168.3.2 icmp_seq=1 ttl=61 time=6.317 ms
84 bytes from 192.168.3.2 icmp_seq=2 ttl=61 time=1.753 ms
84 bytes from 192.168.3.2 icmp_seq=3 ttl=61 time=1.607 ms
84 bytes from 192.168.3.2 icmp_seq=4 ttl=61 time=2.905 ms
84 bytes from 192.168.3.2 icmp_seq=5 ttl=61 time=3.034 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
192.168.3.2 icmp_seq=2 timeout
192.168.3.2 icmp_seq=3 timeout
192.168.3.2 icmp_seq=4 timeout
192.168.3.2 icmp_seq=5 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
*12.12.12.2 icmp_seq=2 Communication administratively prohibited
*12.12.12.2 icmp_seq=3 Communication administratively prohibited
*12.12.12.2 icmp_seq=4 Communication administratively prohibited
*12.12.12.2 icmp_seq=5 Communication administratively prohibited
- Using route:
-
{R2}
/ip route add dst-address=192.168.3.0/24 type=unreachable
You get:
PC-1> ping 192.168.3.2
*12.12.12.2 icmp_seq=1 Destination host unreachable
*12.12.12.2 icmp_seq=2 Destination host unreachable
*12.12.12.2 icmp_seq=3 Destination host unreachable
*12.12.12.2 icmp_seq=4 Destination host unreachable
*12.12.12.2 icmp_seq=5 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 INTERFACE
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 ether1
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
- The default value for a static target-scope route is:
- 255
- 1
- 10
- 0
- If you activate the Check-gateway function for a route then all routes
with the same gateway will they undergo the same control?
- Yes
- No
- To drive traffic that is more specific through a
route with routing-mark, should traffic be identified before or after the routing process?
- Before
- After
- Does the pref-src property indicate which of the IP addresses are preferred as a destination for a gateway?
- Yes
- No
- In the ECMP protocol configuration, can the same gateway be repeated several times for the same destination?
- Yes
- No
- With ECMP only the nexthop gateway with the lowest IP is copied to the FIB?
- Yes
- No
- With ECMP if the router uses an external src-NAT masquerade it is not necessary to indicate a masquerade for each address.
- Yes
- No
- ECMP realizes the load balancing:
- For connection.
- By source
address.
- By destination address.
Solutions
- 10.
- Yes.
- Before (see the diagram on page packet-flow
).
- 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.
- Yes.
- No, all reachable nexthop gateways are copied to the FIB.
- No, you must indicate all the addresses to which the masquerade acts.
- by connection. See the in-depth questions on page ecmp-domanda
.