At 09:43 AM 4/5/2002 -0500, you wrote: >Hi, > >You have tried to post to GroupStudy.com's Professional mailing list. Because >the server does not recognize you as a confirmed poster, you will be required >to authenticate that you are using a valid e-mail address and are not a >spammer. By confirming this e-mail you certify that you are not sending >Unsolicited Bulk Email (UBE). > >PLEASE DO NOT SEND YOUR ORIGINAL MESSAGE AGAIN! BY CONFIRMING THIS EMAIL >YOUR ORIGINAL MESSAGE (WHICH IS NOW QUEUED IN THE SERVER) WILL BE POSTED. > > >By confirming this e-mail you also certify the following: > >1. The message does NOT break Cisco's Non-Disclosure requirements. > >2. The message is NOT designed to advertise a commercial product. > >3. You understand all postings become property of GroupStudy.com > >4. You have searched the archives prior to posting. > >5. The message is NOT inflammatory. > >6. The message is NOT a test message. > >To confirm, simply reply to this message. No editing is necessary. Once >confirmed, you will be able to post without additional confirmations. > > >Welcome to GroupStudy.com! > > >------ORIGINAL MESSAGE--------- > > >From [EMAIL PROTECTED] Fri Apr 5 09:43:38 2002 >Received: from usermail.com (www.usermail.com [208.239.240.90]) > by groupstudy.com (8.9.3/8.9.3) with ESMTP id JAA04437 > GroupStudy Mailer; Fri, 5 Apr 2002 09:43:38 -0500 >Received: from pvanoene-lt1.usermail.com (natsvc.juniper.net [207.17.136.130]) > by usermail.com (8.11.6/8.9.3) with ESMTP id g35EijQ20325 > for ; Fri, 5 Apr 2002 09:44:46 -0500 >Message-Id: >X-Sender: [EMAIL PROTECTED] >X-Mailer: QUALCOMM Windows Eudora Version 5.1 >Date: Fri, 05 Apr 2002 09:44:41 -0500 >To: [EMAIL PROTECTED] >From: Peter van Oene >Subject: Re: OSPF design [7:40269] >In-Reply-To: >Mime-Version: 1.0 >Content-Type: text/plain; charset="us-ascii"; format=flowed > >Please pardon the snipping (and top posting for that matter) Posted some >notes inline. > > > >Peter, when you say that the solution could involve "less specific > > >summaries" - do you really mean more specific summaries? Summarising less > > >drastically (e.g. summarising each site separately) isn't a good solution > > >in this particular case because it creates too much load in the core - > > >that's how we used to do it but it created other problems. > >Yes. Thanks for catching one of my ever more frequent brain farts :) I >definitely meant to suggest that using more specific summaries on the ABR's >would help. Possibly pinning up major aggregates to null0 for the entire >area and leaking appropriate specifics per ABR might help. However, one >would have to consider the impact on the core of both the additional type >3's and the additional processing required to track their state (and their >stability etc) > > > > >As you should be able to see, each of these can be valid assumptions > >depending on your network objectives. Peter, how does JunOS deal > >with this situation? > >JunOS behaves much like Cisco in that we'll advertise the summary so long >as we match a contributing specific. There is currently no additional >"conditional" type capabilities available. However, given the service >provider focus in JunOS, I tend to think that there hasn't been that much >pressure for type 3 handling enhancements. In these networks, OSPF >provides reachability toward loopbacks for IBGP peering and more >importantly, BGP next-hop resolution where path accuracy is pretty >important. Sub-optimal routing for transit traffic burns money :) Further, >LSDB's are generally kept as small as possible (no type 5's for example) >which minimizes the need for summarization from a router processing >perspective. If folks summarize at all, it's only for link addresses in a >pop. > >I actually prefer ISIS for use in networks of this nature as the >distribution of reachability information between levels of the hierarchy >tends to be less restrictive in most implementations. In JunOS (and IOS to >some extent), one can use policies (route-maps in IOS) to govern the flow >of information between areas instead of having to try and manipulate a >summarization knob. In this case, one can leak prefixes without worrying >about what summary range they fall into. Further, one can advertise >aggregates and leak various specifics at the same time which can also be >helpful in some cases. > > >What would be really nice is if Cisco extended BGP conditional > >advertisement to IGPs, and introduced a knob to have the default > >behavior overridden by conditional. > > > > >I think in this case I'll be going for the "protect against partitioning" > > >solution and bung in another cable. > >Wanted to voice my admiration for your verb selection here :) Bung is >definitely a cool way to describe a number of solutions I've seen in the >past. This one being far less bunged up than others I should add.
Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=40602&t=40602 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
