From owner-freebsd-net@FreeBSD.ORG Fri Oct 18 19:54:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 63CFB9B2; Fri, 18 Oct 2013 19:54:08 +0000 (UTC) (envelope-from raitech@gmail.com) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 35B312A83; Fri, 18 Oct 2013 19:54:08 +0000 (UTC) Received: by mail-pb0-f51.google.com with SMTP id wz7so185495pbc.38 for ; Fri, 18 Oct 2013 12:54:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=jbF268gh6LaxI9BH/+QlwUzc2TJFcc8TJyaan0TnjUw=; b=s18+xdA4lKMvfhli1yd36PVILFFdt7RAJkRRoF1c/Q06Y0GsbB8+vZUwXaBkkPR6jH Pgn+SQA8FrXumpW3VS/X8SWYFSdsI8Kae94OYSfP4dw17SpPwyc3buOVHg4JtmqxToEg rvVClxmeO6iH7WdIFgR2MSN9+hpLT8N1XpkjEhZTnzBNbRkJZ14WXZ4lB+VIvqa1UvEX daH2SDeXlDRi/4bxK7/ybAiqr4O4a5Lz3HFcBejA3cCJ/u2U6DMnI/5WIWxai53kvUX9 Ocx3lu9QFPn1vGHSmxphk4UkRlfAJfEJtVTDRA003ALxTGLEJe0BdcD0WCH5QZkrxzUc kBhQ== X-Received: by 10.68.194.130 with SMTP id hw2mr4723587pbc.114.1382126047847; Fri, 18 Oct 2013 12:54:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.101.70 with HTTP; Fri, 18 Oct 2013 12:53:46 -0700 (PDT) In-Reply-To: References: <525F8C4F.5090303@FreeBSD.org> <5260147D.3000907@FreeBSD.org> From: Raimundo Santos Date: Fri, 18 Oct 2013 16:53:46 -0300 Message-ID: Subject: Re: ifconfig: ioctl (SIOCAIFADDR): File exists - but not only with alias command To: "Alexander V. Chernikov" , freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 19:54:08 -0000 Upgraded from 9.1 to 9.2-RELEASE, problem solved. Thank you all! Raimundo Santos On 17 October 2013 14:31, Raimundo Santos wrote: > > Oh my... I forgot to reply to list... an here we go again! > > > > On 17 October 2013 13:46, Alexander V. Chernikov wrote: > >> On 17.10.2013 18:25, Raimundo Santos wrote: >> >> On 17 October 2013 04:05, Alexander V. Chernikov wrote: >> >>> This seems rather strange. I'm using multiple fibs in production, and it >>> shouldn't behave that way. >>> >>> >> It occurs even with aliases. >> >>> >>> Can you do the following and send me output? >>> >>> 1) issue `route -n monitor` and log all messages >>> 2) add first address to interface >>> 3) do route -n get network_address (e.g. XX.XX.XX.16/28) for added >>> prefix (in fib 0 and fib 1) >>> 4) remove this address >>> 5) repeat step 3 >>> 6) add this prefix to another port >>> 7) repeat step 3 >>> >>> >> Hello, Alexander! >> >> The machine in question are under production, too. It hurts the results >> if I do these steps without removing all the addresses from the interface? >> >> By the way, this machine is a "border" router (not using BGP by now, >> but over the borders of my network and my providers network). All the >> addresses over this Intel NIC are routable, except in one port, where we >> have some equipment lying out the network (just don't ask why...) and all >> of them have private addresses. I saw the issue when trying to comunicate >> to these equipments adding and removing aliases in one of the ports. That >> said, there is an intersting output, after removing ALL the aliases from >> the refered NIC port: >> >> command issued: >> >> for i in `seq 0 14`; do \ >> echo "fib $i" >> routing.fibs; \ >> setfib $i netstat -rnfinet | grep '172\.31\.' >> routing.fibs; \ >> echo "--------------------------------" >> routing.fibs; \ >> done >> >> status of igb1 and 2: >> >> igb1: flags=8843 metric 0 mtu 1500 >> >> options=401bb >> ether 00:1b:21:5a:93:31 >> inet6 fe80::21b:21ff:fe5a:9331%igb1 prefixlen 64 scopeid 0x2 >> inet (routable addr) netmask 0xfffffff0 broadcast (routable addr >> broadcast) >> nd6 options=29 >> media: Ethernet autoselect (1000baseT ) >> status: active >> >> igb2: flags=8843 metric 0 mtu 1500 >> >> options=401bb >> ether 00:1b:21:5a:93:34 >> inet (routable addr) netmask 0xfffffff8 broadcast (routable >> broadcast) >> inet6 fe80::21b:21ff:fe5a:9334%igb2 prefixlen 64 scopeid 0x3 >> nd6 options=29 >> media: Ethernet autoselect (100baseTX ) >> status: active >> >> And the output of the commands: >> >> fib 0 >> 172.31.19.0/24 172.31.19.190 U 0 0 igb1 >> 172.31.20.0/24 172.31.20.190 U 0 0 igb2 >> >> ^^^^^^^^^^ >> This is probably installed by some routing daemon (issuing RTM_CHANGE >> message) >> (can be easily checked with `route -n monitor`) >> This is fixed in r248070 ( and merged to 9.2) >> >> -------------------------------- >> fib 1 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 2 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 3 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 4 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 5 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 6 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 7 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 8 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 9 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 10 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 11 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 12 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 13 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> fib 14 >> 172.31.19.0/24 link#2 U 0 0 igb1 >> -------------------------------- >> >> I never set 172.31.whatever over igb2! Just over igb1. >> >> Just to remeber: >> >> kernel options >> >> options VIMAGE >> >> # routing options >> options ROUTETABLES=15 >> # IPFW options >> options IPFIREWALL_FORWARD >> options IPFIREWALL_VERBOSE >> options IPFIREWALL_VERBOSE_LIMIT=300 >> options IPFIREWALL_DEFAULT_TO_ACCEPT >> >> Under >> >> FreeBSD 9.1-RELEASE-p4 >> >> Thank you for your time! >> >> >> > Okey, Alexander, I found the culprit: routed, running in this machine as > pid 99399. This is the result of 'route -n monitor' after doing a for loop > over all fibs and manualy removing 172.31.19/24 and 172.31.20/24. First > two, the deletes, last two, the adds. No RTM_CHANGE, so far, and the ADD > only apply to fib 0. (Thank you for the route monitor advice!) > > got message of size 192 on Thu Oct 17 14:14:01 2013 > RTM_DELETE: Delete Route: len 192, pid: 94802, seq 1, errno 0, flags: > locks: inits: > sockaddrs: > 172.31.19.0 172.31.19.190 (255) ffff ffff ff > > got message of size 192 on Thu Oct 17 14:14:07 2013 > RTM_DELETE: Delete Route: len 192, pid: 94819, seq 1, errno 0, flags: > locks: inits: > sockaddrs: > 172.31.20.0 172.31.20.190 (255) ffff ffff ff > > got message of size 191 on Thu Oct 17 14:14:29 2013 > RTM_ADD: Add Route: len 191, pid: 99399, seq 1142, errno 0, flags: > locks: inits: > sockaddrs: > 172.31.19.0 172.31.19.190 > pmsg_addrs: truncated route message, only 7 bytes left > > > got message of size 191 on Thu Oct 17 14:14:32 2013 > RTM_ADD: Add Route: len 191, pid: 99399, seq 1143, errno 0, flags: > locks: inits: > sockaddrs: > 172.31.20.0 172.31.20.190 > pmsg_addrs: truncated route message, only 7 bytes left > > From where routed take these addresses? When removing an fib entry, > doesn't it means that routed will never announce/add our whatever with the > non-existing entry? > > When came to changing, adding or removing an interface address, will it be > good to restart routing and routed services? > > And by upgrading to 9.2-RELEASE, may the issue goes away! > > Best regards, > Raimundo Santos >