Header Only - DO NOT REMOVE - Extreme Networks

Lagging between Fortinet and Extreme SSA


Userlevel 1
We currently have a pair of Fortinet 1500D the have the internal port(s) connected to a C3 stack. I would like to take it off the stack and connect it to the SSA-T1068 at the top of the network for our central office. Last night I attempted to do so while upgrading some other switches. Let's say I was not very successful. Has anyone else encountered problems with Fortinet/Extreme interoperability? I am new to Extreme and any assistance would be very helpful.

15 replies

Are you sure the ports came up on the right speed/duplex? On Fortinet stuff, I have had to manually set speed and duplex once, but that was on a Fortigate 1000A.
Userlevel 1
I am pretty sure. What is baffling me is that I can connect it to any port in the stack with no configuration tweaking and it works.
Userlevel 4
In short, I agree that an S-Series Dynamic LAG should come up and function when connected. Has this unit been used previously for LAGs? Perhaps peer data learned earlier is being obstructive now.

A bit more background would be helpful; including (1) identification of the ethernet port numbers being used for the LAG, and (2) output of a '
code:
show config all lacp
', '
code:
show config all port
' (for each of these omitting the configs for ports not under discussion), and '
code:
show lacp
'.

You may alternatively consider opening a GTAC Support case to work this issue, then ultimately closing the loop here to report the cause and the resolution.
Userlevel 1
I do not currently have the Fortinet connected to the SSA because in doing so lots of network problems arise. I also want to clarify the Fortinet setup. We have a oair of 1500D's in an active active cluster. I was taking on cable from each and connecting it to the SSA. The info requested is below.

set lacp aadminkey lag.0.2
set lacp enable
set lacp singleportlag disable
set lacp flowRegeneration disable
set lacp outportAlgorithm dip-sip
set lacp outportLocalPreference none

set port advertise ge.1.5 10t 10tfd 100tx 100txfd bpause 1000tfd
set port advertise ge.1.6 10t 10tfd 100tx 100txfd bpause 1000tfd

set port broadcast ge.1.5 1488100
set port broadcast ge.1.6 1488100

set port discard ge.1.5 none
set port discard ge.1.6 none

set port ingress-filter lag.0.2 disable

set port ingress-filter ge.1.5 disable
set port ingress-filter ge.1.6 disable

set port jumbo disable ge.1.5
set port jumbo disable ge.1.6

set port lacp port ge.1.5 aadminkey 32768
set port lacp port ge.1.6 aadminkey 32768

set port lacp port ge.1.5 padminsyspri 32768
set port lacp port ge.1.6 padminsyspri 32768

set port lacp port ge.1.5 padminsysid 00-00-00-00-00-00
set port lacp port ge.1.6 padminsysid 00-00-00-00-00-00

set port lacp port ge.1.5 padminkey 261
set port lacp port ge.1.6 padminkey 262

set port lacp port ge.1.5 aportpri 32768
set port lacp port ge.1.6 aportpri 32768

et port lacp port ge.1.5 padminport 261
set port lacp port ge.1.6 padminport 262

set port lacp port ge.1.5 padminportpri 32768
set port lacp port ge.1.6 padminportpri 32768

clear port lacp port ge.1.5 aadminstate all
clear port lacp port ge.1.6 aadminstate all

clear port lacp port ge.1.5 padminstate all
clear port lacp port ge.1.6 padminstate all

et port lacp port ge.1.5 enable
set port lacp port ge.1.6 enable

set port oam ge.1.5 status disable
set port oam ge.1.6 status disable

set port oam ge.1.5 mode active
set port oam ge.1.6 mode active

set port oam ge.1.5 loopback-rx ignore
set port oam ge.1.6 loopback-rx ignore

set port oam ge.1.5 notify-retry 1
set port oam ge.1.6 notify-retry 1

set port priority lag.0.2 0

set port priority ge.1.5 0
set port priority ge.1.6 0

set port priority-queue lag.0.2 1 0
set port priority-queue lag.0.2 2 0
set port priority-queue lag.0.2 3 0
set port priority-queue lag.0.2 4 0
set port priority-queue lag.0.2 5 0
set port priority-queue lag.0.2 6 0
set port priority-queue lag.0.2 7 0

et port priority-queue ge.1.5 0 2
set port priority-queue ge.1.5 1 0
set port priority-queue ge.1.5 2 1
set port priority-queue ge.1.5 3 3
set port priority-queue ge.1.5 4 4
set port priority-queue ge.1.5 5 5
set port priority-queue ge.1.5 6 6
set port priority-queue ge.1.5 7 7
set port priority-queue ge.1.6 0 2
set port priority-queue ge.1.6 1 0
set port priority-queue ge.1.6 2 1
set port priority-queue ge.1.6 3 3
set port priority-queue ge.1.6 4 4
set port priority-queue ge.1.6 5 5
set port priority-queue ge.1.6 6 6
set port priority-queue ge.1.6 7

set port tcioverwrite lag.0.2 disable

et port tcioverwrite ge.1.5 disable
set port tcioverwrite ge.1.6 disable

set port trap ge.1.1-48 enable

set port trap lag.0.1-62 disable

