On 09/12/2008 07:18 PM, Fargusson.Alan wrote: > The problem I eluded to is that some network cards and hubs don't > send and receive at the same time, so if you send a packet to your > own IP address you don't see it come back. That means that you won't > be able to access machine x from machine x using the IP address. The > loopback interface always works, which is why most systems either use > a special route, or has a /etc/host entry to a 127.* address.
Either a special route or special code in the forwarding section of the IP implementation handles packages destined to any IP address which belongs to any local network interface by forwarding them to the loopback interface. Entries in /etc/hosts are just for the resolver (DNS), i.e. for conversion between hostnames and IP addresses. This is not related to IP packet forwarding (at least not directly). While this still leaves the reason for the observed entries in /etc/hosts open, I would like to point out the difference between routes and /etc/hosts. > -----Original Message----- From: Linux on 390 Port > [mailto:[EMAIL PROTECTED] Behalf Of John Summerfield Sent: > Friday, September 12, 2008 9:35 AM To: [email protected] > Subject: Re: 127.0.0.2 in /etc/hosts? > > Fargusson.Alan wrote: >> I just did a netstat -r on SLES 10 SP1 and I didn't see my IP >> routed to the loopback interface. I did a netstat -r on Windows >> and I did. It may be that SP1 fails to access itself on some >> networks. This may be the reason for the change. > gargant:~ root# netstat -rn Routing tables > > Internet: Destination Gateway Flags Refs > Use Netif Expire default 192.168.1.252 UGSc 5 > 2 en1 127 127.0.0.1 UCS 0 0 > lo0 127.0.0.1 127.0.0.1 UH 6 44459 > lo0 169.254 link#5 UCS 1 0 > en1 169.254.112.1 0:30:65:2:4:a9 UHLW 0 0 > en1 398 192.168.1 link#5 UCS 4 > 0 en1 192.168.1.71 0:30:65:2:4:a9 UHLW 0 0 > en1 422 192.168.1.250 127.0.0.1 UHS 0 > 0 lo0 192.168.1.252 0:d:56:c5:48:30 UHLW 3 67 > en1 1168 > So latest OS X is doing it. > > My Debian/Etch system does not. Whether it's because Debian does not, > or because it has several active interfaces I don't know. > > My sl5/CentOS5 systems do not. My WBEL4/CentOS4 systems do not. Linux also uses loopback routes for addresses of local interfaces, just more silently in the background. Take the following host with eth0 having address X.Y.108.38/22: > [EMAIL PROTECTED] sbin]# ip -4 address show dev eth0 > 7: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1492 qdisc pfifo_fast qlen 1000 > inet X.Y.108.38/22 brd X.Y.111.255 scope global eth0 Using the classic route command from the net-tools package does not reveal all: > [EMAIL PROTECTED] sbin]# route > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use Iface > X.Y.108.0 * 255.255.252.0 U 0 0 0 eth0 > 169.254.0.0 * 255.255.0.0 U 0 0 0 eth0 > default X.Y.108.1 0.0.0.0 UG 0 0 0 eth0 However, using the ip command from the iproute package is able to show every internal detail of the Linux routing machinery: > [EMAIL PROTECTED] sbin]# ip -4 route list table all > X.Y.108.0/22 dev eth0 proto kernel scope link src X.Y.108.38 > 169.254.0.0/16 dev eth0 scope link > default via X.Y.108.1 dev eth0 > local X.Y.108.38 dev eth0 table 255 proto kernel scope host src > X.Y.108.38 The above entry in some special in-kernel routing table, which is implicitly maintained, is of type local and its target is exactly the address of eth0. Whenever a route lookup returns such a route flagged local, the forwarding happens through the loopback interface. > broadcast 127.255.255.255 dev lo table 255 proto kernel scope link src > 127.0.0.1 > broadcast X.Y.108.0 dev eth0 table 255 proto kernel scope link src > X.Y.108.38 > broadcast X.Y.111.255 dev eth0 table 255 proto kernel scope link src > X.Y.108.38 > broadcast 127.0.0.0 dev lo table 255 proto kernel scope link src > 127.0.0.1 > local 127.0.0.1 dev lo table 255 proto kernel scope host src 127.0.0.1 > local 127.0.0.0/8 dev lo table 255 proto kernel scope host src 127.0.0.1 Here you also have the 127/8 network, which is all loopback. > [EMAIL PROTECTED] sbin]# ip route get X.Y.108.38 > local X.Y.108.38 dev lo src X.Y.108.38 > cache <local> mtu 16436 advmss 16396 hoplimit 64 You can use "ip" to find out what the routing/forwarding would do, if you sent a packet to the specified destination address. > [EMAIL PROTECTED] sbin]# ping -c1 X.Y.108.38 > PING X.Y.108.38 (X.Y.108.38) 56(84) bytes of data. > 64 bytes from X.Y.108.38: icmp_seq=1 ttl=64 time=0.039 ms > > --- X.Y.108.38 ping statistics --- > 1 packets transmitted, 1 received, 0% packet loss, time 0ms > rtt min/avg/max/mdev = 0.039/0.039/0.039/0.000 ms On actually sending something to that address, the following entries are added to the routing cache, revealing that the ICMP echo request was sent on the loopback interface and the echo reply was received from the loopback: > [EMAIL PROTECTED] sbin]# ip route list table cache > local X.Y.108.38 dev lo src X.Y.108.38 > cache <local> mtu 16436 advmss 16396 hoplimit 64 > local X.Y.108.38 from X.Y.108.38 dev lo > cache <local> ipid 0x8142 mtu 16436 advmss 16396 hoplimit 64 > ... > I imagine that route would allow one to use the IP address of a down > interface. I'm not sure I'd want that. Yes, you could reach your own host via the IP address of a down interface since packets would go through loopback. At least from a performance point of view, forwarding packets destined for oneself efficiently within the host is a good thing. AFAIK this has been the usual behavior of Unix IP stacks since BSD. Steffen Linux on System z Development IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Erich Baier Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
