Ok, good scenario. Assuming your network has grown to a point where type 5's are stressing the AS, some scaling effort must take place. There are a number of poorly scaling cludges to this type of scenario outside of OSPF, but I've seen NSSA areas used here with some success. The net result is that your individual areas have no awareness of the more specifics in other areas which isn't bad assuming your aggregation strategy is clean as they can simply follow the aggregates put out by the ASBRs. Within the area, the type 7's provide enough info for intra area routers to make informed decisions re paths out toward the customer networks. Your backbone will naturally see all external info which shouldn't be an issue as a mid size ISP should have some good routers therein. The key point is again that type 5's are unmodified at area borders. They in fact flood untouched throughout the AS. Hence, unlike normal summarizes, 5's aren't repackaged at each ABR before they hit other areas. For that reason, you cannot control their flooding scope once they hit the domain without using area modifications like stubinness. Interestingly, due to type 7's needing to be converted to 5's by ABR's, they are repackaged before entering the backbone and thus can be summarized via area-range like commands at ABR's. Another reason why this is a viable solution to your situation. I'm also curious how you can do this with a Juniper? Can you provide a quick outline? Thanks Peter *********** REPLY SEPARATOR *********** On 7/18/2001 at 4:54 PM [EMAIL PROTECTED] wrote: >okay, let me give you a scenario: > >say you have a mid-sized ISP network - a size such that it's not really >worth going with confederations, etc. > >say that you have a couple of PoPs and a couple of colo/hosting centres. > >let's suppose that we want to run an area0 backbone between the sites, and >have the infrastructure of each site be an OSPF area. > >a bunch of your customers want to multi-home within a particular location >to >multiple switches/routers, and since you don't really want the customer to >participate in your IGP (auughhh) you have to statically route them, and >redistribute the routes within the area. summarizing lsa type-5s at each >ASBR is out, as a customer could drop their uplink to that ASBR, without >the >summarizing ASBR dropping the aggregate which would kinda kill their >traffic >- good ol' CEF keeps a-load-balancing half the traffic to the router >without >a route... ;-) > >hence, this is why I want full specifics intra-area, and aggregate-only >inter-area. > >I could do it on a Juniper dammit... > >take care :-) > >Andy > >Peter Van Oene wrote on July 18, 2001 at 9:14 PM: > >Ahh, I did indeed mean to suggest that you filter at the ingress ASBR (the >one that creates the type 5 in the first place) Type 5's are unmodified >throughout the AS and thus there is no mechanism within the protocol to >control their flow between areas. However, I'm confused as to why you need >the full specifics advertised to the area and only the summary to the rest >of the AS. Even if you have multiple customer networks attached to the >ASBR, you are still going to pull traffic destined toward them to the ASBR >via the aggregate. What are you gaining by not using the summary address >command on the ASBR? > > >*********** REPLY SEPARATOR *********** > >On 7/18/2001 at 3:34 PM [EMAIL PROTECTED] wrote: > >>hi all, >> >>thanks for all the replies - gave me some stuff to chew over >> >>have been looking into this some more - it's still bugging me. >> >>my investigations revealed: >> >>* making the area stub or total-stub will not work as type-5s are not >>permitted in the area. all routers set E=0 in the options field to denote >>stub, and won't talk to non-stub neighbors. no fooling them apparently... >> >>* summary-address will only summarize external routes originated on that >>local router - hence cannot use to summarize for non-local type-5s >> >>I cannot believe that it is not possible to do something as simple as this >>without resorting to multiple OSPF instances and redistributing between >>them!! >> >>cheers >> >>Andy >> >>Peter Van Oene wrote on July 13, 2001 at 6:43 PM: >> >> >>> Making the area stub will explicitly deny the use of type 4/5 in the >>area, >>> hence, this should not work. Summarization at the ABR would make the >>most >>> sense to me. Odd that it doesn't seem to work. >>> >>> pete >>> >>> *********** REPLY SEPARATOR *********** >>> >>> On 7/12/2001 at 6:40 PM John Neiberger wrote: >>> >>> >Could you accomplish this by making the area containing the ASBR a >>> >stubby area? IIRC, you can put an ASBR inside a stubby area but the >>> >Type-5 LSAs will not leave the area. I'm not sure about that, but I'd >>> >swear I read that somewhere recently. >>> > >>> >Okay, I just checked this in Giles, 2nd edition. According to him, the >>> >above is true. But who knows if it works in the real world. >>> > >>> >Good luck! >>> > >>> >John >>> > >>> >>>> "[EMAIL PROTECTED]" >>> > 7/12/01 1:58:11 PM >>> >>> >hi all, >>> > >>> >have a problem that has been nagging at me for a good long time now... >>> > >>> >say you have a pair of ABRs sitting at an OSPF area boundary, and an >>> >ASBR is >>> >originating Type-5 LSAs from inside the non-backbone area. Is there an >>> >easy >>> >way to suppress the propagation of the type-5s outside the area? I >>> >would >>> >have a range statement on the ABRs to advertise the area aggregate, I >>> >just >>> >want to suppress the more specifics. >>> > >>> >I have tried using 'distribute-list out ' which would do it for >>> >me, but for some reason IOS won't allow this with OSPF: >>> > >>> >router(config)#router os 1 >>> >router(config-router)#distribute-list 1 out FastEthernet 0/0 >>> >% Interface not allowed with OUT for OSPF >>> >router(config-router)# >>> > >>> >I suppose that allowing this could potentially screw up routing if >>> >done >>> >without some care, but JunOS lets you do exactly this sort of thing - >>> >you >>> >can produce some wacky policies, but at least you have the option ;-) >>> > >>> >btw - I know I could prolly do this with multiple OSPF instances and >>> >redistribute between them, but I *really* don't want to get into this >>> >level >>> >of complexity. >>> > >>> >thanks in advance - this one has been driving me mad >>> > >>> >Andy Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=12894&t=12894 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
