[f-nsp] Layer 2 packet forwarded in hardware(PP)

Fri Sep 14 04:50:28 EDT 2018

On Do, Sep 13, 2018 at 08:23:06 -0600, Eldon Koyle <ekoyle+puck.nether.net at gmail.com> wrote:
> Have you tried running dm pstat?  It can sometimes help identify the type
> of traffic causing issues.  First run is a throwaway, it shows counts since
> the previous run.

Thank you, Eldon.
I think this is a hint into the right direction, it looks like a lot of
mac learning is taking place:

MODULE 2
----------

Total Packets Received:                  8696

MPLS uplink packets received:            0
    VPLS packets received:               0
    VLL packets received:                0
    L3 VPN packets received:             0
    Other MPLS packets received:         0

ARP packets received:                    2139
    ARP request packets received:        2107
    ARP response packets received:       2107

IPV4 packets received:                   234
    IPv4 unicast packets routed:         0
    IPv4 protocol packets received:      121
    GRE tunnel packets received:         0
    6to4 tunnel packets received:        0

IPV6 packets received:                   56
    IPv6 unicast packets routed:         0
    IPv6 protocol packets received:      29                       

IPv4 multicast packets routed:           0                        
IPv6 multicast packets routed:           0                        

L2VPN endpoint packets received:         0                        
    VPLS endpoint packets received:      0                        
    VLL endpoint packets received:       0                        
    Local-VLL endpoint packets received: 0                        

L2 packets received:                     7705                     
    L2 known unicast packets forwarded:  0                        
    L2 unknown unicast packets flooded:  1002                     
    L2 broadcast Packets flooded:        2147                     
    L2 multicast Packets flooded:        129                      
    Packets received for SA learning:    4721                     

Other packets received:                  0                        

Total Packets dropped:                   4937                     

Packet drop causes:                                               
         1 ( 0-Unknown cause)                                     
      4179 ( 1-Layer 2 packet forwarded in hardware(PP))          
       669 ( 9-Packet received for SFLOW sampling(PP))            
        13 (45-IP TTL too small(PE))                              
         5 (53-IPv4 protocol drop(PFE))                           
        37 (54-IP no route(PFE))                                  
        17 (56-Layer 3 invalid FID(PFE))                          
        14 (57-Ipv6 protocol drop(PFE))                           
         2 (67-DA learned on source port(OD))                     

ARP packets captured for DAI:            2139                     
ARP packets failed DAI:                  0  

Debugging says a lot of those lines:

# debug mac learning vlan 3595  
        learning:  debugging is on
Sep 14 10:09:25.761 info - macmgr_ipc_learn_da_entry. Learn DA 000c.2939.c197 IPC received
Sep 14 10:09:25.761 info - macmgr_ipc_learn_da_entry. Learn DA 000c.2939.c197 IPC received
Sep 14 10:09:25.761 info - macmgr_ipc_learn_da_entry. Learn DA 000c.2939.c197 IPC received
Sep 14 10:09:25.761 info - macmgr_ipc_learn_da_entry. Learn DA 000c.2939.c197 IPC received

However, we do not know that mac:

#sh mac-address 000c.2939.c197
Total active entries from all ports = 3089
Type Code - ST:Static SEC:Secure 1x:Dot1x NA: NotAvail A:Allow D:Deny
CCL: Cluster Client Local CCR:Cluster Client Remote CL:Local CR:Remote

It looks like the system cannot learn the DA 000c 2939 c197:

[ppcr_rx_packet]: Packet received
Time stamp : 31 day(s) 18h 37m 42s:,
TM Header: [ 00be 0196 0013 ]
Type: Fabric Unicast(0x00000000) Size: 190 Class: 0 Src sys port: 406
Dest Port: 0  Drop Prec: 0 Ing Q Sig: 1 Out mirr dis: 0x0 Excl src: 1 Sys mc: 1
**********************************************************************
Packet size: 182, XPP reason code: 0x00000000
00: a054 2003 3850 0e0b-0020 008a 0000 0000  FID     = 0xa054
10: 000c 2939 c197 000c-29f5 951b 0800 4500  Offset  = 0x10
20: 0306 b617 4000 4011-5981 0a0a 0a1b 0a0a  VLAN    = 3595(0x0e0b)
30: 0a20 eb71 08af 02f2-b549 7b22 5365 7665  CAM     = 0x100045(R)
40: 7269 7479 2220 3a20-2269 6e66 6f22 2c22  SFLOW   = 0
50: 5461 6722 203a 2022-5c75 3030 3533 5c75  DBL TAG = 0
60: 3030 3635 5c75 3030-3732 5c75 3030 3736
70: 5c75 3030 3635 5c75-3030 3732 222c 2253
Pri CPU MON SRC   PType US BRD DAV SAV DPV SV ER TXA SAS Tag MVID
0   1   0   1/1   3     0  0   1   1   1   0  0  0   0   1   0

10.10.10.27 -> 10.10.10.32 UDP [60273 -> 2223] 
**********************************************************************
[ppcr_tx_packet] ACTION: Drop packet(reason: Layer 2 packet forwarded in hardware(PP))

I have know set "unknown-unicast-mac-entry" in the VLAN configuration
and this caused LP CPU to drop back to normal values because those
packets are not hitting the CPU any more. From the manual:
∙ Using the unknown-unicast-mac-entry command will forward Layer 2
unknown unicast traffic without going to the CPU.

The unknown-unicast-mac-entry command must be configured with the
vlan-cpu-protection command, as shown in the example above.

I guess the mac address in question is not in use and traffic towards
that address gets always flooded across the network.
Message "Layer 2 packet forwarded in hardware(PP)" still sounds a bit
bizarre to me. Maybe this means that packet is being forwarded in
hardware after it has been processed by CPU for learning?

Best regards,

Franz Georg