Versions Compared

Old Version 64

changes.mady.by.user Artūrs C.

Saved on

compared with

New Version 65

changes.mady.by.user Artūrs C.

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Trying fixing some formatting issues

...

Now, let's take our first example where packet gets routed over the router and look deeper through what facilities packet goes:

Section


Column
width400px50%

We already learned that packet goes into in-interface, the router determines that it is an IP packet and need to be routed, and here starts the complicated process:

  1.  The packet enters prerouting processing:
    1. check if there is a hotspot and modify the packet for hotspot use
    2. process packet through RAW prerouting chain;
    3. send the packet through connection tracking;
    4. process packet through Mangle prerouting chain;
    5.  process packet through NATs dst-nat chain;
  2. Run packet through routing table to make routing decision;
  3. The packet enters forward process;
    1. check TTL value;
    2. process packet through Mangle forward chain;
    3. process packet through Filter forward chain;
    4. send the packet to accounting processes;

  4. A packet enters postrouting process;
    1. process packet through Mangle postrouting chain;
    2. process packet through NATs src-nat chain;
    3. if there is a hotspot undo any modifications made in hotspot-in;
    4. process packet through queue tree (HTB Global);
    5. process packet through simple queues;

  5. Check if there is IPsec and then process through IPsec policies;


Column
width50%

Image Modified



Input

We already learned that packet goes into in-interface, the router determines that it is an IP packet and need to be routed, and here starts the complicated process:

Section


Column
width400px50%
  1. A very similar process happens when a packet's destination is a router (routing input): Packet enters prerouting processing:
    1. - check if there is a hotspot and modify the packet for hotspot use;
    2. - process packet through RAW prerouting chain;
    3. - send a packet through connection tracking;
    4. - process packet through Mangle prerouting chain;
    5. - process packet through NATs dst-nat chain;

  2. Run packet through routing table to make routing decision;

  3. A Packet enters forward process;
    1. - check TTL value;
    2. - process packet through Mangle forward chain;
    3. - process packet through Filter forward chain;
    4. - send a packet to accounting processes;

  4.  A Packet enters postrouting process; 
    1. - process packet through Mangle postrouting chain;
    2. - process packet through NATs src-nat chain;
    3. - if there is a hotspot undo any modifications made in hotspot-in;
    4. - process packet through queue tree (HTB Global);
    5. - process packet through simple queues;

  5.  Check if there is IPsec and then process through IPsec policies;


Column
width50%


Output

Or when a packet is originated from the router (routing output):

Section


Column
width400px50%
  1. The packet is originated from the router itself
    1. the packet goes through the routing table to make a routing decision

  2. A packet enters the output process
    1. process packet through the Bridge decision;
    2. send the packet through connection tracking;
    3. process packet through Mangle output chain;
    4. process packet through Filter output chain;
    5. send the packet to routing adjustment ( policy routing)

  3.  The packet enters postrouting process; 
    1. - process packet through Mangle postrouting chain;
    2. - process packet through NATs src-nat chain;
    3. - if there is a hotspot undo any modifications made in hotspot-in;
    4. - process packet through queue tree (HTB Global);
    5. - process packet through simple queues;

  4. Check if there is IPsec and then process through IPsec policies;


Column
width50%




Flow of Bridged Packet

Below is discussed a general bridging process in RouterOS. Most of the packets will always follow the same processing path, but in certain configurations (e.g. with enabled VLAN filtering, horizon, STP, DHCP, or IGMP snooping) some packets can be treated differently. Please visit the bridging manual for more specific information.

...

Bridge forward is a process that takes place when a packet is forwarded from one bridge port to another, essentially connecting multiple devices on the same network. After receiving a packet on in-interface, the device determines that in-interface is a bridge port, so it gets passed through the bridging process:

Section


