North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: OSPF multi-level hierarchy: Necessary at all?
> 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 188.8.131.52 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 184.108.40.206 > > 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 220.127.116.11_ 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)