Open Stack

Thanks Kevin, very helpful....other comments in line.
CM

On Mon, May 22, 2017 at 9:15 PM, Kevin Benton <kevin at benton.pub> wrote:

> On May 22, 2017 9:34 AM, "Chris Marino" <chris at romana.io> wrote:
>
> I'm digging into how Routed Provider Networks work and have some questions
> as well. I will presenting at the OpenStack Meetup
> <https://www.meetup.com/openstack/events/239889735/>on Wed on this and
> want to make sure I have my facts straight......
>
> From the doc page
> <https://docs.openstack.org/ocata/networking-guide/config-routed-networks.html> it
> shows a multi-segment network with segment 1 on 203.0.113.0/24 and
> segment 2 on 198.51.100.0/24. It also suggests using the same VLAN ID for
> these segments.
>
> I find both of these things really confusing.
>
>
> What do you find confusing about this? It's a pretty standard L3 to ToR
> and L2 in rack setup. L2 is limited to the rack so you can use or not use
> whatever VLANs in that scope. We can fix the docs to clear up whatever
> confusion you have.
>

My confusion was based on my somewhat narrow understanding of the use case.
My thinking was that the current L2 provider networks would be cast as set
of L2 segments (with contiguous CIDRs) on an L3 network. Seeing both the
203. and 198. networks getting consolidated into a single network is pretty
disorienting. Together they are not a single network by the traditional
definition of a network. Then describing the 'segment ID' as a VLAN ID was
confusing for two reasons. First, it carries forward the idea that the
segments are VLANs, which they might be, but don't have to be. Then using
the same 'VLAN ID' for different segments (even though its a segment ID) on
different networks implies that they might even be the same VLAN, which
they are not.


> But ignoring that for a minute, I'm more interested in the expected use
> case for this feature. I see from the original spec/blueprint
> <http://specs.openstack.org/openstack/neutron-specs/specs/newton/routed-networks.html>
>  that the goal was to allow for a single Provider Network to be made up
> from multiple network segments, where external routing provided
> connectivity among the segments. And Routed Provider Networks provide
> this.  Great.
>
> But the use cases I'm curious about are where the operator wants to take
> their current L2/VLAN Provider Networks, but deploy it as an L3 Provider
> Network. Same CIDR as the L2 provider network, but in a fully routed
> deployment (i.e. no L2 adjacency). It might be L3 to the ToR and (untagged)
> L2 to the host. Or L3 to the host.
>
> Both of these configurations are gaining popularity and wondering how they
> would need to be configured. For the L3 to ToR, the network segments would
> have to be split across the ToRs as described in the doc, but what about L3
> to host? Guessing a segment per host, but wondering how practical that's
> going to be without better coordination of IP/segments with Nova?
>
>
> L3 to the host and one segment per host is possible, but it's going to
> have a severe limitation of not being able to migrate VMs without an IP
> change. To get migration at that point you will need some form of dynamic
> routing.
>

Yes, dynamic routing is going to help here as well as the config/setup.


>
> L3 to ToR and L2 in rack is definitely the target use case as of now.
>

Yes, I see that more clearly now.


>
> On May 22, 2017 9:34 AM, "Chris Marino" <chris at romana.io> wrote:
>
>> I'm digging into how Routed Provider Networks work and have some
>> questions as well. I will presenting at the OpenStack Meetup
>> <https://www.meetup.com/openstack/events/239889735/>on Wed on this and
>> want to make sure I have my facts straight......
>>
>> From the doc page
>> <https://docs.openstack.org/ocata/networking-guide/config-routed-networks.html> it
>> shows a multi-segment network with segment 1 on 203.0.113.0/24 and
>> segment 2 on 198.51.100.0/24. It also suggests using the same VLAN ID
>> for these segments.
>>
>> I find both of these things really confusing. But ignoring that for a
>> minute, I'm more interested in the expected use case for this feature. I
>> see from the original spec/blueprint
>> <http://specs.openstack.org/openstack/neutron-specs/specs/newton/routed-networks.html> that the
>> goal was to allow for a single Provider Network to be made up from multiple
>> network segments, where external routing provided connectivity among the
>> segments. And Routed Provider Networks provide this.  Great.
>>
>> But the use cases I'm curious about are where the operator wants to take
>> their current L2/VLAN Provider Networks, but deploy it as an L3 Provider
>> Network. Same CIDR as the L2 provider network, but in a fully routed
>> deployment (i.e. no L2 adjacency). It might be L3 to the ToR and (untagged)
>> L2 to the host. Or L3 to the host.
>>
>> Both of these configurations are gaining popularity and wondering how
>> they would need to be configured. For the L3 to ToR, the network segments
>> would have to be split across the ToRs as described in the doc, but what
>> about L3 to host? Guessing a segment per host, but wondering how practical
>> that's going to be without better coordination of IP/segments with Nova?
>>
>> CM
>> ᐧ
>>
>> On Sun, May 21, 2017 at 6:12 AM, Alex Evonosky <alex.evonosky at gmail.com>
>> wrote:
>>
>>> Thank you Yura.
>>>
>>> A
>>>
>>> On Thu, May 18, 2017 at 3:24 AM, Yura Poltoratskiy <
>>> yurapoltora at gmail.com> wrote:
>>>
>>>> Hi
>>>>
>>>> On 17.05.2017 21:56, Alex Evonosky wrote:
>>>>
>>>>> Hello fellow Openstackers-
>>>>>
>>>>> I have a quick question regarding routed provider networks.  I am
>>>>> looking at this
>>>>> page: https://docs.openstack.org/ocata/networking-guide/config-rou
>>>>> ted-networks.html
>>>>>
>>>>> I configured the controller as stated in the docs, however this line is
>>>>> somewhat vaugue:
>>>>>
>>>>> "
>>>>>
>>>>>
>>>>>       Network or compute nodes¶
>>>>>       <https://docs.openstack.org/ocata/networking-guide/config-ro
>>>>> uted-networks.html#network-or-compute-nodes>
>>>>>
>>>>>   * Configure the layer-2 agent on each node to map one or more
>>>>> segments
>>>>>     to the appropriate physical network bridge or interface and restart
>>>>>     the agent."
>>>>>
>>>>>
>>>>> Which file am I editing on the compute nodes to answer the above
>>>>> question?
>>>>>
>>>> If you are using OpenVSwitch agent, then on compute/network node you
>>>> should modify:
>>>> /etc/neutron/plugins/ml2/openvswitch_agent.ini
>>>> /etc/neutron/plugins/ml2/ml2_conf.ini
>>>>
>>>>
>>>>>
>>>>> Thank you,
>>>>> A
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Mailing list: http://lists.openstack.org/cgi
>>>>> -bin/mailman/listinfo/openstack
>>>>> Post to     : openstack at lists.openstack.org
>>>>> Unsubscribe : http://lists.openstack.org/cgi
>>>>> -bin/mailman/listinfo/openstack
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Mailing list: http://lists.openstack.org/cgi
>>>> -bin/mailman/listinfo/openstack
>>>> Post to     : openstack at lists.openstack.org
>>>> Unsubscribe : http://lists.openstack.org/cgi
>>>> -bin/mailman/listinfo/openstack
>>>>
>>>
>>>
>>> _______________________________________________
>>> Mailing list: http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>> Post to     : openstack at lists.openstack.org
>>> Unsubscribe : http://lists.openstack.org/cgi
>>> -bin/mailman/listinfo/openstack
>>>
>>>
>>
>> _______________________________________________
>> Mailing list: http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20170523/77a66b87/attachment.html>