might be a stupid remark, but if you want machines to talk to each other
inside the same network, you have to put them in the same network
so, if you configure:
192.168.0.1/32 and 192.168.0.2/32, then these 2 machines are on a
different network, so outgoing traffic will go via it's network with the
default route, which is your 192.168.1.x/24 network.
So... i suggest you configure the interface on lo on at least 192.168.0.30
(or maybe more clear: 24) and go with that....
What's the reason you put /32 on those lo interfaces? what will you use
them for?
kr,
Rik Bobbaers
-- http://harry.enzoverder.be
linux/unix/system/network/security/hardware admin
infrastructure architect
> I just confirmed that using dummy interfaces with a real netmask does
> actually make things work the way I want. I notice the lo /32 interface
> still gets created with the same IP. Are there any drawbacks in doing it
> this way?
>
> Gordan
>
> Gordan Bobic wrote:
>> Adrian Reyer wrote:
>>> Hi Gordon,
>>>
>>> On Thu, Oct 14, 2010 at 10:22:15PM +0100, Gordan Bobic wrote:
>>>> Is there a way to add a static route to a VM on loopback?
>>>
>>> You don't need to. As the guest has no network, it doens't need to
>>> route, either. The kernel has the network and does the routing.
>>> Do you experience any problems with this setup?
>>
>> Yes I am seeing a problem with this setup.
>>
>> Host A:
>> lo:192.168.0.1/32
>> eth0: 192.168.1.1/24
>>
>> Host B:
>> lo:192.168.0.2/32
>> eth0: 192.168.1.2/24
>>
>> When host A connects to 192.168.0.2, the connection looks like it came
>> from 192.168.1.1, rather than 192.168.0.1. I don't want my app on host B
>> binding on listening on 192.168.1.0/24 interface. I want the connection
>> to be going via the internal loopback only. I also want to keep the
>> iptables rules relatively sane and intuitive.
>>
>> Normally, this would be implicit by the network scope, but since lo is
>> different and setting 192.168.0.1/24 on it would make the local host
>> respond on the entire range, I need an alternative solution that would
>> work more sensibly. Would using a dummy network device work for this? Or
>> is there a better way?
>>
>> Gordan
>
>
Received on Fri Oct 15 14:23:29 2010