OpenSolaris

Printable Version Enter a New Search
Bug ID 4173841
Synopsis Packet goes out with source IP address of another interface
State 7-Fix in Progress (Fix is in progress)
Category:Subcategory kernel:tcp-ip
Keywords clearview | refactor-potential
Responsible Engineer Sowmini Varadhan
Reported Against 5.6 , s10 , solaris_9 , solaris_10u6
Duplicate Of
Introduced In
Commit to Fix snv_135
Fixed In
Release Fixed
Related Bugs 4914097 , 6912171 , 4777670
Submit Date 15-September-1998
Last Update Date 28-January-2010
Description
A Netra I4 with two interfaces, multihomed, runnin 2.6 patched to 105786-05, sends out a packet through an interface with the IP address of another interface.

The following ndd parameters are set while start up :

================================

#8:58PM
#!/bin/sh

##########
# this is run in /etc/rc3.d
# Nettune is from instructions foun in a sun infodoc
# regarding multihome boxes  - try infodoc 15659
# some tech suggested this....
# The first argument tells what to do.
##########

state=$1

case $state in

'start')
      /sbin/ifconfig hme0 ether a:0:20:7e:8d:b3 
      /usr/sbin/ndd -set /dev/ip ip_enable_group_ifs 0
      /usr/sbin/ndd -set /dev/ip ip_forwarding 0
      /usr/sbin/ndd -set /dev/ip ip_strict_dst_multihoming 0
        ;;
'stop')
# Nothing to do here.
        ;;
esac
=========================================================
Each interface has its own mac address (the firs byte:  "08" has been replaced with "0a" for the secondary interface ,hme0, to distinguesh them). Two default routers are defined one for each network the machine is attached to.

==============
lo0: flags=849<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
        inet 127.0.0.1 netmask ffffffc0 
hme0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
        inet 199.236.165.55 netmask ffffff00 broadcast 199.236.165.255
        ether a:0:20:7e:8d:b3 
le0: flags=863<UP,BROADCAST,NOTRAILERS,RUNNING,MULTICAST> mtu 1500
        inet 199.236.166.66 netmask ffffff00 broadcast 199.236.166.255
        ether 8:0:20:7e:8d:b3 
===============
-------------------- -------------------- ----- ----- ------ ---------
199.236.166.0        199.236.166.66        U        2      0  le0
199.236.165.0        199.236.165.55        U        3     14  hme0
224.0.0.0            199.236.165.55        U        3      0  hme0
default              199.236.166.12        UG       0      0  
default              199.236.165.11        UG       0      0  
127.0.0.1            127.0.0.1             UH       0     10  lo0
=================

When the gateway is chosen for a particular destination ( may be default), the interface should be picked up according as, if it is connected to network on which the gateway exists. The source ether address and the source IP address for the datagram should be defined as the ether and the IP address associated with the interface.

From the snoops attached, it can be see that the gateway 199.236.165.11 (mac P: 8:0:20:9a:b6:4) has been chosen. So the frame should go out through the interface  hme0 ( mac a:0:20:7e:8d:b3, ip 199.236.165.55 )  with the Source mac/IP address as those of the interface (hme0).  The frame in the snoop shows that the mac address has been picked correctly (a:0:20:7e:8d:b3) but the IP address is picked up as 199.236.166.66, which corresponds to the le0.


Firewalls exist on both the gateways and when a response is provided for this packet from the destination, the packet tries to come in through the gateway on the 199.236.166.0 network (i.e 199.236.166.12). The firewall running on this gateway simply drops the packet as it does not have any tcp state history of this connection, and hence the connection never completes.  

Customer complains that the effective default router keeps switching and this cause lots of connections to be brokendown, because the packets are being sent out with wrong srouce ip address.


There are two problems here:

1) According to customer the effective defaultrouter keep flipping between the two gateways specified even though both of them are up an ok.

2) The frame goes out through one interface with source address of another interface, causing return packets to be dropped at the firewalls running on gateways.
Work Around
N/A
Comments
N/A