set port vlan lag.0.2 11

et port vlan ge.1.5 11
set port vlan ge.1.6 11

Aggregator: lag.0.2
Actor Partner
System Identifier: 00:1f:45:fc:e8:23 00:00:00:00:00:00
System Priority: 32768 32768
Admin Key: 2
Oper Key: 2 2
Attached Ports: None.
Standby Ports: None.
Userlevel 4
Looks like if you issue '
code:
set port lacp port ge.1.5-6 aadminkey 2
' to override the
code:
32768
default, the aadminkey of these two intended underlying ethernet ports should then match that of the intended LAG aggregator ('
code:
set lacp aadminkey lag.0.2 2
'), allowing LAG lag.0.2 to form using underlying ports ge.1.5-6.

That may or may not be the whole story, but it should move things in the right direction.

You could as desired test the SSA with any other Dynamic LAG device. If it works with that test device, then it should work with the Fortinet. Based on my findings above, I surmise that SSA ports ge.1.5-6 are not LAGging with anything now - unless some other local LAG aggregator instance has a
code:
32768
aadminkey value.
Userlevel 1
What is the expected behavior of the SSA when it sees the connections are from two devices? Will spantree block one or both ports?
Userlevel 4
If you are saying that the other end of the LAG attaches to two separate devices, in that event you'll get two separate LAGs rather than an EXOS "Multi-LAG" which is not supported on the S-Series. However, here I've already seen that singleportlag is disabled and only two ports are in use for this LAG.

"
code:
We have a pair of 1500D's in an active cluster. I was taking one cable from each and connecting it to the SSA.
"

If this is what you are referring to here regarding "two devices", then if it worked as a Dynamic LAG to a SecureStack standalone or stack then it should work to a SSA as well. However, I am not familiar with how such a cluster would support a Dynamic LAG in a connection to another Fortinet or to a third-party peer device such as a SecureStack or S-Series.

If Spanning Tree remains enabled on the LAG aggregator and underlying ports, then yes, it should kick in to stop any detected loop regardless of whether or not one or more LAGs have formed - as long as BPDUs aren't being filtered within the path of the data loop.
Userlevel 1
I double checked the ports status in the stack that the Fortinets are connected to. It did not form a Dynamic Lag as previously thought, even though dynamic lagging is on in the stack. The port type shows as "access" as the other lags are "interswitch". This is coming from Oneveiw.
I still have a 1000A and an SSA laying around.. I'm going to try this..
Userlevel 1
I am going to contact GTAC and get a case opened. I'll post the outcome here.
Userlevel 1
I believe with the assistance of GTAC we may have found the issue. I may have a little VLAN hopping going on. This SSA was configured by Extreme's pro. services when it was installed before I was hired on. I am going to tweak the config one night this week when I have a chance to take the network down.
Userlevel 6
Thomas Maddox wrote:

I believe with the assistance of GTAC we may have found the issue. I may have a little VLAN hopping going on. This SSA was configured by Extreme's pro. services when it was installed before I was hired on. I am going to tweak the config one night this week when I have a chance to take the network down.

Thanks for keeping the Community informed as you go. Good stuff!
Userlevel 1
Ok so it took some time to be able to take the network down to attempt some changes. Over the course of three hours and two GTAC engineers we were able to solve the issue. Upgrading the firmware on the SSA is what resolved it. What led to this determination is that when I would connect the Fortinet to the designated ports on the SSA, by executing the show port status command I would see the ports as down/up, even though I got activity and link lights on the ports. Weird right? Anyway the firmware upgrade solve it and I am now routing all of the Districts traffic through the SSA instead of the Secure Stack which is the way it should be. Thanks to all who helped out.
Userlevel 7
Thomas Maddox wrote:

Ok so it took some time to be able to take the network down to attempt some changes. Over the course of three hours and two GTAC engineers we were able to solve the issue. Upgrading the firmware on the SSA is what resolved it. What led to this determination is that when I would connect the Fortinet to the designated ports on the SSA, by executing the show port status command I would see the ports as down/up, even though I got activity and link lights on the ports. Weird right? Anyway the firmware upgrade solve it and I am now routing all of the Districts traffic through the SSA instead of the Secure Stack which is the way it should be. Thanks to all who helped out.

Thanks for coming back to the community to share your solution! This is great!
Thomas Maddox wrote:

Ok so it took some time to be able to take the network down to attempt some changes. Over the course of three hours and two GTAC engineers we were able to solve the issue. Upgrading the firmware on the SSA is what resolved it. What led to this determination is that when I would connect the Fortinet to the designated ports on the SSA, by executing the show port status command I would see the ports as down/up, even though I got activity and link lights on the ports. Weird right? Anyway the firmware upgrade solve it and I am now routing all of the Districts traffic through the SSA instead of the Secure Stack which is the way it should be. Thanks to all who helped out.

AHH, you just jogged my memory. A long time ago when we had a 6509, I had the most difficult time setting up a lag between the 6509 and the S4. The 6509 would shut down a port in the LAG because it would detect a loop. I don't 100% remember all of the reasonings, but the solution was upgrading the code on the S4. Glad you solved the problem.

Reply