OSPF multi-level hierarchy: Necessary at all?
Alex P. Rudnev
alex at Relcom.EU.net
Thu May 27 17:11:39 UTC 1999
> Yeah, in this case the sub-area 0.1.1's topology would be hidden
> from the 0.1's routers and vice versa.
>
> > (moreobver, VL can't be used with CISCO's at all because CISCO
> >don't allow to control router-id directly and you can't build VL withouth
>
> Well, you do know that you can create loopback interfaces and the router-ID
> will be the highest one among them. Say you do:
>
> int lo 0
> ip address 255.1.1.1
Hmm. Try yourself. Then, the quote from my config:
!
interface Loopback98
description Router-ID
ip address 223.255.254.118 255.255.255.255
I even proposed to declare 223.255/16 as private block -:).
Looks like doing the sex on the top of the tree - to make the life more
complex...
> > router ospf 111
> > router-id 1.2.3.4
>
> Actually there is a DDTS on the wish-list, but it is still not implemented for
> some reason, let's hope it will be....
I can imagine the ONLY reason for such SIMPLE thing... And it's in TODO
for a years - now everyone know the trick you showed above...
> >network and name his _AREA 1.2.3.4_ with the strict filtering on the
> >border.
>
> I was thinking about it as well. One could configure some area range
> as a "discard" one, effectively saying that all routes dropping into the
> range should be ignored instead of announced in a summary-LSA.
I am not sure if it's the same what I was saying, but approx. it is. We
need good inter-area routing with the distribute-control over it. We can
control exported prefixes by -STUB AREA- definition and/or
summarisations, but we can't control incoming routes,
Btw, do you know _GATED_? It allow to control IMPORTED routes, but for
OSPF_ASE_ routes only. I don't think it's possible to control route
import anywhere except area borders (for the OSPF case), but why don't do
it on the area boundaries?
> >This is reason why ISP don't like OSPF and such protocols - they can be
> >used for the inter-router routing, but they can't be used to connect with
> >the customers (no, I can run 10 different OSPF processes and re-advertise
> >routes - one more headache for the network admins).
>
> Actually, you can use NSSA, but doesn't allow for filtering either.
Sorry, what's NSSA?
> >PS. From ISP's point of view. What I'd like.
> >
>
> [snip: got your wish, Alex]
>
> >3) Moreover, why can't I determine different BGP AS numbers for the boths
> >ISP and CUST OSPF zones.
>
> who said you can't ? or I'm missing something?
Yes, I can. But no one (except me) know about it -:).
I mean some mixturing of OSPF and BGP properties. They are mixtured
already - OSPF tag can hold 1 BGP paths. Through I don't think it's
important for now.
>
>
> Alex.
>
> >
> >
> >
> >
> >On Thu, 27 May 1999, Alex Zinin wrote:
> >
> >> Date: Thu, 27 May 1999 19:36:13 +0400
> >> From: Alex Zinin <zinin at amt.ru>
> >> To: nanog at merit.edu
> >> Subject: OSPF multi-level hierarchy: Necessary at all?
> >>
> >>
> >> Hello,
> >>
> >> We're currently discussing necessity of multi-level hierarchy
> >> in OSPF on the WG mail list.
> >>
> >> The idea is to implement SPF-based interarea routing
> >> with more than two levels of topology abstraction and
> >> route aggregation (we have two levels in OSPF at the
> >> moment level1 being intra-area routing and level2 being
> >> the inter-area one).
> >>
> >> I have some thoughts on how this could be done,
> >> but the main question is whether there is a demand
> >> for it or not.
> >>
> >> Everyone is really welcome to share opinions.
> >>
> >> Thanks in advance,
> >> ------------------------------------------------------------------
> >> Alex D. Zinin, Consultant
> >> CCSI #98966
> >> CCIE #4015
> >> AMT Group / ISL
> >> Cisco Systems Gold Certified Partner
> >> http://www.amt.ru
> >> irc: //EFNET/#cisco, //irc.msn.com/#NetCisco [Ustas]
> >>
> >>
> >>
> >
> >Aleksei Roudnev, Network Operations Center, Relcom, Moscow
> >(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41,
> N 13729 (pager)
> >(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
> >
> >
> >
> ------------------------------------------------------------------
> Alex D. Zinin, Consultant
> CCSI #98966
> CCIE #4015
> AMT Group / ISL
> Cisco Systems Gold Certified Partner
> http://www.amt.ru
> irc: //EFNET/#cisco, //irc.msn.com/#NetCisco [Ustas]
>
>
Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
More information about the NANOG
mailing list