March 2007

Version 7.2

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 (

General Questions

1. What does CIDR stand for?

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.

2. What is an ASN?

ASN stands for Autonomous System Number and acts to merge many networks into a logical domain.

3. What is BGP?

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.

4. Why should I make the effort and convert my routing to be CIDRized?

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.

5. Can you give an example of a simple CIDR configuration for a Cisco router?

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.

router bgp 64100
no synchronization
aggregate-address summary-only
aggregate-address summary-only
neighbor remote-as 65000
neighbor distribute-list 12 out
default-metric 70
access-list 12 permit
access-list 12 permit

Another method might be:

router bgp 64100
no synchronization
neighbor remote-as 65000
neighbor distribute-list 102 out
default-metric 70
access-list 102 deny
access-list 102 deny

An alternate method is via network and route statements:

router bgp 64100
no synchronization
network mask
network mask
neighbor remote-as 65000
default-metric 70
ip route Null0 254
ip route Null0 254

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:

  1. if your IGP is classful (e.g. RIP or IGRP) you will by default not do any route aggregation
  2. if you have an internal stability problem (accidents do happen), this will be reflected as a "route flap" in the whole routing system, globally burning CPU cycles better spent on other things
  3. if the IGP -> BGP transition is unrestricted, this can lead to false routing information escaping from your network (especially if you do not fully have administrative control over your IGP)

6. What do all these /16s and /24s mean in my BGP tables?

This refers to the number of bits of the network part of the IP address. A former class B may appear as, which is the same as 256 class C's which can appear as A single class C appears as 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 table
CIDR PrefixMask# of former class C nets
/17255.255.128.0 128
/16255.255.0.0256 = 1 class B

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

7. Do I need to carry the full Internet routing table? When would it be necessary? What routers on the Internet carry full routing tables?

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.

8. What is there in the Internet to stop me from making a mistake and announcing via BGP an aggregate that is larger than the nets I am in charge of?

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.

9. Who has to renumber with CIDR?

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.

Specific questions

10. How can I redistribute our IGP routes (IGRP) so that they become aggregated when sent out via BGP?

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:

router bgp 64100
aggregate-address summary-only
aggregate-address summary-only
redistribute igrp 64100 route-map origin-AS64100
! or:
! redistribute igrp 64100
! distribute-list 10 out igrp 64100
route-map origin-AS64100 permit 10
match ip address 10
access-list 10 permit
access-list 10 permit
access-list 10 permit

This example would generate one route and one route if any of the contained networks is in the IGP.

11. I am multihomed to three ISPs and can only CIDRize to two of them but to the third I need to still announce specific nets. What damage will this do to my ASN?

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.

12. I don't want to CIDRize. Can someone do proxy aggregation for me?

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.

Supplemental information

The following information is presented as supplemental information that is related to the CIDRization process.

13. What is the Internet Routing Registry?

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:

password: xxxxxxxx
*de: NET-IEC
*or: AS378
*mb: AS378-MNT
*ch: 19950724
*so: RIPE

The *rt: tag identifies the net and the routing policy is based on *or: tag. An example of a routing policy is presented below:

aut-num: AS378
descr: ILAN
descr: Israeli Academic and Research Network
as-in: from AS1755 100 accept ANY
as-in: from AS174 100 accept ANY
as-in: from AS3339 100 accept AS3339
as-out: to AS1755 announce AS378 AS3339
as-out: to AS174 announce AS378 AS3339
as-out: to AS3339 announce ANY
default: AS174 10
default: AS1755 20
default: AS3339 30
mnt-by: AS378-MNT
admin-c: Hank Nussbacher
tech-c: Hank Nussbacher
changed: 19950627
source: RIPE

For further details read over the RIPE Database Reference Manual.

14. Are there any statistics available as to aggregation in the Internet?

Geoff Huston has maintained statistics on the growth of the Internet.

15. How do I update the registered routing information for my ASN?

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.

16. Which Routing database takes precedence? RIPE? RADB? CW? Do I have to update all of them?

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.

17. How do I check what is registered in the IRR?

The tool to use is whois. A few examples make the command self explanatory:

whois -h
whois -h as378
whois -h

There is an easy Web interface to query the IRR:

Contributors (1997):
  • Christian Panigl - Vienna University, Austria
  • Bill Manning - ISI
  • Tony Li - Cisco Systems
  • Havard Eidnes - SINTEF, Norway
  • Yakov Rekhter - Cisco Systems
  • Craig Labovitz - Merit Network

This page is maintained by Hank Nussbacher (
Phone: +972-9-7663447, Fax: +972-9-7663432, Cell: +972-54-5568881
Last modified on Sun Mar 11, 2007