SCTP Multihoming Always sending primary interface ip I

SCTP Multihoming Always sending primary interface ip I

[VARUN BHATIA]

Hi,

We have developed multihomed application now while testing my setup is:

Eth4  as primary interface connected back to back to another machine.
Eth5 as secondary interface connected back to back to another machine.

I make my porimary interface down now when the INIT is been sent it
reaches to peer machine seems using secondary interface but the source
ip address kept is of primary interface only due to which when peer
machine tries to respond INIT_ACK it tries to send on primary
interface ip which is down and due to ICMP it drops the packet.

I am not too good in Routing but it seems that some routing has not
been configuered properly, why is it always using primary ip ?

I have tested the same part when I have connected my primary &
secondary interface through router but facrd the same issue.

Any inputs are appreciated as I am stuck in it since last 2 days.


-- 
Regards,
Varun Bhatia

Re: SCTP Multihoming Always sending primary interface ip I

[Vlad Yasevich]

On 09/24/2014 08:56 AM, VARUN BHATIA wrote:
> Hi,
> 
> We have developed multihomed application now while testing my setup is:
> 
> Eth4  as primary interface connected back to back to another machine.
> Eth5 as secondary interface connected back to back to another machine.
> 
> I make my porimary interface down now when the INIT is been sent it
> reaches to peer machine seems using secondary interface but the source
> ip address kept is of primary interface only due to which when peer
> machine tries to respond INIT_ACK it tries to send on primary
> interface ip which is down and due to ICMP it drops the packet.
> 
> I am not too good in Routing but it seems that some routing has not
> been configuered properly, why is it always using primary ip ?
> 
> I have tested the same part when I have connected my primary &
> secondary interface through router but facrd the same issue.
> 
> Any inputs are appreciated as I am stuck in it since last 2 days.
> 

Try to put the 2 interfaces into 2 different subnets.  That should fix
your issue.  If you can't do that,  then you'd have to play with arp_ignore
and arp_announce sysctl values to make it do what you want.

-vlad

Re: SCTP Multihoming Always sending primary interface ip I

[Varun Bhatia]

