|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Scaling Existing IGP Administration (was) Re: IGPs in use
The "IGP's in use" thread is diverging into several interesting subthreads, so I thought I'd start changing the title. There seems to be one thread on requirements/properties of a future IGP that Does The Right Thing: Sean Doran eloquently commented, in respect to something based on IS-IS, >Frankly, though, I'm hoping that rather than locking themselves >in the room to "improve" IS-IS, the Obvious People lock themselves >into a room and build something else instead (which they might simply >call IS-IS, even if it isn't. Been there, done that, called it BGP). May I propose a name for this? IS-IS's New Technology, or ISNT? As a followon to the T-shirt "IS - IS = 0" this could be "It ISNT IS-IS". My focus in this subthread is working with what we have now, a somewhat different emphasis. A rough example follows. At 3:18 PM -0700 10/13/98, Tony Li wrote: >[email protected] (Howard C. Berkowitz) writes: > >> When I gave my OSPF tutorial at NANOG in June, I stressed OSPF shouldn't be >> thought of purely as a 2-level hierarchy with a routing domain consisting >> of an area 0 and a set of nonzero areas. Some of the OSPF scaling >> problems I see, and these are probably equally likely in IS-IS, come from >> people trying to put everything into a single OSPF routing domain. Aside >> from performance issues, this can become a network administration nightmare. >> >> Splitting the interior network into several IGP routing domains, and >> linking these with a backbone-of-backbones, helps both performance and >> administration. The backbone group doesn't need to be concerned with LAN >> installations in a POP or customer site. Depending on the particular >> network, you might link IGP routing domains with: >> >> -- static routes >> -- iBGP, putting all IGPs in a single AS >> -- iBGP and eBGP in a confederation >> -- Hybrid layer 2/3 techniques, such as linking IGP-routed domains >> to internal layer 2 "superhubs" >> >> How much IGP support you need will depend on your network. A large >> enterprise, or a provider of both connectivity and content, will probably >> need more IGP stuff than a pure connectivity provider. > > >Howard, > >Yes, those sound like a list of administrative nightmares. ;-) Or a lucrative dream for the right sort of consultant? :-) [not me!] > >Wouldn't it be much easier to make use of a three or four level >hierarchical IGP? As you'll see in the example below, is looking at this purely from an IGP perspective the whole issue for ISPs? I've sketched out some administration tools/procedures below that consider operational requirements other than the routing alone. No argument that it would be easier if everything were picked up dynamically by a new protocol -- but I was focused on what is commercially available now. As you've pointed out many times, static routes have a distinct role at the edge (and other places). Pending the deployment of more general hierarchical protocols, and supporting mechanisms such as MPLS, I was trying to focus on short-term things. My first law of network design is to try never to enter an address more than once, and locally written scripts and simple programs can help enormously with this. I grant that one cannot assume the average enterprise necessarily has any programming capability. Yet most ISPs and integrators do. I'd like to throw out an example how some simple programming can minimize administrative work. Obviously, there are higher-end packages that can do some, but not all of this. Consider the fundamental requirement to manage one's address space. Let's say you are an ISP, and decide to offer /28 blocks to small customers, with a /30 for single-homed connectivity to each of them. Initially, you plan for 128 such customers, so you obtain a /21 for the small LANs and a /23 for the LAN access. You have some number of edge routers that have a single active path to your distribution/backbone level. By single active path, I include load-shared links and on-demand backups. The distribution tier routers do run a dynamic IGP and have multiple paths. Assume you have four distribution routers servicing 32 users, so the router has a /23 for LANs and a /25 for WANs. Set up blackhole static routes to each of these blocks, and redistribute them into the IGP. A rough example follows. When you set up a new customer, have scripts/programs that do the following: 1. Create a customer entry in your database (which might be a spreadsheet) Capture: the DLCI and physical serial interface ID of the customer's PVC at the distribution router end basic DNS information, such as the customer domain, the mail exchanger, etc. You'll have string variables already defined with your domain name, etc. Fill in standard host names if desired, such as www.customerdomain. 2. Assign the next available /28 and /30. Create integer variables with the prefix values of both: lanPrefix and wanPrefix 3. Assuming a single frame link between the core and distribution routers, generate the statements, using an ipAddr function that outputs a string containing a dotted decimal address for an input 32 bit integer: ! for the edge router ip route 0.0.0.0 0.0.0.0 ipAddr(wanPrefix + 1) ! for the distribution router, which is redistributing static ip route lanPrefix 255.255.255.240 ipAddr(wanPrefix + 2) int s(whatever).DLCI ip addr ipAddr(wanPrefix + 1) 255.255.255.252 ! assuming you want DNS names for your router interface, ! generate for your DNS as appropriate... <interface-name-convention> IN A ipAddr (wanPrefix + 1) (wanPrefix + 1) IN PTR <interface-name-convention> <interface-name-convention> IN A ipAddr (wanPrefix + 2) (wanPrefix + 2) IN PTR <interface-name-convention> ! user router interface, using a convention of the router interface ! is the first host. I like to use a convention of it being the last. <interface-name-convention> IN A ipAddr (lanPrefix + 1) (lanPrefix + 1) IN PTR <interface-name-convention> ! MX record as appropriate ! user host records as appropriate ! generate access lists, access server commands, firewall commands, ! etc. as appropriate for your local policies. 4. Load the generated configuration statements into the appropriate router config files. There are any number of ways to do this, and your local policies will dictate whether you replace or merge.
|