Per Jessen wrote:

Per Jessen wrote:

...

I'm trying to assign a virtual IP to the loopback interface 'lo':

/etc/sysconfig/network/ifcfg-lo:

# Loopback (lo) configuration IPADDR_1=127.0.0.1/8 NETWORK=127.0.0.0 BROADCAST=127.255.255.255 STARTMODE=onboot USERCONTROL=no IPADDR_2=192.168.2.231/32

Can anyone spot why this isn't working?

I should add that the first ip-address 127.0.0.0/8 is added, but the second 192.168.2.231/32 isn't.

You can't set multiple IP addresses to a single interface. You need to create an alias interface, lo:1, for instance. However, you shouldn't be adding ip addresses to the loopback, unless absolutely necessary. Add it to eth0 instead. Just `ifconfig eth0:1 192.168.2.231`.

John Andersen wrote:

On Saturday 26 August 2006 06:04, suse@rio.vg wrote:

...

However, you shouldn't be adding ip addresses to the loopback, unless absolutely necessary. Add it to eth0 instead. Just `ifconfig eth0:1 192.168.2.231`.

Why shouldn't you add ip addresses to loopback?

What would be the point? Nothing else on that network could access it. loopback is specifically for the local machine only, there's no reason to have multiple ip addresses for it, unless you're doing something very strange.

Wouldn't your solution allow access via that IP, as well as potentially leaking martian traffic?

eth0:1 is considered a separate interface, for most purposes. And, yes, you'd be able to access the machine via that IP... why else would you add an IP address to a machine if you didn't want it to be able to access a network?

Kastus wrote:

Running tinydns on a loopback address for an internal domain is not strange at all. Then you can run dnscache on eth interface and point it to tinydns on loopback for that internal domain.

This allows to use the same host for multiple internal domains. For example, you have dev, QA, and prod environments. All use the same domain but should resolve to different IP addresses in different environments. Using multiple loopback addresses on the same host you can run tinydns for all your environments on the same host.

Fair enough. I've never used tinydns. Those times that I've had internal and external dns's, a firewall was involved, so they weren't on the same machine.

On top of that, run multiple instances of dnscache bound to different secondary addresses on eth interface. Then point DNS resolver to a diiferent dnscache depending on the environment (dev, qa, prod) and you get a way of testing your application in different environments using the same FQDNs.

I was always taught to stay away from loopback stuff, and just use alias eth interfaces as you mention here. I suppose in the grand scheme of things, one method is as good as another.

On Sat, Aug 26, 2006 at 10:29:24AM -0400, suse@rio.vg wrote:

...

Why shouldn't you add ip addresses to loopback?

What would be the point? Nothing else on that network could access it. loopback is specifically for the local machine only, there's no reason to have multiple ip addresses for it, unless you're doing something very strange.

Just forgot to mention one other possible use of secondary IP address on the loopback interface. If you are using using Foundry Networks ServerIron load balancer with direct server return feature, you need that secondary IP on the loopback to use the server in a pool. A pool configured on the LB is assigned an IP address. The same IP address is configured as secondary on loopback on all servers in that pool. When a packet is sent to the pool IP address, LB receives it, then tweaks packet on layer 2 substituting MAC address with an address of one of the servers in the pool leaving destination IP address intact. The packet is delivered to the server in question, and IP stack on that server accepts the packet because the host has destination IP address on its looopback interface. The source IP address of the packet is kept intact, so the server sends a response directly to the client bypassing LB on the way back, hence the name "direct server return". -Kastus

On Saturday 26 August 2006 06:29, suse@rio.vg wrote:

John Andersen wrote:

...

On Saturday 26 August 2006 06:04, suse@rio.vg wrote:

...

However, you shouldn't be adding ip addresses to the loopback, unless absolutely necessary. Add it to eth0 instead. Just `ifconfig eth0:1 192.168.2.231`.

Why shouldn't you add ip addresses to loopback?

