Virtual IP

[Igaduma]

Hi All,

- 1 server with 1 hardware hme0
- virtual ip on hme0:1
- virtual ip on hme0:2

Is it possible to have all starting-at-boottime networking applications (ssh, ...) just listening/binding to the primary hme0 and not listen per default also on hme0:1 & hme0:2 ?

Any advice welcome!
Iga

 

[Igaduma]

Hi All,

This is a no-issue, but I didn't give all info.

*.port processes listen on every ip.port available on the system, normal behaviour.
Whenever a new process is bound to a dedicated virtualip.port it will receive all packets for that unique virtualip.port and the primaryip.port process will not even get that packet.
When the virtualip.port process releases the virtualip.port again, packets for that virtualip.port will end up on *.port.

Thanks,
Iga

 

[elgrandeperro]

I think you have to configure the sshd (or other daemon) binding in the config file to ignore the wildcard. The other option would be to tcp_wrapper which would block apps that are tcp_wrapperable.

 

[Igaduma]

Hi ElGrandePerro,

never mind It's solved.
sshd was just an example for any process that listens to *.*

But thanks

 

[Annihilannic]

Igaduma,

In the caring-sharing world of tek-tips we like to let people know *how* we resolved things so that everyone can benefit... ;-)

Annihilannic.

 

[Igaduma]

The 1ste question was unclear.

This is what I meant to ask:
Would a process, listening on *.8080, prevent another process from binding to virtualip.8080, if it's a virtualip on the primary interface ?

The answer is no, anything listening on the catch-all ip's *.8080 does initially listen on all interfaces, but when a process requests to bind to virtualip.8080, the *.8080 process will stop listening on it, and the process using virtualip.8080 will get all the packets.
If virtualip.8080 process releases the port again, packets coming on the virtualip.8080 will be received by *.8080 again.

Iga

 

[Annihilannic]

My apologies, you did explain that, I just misunderstood. Useful to know!

Annihilannic.

 

[elgrandeperro]

I don't that is right.

The virt, if bound to only the specific IP, will only get packets destined for the virt. Suppose I brought up a web server on *;80. If I bring up a virt for another server, that server can only get the virt packets it doesn't magically gt *:80

It is like a routing table; it takes the inbound DEST and matches the most specific (the virt) and if that doesn't exist it matches the wildcard *).

 

[Annihilannic]

I think that's more-or-less what Iggy said, but in a different way. Basically if a virtual server is listening on 1.2.3.4:80, and another server on *:80, then the virtual server will get any traffic destined for 1.2.3.4:80, and any other traffic for other IPs on that interface will go to the *:80 server. i.e. the more specific one takes precedence.

I would have expected it to fail to start the 1.2.3.4:80 listener since *:80 was already in use, but I have never tried it.

Annihilannic.

 

[elgrandeperro]

No, I think Igaduma said that the virt gets ALL the packets; no it only gets ALL the packets bound for the VIRT. The * entry gets all the rest, and it doesn't "stop" because a virt is configured. Yes, what Igaduma is half right I guess, but
the difference is important.

Yes, you can bind to the more specific 1.2.3.4:80 with *:80 being listened by another process. I have done this with web servers, where the "default" one is listening on the wildcard and setup other apache servers listening on the virts.

 

[Igaduma]

Again, there was too much room for interpretation in what I wrote! Sorry!

Nothing as clear ... as examples!:

1.1.1.1 primary IP
2.2.2.2 virtual IP

Jboss1 is started, as-is, no port binding.
netstat -an shows *.8080 as listening aka occupied.
A packet for 1.1.1.1:8080 -OR- 2.2.2.2:8080 will both be received by Jboss1, the process listening on *.8080

On that same server Jboss2 is started, but bound to virtual ip 2.2.2.2 (./run.sh -b 2.2.2.2)
(btw: Starting Jboss2 as-is fails, as it would try to bind to *.80, clearly in use by Jboss1)
netstat -an shows a new entry 2.2.2.2.80, -AND- the *.80 entry is also still there.

A packet for 1.1.1.1:8080 will now go to Jboss1 listening on *.80, while a packet specifically addressed to 2.2.2.2:8080 will go to Jboss2.
(makes sense, netstat -an reads like a routing table)

Stop Jboss1.
Netstat now only shows 2.2.2.2.80 as listening.
A packet arriving on 1.1.1.1.80 will -NOT- be received by Jboss2 who's only listening on 2.2.2.2.80
Starting Jboss1 again, without binding, will make it listen again to *.80, while Jboss2 continues on 2.2.2.2.80.

I hope this clears up the fog-of-what-the-heck-is-he-sayin ?

Cheers!
Iga

 

[elgrandeperro]

thanks for the clarification!