question about ip address tables in iproute2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I have managed to get ethernet connections to a single subnet working
using the iproute2 tools. However, it seems to be somewhat dependent on
the order of the addresses as they are listed by the "ip addr" command. 
Is this the way it should be, or is this a bug or oversight?

current configuration:
# ip addr
1: lo: <LOOPBACK,UP> mtu 3924 qdisc noqueue
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:30:65:a1:05:5c brd ff:ff:ff:ff:ff:ff
    inet 47.127.17.93/20 brd 47.127.31.255 scope global eth0
    inet 192.168.0.20/32 brd 192.168.0.255 scope global eth0
    inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 100
    link/ether 00:50:ba:e8:2b:e5 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.20/32 brd 192.168.0.255 scope global eth1
    inet 192.168.0.2/24 brd 192.168.0.255 scope global eth1

# ip ru li
0:      from all lookup local
199:    from 192.168.0.20 lookup masq_table
200:    from 192.168.0.1 lookup eth0_table
201:    from 192.168.0.2 lookup eth1_table
1000:   from all to 192.168.0.0/24 lookup masq_table
32766:  from all lookup main
32767:  from all lookup 253

# ip ro li table masq_table
default via 192.168.0.20 dev eth1

# ip ro li table eth0_table
default via 192.168.0.1 dev eth0

# ip ro li table eth1_table
default via 192.168.0.2 dev eth1

# ip ro li
47.127.17.93 dev eth0  scope
link                                                   192.168.0.0/24
dev eth0  proto kernel  scope link  src 192.168.0.1
192.168.0.0/24 dev eth1  proto kernel  scope link  src 192.168.0.2
127.0.0.0/8 dev lo  scope link
default via 47.127.17.93 dev eth0  scope
link                                                                               


Using this setup, anything bound directly to 0.1 or 0.2 is sent out
directly on eth0 or eth1 as appropriate.  Anything bound to 0.20 is sent
out on whichever interface is specified in the masq_table.  Anything
sent out on the 192.168.0.0 subnet is sent out on the interface
specified in masq_table, with 0.20 as its source address.  Finally,
anything coming in to 0.20 is received by either one, and is essentially
dependent on the arp tables of the other entities.  Under normal
circumstances it doesn't matter if it comes in on one and out the other,
and if one link goes down I detect it and send out an arp broadcast on
the other to update all the clients.

The main reason for doing it this way is that if a link goes down I can
fail over from one link to the other very quickly--about a millisecond
and a half--because all I have to do is update masq_table to point to
the other interface and send out some gratuitous arps.

However, it seems that iproute2 is dependent on the order of the
listings in the address table.  From my testing, the outgoing packet
being sent out on a subnet is stamped with the first address listed for
that subnet.  This doesn't seem to make sense to me.  For instance, if
the positions of the 0.20 and 0.2 addresses under eth1 are reversed,
then any default packets going onto the 192.168.0.0 subnet get stamped
with the 0.2 address as the sender.  This seems wrong to me, as they are
being sent "via 192.168.0.20".

-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com
-
: send the line "unsubscribe linux-net" in
the body of a message to majordomo@vger.kernel.org


[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux 802.1Q VLAN]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Git]     [Bugtraq]     [Yosemite News and Information]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux PCI]     [Linux Admin]     [Samba]

  Powered by Linux