August 1995 - lir-wg - mailman.ripe.net

Re: CIDR FAQ
by jgs＠aads.net 16 Aug '95

16 Aug '95

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

4 4

Re: PCs as routers...
by Jonathan Heiliger 15 Aug '95

15 Aug '95

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(a)MFSDatanet.COM ooo MFS Datanet, Inc. ------------------------------------------------------------------------ Telephone: [408].975.2259 oOo NCC: [800].637.4872

1 0

Re: CIDR FAQ
by Vince Fuller 15 Aug '95

15 Aug '95

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)

1 0

Re: CIDR FAQ
by registry＠cerbernet.co.uk 15 Aug '95

15 Aug '95

> > From: jon(a)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

1 0

Re: CIDR FAQ
by sob＠academ.com 15 Aug '95

15 Aug '95

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

5 5

Local IR Training Course - Registration Closed
by RIPE NCC Training 14 Aug '95

14 Aug '95

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 <training(a)ripe.net>. Kind regards, Mirjam Kuehne RIPE NCC Training Team ------------------------

1 0

Ford asking for space
by RIPE NCC Staff 08 Aug '95

08 Aug '95

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

1 0

CIDR FAQ
by Hank Nussbacher 06 Aug '95

06 Aug '95

All follow-ups to cidrd(a)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(a)vm.tau.ac.il or hank(a)ibm.net.il |If you would like to "discuss" items from this FAQ please send |your mail to cidrd(a)iepg.org |This FAQ is being distributed to the following groups and lists: |alt.internet.services |alt.internet.access.wanted |nanog(a)merit.edu |inet-access(a)earth.com |iap(a)vma.cc.nd.edu |local-ir(a)ripe.net |cidrd(a)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(a)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(a)vm.biu.ac.il mnt-by: AS378-MNT admin-c: Hank Nussbacher tech-c: Hank Nussbacher changed: hank(a)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 <jimi(a)dxcoms.cern.ch> Contributors: Christian Panigl - Vienna University, Austria Bill Manning - ISI Tony Li - Cisco Systems Havard Eidnes - SINTEF, Norway Yakov Rekhter - Cisco Systems

1 0

New Document available: ripe-129
by RIPE NCC Document Annoucement Service 01 Aug '95

01 Aug '95

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. 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(a)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. SEND ripe/docs/ripe-129.txt

1 0

New Document available: ripe-128
by RIPE NCC Document Annoucement Service 01 Aug '95

01 Aug '95

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. 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(a)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. SEND ripe/docs/ripe-128.txt

1 0