From: Senthil Kumar (senthil.kumar@intechnology.co.uk)
Date: Thu Oct 03 2002 - 12:47:24 GMT-3
I think what you are saying is that the two ABRs share the link over
which traffic should go, even if they are in different areas. Am I
incorrect?
i am ^&*fused.
but, what i meant was...unless if a backbone interface in a ABR anounces
inter-area summary routes to other ABR's which then propogates it inside its
area..there is no way two ABR's can exchange routes directly.
in this case..the abr of area 1 and area 0 will announce their part of
network connecting to router 12 along with other networks/links.
but when the routers learn about presence of an exit via r12..to both
area..they would prefer that path if it is the shortest to the destination..
dont you think so??..
-----Original Message-----
From: Howard C. Berkowitz [mailto:hcb@gettcomm.com]
Sent: 03 October 2002 16:23
To: Senthil Kumar
Subject: RE: OSPF Design
>true, but isnt this like overriding the default behaviour of asking an ABR
>to send lSA-4 type summary to another ABR but not through backbone.. router
>12 will not advertise area summary to neither of the area routers, it will
>use it itself and will want a virtual link to the area0 for exchanging
>summary routes.. (if you are not happy using virtual link)..no problem
other
>ABRs in area 1 and area 2 will exchange their part of routes/networks
>(including connecting to r12) to the backbone and you will other area
routes
>from the backbone.
>
>what do you think ?
I may not be visualizing what you are suggesting--too bad we don't
have a picture. If you could draw one, it would help me. I'm on a Mac
so don't have Visio, but can receive jpeg/gif or native PowerPoint.
I think what you are saying is that the two ABRs share the link over
which traffic should go, even if they are in different areas. Am I
incorrect?
May I suggest we put this on the general list so all can learn from it?
>
>-----Original Message-----
>From: Howard C. Berkowitz [mailto:hcb@gettcomm.com]
>Sent: 03 October 2002 14:42
>To: Senthil Kumar
>Subject: RE: OSPF Design
>
>
>>should not all ABRs send the area summeries to backbone and the backbone
>>routers forward this LSA4 summary to all ABRs..there by connecting all
>areas
>>through backbone routers.
>>
>>this case, the ABRS connected to backbone will summarize all its interarea
>>routes and forward it to the backbone which then forwards those summeries
>to
>>other ABRS...
>>
>>SEN.
>
>
>That's the normal case. What was desired here is avoiding the backbone.
>
>>
>>
>>-----Original Message-----
>>From: Howard C. Berkowitz [mailto:hcb@gettcomm.com]
>>Sent: 03 October 2002 13:06
>>To: ccielab@groupstudy.com
>>Subject: Re: OSPF Design
>>
>>
>>At 7:58 AM -0300 10/3/02, Carlos G Mendioroz wrote:
>>>All,
>>>what's wrong with two VLs ?
>>>This would actually make R12 an ABR (it is not unless
>>>it has a link in the backbone). Then it will do (if it
>>>is the best path, which I would guess is the case)
>>>route between areas 1 & 2.
>>
>>In general, I don't like to use virtual links unless I have to. This
>>was long a recommendation in CID. There are both practical and
>>protocol considerations.
>>
>>Practically, there were bugs in the OSPFv1 specification of VLs, so
>>people stayed away from them, and the code just wasn't tested to the
>>same extent as other features. The subtlety of configuring a router
>>ID rather than an interface as an endpoint can make them hard to
>>troubleshoot, as well as authentication.
>>
>>I'm also assuming that the best path is between the two non-backbone
>>areas. The static route with OSPF backup approach is something I've
>>primarily used to force traffic onto a preferred path -- manual
>>traffic engineering.
>>
>> From the protocol standpoint, running virtual links in an area makes
>>it ineligible for any kind of stubbiness.
>>
>>>
>>>Jason Sinclair wrote:
>>>>
>>>> Howard,
>>>>
>>>> I agree - makes much more sense design wise and will actually work
as
>>>> expected.
>>>>
>>> > Regards,
>>>\
>>> >
>>>> -----Original Message-----
>>>> From: Howard C. Berkowitz [mailto:hcb@gettcomm.com]
>>>> Sent: Thursday, 3 October 2002 10:10
>>>> To: ccielab@groupstudy.com
>>>> Subject: RE: OSPF Design
>>>>
>>>> At 9:49 AM +1000 10/3/02, Jason Sinclair wrote:
>>>> >I would not call this design as such, however this could be
>configured
>>via
>>>> >the use of two virtual links to area 0 via the other two respective
>>areas.
>>>>
>>>> Mea culpa, Jason. Let me suggest a compromise that does force an ABR
>>>> area 0.0.0.0 connection, but doesn't send this traffic over it
unless
>>>> the primary link fails.
>>>>
>>>> What I usually do in a case like this is define a static route(s)
>>>> between the endpoints, give it an administrative distance lower than
>>>> OSPF's, and ABSOLUTELY NOT REDISTRIBUTE IT INTO OSPF. That way,
>>>> traffic will take the preferred path as long as it's up, but will
use
> >>> area 0.0.0.0 as backup if there is a primary path failure.
>>>>
>>>> >au
>>>> >
>>>> > -----Original Message-----
>>>> >From: Howard C. Berkowitz [mailto:hcb@gettcomm.com]
>>>> >Sent: Thursday, 3 October 2002 04:28
>>>> >To: ccielab@groupstudy.com
>>>> >Subject: Re: OSPF Design
>>>> >
>>>> >At 1:51 PM -0400 10/2/02, Peter Wodle wrote:
>>>> >>I wonder if the following OSPF Design is valid/workable?
>>>> >>
>>>> >>Have the area 0 with a no of routers. 1 ABR links area 0 to Area
1.
>>>> >>another ABR links area 0 to Area 2. So far no issues. But then we
>>>> >>have R12 that connects area 1 & area 2 togather i.e. R12 has one
>>>> >>interface in area 1 and one one interface in area 2. R12 has no
>>>> >>interface in area 0. So, it is an ABR (right?) but has no link to
>>>> >>area 0. Could this could lead to area 1 & area 2 exhange routes
via
>>>> >>this "backdoor" router?R12
>>>> >>
>>>> >>Can we do this? I can see it is bad design but...
>>>> >
>>>> >Not in the present standard or most (if not all) Cisco
>>>> >implementations. There is a proposal in the IETF OSPF Working
Group
>>>> >to do something close to it:
>>> > >http://www.ietf.org/internet-drafts/draft-ietf-ospf-mlinks-03.txt
>>
>>________________________________________________________________________
>>This message has been checked for all known viruses by the
>>CitC Virus Scanning Service powered by SkyLabs. For further information
>>visit
>>http://www.citc.it
>>
>>___
>>
>>_____________________________________________________________________
>>This message has been checked for all known viruses by the
>>CitC Virus Scanning Service powered by SkyLabs. For further information
>visit
>>http://www.citc.it
>
>
>________________________________________________________________________
>This message has been checked for all known viruses by the
>CitC Virus Scanning Service powered by SkyLabs. For further information
>visit
>http://www.citc.it
>
>___
>
>_____________________________________________________________________
>This message has been checked for all known viruses by the
>CitC Virus Scanning Service powered by SkyLabs. For further information
visit
>http://www.citc.it
This archive was generated by hypermail 2.1.4 : Tue Nov 05 2002 - 08:35:38 GMT-3