From hostmaster at ripe.net Tue Aug 1 17:44:08 1995 From: hostmaster at ripe.net (RIPE NCC Hostmaster) Date: Tue, 01 Aug 1995 17:44:08 +0200 Subject: new documents: IP Address Request Form and Supporting Notes Message-ID: <9508011544.AA23701@ncc.ripe.net> Dear Local Registries, As you probably noticed is ripe-124 ("European IP Address Space Request Form and Supporting Notes") expired quite some time ago. Unfortunately we had no time to revisit the document as extensive as we would like to do. But there are some changes to note: One of the main changes is that we have split ripe-124 in two separate documents: - ripe-128.{txt, ps} "Supporting Notes for European IP Address Space Requests" - ripe-129.txt "European IP Address Space Request Form" Please note that there is no ps version for the form itself anymore. We receive too many requests by Fax, where e-mail would be possible (and preferred). If you have any problems with this, please let us know. Please note also other changes in the new documents. Some are listed below: - nic-hdl's for admin- and tech-c's are now mandatory. Please refer to ripe-126 for more information. - network details are now required for every request not only for requests for more than two C's There are still a lot of changes necessary, therefor the new version will expire again at 31st October 1995. If you have comments or suggestions for the new document, please contact us as soon as possible. All input is welcom. You will receive the official notification for the two documents in separate mails. Kind regards, Mirjam Kuehne RIPE NCC hostmaster team From ncc at ripe.net Tue Aug 1 18:01:27 1995 From: ncc at ripe.net (RIPE NCC Document Annoucement Service) Date: Tue, 01 Aug 1995 18:01:27 +0200 Subject: New Document available: ripe-128 Message-ID: <9508011601.AA24012@ncc.ripe.net> New/Revised RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store. Ref: ripe-124 Title: European Internet Network Number Application Form Title: and Supporting Notes Author: RIPE NCC Date: 7 October 1994 Format: PS=76937 TXT=34471 bytes Obsoletes: ripe-115 Obsoleted by: ripe-128 & ripe-129 Updates: Updated by: Old: Ref: ripe-128 Title: Supporting Notes for European IP Address Space Requests Author: RIPE NCC Date: 1 August 1995 Format: PS=76937 TXT=34471 bytes Obsoletes: ripe-124 Obsoleted by: Updates: Updated by: Old: Short content description ------------------------- This document is the revised version of the "European Internet Network Number Application Form and Supporting Notes". The new document contains only the Supporting Notes. The form itself is published in a separate document. -------------- next part -------------- FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/" followed by the command "get filename". The relevant filenames for this document are: ripe-128.txt for the ASCII version ripe-128.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server at ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. -------------- next part -------------- SEND ripe/docs/ripe-128.txt From ncc at ripe.net Tue Aug 1 18:04:29 1995 From: ncc at ripe.net (RIPE NCC Document Annoucement Service) Date: Tue, 01 Aug 1995 18:04:29 +0200 Subject: New Document available: ripe-129 Message-ID: <9508011604.AA24055@ncc.ripe.net> New/Revised RIPE Document Announcement -------------------------------------- A revised document is available from the RIPE document store. Ref: ripe-124 Title: European Internet Network Number Application Form Title: and Supporting Notes Author: RIPE NCC Date: 7 October 1994 Format: PS=76937 TXT=34471 bytes Obsoletes: ripe-115 Obsoleted by: ripe-128 & ripe-129 Updates: Updated by: Old: Ref: ripe-129 Title: European IP Address Space Request Form Author: RIPE NCC Date: 1 August 1995 Format: PS=76937 TXT=34471 bytes Obsoletes: ripe-124 Obsoleted by: Updates: Updated by: Old: Short content description ------------------------- This document is revised version of the "European Internet Network Number Application Form and Supporting Notes". The new document contains *only* the Request Form. The Supporting Notes are published in ripe-128. -------------- next part -------------- FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/" followed by the command "get filename". The relevant filenames for this document are: ripe-129.txt for the ASCII version ripe-129.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server at ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. -------------- next part -------------- SEND ripe/docs/ripe-129.txt From HANK at VM.TAU.AC.IL Sun Aug 6 10:55:43 1995 From: HANK at VM.TAU.AC.IL (Hank Nussbacher) Date: Sun, 06 Aug 95 10:55:43 IST Subject: CIDR FAQ Message-ID: <9508060803.AA18212@ncc.ripe.net> All follow-ups to cidrd at iepg.org 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) hank at vm.tau.ac.il or hank at ibm.net.il |If you would like to "discuss" items from this FAQ please send |your mail to cidrd at iepg.org |This FAQ is being distributed to the following groups and lists: |alt.internet.services |alt.internet.access.wanted |nanog at merit.edu |inet-access at earth.com |iap at vma.cc.nd.edu |local-ir at ripe.net |cidrd at iepg.org 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: hank at aristo.tau.ac.il 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: HANK at vm.biu.ac.il mnt-by: AS378-MNT admin-c: Hank Nussbacher tech-c: Hank Nussbacher changed: hank at vm.tau.ac.il 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 Contributors: Christian Panigl - Vienna University, Austria Bill Manning - ISI Tony Li - Cisco Systems Havard Eidnes - SINTEF, Norway Yakov Rekhter - Cisco Systems From sob at academ.com Sun Aug 6 20:47:21 1995 From: sob at academ.com (Stan Barber) Date: Sun, 6 Aug 1995 13:47:21 CDT Subject: CIDR FAQ In-Reply-To: Hank Nussbacher "CIDR FAQ" (Aug 6, 10:55am) Message-ID: <199508061847.NAA06322@academ.com> Here is a small list for you. Of couse, corrections are most welcome: Routers that don't support fully support CIDR: ASCEND Pipeline and MAX products Telebit Netblazer Compatible Systems -- Stan | Academ Consulting Services |internet: sob at academ.com Olan | For more info on academ, see this |uucp: amdahl!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine. From nathan at netrail.net Sun Aug 6 21:53:12 1995 From: nathan at netrail.net (Nathan Stratton) Date: Sun, 6 Aug 1995 15:53:12 -0400 (EDT) Subject: CIDR FAQ In-Reply-To: <199508061847.NAA06322@academ.com> Message-ID: The cisco 4000-M with 32 M should also support the internet routing table. Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales at netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From jerry at fc.net Mon Aug 7 03:29:02 1995 From: jerry at fc.net (Jeremy Porter) Date: Sun, 6 Aug 1995 20:29:02 -0500 (CDT) Subject: CIDR FAQ In-Reply-To: <199508061847.NAA06322@academ.com> from "Stan Barber" at Aug 6, 95 01:47:21 pm Message-ID: <199508070129.UAA02765@freeside.fc.net> > >Here is a small list for you. Of couse, corrections are most welcome: > >Routers that don't support fully support CIDR: > ASCEND Pipeline and MAX products > Telebit Netblazer Livingston Portmasters, and possibly IRX routers also. > -- ---------------------------------------------------------------------------- | Jeremy Porter (512)-339-6094 Freeside Communications, Inc. info at fc.net | | jerry at fc.net (512)-339-4466 (data) P.O. Box 530264 Austin, TX 78753 | ---------------------------------------------------------------------------- From randy at psg.com Sun Aug 6 23:15:00 1995 From: randy at psg.com (Randy Bush) Date: Sun, 6 Aug 95 14:15 PDT Subject: CIDR FAQ References: <199508061847.NAA06322@academ.com> Message-ID: > Here is a small list for you. Of couse, corrections are most welcome: > > Routers that don't support fully support CIDR: > ASCEND Pipeline and MAX products > Telebit Netblazer > Compatible Systems Also Livingston IRX and Portmaster. They're RIP-1-only, and hence not classless. randy From nathan at netrail.net Mon Aug 7 06:56:38 1995 From: nathan at netrail.net (Nathan Stratton) Date: Mon, 7 Aug 1995 00:56:38 -0400 (EDT) Subject: CIDR FAQ In-Reply-To: <199508070129.UAA02765@freeside.fc.net> Message-ID: On Sun, 6 Aug 1995, Jeremy Porter wrote: > > > >Here is a small list for you. Of couse, corrections are most welcome: > > > >Routers that don't support fully support CIDR: > > ASCEND Pipeline and MAX products > > Telebit Netblazer > > Livingston Portmasters, and possibly IRX routers also. > > > Yes, add the IRX's to the list. Tho Livingston says they are working on it. Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales at netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From ncc at ripe.net Tue Aug 8 13:50:12 1995 From: ncc at ripe.net (RIPE NCC Staff) Date: Tue, 08 Aug 1995 13:50:12 +0200 Subject: Ford asking for space Message-ID: <9508081150.AA13274@ncc.ripe.net> Dear Local Registry contacts, We have got someone from Ford asking for address space to set up a network for their dealers. Ford currently has about 150 B class addresses already. If you get any request from address space from them, could you please refer them to us? Thanks. Kind regards, Roderik Muit RIPE NCC From training at ripe.net Mon Aug 14 11:27:38 1995 From: training at ripe.net (RIPE NCC Training) Date: Mon, 14 Aug 1995 11:27:38 +0200 Subject: Local IR Training Course - Registration Closed Message-ID: <9508140927.AA19374@ncc.ripe.net> Dear Local IR's, The registration for the Local IR Training course in Vienna, August, 25th 1995 has now been closed. As the course was oversubscribed, we were regrettably, not able to accept everyone. There are still free places for the courses in Milan, September, 4th 1995 and in Amsterdam, October, 16th 1995. If you are interested in having a course in your country for a number of local IR's, we would be happy to do this. To discuss this further, please send mail to . Kind regards, Mirjam Kuehne RIPE NCC Training Team ------------------------ From bwatson at mci.net Tue Aug 15 04:31:13 1995 From: bwatson at mci.net (Brett Watson) Date: Mon, 14 Aug 1995 22:31:13 -0400 Subject: CIDR FAQ In-Reply-To: Your message of "Mon, 07 Aug 1995 00:56:38 EDT." Message-ID: <199508150231.WAA16623@carbon.cary.mci.net> > On Sun, 6 Aug 1995, Jeremy Porter wrote: > > > > > > >Here is a small list for you. Of couse, corrections are most welcome: > > > > > >Routers that don't support fully support CIDR: > > > ASCEND Pipeline and MAX products > > > Telebit Netblazer > > > > Livingston Portmasters, and possibly IRX routers also. > > > > > > Yes, add the IRX's to the list. Tho Livingston says they are working on it. Since people are throwing in dialup/routing equipment add: USR Total Control Hubs -brett From sob at academ.com Tue Aug 15 05:16:20 1995 From: sob at academ.com (Stan Barber) Date: Mon, 14 Aug 1995 22:16:20 CDT Subject: CIDR FAQ In-Reply-To: Brett Watson "Re: CIDR FAQ" (Aug 14, 10:31pm) Message-ID: <199508150316.WAA25481@academ.com> Don't you really mean the USR Routing cards for these hubs? You can put a Cisco AS5100 in them and they route just like a Cisco 2511. -- Stan | Academ Consulting Services |internet: sob at academ.com Olan | For more info on academ, see this |uucp: amdahl!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine. From peter at demon.net Tue Aug 15 09:39:06 1995 From: peter at demon.net (peter at demon.net) Date: Tue, 15 Aug 1995 08:39:06 +0100 (BST) Subject: CIDR FAQ In-Reply-To: <199508150316.WAA25481@academ.com> from "Stan Barber" at Aug 14, 95 10:16:20 pm Message-ID: <9508150839.aa20684@office.demon.net> > Don't you really mean the USR Routing cards for these hubs? You can > put a Cisco AS5100 in them and they route just like a Cisco 2511. I beleive the reference was to the NetServer cards, which are a Livingstone based product, and do *not* do CIDR. BTW Any BSD4.4 based *NIX (NetBSD, FreeBSD, etc) *does* do CIDR. Regards, -- Peter Galbavy peter at demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/ From jon at branch.com Tue Aug 15 16:29:40 1995 From: jon at branch.com (Jon Zeeff) Date: Tue, 15 Aug 1995 10:29:40 -0400 (EDT) Subject: CIDR FAQ In-Reply-To: <9508150839.aa20684@office.demon.net> from "peter@demon.net" at Aug 15, 95 08:39:06 am Message-ID: > Livingstone based product, and do *not* do CIDR. > > BTW Any BSD4.4 based *NIX (NetBSD, FreeBSD, etc) *does* do CIDR. Another reason why some people are thinking that workstations and generic micros sometimes look pretty good as replacements for "real" routers. You get software that works, full source code, faster CPUs, and fewer memory limitations. At a cost low enough to get a "free" spare. From pst at shockwave.com Tue Aug 15 18:39:13 1995 From: pst at shockwave.com (Paul Traina) Date: Tue, 15 Aug 1995 09:39:13 -0700 Subject: CIDR FAQ In-Reply-To: Your message of "Tue, 15 Aug 1995 10:29:40 EDT." Message-ID: <199508151639.JAA28314@puli.cisco.com> From: jon at branch.com (Jon Zeeff) Subject: Re: CIDR FAQ > BTW Any BSD4.4 based *NIX (NetBSD, FreeBSD, etc) *does* do CIDR. Another reason why some people are thinking that workstations and generic micros sometimes look pretty good as replacements for "real" routers. You get software that works, full source code, faster CPUs, and fewer memory limitations. At a cost low enough to get a "free" spare. Look, I really hate to sound like I have sour grapes, but this thread keeps coming up and I all hear about the PC router issue is a lot of talk about price and CPUs, but I don't actually hear any operational experience about them. PCs have been around for years, and even 4.4+reno/gated boxes have been around as long as cisco/bgp4 boxes. If they really are such a great value, why the hell aren't "those evil router vendors" out of business in the Internet market yet? Call me thin skinned, but this is really starting to get old. I would like to personally see the folks who keep extoling the virtues of roll-your-own solutions either put up or shut up. Can we kindly return this thread to: "What boxes don't do classless routing?" From peter at demon.net Tue Aug 15 19:13:47 1995 From: peter at demon.net (peter at demon.net) Date: Tue, 15 Aug 1995 18:13:47 +0100 (BST) Subject: CIDR FAQ In-Reply-To: <199508151639.JAA28314@puli.cisco.com> from "Paul Traina" at Aug 15, 95 09:39:13 am Message-ID: <9508151814.aa18193@office.demon.net> > Look, I really hate to sound like I have sour grapes, but this thread > keeps coming up and I all hear about the PC router issue is a lot of > talk about price and CPUs, but I don't actually hear any operational > experience about them. OK. Here we are. We use them in a mission critical environment. For Ethernet to Ethernet routeing with a full routeing table they are wonderful. Trying to make them work as fast serial routers is another matter. But they *do* work. > PCs have been around for years, and even 4.4+reno/gated boxes have been > around as long as cisco/bgp4 boxes. If they really are such a great value, > why the hell aren't "those evil router vendors" out of business in the > Internet market yet? There are a large number of reasons, from the technical to the commercial to the marketing-people-on-steroids reasons. Reason 1. Special boxes are better. In some cases. Especial for the non technically competant organisations that don't want to or need to roll there own. There are of course also Cisco/Bay Networks hackers too. Reason 2. "Know one ever got fired for buying Cisco." Remember where that saying has been adapted from. Reason 3. Marketing. "We use Cisco/Bay/router-of-the-day in our core network. We must be profressionals". Hmm. > Call me thin skinned, but this is really starting to get old. > I would like to personally see the folks who keep extoling the virtues of > roll-your-own solutions either put up or shut up. We have. Thanks. We are very happy using Pentiums running NetBSD as *core* routers. Three PCI 10/100Mb Ethernet cards. Great stuff. 35,000 dialup SLIP/PPP customers can't be that wrong. > Can we kindly return this thread to: "What boxes don't do classless routing?" We did - the CIDR FAQ started out as an ad for Cisco, some of us are trying to get some balance in this area. Regards, -- Peter Galbavy peter at demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/ From nathan at netrail.net Tue Aug 15 19:30:57 1995 From: nathan at netrail.net (Nathan Stratton) Date: Tue, 15 Aug 1995 13:30:57 -0400 (EDT) Subject: CIDR FAQ In-Reply-To: <199508151639.JAA28314@puli.cisco.com> Message-ID: On Tue, 15 Aug 1995, Paul Traina wrote: > > From: jon at branch.com (Jon Zeeff) > Subject: Re: CIDR FAQ > > > BTW Any BSD4.4 based *NIX (NetBSD, FreeBSD, etc) *does* do CIDR. > > Another reason why some people are thinking that workstations and generic > micros sometimes look pretty good as replacements for "real" routers. > > You get software that works, full source code, faster CPUs, and fewer > memory limitations. At a cost low enough to get a "free" spare. > > Look, I really hate to sound like I have sour grapes, but this thread > keeps coming up and I all hear about the PC router issue is a lot of > talk about price and CPUs, but I don't actually hear any operational > experience about them. Well we are going to use a PC router if all works out for our MAE-East connection. But we do have a cisco 4500-M if it des not work out. Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales at netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From michael at junction.net Tue Aug 15 19:56:25 1995 From: michael at junction.net (Michael Dillon) Date: Tue, 15 Aug 1995 10:56:25 -0700 (PDT) Subject: CIDR FAQ In-Reply-To: <9508151814.aa18193@office.demon.net> Message-ID: On Tue, 15 Aug 1995 peter at demon.net wrote: > > I would like to personally see the folks who keep extoling the virtues of > > roll-your-own solutions either put up or shut up. > > We have. Thanks. We are very happy using Pentiums running NetBSD as > *core* routers. Three PCI 10/100Mb Ethernet cards. Great stuff. > 35,000 dialup SLIP/PPP customers can't be that wrong. Isn't that 600% growth in customers over the past year? Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael at memra.com From dsiegel at net99.net Tue Aug 15 20:00:29 1995 From: dsiegel at net99.net (Dave Siegel) Date: Tue, 15 Aug 1995 11:00:29 -0700 (MST) Subject: CIDR FAQ In-Reply-To: from "Jon Zeeff" at Aug 15, 95 10:29:40 am Message-ID: <199508151800.LAA02521@dewey.net99.net> > > Livingstone based product, and do *not* do CIDR. > > > > BTW Any BSD4.4 based *NIX (NetBSD, FreeBSD, etc) *does* do CIDR. > > Another reason why some people are thinking that workstations and generic > micros sometimes look pretty good as replacements for "real" routers. > > You get software that works, full source code, faster CPUs, and fewer > memory limitations. At a cost low enough to get a "free" spare. Let's excuse the fact that gated consumes more memory than a cisco for the same amount of routes for a second... Okay, so let's talk functionality. Are there HSSI PCI cards available? Can you do SMDS over this card? Frame? What about a DS3 ATM card, or higher? I know we can do Ethernet, FDDI, sync, and T1 FR, so that's half of it, but there are still lot's of reason's to buy Cisco gear. I'm not excusing the possibility of being able to use PC's, but the additional management issues of having to manage Unix box's in addition to internal routing policies, and expansion efforts sounds like a headache. Managing a network of Cisco's requires a relatively small amount of time, and my staff and I can concentrate on real problems. Dave -- Dave Siegel Director of Engineering, Net99 http://www.webcity.com/ (602)249-1083 24x7 NOC line http://www.rtd.com/~dsiegel/ (520)318-0696 My Tucson Office From jgs at aads.net Tue Aug 15 21:12:30 1995 From: jgs at aads.net (John G. Scudder) Date: Tue, 15 Aug 1995 15:12:30 -0400 Subject: CIDR FAQ Message-ID: At 11:00 AM 8/15/95, Dave Siegel wrote: >Let's excuse the fact that gated consumes more memory than a cisco for the >same amount of routes for a second... > >Okay, so let's talk functionality. > >Are there HSSI PCI cards available? Can you do SMDS over this card? Frame? >What about a DS3 ATM card, or higher? And Paul Traina wrote something vaguely similar. I think you guys are both missing what I think was Jon's original point: Routers forward packets faster than PCs, but the forwarding function and the routing protocol function do not have to reside on the same box. You can add a PC (workstation, whatever) which runs the routing protocol and stuffs routes into the router. It doesn't have to support the link-layer du jour. Ethernet will do the job just fine. As I recall the original discussion was of colocating a router, to forward packets, with a workstation, to compute routes. --John From dsiegel at net99.net Tue Aug 15 21:28:00 1995 From: dsiegel at net99.net (Dave Siegel) Date: Tue, 15 Aug 1995 12:28:00 -0700 (MST) Subject: CIDR FAQ In-Reply-To: from "John G. Scudder" at Aug 15, 95 03:12:30 pm Message-ID: <199508151928.MAA03857@dewey.net99.net> > And Paul Traina wrote something vaguely similar. > > I think you guys are both missing what I think was Jon's original point: > Routers forward packets faster than PCs, but the forwarding function and > the routing protocol function do not have to reside on the same box. You > can add a PC (workstation, whatever) which runs the routing protocol and > stuffs routes into the router. It doesn't have to support the link-layer > du jour. Ethernet will do the job just fine. > > As I recall the original discussion was of colocating a router, to forward > packets, with a workstation, to compute routes. > So what would the normal implementation of such a design be? ebgp-multihop all of your peers into the PC, and then a single peering session the Cisco, presuming no "next-hop-self" routes? I can see some amount of value in such a design, if it could be made to work correctly. Does anybody have the spare equipment to build a lab? (pfeh, yeah, right) Dave -- Dave Siegel Director of Engineering, Net99 http://www.webcity.com/ (602)249-1083 24x7 NOC line http://www.rtd.com/~dsiegel/ (520)318-0696 My Tucson Office From registry at cerbernet.co.uk Tue Aug 15 21:40:29 1995 From: registry at cerbernet.co.uk (cerbernet registry) Date: Tue, 15 Aug 95 19:40:29 GMT Subject: CIDR FAQ Message-ID: <9508151940.AA27957@phineas.cerbernet.co.uk> > > From: jon at branch.com (Jon Zeeff) > Subject: Re: CIDR FAQ > > > BTW Any BSD4.4 based *NIX (NetBSD, FreeBSD, etc) *does* do CIDR. > > Another reason why some people are thinking that workstations and generic > micros sometimes look pretty good as replacements for "real" routers. > > You get software that works, full source code, faster CPUs, and fewer > memory limitations. At a cost low enough to get a "free" spare. > >Look, I really hate to sound like I have sour grapes, but this thread >keeps coming up and I all hear about the PC router issue is a lot of >talk about price and CPUs, but I don't actually hear any operational >experience about them. > >PCs have been around for years, and even 4.4+reno/gated boxes have been >around as long as cisco/bgp4 boxes. If they really are such a great value, >why the hell aren't "those evil router vendors" out of business in the >Internet market yet? > >Call me thin skinned, but this is really starting to get old. >I would like to personally see the folks who keep extoling the virtues of >roll-your-own solutions either put up or shut up. > >Can we kindly return this thread to: "What boxes don't do classless routing?" > > Here, Here! daniel From vaf at valinor.barrnet.net Tue Aug 15 22:10:22 1995 From: vaf at valinor.barrnet.net (Vince Fuller) Date: Tue, 15 Aug 95 13:10:22 PDT Subject: CIDR FAQ In-Reply-To: Your message of Tue, 15 Aug 1995 11:00:29 -0700 (MST) Message-ID: Please remove CIDRD from the CC list for further discussion of the relative merits of cisco vs. PC routers. This is NOT relavent to the charter of the CIDR Deployment Working Group. Thanks, --Vince (the silent co-chair) From nathan at netrail.net Tue Aug 15 22:22:15 1995 From: nathan at netrail.net (Nathan Stratton) Date: Tue, 15 Aug 1995 16:22:15 -0400 (EDT) Subject: CIDR FAQ In-Reply-To: <199508151800.LAA02521@dewey.net99.net> Message-ID: On Tue, 15 Aug 1995, Dave Siegel wrote: > Let's excuse the fact that gated consumes more memory than a cisco for the > same amount of routes for a second... > > Okay, so let's talk functionality. > > Are there HSSI PCI cards available? Can you do SMDS over this card? Frame? > What about a DS3 ATM card, or higher? > > I know we can do Ethernet, FDDI, sync, and T1 FR, so that's half of it, but > there are still lot's of reason's to buy Cisco gear. > > I'm not excusing the possibility of being able to use PC's, but the additional > management issues of having to manage Unix box's in addition to internal > routing policies, and expansion efforts sounds like a headache. Managing > a network of Cisco's requires a relatively small amount of time, and my staff > and I can concentrate on real problems. Ok, yes you are correct you can't drop a DS3 into the back of a PC, but why not use a 4500 or 7000 for your ds3's and then use a PC to do the major BGP4? On a 4500 I only can put in 32 megs or ram. Yes gated will use more ram for the same number of routes, but I can put 128 meg or more in a PC. I think we need to talk about using PC route servers and cisco together for a solution, the cisco's just can't hold the ram needed. Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales at netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From loco at MFSDatanet.COM Tue Aug 15 23:02:13 1995 From: loco at MFSDatanet.COM (Jonathan Heiliger) Date: Tue, 15 Aug 1995 14:02:13 -0700 Subject: PCs as routers... In-Reply-To: Nathan Stratton "Re: CIDR FAQ" (Aug 15, 4:22pm) References: Message-ID: <9508151402.ZM4655@tweek.mfsdatanet.com> On Aug 15, 4:22pm, Nathan Stratton wrote: > Ok, yes you are correct you can't drop a DS3 into the back of a PC, but > why not use a 4500 or 7000 for your ds3's and then use a PC to do the > major BGP4? On a 4500 I only can put in 32 megs or ram. Yes gated will > use more ram for the same number of routes, but I can put 128 meg or more > in a PC. >-- End of excerpt from Nathan Stratton I don't know if others have mentioned it... but I seem to recall that DEC was developing a PCI based HSSI interface for PCs. It also recently surfaced on one of the zillions of mailing lists. Granted you'd still need a DL 3100 or Larse Access-T45 to do your DS3 <-> HSSI stuff though. -- Jonathan Heiliger oOo Technical Specialist Email: loco at MFSDatanet.COM ooo MFS Datanet, Inc. ------------------------------------------------------------------------ Telephone: [408].975.2259 oOo NCC: [800].637.4872 From tli at cisco.com Wed Aug 16 00:52:27 1995 From: tli at cisco.com (Tony Li) Date: Tue, 15 Aug 1995 15:52:27 -0700 Subject: CIDR FAQ In-Reply-To: (message from Nathan Stratton on Tue, 15 Aug 1995 16:22:15 -0400 (EDT)) Message-ID: <199508152252.PAA19081@greatdane.cisco.com> Ok, yes you are correct you can't drop a DS3 into the back of a PC, but why not use a 4500 or 7000 for your ds3's and then use a PC to do the major BGP4? On a 4500 I only can put in 32 megs or ram. Yes gated will use more ram for the same number of routes, but I can put 128 meg or more in a PC. I think we need to talk about using PC route servers and cisco together for a solution, the cisco's just can't hold the ram needed. That's why there's the 4500M, and the 7000, and ... Tony From nathan at netrail.net Wed Aug 16 02:02:42 1995 From: nathan at netrail.net (Nathan Stratton) Date: Tue, 15 Aug 1995 20:02:42 -0400 (EDT) Subject: CIDR FAQ In-Reply-To: <199508152252.PAA19081@greatdane.cisco.com> Message-ID: On Tue, 15 Aug 1995, Tony Li wrote: > > Ok, yes you are correct you can't drop a DS3 into the back of a PC, but > why not use a 4500 or 7000 for your ds3's and then use a PC to do the > major BGP4? On a 4500 I only can put in 32 megs or ram. Yes gated will > use more ram for the same number of routes, but I can put 128 meg or more > in a PC. > > I think we need to talk about using PC route servers and cisco together > for a solution, the cisco's just can't hold the ram needed. > > That's why there's the 4500M, and the 7000, and ... > and ... ? And what? That is the problem, I go out get a 7000 and then need more ram in a few month I need to get a new router that is vary expensive. Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales at netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From tli at cisco.com Wed Aug 16 02:17:29 1995 From: tli at cisco.com (Tony Li) Date: Tue, 15 Aug 1995 17:17:29 -0700 Subject: CIDR FAQ In-Reply-To: (message from Nathan Stratton on Tue, 15 Aug 1995 20:02:42 -0400 (EDT)) Message-ID: <199508160017.RAA26032@greatdane.cisco.com> and ... ? And what? That is the problem, I go out get a 7000 and then need more ram in a few month I need to get a new router that is vary expensive. That's why we want to deploy CIDR. So we're not caught in this bind... As to the specifics, please consult your cisco salesperson and ask for a nondisclosure presentation on high end futures. Tony From peter at demon.net Wed Aug 16 09:55:47 1995 From: peter at demon.net (peter at demon.net) Date: Wed, 16 Aug 1995 08:55:47 +0100 (BST) Subject: CIDR FAQ In-Reply-To: from "Michael Dillon" at Aug 15, 95 10:56:25 am Message-ID: <9508160856.aa22931@office.demon.net> > > We have. Thanks. We are very happy using Pentiums running NetBSD as > > *core* routers. Three PCI 10/100Mb Ethernet cards. Great stuff. > > 35,000 dialup SLIP/PPP customers can't be that wrong. > > Isn't that 600% growth in customers over the past year? At *least*. We know. Ouch. Regards, -- Peter Galbavy peter at demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/ From peter at demon.net Wed Aug 16 09:59:43 1995 From: peter at demon.net (peter at demon.net) Date: Wed, 16 Aug 1995 08:59:43 +0100 (BST) Subject: CIDR FAQ In-Reply-To: <199508151800.LAA02521@dewey.net99.net> from "Dave Siegel" at Aug 15, 95 11:00:29 am Message-ID: <9508160859.aa23478@office.demon.net> > Let's excuse the fact that gated consumes more memory than a cisco for the > same amount of routes for a second... HA HA HA HA. Sorry, had to laugh. Is my PCI Pentium limited to 64Mb RAM and can only carry ~30k routes? No. Architechture first, penis length second. Memory is only relevant if you can use it efficiently. Same for CPU. > Okay, so let's talk functionality. > > Are there HSSI PCI cards available? Can you do SMDS over this card? Frame? > What about a DS3 ATM card, or higher? I agree, this is where "real" routers are required. However, by the time you can afford the high bandwidth connections you can most definately afford the routers. So the argument goes away. For a T1 line or Ethernet, especially locally in the US (not here) the cost of the router *outweighs* the cost of the line, and so commercial decisions will be made based on router cost. Regards, -- Peter Galbavy peter at demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/ From peter at demon.net Wed Aug 16 10:13:10 1995 From: peter at demon.net (peter at demon.net) Date: Wed, 16 Aug 1995 09:13:10 +0100 (BST) Subject: CIDR FAQ In-Reply-To: <199508160017.RAA26032@greatdane.cisco.com> from "Tony Li" at Aug 15, 95 05:17:29 pm Message-ID: <9508160913.aa27874@office.demon.net> > That's why we want to deploy CIDR. So we're not caught in this > bind... That's back to the mainstream discussion now. I would hope we all realise that CIDR is a sticking plaster and not the ultimate solution to the possible problems in the future ? I am certainly of that mind, and I think that "the CIDR working group" and all of us out here should not become the "Cisco workaround comittee". If you router is non-expandable then bitch to your supplier, be they Cisco, Bay, the-guy-down-the-road-in-the-garage - anyone. BTW - I have not studied the RFC's - so what will IPv6 do for us in the contect of routeing aggregation and latger boxes etc ? Regards, -- Peter Galbavy peter at demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/ From tli at cisco.com Wed Aug 16 10:31:43 1995 From: tli at cisco.com (Tony Li) Date: Wed, 16 Aug 1995 01:31:43 -0700 Subject: CIDR FAQ In-Reply-To: <9508160913.aa27874@office.demon.net> (peter@demon.net) Message-ID: <199508160831.BAA17207@greatdane.cisco.com> If you router is non-expandable then bitch to your supplier, be they Cisco, Bay, the-guy-down-the-road-in-the-garage - anyone. I see we still have an education problem. Sigh. The intrinsic problem is that the routing table is growing faster than we can develop bigger routers. It's not just us. It's growing faster than the computer industry can grow memory either. [The computer industry doubles memory sizes every two years or so. The routing table doubles every nine months.] BTW - I have not studied the RFC's - so what will IPv6 do for us in the contect of routeing aggregation and latger boxes etc ? Absolutely Nothing. You end up back at hierarchical routing. IPv6 gets you a bigger address space, so it actually hurts in that it takes more memory to store a prefix. Tony From alex at kiae.su Wed Aug 16 12:34:25 1995 From: alex at kiae.su (alex at kiae.su) Date: Wed, 16 Aug 95 14:34:25 +0400 Subject: CIDR FAQ References: <199508151928.MAA03857@dewey.net99.net> Message-ID: > So what would the normal implementation of such a design be? ebgp-multihop > all of your peers into the PC, and then a single peering session the Cisco, > presuming no "next-hop-self" routes? > > I can see some amount of value in such a design, if it could be made to work > correctly. Does anybody have the spare equipment to build a lab? (pfeh, yeah, > right) It's just as 'routing policy server' works. There is such projects and it seems there is some good things in this idea. But did anybody see real realisation of this? From alex at kiae.su Wed Aug 16 12:31:59 1995 From: alex at kiae.su (alex at kiae.su) Date: Wed, 16 Aug 95 14:31:59 +0400 Subject: CIDR FAQ References: Message-ID: Sorry, what's the original question? really, we have a great experience with gated and PC based routers there... > At 11:00 AM 8/15/95, Dave Siegel wrote: > >Let's excuse the fact that gated consumes more memory than a cisco for the > >same amount of routes for a second... > > > >Okay, so let's talk functionality. > > > >Are there HSSI PCI cards available? Can you do SMDS over this card? Frame? > >What about a DS3 ATM card, or higher? > > And Paul Traina wrote something vaguely similar. > > I think you guys are both missing what I think was Jon's original point: > Routers forward packets faster than PCs, but the forwarding function and > the routing protocol function do not have to reside on the same box. You > can add a PC (workstation, whatever) which runs the routing protocol and > stuffs routes into the router. It doesn't have to support the link-layer > du jour. Ethernet will do the job just fine. > > As I recall the original discussion was of colocating a router, to forward > packets, with a workstation, to compute routes. > > --John > > > From bilse at EU.net Wed Aug 16 14:45:09 1995 From: bilse at EU.net (Per Gregers Bilse) Date: Wed, 16 Aug 1995 14:45:09 +0200 Subject: CIDR FAQ In-Reply-To: Message-ID: <199508161245.AA08485@jotun.EU.net> On Aug 16, 14:34, alex at kiae.su wrote: > Subject: Re: CIDR FAQ > > So what would the normal implementation of such a design be? ebgp-multihop > > all of your peers into the PC, and then a single peering session the Cisco, > > presuming no "next-hop-self" routes? > > > > I can see some amount of value in such a design, if it could be made to work > > correctly. Does anybody have the spare equipment to build a lab? (pfeh, yeah, > > right) > It's just as 'routing policy server' works. There is such projects > and it seems there is some good things in this idea. > > But did anybody see real realisation of this? This is effectively the way we do ISDN PRI backup -- the BGP host isn't (necessarily) in the same router that is actually switching the traffic. So it does work, yes. (This is all with Ciscos, BTW.) Yes, PCs and other workstations can route traffic too. We know that. But as has been noted, this has little or nothing to with with the I-D, and probably nothing to do with the CIDR FAQ either. It would be very beneficial if everybody tried to stay on track. -- ====== ___ === Per G. Bilse, Mgr Network Operations Ctr ===== / / / __ ___ _/_ ==== EUnet Communications Services B.V. ==== /--- / / / / /__/ / ===== Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / ====== tel: +31 20 6233803, fax: +31 20 6224657 === ======= 24hr emergency number: +31 20 421 0865 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse at EU.net From yakov at cisco.com Wed Aug 16 14:47:43 1995 From: yakov at cisco.com (Yakov Rekhter) Date: Wed, 16 Aug 95 05:47:43 PDT Subject: CIDR FAQ In-Reply-To: Your message of "Wed, 16 Aug 95 09:13:10 BST." <9508160913.aa27874@office.demon.net> Message-ID: <199508161247.FAA11486@hubbub.cisco.com> Peter, > > BTW - I have not studied the RFC's - so what will IPv6 do for us in > the contect of routeing aggregation and latger boxes etc ? > Couple of observations: 1. The ability to aggregate routing information depends on how addresses are assigned, but does not depend on whether addresses are 32 bits wide or 128 bits wide. 2. IPv6 address allocation architecture (see draft-ietf-ipngwg-unicst-addr-allo-01.txt) is the same as IPv4. (just so that folks who read this note would have no doubts, the IPv6 Address Allocation Architecture document was written by Tony Li and myself - the same people who wrote the CIDR Address Allocation Architecture document). Conclusion: In the area of routing aggregation IPv6 will do for us *exactly the same* as what IPv4 does. Yakov. From afink at ping.ch Wed Aug 16 15:22:03 1995 From: afink at ping.ch (Andreas Fink) Date: Wed, 16 Aug 1995 15:22:03 +0200 Subject: CIDR FAQ (off topic) Message-ID: Please dont CC your messages to local-ir at ripe.net. Its off topic there. Thank you ---------------------------------------------------------------- To: peter at demon.net Cc: nathan at netrail.net, dsiegel at net99.net, jon at branch.com, sob at academ.com, bwatson at mci.net, jerry at fc.net, inet-access at earth.com, HANK at taunivm.tau.ac.il, nanog at merit.edu, local-ir at ripe.net, iap at vma.cc.nd.edu, yakov at cisco.com Subject: Re: CIDR FAQ Date: Wed, 16 Aug 95 05:47:43 PDT From: Yakov Rekhter Peter, > > BTW - I have not studied the RFC's - so what will IPv6 do for us in > the contect of routeing aggregation and latger boxes etc ? > Couple of observations: 1. The ability to aggregate routing information depends on how addresses are assigned, but does not depend on whether addresses are 32 bits wide or 128 bits wide. 2. IPv6 address allocation architecture (see draft-ietf-ipngwg-unicst-addr-allo-01.txt) is the same as IPv4. (just so that folks who read this note would have no doubts, the IPv6 Address Allocation Architecture document was written by Tony Li and myself - the same people who wrote the CIDR Address Allocation Architecture document). Conclusion: In the area of routing aggregation IPv6 will do for us *exactly the same* as what IPv4 does. Yakov. Andreas Fink --------------------------------------------------------------------- Ping Net GmbH, Dorfstrasse 21, 8902 Urdorf, Switzerland afink at ping.ch http://www.ping.ch/ Tel: 01-7358333 Fax: 01-7358334 Administration: admin at ping.ch Tech Support: support at ping.ch --------------------------------------------------------------------- Ping Net Sarl, World Trade Cent er, Av. Gratta Paille 2, 1000 Lausanne 30, Switzerland. Tel: 021-6411339 Fax: 021-6411310 --------------------------------------------------------------------- From paul at vix.com Wed Aug 16 16:31:04 1995 From: paul at vix.com (Paul A Vixie) Date: Wed, 16 Aug 1995 07:31:04 -0700 Subject: CIDR FAQ In-Reply-To: Your message of "Wed, 16 Aug 1995 01:31:43 PDT." <199508160831.BAA17207@greatdane.cisco.com> Message-ID: <9508161431.AA19163@gw.home.vix.com> > BTW - I have not studied the RFC's - so what will IPv6 do for us in > the contect of routeing aggregation and latger boxes etc ? > > Absolutely Nothing. You end up back at hierarchical routing. IPv6 > gets you a bigger address space, so it actually hurts in that it takes > more memory to store a prefix. > > Tony the plan is that IPv6 addresses will be allocated hierarchically from day 1, and with proxy aggregation it should be possible for sean's stated goal of "4 routes in the table on some defaultless networks" to be reached. the routing table is no longer doubling every nine months. we've been sort of hanging out in the 25,000 - 30,000 range for almost six months now. the largest single component of the table size comes from old allocations of class c nets, which are 2/3 the total. thus if ipv6 actually comes to pass, and we do start over with new prefixes allocated pseudohierarchically, we may have a lot fewer prefixes, each taking more memory than an ipv4 prefix, yet taking dramatically less memory overall. that's the _plan_, mind you. i don't believe any of it. From nathan at netrail.net Wed Aug 16 16:55:32 1995 From: nathan at netrail.net (Nathan Stratton) Date: Wed, 16 Aug 1995 10:55:32 -0400 (EDT) Subject: CIDR FAQ In-Reply-To: <9508161431.AA19163@gw.home.vix.com> Message-ID: On Wed, 16 Aug 1995, Paul A Vixie wrote: > > BTW - I have not studied the RFC's - so what will IPv6 do for us in > > the contect of routeing aggregation and latger boxes etc ? > > > > Absolutely Nothing. You end up back at hierarchical routing. IPv6 > > gets you a bigger address space, so it actually hurts in that it takes > > more memory to store a prefix. > > > > Tony > > the plan is that IPv6 addresses will be allocated hierarchically from day 1, > and with proxy aggregation it should be possible for sean's stated goal of > "4 routes in the table on some defaultless networks" to be reached. > > the routing table is no longer doubling every nine months. we've been sort > of hanging out in the 25,000 - 30,000 range for almost six months now. > > the largest single component of the table size comes from old allocations of > class c nets, which are 2/3 the total. > Why can' the NIC reallocat the old class c's and use CIDR? Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales at netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From yakov at cisco.com Wed Aug 16 17:07:48 1995 From: yakov at cisco.com (Yakov Rekhter) Date: Wed, 16 Aug 95 08:07:48 PDT Subject: CIDR FAQ In-Reply-To: Your message of "Wed, 16 Aug 95 07:31:04 PDT." <9508161431.AA19163@gw.home.vix.com> Message-ID: <199508161507.IAA25844@hubbub.cisco.com> Paul, > the plan is that IPv6 addresses will be allocated hierarchically from day 1, > and with proxy aggregation it should be possible for sean's stated goal of > "4 routes in the table on some defaultless networks" to be reached. > > the routing table is no longer doubling every nine months. we've been sort > of hanging out in the 25,000 - 30,000 range for almost six months now. > > the largest single component of the table size comes from old allocations of > class c nets, which are 2/3 the total. > > thus if ipv6 actually comes to pass, and we do start over with new prefixes > allocated pseudohierarchically, we may have a lot fewer prefixes, each taking > more memory than an ipv4 prefix, yet taking dramatically less memory overall. The most serious problem we're facing is NOT how to route to the existing allocations, but how we're going to route to all the new allocations that are due to the exponential growth of the Internet. With this in mind, why do you think that IPv6 allocation would be any different than CIDR IPv4 allocations (which is how all the new allocations suppose to be done) ? So far all the documents I've seen on IPv6 address allocation are quite similar to IPv4 address allocation documents. > that's the _plan_, mind you. I think this is not even "the _plan_". I think that is what some of us could wish be "the plan". Yakov. From pst at cisco.com Wed Aug 16 17:55:59 1995 From: pst at cisco.com (Paul Traina) Date: Wed, 16 Aug 1995 08:55:59 -0700 Subject: CIDR FAQ In-Reply-To: Your message of "Wed, 16 Aug 1995 09:13:10 BST." <9508160913.aa27874@office.demon.net> Message-ID: <199508161556.IAA18029@puli.cisco.com> From: peter at demon.net Subject: Re: CIDR FAQ > That's why we want to deploy CIDR. So we're not caught in this > bind... That's back to the mainstream discussion now. I would hope we all realise that CIDR is a sticking plaster and not the ultimate solution to the possible problems in the future ? I am certainly of that mind, and I think that "the CIDR working group" and all of us out here should not become the "Cisco workaround comittee". I don't understand why some folks continue to believe that CIDR is a band-aid or a "Cisco workaround" or some other such rot. That is an utter falacy. CIDR is the exponential growth in resource requirements workaround comittee. It doesn't matter if you're using a PC, a pair of tin cans, or a router, if the number of routes required to maintain connectivity doubles every 6 months, the cost of business for operating on the internet will be prohibitive for everyone except "the big players" you guys are spending your time smacking around. We would be more than happy to sell you a new box, or more certified memory every few months...hell, that sort of stupidity in the marketplace would give us more than enough business justification for high-priority projects. When CIDR was dreamed up, there were two problems it was trying to solve, routing and addressing. If you don't do heirarchical addressing at some places along your heirarchy, then you need to deal with the fact that (a) everyone has all routes (b) everyone is ANNOUNCING all routes (c) when a route flaps, it affects everyone If you router is non-expandable then bitch to your supplier, be they Cisco, Bay, the-guy-down-the-road-in-the-garage - anyone. I rarely see products that are capable of standing more than one or two doublings in CPU and memory capacity. They usually don't sell when they are produced because their initial investment cost is 3x the competition. BTW - I have not studied the RFC's - so what will IPv6 do for us in the contect of routeing aggregation and latger boxes etc ? It's a pity you haven't. IPv6 makes the addressing problem much less of an issue, but raised the number of routes in the internet from 2^32 to 2^128. The only sane way to deal with this is aggregation, AGAIN. So, the same pathetic fools who brought you CIDR are going to ruin your IPv6 dreams before they've started. I would ask that folks consider moving this OFF of the CIDR and NANOG mailing lists and onto com-priv where it is much more "on-topic." Paul From owen at DeLong.SJ.CA.US Wed Aug 16 18:33:36 1995 From: owen at DeLong.SJ.CA.US (Owen DeLong) Date: Wed, 16 Aug 1995 09:33:36 -0700 Subject: CIDR FAQ Message-ID: <199508161633.JAA18530@dixon.DeLong.SJ.CA.US> > Peter, > > > > > BTW - I have not studied the RFC's - so what will IPv6 do for us in > > the contect of routeing aggregation and latger boxes etc ? > > > > Couple of observations: > > 1. The ability to aggregate routing information depends > on how addresses are assigned, but does not depend on whether > addresses are 32 bits wide or 128 bits wide. > > 2. IPv6 address allocation architecture (see > draft-ietf-ipngwg-unicst-addr-allo-01.txt) is the same as IPv4. > (just so that folks who read this note would have no doubts, > the IPv6 Address Allocation Architecture document was written > by Tony Li and myself - the same people who wrote the CIDR Address > Allocation Architecture document). > > Conclusion: > > In the area of routing aggregation IPv6 will do for us *exactly the same* > as what IPv4 does. > With one notable exception.... No allocation legacies. That is there aren't any old badly-distributed ipv6 addresses floating around. This means that ipv6 aggregation should be substantially more effective than ipv4 CIDR has been. > Yakov. > Owen From yakov at cisco.com Wed Aug 16 19:02:08 1995 From: yakov at cisco.com (Yakov Rekhter) Date: Wed, 16 Aug 95 10:02:08 PDT Subject: CIDR FAQ In-Reply-To: Your message of "Wed, 16 Aug 95 09:33:36 PDT." <199508161633.JAA18530@dixon.DeLong.SJ.CA.US> Message-ID: <199508161702.KAA03876@hubbub.cisco.com> Owen, > With one notable exception.... No allocation legacies. That is there aren't > any old badly-distributed ipv6 addresses floating around. This means that > ipv6 aggregation should be substantially more effective than ipv4 CIDR has > been. It is not the legacy allocations that we're concerned with. It is new allocations that we're worry about. Yakov. From poole at eunet.ch Wed Aug 16 19:49:31 1995 From: poole at eunet.ch (Simon Poole) Date: Wed, 16 Aug 1995 19:49:31 +0200 (MET DST) Subject: CIDR FAQ In-Reply-To: <199508161507.IAA25844@hubbub.cisco.com> from "Yakov Rekhter" at Aug 16, 95 08:07:48 am Message-ID: <199508161749.TAA22475@chsun.eunet.ch> Yakov writes: > The most serious problem we're facing is NOT how to route to the existing > allocations, but how we're going to route to all the new allocations that are > due to the exponential growth of the Internet. >From this and an earlier mail (somewhere you said we should "deploy CIDR") I sense some kind of fundamental problem in this discussion. >From -my- point of view CIDR -is- deployed: - we've been allocating from provider blocks for probably two years now, and the number of prefixes announced has been growing -very- slowly (with respect to -new- allocation of addresses), even with customers not returning their addresses when they leave us. Do you have -any- hard data that anything else is happening at a global scale? - there is naturally a tendency for the provider address space to fragment over time, however do we have -any- data that this is causing any of the problems we are seeing (it surely isn't creating a large increase in prefixes -now-)? - nearly -all- of the prefixes we announce are pre-CIDR allocations (B and quite a large number of C's (that we are trying to clean up)), I don't believe this to be different with any other ISP. Yakov, if you have data that CIDR is -not- working for new allocations please present it here. Simon From tli at cisco.com Wed Aug 16 20:02:25 1995 From: tli at cisco.com (Tony Li) Date: Wed, 16 Aug 1995 11:02:25 -0700 Subject: CIDR FAQ In-Reply-To: <199508161749.TAA22475@chsun.eunet.ch> (poole@eunet.ch) Message-ID: <199508161802.LAA09670@greatdane.cisco.com> Yakov, if you have data that CIDR is -not- working for new allocations please present it here. Simon, >From the last CIDRD meeting (Erik-Jan Bos's slides), we have strong data which indicates that the routing table sizes are again growing at the double-every-nine-months rate. Thus the obvious concern. The exact source of this growth has not been determined quantitatively. Tony From tli at cisco.com Wed Aug 16 20:16:41 1995 From: tli at cisco.com (Tony Li) Date: Wed, 16 Aug 1995 11:16:41 -0700 Subject: CIDR FAQ In-Reply-To: <9508160859.aa23478@office.demon.net> (peter@demon.net) Message-ID: <199508161816.LAA10858@greatdane.cisco.com> > Let's excuse the fact that gated consumes more memory than a cisco for the > same amount of routes for a second... HA HA HA HA. Sorry, had to laugh. Is my PCI Pentium limited to 64Mb RAM and can only carry ~30k routes? No. Neither is your 7000. ;-) Wherever you got your numbers from, they're wrong. For a T1 line or Ethernet, especially locally in the US (not here) the cost of the router *outweighs* the cost of the line, and so commercial decisions will be made based on router cost. For a T1, perhaps the monthly charge, but over the lifetime of the line, I don't believe this. Tony From rv at zeus.NIC.DTAG.DE Wed Aug 16 21:14:19 1995 From: rv at zeus.NIC.DTAG.DE (Ruediger Volk) Date: Wed, 16 Aug 1995 21:14:19 +0200 Subject: CIDR FAQ In-Reply-To: Your message of "Wed, 16 Aug 1995 09:33:36 PDT." <199508161633.JAA18530@dixon.DeLong.SJ.CA.US> Message-ID: <14672.808600459@zeus.NIC.DTAG.DE> Owen, > > Conclusion: > > > > In the area of routing aggregation IPv6 will do for us *exactly the same* > > as what IPv4 does. > > > With one notable exception.... No allocation legacies. That is there aren't > any old badly-distributed ipv6 addresses floating around. doesn't the transition strategy foresee to embedded the old cluttered IPv4 space into the new supposedly clean IPv6 megaspace... Thus I suspect the allocation legacy will be inherited. While I agree with Yakov that we need to worry about the new allocations, I think that the legacy is large enough that some garbage collection would be well advised - and could be important for survival under current and future growth. > This means that > ipv6 aggregation should be substantially more effective than ipv4 CIDR has > been. I guess it can be made more effective, because distributing address space over service providers can be done in ways that allow much more space for growth without renumbering into a new bigger contiguous allocation. With the current scarce IPv4 space forces registries to apply slow start allocations for providers - resulting in multiple prefixes for one provider (or the need to renumber more or less complete provider spaces). Considering this (on the very pessimistic side) two questions come to mind: - it seems to me that so far we only have considered to ask for the renumbering of customer networks (when they switch providers, or to kindly release large, inefficiently used spaces), and maybe small access providers. Will things get so tough that I will have to ask my customers to renumber because I need to switch from a clutter of small spaces (as built in slow start and and with allocations not larger then /16) into a larger single prefix space? - even when I started out with provider aggregatable space, and tell customers that address space cannot be moved to another provider and I'm warning them that using their old numbers we cannot guarantee "full" connectivety. - if large scale renumbering needs to happen, the problem seems to be analog to memory allocation systems (on the fly); I faintly remember that this could mean another factor of ineffeciency for the use of space. How much will this reduce the expected life time of the IPv4 space? (well, of course, under exponential growth it will be not very much) BTW we would need to recognize the need for large scale renumbering a couple of years ahead - else we will not have the tools to do it, not to think about the need to educate network and systems administrators... For a more positive perspective: Can we assume that the current "end of the line" routers can be made to deal safely with 45,000 routes? (Seems 64 MB is ok for this; probably somewhat faster processors would be nice to deal with the updates and flapping; how much more thrust would be needed to deal with the computational complexity of the routing problem at this level?) Considering that 45,000 is already 75% of all possible /16 prefixes, could we define the goal of limiting the number of prefixes to 45,000 or some other (but firmly defined) close number? Assuming - we make wise use of space on the new allocations, - we really drop long prefixes for old cluttered space when we get close to the limit, - the typical topology does not change in ways that are require much more router ressources, - we decide quickly, - and we start communicating this to planners and administrators, I think there could be good chance to survive until a high percentage of v4 space is consumed (and the expected life time of our big boxes might be higher and more secure). This should be sufficient for v6 to survive for some time as well; but of course the question of the limit of number of routes needs to be revisited with some different parameters - and hopefully some additional helpful tools, and maybe some new algorithms. Ruediger From nipper at xlink.net Thu Aug 17 00:30:19 1995 From: nipper at xlink.net (Arnold Nipper) Date: Thu, 17 Aug 1995 00:30:19 +0200 (MET DST) Subject: CIDR FAQ In-Reply-To: <199508161749.TAA22475@chsun.eunet.ch> from "Simon Poole" at Aug 16, 95 07:49:31 pm Message-ID: <"xlink100.x.417:16.07.95.22.30.30"@xlink.net> Simon Poole wrote: > > Yakov, if you have data that CIDR is -not- working for new allocations > please present it here. > > Simon CIDR doesn't work as it should. We had to inject all of the more specifics of 194.45/16 cause Sprintlink isn't able to handle CIDR routes correctly. Arnold From davids at on-ramp.ior.com Thu Aug 17 02:33:00 1995 From: davids at on-ramp.ior.com (David J. Schmidt) Date: Wed, 16 Aug 95 17:33 PDT Subject: CIDR FAQ In-Reply-To: <14672.808600459@zeus.NIC.DTAG.DE> (message from Ruediger Volk on Wed, 16 Aug 1995 21:14:19 +0200) Message-ID: Date: Wed, 16 Aug 1995 21:14:19 +0200 From: Ruediger Volk Owen, > > Conclusion: > > > > In the area of routing aggregation IPv6 will do for us *exactly the same* > > as what IPv4 does. > > > With one notable exception.... No allocation legacies. That is there aren't > any old badly-distributed ipv6 addresses floating around. doesn't the transition strategy foresee to embedded the old cluttered IPv4 space into the new supposedly clean IPv6 megaspace... Thus I suspect the allocation legacy will be inherited. While I agree with Yakov that we need to worry about the new allocations, I think that the legacy is large enough that some garbage collection would be well advised - and could be important for survival under current and future growth. Ruediger I thought that the IPv6 address space had fields for a provider number outside of the "legacy" IPv4 address space. Thus "legacy" IPv4 networks can be moved by changing the provider bits in the larger IPv6 address. The routers involved will need to be IPv6 capable, but the individual hosts on a lan continue to use their old IPv4 addresses and do *not* need to be renumbered. The IPv4 networks are now "mobile" and can move from provider to provider providing the routers involved all talk IPv6. Please correct me if I'm wrong. I got this from reading a 3 page overview of IPv6 which I can't find at this momemt. -- David.Schmidt at on-ramp.ior.com Internet On-Ramp, Inc. (509)624-RAMP (7267) Spokane, Washington http://www.ior.com/ (509)622-2866 (fax) From poole at eunet.ch Thu Aug 17 06:35:25 1995 From: poole at eunet.ch (Simon Poole) Date: Thu, 17 Aug 1995 06:35:25 +0200 (MET DST) Subject: CIDR FAQ In-Reply-To: <199508161802.LAA09670@greatdane.cisco.com> from "Tony Li" at Aug 16, 95 11:02:25 am Message-ID: <199508170435.GAA15164@chsun.eunet.ch> > > > Yakov, if you have data that CIDR is -not- working for new allocations > please present it here. > > Simon, > > >From the last CIDRD meeting (Erik-Jan Bos's slides), we have strong > data which indicates that the routing table sizes are again growing at > the double-every-nine-months rate. Thus the obvious concern. The > exact source of this growth has not been determined quantitatively. Tony Which somewhat explains why this group reminds me of a bunch of decapitated hens. Would it be correct to interpret your last sentence as: We don't what the underlying cause of the growth in prefixes is (new allocations, old allocations, ISP's not aggregating). With other words, we don't even know if the I-D in question is fixing the right problem. Simon From tli at cisco.com Thu Aug 17 08:11:29 1995 From: tli at cisco.com (Tony Li) Date: Wed, 16 Aug 1995 23:11:29 -0700 Subject: CIDR FAQ In-Reply-To: <199508170435.GAA15164@chsun.eunet.ch> (poole@eunet.ch) Message-ID: <199508170611.XAA19283@greatdane.cisco.com> Simon, >The exact source of this growth has not been determined quantitatively. Which somewhat explains why this group reminds me of a bunch of decapitated hens. We welcome folks who would like to study it in more detail. We have a surplus of folks interested in flaming, a shortage of those actually interested in the problem (and I include both pro and con participants). Would it be correct to interpret your last sentence as: We don't what the underlying cause of the growth in prefixes is (new allocations, old allocations, ISP's not aggregating). This is overly broad. We have been doing periodic (but irregular!) top-20 non-aggregating ISP reports which clearly show that there are major gains to be had by certain ISP's aggregating. Determining if a particular prefix is the result of someone using an address in the "portable" model is rather difficult as you have to understand their motivation and plans, as well as just the routing data. For example, they may be in the process of doing the renumbering within the organization and may quite legitimately be using multiple prefixes, some from the old provider or a legacy allocation. With other words, we don't even know if the I-D in question is fixing the right problem. I think we have a small misunderstanding here. Erik-Jan's figures as presented in Stockholm are evidence that we still have a problem. The address ownership I-D is _not_ a direct response to that presentation. In fact, the "ownership" presentation was first given in Danvers. This is not cause and effect and I certainly didn't intend it as such. I apologize if I was misleading. To summarize: - We know we still have a bad problem. - We have end users who want "portable" addresses. - Some of them are actually getting them. - There are some ISP's who are not doing a reasonable job of aggregation. - We would like the ISP's to do a better job of aggregation. - "Portable" addresses, by definition, are not aggregateable. - If we can substantially reduce the number of "portable" addresses which are assigned, then we can alleviate one _clear_ cause of the problem. - Other measures are in place to encourage ISP's to aggregate. - Even more measures still remain to be developed. - Most of the Evil Greedy Bastards who espouse CIDR have done a good job of aggregating already. Tony From poole at eunet.ch Thu Aug 17 08:14:41 1995 From: poole at eunet.ch (Simon Poole) Date: Thu, 17 Aug 1995 08:14:41 +0200 (MET DST) Subject: CIDR FAQ In-Reply-To: <199508170435.GAA15164@chsun.eunet.ch> from "Simon Poole" at Aug 17, 95 06:35:25 am Message-ID: <199508170614.IAA20461@chsun.eunet.ch> I write: > > Which somewhat explains why this group reminds me of a bunch of decapitated > hens. > > Would it be correct to interpret your last sentence as: > > We don't what the underlying cause of the growth in prefixes > is (new allocations, old allocations, ISP's not aggregating). > > With other words, we don't even know if the I-D in question is fixing the > right problem. [the CC list is getting very long, I've tried to trim it a bit] Just to provide some hard (haha) data I wipped up a perl script and dumped a full routing table from one of our routers. Daniel Karrenberg has produced similar numbers before if I remember correctly. In any case this allows a large amount of finger pointing (located in Europe I particulary happy with the performance of 193/24), in particular visual inspection of 199/24 would seem to indicate a -lot- of aggregation potential. Format /24 prefix #of prefixes %of total address space announced All usual disclaimers apply (I've not done more than a couple of sanity checks on the data). 6 1 100 9 2 00 12 1 100 13 1 100 16 1 100 17 1 100 18 1 100 20 1 100 26 1 100 32 1 100 33 1 100 34 1 100 35 1 100 36 1 100 38 1 100 39 25 00 40 1 100 44 1 100 45 1 100 46 1 100 50 1 100 57 1 100 128 175 68 129 180 70 130 147 57 131 129 80 132 90 70 133 153 59 134 215 75 135 11 04 136 56 25 137 159 66 138 117 57 139 100 39 140 148 57 141 168 81 142 121 100 143 111 45 144 118 46 145 15 05 146 125 48 147 149 60 148 100 40 149 151 58 150 148 59 151 65 23 152 84 49 153 56 24 154 3 01 155 123 53 156 58 22 157 125 49 158 136 61 159 118 45 160 106 47 161 109 42 162 64 25 163 106 41 164 104 41 165 124 50 166 71 24 167 90 46 168 121 47 169 26 13 170 72 28 171 5 26 192 6743 25 193 1953 100 194 1298 28 195 1 100 196 280 04 197 1 00 198 4109 55 199 3372 54 200 273 09 202 1243 19 203 580 33 204 3013 69 205 1217 33 206 329 19 208 3 00 Simon From yakov at cisco.com Thu Aug 17 15:04:21 1995 From: yakov at cisco.com (Yakov Rekhter) Date: Thu, 17 Aug 95 06:04:21 PDT Subject: CIDR FAQ In-Reply-To: Your message of "Wed, 16 Aug 95 17:33:00 PDT." Message-ID: <199508171304.GAA21503@hubbub.cisco.com> David, > I thought that the IPv6 address space had fields for a provider number > outside of the "legacy" IPv4 address space. Thus "legacy" IPv4 > networks can be moved by changing the provider bits in the larger IPv6 > address. > > The routers involved will need to be IPv6 capable, but the individual > hosts on a lan continue to use their old IPv4 addresses and do *not* > need to be renumbered. The IPv4 networks are now "mobile" and can > move from provider to provider providing the routers involved all talk > IPv6. In IPv6 there is a notion of "IPv4 compatible" addresses. These are IPv6 addresses (128 bits) that have IPv4 address as their low order 32 bits and the rest (96 bits) are zero. If you look at the IPv6 transition then you'll find that it is a so-called "dual stack" transition, where hosts have to have both IPv4 and IPv6. Moreover, to make transition reasoably simple, hosts should have IPv6 addresses that are "IPv4 compatible". A consequence of this, is that the allocation of IPv6 addresses that are "IPv4 compatible" is *exactly the same* as the current IPv4 allocation. So, "legacy networks" would not be able to move "by changing the provider bits in the larger IPv6 address", as "IPv4 compatible" addresses have no "provider bits". What you said is correct only if hosts use IPv6 addresses that are not "IPv4 compatible". But transition with hosts that don't have IPv4 compatible addresses is quite messy. Yakov. From yakov at cisco.com Thu Aug 17 15:16:24 1995 From: yakov at cisco.com (Yakov Rekhter) Date: Thu, 17 Aug 95 06:16:24 PDT Subject: CIDR FAQ In-Reply-To: Your message of "Wed, 16 Aug 95 23:11:29 PDT." <199508170611.XAA19283@greatdane.cisco.com> Message-ID: <199508171316.GAA22091@hubbub.cisco.com> Simon, > With other words, we don't even know if the I-D in question is fixing the > right problem. The "I-D in question" addresses the incompatibility between CIDR and the notion of "address ownership". This incompatibility is *fundamental*. Ignoring it (or pretending that it does not exist) does not make the incompatibility less fundamental. Yakov. From davids at on-ramp.ior.com Thu Aug 17 17:21:00 1995 From: davids at on-ramp.ior.com (David J. Schmidt) Date: Thu, 17 Aug 95 08:21 PDT Subject: CIDR FAQ In-Reply-To: <199508171304.GAA21503@hubbub.cisco.com> (message from Yakov Rekhter on Thu, 17 Aug 95 06:04:21 PDT) Message-ID: cc: rv at zeus.nic.dtag.de, owen at delong.sj.ca.us, inet-access at earth.com, nanog at merit.edu, local-ir at ripe.net Date: Thu, 17 Aug 95 06:04:21 PDT From: Yakov Rekhter David, > I thought that the IPv6 address space had fields for a provider number > outside of the "legacy" IPv4 address space. Thus "legacy" IPv4 > networks can be moved by changing the provider bits in the larger IPv6 > address. > > The routers involved will need to be IPv6 capable, but the individual > hosts on a lan continue to use their old IPv4 addresses and do *not* > need to be renumbered. The IPv4 networks are now "mobile" and can > move from provider to provider providing the routers involved all talk > IPv6. In IPv6 there is a notion of "IPv4 compatible" addresses. These are IPv6 addresses (128 bits) that have IPv4 address as their low order 32 bits and the rest (96 bits) are zero. If you look at the IPv6 transition then you'll find that it is a so-called "dual stack" transition, where hosts have to have both IPv4 and IPv6. Moreover, to make transition reasoably simple, hosts should have IPv6 addresses that are "IPv4 compatible". A consequence of this, is that the allocation of IPv6 addresses that are "IPv4 compatible" is *exactly the same* as the current IPv4 allocation. So, "legacy networks" would not be able to move "by changing the provider bits in the larger IPv6 address", as "IPv4 compatible" addresses have no "provider bits". What you said is correct only if hosts use IPv6 addresses that are not "IPv4 compatible". But transition with hosts that don't have IPv4 compatible addresses is quite messy. Yakov. But isn't it possible to have a router convert from an IPv6 address with provider bits to an IPv4 address by simply stripping all but the lowest 32 bits from the IPv6 address? The hosts on the LAN remain entirely IPv4, but the addresses that leave the router have the provider bits added by the router. Isn't that one of the goals of IPv6? To allow hosts to remain IPv4 and coexist with the IPv6 hosts and backbone? -- David.Schmidt at on-ramp.ior.com Internet On-Ramp, Inc. (509)624-RAMP (7267) Spokane, Washington http://www.ior.com/ (509)622-2866 (fax) From curtis at ans.net Thu Aug 17 19:06:17 1995 From: curtis at ans.net (Curtis Villamizar) Date: Thu, 17 Aug 1995 13:06:17 -0400 Subject: CIDR FAQ In-Reply-To: Your message of "Wed, 16 Aug 1995 23:11:29 PDT." <199508170611.XAA19283@greatdane.cisco.com> Message-ID: <199508171706.NAA00806@brookfield.ans.net> In message <199508170611.XAA19283 at greatdane.cisco.com>, Tony Li writes: > > To summarize: > - We know we still have a bad problem. > - We have end users who want "portable" addresses. > - Some of them are actually getting them. > - There are some ISP's who are not doing a reasonable job of > aggregation. > - We would like the ISP's to do a better job of aggregation. > - "Portable" addresses, by definition, are not aggregateable. > - If we can substantially reduce the number of "portable" > addresses which are assigned, then we can alleviate one > _clear_ cause of the problem. > - Other measures are in place to encourage ISP's to aggregate. > - Even more measures still remain to be developed. > - Most of the Evil Greedy Bastards who espouse CIDR have done > a good job of aggregating already. > > Tony Tony, This would be a good outline for an information RFC giving the status of CIDR deployment. CIDR deployment status is an important issue for the Internet. It is not well understood outside of the NANOG, IEPG, CIDRD community (which are all the same people anyway). With the move to discourage portable addresses, CIDR deployment directly affects a large body of users who don't understand the issues or the broader picture. These users might be less inclined toward accusations that users are taking the brunt of the changes and twoard conspiracy theories if the bigger CIDR deploymnent picture was more clearly presented to them. Curtis From yakov at cisco.com Thu Aug 17 20:03:36 1995 From: yakov at cisco.com (Yakov Rekhter) Date: Thu, 17 Aug 95 11:03:36 PDT Subject: CIDR FAQ In-Reply-To: Your message of "Thu, 17 Aug 95 08:21:00 PDT." Message-ID: <199508171803.LAA13970@hubbub.cisco.com> David, > But isn't it possible to have a router convert from an IPv6 address > with provider bits to an IPv4 address by simply stripping all but the > lowest 32 bits from the IPv6 address? > > The hosts on the LAN remain entirely IPv4, but the addresses that > leave the router have the provider bits added by the router. You can't strip a non-zero part of IPv6 address, as this would cause transport layer pseudo-header checksum to fail. Yakov. From jon at branch.com Thu Aug 17 20:24:02 1995 From: jon at branch.com (Jon Zeeff) Date: Thu, 17 Aug 1995 14:24:02 -0400 (EDT) Subject: CIDR FAQ In-Reply-To: <199508171803.LAA13970@hubbub.cisco.com> from "Yakov Rekhter" at Aug 17, 95 11:03:36 am Message-ID: > > But isn't it possible to have a router convert from an IPv6 address > > with provider bits to an IPv4 address by simply stripping all but the > You can't strip a non-zero part of IPv6 address, as this would cause > transport layer pseudo-header checksum to fail. Unless you recalulate the checksum. There are products out now that do similar things (like map a large set of private ip addresses to a single class C). From yakov at cisco.com Thu Aug 17 20:37:44 1995 From: yakov at cisco.com (Yakov Rekhter) Date: Thu, 17 Aug 95 11:37:44 PDT Subject: CIDR FAQ In-Reply-To: Your message of "Thu, 17 Aug 95 14:24:02 EDT." Message-ID: <199508171837.LAA16420@hubbub.cisco.com> Jon, > > > But isn't it possible to have a router convert from an IPv6 address > > > with provider bits to an IPv4 address by simply stripping all but the > > > You can't strip a non-zero part of IPv6 address, as this would cause > > transport layer pseudo-header checksum to fail. > > Unless you recalulate the checksum. There are products out now > that do similar things (like map a large set of private ip addresses to > a single class C). You're absolutely correct -- Network Address Translation (NAT) boxes do this. Moreover, the use of NAT boxes allows to significantly reduce the problem of IPv4 address space depletion (as sites that use NAT boxes can use private address space out of RFC1597), so that we wouldn't run out of IPv4 addresses any time soon. Yakov. From sob at newdev.harvard.edu Thu Aug 17 21:15:00 1995 From: sob at newdev.harvard.edu (Scott Bradner) Date: Thu, 17 Aug 1995 15:15:00 -0400 (EDT) Subject: CIDR FAQ Message-ID: <199508171915.PAA01161@newdev.harvard.edu> > You can't strip a non-zero part of IPv6 address > as this would cause transport layer pseudo-header checksum to fail which is why the compatable address has 96 0s in the prefix Scott From tli at cisco.com Thu Aug 17 23:25:36 1995 From: tli at cisco.com (Tony Li) Date: Thu, 17 Aug 1995 14:25:36 -0700 Subject: CIDR FAQ In-Reply-To: <199508171706.NAA00806@brookfield.ans.net> (message from Curtis Villamizar on Thu, 17 Aug 1995 13:06:17 -0400) Message-ID: <199508172125.OAA05068@greatdane.cisco.com> Curtis, This would be a good outline for an information RFC giving the status of CIDR deployment. CIDR deployment status is an important issue for the Internet. It is not well understood outside of the NANOG, IEPG, CIDRD community (which are all the same people anyway). With the move to discourage portable addresses, CIDR deployment directly affects a large body of users who don't understand the issues or the broader picture. These users might be less inclined toward accusations that users are taking the brunt of the changes and twoard conspiracy theories if the bigger CIDR deploymnent picture was more clearly presented to them. Thank you, yes I agree. I would very much like to see a volunteer step forward and write such a document. They are welcome to the "outline" and I'll forgo any credit for it. ;-) Tony From yakov at cisco.com Thu Aug 17 23:47:07 1995 From: yakov at cisco.com (Yakov Rekhter) Date: Thu, 17 Aug 95 14:47:07 PDT Subject: CIDR FAQ In-Reply-To: Your message of "Thu, 17 Aug 95 14:25:36 PDT." <199508172125.OAA05068@greatdane.cisco.com> Message-ID: <199508172147.OAA02820@hubbub.cisco.com> Tony, > Thank you, yes I agree. I would very much like to see a volunteer > step forward and write such a document. They are welcome to the > "outline" and I'll forgo any credit for it. ;-) I think I can voluneer for this. Yakov. From HANK at VM.TAU.AC.IL Mon Aug 21 15:25:04 1995 From: HANK at VM.TAU.AC.IL (Hank Nussbacher) Date: Mon, 21 Aug 95 15:25:04 IST Subject: CIDR FAQ - V2 Message-ID: <9508211235.AA06110@ncc.ripe.net> All followups to cidrd only plz... ------------------------------------------------------------------------ The CIDR FAQ | Version 2 | 21 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) hank at vm.tau.ac.il or hank at ibm.net.il If you would like to "discuss" items from this FAQ please send your mail to cidrd at iepg.org This FAQ is being distributed to the following groups and lists: alt.internet.services alt.internet.access.wanted nanog at merit.edu inet-access at earth.com iap at vma.cc.nd.edu local-ir at ripe.net cidrd at iepg.org 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 (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. 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, 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: | cisco 7000 w/ 64Mb cisco 4500 w/ 32Mb | IBM ENSS w/ 64Mb | BayNetworks models AN/ASN/BLN/BCN 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. | 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. |14. What routers on the market today do support CIDR (classless | routing)? | Routers that are capable of handling CIDR are: | | - all Cisco routers running 10.0 or higher | - all Bay Networks routers running 8.01 or higher | - 3Com Netbuilder II and Netbuilder Remote Office | - Telebit EMPB | - Unix w/ BSD/OS 2.0 w/ gated 3.5alpha_11 + radix-fixes | - IBM 2210 routers 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. | 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 *rt: 138.134.0.0/16 *de: NET-IEC *or: AS378 *mb: AS378-MNT *ch: hank at aristo.tau.ac.il 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: HANK at vm.biu.ac.il mnt-by: AS378-MNT admin-c: Hank Nussbacher tech-c: Hank Nussbacher changed: hank at vm.tau.ac.il 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? | 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. |19. 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.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 Contributors: Christian Panigl - Vienna University, Austria Bill Manning - ISI Tony Li - Cisco Systems Havard Eidnes - SINTEF, Norway Yakov Rekhter - Cisco Systems From training at ripe.net Thu Aug 24 11:02:35 1995 From: training at ripe.net (RIPE NCC Training) Date: Thu, 24 Aug 1995 11:02:35 +0200 Subject: Local IR Training Course - Registration Closed Message-ID: <9508240902.AA12943@ncc.ripe.net> Dear Local IR's, The registration for the Local IR Training course in Amsterdam, 16. October 1955 has now been closed. As the course was oversubscribed, we were regrettably, not able to accept everyone. There are still some free places for the courses in Milan, September, 4th 1995. If you are interested in having a course in your country for a number of local IR's, we would be happy to do this. To discuss this further, please send mail to . Kind regards, Mirjam Kuehne RIPE NCC Training Team ------------------------ From training at ripe.net Mon Aug 28 17:59:33 1995 From: training at ripe.net (RIPE NCC Training) Date: Mon, 28 Aug 1995 17:59:33 +0200 Subject: Local IR Training Course - Registration Closed Message-ID: <9508281559.AA04253@ncc.ripe.net> Dear Local IR's, The registration for the Local IR Training course in Milan, 4. September 1995 has now been closed. As the course was oversubscribed, we were regrettably, not able to accept everyone. If you are interested in having a course in your country for a number of local IR's, we would be happy to do this. To discuss this further, please send mail to . As soon as we have scheduled additional Training Courses, we will announce them on the local-ir mailing list. Kind regards, Mirjam Kuehne RIPE NCC Training Team ------------------------ From ncc at ripe.net Tue Aug 29 14:36:27 1995 From: ncc at ripe.net (RIPE NCC Document Annoucement Service) Date: Tue, 29 Aug 1995 14:36:27 +0200 Subject: New Document available: ripe-130 Message-ID: <9508291236.AA15720@ncc.ripe.net> New/Revised RIPE Document Announcement -------------------------------------- A revised/new document is available from the RIPE document store. Ref: ripe-130 Title: The advisory attribute Author: David Kessens, RIPE NCC Date: 1 August 1995 Format: TXT=3230 bytes Obsoletes: Obsoleted by: Updates: ripe-181 Updated by: Old: Short content description ------------------------- This document describes the advisory attribute of the route object. -------------- next part -------------- FTP Access ---------- All RIPE documents and Internet RFC`s are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/docs/" followed by the command "get filename". The relevant filenames for this document are: ripe-130.txt for the ASCII version ripe-130.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server at ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WAIS Access ----------- There is also a "WAIS" server at wais.ripe.net, where there is a WAIS index for RIPE documents "ripe-docs.src" WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. -------------- next part -------------- SEND ripe/docs/ripe-130.txt From ncc at ripe.net Tue Aug 29 17:44:38 1995 From: ncc at ripe.net (RIPE NCC) Date: Tue, 29 Aug 1995 17:44:38 +0200 Subject: RIPE21: Draft Minutes available: ripe-m-21 Message-ID: <9508291544.AA18738@ncc.ripe.net> RIPE Minutes Announcement ------------------------- The RIPE21 minutes are now available from the RIPE document store : ripe-m-21 20th meeting 1995 May GARR/CNR - Roma -------------- next part -------------- FTP Access ---------- All RIPE minutes (and more) are available via anonymous FTP from host ftp.ripe.net. Type "ftp ftp.ripe.net". Login with username "anonymous" supplying your email address as the password. After logging in, type "cd ripe/minutes/" followed by the command "get filename". The relevant filenames for this document are: ripe-m-21.txt for the ASCII version ripe-m-21.ps for the PostScript version Electronic Mail Retrieval of Documents -------------------------------------- Documents can also be retrieved from the RIPE document store using a mail server program. For more information on how to use the program, send email to: mail-server at ripe.net with "send HELP" in the body text. RIPE NCC Interactive Information Server --------------------------------------- Type "telnet info.ripe.net". This is a menu driven service allows the document store to be browsed. After reading documents you are prompted as to whether you would like to receive an email copy of the document you have just read. If you would, you simply enter your email address and the document will be mailed to you. Below are details of alternative methods of access. Gopher Access ------------- The same documents are available via a "gopher" server at "gopher gopher.ripe.net". WWW Access ---------- For those who wish to add this home page at the RIPE NCC to their own customized home pages, it can be accessed as: http://www.ripe.net MIME Mail Reader ---------------- Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the RIPE document by FTP or mail server. -------------- next part -------------- SEND ripe/minutes/ripe-m-21.txt From Roderik.Muit at ripe.net Thu Aug 31 10:23:16 1995 From: Roderik.Muit at ripe.net (Roderik Muit) Date: Thu, 31 Aug 1995 10:23:16 +0200 Subject: ripe-m-21.txt Message-ID: <9508310823.AA12421@ncc.ripe.net> Abovementioned file now has no control characters inside anymore. Apologies, Roderik.