I am using  EZBRCIFR to trace TCP/IP traffic, and this works well.

I see there is support to trace dropped packets.

I have set

my.filter.RCFLPkt.RCPKFiltFlags |= RCPKFDISCARD;   (it is set to 1200)
my.filter.RCFLPkt. RCPKDiscard    = traceDiscard;     (it is the value 1)

If I ping a valid address 7.168.1.74 I get out trace data.

If I ping an invalid address 7.168.1.75 ... I do not get  any data.

Wireshark on Linux  shows the traffic on the interface.

Should I see the packet with the invalid address on the interface?  or have I misread the documentation?

I would expect a reason code of IP_OPT_FWD =The packet cannot be forwarded. 

Colin

If I define my interface with PRIROUTER, I can see the packets, and I get drop reason code IP_NO_FWD     The packet cannot be forwarded as expected.

Colin,

We need more information about your TCPIP stack configuration on IBM Z.  Do you have the TCPIP profile that you can send us for our review?  Please note that while the PRIROUTER, SECROUTER, and NONROUTER settings are configured for an OSA interface in the TCPIP profile, they are passed to the OSA to enable or disable IP forwarding to the owning LPAR whereas IP forwarding can be enabled in the TCPIP stack via the IPCONFIG DATAGRAMFWD parameter.  If NONROUTER is coded, IP forwarding is disabled in the OSA for packets having unknown destinations. Unknown destination means that the target IP address in the packet does not match any home IP address in a TCPIP stack of a LPAR.  Otherwise, the OSA will forward the packets to first LPAR with PRIROUTER if available.  If that is not avaiable, then the OSA forward the packets to the first LPAR with SECROUTER. Please note that because of the confusion and complexity with the PRIROUTER and SECROUTER settings, IBM recommends using VMAC ROUTEALL (or VMAC ROUTELCL) for best practice.  If VMAC is coded on an OSA interface, the default is ROUTEALL because the default IP forwarding option in a TCPIP stack is IPCONFIG DATAGRAMFWD where the TCPIP stack can forward packets with unknown destinations to a neighbor LPAR or network router (for example, default router).   If a TCPIP stack does not have IP forwarding enabled, then it will drop packets with unknown destinations sent from the OSA that has IP forwarding enabled.  VMAC ROUTEALL is equivalent to PRIROUTER and SECROUTER in that the OSA will forward packets with unknown destinations to the LPAR that owns the VMAC.  VMAC ROUTELCL is equivalent to NONROUTER in that the OSA will not forward packets with unknown destinations to a LPAR.  For the ping, I assume that it is issued from IBM Z to zLinux guest with Wireshark. 

Thanks!

Best regards- Jon Bell (JB)
IBM z/OS Communications Server Support

Colin, 

When specifying an invalid IP address in the ping command, was the ping was issued from z/OS to another LPAR or a network device running Linux with Wireshark?  If another LPAR, is it a zLinux guest on zVM?  As for the ping failure, did it result in "Destination Host unreachable" to indicate there is no matching route found in the local IP routing table to reach the destination and the ping request packet(s) will not be placed on the wire for the local LAN and therefore not traced at the receiving end.  Otherwise, if the ping failure had resulted in "Request timed out", then this indicates that no ping reply packet(s) were received within the default timeout (default 10 secs on z/OS CommServer).  This can be the result of a network congestion, ARP request or reply failure, packet filtering, routing error, or a silent discard.  To help locate the source of the packet drops for problem determination, a traceroute command can be used to display the nexthops of network or host devices acting as intermediate routers along a routing path to a destination.

Another point, depending on what IBM zSeries machine and what OSA-Express cards you're using, there is a known communications problem between the z/OS and z/VM LPARs sharing an OSA-Express card to result in the potential packet drops and there is a OSA microcode patch available to provide relief.  It has to do with the OSA card operating in Layer 3 mode for the z/OS LPAR and Layer 2 mode for the z/VM LPAR that includes the zLinux guest. 

Best regards- JB