From owner-freebsd-net@FreeBSD.ORG Sun Mar 6 20:30:06 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EABE106564A for ; Sun, 6 Mar 2011 20:30:06 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id 0F6C28FC0A for ; Sun, 6 Mar 2011 20:30:05 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 06E7925D37C7; Sun, 6 Mar 2011 20:29:33 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 07837159A2E3; Sun, 6 Mar 2011 20:29:33 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id YgEJBvDi6C0T; Sun, 6 Mar 2011 20:29:31 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 6F1CC159A2D8; Sun, 6 Mar 2011 20:29:31 +0000 (UTC) Date: Sun, 6 Mar 2011 20:29:30 +0000 (UTC) From: "Bjoern A. Zeeb" To: fredrik danerklint In-Reply-To: <201103061642.31177.fredan@fredan.se> Message-ID: References: <201103051943.41917.fredan@fredan.se> <201103061642.31177.fredan@fredan.se> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-5102154-1299443371=:6104" Cc: freebsd-net@freebsd.org Subject: Re: ifconfig lo1 down X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 20:30:06 -0000 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 wrote: >>> Hi, >>> >>> I would like to know what is the differents between ip4 and ip6 for this >>> command. >>> >>> First: >>> >>> #ifconfig lo1 >>> lo1: flags=8049 metric 0 mtu 16384 >>> options=3 >>> inet xx.xx.xx.2 netmask 0xffffffff >>> inet6 2a03:xxxx:xxxx::xxxx:xx02 prefixlen 128 >>> nd6 options=3 >>> >>> $ 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--