Fortigate - ARP-Issues after Upgrade 5.6.6 to 5.6.9 - Unicast flooded to all switch-ports

[KPS]

Hi!

I just updated my 200E-Cluster from 5.6.6 to 5.6.9. Now, I have a very strange issue:

The unicast-traffic that passes the fortigate is "acting" like broadcast-traffic.

--> The traffic is sent to every switchport

If I monitor the traffic on ANY switchport, I see all the unicast-packets, that where routed by the fortigate.

If I ping the fortigate from the destination IP, the problem stops instantly.

Do you have any idea, what happens there?

For me, the Fortigate seems to "forget" to use the ARP-table for those packets. If I have "incoming" traffic (destination=fortigate), that ARP seems to work fine.

The ARP for one test-server:

#diagnose ip arp list | grep 10.49.0.48 index=34 ifname=DMZ-HO-Bond 10.49.0.48 00:50:56:89:xx:xx state=00000004 use=369512 confirm=372713 update=368876 ref=4

Thank you for your help!

KPS

[kubimike]

This applies to spanning tree only. What type of switches do you have what model ? Very odd you don't have that command? Perhaps its because of the age of your OS ? Why do you run such an old release ? The idea here is you want the Fortigate as root.

[KPS]

I think, we are talking about different things:

I am not using Fortinet-Switches. I am using Dell and Arista with RSTP enabled.

The system version of my fortigates is 5.6.9 - not very old, but I am not using them as switches.

[kubimike]

No we are talking about the same thing so you do have spanning tree turned on for the switches it seems. So yeah you'll need to see why your OS doesn't include the config stp. I've had great success with version 6.0.4 

[KPS]

Tomorrow, I will remove one port of the bond to test, if the bond is involved in the problem.

5.6.6 did not show that behavior...

[kubimike]

Thats a good test. Make sure you don't have any health monitors to trigger a failover. 

[KPS]

HI!

I removed the "redundancy-link", but the problem is still there and very strange.

According to the docs, ARP-Cache should be at least 5 minutes, but that is not the case.

Test:

Ping "over Fortigate" to ip.

--> get system arp | grep IP --> Entry exists after ping:

get system arp | grep 10.49.0.51
10.49.0.51 0 00:50:56:96:49:b2 DMZ-HO-Bond

61 seconds later, the ARP-entry is away:

fg200e_HZ_1_1 (root) # get system arp | grep 10.49.0.51

Thank you and best wishes

KPS

[mjcrevier]

You mentioned this link is a "bond" then also mentioned "redundant link". Do you know which one you're using?

You can check with "diag netlink aggregate list"

How are your switches configured? Are they stacked or using MCLAG? How do you physically have them connected?

Typically, I see unicast flooding in environments where the MAC/ARP timers have been incorrectly configured, or where there is asymmetry. Are you doing any routing on your Arista/Dell switches?

[KPS]

Hi!

I am only using "redundant" interfaces (active-passive) and so, there is no config on the switches for LAGs, etc.

The switches are not doing any routing.

[emnoc]

Why use a redundant link? I never even heard of this, can you show us your interface config? This might be part of the issue and maybe it was or was not going up prior to the upgrade and now you're seeing or noticing it.

I would also check for "local switch mac address table" for mac-addr flapping. I 'm betting the member links are and persistent with the layer2 mac-table of the switch.

[KPS]

Hi!

I am a bit confused. I use redundant interfaces (Type: Redundant Interface) for years to avoid problems, if a switch fails.

I can confirm, that there is no outgoing traffic on the secondary link and that mac-address-tables are stable.

Don't you use redundant interfaces??

...and the config

    edit "DMZ-HO-Bond"
        set vdom "root"
        set ip 10.49.0.2 255.255.255.0
        set allowaccess ping https ssh snmp http fgfm
        set type redundant
        set explicit-web-proxy enable
        set member "port3" "port4"
        set role lan
        set snmp-index 29
    next