North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: OSPF multi-level hierarchy: Necessary at all?

  • From: Alex P. Rudnev
  • Date: Thu May 27 13:20:39 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 <[email protected]>
> >> To: [email protected]
> >> 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)