Column
width400px50%
  1. A packet goes through the bridge NAT dst-nat chain, where MAC destination and priority can be changed, apart from that, a packet can be simply accepted, dropped, or marked;
  2. Checks whether the use-ip-firewall option is enabled in the bridge settings;
  3. Run packet through the bridge host table to make a forwarding decision. A packet that ends up being flooded (e.g. broadcast, multicast, unknown unicast traffic), gets multiplied per bridge port and then processed further in the bridge forward chain.
  4. A packet goes through the bridge filter forward chain, where priority can be changed or packet can be simply accepted, dropped, or marked;
  5. Checks whether the use-ip-firewall option is enabled in the bridge settings;
  6. A packet goes through the bridge NAT src-nat chain, where MAC source and priority can be changed, apart from that, a packet can be simply accepted, dropped, or marked;
  7. Checks whether the use-ip-firewall option is enabled in the bridge settings;


Column
width50%



Bridge Input

Bridge input is a process that takes place when a packet is destined to the bridge interface. Most commonly this happens when you need to reach some services that are running on the bridge interface (e.g. a DHCP server) or you need to route traffic to other networks. The very first steps are similar to the bridge forward process - after receiving a packet on in-interface, the device determines that in-interface is a bridge port, so it gets passed through the bridging process:

Section


Column
width400px
  1. A packet goes through the bridge NAT dst-nat chain, where MAC destination and priority can be changed, apart from that, a packet can be simply accepted, dropped, or marked;
  2. Checks whether the use-ip-firewall option is enabled in the bridge settings;
  3. Run packet through the bridge host table to make a forwarding decision. A packet where the destination MAC address matches with the bridge MAC address will be passed to the bridge input chain. A packet that ends up being flooded (e.g. broadcast, multicast, unknown unicast traffic), also reaches the bridge input chain as the bridge interface itself is one of the many destinations;
  4. A packet goes through the bridge filter input chain, where priority can be changed or the packet can be simply accepted, dropped, or marked;


Column
width50%


Bridge Output

Bridge output is a process that takes place when a packet should exit the device through one or multiple bridge ports. Most commonly this happens when a bridge interface itself tries to reach a device connected to a certain bridge port (e.g. when a DHCP server running on a bridge interface is responding to a DHCP client). After a packet is processed on other higher-level RouterOS processes and device finally determines that the output interface is a bridge, the packet gets passed through the bridging process:

Section


Column
width400px
  1. Run packet through the bridge host table to make a forwarding decision. A packet that ends up being flooded (e.g. broadcast, multicast, unknown unicast traffic), gets multiplied per bridge port and then processed further in the bridge output chain.
  2. A packet goes through the bridge filter output chain, where priority can be changed or the packet can be simply accepted, dropped, or marked;
  3. A packet goes through the bridge NAT src-nat chain, where MAC source and priority can be changed, apart from that, a packet can be simply accepted, dropped, or marked;
  4. Checks whether the use-ip-firewall option is enabled in the bridge settings;


Column
width50%


Forward With Firewall Enabled

...

Section


Column
width400px
  1. A packet goes through the bridge NAT dst-nat chain;
  2. With the use-ip-firewall option enabled, the packet will be further processed in the prerouting chain;
  3. A packet enters prerouting processing;
  4. Run packet through the bridge host table to make forwarding decision;
  5. A packet goes through the bridge filter forward chain;
  6. With the use-ip-firewall option enabled, the packet will be further processed in routing forward chain;
  7. A packet enters routing forward processing;
  8. A packet goes through the bridge NAT src-nat chain;
  9. With the use-ip-firewall option enabled, the packet will be further processed in the postrouting chain;
  10. A packet enters prerouting processing;


Column
width50%


Flow of Hardware Offloaded Packet

On the previous topic, we solely discussed a software bridging that requires the main CPU processing to forward packets through the correct bridge port. Most of the MikroTik devices are equipped with dedicated switching hardware, so-called switch chip or switch ASIC. This allows us to offload some of the bridging functions, like packet forwarding between bridge ports or packet filtering, to this specialized hardware chip without consuming any CPU resources. In RouterOS, we have named this function as Bridge Hardware (HW) Offloading. Different MikroTik devices might have different switch chips and each chip has a different set of features available, so make sure to visit this article to get more details - Bridge Hardware Offloading.

Image Modified


Note

