Learning Tcp flags

TCP标志详解:握手、确认与关闭
TCP标志包括SYN、ACK、FIN等,它们在建立和终止连接中起关键作用。SYN用于初始化三次握手,ACK确认接收到的数据,FIN表示发送方不再有数据。URG标记紧急数据,PSH提示立即处理数据,RST用于重置连接,ECE和CWR处理拥塞控制,NS是实验性的安全特性。

What are TCP flags?

Each TCP flag corresponds to 1 bit in size. The list below describes each flag in greater detail. Additionally, check out the corresponding RFC section attributed to certain flags for a more comprehensive explanation.

  • SYN - The synchronisation flag is used as a first step in
    establishing a three way handshake between two hosts. Only the first
    packet from both the sender and receiver should have this flag set.
    The following diagram illustrates a three way handshake process.
  • ACK - The acknowledgment flag is used to acknowledge the successful
    receipt of a packet. As we can see from the diagram above, the
    receiver sends an ACK as well as a SYN in the second step of the
    three way handshake process to tell the sender that it received its
    initial packet.
  • FIN - The finished flag means there is no more data from the sender.
    Therefore, it is used in the last packet sent from the sender.
  • URG - The urgent flag is used to notify the receiver to process the urgent packets before processing all other packets. The receiver will be notified when all known urgent data has been received. See RFC 6093 for more details.
  • PSH - The push flag is somewhat similar to the URG flag and tells the receiver to process these packets as they are received instead of buffering them.
  • RST - The reset flag gets sent from the receiver to the sender when a packet is sent to a particular host that was not expecting it.
  • ECE - This flag is responsible for indicating if the TCP peer is ECN capable. See RFC 3168 for more details.
  • CWR - The congestion window reduced flag is used by the sending host to indicate it received a packet with the ECE flag set. See RFC 3168 for more details.
  • NS (experimental) - The nonce sum flag is still an experimental flag used to help protect against accidental malicious concealment of packets from the sender. See RFC 3540 for more details.

Reference:

Tcpdump: Filter Packets with Tcp Flags

Understanding TCP Flags

