- routing-wg - mailman.ripe.net

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

Re: SURFnet CIDR announcements
by jimi＠dxcoms.cern.ch 29 Mar '94

29 Mar '94

>----- Text sent by Erik-Jan Bos follows ------- > This message is to inform you that SURFnet will stop announcing > 192.87.108.0/22 somewhere this week. Instead we will be announcing the > following four CIDR blocks: > - 192.87.0.0/16 (256 Cs, of which 192.87.108/22 is part) > - 145.0.0.0/9 (128 Bs) > - 145.128.0.0/10 (64 Bs) > - 145.192.0.0/11 (32 Bs) > > Soon we will stop announcing some (and later on: all) of the explicit > routes inside the four mentioned CIDR blocks. It depends on several > external factors who quick we will proceed. But the fact that SWITCH will > talk BGP4 real soon now, is very important for this! Erik-Jan, Thanks to SURFnet for this good news. I know from Thomas that SWITCH has similar plans. Would it be possible to know what are the plans of DFN, JANET, RENATER, GARR and other major service providers ? Any date ? Hope to ear from them very soon. We are close to 20,000 routes in Europe now :-) Time is now to use CIDR in production! -- Jean-Michel

2 1

Re: A couple of possibly interesting stats.
by Vadim Antonov 26 Mar '94

26 Mar '94

You don't need a CIDR-capable IGP to have a CIDR-capable network. iBGP-4 + *any* IGP will do the trick. It's a good idea for regionals to start register aggregate NACRs, though. --vadim

2 1

Re: A couple of possibly interesting stats.
by Vince Fuller 26 Mar '94

26 Mar '94

A lot of the regional networks have more than one attachment point to ANSnet. Some use one as primary and one as backup. Most of the regional networks announce some of their networks as primary at one attachment point and other networks at another attachment point. This means that that regional could not aggregate before reaching ANSnet because to do so would mean losing the load balancing. One longer term way around this is to have ANS accept more specific routes plus an aggregate and propogate the more specific routes into it's IBGP but not propogate them further (just the aggregate). Is this really a common case? BARRNet has two attachments to ANS/NSFNET, but they are strictly primary/secondary, so the same aggregates will be advertised at both locations. Any network provider which is using multiple ANS/NSFNET connections to split load should have an addressing plan that assigns a different aggregate to each exit point. The basic rule is: for each routing policy you have, you should have different CIDR block. I thought we'd been over this in at least the Regional Techs forum before. --Vince

6 6

Re: A couple of possibly interesting stats.
by solensky＠ftp.com 25 Mar '94

25 Mar '94

> Seriously - Let's take this discussion of how to make the estimates > more accurate off line or move it to the ALE list (there is one > right?)... Yup: the subscribe address is "ipv4-ale-request(a)ftp.com" Try "ipv4-ale-request(a)research.ftp.com" if you get a bounce message on the former. I'll forward your message over there. > (Hey - it's only memory on the > routers - we'll just plug in 64MB were we need it:). The thought struck me the other day: according to Moore's law, memory performace doubles every two years. If the size of the net tables continue to double every year,.. -- Frank

1 0

Re: A couple of possibly interesting stats.
by solensky＠ftp.com 25 Mar '94

25 Mar '94

> I'm not saying CIDR isn't going to be highly beneficial, it will be. > I'm just saying that Tony's figures are optimistic. This brings up one of the items I wanted to talk about in ALE next week: the figures that I've been generating for the growth charts to estimate how much CIDR helps are also based off Merit's nets.unl files, but look at only the first AS number to decide where the aggregation occurs.. Would that be considered overly pessimistic? -- Frank

4 3