Interface HTB will not work correctly when the out-interface is hardware offloaded and the bridge Fast Path is not active.

Image Modified

  • switching decision - widely depends on the switch model. This block controls all the switching related tasks, like host learning, packet forwarding, filtering, rate-limiting, VLAN tagging/untagging, mirroring, etc. Certain switch configuration can alter the packet flow;
  • switch-cpu port - a special purpose switch port for communication between the main CPU and other switch ports. Note that the switch-cpu port does not show up anywhere on RouterOS except for the switch menu, none of the software related configuration (e.g. interface-list) can be applied to this port. Packets that reach the CPU are automatically associated with the physical in-interface.

...

We will further discuss a packet flow when bridge hardware offloading is enabled and a packet is forwarded between two switched ports on a single switch chip. This is the most common and also the simplest example:

Section


Column
width400px50%
  1. The switch checks whether the in-interface is hardware offloaded interface;
  2. Run a packet through the switch host table to make a forwarding decision. If the switch finds a match for the destination MAC address, the packet is sent out through the physical interface. A packet that ends up being flooded (e.g. broadcast, multicast, unknown unicast traffic) gets multiplied and sent out to every hardware offloaded switch port.


Column
width50%


Switch to CPU Input

This process takes place when a packet is received on a physical interface and it is destined to switch-cpu port for further software processing. There are two paths to the switch-cpu. One where hardware offloading and switching is not even used (e.g. a standalone interface for routing or a bridged interface but with deliberately disabled HW offloading), so the packet is simply passed further for software processing. Another path is taken when hardware offloading is active on the in-interface. This will cause the packet to pass through the switching decision and there are various reasons why switch might forward the packet to the switch-cpu port:

...

See the packet walkthrough when an in-interface is hardware offloaded:

Section


Column
width400px50%
  1. The switch checks whether the in-interface is hardware offloaded interface;
  2. Run a packet through the switch host table to make a forwarding decision. In case any of the above-mentioned points are true, the packet gets forwarded to the switch-cpu port.
  3. The packet exits through the switch-cpu port and it will be further processed by the RouterOS packet flow.


Column
width50%



Note

Any received packet that was flooded by the switch chip will not get flooded again by the software bridge to the same HW offloaded switch group. This prevents the formation of duplicate packets.

...

This process takes place when a packet exits the RouterOS software processing and it is received on the switch-cpu port. Again, there are two paths the packet can take. One where hardware offloading and switching is not even used (e.g. a standalone interface for routing or a bridged interface but with deliberately disabled HW offloading), so the packet is simply sent out through the physical out-interface. Another path is taken when hardware offloading is active on the out-interface. This will cause the packet to pass through the switching decision. Just like any other switch port, the switch will learn the source MAC addresses from packets that are received on the switch-cpu port. This does come in handy when a bridge contains HW and non-HW offloaded interfaces, so the switch can learn which frames should be forwarded to the CPU. See the packet walkthrough when an out-interface is hardware offloaded:

Section


Column
width400px50%
  1. A packet that exits the RouterOS software processing is received on the switch-cpu port;
  2. The switch checks whether out-interface is hardware offloaded interface;
  3. Run a packet through the switch host table to make a forwarding decision. If the switch finds a match for the destination MAC address, the packet is sent out through the physical interface. A packet that ends up being flooded (e.g. broadcast, multicast, unknown unicast traffic) gets multiplied and sent out to every hardware offloaded switch port.


Column
width50%



Note

A software bridge that sends a flooded packet through HW offloaded interfaces, will only send a single packet copy per HW offloaded switch group rather than per HW offloaded interface. The actual flooding will be done by the switch chip, this prevents the formation of duplicate packets.

Flow of MPLS Packet

Pop Label

Section



400px
Column
width

1.

2.

3.

Column



Switch Label

1.

2.
Section
Column
width400px



Column



Push Label

1.

2.
Section
Column
width400px



Column



Logical Interfaces

So far we looked at examples when in or out interfaces are actual physical interfaces (Ethernet, wireless), but how packets will flow if the router receives tunnel encapsulated packets?

...