- routing-wg - mailman.ripe.net

Re: 20402 routing entries
by Vadim Antonov 15 Apr '94

15 Apr '94

>We can aggregate all of >202.32/16, but we either have to lie to the NSF and claim all >customers in that block are AUP compliant or all the customers in that >block can't get to the NSFnet. Please note that networks shouldn't be "AUP compliant" to be routed thru NSFNET, they only shouldn't send non-AUP traffic across NSFNET. Since they don't do that now there are good chances they won't do that in the future. NSFNET AUP does not explicitly state what kind of enforcement users should use (if any) and i do not see any sense in assuming that network number filtering is mandatory to be AUP-compliant. >Therefore, we have to break 202.32/16 >into pieces and some service provider up the wire may proxy aggregate >for us. Don't do that! It will hurt many service providers most of which don't have anything to do with NSFNET AUP. Since your commercial traffic won't go to NSFNET anyway you don't run any risk of violating AUP. [As a side note -- here comes another technically unenforceable policy. AUP and Die.]. >Or have I missed something obvious? Yes. Enforcing NSFNET's policy with some (small) probability can prevent abuse of US taxpayers' money; not aggregating will CERTAINLY hurt the whole Internet (not excluding NSFNET) -- most of which wasn't built on US taxpayers' money. --vadim

3 3

Re: 20402 routing entries
by Peter Lothberg 15 Apr '94

15 Apr '94

> When I checked today I noticed that there are about 1,200 more > specific routes that are covered by aggregates (unless my perl code is > broken). I suspect most of these could be withdrawn but it may be > that providers are still waiting to see if any bad things happen. Yeeiks, if they don't withdraw, BIG-bad things will hapen, if they take out the specific routes, small-bad things might hapen. Let's try to gently ask the people who are sending both aggregates and specific routes, to pull their specific routes NOW. -Peter

1 0

Re: 20402 routing entries
by Vadim Antonov 15 Apr '94

15 Apr '94

I would like Merit to start processing CIDR NACRs on priority basis and with less formalities. Also, it won't be a bad idea to *stop* processing NACRs for blocks of consequtive networks and tell people to do aggregation instead. --vadim

2 1

20402 routing entries
by Peter Lothberg 15 Apr '94

15 Apr '94

Folks, We are at the point where action has to be taken, either to get CIDR the 'proper way' or by forced proxy aggregation at some places in the Internet. Are we all really doing our best to cut down the number of routing entries? -Peter

2 1

20402 routing entries
by yakov＠watson.ibm.com 14 Apr '94

14 Apr '94

Ref: Your note of Thu, 14 Apr 94 23:49:40 MET DST Peter, >We are at the point where action has to be taken, either to get >CIDR the "proper way", or by forced proxy aggregation at some >places in the Internet. Let me suggest to pursue a combination of both. Folks who are willing and able to cooperate should pursue the "proper way", and the rest may be subject of proxy aggregation (which may be "forced"). Yakov.

1 0

Re: Corrupted data
by Tony Bates 14 Apr '94

14 Apr '94

