>Comments below... > >Thanks, >JMcL >----- Forwarded by Jenny Mcleod/NSO/CSDA on 05/04/2002 03:25 pm ----- > > >"Howard C. Berkowitz" >Sent by: [EMAIL PROTECTED] >05/04/2002 02:09 pm >Please respond to "Howard C. Berkowitz" > > > To: [EMAIL PROTECTED] > cc: > Subject: Re: OSPF design [7:40269] > > >Jenny, > >First, I apologize for not giving more of a response earlier, but >it's been a crazy few days...three people in my office, including >myself, have had close relatives/friends in surgery and there have >been a lot of distractions. >JMcL: Err.. yes, I can see how that would be distracting. Thanks for >taking the time for this. /JMcL > >I'm going to post and elaborate a bit on some observations I sent to >you earlier, but I'm interested in why and how you have so much core >trouble. Could you give us an idea of the number of routes and of >routers, and the stability of both, in the non-backbone areas? Are >the ABRs and any pure backbone routers doing any other >processor-intensive tasks? >JMcL: The non-backbone areas (about twenty of them) vary quite a bit in >size as they map (or did once) to geographic/administrative regions. As >they consist of multiple geographically-dispersed small offices with two >routers each (for redundancy), they are pretty router-rich - the smallest >area has 20 routers and 21 networks, the largest (I think) has 52/49 in >area x.1.0.0 and 29/27 in x.2.0.0. >While they aren't too bad for stability, the sheer number of sites means >that something is usually playing up somewhere :-(
Those numbers don't sound too bad. But I think the villains are below. >The ABRs mentioned in the problem below aren't doing anything very >exciting, but some of the core routers have a fair load. There are >currently 50 routers in the backbone area - the backbone area is spread >across two data centres and the ABRs mentioned (which are in sites around >the country - they have WAN connections to the data centres, not LAN). First, while I know of backbone areas that do have hundreds of routers (Pat Murphy at the US Geological Survey--but he's also an OSPF protocol developer), generally it's a bad idea. The larger cores that I've built recently had certainly no more than 20-32 routers. Given you've got two data centres (see, I can spell in Oz), a natural split would be to center one area 0.0.0.0 on each data center, and have local areas (i.e., nonzero) even at the physical data centre. Why should such things as server-to-server backup, etc., be traversing the core? Without knowing your Internet connectivity requirements, you could link the backbone areas (i.e., two OSPF domains) with multiple static routes (adding floating for backup). >Core routers in the data centres also support CIP cards, may be ABRs for >other areas (we're not very good at "pure" backbone routers ;-), and until >recently terminated stacks of DLSw circuits. This is bad news. And remember, in OSPF (as opposed to ISIS), the _router_ is not in any specific area. It is the _interfaces_ that are in an area. If, hypothetically, you were to create a local area in the data centre for the IBM machines, all it would take is changing the network statements for the interfaces going to that area. Incidentally, there's a sneaky cost saving you can use for CIP cards. 7000 series routers support them, but don't have very fast CPUs. But you don't need a fast CPU to support the CIP itself, because it has its own fast CPU. You do need substantial CPU power for terminating the IBM tunnels. A trick I used a good deal (and by the equipment types, you'll see this is fairly old), is to put the CIP into a 3-slot 7010, or two if I needed redundancy. I then ran the fastest available medium -- mostly FDDI at the time -- back to 4500/4700 series routers, which were the first RISC processor routes. They terminated RSRB, did IBM conversions, and all the other things that were processor intensive. Given that there was a shared medium, I could use multiple 4x00s if necessary. >We also have adjusted the OSPF timers throughout the network to make them >more sensitive - this because we had SNA traffic (first via RSRB, then >DLSw) and we wanted fast failover. DLSW doesn't have the local acknowledgement problem of RSRB. You may be able to start returning the timers to the normal values. >This worked, but does make OSPF a bit >more inclined to hysteria when there are links flapping. This is now >being phased out as we have moved to TN3270, but the timers haven't all >been changed back yet. >We possibly could go back to advertising each site separately now, since >we've reduced the load in the core by various other methods, but I >wouldn't want to battle the layer 8 issues to do it. >/JMcL > >There can be creative solutions if you think outside the traditional >OSPF box. Hypothetically, if your address plan split geographically, >it might even be an idea to have an eastern and western OSPF domain >(i.e., an area 0.0.0.0 and a set of nonzero areas), linked by >redundant static routes or possibly BGP. The latter is especially >useful if you have multiple ISP connections. Remember also that a >router can have multiple OSPF processes, so the same router could >participate in different domains. I assume your user population >stretches across at least three time zones, so this sort of redesign >might localize some core thrashing. >JMcL: I don't think we have too much time-based thrashing - even though >most of our population is in the same time zone (especially in winter). >Splitting our core is something that has frequently been considered, and >in fact it was originally split, with very ugly redistribution using IGRP, >which caused more problems than it solved. Don't think of using a dynamic IGP to link cores. Static routes or BGP. >As I mentioned, we may be >doing a major redesign in the medium term and this is something we can >consider again. >/JMcL Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=40582&t=40269 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
