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=40591&t=40269 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
