/etc/sysconfig/network/ifcfg-lo - setting multiple IP-addresses
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? /Per Jessen, Zürich
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. /Per Jessen, Zürich
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`.
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? Wouldn't your solution allow access via that IP, as well as potentially leaking martian traffic? -- _____________________________________ John Andersen
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?
On Sat, Aug 26, 2006 at 10:29:24AM -0400, 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, there's no reason to have multiple ip addresses for it, unless you're doing something very strange.
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. 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. -Kastus
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:58:13AM -0400, suse@rio.vg wrote:
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.
That's very true. It's so easy to screw the whole network up by just specifying wrong netmask on the loopback. For any secondary IP it must be /32. I must admit I made that mistake multiple times. -Kastus
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
Kastus wrote:
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.
I'm setting up LVS-DR, and what you're saying sounds pretty similar. /Per Jessen, Zürich
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
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.
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
On Sun, Aug 27, 2006 at 08:39:38AM +0200, Per Jessen wrote:
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, you are out of luck here, unfortunately. In Linux, 'lo' is an arping interface. (It is not in Solaris). We learnt it the hard way with Foundry load balancers. The only workaround we came with was to use static arp tables on the clients which potentially can talk both to the pool (VIP) address and real servers in the pool. -Kastus
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
suse@rio.vg wrote:
You can't set multiple IP addresses to a single interface. You need to create an alias interface, lo:1, for instance.
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. /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 --
On Sat, Aug 26, 2006 at 10:50:51AM +0200, 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
Configuration looks good to me. I might try adding NETWORK_2=255.255.255.255
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.
How do you check for that? ifconfig might not show your secondary address. Try "ip addr show dev lo" Do you by any chance use 192.168.2 network on some other interface? What if you try to add it manually using this command: ip addr add 192.168.2.231/32 dev lo -Kastus
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: <LOOPBACK,UP> 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
Sun, 27 Aug 2006, by per@computer.org:
Kastus Shchuka wrote:
I'm trying to assign a virtual IP to the loopback interface 'lo': [..] 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: <LOOPBACK,UP> 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.
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)? It would then be a lot clearer that the addres belongs to LO imho, and not cause any possible confusion in the future. Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 9.2 + Jabber: muadib@jabber.xs4all.nl Kernel 2.6.8 + See headers for PGP/GPG info. Claimer: any email I receive will become my property. Disclaimers do not apply.
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
Sun, 27 Aug 2006, by per@computer.org:
Theo v. Werkhoven wrote:
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).
Ok, tnx. Theo -- Theo v. Werkhoven Registered Linux user# 99872 http://counter.li.org ICBM 52 13 26N , 4 29 47E. + ICQ: 277217131 SUSE 9.2 + Jabber: muadib@jabber.xs4all.nl Kernel 2.6.8 + See headers for PGP/GPG info. Claimer: any email I receive will become my property. Disclaimers do not apply.
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
Kastus wrote:
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.
Yes, but I can take care of that using the arp_ignore and arp_announce settings (see "sysctl -a | grep arp").
That's why you either have to put your cluster members on a routed subnet
The cluster members are all on public addresses, but I do not have great control over which subnets they're on.
or use static arp tables on the clients talking to the cluster.
Also not a possibility - I have no control over the clients. As it happens, I'll probably not be using the LVS direct route setup, but use LVS tunnelling instead. /Per Jessen, Zürich
participants (7)
-
Jan Engelhardt -
John Andersen -
Kastus -
Kastus Shchuka -
Per Jessen -
suse＠rio.vg -
Theo v. Werkhoven