From: Paul Cosgrove (paul.cosgrove@heanet.ie)
Date: Wed May 21 2008 - 13:42:15 ART
Hi Yemi,
I wasn't trying to make a point about intra area routes vs inter area
routes, just about the handling of inter-area (summary) routes. In the
example where three routers form a triangle, connected using three
different areas, each router is receiving a summary route for the one
link it is not directly connected to. Provided each router has another
interface in area 0, and does not have a neighbor in that area 0, it
will still see the summary route as valid.
This rule is actually contained in RFC2328:
16.2. Calculating the inter-area routes
The inter-area routes are calculated by examining summary-LSAs.
If the router has active attachments to multiple areas, only
backbone summary-LSAs are examined.
In addition, summary routes are not forwarded between areas, they are
originated by ABRs due to network LSAs and ASBRs within a connected
area. This limits how far routes can propagate along the chain of areas
you described in your last email.
I see that the quote you mentioned from the RFC is correct, that it does
indeed specify that the backbone must be contiguous. In reality though
the routers have no way to know this; they only know that they have
received summary LSAs on a non-backbone link, and the inter-area routing
rule above determines whether or not they use such routes.
Regards,
Paul.
Salau, Yemi wrote:
> I agree, Intra-Area route is preferred to inter-area route, right?
>
> But what I'm saying is that, if you have Area0---Area2----Area0, and
> there is say x.x.x.0/24 in one Area0, and y.y.y.0/24 in another. Will
> the Middle Area2 router(s) still be able to ping x.x.x.0/24 &
> y.y.y.0/24? Will the Area0 Router on the Right be able to ping
> y.y.y.0/24 on Left Area0's Router? Will the left Area0 Router still be
> able to ping the right Area0's Router's x.x.x.x0/24?
>
> Ideally I will love to use this:
>
> R1-----R2----R3-----R4
>
> Say R1 is running Area0 to R2
> R2 is then running Area2 to R3
> & Finally R3 is running another Area0 to R4?
>
> After testing/labbing this scenario, I discovered R4 can't ping R2's
> interface in Area2, likewise R1 can't ping R3's interface in Area2
> Similarly, R2 can't ping R4's interface in Area0, likewise, R3 can't
> ping R1's interface in Area0.
>
> Looking deeper into the OSPF Database, on R1, you wouldn't find any link
> state entry in OSPF database for the R3/R4 network lan. Similarly, you
> wouldn't find any link state entry for R1/R2 network lan on R4. Could we
> then say that this is down to R1 "filtering" that entry off its OSPF
> database because of inter-area route?
>
> By the way, R2 has Router & Summary Network Link states for the R3/R4
> network, can ping R3's interface on this network, but can't ping R4's
> Similary, R3 has Router & Summary Network Link states for the R1/R2
> network, can ping R2's interface on this network, but can't ping R1's
>
> Maybe I'm not using the correct English to describe this, but I'm yet to
> find an RFC (still searching though, please forward me a link if you
> find one) that link the problems of discontiguos area0 to inter/intra
> area route preference. But what RFC did say is that "OSPF Area0 is
> responsible for distributing routing information btw non-backbone areas,
> the backbone must be contiguos. However it nee not be physically
> contiguous"
>
> Many Thanks.
>
> Yemi Salau
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Paul Cosgrove
> Sent: Wednesday, May 21, 2008 2:41 PM
> To: Salau, Yemi
> Cc: ahmed badr; Ina&Laurean; Miguel Trejo; Cisco certification
> Subject: Re: OSPF areas
>
> Hi Yemi,
>
> When you area using a single ospf process on each router, in order to
> have disconnected area 0s, they would have to be defined on different
> routers. Each router is making its normal route selection decisions
> based on the routes is receives, and they do not have an additional link
>
> state database.
>
> The problem with disconnected area 0s is not that OSPF gets confused,
> just that another rule starts taking effect if you also have active
> neighbors in multiple areas - you begin ignoring summary LSAs learned
> (from another ABR) via a non-backbone area.
>
> Connect three routers using three non backbone areas so that the routers
>
> form a single triangle. Then add a loopback interface on each router
> into area 0. You will still have full connectivity even though there
> are three disconnected area 0s. Then add a new router to any of the
> three existing area 0s...
>
> Paul.
>
>
> Salau, Yemi wrote:
>> No it's not, for the so called discontiguous networks, you can use
>> tunnel interfaces/vpn to bridge into the backbone area, be careful
>> though on the real environment.
>>
>> You don't want to have 2 Area0's do you, at least not what the RFC
>> recommends if you don't want to confuse the hell out of your OSPF
>> routers ... ie. which link-database to believe. So, you ideally also
>> want to "bridge" the two Area0s. What of if you're merging two
> different
>> companies' OSPF networks, well ... that's where BGP comes in handy,
> I'm
>> sure there are other ways to achieve this also.
>>
>> One thing I need to also note is that it's possible to have multiple
>> instances of a non-backbone area as long as they have ABR connecting
> to
>> the Backbone area, and you don't need a virtual link in this case.
>> Although, the Design/Architect guys would normally object to this, as
>> it's suboptimal and can cause issues. Still looking/digging through
> the
>> RFC that mitigates against the fundamental design principles for this
>> though.
>>
>> So if you have Area2-------Area0------Area2 This needs no virtual
>> link/tunnel interfaces, and will work, I've done it several times in
> my
>> office; but is not best practise from design perspective
>>
>> But if you have Area0------Area1-------Area2 You have to hook Area2
> up
>> back to Area0 (hope this make some sense); Golden OSPF Area Rules: All
>> areas must have a link/leg in Area0, and there should only be one
> Area0
>> Many Thanks
>>
>> Yemi Salau
>>
>> -----Original Message-----
>> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
>> ahmed badr
>> Sent: Wednesday, May 21, 2008 12:53 PM
>> To: Ina&Laurean
>> Cc: Miguel Trejo; Cisco certification
>> Subject: Re: OSPF areas
>>
>> In cisco CCIE Exam certification guide, the author recommends that if
>> you
>> have discontiguous or partitioned area, you should link it by Virtual
>> link.
>> this is to have the same LSA database in the area.
>> I LABed it without virtual links and it worked. *is this a MUST??*
>>
>> Also the more important question is that: what if the discontiguous
> area
>> is
>> area 0. i.e I have
>> area 0 ---->area 5 ----> area 0
>> should I connect area0s together using a virtual link?
>> I also LABed that and it worked ok without virtual links. *is this a
>> MUST
>> too?*
>>
>>
>>
>> 2008/5/15 Ina&Laurean <ina.laurean@gmail.com>:
>>
>>> Depending on IP address space on Area 5 you may experince problems if
>> you
>>> want to summarize.
>>> A single summary route for Area 5 won't work if you don't link the
> two
>>> sections together.
>>>
>>> Laurean
>>>
>>>
>>>
>>> On Wed, May 14, 2008 at 9:31 PM, Miguel Trejo <mike.trejo@gmail.com>
>>> wrote:
>>>
>>>> The main reason behind this working with no problem is that LSA
>> doesn't
>>>> carry out area information once they are injected as inter-area
>> routes. So
>>>> when they reach the "other"area 5 that ABR doesn't care about the
>> original
>>>> area this belonged to, only about the ABR that originated the route
>> as the
>>>> routers inside the "other" area 5 only care that this ABR knows how
>> to
>>>> reach
>>>> the remote networks. OSPF is alink state protocol only at area
> level,
>> when
>>>> talking about routes to networks in other areas we rely on what the
>> ABR
>>>> says, pretty much like distance vector.
>>>>
>>>>
>>>> On Sat, May 10, 2008 at 3:51 PM, ahmed badr
> <eng.ahmedbadr@gmail.com>
>>>> wrote:
>>>>
>>>>> ok I got it. thnx
>>>>>
>>>>>
>>>>>
>>>>> 2008/5/10 Ibrahim kabir <kebramccie@live.com>:
>>>>>
>>>>>> yeah jason i meant OI i.e inter-area routes. The terms keep
>> confusing
>>>> me
>>>>>> inter(btween areas) and intra(within same) area.
>>>>>>
>>>>>> Kabir K Ibrahim
>>>>>> B.sc CCNA CCNP CCDP CCNP MCP
>>>>>> +2348036477283
>>>>>>
>>>>>>
>>>>>>> Date: Sat, 10 May 2008 08:23:43 -0600
>>>>>>> From: madsen.jason@gmail.com
>>>>>>> To: kebramccie@live.com
>>>>>>> Subject: Re: OSPF areas
>>>>>>> CC: eng.ahmedbadr@gmail.com; ccielab@groupstudy.com
>>>>>>> correct, a virtual link doesn't seem appropriate here. Kebram,
>> I
>>>> think
>>>>>> you
>>>>>>> meant that the discontiguous area 5s are seeing each other as
>>>>> inter-area
>>>>>>> routes and not intra-area routes, right? each area 5 should end
>> up
>>>>> being
>>>>>>> it's own unique area unless a tunnel is used.
>>>>>>>
>>>>>>> Jason
>>>>>>>
>>>>>>> On Sat, May 10, 2008 at 6:15 AM, Ibrahim kabir
>> <kebramccie@live.com
>>>>>> wrote:
>>>>>>>> Ahmed,
>>>>>>>>
>>>>>>>> neva thought about this type of design at all. bt i labbed it
>> and
>>>> it
>>>>>> worked
>>>>>>>> without gre or virtual-links. The main thing to look out for
>> is
>>>> that
>>>>>> each
>>>>>>>> area
>>>>>>>> should be connected to the backbone area (Area 0). and
>> looking at
>>>>> your
>>>>>>>> diagram the condition is true. only that the discontigious
>> area
>>>> 5's
>>>>> see
>>>>>>>> each
>>>>>>>> others routes as intra-area routes.
>>>>>>>> Lab it and see for urself.
>>>>>>>> cheers,
>>>>>>>> kebram
>>>>>>>>
>>>>>>>>
>>>>>>>>> Date: Sat, 10 May 2008 13:30:06 +0300> From:
>>>>> eng.ahmedbadr@gmail.com
>>>>>>>> To:
>>>>>>>> ccielab@groupstudy.com> Subject: OSPF areas> > Dears,> >
>>>> according
>>>>> to
>>>>>> the
>>>>>>>> diagram below, should I link area 5 in the two sides by any>
>> mean
>>>> (eg
>>>>>>>> tunnel)
>>>>>>>> or it should work fine.> > > > Area5 Area0 Area5>
>>>> -------------------
>>>>>>>> ----------- ------------------> - - - - - -> -
>> --R1-----------
>>>>>>>> R2------------R3------------R4-- -> - - - - - ->
>>>> -------------------
>>>>>>>> ----------- -------------------> > >
>>>>>>>>
> _______________________________________________________________________>
>>>>>>>> Subscription information may be found at: >
>>>>>>>> http://www.groupstudy.com/list/CCIELab.html> > > >
>>>>>>>>
>> _________________________________________________________________
>>>>>>>> Invite your mail contacts to join your friends list with
>> Windows
>>>> Live
>>>>>>>> Spaces.
>>>>>>>> It's easy!
>>>>>>>>
>>>>>>>>
> http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.a
>> spx&m
>>>>>>>> kt=en-us
>>>>>>>>
>>>>>>>>
>>>>>>>>
> _______________________________________________________________________
>>>>>>>> Subscription information may be found at:
>>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>>
> _______________________________________________________________________
>>>>>>> Subscription information may be found at:
>>>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> ------------------------------
>>>>>> Invite your mail contacts to join your friends list with Windows
>> Live
>>>>>> Spaces. It's easy! Try it!<
> http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.a
>> spx&mkt=en-us
>>>>>
> _______________________________________________________________________
>>>>> Subscription information may be found at:
>>>>> http://www.groupstudy.com/list/CCIELab.html
>>>>
> _______________________________________________________________________
>>>> Subscription information may be found at:
>>>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>
>
-- HEAnet Limited Ireland's Education & Research Network 5 George's Dock, IFSC, Dublin 1, Ireland Tel: +353.1.6609040 Web: http://www.heanet.ie Company registered in Ireland: 275301Please consider the environment before printing this e-mail.
This archive was generated by hypermail 2.1.4 : Mon Jun 02 2008 - 06:59:18 ART