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 <[email protected]> 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 <[email protected] > > 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 >> <[email protected]> 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 : [email protected] >> > Unsubscribe : https://launchpad.net/~fuel-dev >> > More help : https://help.launchpad.net/ListHelp >> > >> >> -- >> Mailing list: https://launchpad.net/~fuel-dev >> Post to : [email protected] >> 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!
-- Mailing list: https://launchpad.net/~fuel-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~fuel-dev More help : https://help.launchpad.net/ListHelp
