[quagga-dev 9995] Re: ospf daemon not learning Type3 LS updates

vishal kumar vishal3.kumar at gmail.com
Thu Nov 15 15:03:02 GMT 2012


Thx for the confirmation Scott.
I would be more than happy to send the proper patch to the dev list, but I
am on vacation till 25th Nov.
I will post my fix as soon as I return.

Thanks
Vishal


On Thu, Nov 1, 2012 at 11:26 PM, Scott Feldman
<sfeldma at cumulusnetworks.com>wrote:

> Hi Vishal,
>
> So the first part of your patch was independently fix and has been
> applied.  It's nice that the exact fix was found by both.
>
> On the second part of your patch (type 5), would you generate/send a
> proper patch to the dev list with just that fix?  Thanks.
>
> -scott
>
> On Oct 29, 2012, at 5:00 AM, vishal kumar wrote:
>
> > Hi List,
> >
> > I have confirmed the fix for this problem with Quagga team, the final
> fix for this issue is:
> >
> > RCS file: /projects/fusion/cvs/src/services/quagga/ospfd/ospf_abr.c,v
> > retrieving revision 1.6
> > diff -r1.6 ospf_abr.c
> > 738c739
> > <       if (GET_METRIC (sl->metric) == cost)
> > ---
> > >       if ((GET_METRIC (sl->metric) == cost) &&
> >                ((old->flags & OSPF_LSA_IN_MAXAGE) == 0))
> >
> > Similar problem exists for Type:5 ls updates and the solution for which
> I have done is:
> >
> > 1127c1128
> > <   if (old && (GET_METRIC (slsa->metric) == cost))
> > ---
> > >   if (old && (GET_METRIC (slsa->metric) == cost) &&
> >                ((old->flags & OSPF_LSA_IN_MAXAGE) == 0))
> >
> > 1670c1671
> >
> > This is working for me without any exception in the scenario mentioned
> in the mail chain.
> >
> > Regards
> > Vishal
> >
> > On Thu, Oct 18, 2012 at 12:35 AM, vishal kumar <vishal3.kumar at gmail.com>
> wrote:
> > Hi Dinesh,
> >
> > You were referring to me or Staale.
> >
> > @Staale, I went through your fix which you provided on Sep 29, 2012
> where you proposed to introduce a new function 'ospf_lsa_maxage_now' which
> will remove the ls update from ABR when the neighbour state change. This
> has following problem:
> >
> > 1) In your example after applying your fix when we fire the 'show ip
> ospf database' command on CiscoR1 and QuaggaR1 the database will be not in
> sync. The database at CiscoR1 will be still showing the Type-3 ls update in
> its table with MAX_AGE (3600) value but in the database table at QuaggaR1
> it wont be present as we just deleted it after the state change. This is
> not as per the standard 'Link state Protocol' definition.
> > 2) Another problem is that this will work only in the case which you
> have mentioned when the interface between QuaggaR1 and QuaggaR2 are going
> down; not when ospf is terminated at QuaggaR1. This is because when
> interface b/w QuaggaR1 and QuaggaR2 is brought down ospf is still running
> and it can run the remover routing to perform your required task. But in
> the other case ospf is terminated and it cannot perform any task.
> >
> > Regards
> > Vishal
> >
> >
> > On Sat, Oct 13, 2012 at 11:19 AM, Dinesh Dutt <ddutt at cumulusnetworks.com>
> wrote:
> > Staale,
> >
> > I think your patch is correct.
> >
> > Dinesh
> >
> > On Fri 12 Oct 2012 01:32:53 PM PDT, vishal kumar wrote:
> > I read more about ospf and debugged the issue. There is certainly a
> > issue in current ospf code (quagga:0.99.21) in case when ospf running
> > on ABR goes down and comes up before Network Summary routes (published
> > by this ABR) are aged out at its peer.
> > I also found a solution for this, so far in my testing I dont see any
> > side effects. 1st I will try to explain the scenario with example,
> > where this can be observed then I will post the code diff.
> >
> > 1) The ospf network is up and Network summary route (10.157.96.0/24
> > <http://10.157.96.0/24>) is learnt at Router1. Let say Router1 is also
> >
> > the DR for area 0.0.0.1
> > 2) Now ospf goes down at DUT and he dont inform Router1 about his
> > ospfd termination (as per the current quagga ospf design), so Router1
> > will retain its Network Summary routes till hello dead time arrives.
> > 3) Now before Network Summary routes set aged out (after hello dead
> > time) at Router1, start ospf daemon at DUT. This will initiate ospf
> > description and ls update exchange between the Router1 and DUT.
> > Similar activity will be going on between DUT and Router2 in area
> 0.0.0.0.
> > 4) Now Router1 being the DR for area 0.0.0.1 he will publish all his
> > ospf learnt route to DUT, which will also contain the Network Summary
> > route (10.157.96.0/24 <http://10.157.96.0/24> -> 10.157.91.30) learnt
> >
> > earlier frm DUT.
> > 5) After receiving this Network Summary route from Router1, DUT
> > responses Router1 with a LS update for that Network summary with a ls
> > age = 3600 (OSPF_LSA_MAXAGE) so that Router1 can age out its entry for
> > its Network Summary Route table. At the same time DUT also sets the ls
> > age time at its own datastructure with ls age of 3600 for Type3 ls
> > update. This is so that 'ospf_lsa_maxage_walker_remover' can clean
> > this form DUT and Rouetr1.
> > 6) Now as I mentioned earlier similar ospf negotiation was going on
> > between DUT and Router1 in area 0.0.0.0, from where he learnt the
> > 10.157.96.0/24 <http://10.157.96.0/24> network again. Now this learnt
> >
> > network needs to be published in area 0.0.0.1 by DUT as Network
> > summary route with correct metics/ls age. But DUT doesnt do that
> > because of the current Quagga ospf code. Because of which this Network
> > Summary route is never learnt at Router1.
> > The current code of ospf prevent in sending the Network Summary router
> > because it has already send a Network summary route with ls age time
> > 3600 earlier which is maintained in its data structure.
> >
> > Following is the changes I have made to rectify the problem:
> >
> > RCS file: /projects/fusion/cvs/src/services/quagga/ospfd/ospf_abr.c,v
> > retrieving revision 1.6
> > diff -r1.6 ospf_abr.c
> > 738c739
> > <       if (GET_METRIC (sl->metric) == cost)
> > ---
> > >       if ((GET_METRIC (sl->metric) == cost) && !IS_LSA_MAXAGE (old))
> >
> > Similar problem exists for Type:5 ls updates and the solution for
> > which I have done is:
> >
> > 1127c1128
> > <   if (old && (GET_METRIC (slsa->metric) == cost))
> > ---
> > >   if (old && (GET_METRIC (slsa->metric) == cost) && !IS_LSA_MAXAGE
> > (old))
> > 1670c1671
> >
> > Please let me know if my solution is wrong or posses any threat and
> > if I need to share any further description regarding this.
> >
> > Regards
> > Vishal
> >
> >
> > _______________________________________________
> > Quagga-dev mailing list
> > Quagga-dev at lists.quagga.net
> > http://lists.quagga.net/mailman/listinfo/quagga-dev
> >
> >
> > _______________________________________________
> > Quagga-dev mailing list
> > Quagga-dev at lists.quagga.net
> > http://lists.quagga.net/mailman/listinfo/quagga-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quagga.net/pipermail/quagga-dev/attachments/20121115/934b2a02/attachment-0001.html>


More information about the Quagga-dev mailing list