While we all are agreeing (mostly) that the ultimate solution to scale
better and get the most out of the system is to provide N-in-1 and 1-in-1
and also both together. So, lets see how the desired model may look like if
we also want to utilize the submitted patches to the best of their
capabilities :).
if user wants..
N = M x P
N = total number of VRFs
P = total number of processes
M = total number of (VRF)instances per processes.
(M could vary per process too)
If we keep things simple, and continue with single zebra daemon approach
(submitted by 6WIND), and see how protocols (OSPF/BGP/etc.) can be made to
work in the above model.
Multi-instance OSPF (submitted by Cumulus) can be used to create multiple
protocol daemons.
(I am not sure if 6WIND or someone else has a working model of creating
processes based on the config read by vtysh, didn¹t explore this).
Few relevant things to note about the Cumulus patch:
- It already registers with zebra with process-instance-identifier
(coming from 'router ospf <id>¹) and by default reads/writes to the current
non-VRF table.
- Once daemons are up, then all configuration/debug/show commands are from
the vtysh just like before.
- There is one TO-DO, like some registering with the IP stack so one
process receives packets only coming on interfaces its interested in.
Once inside vtsyh, any config is allowed for those daemons. So, at that
point, VRFs can be configured within these OSPF daemons and map to different
tables for route-updates/redistribution purpose.
| OSPFd1 < vrf1, vrf2, ..
|
Zebra (VRF LIB) --| OSPFd2 < vrfs
|
| OSPFd3 < vrfs
|
>From the VRFs requirement point of view, the key difference from the MI OSPF
is that for VRFs, OSPF (instances/processes) should be writing to different
tables in zebra, I assume 6WIND design/patches take care of that.
So, as far as I see, with ospf process-id specification, writing to the same
non-vrf table, and VRFs mapping to different VRF tables, should cover what
we are trying to achieve.
For example:
- if someone wants separate process for each VRF, they just configure
one VRF per process.
- if someone wants all VRFs per process, that¹s what they can configure.
- and a mix can be imagined too.
- Multi-instance OSPF when users wants separate process for each
instance would work as is
Except..
.. if we want to create multiple OSPF (non-vrf) instances within one
process.
Was 6WIND planning to create generic separations within OSPF, and then give
flexibility to have a way to map those to either the same non-VRF table or
separate VRF tables ?
I think if we have this last one also taken care of, then we can head
towards a very generic model. And all we need to provide are
initialization/configuration methods.
Regards,
Vipin
PS: I tried to read all the comments, so I don¹t repeat whats already been
discussed/discarded, still its possible there is some redundancy to my text.
Also, I agree in general that individual processes for each VRFs will
have memory overhead, but I think 90M is probably too much, may be some more
insight is needed, it might be coming from static allocations, which can be
improved to make it need based.
On 12/12/14, 1:12 AM, "Feng Lu" <[email protected]> wrote:
> On 12/10/2014 10:03 PM, Paul Jakma wrote:
>>
>> Yeah, I remember when that was added in GNU Zebra days. Lot of churn.
>> I had assumed back then multi-instance support was going to follow,
>> but it never did.
>>
>> It's my memory of that churn that makes me a bit resistant to
>> N-instance-in-1. However, for ospfd, if the price has already been
>> paid and VRF can build on that without further churn, maybe...
>>
>> Tthere's still the config story though. I'd hate to end up with VRF
>> config relating a protocol instance to VRFs potentially in both the
>> config file of a VRF management daemon (to manage what processes
>> handle what), and also in the config of a daemon (if it's handling
>> multiple VRFs in one 1).
>>
>> If you can allay that fear, that'd help too.
>>
>> regards,
> Hi Paul,
>
> Have you seen in the patch of OSPF multi-instance from Cumulus?
>
> An individual daemon is already started for an instance. Hence
> we would think there would be only a little code to handle the
> instance related stuff within the instance (except the redist
> commands). But it is not. For examples:
>
> - The instance ID is added to lots of commands, and is used to
> check whether the instance is the correct instance;
> - All commands under the "router ospf" context now need to check
> whether the current instance exists.
>
> I would say, that's another type of churn. Maybe it is not so
> much as managing multiple instances in one daemon, while would
> be at the same level, I think.
>
> Well, if it was decided to forbid the idea of multi-instance in
> one daemon, I would suggest to use some other way to manage the
> daemons, trying to minimize the instance-ID-sensitive within
> the code. But I will not, because that's just the first step to
> handle multiple instances in one daemon. ;)
>
> What I want to say is - please release the fear to churn. Just
> do it, if people need it. :)
>
> Best regards,
> Feng Lu
>
> _______________________________________________
> Quagga-dev mailing list
> [email protected]
> https://lists.quagga.net/mailman/listinfo/quagga-dev
>
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
