Phone: +972-9-7663447, Fax: +972-9-7663432, Cell: +972-54-5568881
Last modified on Sun Mar 11, 2007
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.
The previous version - 6.1, was last updated on September 1997, so I guess there may be much listed here that may sound quaint and old-fashioned but back in 1997 - it was leading edge :-)
If you have any questions, please send them to the editor mentioned below:
Hank Nussbacher (hank@interall.co.il)
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 used 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 were over 29,000 routes, whereas in May 2004, there were 134,000 routes. Routers at interconnection points (or multi-homed hosts doing full routing with many peers) receive these routes from several peers, and need hundreds of megabytes of RAM (and the appropriate CPU horsepower) to handle this. Routers with 64MB of memory had the capacity for approximately 60,000 routes after which some routes would just be left out of the global routing tables, and the more likely ones to be left out were routes covering small pieces of address space. Nowadays, to handle 134,000 routes, the recommended amount of memory is 256MB.
Without the CIDRization work that has taken place over the past decade the routing tables would be in excess of 500,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 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 via 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 | Mask | # of former class C nets |
|---|---|---|
| /30 | 255.255.255.252 | 1/64 |
| /29 | 255.255.255.248 | 1/32 |
| /28 | 255.255.255.240 | 1/16 |
| /27 | 255.255.255.224 | 1/8 |
| /26 | 255.255.255.192 | 1/4 |
| /25 | 255.255.255.128 | 1/2 |
| /24 | 255.255.255.0 | 1 |
| /23 | 255.255.254.0 | 2 |
| /22 | 255.255.252.0 | 4 |
| /21 | 255.255.248.0 | 8 |
| /20 | 255.255.240.0 | 16 |
| /19 | 255.255.224.0 | 32 |
| /18 | 255.255.192.0 | 64 |
| /17 | 255.255.128.0 | 128 |
| /16 | 255.255.0.0 | 256 = 1 class B |
| /15 | 255.254.0.0 | 512 |
| /14 | 255.252.0.0 | 1024 |
| /13 | 255.248.0.0 | 2048 |
| /12 | 255.240.0.0 | 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 ASN, it is a good idea to announce as few prefixes as possible and to utilize the address space as much as possible.
For a more comprehensive table see: 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 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.
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.0.0/18 and one route 172.16.0.0/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.
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 Assets 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 many entities that contribute to the IRR effort. 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 the RIPE Database Reference Manual.
You 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.
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.
You should only have to register in one of the IRR component databases.
The tool to use is whois. A few examples make the command self explanatory:
There is an easy Web interface to query the IRR: http://www.completewhois.com/whois.htm