What would be the point? Nothing else on that network could access it. loopback is specifically for the local machine only,

That is exactly the point. Sometimes you WANT things that way. -- _____________________________________ John Andersen

suse@rio.vg wrote:

John Andersen wrote:

...

That is exactly the point. Sometimes you WANT things that way.

This is true. I didn't say you can't. Generally, you shouldn't, unless you're absolutely certain. I don't know what application he's trying to set up, my post works equally well with lo or eth. It's just that I find suggesting eth instead of lo to be sound advice for most circumstances.

I'm setting up LVS, and it is recommended/required that you set up the virtual IP on a non-arping interface, eg. 'lo'. /Per Jessen, Zürich

suse@rio.vg wrote:

What would be the point? Nothing else on that network could access it.

That's not quite correct - in fact, it works perfectly well. The setup is working, I just now need to have it also setup after a reboot. /Per Jessen, Zürich

...

You can't set multiple IP addresses to a single interface. You need to create an alias interface, lo:1, for instance.

This is wrong. You can create multiple IP addresses for a single interface without the use of aliases: ip a a 1.2.3.4/5 dev eth0 ip a a 2.3.4.5/6 dev eth0 However, it may not be possible to do that right away with the config scripts, though.

Which is what I've tried to do with the config I posted.

...

However, you shouldn't be adding ip addresses to the loopback, unless absolutely necessary.

It is absolutely necessary.

The "lo" interface already responds to the whole 127.0.0.0/8 range even though only one address (.1) is assigned. What more? Jan Engelhardt --

Kastus Shchuka wrote:

...

...

I'm trying to assign a virtual IP to the loopback interface 'lo':

/etc/sysconfig/network/ifcfg-lo:

# Loopback (lo) configuration IPADDR_1=127.0.0.1/8 NETWORK=127.0.0.0 BROADCAST=127.255.255.255 STARTMODE=onboot USERCONTROL=no IPADDR_2=192.168.2.231/32

Configuration looks good to me. I might try adding NETWORK_2=255.255.255.255

I'm sure you meant NETMASK, but according to ifcfg.template, that is ignored when I've specified the address with a subnet-mask.

...

I should add that the first ip-address 127.0.0.0/8 is added, but the second 192.168.2.231/32 isn't.

How do you check for that? ifconfig might not show your secondary address. Try "ip addr show dev lo"

I just checked it with 'ifconfig', thinking that I should be seeing a second interface 'lo:n' ? # ip addr show dev lo 1: lo: mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet 192.168.2.231/32 scope global lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever Well, there it is! Excellent. Thanks. /Per Jessen, Zürich

Theo v. Werkhoven wrote:

I'm curious; why don't you use e.g. 127.22.0.1/32 as a virtual IP address (instead of an RFC1918 address)?

Because loopback addresses are not reachable from another machine, whereas 192.168.2.231 works fine on the local network. (which is 192.168.2). I need requests to 192.168.2.231 to go to a local machine (the LVS director), from where the requests are distributed across a number of servers. These servers need to _accept_ traffic as 192.168.2.231, but they cannot pretend to _be_ 192.168.2.231 externally.

It would then be a lot clearer that the addres belongs to LO imho, and not cause any possible confusion in the future.

The reason I assign it to 'lo' is that 'lo' does not respond to arp requests. There is more to this than meets the eye - if you to know more, check out the documentation for setting up a linux virtual server with direct routing (LVS-DR). /Per Jessen, Zürich

On Sun, Aug 27, 2006 at 02:55:02PM +0200, Per Jessen wrote:

The reason I assign it to 'lo' is that 'lo' does not respond to arp requests. There is more to this than meets the eye - if you to know more, check out the documentation for setting up a linux virtual server with direct routing (LVS-DR).

It does not respond to arp requests but it adverises your IP alias from 'lo' interface on the 'eth' interface. Please keep that in mind. That's why you either have to put your cluster members on a routed subnet or use static arp tables on the clients talking to the cluster. -Kastus