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@xxxxxxxxx> wrote: > > On Mon, Oct 13, 2014 at 9:26 AM, VARUN BHATIA <varuninbharti@xxxxxxxxx> 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@xxxxxxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxx> 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
