Silent Nets, CIDR, and Conservation of Routing Table Space Mark Knopper March 10, 1993 Merit has started a project to analyze the NSFNET Policy Routing Database (PRDB) to look for networks that are not being announced to the backbone. Enke Chen of Merit has been sending each regional or midlevel (AS administrator actually) a list of the "silent nets" for their autonomous system. Our goal is to prune out of the database any networks not being used and not expected to be used in the near future. This is important for a couple of reasons: 1) we are approaching a hard limit in the table size in the ANS backbone routers; and 2) storing information for the non-announced networks requires human resources and some router space resources since all of the configured nets are stored in the configuration file on each router. As of March 5, there are 10057 networks configured in the database. The number of silent nets for February was 1955, ie. 1955 networks which were in the database as of February 1 were never announced in the entire month. So far we have received requests to delete about 200 of the silent nets. The maximum number of nets that were announced to the backbone as of 2/28 was 7037. Historical growth in network announcements is summarized in the following table. MONTH MAX RATE(%) ===== ==== ====== 07/92 4596 08/92 4866 5.9 09/92 5070 4.2 10/92 5432 7.1 11/92 5772 6.3 12/92 6239 8.1 01/93 6654 6.7 02/93 7037 5.8 (Avg monthly growth rate: 6.3%) The interface forwarding tables on the ANSnet routers are currently configured to support 10000 destinations. In the near term, microcode changes will be deployed to support improved address compression in the forwarding tables which will support 12000 destinations. Later the gated software when deployed will support a number of enhancements that increase the forwarding table capacity. When Classless Inter-Domain Routing (CIDR) and Supernetting is available (target is June, 1993), regional and midlevel peer routers will begin announcing aggregated routing information to the backbone. The backbone will be configured to receive and redistribute aggregated routes to other networks that support the BGP-4 protocol. This will be possible since regionals/midlevels have been allocating network numbers to members and customers from contiguous blocks of network numbers allocated by the NIC. It is expected that this plan will significantly curtail the growth of routing table size for networks carrying full routing information. In the interim before aggregation can occur, we as regionals, midlevels and backbone operators must cooperate to conserve routing table size. We propose the following steps to help manage the problem, and would appreciate your feedback on them. Regional/Midlevels' Responsibilities: 1) Reply to the "silent nets" lists from Enke Chen and indicate your intent to delete any nets that are not planned to be announced in the next 30 days. 2) Send in delete requests to nsfnet-admin@merit.edu using the standard template.net. 3) Make sure you are using a CIDR block of class C net numbers obtained from the NIC for allocation to your member networks. Only send in requests for addition to the NSFNET database for those nets which will actually be used within 30 days. Merit's Responsibilities: 1) Merit will announce our intent to temporarily delete network numbers from the configuration files that have not been announced for 90 days. We will retain the nets in the database but will mark them as "inactive" and will not include them in the router configuration files. We will re-activate them at such time as the backbone routing table size limitation is resolved. We will also re-activate individual nets upon request. 2) If it would be convenient, Merit could set up a holding database so that network numbers can be submitted which would not actually be included in the router configuration files. The holding database could include all of the regular administrative and routing information associated with the network. Additional requests could be sent to Merit to have a network moved from holding status to active.
participants (1)
-
Mark Knopper