Hi lurker888,
thanks again(!) for the review! So, if I understand correctly, two concerns:
1. redundancy / over-complication by using first a connection-mark and then converting to routing-mark
2. not only redundancy but potential problem due to conflict: same traffic (e.g. "chain=prerouting in-interface=ether1") will/might receive 2x connection mark: new-connection-mark=plc1-conn and new-connection-mark=from-mgmt
To fix this, simply collapsing the redundant rules into one would fix both issues?
(already changed in the guide post).
Thanks you!! Jürgen
P.S. if you really "overdose" on that coffee, I am happy to test this VRF configuration
but really no pressure!! I just tested the final configuration from the write-up and it seems fine!
thanks again(!) for the review! So, if I understand correctly, two concerns:
1. redundancy / over-complication by using first a connection-mark and then converting to routing-mark
2. not only redundancy but potential problem due to conflict: same traffic (e.g. "chain=prerouting in-interface=ether1") will/might receive 2x connection mark: new-connection-mark=plc1-conn and new-connection-mark=from-mgmt
To fix this, simply collapsing the redundant rules into one would fix both issues?
Code:
# before/ip firewall mangleadd chain=prerouting in-interface=ether1 dst-address=172.29.10.101 action=mark-connection new-connection-mark=plc1-conn comment="Mark PLC1 Connections"add chain=prerouting in-interface=ether1 connection-mark=plc1-conn action=mark-routing new-routing-mark=to-plc1 comment="Mark route to PLC1"# afteradd chain=prerouting in-interface=ether1 dst-address=172.29.10.102 action=mark-routing new-routing-mark=to-plc1 comment="Route to PLC1"
Thanks you!! Jürgen
P.S. if you really "overdose" on that coffee, I am happy to test this VRF configuration

Statistics: Posted by juwalter — Mon Apr 07, 2025 2:32 am