Laurent Joncheray <lpj(a)merit.edu> writes: * Could you clean up these data? Some of the policies are not RIPE-81 * compliant. Thanks. * Laurent, while this is interesting it is not very helpful as the users have no idea what objects these errors refer to. Here is some more useful output (at the end) from our DB checker. One caveat - I also note a bug in my parsing of default which I'l fix in a minute. Also, "*am" is certainly valid. You need to update your configuration probably. By the way we also post out errors every now and again anyway, we need to do this more regulalrly. The problem is these got in before we had fully implemented stronger syntax checking barring the bug of course. Tony * alc: reading file "/f/rrdb/dbase-beta/data/ripe.db" (RIPE-DB)... * * ERROR (201339): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*ao: AS1853" * ERROR (201348): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*ai: AS1800 ANY" * ERROR (201349): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*ai: AS1880 ANY" * ERROR (201368): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*df: AS1755 100 AS1755 AS690" * ERROR (201369): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*df: AS1883 200 AS1755 AS690" * ERROR (201382): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*df: AS1880 100 AS1755 AS690" * ERROR (201395): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*df: AS1880 100 AS1755 AS690" * ERROR (201396): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*df: AS1883 200 AS1755 AS690" * ERROR (201414): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*df: AS1755 100 AS1755 AS690" * ERROR (203306): attribute value error in db file /f/rrdb/dbase-beta/data/ri * pe.db: "*ao: AS1755 AND AND NOT (AS1729)" * ERROR (205269): object *am undefined * alc: Printing stat for db RIPE-DB * alc: ipblock: 16075 objects, 38766 count * alc: autsys: 321 objects, 321 count * aut-num: AS1271 descr: DE-NIC unused admin-c: Ruediger Volk changed: rv(a)Informatik.Uni-Dortmund.DE 930310 source: RIPE *ERROR*: mandatory field "tech-c" missing aut-num: AS1752 descr: BT main internal data network guardian: N.Titley(a)axion.bt.co.uk admin-c: Nigel Titley (NT13) tech-c: Nigel Titley (NT13 changed: N.Titley(a)axion.bt.co.uk 930520 source: RIPE *ERROR*: syntax error in "tech-c" *ERROR*: syntax error in "admin-c" aut-num: AS1759 descr: The DataNet IP Service descr: Fi as-in: AS544 50 ANY as-in: AS701 100 ANY as-in: AS1729 100 ANY as-in: AS1732 100 NOT AS544 as-in: AS1755 100 ANY as-out: AS544 ANY as-out: AS701 NOT AS1729 AS1741 AS1755 as-out: AS1729 NOT AS701 AS1741 AS1755 as-out: AS1732 ANY as-out: AS1755 NOT AS701 AS1729 AS1741 guardian: netman(a)noc.datanet.tele.fi admin-c: Seppo Noppari tech-c: netman(a)noc.datanet.tele.fi tech-c: Tapio Aaltio changed: jok(a)noc.datanet.tele.fi 930603 source: RIPE *ERROR*: syntax error in "tech-c" aut-num: AS1853 descr: ACOnet Backbone descr: AT as-out: AS1853 guardian: net-admin(a)cc.univie.ac.at admin-c: Walter Kunft tech-c: Ewald Jenisch changed: Ewald.Jenisch(a)cc.univie.ac.at 930403 source: RIPE *ERROR*: syntax error in "as-out: AS1853" - no routing policy expression given aut-num: AS1878 descr: Peter & Paul's test network as-in: AS1800 ANY as-in: AS1880 ANY as-out: AS1800 ANY as-out: AS1880 ANY guardian: roll(a)stupi.se admin-c: Peter Lothberg tech-c: Peter Lothberg changed: roll(a)stupi.se 930819 source: RIPE *ERROR*: syntax error in "as-in: AS1800 ANY" - cost ANY must be a positive integer *ERROR*: syntax error in "as-in: AS1880 ANY" - cost ANY must be a positive integer aut-num: AS1880 descr: Stupi, house man's policy as-in: AS1755 100 AS1755 AS1653 AS1257 AS1883 as-in: AS1883 200 AS1755 AS1653 AS1257 AS1883 as-in: AS1881 100 AS1881 as-in: AS1882 100 AS1882 as-out: AS1755 AS1880 AS1881 AS1882 AS1883 as-out: AS1883 ANY as-out: AS1881 ANY as-out: AS1882 ANY default: AS1755 100 AS1755 AS690 default: AS1883 200 AS1755 AS690 guardian: Peter Lothberg admin-c: Peter Lothberg tech-c: Peter Lothberg changed: tony(a)ripe.net 930312 source: RIPE *ERROR*: syntax error in "guardian" - guardian must be a mailbox entry aut-num: AS1881 descr: Stupi, toaster network as-in: AS1880 100 ANY as-in: AS1882 100 ANY as-out: AS1800 ANY as-out: AS1802 ANY default: AS1880 100 AS1755 AS690 guardian: Peter Lothberg admin-c: Peter Lothberg tech-c: Peter Lothberg changed: tony(a)ripe.net 930312 source: RIPE *ERROR*: syntax error in "guardian" - guardian must be a mailbox entry aut-num: AS1882 descr: Stupi, house woman's policy as-in: AS1883 200 AS1755 AS1653 AS1257 AS1883 AS1880 AS1881 as-in: AS1880 100 AS1755 AS1653 AS1257 AS1883 AS1880 AS1881 as-out: AS1883 ANY as-out: AS1880 ANY default: AS1880 100 AS1755 AS690 default: AS1883 200 AS1755 AS690 guardian: Ulla Sandberg admin-c: Ulla Sandberg tech-c: Ulla Sandberg changed: tony(a)ripe.net 930312 source: RIPE *ERROR*: syntax error in "guardian" - guardian must be a mailbox entry aut-num: AS1883 descr: Stupi, backboone test network as-in: AS1755 100 ANY as-in: AS1755 50 AS1880 AS1881 AS1882 as-in: AS1653 100 ANY as-in: AS1880 100 AS1880 AS1881 AS1882 as-in: AS1882 300 AS1880 AS1881 AS882 as-out: AS1755 AS1880 AS1881 AS1882 AS1883 AS1653 as-out: AS1653 ANY as-out: AS1880 ANY as-out: AS1882 ANY default: AS1755 100 AS1755 AS690 guardian: Peter Lothberg admin-c: Peter Lothberg admin-c: Bjorn Carlsson tech-c: Peter Lothberg tech-c: Bjorn Carlsson changed: tony(a)ripe.net 930312 source: RIPE *ERROR*: syntax error in "guardian" - guardian must be a mailbox entry aut-num: AS2047 descr: KFKI-RMKI Autonomous system as-in: AS1955 100 AS1955 as-in: AS2547 100 AS2547 as-in: AS2012 100 AS2012 as-in: AS513 100 DEFAULT as-out: AS1955 AS2047 as-out: AS2547 AS2047 as-out: AS2012 AS2047 as-out: AS513 AS2047 default: AS513 100 guardian: giese(a)rmki.kfki.hu admin-c: Piroska Giese tech-c: Piroska Giese changed: giese(a)rmki.kfki.hu 930618 source: RIPE *ERROR*: syntax error in "as-in: AS513 100 DEFAULT" - DEFAULT is not a routing policy KEYWORD aut-num: AS544 descr: The DataNet IP Service descr: Fi as-in: AS1732 100 NOT AS1759 as-in: AS1741 50 NOT AS1759 AS790 as-in: AS1759 100 ANY as-out: AS1732 ANY as-out: AS1741 NOT AS701 AS1729 AS1755 as-out: AS1759 NOT AS1755 guardian: netman(a)noc.datanet.tele.fi admin-c: Seppo Noppari tech-c: DataNet NOC tech-c: Tapio Aaltio changed: jok(a)noc.datanet.tele.fi 030194 source: RIPE *ERROR*: date part of "changed" is not a valid YYMMDD value

