(Resending as the previous mail was incomplete.)

On 5/15/07, sujay gupta <[EMAIL PROTECTED]> wrote:

Hi,

I fail to see as to how a non-optimal path will be picked up, for all
ABR's adjoining the transit area will do a transit area summary lsa
checking and route table modification if required.
Noting that the only difference prior to transit area summary lsa checking
and
after will be the nexthop modified by the ABR to reach the same
destination, and
as IP is hop by hop forwarding any border router adjoining the transit
area will pick
up the optimum path( be it thru the VL or not).

  The Transit area summary lsa check is placed after Intra and Inter area
route calculation
   so all routes will be touched if required.

Am I missing something?



Regds,
Sujay


On 4/30/07, Kui Zhang <[EMAIL PROTECTED]> wrote:
>
> Hi Acee,
>
> Yes, a simple way to prevent this from happening is to configure a full
> mesh
> of virtual links between all ABRs in the transit area.
> And this makes IP FRR works well too.
>
> Thanks,
> Kui
> -----Original Message-----
> From: Acee Lindem [mailto:[EMAIL PROTECTED] ]
> Sent: Monday, April 30, 2007 8:28 PM
> To: 章魁
> Cc: 'Anton Smirnov'; 'OSPF List'; 'Jin Wang'
> Subject: Re: [OSPF] Doubt for virtual link cost ?
>
> Hi Kui,
> Yes - there could be an ABR for the transit area that takes a
> "shortcut" across the transit area for a non-virtual link path. Other
> routers in the backbone will not know about this path and may take
> other paths.  However, this is not a problem since there is no
> possibility of a routing loop. Additionally, the situation can easily
> be remedied by configuring a virtual link between the transit area
> routers across the "shortcut" path.
>
> Thanks,
> Acee
>
> On Apr 30, 2007, at 2:48 AM, 章魁 wrote:
>
> > Hi Acee,
> > I guess Jin is asking that a non-optimal path might be chosen when
> > other
> > routers in backbone area can't check the transit area's summary lsa to
> > update the intra-area route. This should be a drawback of virtual
> > link, I
> > think.
> >
> > Kui
> > -----Original Message-----
> > From: Acee Lindem [mailto:[EMAIL PROTECTED]
> > Sent: Monday, April 30, 2007 4:11 AM
> > To: Anton Smirnov
> > Cc: OSPF List; Jin Wang
> > Subject: Re: [OSPF] Doubt for virtual link cost ?
> >
> > Hi Anton, Jin,
> > I guess I don't really understand the point of controversy here. I
> > agree with Anton. Note that if there is not an active virtual link
> > then the non-backbone area is not a transit area.
> > Thanks,
> > Acee
> > On Apr 29, 2007, at 8:23 AM, Anton Smirnov wrote:
> >
> >>    Jin,
> >>    right. In network design where such scenario is possible you
> >> always
> >> can create VL between this ABR and ABR providing best path via
> >> transit
> >> area. This will make the best path 'visible' to other routers in
> >> backbone.
> >>
> >> Anton
> >>
> >>
> >> Jin Wang wrote:
> >>>
> >>> Thanks for anton's response.
> >>> But if so,only the traffic going through this ABR(determined
> >>> before 16.3
> >>> calculating result) is forwarded by the new optimal path.For those
> >>> other
> >>> traffic not forwarded via this ABR(determined by 16.1 & 16.2) in the
>
> >>> backbone will not consider the new path(via ABR) even path is
> >>> shorter.right?
> >>>
> >>>
> >>> Best regards,
> >>>
> >>> Wangjin
> >>> Accton Technology China Company Ltd.
> >>> Shanghai R&D Center
> >>> TEL:+86-021-64859922*6227
> >>> E-mail:[EMAIL PROTECTED]
> >>> Web Site: www.accton.com.cn
> >>>
> >>
> >>
> >> _______________________________________________
> >> OSPF mailing list
> >> [email protected]
> >> https://www1.ietf.org/mailman/listinfo/ospf
> >
> >
> > _______________________________________________
> > OSPF mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/ospf
> >
> >
>
>
>
>
> _______________________________________________
> OSPF mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ospf
>


_______________________________________________
OSPF mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ospf

Reply via email to