How to Check for Logical Errors on an Interface
Resolution
SNMP traps for logical interfaces
According to RFC 1213 the MIB will include only standard interface table. The traps are only for the system and interface groups that are incorporated in the MIB are supported.
PAN-OS 7.0 supports logical interfaces.
When running versions of PAN-OS up to 6.1.x , you can send intel on interface group for physical interfaces only, and not for logical interfaces. As a workaround, enable netflow to get this information.
For PAN-OS 5.0 and older
To check for logical errors on a specific interface (ethernet1/3 is used as an example) type the CLI command:
admin@Ironhide> show interface ethernet1/3
--------------------------------------------------------------------------------
Name: ethernet1/3, ID: 18
Link status:
Runtime link speed/duplex/state: 1000/full/up
Configured link speed/duplex/state: 1000/auto/auto
MAC address:
Port MAC address b4:0c:25:f8:e5:12
Operation mode: layer3
Untagged sub-interface support: yes
--------------------------------------------------------------------------------
Name: ethernet1/3, ID: 18
Operation mode: layer3
Virtual router default
Interface MTU 1500
Interface IP address: 192.168.9.1/24
Interface management profile: allowall
ping: yes telnet: yes ssh: yes http: yes https: yes
snmp: yes response-pages: yes userid-service: no
Service configured:
Interface belong to same subnet as management interface: Yes
Zone: trust_9999, virtual system: vsys1
Adjust TCP MSS: no
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Physical port counters read from MAC:
--------------------------------------------------------------------------------
rx-broadcast 0
rx-bytes 1775076722
rx-multicast 0
rx-unicast 13635670
tx-broadcast 110085
tx-bytes 6992300789
tx-multicast 0
tx-unicast 11299072
--------------------------------------------------------------------------------
These are the interface counters from the time the data-plane started on the firewall. These counters can be cleared with a data-plane restart only.
--------------------------------------------------------------------------------
Hardware interface counters read from CPU:
--------------------------------------------------------------------------------
bytes received 360
bytes transmitted 0
packets received 6
packets transmitted 0
receive errors 6
packets dropped 0
--------------------------------------------------------------------------------
Packets that fail the L2-L4 parsing checks will cause the receive errors counters above to increment and are dropped, they are not passed to CPU. Most common cases include invalid destination mac, invalid vlan tag, invalid ip, invalid tcp/udp port and so forth. For the above example we can see that there are 6 receive errors ( TCP packet too short), which are dropped and not passed to the CPU level and thus the packet received at the the logical interface counters is reading zero as shown below.
Logical interface counters read from CPU:
--------------------------------------------------------------------------------
bytes received 0
bytes transmitted 84
packets received 0
packets transmitted 2
receive errors 0
packets dropped 0
packets dropped by flow state check 0
forwarding errors 0
no route 0
arp not found 0
neighbor not found 0
neighbor info pending 0
mac not found 0
packets routed to different zone 0
land attacks 0
ping-of-death attacks 0
teardrop attacks 0
ip spoof attacks 0
mac spoof attacks 0
ICMP fragment 0
layer2 encapsulated packets 0
layer2 decapsulated packets 0
--------------------------------------------------------------------------------
After successful L2-L4 parsing of the packet, further security checks are done on the packet. Packets dropped due to security rules, Non-Syn tcp checks and other reasons will cause the above "packet dropped" counters to increment.
One can check the exact reason for the packet drop from the global counters. For example, the packets in this example are dropped at the l2-l4 parsing due to the highlighted reason in the below global counters.
admin@Ironhide> show counter global filter delta yes
Global counters:
Elapsed time since last sampling: 1.150 seconds
name value rate severity category aspect description
--------------------------------------------------------------------------------
pkt_recv 41 35 info packet pktproc Packets received
pkt_recv_zero 41 35 info packet pktproc Packets received from QoS 0
pkt_sent 7 6 info packet pktproc Packets transmitted
pkt_alloc 1 0 info packet resource Packets allocated
flow_rcv_err 1 0 drop flow parse Packets dropped: flow stage receive error
flow_rcv_dot1q_tag_err 5 4 drop flow parse Packets dropped: 802.1q tag not configured
flow_no_interface 5 4 drop flow parse Packets dropped: invalid interface
flow_fwd_l3_mcast_drop 11 9 drop flow forward Packets dropped: no route for IP multicast
flow_parse_l4_hdr 1 6 drop flow parse Packets dropped: TCP (UDP) packet too short
Counters can be cleared with the following CLI command:
> clear counter all
All counters cleared
owner: panagent