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

[ede_pfau]

Thanks for the heads-up. This might well influence the deployment of 1500D cluster in the pipe. Do you have any Bug ID we have to watch in the upcoming Release Notes? Did Fortinet eng hint at which patch release will fix this?

[SgtMalicious]

Is this an issue with the new NP6 ASIC or just the underlying PHY hardware on the 1500D? Does it affect the 3700D also?

[Matthew_Mollenhauer]

I' ve found the exact same problem while readying our 1500D' s to replace our 1240B' s. During my testing I found that the factory firmware, build 208 (which I think correlates with 5.0.3) worked. I also found 5.0.5 works as expected, but 5.0.6 does not. Now I' m sitting sitting on a 5.0.5 cluster that I don' t want to cutover to as there is no certainty that a future upgrade won' t take down the cluster. As ede_pfau asked, do you have a Bug ID, and when did TAC confirm to you this as a bug? I ask as I opened my case on the 6th and as of this moment the TAC haven' t confirmed this as a bug. I would suspect that Fortinet have known about this bug for a little while now as if you look at the Release notes for 5.0.7 both the 1500D & 3700D were removed from the supported devices list on the 17th of April. Nor are they supported models for the current 5.2 Beta/RC. Regards, Matthew Mollenhauer

[emnoc]

Qs: Is this problem effecting non 802.3ad aggregate-modes? Can you get by with static-bundles ?

[HA]

Hello all, For your informations, redundant interface is not working on Fortigate 240D. Release:5.0.7. I opened an SR and the TAC confirm it " There are reported issues regarding redundant links" . Regards, HA

[HA]

Hello all, Disabling Asic Offloading the policy solve the problem ! Unfortunately, it must be done for each policy... Waiting for a bug fix. Regards, HA

[ede_pfau]

That is,

config firewall policy
 edit <index_int>
 set auto-asic-offload {enable | disable}

?

[Matthew_Mollenhauer]

Qs: Is this problem effecting non 802.3ad aggregate-modes? Can you get by with static-bundles ?

I have seen this with both the " set lacp-mode" configured as active, passive & static. None work, if it was only the LACP negotiation that was broken then I think I could live with it. As for the asic offloading, aside from being very " time intensive" (we have over 600 policies in our Production environment) it also strikes me as turning off a major feature. We purchased the 1500D in part because it has the 8x10G spf+ interfaces but also because we want to take advantage of some of the UTM features, like IPS, AV, DLP and (in 5.2) passive SSL deep inspection. All of these features are either in the NP or CP and to have the unit turn off access to the NP just isn' t feasible. Matthew

[Camshaft007]

Sorry for the delay in getting back to the forums, I' ve actually been out of town and working on other major projects that include this one. However, I do have a Bug ID: 233810 , I also heard that the patch to correct this problem has been slated for EOB Monday 5/26/2014 . Of course, " No Promises" ... [:' (] Again, everyone sorry I' ve been away for so long.