North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

CIDR FAQ

  • From: Hank Nussbacher
  • Date: Sun Aug 06 06:07:52 1995

All follow-ups to [email protected] please...

 ------------------------------------------------------------------------
                            The CIDR FAQ
                              Version 1
                            6 August 1995
 ------------------------------------------------------------------------
 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.

 Updates from a previous version are marked with a '|' in column 1.

 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)
 [email protected] or [email protected]

|If you would like to "discuss" items from this FAQ please send
|your mail to [email protected]

|This FAQ is being distributed to the following groups and lists:
|alt.internet.services
|alt.internet.access.wanted
|[email protected]
|[email protected]
|[email protected]
|[email protected]
|[email protected]

 To retrieve the most up-to-date version of this document:
 - anonymous FTP: ftp.ibm.net.il/pub/docs/cidr.faq
 ------------------------------------------------------------------------

 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 (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 now
    over 29,000 routes and one of the main routers that can handle the
    full routing tables are cisco 7000's with 64MB of memory.  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:

    cisco 7000 w/ 32Mb
    cisco 4500 w/ 32Mb
    IBM 6611' w/ 64Mb  (formerly known as ENSS)
    BayNetworks ????  w/ 32Mb

 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 172.16.0.0 255.248.0.0 summary-only
    aggregate-address 192.168.50.0 255.255.255.0 summary-only
    neighbor 192.168.54.2 remote-as 65000
    neighbor 192.168.54.2 distribute-list 12 out
    default-metric 70
    !
    access-list 12 permit 192.168.50.0 0.0.0.255
    access-list 12 permit 172.16.0.0 0.7.255.255

    An alternate method is via network and route statements:

    router bgp 64100
    no synchronization
    network 172.16.0.0 mask 255.248.0.0
    network 192.168.50.0 mask 255.255.255.0
    neighbor 192.168.54.2 remote-as 65000
    neighbor 192.168.54.2
    default-metric 70
    ip route 172.16.0.0 255.248.0.0 Null0 254
    ip route 192.168.50.0 255.255.255.0 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 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:

    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 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:

                      # of
                      former
    CIDR              class C
    block             nets
    ----              ----
    /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 former class B
    /15               512
    /14              1024
    /13              2048

    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.

 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 and how much memory is needed?

     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.

 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.

 Specific questions
 ------------------


 10. I have a /16 but have registered parts of it as /24s in the RADB.
     I now want to CIDRize.  The problem is parts of the /16s are
     missing and are routed via a different ASN.  Can you explain how
     more specific routes override more general ones and will I hurt my
     routing if I just advertise the /16 and not a bunch of /20s and
     /21s?

     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).

 11. 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 192.168.0.0 255.255.192.0 summary-only
     aggregate-address 172.16.0.0 255.254.0.0 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 192.168.0.0 0.0.63.0
     access-list 10 permit 172.16.0.0
     access-list 10 permit 172.17.0.0

     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.

 12. 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 AS?

     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.

 13. 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.

 14. What routers on the market today don't support CIDR?

     ???

 15. How do I reach other parts of a subnetted old-style network when
     I have only partial routing information for that same old-style
     network?"

     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:

      o Preferred solution: turn on "ip classless" in your routers and
        use a default route inside your AS.  The "ip classless"
        command prevents the existence of a single "subnet" route from
        blocking access via the default route to other subnets of the
        same old-style network.

      o Workaround for 9.1 or later software where the "ip classless"
        command is not available: install a "default network route"
        like this: "ip route 39.0.0.0 255.0.0.0 next-hop" along the
        axis your default route would normally take.

      o Workaround for 9.0 or older software: create a "default
        subnet route": "ip route 39.x.y.0 next-hop" combined with "ip
        default-network 39.x.y.0", otherwise as the 9.1 fix.

     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).

 Supplemental information
 ------------------------

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

 16. 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 Arbiter Data Base, which
     is part of the IRR, is part of a joint project between Merit and
     ISI. For full details contact:
     http://www.ra.net/routing.arbiter/RA/index.html.

     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.

     The Routing Arbiter can be contacted via auto-mail handlers
     that accept batch updates via email. An example of a routing
     update appears below:

     password: xxxxxxxx
     *rt: 138.134.0.0/16
     *de: NET-IEC
     *or: AS378
     *mb: AS378-MNT
     *ch: [email protected] 950724
     *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
     guardian:    [email protected]
     mnt-by:      AS378-MNT
     admin-c:     Hank Nussbacher
     tech-c:      Hank Nussbacher
     changed:     [email protected] 950627
     source:      RIPE

     For further details read over ripe-120.ps, ripe-121.ps and
     ripe-181.ps (via anonymous ftp from info.ripe.net/ripe/docs).

 17. 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.

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

     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.

 19. How do I check what is in the RA?

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

     whois -h whois.ra.net 128.228.0.0
     whois -h whois.ripe.net as378
     whois -h whois.canet.ca 142.77.0.0

 20. Is there a tool to automatically create route filters based
     on IRR information?

     rlc 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, CERN <[email protected]>

  Contributors:
  Christian Panigl - Vienna University, Austria
  Bill Manning - ISI
  Tony Li - Cisco Systems
  Havard Eidnes - SINTEF, Norway
  Yakov Rekhter - Cisco Systems