Bridge Counters 10.15.1 Bridge Ingress Counters 10.15.1.1 Bridge Drop Counter The Bridge engine can assign a HARD or SOFT DROP command to packets for many reasons. The Bridge engine maintains a 32-bit counter that can be configured to count all bridge packet drop events, or only count packet drop events due to a specifically configured reason. The specific reasons for a Bridge drop are:  Spanning Tree port state drop (Spanning Tree Filtering)  FDB entry command drop (FDB Entry Command)  MAC SA Moved Event (Moved MAC Command)  ARP CPU code (Router Security Checks for Bridged IPv4/6 and ARP Traffic)  MAC SA is DA (Source Address is destination address)  Source IP Equals Destination IP Event (Source IP (SIP) is Destination IP (DIP))  TCP/UDP Source Port Equals Destination Port (TCP/UDP Source Port is Destination Port)  Invalid SA drop (FDB Source MAC Learning) (FDB Source MAC Learning)  TCP Packet With Fin Flag And Without Ack (TCP Flags with FIN without ACK)  IEEE Reserved Drop (IEEE Reserved Multicast)  ICMP (MLD and Other IPv6 ICMP)  TCP Packet Without Full Header (TCP Without Full Header)  IPv4 RIPv1 (Routing Information Protocol (RIPv1))  IPv6 Neighbor Solicitation (IPv6 Neighbor Solicitation)  Unregistered IPv4 Broadcast drop (Per-eVLAN Unregistered IPv4 Broadcast Filtering)  Unregistered non-IPv4 Broadcast drop (Per-eVLAN Unregistered Non-IPv4 Broadcast Filtering)  Cisco command (Proprietary Layer 2 Control Multicast)  Unregistered Non-IP Multicast drop (Per-eVLAN Unregistered Non-IPv4/6 Multicast Filtering)  Unregistered IPv4 Multicast drop (Per-eVLAN Unregistered IPv4 Multicast Filtering) Unregistered IPv6 Multicast drop (Per-eVLAN Unregistered IPv6 Multicast Filtering)  Unknown Unicast drop (Per-eVLAN Unknown Unicast Filtering)  Secure Automatic Learning Unknown SA drop (Secure Automatic Learning)  eVLAN not valid drop (Invalid eVLAN Filtering)  Physical Port not member in VLAN drop (eVLAN Ingress Filtering)  eVLAN range drop (eVLAN Range Filtering)  Moved static address drop (FDB Static Entries)  MAC Spoof Protection Event (MAC Spoof Protection)  ARP MAC SA Mismatch (ARP MAC SA Mismatch)  Controlled Learning Unknown MAC SA drop (Source MAC Address CPU Controlled Learning)  SYN with data (TCP SYN Packet with Data)  TCP over Multicast (TCP over MAC Multicast/Broadcast)  Bridge Access Matrix (Bridge Access Matrix)  Fragmented ICMPv4 (Fragmented ICMPv4)  TCP Flags Zero (Zero TCP Flags)  TCP Flags FIN, URG and PSH (TCP Flags with FIN-URG-PSH)  TCP Flag SYN and FIN (TCP Flags with SYN-FIN)  TCP Flags SYN and RST (TCP Flags with SYN-RST)  TCP/UDP Port is Zero (Zero TCP/UDP Port)  Bridge Access Matrix Drop (Bridge Access Matrix)  Acceptable Frame Type (Acceptable Frame Type Filtering)  eVLAN MRU (eVLAN Maximum Receive Unit (MRU))  Rate Limiting drop (Ingress Port Storm Rate Limit Enforcement)  Local ePort drop (Bridge Local Switching)  IP Multicast In Iana Range Drop (IP and Non-IP Multicast Filtering)  IP Multicast Not In Iana Range Drop (IP and Non-IP Multicast Filtering)  DSA Tag Source Device is Local Device Drop (Loop Detection) Configuration  To configure the Bridge Drop Counter reason, use the <Bridge Drop Counter Mode> field in the Bridge Global Configuration1 Register (Table 320 p. 2219).  To read/write to the Bridge Drop Counter, read/write to the <BridgeDropCnt> field in the Bridge Filter Counter Register (Table 368 p. 2309) according 10.15.1.2 Bridge Host Counters A set of Host Group counters is maintained for a configured MAC Source Address and MAC Destination Address. These counters correspond to RMON-1 MIB (RFC 2819) Host counters. Configuration  To configure the MAC DA to be used by the host counters, use the MAC Address Count0 Register (Table 373 p. 2311) and the MAC Address Count1 Register (Table 374 p. 2311).  To configure the MAC SA to be used by the host counters, use the MAC Address Count1 Register (Table 374 p. 2311) and the MAC Address Count2 Register (Table 375 p. 2311).  The hostInPkts counter can be read from the Host Incoming Packets Count Register (Table 376 p. 2311). This counter is clear-on-read.  The hostOutPkts counter can be read from Host Outgoing Packets Count Register (Table 377 p. 2311). This counter is clear-on-read.  The hostOutBroadcastPkts counter can be read from Host Outgoing Packets Count Register (Table 377 p. 2311) This counter is clear-on-read.  The hostOutMulticastPkts counter can be read from Host Outgoing Packets Count Register (Table 377 p. 2311). This counter is clear-on-read. 10.15.1.3 Bridge Matrix Group A packet counter is maintained for a single, CPU-configured MAC source/Destination Address pair. These counters correspond to RMON-1 MIB (RFC 2819) Matrix counters. Configuration Read the matrixSDPkts counter from the <MatrixSDPkts> field in the Matrix Source/Destination Packet Count Register (Table 380 p. 2312) accordingly. This counter is clear-on-read. Table 34: Host Counters Counter Name Counter Description hostInPkts The number of good packets1 with a MAC DA matching the CPU-configured MAC DA. hostOutPkts The number of good packets with a MAC SA matching the CPU-configured MAC SA. hostOutBroadcast Pkts The number of good Broadcast packets with a MAC SA matching the configured MAC SA. hostOutMulticastPkts The number of good Multicast Packets with a MAC SA matching the configured MAC SA. 1. Good packets are error-free Ethernet packets that have a valid frame length, per RFC 2819. Table 35: Matrix Source Destination Counters Counter Name Counter Description matrixSDPkts The number of good packets with a MAC SA/DA matching the CPU￾configured MAC SA/DA 10.15.1.4 Bridge ePort/eVLAN/Device Counters There are two sets of Ingress ePort/eVLAN/device bridge counters—Set-0 and Set-1. Each counter-set is applied to a configured packet Ingress stream based on eVLAN and ePort. eVLAN and ePort can be set as a wildcard (traffic from all ePorts for the eVLAN), all traffic for the ePort, and all traffic in the switch. Each counter-set can be configured independently. Each counter-set maintains four counters as described in Table 36. Table 36: Ingress Port/VLAN/Device Counters per Counter-Set Counter Name Counter Description Bridge In Frames Counter Number of packets received by the bridge according to the specified mode criteria. Depending on the mode selected, this counter can be used to satisfy Bridge and SMON MIB objects (RFC 2674 and RFC 2613) such as: • dot1dTpPortInFrames (mode 1). • smonVlanIdStatsTotalPkts (mode 2). • dot1qTpVlanPortInFrames (mode 3). eVLAN Ingress Filtered Packet Counter Number of packets discarded due to invalid eVLAN, eVLAN not in Range, or Ingress physical port not eVLAN member. This counter can be used to satisfy Bridge MIB objectdot1qTpVlanPortInDiscard (mode 3) Security Filtered Packet Counter Number of packets discarded due to Security Filtering measures: • FDB command drop (Section 10.4.4). • Invalid SA drop (Section 10.4.8). • Moved Static address is a Security Breach drop (Section 10.4.9). • Unknown source MAC command drop, and unknown source MAC is Security breach (Section 10.4.8.4). Bridge Filtered Packet Counter Number of packets dropped by the Bridge for reasons other than eVLAN Ingress filtering and Security breach events. This counter counts packets dropped due any of the following reasons: • Rate Limiting drop (Section 10.10, Ingress Port Storm Rate Limit Enforcement) • Local port drop (Section 10.13, Bridge Local Switching) • Spanning Tree state drop (Section 10.3, Spanning Tree Filtering) • IP Multicast drop (Section 10.12, IP and Non-IP Multicast Filtering) • Non-IP Multicast drop (Section 10.12) • Unregistered Non-IPM Multicast drop (Section 10.11.1.2, Per-eVLAN Unregistered Non-IPv4/6 Multicast Filtering) • Unregistered IPv6 Multicast drop (Section 10.11.1.4, Per-eVLAN Unregistered IPv6 Multicast Filtering) • Unregistered IPv4 Multicast drop (Section 10.11.1.3, Per-eVLAN Unregistered IPv4 Multicast Filtering) • Unknown Unicast drop (Section 10.11.1.1, Per-eVLAN Unknown Unicast Filtering) • Unregistered IPv4 Broadcast drop (Section 10.11.1.5, Per-eVLAN Unregistered IPv4 Broadcast Filtering) • Unregistered non-IPv4 Broadcast drop (Section 10.11.1.6, Per-eVLAN Unregistered Non-IPv4 Broadcast Filtering) This counter can be used to satisfy Bridge MIB objects: • dot1dTpPortInDiscards • dot1qTpVlanPortInDiscards Configuration  To configure counter set 0/1 criteria, use the <Set<n>ePort>, and <Set<n>CntMode> fields in the Counters Set<n> Configuration 0 Register (n=0–1) (Table 381 p. 2312) and the <Set<n>eVLAN> field in the Counters Set<n> Configuration 1 Register (n=0–1) (Table 382 p. 2312).  The following counters can be read from their respective registers. These counters are clear on read: • Set<n> VLAN Ingress Filtered Packet Count Register (n=0–1) (Table 384 p. 2313) • Set<n> Security Filtered Packet Count Register (n=0–1) (Table 385 p. 2313) • Set<n> Bridge Filtered Packet Count Register (n=0–1) (Table 386 p. 2313) • Set<n> Incoming Packet Count Register (n=0–1) (Table 383 p. 2313)翻译一下
11-18
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值