From owner-freebsd-net@FreeBSD.ORG Thu Oct 17 17:32:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9159A896; Thu, 17 Oct 2013 17:32:17 +0000 (UTC) (envelope-from raitech@gmail.com) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 63FBB23FF; Thu, 17 Oct 2013 17:32:17 +0000 (UTC) Received: by mail-pa0-f50.google.com with SMTP id fa1so3063094pad.23 for ; Thu, 17 Oct 2013 10:32:17 -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=ATv5gPvPVg8LKNP1N5I7vojCgxwqmyJxG8vBC2Xj+rE=; b=Z1FnZgK2ODqQg6yD0UOdyyTbgupaJJgqyi22SNR8kVuECg6CcYgvs1mtYcgbvbWY82 ya6kliTs2VICiiIY3U1LMh/n9UZMwz9lKVeuS1nPZchqegEVpeP4M3tmu5ctyUMOcH7p EYtlxlwA0Y/0yBmIQn7/qgM0h19ERn71BNsyUmgfMZHumxTtpDmwRnL7eSbHAJfd0t7A 6UqYT7eEfZ4jW8pdjfjAb3KgPCaJ6VHkn0yWnv4+fXgfxhCh7XtPZJmIcrtUIrYT2XAT GEG5eEM7lWgbZ6sgHsq5QFdPukBfv1EKcm9QbzjtsiPlBa30HlS+24OouMKXkRnqvi6G Hhvg== X-Received: by 10.68.113.130 with SMTP id iy2mr9782335pbb.2.1382031136987; Thu, 17 Oct 2013 10:32:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.70.101.70 with HTTP; Thu, 17 Oct 2013 10:31:56 -0700 (PDT) In-Reply-To: <5260147D.3000907@FreeBSD.org> References: <525F8C4F.5090303@FreeBSD.org> <5260147D.3000907@FreeBSD.org> From: Raimundo Santos Date: Thu, 17 Oct 2013 14:31:56 -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: Thu, 17 Oct 2013 17:32:17 -0000 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