Jumbo Frames cisco ASA

In this post, we will look at the enabling of the jumbo-frames for ethernet interfaces on the cisco ASA
software version 9.1.4

The usage of jumbo frames allows for a bigger ethernet payload to be used, thus reducing the overhead & maximizing the media thru-put.

A cisco ASA uses the defacto 1514/1518 bytes MTU for the processing of ethernet frames ( non-802.1tag vrs 802.1q tagged ) . A frame bigger than these 2 values would be considered a  "giant" and would be dropped unless the interfaces supports a ethernet-frame bigger than  1518bytes.

When enabling jumbo-frame support, it will always require a reboot of the firewall or all units in a cluster.

e.g

To validate the status of jumbo frames, the cli cmd  "show jumbo reserve" will easy identify or provided a warning if the stand-by unit has not been enable  or reboot.

NOTE: You have to reboot all units in the cluster for the changes to take place & to be effective.


Now that you have the  jumbo frame supported, you can make changes per interface, to change the actual mtu via the cli cmd mtu < intf-name> <size>


e.g

and a quick check before/after the change,  will show you  the newly applied MTU value;


e.g

NOTE:  if you happen to try changing a interface MTU on a cisco ASA that didn't have  jumbo-frames enabled you will get the following warning.

Things to consider b4 enabling jumbo-frames;

•   does the layer2 switch port of the device directly connected, even  supports  jumbo frames ( it makes no sense to enable a device for jumbo but the switchport does not support jumbo frames )

•   what's the max recognized frame size that you expect to received

•   does your lan segment host/servers support jumbo frames

•   are you using PMTUd  for mtu discovery

•   does anything down or upstream support PMTUd

•   does anything on your lan/wan links drops icmp messages or does not  generate icmp-type 3 icmp-code 4 messages

•  Does you Software application have any restriction on the size of data per ethernet frame segment

• or udp/tcp-segments limits in the size of payload

You can monitor interface drops on the ASA with the following cmd

show interface < interface name> detail

e.g

and on a cisco switch  via the command;

 show int <number> counter errors

e.g

NOTE: Keep in mind that Jumbo frames are typically not supported across any networks paths outside of your control and the defacto 1514/1518 bytes ethernet-frame for  non-802.1q and 802.1q  are the norm. 

IMHO they ( jumbo ) are only to be trusted as supportive in networks paths that's under your control. So this means you can discount the INTERNET for support of Jumbo-Frames.

Ken Felix

Freelance Network / Security Engineer

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

     ^      ^

=(   ^   ^  )=

          o

       /     \

Logging suppression IOS-XR

In this post, we will look at one means for suppression of logging messages within IOS-XR. Take the following  recurring log messages from my nagios check_ssh plugin.

This check happens every 2-5 mins, & from various nagios servers. With this check going on, the logging buffer and log messages that's are sent to the remote-syslog servers, will be flooded with this useless message.

So how can we filter this? Very easy.

The means to filter these or similar  messages is quite simple with a suppression rule and  by applying the suppression. 1st let's look at how cisco classify all log messages.

http://www.cisco.com/c/en/us/td/docs/routers/crs/software/crs_r4-2/system_monitoring/configuration/guide/b_sysmon_cg42crs/b_sysmon_cg42crs_chapter_0100.html

All messages has  the following;

So knowing this information, will help in identifying the messages or via using log management/crunching tools like;   sawmill, splunk, ng-syslog, etc... You can write triggers to handle certain log messages base on the log message type and severity, etc.....

The same applies within the IOS-XR integral suppression. Here we will break down the log format and build a suppression rule named "dropitlikeitshot_log"

So for the  ssh error message;

%SECURITY-SSHD-6-INFO_GENERAL : Failed to read from socket


We now know the following

•   it's a SECURITY message from the SSHD service
•   with a severity of 6 { unix-information level]
•   the information is general
•   and the body contains "Failed to read from socket"

So a suppression rule can be built that will act on the values that we plugin into the rule. Suppression rules can be built for specific alarms  or all-alarms.

NOTE: If you choose the latter ( all-alarms ) this would not require a message-category , and may limit your flexibility with regards to the suppression of certain types of messages.

Now know the above following  details of our unix-like log messages, we can build a suppression rule and apply it.

Okay that was very easy and we learn of one way to build and activate a suppression filter.

Key points to consider b4 you start suppressing log messages;

•   if you suppress it,   the message would not be logged or recorded

•   beaware of any active suppression rules that are currently applied

•   you might want to disable suppression during any major upgrades to ensure nothing is suppressed from  your view

•   you don't have the luxury to apply suppression per logging destinations,  as you do within IOS, so suppression effects  ALL   local/remote/file-logging equally

•  modifying an active rule,  requires you to disable  the suppression before you can make any changes

Logging within IOS-XR is a need to ensure critical to informational events are always present. Without logging, we would blind to system generated events. It may come a time to filter certain types of messages from the logging systems to reduce load or eliminate redundant or useless information.

Ken Felix

Freelance Network / Security Engineer

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

     ^      ^

=(   <   >  )=

          o

       /     \

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

       /    \