Increasing your firewall capacity via LACP and bundling

Almost all modern firewall supports LACP aka 802.3ad.
In this post,  I will show you some very simple aggregation bundles for  the following firewall types;

• cisco-ASA ( 9.1.4smp ) 
• Juniper-SRX  ( 12.1X46-D10.2 )
• fortinet-fortigate-(5.0.5)

1st why do we bundle links?    

• To provide redundancy  ( multi-path )
• and for increased capacity ( bandwidth )

These general rules applies for the enabling  of  802.3ad members for aggregation;

(1)
Each member must be of the same speed-type. What this means; " if you're enabling  2 members, each member must be of the same speed "

2x 1/10/40GIGE = okay
2x FastEthernet = okay
1 1gig interface + 1 fastethernet = not-okay


NOTE: Don't try enabling a  1gige member in a bundle with a 10gige member or pair a FastEthernet with a  1gig member. You can mix  interface types ( i.e copper and fiber , or SFP+SX and LX  )  on most cisco and other vendor gear. I haven't seen a lot of devices that will complain if you bundled a 1gige copper interface with a 1 gige fiber SFP interface.

(2)

At least one side must be enable for LACP-active. The table below, will show you some of the valid neighbors configuration methods for LACP;

Which one you will enable,  depends on your hardware and your needs. You will almost never go wrong with ACTIVE-ACTIVE imho.


NOTE: If you have problems establishing neighbor ship, you might have to set one side as passive for all members.

(3)

Aggregation bundle numbers/names etc....... DO NOT  need to match in order for LACP to work

NOTE: A lot of junior cisco engineer think the port-channel #s used for both side must match, this is  100% completely wrong.

(4)

Aggregation members ports, must run at full-duplex.  DO NOT try to  bundle half-duplex links into a bundle.

NOTE:  I should not need to explain why this would be bad!

(5)

LACP partner keys are not always supported on all models & devices. So LACP should automatically build the administration key for the partner ports.

In this demonstration we will use a common cisco switch ( 6509 ) with the following items

• 1gige interfaces
• We will  bundle 2x 1gige interfaces to the attached firewalls
• The switch & firewalls will be configured for active LACP but I will do the SRX as passive in  the below example

What that means, either party can negotiate and start the LACP aggregation protocol except for the SRX, which will only setup  LACP up on the cisco 6509 actively sending LACP requests.


(our cisco-switch  port-configs used  thru out this post )

=========================================================================

(1st our cisco-asa FIREWALL  port-configs + show commands )

Now let's look at a cisco-ASA  firewall running 9.1.4 code.

1st, Until recently, the cisco ASAs didn't support LACP, they only had the option for the non-negotiated bundling of interfaces member. It 's a good ideal to backup the configuration when making changes to this magnitude or doing any reconfiguration work.

e.g

copy runming  disk0:mybackup.cfg


Previous codeset allowed only static bundles  ( ASA   <  9.1.2  )  but starting with  cisco ASA  code 9.1.3+ , supports for  802.3ad exists. You have the choice either active or passive 802.3ad.

( a  basic  config with  active mode )

And a show port brief will provide you details on the port-channel;

and like with  the cisco switch,  a show lacp neighbor will give you the lacp  status;

=========================================================================

(2nd up,  our juniper SRX port-configs + show commands )




The juniper SRX has support 802.3ad for  some time now, and from my understanding;  " any make and models of the  SRX platform has 802.3ad support.  "

1st, To enable a  802.3ad lag group, you will have to do a  few more task under Junos.  All interfaces must be cleared of any objects or attachments. What that means;

• remove from any security zone
• remove  any interface vlans
• removed from any sub-interfaces ( vlan tagging )
• remove any ip_addressing
• remote the logic unit interface
• etc........

NOTE: B4 you conduct any  changes of this magnitude you might want to consider backing up the existing config. You can always revert back to a previous configuration.


I find it very simple to run a  few show commands to find any objects bound to the interfaces that you are going to bundle. This will give you a ideal of what needs to be cleared.


e.g

2nd, to enable a  802.3ad interface you will need to configure the LAG setup from the CLI. I not even100% sure if any jweb  manger allows you to do 803.2ad link bundling via the WebGUI. And jweb is horrible at best so I rarely ever use it.

IMPORTANT: enable the aggregation ethernet interface counts 1st before anything else , here we are defining up to 2 "ae" interfaces

NOTE:  Do this command first. Without it; "  you can never create a virtual AE interface ".

Now, we craft the  AE interfaces members by binding the physical members to our virtual "ae" interface

3rd, after you have built your  AE interface ( Aggregate Ethernet ),  you can now add an ipv4/6 address and apply it to your security-zone like any other  interface on a SRX series of firewall.

e.g

Diagnostics are quite simple and the following cli show commands will  provide  you 802.3ad linkstatus for the SRX.

show lacp interface
show lacp statis

NOTE: when the links are bundle the cli cmd show interface  ae ,  will show the speed as the bundled speed in this case 1gig+1gig =2gbps


=========================================================================

(FORTIGATE  firewall )




The fortigate series of firewalls also provide  802.3ad aggregation but with limitations. You can't  execute lacp bundles on the smallest series of firewall from fortinet. In my  experiences, models 110 or smaller, do not support  802.3ad. So stick with a 2XX or larger unit YMMV, &  if you ever plan on deploying LACP.

FWIW:  The smaller SOHO models really don't have enough interfaces for justifying  LACP. And typically you don't need lacp bundle in a SOHO arena.


NOTE:  Just like the juniper SRX, you can  have anything bound to the Physical members that you are  planning to  bundle.

This includes any of the following;

• VPN
• DHCP-servers
• members of another type  of interface or tunnels
• any ip address
• or associated in any vdom outside of root

To craft a bundle-interface, you 1st need to build & define  the Pseudo-Interface name.

Choose a name that's not  normally used as a existing/default name  or associate with any other interfaces.  Here, I've crafted my interface with the simple name of bond and added members  ports #1 and #2 to my aggregate .

Now this bundle Pseudo-Interface name bond can be applied to VPN, fwpolicies, and used like any  other standard interface.

Just like the with the  SRX , the member port1 and port2,  can not have any  interface level configuration attached to it nor have any other dependencies attached such as ( see my warning above );

• DHCP -server
• VPNs
• ip/ip6 address
• pppoe configurations
• etc.....

With any configuration changes;  " it's best to backup your configurations  & think out the design and goals that you want to achieve ". 

So this  wraps up  LACP bundling of  3 different models of firewalls.

On the cisco switch, by using the logging event bundle status  for the members,  logging information will shown when a member enters or leaves a bundle;

Dive in and give it a try, you will find that  lacp-bundling is  not very hard to execute.

Ken Felix

Freelance Network / Security Engineer

kfelix  ----a---t---socpuppets ---d---o---t---com

     ^      ^

=(   #   #  )=

          o

       /    \