Thanks Vlad for your response but they are already on different subnets :(

Sent from Iphone,
Varun

> On 24-Sep-2014, at 18:36, Vlad Yasevich <vyasevich@gmail.com> wrote:
> 
>> On 09/24/2014 08:56 AM, VARUN BHATIA wrote:
>> Hi,
>> 
>> We have developed multihomed application now while testing my setup is:
>> 
>> Eth4  as primary interface connected back to back to another machine.
>> Eth5 as secondary interface connected back to back to another machine.
>> 
>> I make my porimary interface down now when the INIT is been sent it
>> reaches to peer machine seems using secondary interface but the source
>> ip address kept is of primary interface only due to which when peer
>> machine tries to respond INIT_ACK it tries to send on primary
>> interface ip which is down and due to ICMP it drops the packet.
>> 
>> I am not too good in Routing but it seems that some routing has not
>> been configuered properly, why is it always using primary ip ?
>> 
>> I have tested the same part when I have connected my primary &
>> secondary interface through router but facrd the same issue.
>> 
>> Any inputs are appreciated as I am stuck in it since last 2 days.
>> 
> 
> Try to put the 2 interfaces into 2 different subnets.  That should fix
> your issue.  If you can't do that,  then you'd have to play with arp_ignore
> and arp_announce sysctl values to make it do what you want.
> 
> -vlad

Re: SCTP Multihoming Always sending primary interface ip I

[Vlad Yasevich]

On 09/24/2014 11:42 AM, Varun Bhatia wrote:
> Thanks Vlad for your response but they are already on different subnets :(

Look at your neighbor cache (ip neigh list).  If it shows the peer
on the wrong interface, then you need arg_ignore|arp_announce changes.

-vlad

> 
> Sent from Iphone,
> Varun
> 
>> On 24-Sep-2014, at 18:36, Vlad Yasevich <vyasevich@gmail.com> wrote:
>>
>>> On 09/24/2014 08:56 AM, VARUN BHATIA wrote:
>>> Hi,
>>>
>>> We have developed multihomed application now while testing my setup is:
>>>
>>> Eth4  as primary interface connected back to back to another machine.
>>> Eth5 as secondary interface connected back to back to another machine.
>>>
>>> I make my porimary interface down now when the INIT is been sent it
>>> reaches to peer machine seems using secondary interface but the source
>>> ip address kept is of primary interface only due to which when peer
>>> machine tries to respond INIT_ACK it tries to send on primary
>>> interface ip which is down and due to ICMP it drops the packet.
>>>
>>> I am not too good in Routing but it seems that some routing has not
>>> been configuered properly, why is it always using primary ip ?
>>>
>>> I have tested the same part when I have connected my primary &
>>> secondary interface through router but facrd the same issue.
>>>
>>> Any inputs are appreciated as I am stuck in it since last 2 days.
>>>
>>
>> Try to put the 2 interfaces into 2 different subnets.  That should fix
>> your issue.  If you can't do that,  then you'd have to play with arp_ignore
>> and arp_announce sysctl values to make it do what you want.
>>
>> -vlad

Re: SCTP Multihoming Always sending primary interface ip I

[VARUN BHATIA]

Hi Vlad,

This is my configuration eth2 and eth3 of 2 machines are connected
through my office network.
                 Host A                                      Host B
Primary    10.204.200.200                          10.205.200.200
Secondary 10.204.100.100                         10.205.100.100

When my both interfaces are up then:

  0.903456 10.204.200.200 -> 10.204.100.100 SCTP 100 INIT
  0.905510 10.204.100.100 -> 10.204.200.200 SCTP 356 INIT_ACK
  0.905565 10.204.200.200 -> 10.204.100.100 SCTP 312 COOKIE_ECHO
  0.907578 10.204.100.100 -> 10.204.200.200 SCTP 62 COOKIE_ACK

  3.099986 10.205.100.100 -> 10.205.200.200 SCTP 100 HEARTBEAT
  3.106487 10.204.200.200 -> 10.205.100.100 SCTP 100 HEARTBEAT_ACK
  6.889510 10.204.200.200 -> 10.204.100.100 SCTP 100 HEARTBEAT
  6.891533 10.204.100.100 -> 10.204.200.200 SCTP 100 HEARTBEAT_ACK
  9.257506 10.204.200.200 -> 10.205.100.100 SCTP 100 HEARTBEAT
  9.258420 10.204.100.100 -> 10.204.200.200 SCTP 100 HEARTBEAT_ACK
 12.248829 10.204.100.100 -> 10.204.200.200 SCTP 100 HEARTBEAT
 12.248869 10.204.200.200 -> 10.204.100.100 SCTP 100 HEARTBEAT_ACK
 57.372808 10.204.200.200 -> 10.204.100.100 SCTP 56 SHUTDOWN
 57.374730 10.204.100.100 -> 10.204.200.200 SCTP 62 SHUTDOWN_ACK
 57.374767 10.204.200.200 -> 10.204.100.100 SCTP 52 SHUTDOWN_COMPLETE


Now I make my interface down eth2 which is primary of Host A:

At A:

107.729047 10.204.200.200 -> 10.204.100.100 SCTP 100 INIT
110.740242 10.204.200.200 -> 10.205.100.100 SCTP 100 INIT
113.744168 10.204.200.200 -> 10.204.100.100 SCTP 100 INIT


At B:
 69.842169 10.204.200.200 -> 10.204.100.100 SCTP 100 INIT
 69.842234 10.204.100.100 -> 10.204.200.200 SCTP 356 INIT_ACK


It is dropping INIT ACK because the ip address on which it is sending
is down, I have made the changes recommended by you but yet the result
is same:

ip neigh list
fe80::224:13ff:fe45:ced4 dev eth3 lladdr 00:24:13:45:ce:d4 router STALE
fe80::224:13ff:fe45:ced5 dev eth0 lladdr 00:24:13:45:ce:d5 router REACHABLE
10.205.100.100 dev eth3 lladdr 00:0b:ab:55:57:01 DELAY
10.201.100.22 dev eth3 lladdr 00:24:13:45:ce:d4 DELAY
10.206.0.1 dev eth0 lladdr 00:24:13:45:ce:d5 REACHABLE


Thanks,
Varun

On Wed, Sep 24, 2014 at 10:03 PM, Vlad Yasevich <vyasevich@gmail.com> wrote:
> On 09/24/2014 11:42 AM, Varun Bhatia wrote:
>> Thanks Vlad for your response but they are already on different subnets :(
>
> Look at your neighbor cache (ip neigh list).  If it shows the peer
> on the wrong interface, then you need arg_ignore|arp_announce changes.
>
> -vlad
>
>>
>> Sent from Iphone,
>> Varun
>>
>>> On 24-Sep-2014, at 18:36, Vlad Yasevich <vyasevich@gmail.com> wrote:
>>>
>>>> On 09/24/2014 08:56 AM, VARUN BHATIA wrote:
>>>> Hi,
>>>>
>>>> We have developed multihomed application now while testing my setup is:
>>>>
>>>> Eth4  as primary interface connected back to back to another machine.
>>>> Eth5 as secondary interface connected back to back to another machine.
>>>>
>>>> I make my porimary interface down now when the INIT is been sent it
>>>> reaches to peer machine seems using secondary interface but the source
>>>> ip address kept is of primary interface only due to which when peer
>>>> machine tries to respond INIT_ACK it tries to send on primary
>>>> interface ip which is down and due to ICMP it drops the packet.
>>>>
>>>> I am not too good in Routing but it seems that some routing has not
>>>> been configuered properly, why is it always using primary ip ?
>>>>
>>>> I have tested the same part when I have connected my primary &
>>>> secondary interface through router but facrd the same issue.
>>>>
>>>> Any inputs are appreciated as I am stuck in it since last 2 days.
>>>>
>>>
>>> Try to put the 2 interfaces into 2 different subnets.  That should fix
>>> your issue.  If you can't do that,  then you'd have to play with arp_ignore
>>> and arp_announce sysctl values to make it do what you want.
>>>
>>> -vlad
>



-- 
Regards,
Varun Bhatia

Re: SCTP Multihoming Always sending primary interface ip I

[Vlad Yasevich]

On 09/24/2014 01:26 PM, VARUN BHATIA wrote:
> Hi Vlad,
> 
> This is my configuration eth2 and eth3 of 2 machines are connected
> through my office network.
>                  Host A                                      Host B
> Primary    10.204.200.200                          10.205.200.200
> Secondary 10.204.100.100                         10.205.100.100
> 

Is this a /24 netmask?

What does it say if you run
  ip route get 10.205.200.200

and
   ip route get 10.205.100.100

Also, which kernel are you using?

-vlad

> When my both interfaces are up then:
> 
>   0.903456 10.204.200.200 -> 10.204.100.100 SCTP 100 INIT
>   0.905510 10.204.100.100 -> 10.204.200.200 SCTP 356 INIT_ACK
>   0.905565 10.204.200.200 -> 10.204.100.100 SCTP 312 COOKIE_ECHO
>   0.907578 10.204.100.100 -> 10.204.200.200 SCTP 62 COOKIE_ACK
> 
>   3.099986 10.205.100.100 -> 10.205.200.200 SCTP 100 HEARTBEAT
>   3.106487 10.204.200.200 -> 10.205.100.100 SCTP 100 HEARTBEAT_ACK
>   6.889510 10.204.200.200 -> 10.204.100.100 SCTP 100 HEARTBEAT
>   6.891533 10.204.100.100 -> 10.204.200.200 SCTP 100 HEARTBEAT_ACK
>   9.257506 10.204.200.200 -> 10.205.100.100 SCTP 100 HEARTBEAT
>   9.258420 10.204.100.100 -> 10.204.200.200 SCTP 100 HEARTBEAT_ACK
>  12.248829 10.204.100.100 -> 10.204.200.200 SCTP 100 HEARTBEAT
>  12.248869 10.204.200.200 -> 10.204.100.100 SCTP 100 HEARTBEAT_ACK
>  57.372808 10.204.200.200 -> 10.204.100.100 SCTP 56 SHUTDOWN
>  57.374730 10.204.100.100 -> 10.204.200.200 SCTP 62 SHUTDOWN_ACK
>  57.374767 10.204.200.200 -> 10.204.100.100 SCTP 52 SHUTDOWN_COMPLETE
> 
> 
> Now I make my interface down eth2 which is primary of Host A:
> 
> At A:
> 
> 107.729047 10.204.200.200 -> 10.204.100.100 SCTP 100 INIT
> 110.740242 10.204.200.200 -> 10.205.100.100 SCTP 100 INIT
> 113.744168 10.204.200.200 -> 10.204.100.100 SCTP 100 INIT
> 
> 
> At B:
>  69.842169 10.204.200.200 -> 10.204.100.100 SCTP 100 INIT
>  69.842234 10.204.100.100 -> 10.204.200.200 SCTP 356 INIT_ACK
> 
> 
> It is dropping INIT ACK because the ip address on which it is sending
> is down, I have made the changes recommended by you but yet the result
> is same:
> 
> ip neigh list
> fe80::224:13ff:fe45:ced4 dev eth3 lladdr 00:24:13:45:ce:d4 router STALE
> fe80::224:13ff:fe45:ced5 dev eth0 lladdr 00:24:13:45:ce:d5 router REACHABLE
> 10.205.100.100 dev eth3 lladdr 00:0b:ab:55:57:01 DELAY
> 10.201.100.22 dev eth3 lladdr 00:24:13:45:ce:d4 DELAY
> 10.206.0.1 dev eth0 lladdr 00:24:13:45:ce:d5 REACHABLE
> 
> 
> Thanks,
> Varun
> 
> On Wed, Sep 24, 2014 at 10:03 PM, Vlad Yasevich <vyasevich@gmail.com> wrote:
>> On 09/24/2014 11:42 AM, Varun Bhatia wrote:
>>> Thanks Vlad for your response but they are already on different subnets :(
>>
>> Look at your neighbor cache (ip neigh list).  If it shows the peer
>> on the wrong interface, then you need arg_ignore|arp_announce changes.
>>
>> -vlad
>>
>>>
>>> Sent from Iphone,
>>> Varun
>>>
>>>> On 24-Sep-2014, at 18:36, Vlad Yasevich <vyasevich@gmail.com> wrote:
>>>>
>>>>> On 09/24/2014 08:56 AM, VARUN BHATIA wrote:
>>>>> Hi,
>>>>>
>>>>> We have developed multihomed application now while testing my setup is:
>>>>>
>>>>> Eth4  as primary interface connected back to back to another machine.
>>>>> Eth5 as secondary interface connected back to back to another machine.
>>>>>
>>>>> I make my porimary interface down now when the INIT is been sent it
>>>>> reaches to peer machine seems using secondary interface but the source
>>>>> ip address kept is of primary interface only due to which when peer
>>>>> machine tries to respond INIT_ACK it tries to send on primary
>>>>> interface ip which is down and due to ICMP it drops the packet.
>>>>>
>>>>> I am not too good in Routing but it seems that some routing has not
>>>>> been configuered properly, why is it always using primary ip ?
>>>>>
>>>>> I have tested the same part when I have connected my primary &
>>>>> secondary interface through router but facrd the same issue.
>>>>>
>>>>> Any inputs are appreciated as I am stuck in it since last 2 days.
>>>>>
>>>>
>>>> Try to put the 2 interfaces into 2 different subnets.  That should fix
>>>> your issue.  If you can't do that,  then you'd have to play with arp_ignore
>>>> and arp_announce sysctl values to make it do what you want.
>>>>
>>>> -vlad
>>
> 
> 
> 

Re: SCTP Multihoming Always sending primary interface ip I

[VARUN BHATIA]

The mask kept is /16, I placed wrong information correcting it:

                  Host A                                      Host B
Primary    10.204.200.200                          10.204.100.100
Secondary 10.205.200.200                         10.205.100.100

We are having our customized linux.

ip neigh list
fe80::224:13ff:fe45:ced4 dev eth3 lladdr 00:24:13:45:ce:d4 router STALE
fe80::224:13ff:fe45:ced5 dev eth0 lladdr 00:24:13:45:ce:d5 router STALE
10.205.100.100 dev eth3 lladdr 00:0b:ab:55:57:01 REACHABLE

I tried for a workaround and played with nat rules:

iptables -t nat -I POSTROUTING -o eth2 -d 10.204.100.100 -j SNAT -p
sctp --to 10.204.200.200
iptables -t nat -I POSTROUTING -o eth3 -d 10.205.100.100 -j SNAT -p
sctp --to 10.205.200.200

After this it started working though it is not the correct solution,
but yet after this it seems due to some conntrack table entries when I
receive request from peer end it is not working proparly:

  3.484280 10.205.200.200 -> 10.205.100.100 SCTP 98 INIT
  3.488652 10.205.100.100 -> 10.205.200.200 SCTP 354 INIT_ACK
  3.488706 10.205.200.200 -> 10.205.100.100 SCTP 310 COOKIE_ECHO
  3.488923 10.205.100.100 -> 10.205.200.200 SCTP 60 COOKIE_ACK

  3.497282 10.205.200.200 -> 10.205.100.100 SCTP 62 SACK

  6.512476 10.205.100.100 -> 10.205.200.200 SCTP 98 INIT
  6.512575 10.204.200.200 -> 10.205.100.100 SCTP 354 INIT_ACK

 21.240776 10.205.100.100 -> 10.205.200.200 SCTP 310 COOKIE_ECHO
 21.240866 10.204.200.200 -> 10.205.100.100 SCTP 50 COOKIE_ACK
 21.242183 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN
 21.242237 10.205.200.200 -> 10.205.100.100 SCTP 50 SHUTDOWN_ACK
 21.242353 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN_COMPLETE

When peer end sends INIT my box again send INIT_ACK using primary ip
address simlarly for COOKIE_ACK also, but SHUTDOWN ACK it is sending
correct.

Not sure what I am missing here, kindly provide your inputs on this ?

Thanks,
Varun

On Wed, Sep 24, 2014 at 11:52 PM, Vlad Yasevich <vyasevich@gmail.com> wrote:
> On 09/24/2014 01:26 PM, VARUN BHATIA wrote:
>> Hi Vlad,
>>
>> This is my configuration eth2 and eth3 of 2 machines are connected
>> through my office network.
>>                  Host A                                      Host B
>> Primary    10.204.200.200                          10.205.200.200
>> Secondary 10.204.100.100                         10.205.100.100
>>
>
> Is this a /24 netmask?
>
> What does it say if you run
>   ip route get 10.205.200.200
>
> and
>    ip route get 10.205.100.100
>
> Also, which kernel are you using?
>
> -vlad
>
>> When my both interfaces are up then:
>>
>>   0.903456 10.204.200.200 -> 10.204.100.100 SCTP 100 INIT
>>   0.905510 10.204.100.100 -> 10.204.200.200 SCTP 356 INIT_ACK
>>   0.905565 10.204.200.200 -> 10.204.100.100 SCTP 312 COOKIE_ECHO
>>   0.907578 10.204.100.100 -> 10.204.200.200 SCTP 62 COOKIE_ACK
>>
>>   3.099986 10.205.100.100 -> 10.205.200.200 SCTP 100 HEARTBEAT
>>   3.106487 10.204.200.200 -> 10.205.100.100 SCTP 100 HEARTBEAT_ACK
>>   6.889510 10.204.200.200 -> 10.204.100.100 SCTP 100 HEARTBEAT
>>   6.891533 10.204.100.100 -> 10.204.200.200 SCTP 100 HEARTBEAT_ACK
>>   9.257506 10.204.200.200 -> 10.205.100.100 SCTP 100 HEARTBEAT
>>   9.258420 10.204.100.100 -> 10.204.200.200 SCTP 100 HEARTBEAT_ACK
>>  12.248829 10.204.100.100 -> 10.204.200.200 SCTP 100 HEARTBEAT
>>  12.248869 10.204.200.200 -> 10.204.100.100 SCTP 100 HEARTBEAT_ACK
>>  57.372808 10.204.200.200 -> 10.204.100.100 SCTP 56 SHUTDOWN
>>  57.374730 10.204.100.100 -> 10.204.200.200 SCTP 62 SHUTDOWN_ACK
>>  57.374767 10.204.200.200 -> 10.204.100.100 SCTP 52 SHUTDOWN_COMPLETE
>>
>>
>> Now I make my interface down eth2 which is primary of Host A:
>>
>> At A:
>>
>> 107.729047 10.204.200.200 -> 10.204.100.100 SCTP 100 INIT
>> 110.740242 10.204.200.200 -> 10.205.100.100 SCTP 100 INIT
>> 113.744168 10.204.200.200 -> 10.204.100.100 SCTP 100 INIT
>>
>>
>> At B:
>>  69.842169 10.204.200.200 -> 10.204.100.100 SCTP 100 INIT
>>  69.842234 10.204.100.100 -> 10.204.200.200 SCTP 356 INIT_ACK
>>
>>
>> It is dropping INIT ACK because the ip address on which it is sending
>> is down, I have made the changes recommended by you but yet the result
>> is same:
>>
>> ip neigh list
>> fe80::224:13ff:fe45:ced4 dev eth3 lladdr 00:24:13:45:ce:d4 router STALE
>> fe80::224:13ff:fe45:ced5 dev eth0 lladdr 00:24:13:45:ce:d5 router REACHABLE
>> 10.205.100.100 dev eth3 lladdr 00:0b:ab:55:57:01 DELAY
>> 10.201.100.22 dev eth3 lladdr 00:24:13:45:ce:d4 DELAY
>> 10.206.0.1 dev eth0 lladdr 00:24:13:45:ce:d5 REACHABLE
>>
>>
>> Thanks,
>> Varun
>>
>> On Wed, Sep 24, 2014 at 10:03 PM, Vlad Yasevich <vyasevich@gmail.com> wrote:
>>> On 09/24/2014 11:42 AM, Varun Bhatia wrote:
>>>> Thanks Vlad for your response but they are already on different subnets :(
>>>
>>> Look at your neighbor cache (ip neigh list).  If it shows the peer
>>> on the wrong interface, then you need arg_ignore|arp_announce changes.
>>>
>>> -vlad
>>>
>>>>
>>>> Sent from Iphone,
>>>> Varun
>>>>
>>>>> On 24-Sep-2014, at 18:36, Vlad Yasevich <vyasevich@gmail.com> wrote:
>>>>>
>>>>>> On 09/24/2014 08:56 AM, VARUN BHATIA wrote:
>>>>>> Hi,
>>>>>>
>>>>>> We have developed multihomed application now while testing my setup is:
>>>>>>
>>>>>> Eth4  as primary interface connected back to back to another machine.
>>>>>> Eth5 as secondary interface connected back to back to another machine.
>>>>>>
>>>>>> I make my porimary interface down now when the INIT is been sent it
>>>>>> reaches to peer machine seems using secondary interface but the source
>>>>>> ip address kept is of primary interface only due to which when peer
>>>>>> machine tries to respond INIT_ACK it tries to send on primary
>>>>>> interface ip which is down and due to ICMP it drops the packet.
>>>>>>
>>>>>> I am not too good in Routing but it seems that some routing has not
>>>>>> been configuered properly, why is it always using primary ip ?
>>>>>>
>>>>>> I have tested the same part when I have connected my primary &
>>>>>> secondary interface through router but facrd the same issue.
>>>>>>
>>>>>> Any inputs are appreciated as I am stuck in it since last 2 days.
>>>>>>
>>>>>
>>>>> Try to put the 2 interfaces into 2 different subnets.  That should fix
>>>>> your issue.  If you can't do that,  then you'd have to play with arp_ignore
>>>>> and arp_announce sysctl values to make it do what you want.
>>>>>
>>>>> -vlad
>>>
>>
>>
>>
>



-- 
Regards,
Varun Bhatia

Re: SCTP Multihoming Always sending primary interface ip I

[Neil Horman]

On Thu, Sep 25, 2014 at 03:53:13PM +0530, VARUN BHATIA wrote:
> The mask kept is /16, I placed wrong information correcting it:
> 
>                   Host A                                      Host B
> Primary    10.204.200.200                          10.204.100.100
> Secondary 10.205.200.200                         10.205.100.100
> 
> We are having our customized linux.
> 
> ip neigh list
> fe80::224:13ff:fe45:ced4 dev eth3 lladdr 00:24:13:45:ce:d4 router STALE
> fe80::224:13ff:fe45:ced5 dev eth0 lladdr 00:24:13:45:ce:d5 router STALE
> 10.205.100.100 dev eth3 lladdr 00:0b:ab:55:57:01 REACHABLE
> 
> I tried for a workaround and played with nat rules:
> 
> iptables -t nat -I POSTROUTING -o eth2 -d 10.204.100.100 -j SNAT -p
> sctp --to 10.204.200.200
> iptables -t nat -I POSTROUTING -o eth3 -d 10.205.100.100 -j SNAT -p
> sctp --to 10.205.200.200
> 
> After this it started working though it is not the correct solution,
> but yet after this it seems due to some conntrack table entries when I
> receive request from peer end it is not working proparly:
> 
>   3.484280 10.205.200.200 -> 10.205.100.100 SCTP 98 INIT
>   3.488652 10.205.100.100 -> 10.205.200.200 SCTP 354 INIT_ACK
>   3.488706 10.205.200.200 -> 10.205.100.100 SCTP 310 COOKIE_ECHO
>   3.488923 10.205.100.100 -> 10.205.200.200 SCTP 60 COOKIE_ACK
> 
>   3.497282 10.205.200.200 -> 10.205.100.100 SCTP 62 SACK
> 
>   6.512476 10.205.100.100 -> 10.205.200.200 SCTP 98 INIT
>   6.512575 10.204.200.200 -> 10.205.100.100 SCTP 354 INIT_ACK
> 
>  21.240776 10.205.100.100 -> 10.205.200.200 SCTP 310 COOKIE_ECHO
>  21.240866 10.204.200.200 -> 10.205.100.100 SCTP 50 COOKIE_ACK
>  21.242183 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN
>  21.242237 10.205.200.200 -> 10.205.100.100 SCTP 50 SHUTDOWN_ACK
>  21.242353 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN_COMPLETE
> 
> When peer end sends INIT my box again send INIT_ACK using primary ip
> address simlarly for COOKIE_ACK also, but SHUTDOWN ACK it is sending
> correct.
> 
> Not sure what I am missing here, kindly provide your inputs on this ?
> 
> Thanks,
> Varun
> 

This is working as designed.  Since both your host addresses are on the same
subnet, and since ip addresses are owned by the system in linux, not the
interface, its not really relevant which source address is used.  If you want to
force source ip addresses to be used for the interface you are sending from,
you'll want to add higher priority routes that specify the src address.

Neil

Re: SCTP Multihoming Always sending primary interface ip I

[VARUN BHATIA]

Hi,

They both are on different subnets one is on 10.204 & other o 10.205.

Kindly let me know what route will be required for this as I am still
stuck in this issue.

Thanks,
Varun

On Thu, Sep 25, 2014 at 6:06 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> On Thu, Sep 25, 2014 at 03:53:13PM +0530, VARUN BHATIA wrote:
>> The mask kept is /16, I placed wrong information correcting it:
>>
>>                   Host A                                      Host B
>> Primary    10.204.200.200                          10.204.100.100
>> Secondary 10.205.200.200                         10.205.100.100
>>
>> We are having our customized linux.
>>
>> ip neigh list
>> fe80::224:13ff:fe45:ced4 dev eth3 lladdr 00:24:13:45:ce:d4 router STALE
>> fe80::224:13ff:fe45:ced5 dev eth0 lladdr 00:24:13:45:ce:d5 router STALE
>> 10.205.100.100 dev eth3 lladdr 00:0b:ab:55:57:01 REACHABLE
>>
>> I tried for a workaround and played with nat rules:
>>
>> iptables -t nat -I POSTROUTING -o eth2 -d 10.204.100.100 -j SNAT -p
>> sctp --to 10.204.200.200
>> iptables -t nat -I POSTROUTING -o eth3 -d 10.205.100.100 -j SNAT -p
>> sctp --to 10.205.200.200
>>
>> After this it started working though it is not the correct solution,
>> but yet after this it seems due to some conntrack table entries when I
>> receive request from peer end it is not working proparly:
>>
>>   3.484280 10.205.200.200 -> 10.205.100.100 SCTP 98 INIT
>>   3.488652 10.205.100.100 -> 10.205.200.200 SCTP 354 INIT_ACK
>>   3.488706 10.205.200.200 -> 10.205.100.100 SCTP 310 COOKIE_ECHO
>>   3.488923 10.205.100.100 -> 10.205.200.200 SCTP 60 COOKIE_ACK
>>
>>   3.497282 10.205.200.200 -> 10.205.100.100 SCTP 62 SACK
>>
>>   6.512476 10.205.100.100 -> 10.205.200.200 SCTP 98 INIT
>>   6.512575 10.204.200.200 -> 10.205.100.100 SCTP 354 INIT_ACK
>>
>>  21.240776 10.205.100.100 -> 10.205.200.200 SCTP 310 COOKIE_ECHO
>>  21.240866 10.204.200.200 -> 10.205.100.100 SCTP 50 COOKIE_ACK
>>  21.242183 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN
>>  21.242237 10.205.200.200 -> 10.205.100.100 SCTP 50 SHUTDOWN_ACK
>>  21.242353 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN_COMPLETE
>>
>> When peer end sends INIT my box again send INIT_ACK using primary ip
>> address simlarly for COOKIE_ACK also, but SHUTDOWN ACK it is sending
>> correct.
>>
>> Not sure what I am missing here, kindly provide your inputs on this ?
>>
>> Thanks,
>> Varun
>>
>
> This is working as designed.  Since both your host addresses are on the same
> subnet, and since ip addresses are owned by the system in linux, not the
> interface, its not really relevant which source address is used.  If you want to
> force source ip addresses to be used for the interface you are sending from,
> you'll want to add higher priority routes that specify the src address.
>
> Neil
>



-- 
Regards,
Varun Bhatia

Re: SCTP Multihoming Always sending primary interface ip I

[Neil Horman]

On Wed, Oct 01, 2014 at 07:28:07PM +0530, VARUN BHATIA wrote:
> Hi,
> 
> They both are on different subnets one is on 10.204 & other o 10.205.
> 
> Kindly let me know what route will be required for this as I am still
> stuck in this issue.
> 
> Thanks,
> Varun
> 
You will want to add two routes, one to each peer address exactly (i.e. a /0
address) which specifies the source address to use when sending to that host
Neil

> On Thu, Sep 25, 2014 at 6:06 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> > On Thu, Sep 25, 2014 at 03:53:13PM +0530, VARUN BHATIA wrote:
> >> The mask kept is /16, I placed wrong information correcting it:
> >>
> >>                   Host A                                      Host B
> >> Primary    10.204.200.200                          10.204.100.100
> >> Secondary 10.205.200.200                         10.205.100.100
> >>
> >> We are having our customized linux.
> >>
> >> ip neigh list
> >> fe80::224:13ff:fe45:ced4 dev eth3 lladdr 00:24:13:45:ce:d4 router STALE
> >> fe80::224:13ff:fe45:ced5 dev eth0 lladdr 00:24:13:45:ce:d5 router STALE
> >> 10.205.100.100 dev eth3 lladdr 00:0b:ab:55:57:01 REACHABLE
> >>
> >> I tried for a workaround and played with nat rules:
> >>
> >> iptables -t nat -I POSTROUTING -o eth2 -d 10.204.100.100 -j SNAT -p
> >> sctp --to 10.204.200.200
> >> iptables -t nat -I POSTROUTING -o eth3 -d 10.205.100.100 -j SNAT -p
> >> sctp --to 10.205.200.200
> >>
> >> After this it started working though it is not the correct solution,
> >> but yet after this it seems due to some conntrack table entries when I
> >> receive request from peer end it is not working proparly:
> >>
> >>   3.484280 10.205.200.200 -> 10.205.100.100 SCTP 98 INIT
> >>   3.488652 10.205.100.100 -> 10.205.200.200 SCTP 354 INIT_ACK
> >>   3.488706 10.205.200.200 -> 10.205.100.100 SCTP 310 COOKIE_ECHO
> >>   3.488923 10.205.100.100 -> 10.205.200.200 SCTP 60 COOKIE_ACK
> >>
> >>   3.497282 10.205.200.200 -> 10.205.100.100 SCTP 62 SACK
> >>
> >>   6.512476 10.205.100.100 -> 10.205.200.200 SCTP 98 INIT
> >>   6.512575 10.204.200.200 -> 10.205.100.100 SCTP 354 INIT_ACK
> >>
> >>  21.240776 10.205.100.100 -> 10.205.200.200 SCTP 310 COOKIE_ECHO
> >>  21.240866 10.204.200.200 -> 10.205.100.100 SCTP 50 COOKIE_ACK
> >>  21.242183 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN
> >>  21.242237 10.205.200.200 -> 10.205.100.100 SCTP 50 SHUTDOWN_ACK
> >>  21.242353 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN_COMPLETE
> >>
> >> When peer end sends INIT my box again send INIT_ACK using primary ip
> >> address simlarly for COOKIE_ACK also, but SHUTDOWN ACK it is sending
> >> correct.
> >>
> >> Not sure what I am missing here, kindly provide your inputs on this ?
> >>
> >> Thanks,
> >> Varun
> >>
> >
> > This is working as designed.  Since both your host addresses are on the same
> > subnet, and since ip addresses are owned by the system in linux, not the
> > interface, its not really relevant which source address is used.  If you want to
> > force source ip addresses to be used for the interface you are sending from,
> > you'll want to add higher priority routes that specify the src address.
> >
> > Neil
> >
> 
> 
> 
> -- 
> Regards,
> Varun Bhatia
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: SCTP Multihoming Always sending primary interface ip I

[Vlad Yasevich]

On 10/01/2014 09:58 AM, VARUN BHATIA wrote:
> Hi,
> 
> They both are on different subnets one is on 10.204 & other o 10.205.
> 
> Kindly let me know what route will be required for this as I am still
> stuck in this issue.
> 

If I had to guess, there is some kind of issue in nat/iptables handling....

Any change you try without iptables?

-vlad

> Thanks,
> Varun
> 
> On Thu, Sep 25, 2014 at 6:06 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> On Thu, Sep 25, 2014 at 03:53:13PM +0530, VARUN BHATIA wrote:
>>> The mask kept is /16, I placed wrong information correcting it:
>>>
>>>                   Host A                                      Host B
>>> Primary    10.204.200.200                          10.204.100.100
>>> Secondary 10.205.200.200                         10.205.100.100
>>>
>>> We are having our customized linux.
>>>
>>> ip neigh list
>>> fe80::224:13ff:fe45:ced4 dev eth3 lladdr 00:24:13:45:ce:d4 router STALE
>>> fe80::224:13ff:fe45:ced5 dev eth0 lladdr 00:24:13:45:ce:d5 router STALE
>>> 10.205.100.100 dev eth3 lladdr 00:0b:ab:55:57:01 REACHABLE
>>>
>>> I tried for a workaround and played with nat rules:
>>>
>>> iptables -t nat -I POSTROUTING -o eth2 -d 10.204.100.100 -j SNAT -p
>>> sctp --to 10.204.200.200
>>> iptables -t nat -I POSTROUTING -o eth3 -d 10.205.100.100 -j SNAT -p
>>> sctp --to 10.205.200.200
>>>
>>> After this it started working though it is not the correct solution,
>>> but yet after this it seems due to some conntrack table entries when I
>>> receive request from peer end it is not working proparly:
>>>
>>>   3.484280 10.205.200.200 -> 10.205.100.100 SCTP 98 INIT
>>>   3.488652 10.205.100.100 -> 10.205.200.200 SCTP 354 INIT_ACK
>>>   3.488706 10.205.200.200 -> 10.205.100.100 SCTP 310 COOKIE_ECHO
>>>   3.488923 10.205.100.100 -> 10.205.200.200 SCTP 60 COOKIE_ACK
>>>
>>>   3.497282 10.205.200.200 -> 10.205.100.100 SCTP 62 SACK
>>>
>>>   6.512476 10.205.100.100 -> 10.205.200.200 SCTP 98 INIT
>>>   6.512575 10.204.200.200 -> 10.205.100.100 SCTP 354 INIT_ACK
>>>
>>>  21.240776 10.205.100.100 -> 10.205.200.200 SCTP 310 COOKIE_ECHO
>>>  21.240866 10.204.200.200 -> 10.205.100.100 SCTP 50 COOKIE_ACK
>>>  21.242183 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN
>>>  21.242237 10.205.200.200 -> 10.205.100.100 SCTP 50 SHUTDOWN_ACK
>>>  21.242353 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN_COMPLETE
>>>
>>> When peer end sends INIT my box again send INIT_ACK using primary ip
>>> address simlarly for COOKIE_ACK also, but SHUTDOWN ACK it is sending
>>> correct.
>>>
>>> Not sure what I am missing here, kindly provide your inputs on this ?
>>>
>>> Thanks,
>>> Varun
>>>
>>
>> This is working as designed.  Since both your host addresses are on the same
>> subnet, and since ip addresses are owned by the system in linux, not the
>> interface, its not really relevant which source address is used.  If you want to
>> force source ip addresses to be used for the interface you are sending from,
>> you'll want to add higher priority routes that specify the src address.
>>
>> Neil
>>
> 
> 
> 

Re: SCTP Multihoming Always sending primary interface ip I

[VARUN BHATIA]

Hi Vlad,

For clearing this doubt I created a rule in raw table that it should
bypass my netfilter module but the issue is still coming:

iptables -t raw -I PREROUTING -i eth3 -j CT --notrack
iptables -t raw -I PREROUTING -i eth2 -j CT --notrack

Where eth2 is my primary interface.

Thanks,
Varun

On Fri, Oct 3, 2014 at 8:24 PM, Vlad Yasevich <vyasevich@gmail.com> wrote:
> On 10/01/2014 09:58 AM, VARUN BHATIA wrote:
>> Hi,
>>
>> They both are on different subnets one is on 10.204 & other o 10.205.
>>
>> Kindly let me know what route will be required for this as I am still
>> stuck in this issue.
>>
>
> If I had to guess, there is some kind of issue in nat/iptables handling....
>
> Any change you try without iptables?
>
> -vlad
>
>> Thanks,
>> Varun
>>
>> On Thu, Sep 25, 2014 at 6:06 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>>> On Thu, Sep 25, 2014 at 03:53:13PM +0530, VARUN BHATIA wrote:
>>>> The mask kept is /16, I placed wrong information correcting it:
>>>>
>>>>                   Host A                                      Host B
>>>> Primary    10.204.200.200                          10.204.100.100
>>>> Secondary 10.205.200.200                         10.205.100.100
>>>>
>>>> We are having our customized linux.
>>>>
>>>> ip neigh list
>>>> fe80::224:13ff:fe45:ced4 dev eth3 lladdr 00:24:13:45:ce:d4 router STALE
>>>> fe80::224:13ff:fe45:ced5 dev eth0 lladdr 00:24:13:45:ce:d5 router STALE
>>>> 10.205.100.100 dev eth3 lladdr 00:0b:ab:55:57:01 REACHABLE
>>>>
>>>> I tried for a workaround and played with nat rules:
>>>>
>>>> iptables -t nat -I POSTROUTING -o eth2 -d 10.204.100.100 -j SNAT -p
>>>> sctp --to 10.204.200.200
>>>> iptables -t nat -I POSTROUTING -o eth3 -d 10.205.100.100 -j SNAT -p
>>>> sctp --to 10.205.200.200
>>>>
>>>> After this it started working though it is not the correct solution,
>>>> but yet after this it seems due to some conntrack table entries when I
>>>> receive request from peer end it is not working proparly:
>>>>
>>>>   3.484280 10.205.200.200 -> 10.205.100.100 SCTP 98 INIT
>>>>   3.488652 10.205.100.100 -> 10.205.200.200 SCTP 354 INIT_ACK
>>>>   3.488706 10.205.200.200 -> 10.205.100.100 SCTP 310 COOKIE_ECHO
>>>>   3.488923 10.205.100.100 -> 10.205.200.200 SCTP 60 COOKIE_ACK
>>>>
>>>>   3.497282 10.205.200.200 -> 10.205.100.100 SCTP 62 SACK
>>>>
>>>>   6.512476 10.205.100.100 -> 10.205.200.200 SCTP 98 INIT
>>>>   6.512575 10.204.200.200 -> 10.205.100.100 SCTP 354 INIT_ACK
>>>>
>>>>  21.240776 10.205.100.100 -> 10.205.200.200 SCTP 310 COOKIE_ECHO
>>>>  21.240866 10.204.200.200 -> 10.205.100.100 SCTP 50 COOKIE_ACK
>>>>  21.242183 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN
>>>>  21.242237 10.205.200.200 -> 10.205.100.100 SCTP 50 SHUTDOWN_ACK
>>>>  21.242353 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN_COMPLETE
>>>>
>>>> When peer end sends INIT my box again send INIT_ACK using primary ip
>>>> address simlarly for COOKIE_ACK also, but SHUTDOWN ACK it is sending
>>>> correct.
>>>>
>>>> Not sure what I am missing here, kindly provide your inputs on this ?
>>>>
>>>> Thanks,
>>>> Varun
>>>>
>>>
>>> This is working as designed.  Since both your host addresses are on the same
>>> subnet, and since ip addresses are owned by the system in linux, not the
>>> interface, its not really relevant which source address is used.  If you want to
>>> force source ip addresses to be used for the interface you are sending from,
>>> you'll want to add higher priority routes that specify the src address.
>>>
>>> Neil
>>>
>>
>>
>>
>



-- 
Regards,
Varun Bhatia

Re: SCTP Multihoming Always sending primary interface ip I

[VARUN BHATIA]

Hi,

I have made some changes in routing and it seems started working but
having some doubts in that:

ip route add 10.204.200.200 dev eth2 src 10.204.100.100

ip route add 10.205.200.200 dev eth3 src 10.205.100.100

1. My all the ips are plumbed interfaces so whether it is required to
provide precise dev such as eth2:3 or eth3:2 ?

2. After adding this routing I am expecting symmetric routing that is
primary<->primary & secondary<->secondary, but my peer supports
assymetric also such as it secondary sends packet to my primary too,
how should that part be handled ?

Thanks,
Varun

On Tue, Oct 7, 2014 at 1:02 PM, VARUN BHATIA <varuninbharti@gmail.com> wrote:
> Hi Vlad,
>
> For clearing this doubt I created a rule in raw table that it should
> bypass my netfilter module but the issue is still coming:
>
> iptables -t raw -I PREROUTING -i eth3 -j CT --notrack
> iptables -t raw -I PREROUTING -i eth2 -j CT --notrack
>
> Where eth2 is my primary interface.
>
> Thanks,
> Varun
>
> On Fri, Oct 3, 2014 at 8:24 PM, Vlad Yasevich <vyasevich@gmail.com> wrote:
>> On 10/01/2014 09:58 AM, VARUN BHATIA wrote:
>>> Hi,
>>>
>>> They both are on different subnets one is on 10.204 & other o 10.205.
>>>
>>> Kindly let me know what route will be required for this as I am still
>>> stuck in this issue.
>>>
>>
>> If I had to guess, there is some kind of issue in nat/iptables handling....
>>
>> Any change you try without iptables?
>>
>> -vlad
>>
>>> Thanks,
>>> Varun
>>>
>>> On Thu, Sep 25, 2014 at 6:06 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>>>> On Thu, Sep 25, 2014 at 03:53:13PM +0530, VARUN BHATIA wrote:
>>>>> The mask kept is /16, I placed wrong information correcting it:
>>>>>
>>>>>                   Host A                                      Host B
>>>>> Primary    10.204.200.200                          10.204.100.100
>>>>> Secondary 10.205.200.200                         10.205.100.100
>>>>>
>>>>> We are having our customized linux.
>>>>>
>>>>> ip neigh list
>>>>> fe80::224:13ff:fe45:ced4 dev eth3 lladdr 00:24:13:45:ce:d4 router STALE
>>>>> fe80::224:13ff:fe45:ced5 dev eth0 lladdr 00:24:13:45:ce:d5 router STALE
>>>>> 10.205.100.100 dev eth3 lladdr 00:0b:ab:55:57:01 REACHABLE
>>>>>
>>>>> I tried for a workaround and played with nat rules:
>>>>>
>>>>> iptables -t nat -I POSTROUTING -o eth2 -d 10.204.100.100 -j SNAT -p
>>>>> sctp --to 10.204.200.200
>>>>> iptables -t nat -I POSTROUTING -o eth3 -d 10.205.100.100 -j SNAT -p
>>>>> sctp --to 10.205.200.200
>>>>>
>>>>> After this it started working though it is not the correct solution,
>>>>> but yet after this it seems due to some conntrack table entries when I
>>>>> receive request from peer end it is not working proparly:
>>>>>
>>>>>   3.484280 10.205.200.200 -> 10.205.100.100 SCTP 98 INIT
>>>>>   3.488652 10.205.100.100 -> 10.205.200.200 SCTP 354 INIT_ACK
>>>>>   3.488706 10.205.200.200 -> 10.205.100.100 SCTP 310 COOKIE_ECHO
>>>>>   3.488923 10.205.100.100 -> 10.205.200.200 SCTP 60 COOKIE_ACK
>>>>>
>>>>>   3.497282 10.205.200.200 -> 10.205.100.100 SCTP 62 SACK
>>>>>
>>>>>   6.512476 10.205.100.100 -> 10.205.200.200 SCTP 98 INIT
>>>>>   6.512575 10.204.200.200 -> 10.205.100.100 SCTP 354 INIT_ACK
>>>>>
>>>>>  21.240776 10.205.100.100 -> 10.205.200.200 SCTP 310 COOKIE_ECHO
>>>>>  21.240866 10.204.200.200 -> 10.205.100.100 SCTP 50 COOKIE_ACK
>>>>>  21.242183 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN
>>>>>  21.242237 10.205.200.200 -> 10.205.100.100 SCTP 50 SHUTDOWN_ACK
>>>>>  21.242353 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN_COMPLETE
>>>>>
>>>>> When peer end sends INIT my box again send INIT_ACK using primary ip
>>>>> address simlarly for COOKIE_ACK also, but SHUTDOWN ACK it is sending
>>>>> correct.
>>>>>
>>>>> Not sure what I am missing here, kindly provide your inputs on this ?
>>>>>
>>>>> Thanks,
>>>>> Varun
>>>>>
>>>>
>>>> This is working as designed.  Since both your host addresses are on the same
>>>> subnet, and since ip addresses are owned by the system in linux, not the
>>>> interface, its not really relevant which source address is used.  If you want to
>>>> force source ip addresses to be used for the interface you are sending from,
>>>> you'll want to add higher priority routes that specify the src address.
>>>>
>>>> Neil
>>>>
>>>
>>>
>>>
>>
>
>
>
> --
> Regards,
> Varun Bhatia



-- 
Regards,
Varun Bhatia

Re: SCTP Multihoming Always sending primary interface ip I

[Neil Horman]

On Wed, Oct 08, 2014 at 12:37:04PM +0530, VARUN BHATIA wrote:
> Hi,
> 
> I have made some changes in routing and it seems started working but
> having some doubts in that:
> 
> ip route add 10.204.200.200 dev eth2 src 10.204.100.100
> 
> ip route add 10.205.200.200 dev eth3 src 10.205.100.100
> 
> 1. My all the ips are plumbed interfaces so whether it is required to
> provide precise dev such as eth2:3 or eth3:2 ?
> 
I don't think so, no.

> 2. After adding this routing I am expecting symmetric routing that is
> primary<->primary & secondary<->secondary, but my peer supports
> assymetric also such as it secondary sends packet to my primary too,
> how should that part be handled ?
> 
Under what conditions do you want assymetric routing to occur?

Neil

> Thanks,
> Varun
> 
> On Tue, Oct 7, 2014 at 1:02 PM, VARUN BHATIA <varuninbharti@gmail.com> wrote:
> > Hi Vlad,
> >
> > For clearing this doubt I created a rule in raw table that it should
> > bypass my netfilter module but the issue is still coming:
> >
> > iptables -t raw -I PREROUTING -i eth3 -j CT --notrack
> > iptables -t raw -I PREROUTING -i eth2 -j CT --notrack
> >
> > Where eth2 is my primary interface.
> >
> > Thanks,
> > Varun
> >
> > On Fri, Oct 3, 2014 at 8:24 PM, Vlad Yasevich <vyasevich@gmail.com> wrote:
> >> On 10/01/2014 09:58 AM, VARUN BHATIA wrote:
> >>> Hi,
> >>>
> >>> They both are on different subnets one is on 10.204 & other o 10.205.
> >>>
> >>> Kindly let me know what route will be required for this as I am still
> >>> stuck in this issue.
> >>>
> >>
> >> If I had to guess, there is some kind of issue in nat/iptables handling....
> >>
> >> Any change you try without iptables?
> >>
> >> -vlad
> >>
> >>> Thanks,
> >>> Varun
> >>>
> >>> On Thu, Sep 25, 2014 at 6:06 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> >>>> On Thu, Sep 25, 2014 at 03:53:13PM +0530, VARUN BHATIA wrote:
> >>>>> The mask kept is /16, I placed wrong information correcting it:
> >>>>>
> >>>>>                   Host A                                      Host B
> >>>>> Primary    10.204.200.200                          10.204.100.100
> >>>>> Secondary 10.205.200.200                         10.205.100.100
> >>>>>
> >>>>> We are having our customized linux.
> >>>>>
> >>>>> ip neigh list
> >>>>> fe80::224:13ff:fe45:ced4 dev eth3 lladdr 00:24:13:45:ce:d4 router STALE
> >>>>> fe80::224:13ff:fe45:ced5 dev eth0 lladdr 00:24:13:45:ce:d5 router STALE
> >>>>> 10.205.100.100 dev eth3 lladdr 00:0b:ab:55:57:01 REACHABLE
> >>>>>
> >>>>> I tried for a workaround and played with nat rules:
> >>>>>
> >>>>> iptables -t nat -I POSTROUTING -o eth2 -d 10.204.100.100 -j SNAT -p
> >>>>> sctp --to 10.204.200.200
> >>>>> iptables -t nat -I POSTROUTING -o eth3 -d 10.205.100.100 -j SNAT -p
> >>>>> sctp --to 10.205.200.200
> >>>>>
> >>>>> After this it started working though it is not the correct solution,
> >>>>> but yet after this it seems due to some conntrack table entries when I
> >>>>> receive request from peer end it is not working proparly:
> >>>>>
> >>>>>   3.484280 10.205.200.200 -> 10.205.100.100 SCTP 98 INIT
> >>>>>   3.488652 10.205.100.100 -> 10.205.200.200 SCTP 354 INIT_ACK
> >>>>>   3.488706 10.205.200.200 -> 10.205.100.100 SCTP 310 COOKIE_ECHO
> >>>>>   3.488923 10.205.100.100 -> 10.205.200.200 SCTP 60 COOKIE_ACK
> >>>>>
> >>>>>   3.497282 10.205.200.200 -> 10.205.100.100 SCTP 62 SACK
> >>>>>
> >>>>>   6.512476 10.205.100.100 -> 10.205.200.200 SCTP 98 INIT
> >>>>>   6.512575 10.204.200.200 -> 10.205.100.100 SCTP 354 INIT_ACK
> >>>>>
> >>>>>  21.240776 10.205.100.100 -> 10.205.200.200 SCTP 310 COOKIE_ECHO
> >>>>>  21.240866 10.204.200.200 -> 10.205.100.100 SCTP 50 COOKIE_ACK
> >>>>>  21.242183 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN
> >>>>>  21.242237 10.205.200.200 -> 10.205.100.100 SCTP 50 SHUTDOWN_ACK
> >>>>>  21.242353 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN_COMPLETE
> >>>>>
> >>>>> When peer end sends INIT my box again send INIT_ACK using primary ip
> >>>>> address simlarly for COOKIE_ACK also, but SHUTDOWN ACK it is sending
> >>>>> correct.
> >>>>>
> >>>>> Not sure what I am missing here, kindly provide your inputs on this ?
> >>>>>
> >>>>> Thanks,
> >>>>> Varun
> >>>>>
> >>>>
> >>>> This is working as designed.  Since both your host addresses are on the same
> >>>> subnet, and since ip addresses are owned by the system in linux, not the
> >>>> interface, its not really relevant which source address is used.  If you want to
> >>>> force source ip addresses to be used for the interface you are sending from,
> >>>> you'll want to add higher priority routes that specify the src address.
> >>>>
> >>>> Neil
> >>>>
> >>>
> >>>
> >>>
> >>
> >
> >
> >
> > --
> > Regards,
> > Varun Bhatia
> 
> 
> 
> -- 
> Regards,
> Varun Bhatia
> 

Re: SCTP Multihoming Always sending primary interface ip I

[VARUN BHATIA]

Hi Neil,

The expectation is to support full mesh sctp association which is
capability to establish crossed paths inside SCTP association in
addition to direct paths between SCTP peers (IP addresses).

Not sure whether this can be done through routing or making changes in SCTP ?

Thanks,
Varun



On Wed, Oct 8, 2014 at 6:47 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> On Wed, Oct 08, 2014 at 12:37:04PM +0530, VARUN BHATIA wrote:
>> Hi,
>>
>> I have made some changes in routing and it seems started working but
>> having some doubts in that:
>>
>> ip route add 10.204.200.200 dev eth2 src 10.204.100.100
>>
>> ip route add 10.205.200.200 dev eth3 src 10.205.100.100
>>
>> 1. My all the ips are plumbed interfaces so whether it is required to
>> provide precise dev such as eth2:3 or eth3:2 ?
>>
> I don't think so, no.
>
>> 2. After adding this routing I am expecting symmetric routing that is
>> primary<->primary & secondary<->secondary, but my peer supports
>> assymetric also such as it secondary sends packet to my primary too,
>> how should that part be handled ?
>>
> Under what conditions do you want assymetric routing to occur?
>
> Neil
>
>> Thanks,
>> Varun
>>
>> On Tue, Oct 7, 2014 at 1:02 PM, VARUN BHATIA <varuninbharti@gmail.com> wrote:
>> > Hi Vlad,
>> >
>> > For clearing this doubt I created a rule in raw table that it should
>> > bypass my netfilter module but the issue is still coming:
>> >
>> > iptables -t raw -I PREROUTING -i eth3 -j CT --notrack
>> > iptables -t raw -I PREROUTING -i eth2 -j CT --notrack
>> >
>> > Where eth2 is my primary interface.
>> >
>> > Thanks,
>> > Varun
>> >
>> > On Fri, Oct 3, 2014 at 8:24 PM, Vlad Yasevich <vyasevich@gmail.com> wrote:
>> >> On 10/01/2014 09:58 AM, VARUN BHATIA wrote:
>> >>> Hi,
>> >>>
>> >>> They both are on different subnets one is on 10.204 & other o 10.205.
>> >>>
>> >>> Kindly let me know what route will be required for this as I am still
>> >>> stuck in this issue.
>> >>>
>> >>
>> >> If I had to guess, there is some kind of issue in nat/iptables handling....
>> >>
>> >> Any change you try without iptables?
>> >>
>> >> -vlad
>> >>
>> >>> Thanks,
>> >>> Varun
>> >>>
>> >>> On Thu, Sep 25, 2014 at 6:06 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> >>>> On Thu, Sep 25, 2014 at 03:53:13PM +0530, VARUN BHATIA wrote:
>> >>>>> The mask kept is /16, I placed wrong information correcting it:
>> >>>>>
>> >>>>>                   Host A                                      Host B
>> >>>>> Primary    10.204.200.200                          10.204.100.100
>> >>>>> Secondary 10.205.200.200                         10.205.100.100
>> >>>>>
>> >>>>> We are having our customized linux.
>> >>>>>
>> >>>>> ip neigh list
>> >>>>> fe80::224:13ff:fe45:ced4 dev eth3 lladdr 00:24:13:45:ce:d4 router STALE
>> >>>>> fe80::224:13ff:fe45:ced5 dev eth0 lladdr 00:24:13:45:ce:d5 router STALE
>> >>>>> 10.205.100.100 dev eth3 lladdr 00:0b:ab:55:57:01 REACHABLE
>> >>>>>
>> >>>>> I tried for a workaround and played with nat rules:
>> >>>>>
>> >>>>> iptables -t nat -I POSTROUTING -o eth2 -d 10.204.100.100 -j SNAT -p
>> >>>>> sctp --to 10.204.200.200
>> >>>>> iptables -t nat -I POSTROUTING -o eth3 -d 10.205.100.100 -j SNAT -p
>> >>>>> sctp --to 10.205.200.200
>> >>>>>
>> >>>>> After this it started working though it is not the correct solution,
>> >>>>> but yet after this it seems due to some conntrack table entries when I
>> >>>>> receive request from peer end it is not working proparly:
>> >>>>>
>> >>>>>   3.484280 10.205.200.200 -> 10.205.100.100 SCTP 98 INIT
>> >>>>>   3.488652 10.205.100.100 -> 10.205.200.200 SCTP 354 INIT_ACK
>> >>>>>   3.488706 10.205.200.200 -> 10.205.100.100 SCTP 310 COOKIE_ECHO
>> >>>>>   3.488923 10.205.100.100 -> 10.205.200.200 SCTP 60 COOKIE_ACK
>> >>>>>
>> >>>>>   3.497282 10.205.200.200 -> 10.205.100.100 SCTP 62 SACK
>> >>>>>
>> >>>>>   6.512476 10.205.100.100 -> 10.205.200.200 SCTP 98 INIT
>> >>>>>   6.512575 10.204.200.200 -> 10.205.100.100 SCTP 354 INIT_ACK
>> >>>>>
>> >>>>>  21.240776 10.205.100.100 -> 10.205.200.200 SCTP 310 COOKIE_ECHO
>> >>>>>  21.240866 10.204.200.200 -> 10.205.100.100 SCTP 50 COOKIE_ACK
>> >>>>>  21.242183 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN
>> >>>>>  21.242237 10.205.200.200 -> 10.205.100.100 SCTP 50 SHUTDOWN_ACK
>> >>>>>  21.242353 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN_COMPLETE
>> >>>>>
>> >>>>> When peer end sends INIT my box again send INIT_ACK using primary ip
>> >>>>> address simlarly for COOKIE_ACK also, but SHUTDOWN ACK it is sending
>> >>>>> correct.
>> >>>>>
>> >>>>> Not sure what I am missing here, kindly provide your inputs on this ?
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Varun
>> >>>>>
>> >>>>
>> >>>> This is working as designed.  Since both your host addresses are on the same
>> >>>> subnet, and since ip addresses are owned by the system in linux, not the
>> >>>> interface, its not really relevant which source address is used.  If you want to
>> >>>> force source ip addresses to be used for the interface you are sending from,
>> >>>> you'll want to add higher priority routes that specify the src address.
>> >>>>
>> >>>> Neil
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Varun Bhatia
>>
>>
>>
>> --
>> Regards,
>> Varun Bhatia
>>



-- 
Regards,
Varun Bhatia

Re: SCTP Multihoming Always sending primary interface ip I

[Vladislav Yasevich]

On Mon, Oct 13, 2014 at 9:26 AM, VARUN BHATIA <varuninbharti@gmail.com> wrote:
> Hi Neil,
>
> The expectation is to support full mesh sctp association which is
> capability to establish crossed paths inside SCTP association in
> addition to direct paths between SCTP peers (IP addresses).
>
> Not sure whether this can be done through routing or making changes in SCTP ?

Now I understand what you are trying to do.  No, full mesh isn't supported.
A path is determined per-destination, not per source+destination.

-vlad

>
> Thanks,
> Varun
>
>
>
> On Wed, Oct 8, 2014 at 6:47 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>> On Wed, Oct 08, 2014 at 12:37:04PM +0530, VARUN BHATIA wrote:
>>> Hi,
>>>
>>> I have made some changes in routing and it seems started working but
>>> having some doubts in that:
>>>
>>> ip route add 10.204.200.200 dev eth2 src 10.204.100.100
>>>
>>> ip route add 10.205.200.200 dev eth3 src 10.205.100.100
>>>
>>> 1. My all the ips are plumbed interfaces so whether it is required to
>>> provide precise dev such as eth2:3 or eth3:2 ?
>>>
>> I don't think so, no.
>>
>>> 2. After adding this routing I am expecting symmetric routing that is
>>> primary<->primary & secondary<->secondary, but my peer supports
>>> assymetric also such as it secondary sends packet to my primary too,
>>> how should that part be handled ?
>>>
>> Under what conditions do you want assymetric routing to occur?
>>
>> Neil
>>
>>> Thanks,
>>> Varun
>>>
>>> On Tue, Oct 7, 2014 at 1:02 PM, VARUN BHATIA <varuninbharti@gmail.com> wrote:
>>> > Hi Vlad,
>>> >
>>> > For clearing this doubt I created a rule in raw table that it should
>>> > bypass my netfilter module but the issue is still coming:
>>> >
>>> > iptables -t raw -I PREROUTING -i eth3 -j CT --notrack
>>> > iptables -t raw -I PREROUTING -i eth2 -j CT --notrack
>>> >
>>> > Where eth2 is my primary interface.
>>> >
>>> > Thanks,
>>> > Varun
>>> >
>>> > On Fri, Oct 3, 2014 at 8:24 PM, Vlad Yasevich <vyasevich@gmail.com> wrote:
>>> >> On 10/01/2014 09:58 AM, VARUN BHATIA wrote:
>>> >>> Hi,
>>> >>>
>>> >>> They both are on different subnets one is on 10.204 & other o 10.205.
>>> >>>
>>> >>> Kindly let me know what route will be required for this as I am still
>>> >>> stuck in this issue.
>>> >>>
>>> >>
>>> >> If I had to guess, there is some kind of issue in nat/iptables handling....
>>> >>
>>> >> Any change you try without iptables?
>>> >>
>>> >> -vlad
>>> >>
>>> >>> Thanks,
>>> >>> Varun
>>> >>>
>>> >>> On Thu, Sep 25, 2014 at 6:06 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>>> >>>> On Thu, Sep 25, 2014 at 03:53:13PM +0530, VARUN BHATIA wrote:
>>> >>>>> The mask kept is /16, I placed wrong information correcting it:
>>> >>>>>
>>> >>>>>                   Host A                                      Host B
>>> >>>>> Primary    10.204.200.200                          10.204.100.100
>>> >>>>> Secondary 10.205.200.200                         10.205.100.100
>>> >>>>>
>>> >>>>> We are having our customized linux.
>>> >>>>>
>>> >>>>> ip neigh list
>>> >>>>> fe80::224:13ff:fe45:ced4 dev eth3 lladdr 00:24:13:45:ce:d4 router STALE
>>> >>>>> fe80::224:13ff:fe45:ced5 dev eth0 lladdr 00:24:13:45:ce:d5 router STALE
>>> >>>>> 10.205.100.100 dev eth3 lladdr 00:0b:ab:55:57:01 REACHABLE
>>> >>>>>
>>> >>>>> I tried for a workaround and played with nat rules:
>>> >>>>>
>>> >>>>> iptables -t nat -I POSTROUTING -o eth2 -d 10.204.100.100 -j SNAT -p
>>> >>>>> sctp --to 10.204.200.200
>>> >>>>> iptables -t nat -I POSTROUTING -o eth3 -d 10.205.100.100 -j SNAT -p
>>> >>>>> sctp --to 10.205.200.200
>>> >>>>>
>>> >>>>> After this it started working though it is not the correct solution,
>>> >>>>> but yet after this it seems due to some conntrack table entries when I
>>> >>>>> receive request from peer end it is not working proparly:
>>> >>>>>
>>> >>>>>   3.484280 10.205.200.200 -> 10.205.100.100 SCTP 98 INIT
>>> >>>>>   3.488652 10.205.100.100 -> 10.205.200.200 SCTP 354 INIT_ACK
>>> >>>>>   3.488706 10.205.200.200 -> 10.205.100.100 SCTP 310 COOKIE_ECHO
>>> >>>>>   3.488923 10.205.100.100 -> 10.205.200.200 SCTP 60 COOKIE_ACK
>>> >>>>>
>>> >>>>>   3.497282 10.205.200.200 -> 10.205.100.100 SCTP 62 SACK
>>> >>>>>
>>> >>>>>   6.512476 10.205.100.100 -> 10.205.200.200 SCTP 98 INIT
>>> >>>>>   6.512575 10.204.200.200 -> 10.205.100.100 SCTP 354 INIT_ACK
>>> >>>>>
>>> >>>>>  21.240776 10.205.100.100 -> 10.205.200.200 SCTP 310 COOKIE_ECHO
>>> >>>>>  21.240866 10.204.200.200 -> 10.205.100.100 SCTP 50 COOKIE_ACK
>>> >>>>>  21.242183 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN
>>> >>>>>  21.242237 10.205.200.200 -> 10.205.100.100 SCTP 50 SHUTDOWN_ACK
>>> >>>>>  21.242353 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN_COMPLETE
>>> >>>>>
>>> >>>>> When peer end sends INIT my box again send INIT_ACK using primary ip
>>> >>>>> address simlarly for COOKIE_ACK also, but SHUTDOWN ACK it is sending
>>> >>>>> correct.
>>> >>>>>
>>> >>>>> Not sure what I am missing here, kindly provide your inputs on this ?
>>> >>>>>
>>> >>>>> Thanks,
>>> >>>>> Varun
>>> >>>>>
>>> >>>>
>>> >>>> This is working as designed.  Since both your host addresses are on the same
>>> >>>> subnet, and since ip addresses are owned by the system in linux, not the
>>> >>>> interface, its not really relevant which source address is used.  If you want to
>>> >>>> force source ip addresses to be used for the interface you are sending from,
>>> >>>> you'll want to add higher priority routes that specify the src address.
>>> >>>>
>>> >>>> Neil
>>> >>>>
>>> >>>
>>> >>>
>>> >>>
>>> >>
>>> >
>>> >
>>> >
>>> > --
>>> > Regards,
>>> > Varun Bhatia
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Varun Bhatia
>>>
>
>
>
> --
> Regards,
> Varun Bhatia

Re: SCTP Multihoming Always sending primary interface ip I

[VARUN BHATIA]

Thanks to all of you for your support, first I was trying to make one
to one working only  and got the understanding that it was not working
because it was not able to select proper route as there were default
routes been also created with netmask 16 and it was been selected.
When I created a unique netmask with 24 it started working.

I have analyzed that for SCTP route is required in main routing table
not in user defined routing table, are you aware why is it so ?

Another part the requirement has come to us for full mesh support
because there switch supports full mesh kindly let me know any rfc or
standard which mention specifically this ?
Not sure how to move forward on this.

Thanks,
Varun

On Tue, Oct 14, 2014 at 2:38 PM, Vladislav Yasevich <vyasevich@gmail.com> wrote:
> On Mon, Oct 13, 2014 at 9:26 AM, VARUN BHATIA <varuninbharti@gmail.com> wrote:
>> Hi Neil,
>>
>> The expectation is to support full mesh sctp association which is
>> capability to establish crossed paths inside SCTP association in
>> addition to direct paths between SCTP peers (IP addresses).
>>
>> Not sure whether this can be done through routing or making changes in SCTP ?
>
> Now I understand what you are trying to do.  No, full mesh isn't supported.
> A path is determined per-destination, not per source+destination.
>
> -vlad
>
>>
>> Thanks,
>> Varun
>>
>>
>>
>> On Wed, Oct 8, 2014 at 6:47 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>>> On Wed, Oct 08, 2014 at 12:37:04PM +0530, VARUN BHATIA wrote:
>>>> Hi,
>>>>
>>>> I have made some changes in routing and it seems started working but
>>>> having some doubts in that:
>>>>
>>>> ip route add 10.204.200.200 dev eth2 src 10.204.100.100
>>>>
>>>> ip route add 10.205.200.200 dev eth3 src 10.205.100.100
>>>>
>>>> 1. My all the ips are plumbed interfaces so whether it is required to
>>>> provide precise dev such as eth2:3 or eth3:2 ?
>>>>
>>> I don't think so, no.
>>>
>>>> 2. After adding this routing I am expecting symmetric routing that is
>>>> primary<->primary & secondary<->secondary, but my peer supports
>>>> assymetric also such as it secondary sends packet to my primary too,
>>>> how should that part be handled ?
>>>>
>>> Under what conditions do you want assymetric routing to occur?
>>>
>>> Neil
>>>
>>>> Thanks,
>>>> Varun
>>>>
>>>> On Tue, Oct 7, 2014 at 1:02 PM, VARUN BHATIA <varuninbharti@gmail.com> wrote:
>>>> > Hi Vlad,
>>>> >
>>>> > For clearing this doubt I created a rule in raw table that it should
>>>> > bypass my netfilter module but the issue is still coming:
>>>> >
>>>> > iptables -t raw -I PREROUTING -i eth3 -j CT --notrack
>>>> > iptables -t raw -I PREROUTING -i eth2 -j CT --notrack
>>>> >
>>>> > Where eth2 is my primary interface.
>>>> >
>>>> > Thanks,
>>>> > Varun
>>>> >
>>>> > On Fri, Oct 3, 2014 at 8:24 PM, Vlad Yasevich <vyasevich@gmail.com> wrote:
>>>> >> On 10/01/2014 09:58 AM, VARUN BHATIA wrote:
>>>> >>> Hi,
>>>> >>>
>>>> >>> They both are on different subnets one is on 10.204 & other o 10.205.
>>>> >>>
>>>> >>> Kindly let me know what route will be required for this as I am still
>>>> >>> stuck in this issue.
>>>> >>>
>>>> >>
>>>> >> If I had to guess, there is some kind of issue in nat/iptables handling....
>>>> >>
>>>> >> Any change you try without iptables?
>>>> >>
>>>> >> -vlad
>>>> >>
>>>> >>> Thanks,
>>>> >>> Varun
>>>> >>>
>>>> >>> On Thu, Sep 25, 2014 at 6:06 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>>>> >>>> On Thu, Sep 25, 2014 at 03:53:13PM +0530, VARUN BHATIA wrote:
>>>> >>>>> The mask kept is /16, I placed wrong information correcting it:
>>>> >>>>>
>>>> >>>>>                   Host A                                      Host B
>>>> >>>>> Primary    10.204.200.200                          10.204.100.100
>>>> >>>>> Secondary 10.205.200.200                         10.205.100.100
>>>> >>>>>
>>>> >>>>> We are having our customized linux.
>>>> >>>>>
>>>> >>>>> ip neigh list
>>>> >>>>> fe80::224:13ff:fe45:ced4 dev eth3 lladdr 00:24:13:45:ce:d4 router STALE
>>>> >>>>> fe80::224:13ff:fe45:ced5 dev eth0 lladdr 00:24:13:45:ce:d5 router STALE
>>>> >>>>> 10.205.100.100 dev eth3 lladdr 00:0b:ab:55:57:01 REACHABLE
>>>> >>>>>
>>>> >>>>> I tried for a workaround and played with nat rules:
>>>> >>>>>
>>>> >>>>> iptables -t nat -I POSTROUTING -o eth2 -d 10.204.100.100 -j SNAT -p
>>>> >>>>> sctp --to 10.204.200.200
>>>> >>>>> iptables -t nat -I POSTROUTING -o eth3 -d 10.205.100.100 -j SNAT -p
>>>> >>>>> sctp --to 10.205.200.200
>>>> >>>>>
>>>> >>>>> After this it started working though it is not the correct solution,
>>>> >>>>> but yet after this it seems due to some conntrack table entries when I
>>>> >>>>> receive request from peer end it is not working proparly:
>>>> >>>>>
>>>> >>>>>   3.484280 10.205.200.200 -> 10.205.100.100 SCTP 98 INIT
>>>> >>>>>   3.488652 10.205.100.100 -> 10.205.200.200 SCTP 354 INIT_ACK
>>>> >>>>>   3.488706 10.205.200.200 -> 10.205.100.100 SCTP 310 COOKIE_ECHO
>>>> >>>>>   3.488923 10.205.100.100 -> 10.205.200.200 SCTP 60 COOKIE_ACK
>>>> >>>>>
>>>> >>>>>   3.497282 10.205.200.200 -> 10.205.100.100 SCTP 62 SACK
>>>> >>>>>
>>>> >>>>>   6.512476 10.205.100.100 -> 10.205.200.200 SCTP 98 INIT
>>>> >>>>>   6.512575 10.204.200.200 -> 10.205.100.100 SCTP 354 INIT_ACK
>>>> >>>>>
>>>> >>>>>  21.240776 10.205.100.100 -> 10.205.200.200 SCTP 310 COOKIE_ECHO
>>>> >>>>>  21.240866 10.204.200.200 -> 10.205.100.100 SCTP 50 COOKIE_ACK
>>>> >>>>>  21.242183 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN
>>>> >>>>>  21.242237 10.205.200.200 -> 10.205.100.100 SCTP 50 SHUTDOWN_ACK
>>>> >>>>>  21.242353 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN_COMPLETE
>>>> >>>>>
>>>> >>>>> When peer end sends INIT my box again send INIT_ACK using primary ip
>>>> >>>>> address simlarly for COOKIE_ACK also, but SHUTDOWN ACK it is sending
>>>> >>>>> correct.
>>>> >>>>>
>>>> >>>>> Not sure what I am missing here, kindly provide your inputs on this ?
>>>> >>>>>
>>>> >>>>> Thanks,
>>>> >>>>> Varun
>>>> >>>>>
>>>> >>>>
>>>> >>>> This is working as designed.  Since both your host addresses are on the same
>>>> >>>> subnet, and since ip addresses are owned by the system in linux, not the
>>>> >>>> interface, its not really relevant which source address is used.  If you want to
>>>> >>>> force source ip addresses to be used for the interface you are sending from,
>>>> >>>> you'll want to add higher priority routes that specify the src address.
>>>> >>>>
>>>> >>>> Neil
>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Regards,
>>>> > Varun Bhatia
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Varun Bhatia
>>>>
>>
>>
>>
>> --
>> Regards,
>> Varun Bhatia



-- 
Regards,
Varun Bhatia

Re: SCTP Multihoming Always sending primary interface ip I

[Neil Horman]

On Tue, Oct 14, 2014 at 06:32:17PM +0530, VARUN BHATIA wrote:
> Thanks to all of you for your support, first I was trying to make one
> to one working only  and got the understanding that it was not working
> because it was not able to select proper route as there were default
> routes been also created with netmask 16 and it was been selected.
> When I created a unique netmask with 24 it started working.
> 
> I have analyzed that for SCTP route is required in main routing table
> not in user defined routing table, are you aware why is it so ?
> 
Not sure what you mean by the above, can you elaborate?
Neil

> Another part the requirement has come to us for full mesh support
> because there switch supports full mesh kindly let me know any rfc or
> standard which mention specifically this ?
> Not sure how to move forward on this.
> 
> Thanks,
> Varun
> 
> On Tue, Oct 14, 2014 at 2:38 PM, Vladislav Yasevich <vyasevich@gmail.com> wrote:
> > On Mon, Oct 13, 2014 at 9:26 AM, VARUN BHATIA <varuninbharti@gmail.com> wrote:
> >> Hi Neil,
> >>
> >> The expectation is to support full mesh sctp association which is
> >> capability to establish crossed paths inside SCTP association in
> >> addition to direct paths between SCTP peers (IP addresses).
> >>
> >> Not sure whether this can be done through routing or making changes in SCTP ?
> >
> > Now I understand what you are trying to do.  No, full mesh isn't supported.
> > A path is determined per-destination, not per source+destination.
> >
> > -vlad
> >
> >>
> >> Thanks,
> >> Varun
> >>
> >>
> >>
> >> On Wed, Oct 8, 2014 at 6:47 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> >>> On Wed, Oct 08, 2014 at 12:37:04PM +0530, VARUN BHATIA wrote:
> >>>> Hi,
> >>>>
> >>>> I have made some changes in routing and it seems started working but
> >>>> having some doubts in that:
> >>>>
> >>>> ip route add 10.204.200.200 dev eth2 src 10.204.100.100
> >>>>
> >>>> ip route add 10.205.200.200 dev eth3 src 10.205.100.100
> >>>>
> >>>> 1. My all the ips are plumbed interfaces so whether it is required to
> >>>> provide precise dev such as eth2:3 or eth3:2 ?
> >>>>
> >>> I don't think so, no.
> >>>
> >>>> 2. After adding this routing I am expecting symmetric routing that is
> >>>> primary<->primary & secondary<->secondary, but my peer supports
> >>>> assymetric also such as it secondary sends packet to my primary too,
> >>>> how should that part be handled ?
> >>>>
> >>> Under what conditions do you want assymetric routing to occur?
> >>>
> >>> Neil
> >>>
> >>>> Thanks,
> >>>> Varun
> >>>>
> >>>> On Tue, Oct 7, 2014 at 1:02 PM, VARUN BHATIA <varuninbharti@gmail.com> wrote:
> >>>> > Hi Vlad,
> >>>> >
> >>>> > For clearing this doubt I created a rule in raw table that it should
> >>>> > bypass my netfilter module but the issue is still coming:
> >>>> >
> >>>> > iptables -t raw -I PREROUTING -i eth3 -j CT --notrack
> >>>> > iptables -t raw -I PREROUTING -i eth2 -j CT --notrack
> >>>> >
> >>>> > Where eth2 is my primary interface.
> >>>> >
> >>>> > Thanks,
> >>>> > Varun
> >>>> >
> >>>> > On Fri, Oct 3, 2014 at 8:24 PM, Vlad Yasevich <vyasevich@gmail.com> wrote:
> >>>> >> On 10/01/2014 09:58 AM, VARUN BHATIA wrote:
> >>>> >>> Hi,
> >>>> >>>
> >>>> >>> They both are on different subnets one is on 10.204 & other o 10.205.
> >>>> >>>
> >>>> >>> Kindly let me know what route will be required for this as I am still
> >>>> >>> stuck in this issue.
> >>>> >>>
> >>>> >>
> >>>> >> If I had to guess, there is some kind of issue in nat/iptables handling....
> >>>> >>
> >>>> >> Any change you try without iptables?
> >>>> >>
> >>>> >> -vlad
> >>>> >>
> >>>> >>> Thanks,
> >>>> >>> Varun
> >>>> >>>
> >>>> >>> On Thu, Sep 25, 2014 at 6:06 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
> >>>> >>>> On Thu, Sep 25, 2014 at 03:53:13PM +0530, VARUN BHATIA wrote:
> >>>> >>>>> The mask kept is /16, I placed wrong information correcting it:
> >>>> >>>>>
> >>>> >>>>>                   Host A                                      Host B
> >>>> >>>>> Primary    10.204.200.200                          10.204.100.100
> >>>> >>>>> Secondary 10.205.200.200                         10.205.100.100
> >>>> >>>>>
> >>>> >>>>> We are having our customized linux.
> >>>> >>>>>
> >>>> >>>>> ip neigh list
> >>>> >>>>> fe80::224:13ff:fe45:ced4 dev eth3 lladdr 00:24:13:45:ce:d4 router STALE
> >>>> >>>>> fe80::224:13ff:fe45:ced5 dev eth0 lladdr 00:24:13:45:ce:d5 router STALE
> >>>> >>>>> 10.205.100.100 dev eth3 lladdr 00:0b:ab:55:57:01 REACHABLE
> >>>> >>>>>
> >>>> >>>>> I tried for a workaround and played with nat rules:
> >>>> >>>>>
> >>>> >>>>> iptables -t nat -I POSTROUTING -o eth2 -d 10.204.100.100 -j SNAT -p
> >>>> >>>>> sctp --to 10.204.200.200
> >>>> >>>>> iptables -t nat -I POSTROUTING -o eth3 -d 10.205.100.100 -j SNAT -p
> >>>> >>>>> sctp --to 10.205.200.200
> >>>> >>>>>
> >>>> >>>>> After this it started working though it is not the correct solution,
> >>>> >>>>> but yet after this it seems due to some conntrack table entries when I
> >>>> >>>>> receive request from peer end it is not working proparly:
> >>>> >>>>>
> >>>> >>>>>   3.484280 10.205.200.200 -> 10.205.100.100 SCTP 98 INIT
> >>>> >>>>>   3.488652 10.205.100.100 -> 10.205.200.200 SCTP 354 INIT_ACK
> >>>> >>>>>   3.488706 10.205.200.200 -> 10.205.100.100 SCTP 310 COOKIE_ECHO
> >>>> >>>>>   3.488923 10.205.100.100 -> 10.205.200.200 SCTP 60 COOKIE_ACK
> >>>> >>>>>
> >>>> >>>>>   3.497282 10.205.200.200 -> 10.205.100.100 SCTP 62 SACK
> >>>> >>>>>
> >>>> >>>>>   6.512476 10.205.100.100 -> 10.205.200.200 SCTP 98 INIT
> >>>> >>>>>   6.512575 10.204.200.200 -> 10.205.100.100 SCTP 354 INIT_ACK
> >>>> >>>>>
> >>>> >>>>>  21.240776 10.205.100.100 -> 10.205.200.200 SCTP 310 COOKIE_ECHO
> >>>> >>>>>  21.240866 10.204.200.200 -> 10.205.100.100 SCTP 50 COOKIE_ACK
> >>>> >>>>>  21.242183 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN
> >>>> >>>>>  21.242237 10.205.200.200 -> 10.205.100.100 SCTP 50 SHUTDOWN_ACK
> >>>> >>>>>  21.242353 10.205.100.100 -> 10.205.200.200 SCTP 60 SHUTDOWN_COMPLETE
> >>>> >>>>>
> >>>> >>>>> When peer end sends INIT my box again send INIT_ACK using primary ip
> >>>> >>>>> address simlarly for COOKIE_ACK also, but SHUTDOWN ACK it is sending
> >>>> >>>>> correct.
> >>>> >>>>>
> >>>> >>>>> Not sure what I am missing here, kindly provide your inputs on this ?
> >>>> >>>>>
> >>>> >>>>> Thanks,
> >>>> >>>>> Varun
> >>>> >>>>>
> >>>> >>>>
> >>>> >>>> This is working as designed.  Since both your host addresses are on the same
> >>>> >>>> subnet, and since ip addresses are owned by the system in linux, not the
> >>>> >>>> interface, its not really relevant which source address is used.  If you want to
> >>>> >>>> force source ip addresses to be used for the interface you are sending from,
> >>>> >>>> you'll want to add higher priority routes that specify the src address.
> >>>> >>>>
> >>>> >>>> Neil
> >>>> >>>>
> >>>> >>>
> >>>> >>>
> >>>> >>>
> >>>> >>
> >>>> >
> >>>> >
> >>>> >
> >>>> > --
> >>>> > Regards,
> >>>> > Varun Bhatia
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Regards,
> >>>> Varun Bhatia
> >>>>
> >>
> >>
> >>
> >> --
> >> Regards,
> >> Varun Bhatia
> 
> 
> 
> -- 
> Regards,
> Varun Bhatia
>