Re: OSPF and LDP Intricacies

From: HEMANTH RAJ <hemanthrj_at_gmail.com>
Date: Tue, 6 Aug 2013 14:17:14 +0530

LSR is required not always. It depends on the topology.
If it is a flat back to back connected topology like this

R1-------R2-------R3--------R4------R5

Everyone doesnt know about each other by any other link . In this case, DBD
sends the brief databases of each other and LSR is sent by the neighbor to
get the updates.

Lets consider a ring topology where R2 is connected to R4 via another link
and in that case, R2 exchanges DBDs with R4 and in that case, Its LSA will
be sent to R3 and R3 would have relayed the LSAs to R4 and also R3
generated its own LSUs to R4 .

So in this case R4 knows about R2's connected links previously itself and
he doesnt explicitly ask for certain LSUs

So OSPF is designed to support all topologies and there is a design
constraint in itself when you have inter area logic running.

LDP by default uses IGP has its default loop prevention mechanism . OSPF
and ISIS LFA. Even LDP LFA ( Loop Free Alternates ) is available for loop
free detection logic.

I havent seen Path Vector and Hop Count TLV previously.

Merging two LSPs (going to the same destination) reduces the number of
labels being used in the network. However it makes it impossible to
differentiate between traffic common from two different sources before the
merging happened. To simplify things in transport networks, LSP merge was
also disabled.

On Mon, Aug 5, 2013 at 10:33 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:

> I think you may be wrong here, just to be symmetrical :)
>
> OSPF does not "flush" anything. The only way to get rid of DB data is by
> means of MAXAGE timeout.
>
> Also, keep in mind that even when a link down, routers may still be
> connected via some alternate route, and so the DB might be up to date
> already when the link comes back up (Minus the two LSAs that relate to
> the link being brought up).
>
> -Carlos
>
> routingfreak @ 05/08/2013 13:53 -0300 dixit:
> > Hi Carlos
> >
> > I think u may be wrong here
> >
> > R1-----------R2--------------R3----------R4
> >
> > When link between R2 and R3 fails , so watever R3 gave to R2 will be
> > flushed out, and when R3 forms neighorship with R2 again, R2 will
> > request for all the updates, for wat R3 is connected.
> >
> > So where Link State Request helps here.. Why not R3 can send all the
> > LSUs directly.
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Aug 5, 2013 at 8:25 PM, Carlos G Mendioroz <tron_at_huapi.ba.ar
> > <mailto:tron_at_huapi.ba.ar>> wrote:
> >
> > First part: router A and B from some area may get disconnected for
> some
> > time, and the world goes on. When they reconnect (link up) part of
> the
> > DB could be up to date and part may be not. Exchanging just the DBD
> > enables a more efficient update, just the needed data is sent.
> >
> > Makes sense ?
> > -Carlos
> >
> > routingfreak @ 05/08/2013 11:37 -0300 dixit:
> > > Hi all
> > >
> > > I have certain questions on OSPF .
> > >
> > > 1. Why do we require Link State Request Packet. I mean as per Link
> > State
> > > Routing Protocol, ur entire database has to be synchronised, then
> you
> > > should not request someone to get something, instead the neighbor
> > should
> > > give you entire LSUs to you
> > >
> > > Why they have designed Link State Request packet in OSPF.
> > > Anyhow the neighbor will request for all the LSAs from the DBD,
> > then why do
> > > they have Link State Request Packet in OSPF
> > >
> > > In LDP, There is a Loop Detection Mechanism which includes Hop
> > Count TLV
> > > and Path Vector TLV, Can someone throw some light on how these two
> > things
> > > are utilised,
> > > I have read the RFC and this is wat it says
> > >
> > > Loop Detection is a configurable option that provides a mechanism
> for
> > > finding looping LSPs and for preventing Label Request messages
> > from looping
> > > in the presence of non-merge capable LSRs.
> > >
> > > Can someone explain me wat is called as Non-Merged LSRs
> > >
> > >
> >
> > --
> > Carlos G Mendioroz <tron_at_huapi.ba.ar <mailto:tron_at_huapi.ba.ar>>
> > LW7 EQI Argentina
> >
> >
> >
> >
> > --
> > Regards
> > Routing Freak CCIE#35889 (SPv3)
>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
>
>
>
>
>

-- 
Regards
Hemanth Raj
CCIE#28593 (R&S)
Blogs and organic groups at http://www.ccie.net
Received on Tue Aug 06 2013 - 14:17:14 ART

This archive was generated by hypermail 2.2.0 : Sun Sep 01 2013 - 08:35:50 ART