Hi Guru's,
I'm capturing traffic using 'diagnose sniffer packet' on an Enhanced MAC VLAN-Interface.
The capture contains the proper mac-address from the VDOM. However, when I capture on the client side, it seems that mac address has changed to a different address. I think it's the 'di hardware deviceinfo nic emac-vlan' -> Current_HWaddr address, probably inserted by the EMacvlan Ethernet driver.
Is this correct behaviour and is it possible to retain the original VDOM mac-address? Because this breaks our source based mac forwarding on the loadbalancer.
Regards!
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
This is an internal bug. If your environment is NP7+HA+EMAC_VLAN+VIP, and the phenomenon is that the MAC of EMAC_VLAN will change (one session/traffic will have multiple MAC addresses of EMAC_VLAN), then it matches this bug. Will be fixed in 7.0.12GA/7.2.5GA/7.4.0GA.
Thanks
Kangming
Hi Team,
Thank you for posting your query.
FortiGate implements an enhanced version of MAC VLAN where it adds a MAC table in the MAC VLAN which learns the MAC addresses when traffic passes through.
FortiGate implements an enhanced MAC VLAN consisting of a MAC VLAN with bridge functionality. Because each MAC VLAN has a unique MAC address, virtual IP addresses (VIPs) and IP pools are supported, and you can disable Source Network Address Translation (SNAT) in policies.
Please check the implementation example:-
https://docs.fortinet.com/document/fortigate/6.2.14/cookbook/212317/enhanced-mac-vlans
https://docs.fortinet.com/document/fortigate/7.2.4/administration-guide/212317/enhanced-mac-vlan
Regards
Priyanka
Hi
May I know your device model? There are some differences between NP6 and NP7 devices.
Did you use VIP? Or is it just the MAC address of the interface?
Thanks
Kangming
Device model is a 1800F which is a NP7?
We are using VIPs on the F5 with Source Mac Routing (default settings "auto last hop"), which breaks when we replace the interfaces with emacs. When the F5 returns website traffic, the root vdom drops the traffic, probably because the traffic is returned to the wrong destination mac address.
With Mac Routing the F5 ignores the routing table, and just returns traffic from the source mac it originated from. Emacs seems to (at least in our setup) break the mac routing.
Hi
FGT1800F is NP7 device.
Actually, we already have an internal bug 0820268 working on it, and the issue has been fixed on 7.0.12 and V7.2.5, but need to wait for the GA release. FOS 7.2.5GA will be released in the next few weeks.
Thanks
Kangming
Can I find the bug description 0820268 somewhere? I would like to check if this is the problem we are running into. We now are thinking about giving every vdom it's own physical cables to work around the emacs issue.
This is an internal bug. If your environment is NP7+HA+EMAC_VLAN+VIP, and the phenomenon is that the MAC of EMAC_VLAN will change (one session/traffic will have multiple MAC addresses of EMAC_VLAN), then it matches this bug. Will be fixed in 7.0.12GA/7.2.5GA/7.4.0GA.
Thanks
Kangming
Each VDOM has a separate physical interface or a VLAN interface is a good method.
Thanks
Kangming
V7.0.12GA has been released, please upgrade and try again.
Thanks
Kangming
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1733 | |
1106 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.