From owner-freebsd-net@freebsd.org Wed Aug 29 00:17:37 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 38F64109B912 for ; Wed, 29 Aug 2018 00:17:37 +0000 (UTC) (envelope-from marius.h@lden.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C0C3F741EA; Wed, 29 Aug 2018 00:17:36 +0000 (UTC) (envelope-from marius.h@lden.org) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 2CEC721BF7; Tue, 28 Aug 2018 20:17:36 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute7.internal (MEProxy); Tue, 28 Aug 2018 20:17:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lden.org; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=UV91ghz/fxm6YCy+Zzqbp0ayGmIcN jzNx8Cdzb3Eq1s=; b=aXIhUdNLPp8yZgkrHObjmp7mP3MPAocDXjc63p2Jv4CRh QVH1JbVVp94uuxyFjvS8vd1FR7+f+Ox2sy0rRw0d0if76y3fHCCommQKOUmx58U8 DYlSZ5GiJPdMeUBFaVq7BceCb8yt9kAwNXcwVsHbevXlXuiRq3yksbbG5+H0V7If 4QkFIhSixfjgpB3PnrJOm5ILif1KwYeITUnAm17NW6GZc608RBRKMjEKQ4J4WBhn TyKMFYlsd8DJST3q2ALZ0Vc5BDRpuHyoedDGLEQ+mAlqielBTq2y2Di2A0cKEIrt JpjpuQg9u//5YS8f6G6xowbETBWUPWrOKzBk300lA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=UV91gh z/fxm6YCy+Zzqbp0ayGmIcNjzNx8Cdzb3Eq1s=; b=wegVgV3u2wQyAimRPQK0rv cjocekGOQerBGhB0GE4LaMvH9z8pn1aCPsZVlwIKMVsFyKPLQCHsOWbJoZXEXLOG c1HUQkKb+6GjnZ6EYOIklX8wwr3neByKkXBF9LWY52pu8rQAgVgUADV0cfoCE21u nTuKZCFNNRXKGXXLMoArtQbiu/lchem6O/Wf293VB10n3Za/9TXJoNlcXZBVL2lc ylqroVJ3ncOsISYQr58OcnXwheksiLRjNbsQ9u+8fXunTSioAWzxft3bmgcxCiqb GIwMFm3fbbuJOPHLEE1WEXlP/XL3+lItsiMlCdz2MkSQEE0OiEea61i2Xz5H7Nhw == X-ME-Proxy: X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 51E589E48A; Tue, 28 Aug 2018 20:17:35 -0400 (EDT) Message-Id: <1535501855.1625820.1489435784.68EBD122@webmail.messagingengine.com> From: Marius Halden To: Kevin Oberman Cc: "freebsd-net" , np@freebsd.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-7b72137a Subject: Re: cxl nic not working after reboot References: <1535379569.2132387.1487489784.45227861@webmail.messagingengine.com> <20180827151302.GA10167@ox> <1535395530.234212.1487804896.64257978@webmail.messagingengine.com> <1535448912.3229649.1488521184.1EE83C33@webmail.messagingengine.com> <3bdfa15a-1b9f-e8cd-00a5-f5fdaaa5d15e@FreeBSD.org> <1535480853.1508751.1489107768.35E0F6F1@webmail.messagingengine.com> <72e8b5b8-631b-35b3-b378-804e69dd3250@FreeBSD.org> <1535484638.1530345.1489178328.3374515B@webmail.messagingengine.com> <32fc6737-87f8-7156-17f0-8e17b65a0812@FreeBSD.org> <1535487192.1547312.1489227960.14DA5D07@webmail.messagingengine.com> Date: Wed, 29 Aug 2018 02:17:35 +0200 In-Reply-To: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Aug 2018 00:17:37 -0000 On Wed, Aug 29, 2018, at 01:50, Kevin Oberman wrote: > On Tue, Aug 28, 2018 at 1:14 PM Marius Halden wrote: > > > On Tue, Aug 28, 2018, at 21:34, Navdeep Parhar wrote: > > > On 8/28/18 12:30 PM, Marius Halden wrote: > > > > tx_frames does move, rx_frames is stuck at zero. The following > > counters are non-zero and does increase when traffic is sent through the > > interface, all other are stuck at zero: > > > > > > > > dev.cxl.0.stats.tx_frames_65_127: 26083 > > > > dev.cxl.0.stats.tx_frames_64: 4084 > > > > dev.cxl.0.stats.tx_mcast_frames: 26083 > > > > dev.cxl.0.stats.tx_bcast_frames: 4084 > > > > dev.cxl.0.stats.tx_frames: 30167 > > > > dev.cxl.0.stats.tx_octets: 2608846 > > > > > > > > Anything else I should look at? > > > > > > > > > > What is on the other side of the link? Look at the peer's rx stats and > > > see if it received the frames that cxl0 claims it has transmitted or not. > > > > Our ISPs router is connected to the other side. Unfortunately I don't have > > access to any of the counters, but from what I understood when originally > > debugging this with our ISP they did not see any traffic. If needed I can > > ask them to check the rx counters tomorrow. > > > > -- > > Marius Halden > > > > This looks a lot like either a routing or NDP issue with the adjacent > router. Well, an NDP issue devolves to a routing issue. It also possible > that RDP is an issue, but, if you can't ping the opposite end, that > eliminates RDP. You might check for NDP traffic with tcpdump or wireshark > when the connection is restored. If you are not IPv6 conversant, NDP is the > IPv6 replacement for ARP and it's pretty obvious how this would impact your > connectivity. I do see ARP requests and neighbor solicitations with tcpdump, but not any replies for either. Though I'm pretty sure that's just a symptom of the problem and not the root cause considering both ipv4 and ipv6 will start working again if the SFP is removed and reinserted. What is RDP in this context? -- Marius Halden