ifconfig: ioctl (SIOCAIFADDR): File exists - but not only with alias command
Raimundo Santos
raitech at gmail.com
Thu Oct 17 17:32:17 UTC 2013
Oh my... I forgot to reply to list... an here we go again!
On 17 October 2013 13:46, Alexander V. Chernikov <melifaro at freebsd.org>wrote:
> On 17.10.2013 18:25, Raimundo Santos wrote:
>
> On 17 October 2013 04:05, Alexander V. Chernikov <melifaro at 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
More information about the freebsd-net
mailing list