Re: Possible bug: Association always uses the primary source address in replies

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

 



2018-07-04 16:19 GMT+02:00 Xin Long <lucien.xin@xxxxxxxxx>:
> This is up to the src IP of your INIT packet, which INIT_ACK from server
> will use as the primary transport path to select the out route.
>
> Can you provide the interface addresses, the INIT and INIT ACK
> packet info, and the route info on the server? Thanks.

-----------------
MSrv1> ip rule show
0: from all lookup local
32764: from 195.219.193.96/27 to 178.23.31.0/24 lookup secondary
32765: from 195.219.193.64/27 to 178.23.31.0/24 lookup primary
32766: from all lookup main
32767: from all lookup default

MSrv1>ip r s t all
178.23.31.0/24 via 195.219.193.65 dev eth1 table primary
178.23.31.0/24 via 195.219.193.97 dev eth0 table secondary
default via 195.219.193.65 dev eth1 onlink
10.3.4.0/24 via 192.168.148.1 dev eth2
10.3.8.3 via 192.168.148.1 dev eth2
10.3.8.5 via 192.168.148.1 dev eth2
10.3.192.0/22 via 192.168.148.1 dev eth2
10.113.0.0/24 via 192.168.148.1 dev eth2
192.168.148.0/22 dev eth2 proto kernel scope link src 192.168.151.184
195.219.193.64/27 dev eth1 proto kernel scope link src 195.219.193.90
195.219.193.96/27 dev eth0 proto kernel scope link src 195.219.193.122
broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link
src 127.0.0.1
broadcast 192.168.148.0 dev eth2 table local proto kernel scope link
src 192.168.151.184
local 192.168.151.184 dev eth2 table local proto kernel scope host src
192.168.151.184
broadcast 192.168.151.255 dev eth2 table local proto kernel scope link
src 192.168.151.184
broadcast 195.219.193.64 dev eth1 table local proto kernel scope link
src 195.219.193.90
local 195.219.193.90 dev eth1 table local proto kernel scope host src
195.219.193.90
local 195.219.193.91 dev eth1 table local proto kernel scope host src
195.219.193.90
broadcast 195.219.193.95 dev eth1 table local proto kernel scope link
src 195.219.193.90
broadcast 195.219.193.96 dev eth0 table local proto kernel scope link
src 195.219.193.122
local 195.219.193.122 dev eth0 table local proto kernel scope host src
195.219.193.122
local 195.219.193.123 dev eth0 table local proto kernel scope host src
195.219.193.122
broadcast 195.219.193.127 dev eth0 table local proto kernel scope link
src 195.219.193.122
fe80::/64 dev eth1 proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev eth2 proto kernel metric 256 pref medium
local ::1 dev lo table local proto kernel metric 0 pref medium
local fe80::5054:ff:fe6b:271a dev eth0 table local proto kernel metric
0 pref medium
local fe80::5054:ff:fe97:127 dev eth2 table local proto kernel metric
0 pref medium
local fe80::5054:ff:fed0:4530 dev eth1 table local proto kernel metric
0 pref medium
ff00::/8 dev eth1 table local metric 256 pref medium
ff00::/8 dev eth0 table local metric 256 pref medium
ff00::/8 dev eth2 table local metric 256 pref medium
-----------------

I've attached a pcap file and a graphic of the network.

Our situation is that the gateway 195.219.193.65/27 is reachable but doesn't
forward packets (e.g. because of defect). We then try to establish a connection.
The init packets come from the client and reach the address 195.219.193.122/27,
but the server answers with one init ack from the address 195.219.193.90/27.
After that inits arrive on the server but no acks are sent.

After packet number 8 we shut down the local interface with address
195.219.193.90/27. And then the init ack is sent with the correct address
195.219.193.122/27.

It seems that if a server is bound with two addresses and for one address
all routes are down the server doesn't use the other source address.
Is this the correct behaviour?

Best
   Martin

PS: Personal note: I'm only the proxy here for Ralf who is the developer but
    whose english is not so good.

Attachment: example.pcap
Description: application/vnd.tcpdump.pcap

Attachment: network.pdf
Description: Adobe PDF document


[Index of Archives]     [Linux Networking Development]     [Linux OMAP]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux