- routing-wg - mailman.ripe.net

Re: CIDR routes: Your input, please (fwd)
by Erik-Jan Bos 21 Mar '94

21 Mar '94

Damir, (Cc: to the Routing WG list, since this might be of interest to more people). > as far as I can see on GARR border router (AS137) now we are receiving > announcement for the two of four networks from block 192.87.108/22. Those > which are explicitly annonced. So, we can't ping your machine 192.87.111.59 > directly as there is no BGP entry for it neither for 192.87.109.0. > > GARR-gw.cnr.it#sh ip bgp 192.87.111.0 > % Network not in table > GARR-gw.cnr.it#sh ip bgp 192.87.109.0 > % Network not in table This is exactly where the fun part is. SURFnet is current announcing 192.87.108.0 and 192.87.110.0 as single class C networks. Furthermore, SURFnet is announcing 192.87.108.0/22 as a CIDR route. Whether or not, you are receiving CIDR routes (which means talking BGP4 in the first place) you should be able to reach 192.87.108.0 and 192.87.110.0, since they are announced explicitly. Your capability to reach 192.87.109.0 (not used at the moment) and 192.87.111.0 (in which my laptoy is living) is fully depending on your ability to interpret the CIDR routes received. As soon as CIDR is fully deployed SURFnet will remove the explicit announcements of 192.87.108.0 and 192.87.110.0 and only advertise 192.87.108.0/22. I read from your message that you are not able to ping (or prtraceroute) to my laptoy. Where are you defaulting to? __ Erik-Jan.

1 0

CIDR routes: Your input, please
by Erik-Jan Bos 21 Mar '94

21 Mar '94

Routing WG, yesterday and this morning I sent some messages on the BGP4 Deployment list, which you might or might not have seen. I am resending parts to this dedicated list, to ask for your help, it will only cost you 2 minutes plus the sending of a mail message. Thanks for your cooperation. --- Start of first message SURFnet currently is announcing 192.87.108/22. Two out of the four Cs in this blocks are also explicitly annonced (192.87.108.0 and 192.87.110.0, these are production nets). I currently have a box (my personal laytoy) running in 192.87.111.0 and on the SURFnet backbone this network is routed. You can try to reach my box (192.87.111.59) doing pings or traceroutes (only), I leave it on tonight, but please be gentle to the laptoy :-). --- End of first message --- Start of second message Many people have been sending traceroutes to me (privately). Thanks for this! Up till now my laptoy has processed 5179 echo request, so you have been trying already. Thanks for any help. Y'all could help me by sending traceroutes to me (privately, I will summarize to the list). Please also fil out this small template when you send in the traceroute: Source Network: .................................... Source ASN : .................................... Country : .................................... --- End of second message Any input, privately, in much valued. __ Erik-Jan.

3 2

Re: CIDR routes: Your input, please
by Erik-Jan Bos 21 Mar '94

21 Mar '94

Daniel, > > Erik-Jan Bos <erik-jan.bos(a)SURFnet.nl> writes: > > Source Network: .................................... > > Source ASN : .................................... > > Country : .................................... > > People on *this* list really should use "prtraceroute -v" instead > of filling in templates .... Absolutely! Please find below an example (only not to interesting): survis bos % prtraceroute -v ejpc5.wind.surfnet.nl traceroute with AS and policy additions [Mar 21 11:06:49 UTC] from AS1103 survis.surfnet.nl (192.87.108.3) to AS1103 ejpc5.wind.surfnet.nl (192.87.111.59) 1 AS1103 surrogate.surfnet.nl 192.87.108.1 [I] 2 AS1103 ejpc5.wind.surfnet.nl 192.87.111.59 [I] AS Path followed: 1103 AS1103 = SURFnet IP The laptoy was off line during the weekend, since I needed it for something else. It's back again. __ Erik-Jan.

1 0

Routing prefixes in the RIPE database?
by Havard Eidnes 11 Mar '94

11 Mar '94

