1500D Bug Found and Confirmed by TAC

[Camshaft007]

All, we have discovered a bug in the 1500D’s with Fortinet TAC. I’m in the process of deploying 2 1500D clusters in our Primary and Secondary datacenters, while recycling our 800c clusters to all of our sister sites. The bug we discovered has to do with Aggregate and Redundant Interfaces… In short, they don’t work… The Aggregate ports are not negotiating LACP correctly with the Port Channel on the Cisco 2960s switch (Datacenter Switches will be Nexus 7Ks), but the 800c’s work flawlessly. Fortinet TAC and I looked at this problem from all sides and ultimately had this issue escalated to the engineers, which in turn replied to my open ticket that this is a known issue with the 1500D’s and has been reported to the Dev. Team(s).

---

Aggregate Interface issue: 1 port negotiates LACP fine, and comes on line, but other port sits in a “negotiating” state and never negotiates; thus causing the whole Aggregate to not work. Both Aggregate members are assigned different Aggregate IDs as well. Work around: only have 1 Member of the Aggregate Interface, all works fine.

---

Redundant Interface Issue: 1 port comes up, but the other does not, causing intermittent connectivity or no connectivity. Work around: only have 1 Member of the Redundant Interface, all works fine.

---

I’m glad we were able to Lab this scenario prior to pulling the trigger on the cut-over, because I would have been one upset engineer had this issue been discovered during a weekend cutover. Thoughts about a work around basically mean creating the Aggregate/Redundant Interfaces with a single member and moving forward with my cutover plans, and wait for a patch to correct this. Hope this helps someone in the future. Cam

[Tweety123]

Could you post the LAG interface config you're using?

We are using a 30G LAG for external and a 20G LAG for external config is as follows.

config system interface
    edit "external"
        set vdom "root"
        set ip <ipv4>
        set type aggregate
        set member "port33" "port34" "port35"
            config ipv6
                set ip6-allowaccess ping https ssh
                set ip6-address <ipv6>
            end
        set lacp-speed fast
        set algorithm L3
    next
end

config system interface
    edit "internal"
        set vdom "root"
 set allowaccess ping https ssh
        set type aggregate
        set member "port40" "port39"
        set lacp-speed fast
        set algorithm L3
    next
end

The other question I have, the fgfmsd is daemon is responsible for communications with FortiManager & I think FortiCloud, is this a managed unit?

Yes, it's managed by Fortimanager because of automatic rule deployment via API.