Date: Fri, 18 Oct 2013 16:53:46 -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: <CAGQ6iC8_aKxWsUeuKVRoVMxmUx7Ca--YCAioCRJ6H6w3Vj1mtw@mail.gmail.com> In-Reply-To: <CAGQ6iC_Nhn1jU5y4--XKAtPnGa0igZTyOSpUNh_S4rarBXw3Cg@mail.gmail.com> References: <CAGQ6iC-fKZARrqQrhbswS3YGZqOfOctR9C7B6xSO43LnXh_yTw@mail.gmail.com> <525F8C4F.5090303@FreeBSD.org> <CAGQ6iC9AAFHux4e=TvO8By1dyoSshAfunatn75y-EU0jz-GU_w@mail.gmail.com> <5260147D.3000907@FreeBSD.org> <CAGQ6iC_Nhn1jU5y4--XKAtPnGa0igZTyOSpUNh_S4rarBXw3Cg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Upgraded from 9.1 to 9.2-RELEASE, problem solved. Thank you all! Raimundo Santos On 17 October 2013 14:31, Raimundo Santos <raitech@gmail.com> wrote: > > 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?CAGQ6iC8_aKxWsUeuKVRoVMxmUx7Ca--YCAioCRJ6H6w3Vj1mtw>