Sorry to those of you who see this twice, I mis-spelt one of the addresses and want both groups to receive copies of any resulting discussion. - Havard ------------------------------ Message-Id: <9403092125.AA28955@ravn> To: routing-wg(a)ripe.net Cc: db-gw(a)ripe.net, hostmaster(a)sunet.se, hostmaster(a)uninett.no Subject: Routing prefixes in the RIPE database? Date: Wed, 09 Mar 1994 22:25:48 +0100 From: Havard Eidnes <Havard.Eidnes(a)runit.sintef.no> Hi, all. I've been thinking about what we should do wrt. routing prefixes that are not "natural" network numbers, ie. what should be done about CIDR routes. This was prompted by fear that the Merit people would get "confused" because the routing prefixes we send in NACRs for these days are not directly found in the RIPE database, but it would perhaps also make sense as seen from a general perspective to register routing prefixes (ie. CIDR routes) in the RIPE database. Point for discussion: 1) should we try to register routing prefixes as such in the RIPE database? I know some argue that should not be necessary, eg. with the counter- argument being "you can use 'show ip bgp <prefix>' and thereby inspect the 'aggregator' attribute to get a handle on where to direct trouble reports" etc. etc. However, this only works as long as the prefix is reachable, so... Also, how will this show up in the BGP routing table if it isn't really BGP routes which are aggregated, but the aggregate is "locally originated" in the AS in question? If I am correct in my guesses here, this all points in the direction of registering the prefixes administratively. If there is consensus that we should try to register routing prefixes in the database, I have the following proposals/suggestions: 2) the routing prefix should be a separate object from the "inetnum" object. The reasoning behind this is that "inetnum" is mostly used for registering assignments of natural network numbers -- the ranges registered are not always of power-of-2 size, so cannot be represented as a single routing prefix. I suggest "rout-pfx" as long-form name. 3) the format when registering a routing prefix could be <IP-prefix>/<bitlen>, eg. "129.240/15" or "129.241.0.0/15" or the obvious in-between. 4) lookup of a "natural IP network number" with WHOIS in the RIPE database should give as result all the routing prefixes it is a part of, as well as the traditional "inetnum" output. Hint for implementation in the RIPE database: from a routing prefix eg. "129.240/15" create keys for all the natural IP network numbers covered by this prefix with pointers to the routing prefix object. This should be a fairly straight-forward approach (say I who haven't really hacked on the RIPE software... ;-) Side-effect: lookup of unassigned network numbers within a routing prefix after this change will no longer give the "No entries found for the selected source(s)" result when whois is used, but instead the routing prefix(es) will be returned, but no inetnum object. I haven't really thought much about what attributes the "rout-pfx" object should/could contain -- there probably shouldn't be all that many, and we can probably give a pointer for recursion via the AS where the aggregate is originated (and we all have our ASes registered, right? ;-). Comments? - Havard

5 5

Routing prefixes in the RIPE database?
by Havard Eidnes 09 Mar '94

09 Mar '94

Hi, all. I've been thinking about what we should do wrt. routing prefixes that are not "natural" network numbers, ie. what should be done about CIDR routes. This was prompted by fear that the Merit people would get "confused" because the routing prefixes we send in NACRs for these days are not directly found in the RIPE database, but it would perhaps also make sense as seen from a general perspective to register routing prefixes (ie. CIDR routes) in the RIPE database. Point for discussion: 1) should we try to register routing prefixes as such in the RIPE database? I know some argue that should not be necessary, eg. with the counter- argument being "you can use 'show ip bgp <prefix>' and thereby inspect the 'aggregator' attribute to get a handle on where to direct trouble reports" etc. etc. However, this only works as long as the prefix is reachable, so... Also, how will this show up in the BGP routing table if it isn't really BGP routes which are aggregated, but the aggregate is "locally originated" in the AS in question? If I am correct in my guesses here, this all points in the direction of registering the prefixes administratively. If there is consensus that we should try to register routing prefixes in the database, I have the following proposals/suggestions: 2) the routing prefix should be a separate object from the "inetnum" object. The reasoning behind this is that "inetnum" is mostly used for registering assignments of natural network numbers -- the ranges registered are not always of power-of-2 size, so cannot be represented as a single routing prefix. I suggest "rout-pfx" as long-form name. 3) the format when registering a routing prefix could be <IP-prefix>/<bitlen>, eg. "129.240/15" or "129.241.0.0/15" or the obvious in-between. 4) lookup of a "natural IP network number" with WHOIS in the RIPE database should give as result all the routing prefixes it is a part of, as well as the traditional "inetnum" output. Hint for implementation in the RIPE database: from a routing prefix eg. "129.240/15" create keys for all the natural IP network numbers covered by this prefix with pointers to the routing prefix object. This should be a fairly straight-forward approach (say I who haven't really hacked on the RIPE software... ;-) Side-effect: lookup of unassigned network numbers within a routing prefix after this change will no longer give the "No entries found for the selected source(s)" result when whois is used, but instead the routing prefix(es) will be returned, but no inetnum object. I haven't really thought much about what attributes the "rout-pfx" object should/could contain -- there probably shouldn't be all that many, and we can probably give a pointer for recursion via the AS where the aggregate is originated (and we all have our ASes registered, right? ;-). Comments? - Havard

1 0

FYI
by jimi＠dxcoms.cern.ch 24 Feb '94

24 Feb '94

>----- Text sent by Andrew Partan follows -------

1 0

AlterNet now doing BGP4 w/ THEnet, PSI, NEARnet, IIJ, NSFNET, ...
by asp＠uunet.uu.net 23 Feb '94

23 Feb '94

AlterNet is now doing BGP4 with additional peers. We are now doing BGP4 with the following peers: CERN/1133 ESnet/293 EUnet/286 ICMnet/1800 IIJ/2509 NEARnet/560 PIPEX/1849 PSInet/174 SprintLink/1239 THEnet/114 TIPnet/1729 Route-Server-Europe/1879 NSFNET/690 (Both ENSS136 & ENSS134) We are not (yet) doing BGP4 with these peers: BARRNet/200 Unknown status CIX/1280 Unknown status DataNet/1759 In the process of deploying Demos/2578 Needs gated w/ BGP4 SURAnet/86 In the process of deploying UUNET-Canada/813 In the process of deploying Route-Server-Merit/183 Unknown status Here are the current CIDR routes that we are seeing: Washington.DC.Alter.Net>show ip bgp cidr BGP table version is 350917, local router ID is 137.39.4.129 Status codes: s suppressed, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i192.64.100.0/22 134.222.5.1 100 100 286 1891 ? *>i192.78.186.0/23 134.222.5.1 100 100 286 1891 ? *> 192.87.136.0/22 192.41.177.241 0 100 1800 1755 1128 1103 1125 i * 192.41.177.240 0 100 1800 1755 1128 1103 1125 i *> 192.91.242.0/23 192.41.177.241 0 100 1800 1755 513 i * 192.41.177.220 0 100 1800 1755 513 i *>i192.244.184.0/21 137.39.224.66 100 100 2509 2497 i *>i192.250.24.0/22 134.222.5.1 100 100 286 1890 i *>i193.0.128.0/20 137.39.1.24 100 100 704 1880 i *>i193.0.160.0/20 137.39.1.24 100 100 704 1880 i *>i193.0.192.0/20 137.39.1.24 100 100 704 1880 i *>i193.0.224.0/20 137.39.1.24 100 100 704 1880 i *> 193.10.8.0/23 192.41.177.241 0 100 1800 1755 1653 2836 i * 192.41.177.240 0 100 1800 1755 1653 2836 i *> 193.44.24.0/22 192.41.177.241 0 100 1800 1755 1653 2836 i * 192.41.177.240 0 100 1800 1755 1653 2836 i *>i193.67.128.0/22 134.222.5.1 100 100 286 1890 i *>i193.74.160.0/20 134.222.5.1 100 100 286 1891 ? *>i193.74.176.0/23 134.222.5.1 100 100 286 1891 ? *>i193.74.192.0/22 134.222.5.1 100 100 286 1891 i *>i193.74.200.0/23 134.222.5.1 100 100 286 1891 i *>i193.74.234.0/23 134.222.5.1 100 100 286 1891 i *>i193.74.236.0/23 134.222.5.1 100 100 286 1891 i *>i193.74.238.0/23 134.222.5.1 100 100 286 1891 i *>i193.74.250.0/23 134.222.5.1 100 100 286 1891 ? *>i193.78.32.0/21 134.222.5.1 100 100 286 1890 i *>i193.78.72.0/22 134.222.5.1 100 100 286 1890 i *>i193.78.104.0/22 134.222.5.1 100 100 286 1890 i *>i193.78.120.0/23 134.222.5.1 100 100 286 1890 i *>i193.242.80.0/21 134.222.5.1 100 100 286 i *> 194.12.128.0/21 192.41.177.241 0 100 1800 1755 513 i * 192.41.177.240 0 100 1800 1755 513 i * i198.84.4.0/22 137.39.1.14 0 100 100 ? *>i 137.39.1.14 0 100 100 ? * i 137.39.1.14 0 100 100 ? *> 199.1.254.0/23 144.228.1.39 100 1239 ? * 192.41.177.241 0 100 1800 1239 ? * 192.41.177.240 0 100 1800 1239 ? -- Jean-Michel

1 0

BGP4 path attribute (sorry)
by jimi＠dxcoms.cern.ch 18 Feb '94

18 Feb '94

Folks, Forget about my previous message. I did not intend to send all this stuff to the list, but just the last paragraph. Sorry again, -- Jean-Michel Another point: the previous drafts of BGP4 were introducing a "BGP path attribute" which was carried together with the route. In some recent extensions of Ripe-81, and after some discussions with Peter Lothberg and Tony Bates, it appeared to us that this could be used to "color" network advertisements and carry this information thru the Internet. Any reason why you've dropped the idea ? Yes, it tends to break aggregation. Since you can't aggregate colored routes together, it would cause people to not aggregate. This would increase the size of the routing tables. Tony -- Jean-Michel

1 0

BGP4 path attribute
by jimi＠dxcoms.cern.ch 18 Feb '94

18 Feb '94

>----- Text sent by Tony Li follows -------

1 0

BGP4/CIDR/aggregation presentations (fwd)
by jimi＠dxcoms.cern.ch 18 Feb '94

18 Feb '94

>----- Text sent by Andrew Partan follows -------

1 0