cyber deal
Switching and Bridging RouterOS v7 Book
Study material for the MTCSWE Certification Course updated to RouterOS v7
$19,97
Add to cart
Layer 2 Misconfigurations: Packet Flow with Hardware Offloading and MAC Learning
- Mauro Escalante
- No comments
- Share this article
Facebook
Twitter
LinkedIn
WhatsApp
Telegram
Consider the following scenario: A bridge has been configured with the option to hardware offloading enabled to maximize network performance on a RouterOS device. Due to this configuration, the device functions as a switch instead of a simple bridge at the software level.
This improves performance by allowing the switch chip to handle packet forwarding between ports, rather than having the device's CPU do it.
Configuration
/interface bridge
add name=bridge1
/interface bridge port
add bridge=bridge1 hw=yes interface=ether1 learn=yes
add bridge=bridge1 hw=yes interface=ether2 learn=yes
Problem
When tools like Sniffer o Torch To capture packets on the network, an anomaly is observed: only some packets are visible, generally those that are broadcast/multicast. This is due to how the switch chip handles traffic in a configuration with hardware offloading.
MAC Learning vs Host Table
El switch chip maintains a table of MAC addresses and associated ports known as the “Host table”. Each time a packet needs to be forwarded, the switch chip consults this table to determine which port should be used to forward the packet. If the destination MAC address is not found in the table, the packet is flooded to all ports, including the CPU port.
Therefore, if the destination MAC address has already been learned and is in the table, the switch chip can forward the packet directly without going through the CPU. This means that said package will not be visible to tools like Sniffer o Torch, which capture packets at the CPU level.
Symptom
- Packages not visible in Sniffer or Torch.
- Filtering rules may not work as expected.
Solution
To solve this problem, it is possible to use rules of ACL (Access Control List) to copy or redirect certain packets to the CPU. For example, you can configure a rule that sends a copy of packets destined for a specific MAC address to the CPU for analysis.
/interface ethernet switch rule
add copy-to-cpu=yes dst-mac-address=4C:5E:0C:4D:12:4B/FF:FF:FF:FF:FF:FF
ports=ether1 switch=switch1
It should be noted that sending packets to the CPU for processing will increase the load on the CPU, which could affect the overall performance of the device.
El hardware offloading It is a powerful technique to improve network performance, but it comes with certain limitations in terms of visibility and control at the CPU level. For use cases that require packet analysis or filtering, additional configuration such as ACL rules is required to ensure that the necessary packets are processed by the CPU.
Additional considerations
1. Traffic Prioritization:
In more complex networks, you may want to implement QoS (Quality of Service) to prioritize certain types of traffic. This generally requires packets to pass through the CPU, which could conflict with a hardware offloading configuration.
2. Security:
Hardware offloading can limit the ability to implement stronger security measures, such as Deep Packet Inspection (DPI), because packets may not pass through the CPU.
3. CPU capacity:
It is essential to take into account the processing capacity of the CPU when redirecting traffic to it. Too many packets sent for processing on the CPU can overwhelm it, leading to a decrease in overall system performance.
4. Compatibility:
Not all devices and switch chips support hardware offloading or have the same capabilities. Make sure your hardware supports the features you want to use.
5. Firmware/Software Updates:
Make sure you are using a version of RouterOS that supports all the features you want to implement. Issues and limitations may vary between different versions.
Advanced Solutions
For more complex scenarios, it is possible to use APIs or scripts to automate the addition and removal of ACL rules based on certain events or conditions. This could be especially useful in dynamic environments where destination MAC addresses may change frequently.
Summary
Hardware offloading is an effective technique for improving network performance, but it has its challenges when it comes to detailed traffic control and diagnosis.
Tools like Sniffer or Torch are less effective in this context because many packets are forwarded at the switch chip level and never reach the CPU.
However, with careful planning and the use of features like ACL, it is possible to balance performance with diagnostic and security needs.
Brief knowledge quiz
What do you think of this article?
Do you dare to evaluate your learned knowledge?
Recommended book for this article
Related Posts
Related Posts
Microlabs
(ML-001) How to properly manage multiple public or private IPs on the edge router
$8,99
(ML-002) Ways to assign public IP addresses to clients with MikroTik
$9,99
(ML-003) Guide to configure Internet exit routes with two or more providers (failover and recursion in PCC balancing)
$8,99
(ML-004) Filter implementation strategies to restrict access to web pages with MikroTik
$7,99
Other topics that may interest you
Ways to Assign IPv6 Addressing (Part 2)
March 25th, 2024
WireGuard on MikroTik RouterOS: A Secure and Efficient VPN Solution
March 13th, 2024
Ways to Assign IPv6 Addressing (Part 1)
March 11th, 2024
Do you want to suggest a topic?
Every week we post new content. Do you want us to talk about something specific?
Upcoming online courses
MTCINE OnLine
$187,00
MTCNA Online
$187,00
MTCRE Online
$187,00
Pack 4 MikroTik RouterOS books
$68,47
