Date: Sun, 6 Mar 2011 20:29:30 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: fredrik danerklint <fredan@fredan.se> Cc: freebsd-net@freebsd.org Subject: Re: ifconfig lo1 down Message-ID: <alpine.BSF.2.00.1103062028200.6104@ai.fobar.qr> In-Reply-To: <201103061642.31177.fredan@fredan.se> References: <201103051943.41917.fredan@fredan.se> <AANLkTimq703bJA0dg=y%2B0vHF-1vSMjYnM5jR7eoinVR9@mail.gmail.com> <201103061642.31177.fredan@fredan.se>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--0-5102154-1299443371=:6104
Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8BIT
On Sun, 6 Mar 2011, fredrik danerklint wrote:
Hi,
> lördagen den 5 mars 2011 21.10.19 skrev Sergey Kandaurov:
>> On 5 March 2011 21:43, fredrik danerklint <fredan@fredan.se> wrote:
>>> Hi,
>>>
>>> I would like to know what is the differents between ip4 and ip6 for this
>>> command.
>>>
>>> First:
>>>
>>> #ifconfig lo1
>>> lo1: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
>>> options=3<RXCSUM,TXCSUM>
>>> inet xx.xx.xx.2 netmask 0xffffffff
>>> inet6 2a03:xxxx:xxxx::xxxx:xx02 prefixlen 128
>>> nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
>>>
>>> $ ping xx.xx.xx.2
>>> PING xx.xx.xx.2 (xx.xx.xx.2): 56 data bytes
>>> 64 bytes from xx.xx.xx.2: icmp_seq=0 ttl=64 time=0.012 ms
>>> 64 bytes from xx.xx.xx.2: icmp_seq=1 ttl=64 time=0.010 ms
>>> ^C
>>>
>>> and
>>>
>>> $ ping6 2a03:xxxx:xxxx::xxxx:xx02
>>> PING6(56=40+8+8 bytes) 2a03:xxxx:xxxx::xxxx:xx02 -->
>>> 2a03:xxxx:xxxx::xxxx:xx02 16 bytes from 2a03:xxxx:xxxx::xxxx:xx02,
>>> icmp_seq=0 hlim=64 time=0.053 ms 16 bytes from
>>> 2a03:xxxx:xxxx::xxxx:xx02, icmp_seq=1 hlim=64 time=0.032 ms ^C
>>>
>>> Now we run this command:
>>>
>>> # ifconfig lo1 down
>>>
>>> and trying to ping again:
>>>
>>> $ ping xx.xx.xx.2
>>> PING xx.xx.xx.2 (xx.xx.xx.2): 56 data bytes
>>> ping: sendto: No route to host
>>> ping: sendto: No route to host
>>> ping: sendto: No route to host
>>> ^C
>>> --- xx.xx.xx.2 ping statistics ---
>>> 3 packets transmitted, 0 packets received, 100.0% packet loss
>>>
>>> works as expected (and this is what I want) but this command, however:
>>>
>>> $ ping6 2a03:xxxx:xxxx::xxxx:xx02
>>> PING6(56=40+8+8 bytes) 2a03:xxxx:xxxx::xxxx:xx02 -->
>>> 2a03:xxxx:xxxx::xxxx:xx02 16 bytes from 2a03:xxxx:xxxx::xxxx:xx02,
>>> icmp_seq=0 hlim=64 time=0.048 ms 16 bytes from
>>> 2a03:xxxx:xxxx::xxxx:xx02, icmp_seq=1 hlim=64 time=0.033 ms 16 bytes
>>> from 2a03:xxxx:xxxx::xxxx:xx02, icmp_seq=2 hlim=64 time=0.032 ms ^C
>>> --- 2a03:xxxx:xxxx::xxxx:xx02 ping6 statistics ---
>>> 3 packets transmitted, 3 packets received, 0.0% packet loss
>>> round-trip min/avg/max/std-dev = 0.032/0.038/0.048/0.007 ms
>>>
>>> My question is why is it not the same behavior of ip6 as of ip4?
>>
>> That's how forwarding works/differs for ipv4 and ipv6.
>> You should be able to ping xx.xx.xx.2 again after adding static route.
>> Something like route add xx.xx.xx.2 -iface -lo1.
>
>>
>> I can only say for the moment that from my observation ipv4 "routes to
>> itself" exist as far as interface is up, and ipv6 routes don't depend on
>> if iface is up. You can check this with netstat -r for both addresses with
>> iface up and down.
>
> Hmm... take a look at this:
>
> Internet:
> Destination Gateway Flags Refs Use Netif Expire
> xx.xx.xx.2 link#8 UH 0 0 lo1
>
> Internet6:
> Destination Gateway Flags
> Netif Expire
> 2a03:xxxx:xxxx::xxxx:xx02 link#8 UHS
> lo0
>
> See the differents? For ip4 it uses the correct interface, lo1, but on ip6 it
> uses the lo0 interface and sure enough it is not down at all.
It's new-arp fallout and related to the carp problems with IPv6.
/bz
--
Bjoern A. Zeeb You have to have visions!
Stop bit received. Insert coin for new address family.
--0-5102154-1299443371=:6104--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1103062028200.6104>