Date: Thu, 17 Oct 2013 14:31:56 -0300 From: Raimundo Santos <raitech@gmail.com> To: "Alexander V. Chernikov" <melifaro@freebsd.org>, freebsd-net@freebsd.org Subject: Re: ifconfig: ioctl (SIOCAIFADDR): File exists - but not only with alias command Message-ID: <CAGQ6iC_Nhn1jU5y4--XKAtPnGa0igZTyOSpUNh_S4rarBXw3Cg@mail.gmail.com> In-Reply-To: <5260147D.3000907@FreeBSD.org> References: <CAGQ6iC-fKZARrqQrhbswS3YGZqOfOctR9C7B6xSO43LnXh_yTw@mail.gmail.com> <525F8C4F.5090303@FreeBSD.org> <CAGQ6iC9AAFHux4e=TvO8By1dyoSshAfunatn75y-EU0jz-GU_w@mail.gmail.com> <5260147D.3000907@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Oh my... I forgot to reply to list... an here we go again! On 17 October 2013 13:46, Alexander V. Chernikov <melifaro@freebsd.org>wrote: > On 17.10.2013 18:25, Raimundo Santos wrote: > > On 17 October 2013 04:05, Alexander V. Chernikov <melifaro@freebsd.org>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<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 > > options=401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO> > 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<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > media: Ethernet autoselect (1000baseT <full-duplex>) > status: active > > igb2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 > > options=401bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO> > 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<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL> > media: Ethernet autoselect (100baseTX <full-duplex>) > 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:<DONE> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> 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:<DONE> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> 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:<DONE> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> 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:<DONE> locks: inits: sockaddrs: <DST,GATEWAY,NETMASK> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGQ6iC_Nhn1jU5y4--XKAtPnGa0igZTyOSpUNh_S4rarBXw3Cg>