[quagga-dev 10862] Re: [PATCH 2/4] zebra: quagga-re-onlink-support.patch

Joakim Tjernlund joakim.tjernlund at transmode.se
Sat Oct 26 16:39:43 BST 2013


Christian Franke <nobody at nowhere.ws> wrote on 2013/10/24 16:45:58:
> 
> On 10/24/2013 12:44 AM, Joakim Tjernlund wrote:
> > Dinesh G Dutt <ddutt at cumulusnetworks.com> wrote on 2013/10/24 
06:06:43:
> >> quagga-re-onlink-support.patch
> 
> > I recall this patch had some doubts in the past, I found my own 
comments 
> > in quagga-dev 9519
> 
> Have you had a look at quagga-dev 10576? I feel that this general
> approach might be a bit better as it doesn't yet introduce another
> nexthop type, but there hasn't been all that much feedback on comparing
> the two.
> 
> Quagga master supports NEXTHOP_IPV4_IFINDEX properly, so the only thing
> that still has to be done on top of this patch would be adding a way
> that allows routing daemons to set the NEXTHOP_FLAG_ONLINK via the IPC
> protocol. (I only required that flag internally in zebra to address the
> case of some recursive routes. Therefore, the patch didn't add a way to
> set that flag via IPC, that shouldn't be too complicated though.)

Would it have be explicit? Maybe it can be worked out "automagically"?
If the networks don't match, just add ONLINK attribute ?

Another thing you might know something about:
Unnumbered eth links are new to me, we don't use them(yet).
I am not sure what applies for such I/Fs w.r.t subnetwork mask?
For plain unnumbered ptp one don't have a network(mask = /32 ).
Has this changed for unnumbered eth I/Fs? 

 Jocke 




More information about the Quagga-dev mailing list