fuel-dev team mailing list archive

[Andrew Woodward <xarses@xxxxxxxxx>]

Given

L3 A:
admin 10.20.0.0/24
public 10.20.1.0/24
mgmt 10.20.2.0/24
storage 10.20.3.0/24
default route via 10.20.1.1/24 (A.public)

L3 B:
admin 10.30.0.0/24
public 10.30.1.0/24
mgmt 10.30.2.0/24
storage 10.30.3.0/24
default route via 10.30.1.1/24 (B.public)

A conversation with this setup from A to B.mgmt will look like
A.public-> A.public.gw -> [routers] B.mgmt with a response of B.public ->
B.public.gw -> [routers] -> A.public

We receive a async response

Adding a route on A for 10.30.2.0/24 via A.mgmt
and route on B for 10.20.2.0/24 via B.mgmt results in
A.mgmt-> A.mgmt.gw -> [routers] B.mgmt with a response of B.mgmt ->
B.mgmt.gw -> [routers] -> A.mgmt





On Sat, Jan 25, 2014 at 12:37 AM, Andrew Woodward <xarses@xxxxxxxxx> wrote:

> As in the examples, the packets are arriving on the interface(s) with out
> the default route, and returning on the interface with the default route.
> Adding a specific route on both nodes to use the correct interface results
> in packets traversing from admin to admin or mgmt to mgmt as expected. With
> out these routes the packets are simply being discarded
>
>
> On Sat, Jan 25, 2014 at 12:27 AM, Matthew Mosesohn <mmosesohn@xxxxxxxxxxxx
> > wrote:
>
>> One explanation I can think of is you are trying to reach another node
>> via mgmt net, but it gets sent from the admin interface. The response
>> comes back to the wrong NIC and gets dropped.
>> To be sure routing itself is working, try ping -I $interface $dest
>> from each interface and see where the breakdown occurs. Since you're
>> testing multiple L3 networks, I'm curious to know if the same router
>> NIC is handling all networks for a particular L3 segment with VLANs to
>> split up the logical networks.
>>
>> On Sat, Jan 25, 2014 at 12:01 PM, Andrew Woodward
>> <awoodward@xxxxxxxxxxxx> wrote:
>> > During our ml3 testing today, we found that we will need set multiple
>> routes
>> > into the nodes in order to get them to return packets over the
>> appropriate
>> > interfaces. ie, received traffic comes in one interface and returns
>> over the
>> > default route and creates async routing, which results in dropped
>> responses.
>> >
>> > I think that setting up separate route tables with default routes in 'ip
>> > route' as in [1] or [2] may be the best solution forward. Although
>> possibly
>> > less useful implementations include setting up static routes for peer
>> > networks, or using a routing protocol to learn routes on each interface.
>> >
>> > I'd like some help on possibly implementing one of these methods. Does
>> any
>> > one know of any puppet providers or the like that can stand this up in a
>> > automated way?
>> >
>> > [1]
>> http://serverfault.com/questions/228195/answering-on-the-same-interface-where-the-request-came-from
>> > [2]
>> http://superuser.com/questions/325128/how-can-i-ensure-outbound-traffic-uses-the-same-interface-as-that-of-inbound-tra
>> >
>> > --
>> > Mailing list: https://launchpad.net/~fuel-dev
>> > Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>> > Unsubscribe : https://launchpad.net/~fuel-dev
>> > More help   : https://help.launchpad.net/ListHelp
>> >
>>
>> --
>> Mailing list: https://launchpad.net/~fuel-dev
>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~fuel-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> --
> If google has done it, Google did it right!
>



-- 
If google has done it, Google did it right!