TCP alias problem

[David A. Bandel]

On Wed, 23 Apr 2003 17:19:16 -0700
Bill Campbell <bill at celestial.com> wrote:

> On Wed, Apr 23, 2003 at 06:33:45PM -0500, David A. Bandel wrote:
> >On Wed, 23 Apr 2003 15:54:47 -0700
> >Bill Campbell <bill at celestial.com> wrote:
> >
> >> I'm having a very ``interesting'' problem with a Caldera eDesktop
> >2.4> system that's causing problems with NFS mounts from Apple iMacs
> >> running OS X.  Looking at tcpdump output I see the NFS request from
> >> the Mac going to the primary interface, eth0, on the NIC, but the
> >> response is going back from Caldera box from another interface,
> >> eth0:3.  The Mac doesn't see this as an appropriate reply since
> >it's> coming from the wrong IP address, hence the mount fails.  I
> >have> manually mounted using the IP address of eth0:3 which allows
> >the mount> to succeed, but there are other problems.
> >> 
> >> I've tried ssh to various systems on the LAN, and they also appear
> >to> originate from the eth0:3 interface.  On the other hand, I've
> >tried> ssh via an IPSec VPN tunnel to our private network here, and
> >the IP> address comes back as eth0.
> >> 
> >> Why would outgoing connections and replies appear to originate from
> >> the aliased interface instead of from eth0?
> >
> >can you provide the ip/mask?
> 
> I thought that was in the ifconfig output I attached to the original
> message.  In any case I'm attaching it again.  In any case, eth0 is
> the lowest IP address, and all the others have the same netmask.
> 
> BTW:  The reason for multiple IP addresses here is to support multiple
> djbdns servers which need to be accessible from other systems on the
> LAN and across a VPN from our customer's site to ours where both are
> doing split-horizon DNS for public and private DNS space.
> 
> >Generally, you'll see this not as an IP/interface problem, but as a
> >route problem.  The kernel picks the first route (generally the
> >smallest mask, i.e., least generic, most specific route) that gets
> >the packet to the host.  Look at your routing table.  I'll bet a
> >virtual beer the route being used is the first match in your routing
> >table (and if your masks are not identical, this will be the
> >"smallest" mask).
> 
> I've attached ``netstat -rn'' output as well (I prefer Mackeson's
> stout -- the kind sold in the U.K. not the version sold here :-).
> 
> >To solve the problem, make eth0 your smallest mask and your aliases
> >your larger masks.
> >
> >Now if your masks are the same, it goes in order from lowest network
> >number to the highest.  Solution is the same, manipulate which
> >interface gets which IP to make eth0 (not eth0:3) the first one.
> 
> Isn't that what we have here?

Nope, it's _still_ a routing problem.  In what _order_ are the
interfaces added?

For the following we need iproute2:

Please include useful output.  Output from ifconfig and route are not
useful in seeing what's going on (but it's still a routing problem --
note the _two_ 192.168.254.0 routing table entries, not five, not one,
but two - you probably have a main and local entry).  

david at tole:/home/david$ ip addr ls eth0
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:50:ba:d8:22:32 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
    inet 192.168.0.7/24 brd 192.168.0.255 scope global secondary eth0:0
    inet6 fe80::250:baff:fed8:2232/64 scope link 

also:
david at tole:/home/david$ ip route show
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.1 
206.96.93.0/24 dev eth1  proto kernel  scope link  src 206.96.93.128 
default via 206.96.93.254 dev eth1 

ip rule ls
will show you if you have any defined realms.

if not, local, then main, then default are dealt with in order.

Bear with me, we'll get to the bottom of this (but it's still a routing
problem), and mangling (or unmangling) routing is how to beat it.  No
matter how I rub the two remaining brain cells I have together, the
kernel routing table is what's cooking your goose.

(also look at /proc/net/route -- it's read-only, but we can use ip and
rtacct to manipulate the entries)

Ciao,

David A. Bandel
-- 
Focus on the dream, not the competition.
		Nemesis Racing Team motto
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.linux-sxs.org/pipermail/linux-users/attachments/20030423/32cbdc6d/attachment.pgp