The following document is a collection of Frequently Asked Questions about CIDR. This document is not meant to be a networking/routing guide and tutorial. Where appropriate pointers to other documents of a more general nature have been mentioned.
If you have any questions you would like added, please send them to the editor mentioned below:
Hank Nussbacher (Tel Aviv University and IBM Israel) hank@vm.tau.ac.il or hank@ibm.net.il
If you would like to "discuss" items from this FAQ please send your mail to cidrd@iepg.org
This FAQ is being distributed to the following groups and lists:
To retrieve the most up-to-date version of this document:
CIDR stands for Classless Inter-Domain Routing and is documented in RFC1517/1518/1519/1520. CIDR is an effective method to stem the tide of IP address allocation as well as routing table overflow. Without CIDR having been implemented in 1994 & 1995, the Internet would not be functioning today.
Basically, CIDR eliminates the concept of class A, B, and C networks and replaces this with a generalized "IP prefix". CIDR can be used to perform route aggregation in which a single route can cover the address space of several "old-style" network numbers and thus replace a lot of old routes. This lessens the local administrative burden of updating external routing, saves routing table space in all backbone routers and reduces route flapping (rapid changes in routes), and thus CPU load, in all backbone routers. CIDR will also allow delegation of pieces of what use d to be called "network numbers" to customers, and therefore make it possible to utilize the available address space more efficiently.
See question #6 below for details on "IP prefix"s.
ASN stands for Autonomous System Number and acts to merge many networks into a logical domain.
BGP stands for Border Gateway Protocol and is the de-facto standard for routing between Autonomous Systems in the Internet. All communications between Internet Service Providers (ISP) is handled via BGP4 which supports CIDR.
The routing tables in the Internet have been growing as fast as the Internet and the router technology specifically and computer technology in general has not been able to keep pace. In December 1990 there were 2190 routes and 2 years later there were over 8500 routes. In July 1995 there are now over 29,000 routes, which require approximately 10 MB in a router with a single peer. Routers at interconnection points (or multi-homed hosts doing full routing with many peers) receive these routes from several peers, and need several dozen megabytes of RAM (and the appropriate CPU horsepower) to handle this. A list of those routers that can handle this appears at the end of this question. Routers with 64MB of memory have the capacity for approximately 60,000 routes after which some routes will just have to be left out of the global routing tables, and the more likely ones to be left out are routes covering small pieces of address space.
Without the CIDRization work that has gone on for the past 2 years the routing tables would be in excess of 65,000 routes. By CIDRizing you help the Internet reduce the routing overload as well as increasing the liklihood that in the future your routes will be carried by all ISPs.
The major benefit of CIDR is to allow for continuous, uninterrupted growth of the Internet. For a significant percentage of sites connected to the Internet the value of the Internet increases with the total number of sites connected to the Internet. Therefore, taking steps needed to allow for continuous uninterrupted growth (like CIDRizing, or renumbering) is beneficial to such sites.
The routers today that are available to handle the full routing table are:
The following example creates 2 aggregates and suppresses any more specific addresses that may be contained within those aggregates. The access-list causes only those nets to be distributed as listed, and not any others that may exist in the BGP routing tables.
Another method might be:
An alternate method is via network and route statements:
In this case, only those routes explicitly mentioned in "network" statements will be announced with BGP. For these routes to be announced, there has to be a corresponding route in the IP forwarding table, thus the need to create the static routes. The static routes will also serve as "pull-ups" for the route advertisements and thus prevent route flapping: these routes will always be announced with BGP by this router. Note that as long as more specific routes exist internally in your network, these will be used in preference to the static "less specific" route entries (longest prefix matching is being used).
A good rule to follow is to never redistribute IGP learnt routes directly into BGP, but to rather use network or aggregate-address statements. And if you must redistribute dynamically learnt IGP routes into BGP, you MUST use filtering.
The reasons for this advice are several, some of which are:
This refers to the number of bits of the network part of the IP address. A former class B may appear as 172.50.0.0/16, which is the same as 256 class C's which can appear as 192.200.0.0/16. A single class C appears as 192.201.1.0/24. These "things" are often called an "IP prefix", which consists of an IP address and a mask length. The mask length specifies the number of leftmost contiguous significant bits in the corresponding IP address. Thus, an IP prefix with a prefix length of 15 (denoted /15) covers the address space of 128k IP addresses, and a /17 covers the address space of 32k IP addresses.
Here is a table of the more popular CIDR blocks:
| CIDR Prefix | # of former class C nets |
|---|---|
| /28 | 1/16 |
| /27 | 1/8 |
| /26 | 1/4 |
| /25 | 1/2 |
| /24 | 1 |
| /23 | 2 |
| /22 | 4 |
| /21 | 8 |
| /20 | 16 |
| /19 | 32 |
| /18 | 64 |
| /17 | 128 |
| /16 | 256 = 1 class B |
| /15 | 512 |
| /14 | 1024 |
| /13 | 2048 |
| /12 | 4096 |
In general, advertising a prefix covering less address space than a /24 prefix will probably not get into the global routing tables, and global Internet connectivity is less likely to happen. Note that for you as an administrator of an AS, it is a good idea to announce as few prefixes as possible and to utilize the address space as much as possible.
A more comprehensive table came out in December 1995 as:
RFC1878: Variable Length Subnet Table For IPv4
No you do not need to carry the full Internet routing table. If you are single-homed, meaning you have a single connection to an ISP, then all you need to do is point a default route to the ISP and tell your ISP not to send you the full routing table. If you are multi-homed, you will want to know which nets to route via connection A and which nets to route via connection B. The easiest way to do this is to request a partial routing table from one ISP - with those nets that are closest to them, and default everything else to the other ISP. This way your routing tables need not contain the entire Internet universe but only a small subset.
The closer you get to the hub or nexus of the Internet, the larger your routing tables need to be. For example, those connected to public exchange points (like the NAPs, CIX, STIX, LINX, dGIX) in general, carry full routing tables and run without a default route.
In principle there is nothing to stop you. The responsibility falls on both ends of the BGP link - you are responsible to filter what you announce and the receiving end - if it has its act together - filters also what it *thinks* it should be hearing from you so as prevent mistakes on your part. Those sites that do not work with access lists and filters and just readily accept what is sent to them are just waiting for a problem to happen.
Filtering can either be done at the IP network level or at the BGP path (BGP orgin AS) level. See question 20 below for details on a tool to assist in filtering.
Sites that move from one ISP to another, and who had been allocated addresses from their original ISP's CIDR block, in all likelihood will have to return those addresses as part of the move. The reason is to keep the number of prefixes in the global routing system within the limits of current technology.
For further hints and procedures for renumbering, see the PIER (Procedures for Internet/Enterprise Renumbering) homepage.
There are two aspects to the answer:
1) Real (BGP) world: Given there are several AS's sharing addresses out of a /16 prefix, every AS should advertise exactly those prefixes which it is really originating. However, if there is one AS "originating" a significant majority of this address space, the concerned AS's might agree that this one and only advertises the /16 and all others their more specifics. The more specifics always take precedence over the less specific.
2) Routing registry: The registry DB, of course, should always reflect reality. If in the above example the AS's agree on the "big AS" announcing the /16, the "big AS" should document with the route-object that it's not really originating the whole aggregate by using "hole" attributes (see ripe.181, 5. The Route Object).
It is strongly discouraged to redistribute IGPs into BGP, because local IGP configuration errors might easily corrupt routing information of the whole Internet. If, however, you have to do it anyway, you must use strict distribute-lists with explicit permits (or route-maps) for redistribution. Here is an example for a Cisco configuration:
This example would generate one route 192.168/18 and one route 172.16/15 if any of the contained networks is in the IGP.
No damage can be done if the non-CIDR peer does not further announce your specifics to the global Internet. If your non-CIDR ISP does announce your specifics to the global Internet those specifics will have preference over the less specifics and therefore all traffic to you will get routed through the non-CIDR ISP.
Proxy aggregation should only be done with great care and should be avoided if you are not single-homed ! If you are single-homed ask your ISP.
Others may proxy aggregate over your address range without your consent, and send your traffic over paths/links not of your choosing. Use of Routing Registries may help to identify and correct these problem areas.
Routers that are capable of handling CIDR are:
There are actually three ways to solve this particular problem with Cisco's software. Which of them applies will depend on what software version is involved:
Both of the latter solutions rely on static routes, and in the long run these will be impossible to maintain. In some topologies the use of static routes can be a problem (e.g. if you have more than one possible exit point from your AS to choose from).
The following information is presented as supplemental information that is related to the CIDRization process.
The IRR is a way for ASN's to publicize their own intended routing policies without having to request a change from a go-between.
The RAdb which stands for the Routing Arbiter Data Base, which is part of the IRR, is part of a joint project between Merit and ISI. The Routing Arbiter is a project of the US National Science Foundation. As part of that project, it runs a routing registry database.
That database (the RAdb) forms part of the IRR collection of databases. The RIPE database is not part of the RAdb but does participate in the IRR. At present, there are five entities that contribute to the IRR effort and more are expected. Today, all the contributing registries use the RIPE-181 database format.
All IRR participants can be contacted via automail handlers that accept batch updates via email. An example of a routing update appears below:
The *rt: tag identifies the net and the routing policy is based on *or: tag. An example of a routing policy is presented below:
For further details read over ripe-120.ps, ripe-121.ps and ripe-181.ps (via anonymous ftp from ftp.ripe.net/ripe/docs).
COUNTS OF RADB PREFIXES BY LENGTH - The number of Route objects registered in the RADB, with active and withdrawn routes listed by prefix length. Data from the current week is available from:
ftp://ftp.ra.net/routing.arbiter/radb/reports/ counts-by-prefix/Summarize_prefix.currentReports from previous weeks are available from:
ftp://ftp.ra.net/routing.arbiter/radb/reports/counts-by-prefix/summarize_prefix.yymmddIRR ROUTES SUMMARIZED BY PREFIX LENGTH WITH AGGREGATION - A summary of unique prefixes registered in the IRR. Routes are summarized by the first octet of the network number. If routes within a prefix can be aggregated, a count is printed for each prefix length that has a different count after aggregation. Data from the current week is available from:
ftp://ftp.ra.net/routing.arbiter/radb/reports/IRR_profile/IRR_Profile.currentReports from previous weeks are available from:
ftp://ftp.ra.net/routing.arbiter/radb/reports/ IRR_profile/IRR_Profile.yymmddYou need to submit a "route" object update and perhaps an "aut-num" object update (see examples above). Route objects add new nets to your autonomous system (or you can remove nets from your autonomous system) and the Autonomous-system object describes the type of routing you wish to have.
Each provider is allowed to select the preference order for authentic data. For example, ANS uses the following precedence: ANS, CANET, MCI, RIPE, RADB
If there are two routes (with different origins) within one database, the changed date is used as a tiebreaker. Else, only database precedence is used. Thus, if the RADB entry has a more recent changed date than the RIPE, ANS will use the RIPE entry.
You should only have to register in one of the IRR component databases.
There is a report which shows all routes in the RADB for a specified AS and whether there are any duplicate routes in other IRR registries or any aggregates which cover the route (in any of the registries, including the RADB):
http://www.ra.net/cgi-bin/ra/radb-duplicates.plThe tool to use is whois. A few examples make the command self explanatory:
There is an easy Web interface to query and update the IRR:
http://www.nap.roma.it/cgi-bin/whoisrlc is a route list compiler which is a subset of nlc/alc that allows the generation of route based filters (cisco access- lists) by extracting the nets belonging to an AS or AS MACRO from a routing database (i.e. Ripe Routing Database). In addition, it supports a limited set of functions to generate AS based filter lists.
rlc is fully classless, and hence supports CIDR routes and subnets, as well as host routes.
Source: ftp://dxcoms.cern.ch/pub/ripe-routing-wg Author: Jean-Michel Jouanigot, CERNA web version of the following information can be located at: http://www.ra.net/~ra/tools The information presented here is merely for completeness and printing purposes.
Online Tools and Reports
This graphical interface into the Internet Routing Registry makes it possible to use the Web to query the IRR and update RADB AS objects, Route objects, and Maintainer objects. Users can enter any value that can be submitted through a whois query, such as an AS number, network IP address, or maintainer. IRRWeb then displays the corresponding AS objects, Route objects, or Maintainer objects from the various registries in the IRR. Authorized maintainers can edit the objects directly; IRRWeb performs a cursory pre-check and mails the revised object to auto-dbm@ra.net. The user then receives e-mail from auto-dbm confirming and displaying the revised object, or explaining why the object was rejected.
See http://www.ra.net/cgi-bin/ra/query-radb.plThe Route History Server provides a mechanism for tracking the announce/withdraw history of a given prefix for the last 24 hours. The History Server peers with the route servers at each NAP and records all BGP updates in History Server/Route Server peering session.
See http://www.ra.net/cgi-bin/ra/rshist.plA new RADB tool tells you which RADB routes in an AS are duplicated or covered by less specific routes in the IRR:
http://www.ra.net/~ra/RADB.tools.docs/.reports.htmlRouting table, routing instability, routing problems, and other important statistics:
http://www.ra.net/statisticsTools Available for FTP
The Route Server daemon (RSd) is an enhanced version of the GateD routing software that provides multiples views of routing information. The software provides a mechanism for network service provides to off-load the computational complexity of routing policy calculations from their routers. RSd supports configuration and transparent passing of BGP MEDs. The software also supports BGP route flap dampening.
Follow the pointers from:http://info.ra.net/div7/ra/source.htmlA policy evaluator that inputs a RIPE-181 policy expression, performs essential background calculations such as symbolic evaluations and expansions, and outputs another RIPE-181 policy expression that is used by other tools, such as RTConfig.
Available as part of the RAToolSet at ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet
A router configuration tool that can be used by providers to generate router configs directly from the RADB or other IRR registries. Currently in production use for the RA Route Servers, ANSNET, and CA*net, RTConfig is a front-end tool that uses peval and radbserver transparently to users.
Available as part of the RAToolSet at ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet
This Cisco-to-RIPE-181 conversion package makes it possible for users to convert Cisco router configuration files to RIPE-181 objects that can be submitted to the Internet Routing Registry (IRR). The Cisco access-list can be converted into an explicit set of nets embedded in an AS object or represented as a community. The RADBserver is queried for any missing or previously registered information.
Available at ftp://ftp.ra.net/routing.arbiter/tools/RAToolSet/rrc2r-0.2.tar.gz
IRR users have long recognized the need for tools that check the IRR against routes actually propagated in the Internet. CiscoBGP obtains and analyzes routing information from production Ciscos, and compares the data with routes in the IRR. The software also flags prefixes that are reserved by RFC 1918, Address Allocation for Private Internets.
Available as part of the MRT software distribution at http://www.merit.edu/~mrt
BGPCheck obtains and analyzes routing information from BGP4 peering sessions, and compares the data with routes in the IRR. The software also flags prefixes that are reserved by RFC 1918, Address Allocation for Private Internets.
Available as part of the MRT software distribution at http://www.merit.edu/~mrt
The 'prtraceroute' tool is a powerful form of traceroute that displays the Autonomous Systems that a packet traverses. PRtraceroute was developed by the Pride project.
A version of prtraceroute that queries the RADB is available at ftp://ftp.ra.net/routing.arbiter/pride/prtraceroute-2.0beta2.shar.gz
Tool Announcements
Follow these steps to take advantage of the new RADB support for PGP-based digital signatures:
For detailed instructions, see: http://www.ra.net/RADB.tools.docs/pgp.html