15
Packet flow from VLAN Host to www - how often routing decision is made?
Hi there,
it has been a while
I'm reviewing my firewall rules and have some hiccups grasping all again.
I asked myself quite a basic question but my mind was filled with other things, so I would like to have a second opinion on it.
How often will a package flow through this before it hits www (or my ISP) if I have VLANs and Bridge
If I combine
from Manual:Packet Flow - MikroTik Wiki | 4.3 Vlan Untagging/Tagging in the bridge interface and the Routing Packet Flow Diagram from firewall vs nat packet flow - MikroTik
it is only once, isn't it?
Simplified it is:
it has been a while
I'm reviewing my firewall rules and have some hiccups grasping all again.
I asked myself quite a basic question but my mind was filled with other things, so I would like to have a second opinion on it.
How often will a package flow through this before it hits www (or my ISP) if I have VLANs and Bridge
If I combine
Simplified it is:
- From host to Interface on router (VLAN trunk / tagged port is the physical in)
- Then Decapsulation takes place
- Afterwards it goes to the Logical In Interface, the respective VLAN Interface
- Then, it is forwarded to the physical WAN interface where it leaves the router with any other processing on the router anymore
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7151104211
Url: https://administrator.de/en/packet-flow-from-vlan-host-to-www-how-often-routing-decision-is-made-7151104211.html
Ausgedruckt am: 29.12.2024 um 16:12 Uhr
15 Kommentare
Neuester Kommentar
If it's a new paket wich cannot be matched by the connection tracking table then routing decision has to be made first, otherwise the packet belongs to an existing connection so it flows through the connection tracking process and is forwarded directly without further evaluation (excluding IPsec decapsualtion which has always to be done of course, also SRCNAT and DSTNAT have their own tables and processing takes place in PREROUTING(DSTNAT) and POSTROUTING(SRCNAT)).
This is called a statefull firewall. All modern firewalls use connection states, so you only have to define rules in one direction, the way back will then be allowed automatically by the connection tracking table.
With Mikrotik you have to setup a statefull firewall by your own rules! So you need to define at least two rules for INPUT and FORWARD chains wich have to evaluate the connection states "established,related, untracked" in their settings.
How long connections can stay open when there is no traffic for a period of time or the connection breaks unexpectedly without normal TCP FIN, can be defined in your firewall setup in the CONNTRACK table settings. Here you can define different settings for TCP, UDP, ICMP and so on.
Regards
This is called a statefull firewall. All modern firewalls use connection states, so you only have to define rules in one direction, the way back will then be allowed automatically by the connection tracking table.
With Mikrotik you have to setup a statefull firewall by your own rules! So you need to define at least two rules for INPUT and FORWARD chains wich have to evaluate the connection states "established,related, untracked" in their settings.
How long connections can stay open when there is no traffic for a period of time or the connection breaks unexpectedly without normal TCP FIN, can be defined in your firewall setup in the CONNTRACK table settings. Here you can define different settings for TCP, UDP, ICMP and so on.
Regards
2
Thx a lot @7010350221, your explanation is likely to be a better explanation than anything out there, simple, short, clear.
I have rules in place and CONNTRACK table settings are default.
How is the flow for the first package, the one with the state NEW?
As described in the OP?
I have rules in place and CONNTRACK table settings are default.
How is the flow for the first package, the one with the state NEW?
As described in the OP?
Zitat von @PackElend:
How is the flow for the first package, the one with the state NEW?
As described in the OP?
How is the flow for the first package, the one with the state NEW?
As described in the OP?
It's going the "forward" path, because it's not a packet for the router itself ...
1
What I expected but only once from VLAN interface to WAN interface, then directly to my ISP.
Before it hits the VLAN interface it is going to be decapsulated (VLAN tag removed)?
Before it hits the VLAN interface it is going to be decapsulated (VLAN tag removed)?
Zitat von @PackElend:
Before it hits the VLAN interface it is going to be decapsulated (VLAN tag removed)?
Before it hits the VLAN interface it is going to be decapsulated (VLAN tag removed)?
Yes.
1Zitat von @PackElend:
Before it hits the VLAN interface it is going to be decapsulated (VLAN tag removed)?
Before it hits the VLAN interface it is going to be decapsulated (VLAN tag removed)?
Yes. The first image shows it clearly. Traffic is assigned to the logical interface inside
the router (vlanX) after decapsulation.
1
If that's all, please mark this thread as solved. Thanks.
1
I would like to finish it with marking all up in copies of the the referenced pictures.
should happen tomorrow still work in progress there has been to much to do today
1
Hello again,
I may have THE answer, hope you confirm, fingers are crossed.
My credits go to
I'm still searching for a good reference for what ChatpGPT said so well
I will go from switching to briding to routing post by post, adding more details picture by picture
The entire PowerPoint (source of the pictures) can be shared on request.
May I get a response from rickfreyconsulting to update the drawing with the switch chip.
I may have THE answer, hope you confirm, fingers are crossed.
My credits go to
- Understanding Packet Flow in RouterOS v6 - YouTube
- Packet Flow Diagram – Best packet flow diagram to date | Rick Frey Consulting
I'm still searching for a good reference for what ChatpGPT said so well
Logical interfaces, such as VLAN interfaces, are separate interfaces that operate at Layer 3 and are not considered part of the bridge for packet flow decisions. They handle the IP configuration and routing for specific VLANs but do not directly influence the packet forwarding decisions within the bridge.
I will go from switching to briding to routing post by post, adding more details picture by picture
The entire PowerPoint (source of the pictures) can be shared on request.
May I get a response from rickfreyconsulting to update the drawing with the switch chip.
here is what is written in the image
- LOWER LEFT
IMHO, "Switching Decision" is a bit irritating when it comes to packet flow description,
as a switch only forwards packets between ports (+ …casting).
In the case of VLAN awareness, it alters VLAN tag as well.
More details see Packet Flow in RouterOS - RouterOS - MikroTik Documentation --> switching decision & switch-cpu port --> So,
Input: to Switch-CPU Port
Output: from Switch-CPU Port
as a switch only forwards packets between ports (+ …casting).
In the case of VLAN awareness, it alters VLAN tag as well.
More details see Packet Flow in RouterOS - RouterOS - MikroTik Documentation --> switching decision & switch-cpu port --> So,
Input: to Switch-CPU Port
Output: from Switch-CPU Port
- ORANGE BOX
VLAN tag is handled by Switch Chip VLAN Table:
“VLAN ID-based forwarding takes into account the MAC addresses dynamically learned or manually added in the host table. QCA8337 and Atheros8327 switch-chips also support Independent VLAN Learning (IVL) which does the learning based on both - MAC addresses and VLAN IDs, thus allowing the same MAC to be used in multiple VLANs.”
“VLAN ID-based forwarding takes into account the MAC addresses dynamically learned or manually added in the host table. QCA8337 and Atheros8327 switch-chips also support Independent VLAN Learning (IVL) which does the learning based on both - MAC addresses and VLAN IDs, thus allowing the same MAC to be used in multiple VLANs.”
- BLUE BOX
ANY TRAFFIC BETWEEN THE BRIDGE PORTS AS THEY ARE ALL HARDWARE OFFLOADED. CONFIGURATION FOLLOWING Bridge VLAN Table (standard as from ROS v6.41 )
- ORANGE BOX
- BLUE BOX
If there are bridge ports, which are not connected to the Switch Chip, traffic must be allowed to flow to CPU (software), this is done by adding the bridge itself as a port. Otherwise, traffic will be dropped at the SWITCHING DECISION.
An example can be an hEX S where the SFP port acts an uplink and all ports are members of the same bridge.
VLAN tag is handled by Switch Chip VLAN Table and Bridge VLAN Table
An example can be an hEX S where the SFP port acts an uplink and all ports are members of the same bridge.
VLAN tag is handled by Switch Chip VLAN Table and Bridge VLAN Table
- LEFT, UPPER ORANGE BOX
Packet is not part of VLAN (subnet) anymore, VLAN tag to be removed.
- LEFT, MIDDLE ORANGE BOX
VLAN interfaces, are not considered as part of the bridge in this context.
- LEFT, LOWER ORANGE BOX
VLAN Interface of the bridge as it is tagged traffic, see Bridge vs VLAN Interface
- RIGHT, LOWER-END, ORANGE BOX
New VLAN (subnet), VLAN tag to be added.
- MIDDLE, LOWER-END, ORANGE BOX
VLAN TAGGED of SOURCE SUBNET
not VLAN TAGGED
VLAN TAGGED of TARGET SUBNET
not VLAN TAGGED
VLAN TAGGED of TARGET SUBNET
- BLUE BOX
Inter VLAN routing (excluding L3 Hardware offload), VLAN tagged removed when leaving VLAN, forwarded as normal IP packet on L3, retagged, when entering target VLAN, e.g from VLAN ID 120 (User 2) to VLAN ID 100 (Common Services).
- ORANGE BOX
VLAN TAGGED of SOURCE SUBNET
not VLAN TAGGED
not VLAN TAGGED
- BLUE BOX
from VLAN host to WAN, very similar to inter-VLAN routing but it is going to the WAN interface instead the other VLAN interface.
In this case, it is assumed that the router
has Switch Chip, otherwise in and out
Interfaces are the faded interfacesIn this case, it is assumed that the router
has Switch Chip, otherwise in and out
On CPU level (as on the original drawing).
ALL DONE!
any thoughts community?
