Linux "ip route" changes source address of TCP but not UDP

Question

When sending packets from an application that binds to a local address TCP uses a different source address than UDP. For example, bind to 10.10.0.51 (alias IP), the src addr for UDP is 10.10.0.51 but the src addr for TCP is 10.10.0.2 (primary IP address of the machine). This is observed using tcpdump packet capture.

The output of "ip route show" includes this line: "10.10.0.0/22 dev eth1 proto kernel scope link src 10.10.0.2"

My question: why does TCP use the source address from the routing table but UDP uses the source address the application binds to?

This is on CentOS 6.

[user@host ~]$ ip route show
10.10.0.0/22 dev eth1  proto kernel  scope link  src 10.10.0.2 
10.20.0.0/22 via 10.10.0.1 dev eth1 
10.145.192.0/18 dev eth0  proto kernel  scope link  src 10.145.194.226 
169.254.0.0/16 dev eth0  scope link  metric 1002 
169.254.0.0/16 dev eth1  scope link  metric 1003 
169.254.0.0/16 dev eth2  scope link  metric 1004 
default via 10.145.255.254 dev eth0 



[user@host ~]$ uname -a
Linux machinename 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue Apr 23 19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux



[user@host ~]$ ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:50:56:01:c3:96 brd ff:ff:ff:ff:ff:ff
    inet 10.145.194.226/18 brd 10.145.255.255 scope global eth0
    inet6 fe80::250:56ff:fe01:c396/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:50:56:01:c3:97 brd ff:ff:ff:ff:ff:ff
    inet 10.10.0.2/22 brd 10.10.3.255 scope global eth1
    inet 10.10.0.51/22 scope global secondary eth1:1
    inet 10.10.0.52/22 scope global secondary eth1:2
    inet 10.10.0.53/22 scope global secondary eth1:3
    inet 10.10.0.54/22 scope global secondary eth1:4
    inet 10.10.0.55/22 scope global secondary eth1:5
    inet6 2002::10:10:0:55/96 scope global 
       valid_lft forever preferred_lft forever
    inet6 2002::10:10:0:54/96 scope global 
       valid_lft forever preferred_lft forever
    inet6 2002::10:10:0:53/96 scope global 
       valid_lft forever preferred_lft forever
    inet6 2002::10:10:0:52/96 scope global 
       valid_lft forever preferred_lft forever
    inet6 2002::10:10:0:51/96 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fe01:c397/64 scope link 
       valid_lft forever preferred_lft forever
4: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:50:56:01:c3:98 brd ff:ff:ff:ff:ff:ff
5: ip6tnl0: <NOARP> mtu 1460 qdisc noop 
    link/tunnel6 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00

EDIT: The application in question is SIPp.

sipp -sn uac -i 10.10.0.51 -t tn -p 5060 -m 1 -r 1 10.10.0.1

sipp -sn uac -i 10.10.0.51 -t un -p 5060 -m 1 -r 1 10.10.0.1

EDIT 2:

[user@host ~]$ ss -tplan | grep 5060
LISTEN     0      100              10.10.0.51:5060                     *:*      users:(("sipp",14837,3))
SYN-SENT   0      1                 10.10.0.2:50903            10.10.0.1:5060   users:(("sipp",14837,7))

[user@host ~]$ ss -uplan | grep 5060
UNCONN     0      0                10.10.0.51:5060                     *:*      users:(("sipp",14850,3))

Answer 1

I was able to confirm (to an extent) that the issue is with SIPp and not in Linux in general.

I have created a ticket with SIPp: https://sourceforge.net/p/sipp/bugs/147/

My troubleshooting was as follows:

On "server" side open netcat:

nc -v -l 10.10.0.55 5060

On "client side open netcat:

nc -v -s 10.10.0.5 10.10.0.55 5060

Output on "server" side:

Connection from 10.10.0.5 port 5060 [tcp/*] accepted

Output on "client" side:

Connection to 10.10.0.55 5060 port [tcp/sip] succeeded!

When I don't specify a specific IP on the "client" side:

nc -v 10.10.0.55 5060

Then the output on the "server" side is:

Connection from 10.10.0.4 port 5060 [tcp/*] accepted

This means that specifying a specific IP address works and it's SIPp that doesn't work that way when using the -i flag.