fuel-dev team mailing list archive

[Vladimir Kuklin <vkuklin@xxxxxxxxxxxx>]

Andrew,

I failed to understand what is L3-Routes feature. As it's been a while for
me after our last discussion on this topic, it completely flew out of my
head and I failed to find where I could get complete description for this
feature. It seems that there is no blueprint for it and no comprehendable
description on User Story, requirements or any specifications. Let's start
with blueprint first and finally understand what do we want to configure,
why do we want to do it, what can we do right now and what are the major
concerns and obstacles.


On Thu, Feb 6, 2014 at 9:02 AM, Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>wrote:

> В исходном треде плиз, здесь только 5 человек.
> On Feb 6, 2014 2:27 AM, "Sergey Vasilenko" <svasilenko@xxxxxxxxxxxx>
> wrote:
>
>> sorry, I mean OSPF, exactly...
>>
>>
>> On Thu, Feb 6, 2014 at 2:25 AM, Sergey Vasilenko <svasilenko@xxxxxxxxxxxx
>> > wrote:
>>
>>> Why we can not use BGP in this case?
>>>
>>>
>>> On Wed, Feb 5, 2014 at 10:35 PM, Mike Scherbakov <
>>> mscherbakov@xxxxxxxxxxxx> wrote:
>>>
>>>> > 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?
>>>>
>>>> Коллеги, может быть у нас есть что-то ответить Андреу в исходном треде?
>>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: Andrew Woodward <xarses@xxxxxxxxx>
>>>> Date: Sat, Jan 25, 2014 at 12:48 PM
>>>> Subject: Re: [Fuel-dev] [fuel] multiple L3 routes
>>>> To: Matthew Mosesohn <mmosesohn@xxxxxxxxxxxx>
>>>> Cc: Andrew Woodward <awoodward@xxxxxxxxxxxx>, "
>>>> fuel-dev@xxxxxxxxxxxxxxxxxxx" <fuel-dev@xxxxxxxxxxxxxxxxxxx>
>>>>
>>>>
>>>> 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!
>>>>
>>>> --
>>>> 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
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Mike Scherbakov
>>>> #mihgen
>>>>
>>>
>>>
>>


-- 
Yours Faithfully,
Vladimir Kuklin,
Senior Deployment Engineer,
Mirantis, Inc.
+7 (495) 640-49-04
+7 (926) 702-39-68
Skype kuklinvv
45bk3, Vorontsovskaya Str.
Moscow, Russia,
www.mirantis.com <http://www.mirantis.ru/>
www.mirantis.ru
vkuklin@xxxxxxxxxxxx