1 0

CIDR state
by yakov＠watson.ibm.com 13 Apr '94

13 Apr '94

Ref: Your note of Wed, 13 Apr 1994 16:31:04 +0200 Erik-Jan, >... a possible 227 ASs could start to CIDRize. I doubt that the administrators of all these ASs are on the BGPD mailing list. Therefore, we need to assume that administrators of the Network Service Providers (e.g. regional networks) that connect to these sites to the Internet have to work with these ASs directly. I also think that requiring in the near term all these 227 ASs to perform site-level aggregation by themselves is not very practical (for one thing this would require all these ASs to move to BGP-4). That seems to leave us with only one feasible alternatives -- proxy aggregation, where a CIDR-capable provider generates aggregates on behalf of its clients that are not CIDR-capable. As a way of trying to identify "easy" target first, let me suggest that each provider who is on the BGPD mailing should identify pure stub sites served by the provider. Once identified, the provider can perform proxy aggregation for such a site with no negative impact. Yakov.

1 0

Re: Supernet 192.216
by Steven J. Richardson 13 Apr '94

13 Apr '94

This is great news from Vince and Erik-Jan; let's keep the CIDR use rolling. :-) Steve Richardson/Merit

1 0

Re: Supernet 192.216
by Erik-Jan Bos 12 Apr '94

12 Apr '94

Vince, > Effective today, we have ceased sending most of the explicit routes for the > supernet 192.216/16 to the CIX and have requested that they be removed from > the NSFNET PRDB. The single exception to this change is 192.216.61, which is > multi-homed. > > Assuming no problems are found with 192.216/16, we will next remove all > singly-homed explicit routes in the blocks 198.31/16 and 198.92/14. > > According to the MERIT PRDB, these changes will removed approximately 530 > class-C network routes. According to a recent routing table dump, this will > translate into approximately 210 active routing table entries. Furthermore, > it should cause BARRNet to cease aggrevating the global routing table problem > as the vast majority of our new subscribers are assigned network numbers from > one of our CIDR blocks. > > Anybody else ready to take the plunge? Sure. Today, SURFnet ceased sending any of the explicits in the two large SURFnet CIDR blocks: - 145.0.0.0/9 - 192.87.0.0/16 Some explicits in these blocks remain since the sites using these nets are connected to another provider (but long matches take precedence so no routing problem occurs), but these are not announced by SURFnet (maybe we should try to get those numbers back one day...). This step means that around 60 networks are gone from the routing tables (okay, SURFnet has some smaller numbers than BARRnet :-), but everything helps, IMHO). SURFnet is issuing network numbers from the SURFnet CIDR blocks for customers that are new in the Internet game. SURFnet also "asks gently" from sites that already obtained address space some time ago to renumber to the SURFnet CIDR blocks. Up till now I have been effective in all case except one, since I play this game. This is really worth trying. Who's next? __ Erik-Jan.

1 0

Uninett (AS224) withdraws routes
by Havard Eidnes 08 Apr '94

08 Apr '94

Hi, we have now started announcing the aggregates 129.240.0.0/15 158.36.0.0/14 193.156.0.0/15 and we have withdrawn the more specific routes covered by these aggregates. By doing this we have reduced the number of routing announcements we send to the Internet with approximately 50%, though in real numbers the contribution is small. We know that a number (hopefully small, I'm aware of two...) of european R&D networks will get inoptimal paths for destinations covered by these prefixes, but I still pray that I'll not have to back out this configuration on monday morning... Today's number of routes on the Internet appears to be 20201 (or thereabout). - Havard

1 0