[quagga-dev 743] Re: ripd status

Greg Troxel gdt at ir.bbn.com
Wed Jan 14 17:44:12 GMT 2004


  What would be the difference between ZEBRA_IFA_DUP and
  ZEBRA_IFA_SECONDARY though? Arent they same thing to all intents and 
  purposes?

They might be.  It remains to add comments to the code that define
precisely the semantics of the flag _without_ using the words "is set
if Linux kernel says so".  Or, IFA_SECONDARY can be defined to be set
if Linux says so, but then that becomes a Linux-specific feature, and
we can define DUP to be 'there is another address on this interface
which is not marked DUP which has the prefix-cmp-same prefix'.  I
suppose SECONDARY can be defined just like that, with the added
restriction that the address which doesn't get SECONDARY is chosen to
be the one that the kernel does not label secondary, on kernels which
do such any kind of secondary labeling.

  I had this discussion with Gilad a long time ago. I argued that
  perhaps zebra should do detection of duplicate and included subnets
  and set the secondary flag accordingly. Discussion was inconclusive 
  (though in the case of linux, kernel sets secondary flag, and its 
  reflected on).

It's really a question of whether zebra should provide this
abstraction.  Since it is a bit hard, it might make sense to
centralize it.


  I would argue the issue of promotion or removal of addresses is one
  for the kernel, that zebra simply needs to be kept informed.

I agree.

  eth0:
   1.1.1.0/24
   1.1.1.x/25
   1.1.1.y/32

I'd say we should look at all the routing protocols which deal with
this, and see what def would be most useful for them.
I consider the above example pathological; while two nonoverlapping
prefixes are sometimes reasonble, as is having two addrs in the same
prefix, having overlapping nonequal prefixes to me is a sign of a
confused network design.  This case is likely to be underspecified in
routing daemons.  So it may not matter much how we handle it (but of
course we have to be clear and consistent).



More information about the Quagga-dev mailing list