Brocade Communications Systems 12.4.00a Manual De Usuario
76
ServerIron ADX Security Guide
53-1002440-03
Enabling strict TCP or UDP mode for flow-based ACLs
2
Syntax: [no] hw-drop-acl-denied-packet
Enabling strict TCP or UDP mode for flow-based ACLs
By default, when you use ACLs to filter TCP or UDP traffic, the Brocade device does not compare all
TCP or UDP packets against the ACLs.
TCP or UDP packets against the ACLs.
For TCP and UDP, the device first compares the source and destination information in a TCP control
packet or a UDP packet against entries in the session table. The session table contains forwarding
entries based on Layer 3 and Layer 4 information:
packet or a UDP packet against entries in the session table. The session table contains forwarding
entries based on Layer 3 and Layer 4 information:
•
If the session table contains a matching entry, the device forwards the packet, assuming that
the first packet the device received with the same address information was permitted by the
ACLs.
the first packet the device received with the same address information was permitted by the
ACLs.
•
If the session table does not contain a matching entry, the device sends the packet to the CPU,
where the software compares the packet against the ACLs. If the ACLs permit the packet
(explicitly by a permit ACL entry or implicitly by the absence of a deny ACL entry), the CPU
creates a session table entry for the packet’s forwarding information and forwards the packet.
where the software compares the packet against the ACLs. If the ACLs permit the packet
(explicitly by a permit ACL entry or implicitly by the absence of a deny ACL entry), the CPU
creates a session table entry for the packet’s forwarding information and forwards the packet.
For TCP, this behavior by default applies only to control packets, not to data packets. Control
packets include packet types such as SYN (Synchronization) packets, FIN (Finish) packets, and RST
(Reset) packets.
packets include packet types such as SYN (Synchronization) packets, FIN (Finish) packets, and RST
(Reset) packets.
For tighter access or forwarding control, you can enable the device to perform strict TCP or UDP ACL
processing. The following sections describe the strict modes in more detail.
processing. The following sections describe the strict modes in more detail.
Enabling strict TCP mode
By default, when you use ACLs to filter TCP traffic, the Brocade device does not compare all TCP
packets against the ACLs. Instead, the device compares TCP control packets against the ACLs, but
not data packets. Control packets include packet types such as SYN (Synchronization) packets, FIN
(Finish) packets, and RST (Reset) packets.
packets against the ACLs. Instead, the device compares TCP control packets against the ACLs, but
not data packets. Control packets include packet types such as SYN (Synchronization) packets, FIN
(Finish) packets, and RST (Reset) packets.
In normal TCP operation, TCP data packets are present only if a TCP control session for the packets
also is established. For example, data packets for a session never occur if the TCP SYN for that
session is dropped. Therefore, by filtering the control packets, the Brocade device also implicitly
filters the data packets associated with the control packets. This mode of filtering optimizes
forwarding performance for TCP traffic by forwarding data packets without examining them. Since
the data packets are present in normal TCP traffic only if a corresponding TCP control session is
established, comparing the packets for the control session to the ACLs is sufficient for filtering the
entire session including the data.
also is established. For example, data packets for a session never occur if the TCP SYN for that
session is dropped. Therefore, by filtering the control packets, the Brocade device also implicitly
filters the data packets associated with the control packets. This mode of filtering optimizes
forwarding performance for TCP traffic by forwarding data packets without examining them. Since
the data packets are present in normal TCP traffic only if a corresponding TCP control session is
established, comparing the packets for the control session to the ACLs is sufficient for filtering the
entire session including the data.
However, it is possible to generate TCP data packets without corresponding control packets, in test
or research situations for example. In this case, the default ACL mode does not filter the data
packets, since there is no corresponding control session to filter. To filter this type of TCP traffic,
use the strict ACL TCP mode. This mode compares all TCP packets to the configured ACLs,
regardless of whether the packets are control packets or data packets. If the ACLs permit the
packet, the device creates a session entry for forwarding other TCP packets with the same Layer 3
and Layer 4 addresses.
or research situations for example. In this case, the default ACL mode does not filter the data
packets, since there is no corresponding control session to filter. To filter this type of TCP traffic,
use the strict ACL TCP mode. This mode compares all TCP packets to the configured ACLs,
regardless of whether the packets are control packets or data packets. If the ACLs permit the
packet, the device creates a session entry for forwarding other TCP packets with the same Layer 3
and Layer 4 addresses.