fuel-dev team mailing list archive

[Matthew Mosesohn <mmosesohn@xxxxxxxxxxxx>]

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
>