I s-l-o-w-e-d all traffic through my uplink. I used it on the inbound and outbound uplink lists.
I haven't found a way to identify whether or not my packets have options. I have a NAM. The packets have values in the 21st. byte of the packets, typically 05, 17, 19, or 0d. The 21st. byte is the first byte of the tcp header. Is this byte showing me info about the options?
Another method of blocking options uses the global config command:
"IP options present a security challenge for network devices because these options must be processed as exception packets. This requires a level of CPU effort that is not required for typical packets that traverse the network."
... which may account for the slowdown.
Your ACE specifies "IP" which is the first clue that it is an IP header field, and not a TCP header field that is relevant.
The first byte of the IP header is comprised of two four-bit fields (Version, Header Length).
The IP Version field is typically 0x4, and the Header Length field is typically 0x5.
The Header Length field specifies the header length measured in 32-bit words (4 bytes, if you prefer). Therefore a typical IP header is 20 bytes (5 x 4 bytes).
If this field is greater than 0x5, IP Options are being used.
If the global config command you've referred to doesn't suite your needs, take a look at Flexible Packet Matching.
Flexible Packet Filtering is yet another method of ACL. This time patterns in the packet can be matched on the very granular bit level. It is rocket science to do this, but XML and perhaps something like MARS, Cisco Self Defending Networks, (not now but probably in the future) will use it to do very fast ACL protection on edge devices. If you were good with XML and could identify the attack patterns, you might be able to implement a day 0 defence with this tool. Some kind of GUI would help with field identification and field patterns.
If the header length field is greater than 5 (X 4 octets per word = 20 octets) then options are being used. I will test this.
I am still reading the link on reflexive ACL entries. This technique allows you to do an "extabished" like filtering, used with TCP. It polices the establishment of all protocol flows, including, UDP, TCP, ICMP, etc., not just the TCP used in the "established" ACE.
I am still studying this and the IP options page listed above and will get back later..
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in HA
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationCo...
I am currently unable to specify "crypto keyring" command when configuring VPN connection on my cisco 2901 router.
The following licenses have been activated on my router :