Re: [f-nsp] Layer 2 packet forwarded in hardware(PP)
Franz Georg Köhler <[email protected]> Fri, 14 Sep 2018 10:50:28 +0200
| Newsgroups | gmane.network.nsp.foundry |
|---|---|
| Message-ID | <[email protected]> |
On Do, Sep 13, 2018 at 08:23:06 -0600, Eldon Koyle <[email protected]> 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 _______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp