HP 6125G HP Networking guide to hardening Comware-based devices - Page 18

Limiting the CPU impact of control plane traffic, Understanding control plane traffic

Page 18 highlights

Limiting the CPU impact of control plane traffic Protecting the control plane is critical. Because application performance and the end-user experience can suffer without the presence of data and management traffic, the survivability of the control plane helps ensure that the other two planes are maintainable and operational. Understanding control plane traffic To properly protect the control plane of HP Comware devices, it is essential to understand the types of traffic that is processed by the CPU. CPU-processed traffic normally consists of two different types of traffic. The first type of traffic is directed to the HP Comware device and must be handled directly by the HP Comware device CPU. This traffic consists of traffic to the device: • Traffic to the device This kind of unicast traffic matches FIB entries that either have a next hop of "127.0.0.1" or an outbound interface of InLoop0 (displayed with the display fib command), such as traffic destined to interface IP addresses. Some multicast traffic or broadcast traffic may also need to be processed by the device. The second type of traffic that is handled by the CPU is data plane traffic with a destination beyond the HP Comware device itself. This traffic requires special processing by the CPU. Although not an exhaustive list of CPU-impacting data plane traffic, these types of traffic are processed by the CPU and can therefore affect the operation of the control plane: • IP options Any IP packets with options must be processed by the CPU. • Fragmentation Any IP packet that requires fragmentation must be passed to the CPU for processing. • Time-to-live (TTL) expiry Packets that have a TTL value less than or equal to 1 require Internet Control Message Protocol Time Exceeded (ICMP Type 11, Code 0) messages to be sent, which results in CPU processing. • ICMP unreachables Packets that result in ICMP unreachable messages due to routing, MTU, or filtering are processed by the CPU. • ICMP redirects Packets received and transmitted on the same interface are processed by the CPU. • Traffic requiring an ARP request Destinations for which no ARP entry exists require processing by the CPU. • Non-IP traffic All non-IP traffic is processed by the CPU. The display fib command can be used to check the prefix and next-hop information. FTP and TFTP ACLs An FTP server can deny the FTP requests from some FTP clients and only permit the access of clients allowed by the ACL rules. The command to configure this feature is ftp server acl. For more information, see "FTP" and "TFTP" in the Fundamentals Configuration Guide. The tftp-server acl command can be used to control the device's access to a specific TFTP server using an ACL. User interface ACLs You can use ACLs to control access from telnet/SSH users to VTYs. The following gives an example configuration: # acl number 2001 rule permit source 192.168.1.26 0 # user-interface vty 0 4 acl [ ipv6 ] acl-number { inbound | outbound } # 18

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40

18
Limiting the CPU impact of control plane traffic
Protecting the control plane is critical. Because application performance and the end-user experience can suffer without
the presence of data and management traffic, the survivability of the control plane helps ensure that the other two
planes are maintainable and operational.
Understanding control plane traffic
To properly protect the control plane of HP Comware devices, it is essential to understand the types of traffic that is
processed by the CPU. CPU-processed traffic normally consists of two different types of traffic. The first type of traffic is
directed to the HP Comware device and must be handled directly by the HP Comware device CPU. This traffic consists of
traffic to the device:
Traffic to the device
This kind of unicast traffic matches FIB entries that either have a next hop of “127.0.0.1” or an outbound interface of
InLoop0 (displayed with the
display fib
command), such as traffic destined to interface IP addresses. Some multicast
traffic or broadcast traffic may also need to be processed by the device.
The second type of traffic that is handled by the CPU is data plane traffic with a destination beyond the HP Comware
device itself. This traffic requires special processing by the CPU. Although not an exhaustive list of CPU-impacting data
plane traffic, these types of traffic are processed by the CPU and can therefore affect the operation of the control plane:
IP options
Any IP packets with options must be processed by the CPU.
Fragmentation
Any IP packet that requires fragmentation must be passed to the CPU for processing.
Time-to-live (TTL) expiry
Packets that have a TTL value less than or equal to 1 require Internet Control Message Protocol Time Exceeded (ICMP
Type 11, Code 0) messages to be sent, which results in CPU processing.
ICMP unreachables
Packets that result in ICMP unreachable messages due to routing, MTU, or filtering are processed by the CPU.
ICMP redirects
Packets received and transmitted on the same interface are processed by the CPU.
Traffic requiring an ARP request
Destinations for which no ARP entry exists require processing by the CPU.
Non-IP traffic
All non-IP traffic is processed by the CPU. The
display fib
command can be used to check the prefix and next-hop
information.
FTP and TFTP ACLs
An FTP server can deny the FTP requests from some FTP clients and only permit the access of clients allowed by the ACL
rules. The command to configure this feature is
ftp server acl
. For more information, see “FTP” and “TFTP” in the
Fundamentals Configuration Guide
.
The
tftp-server acl
command can be used to control the device’s access to a specific TFTP server using an ACL.
User interface ACLs
You can use ACLs to control access from telnet/SSH users to VTYs. The following gives an example configuration:
#
acl number 2001
rule permit source 192.168.1.26 0
#
user-interface vty 0 4
acl [ ipv6 ] acl-number { inbound | outbound }
#