- routing-wg - mailman.ripe.net

Reachability of a host in CIDR-The Netherlands
by Erik-Jan Bos 22 Mar '94

22 Mar '94

BGPD, here are some results, FYI, regarding the reachibility of my laptoy living in a CIDR-block of which the individual C net is not explicitly announced. The results below are a snapshot of this weekend and yesterday. Some pattern is visible. If you want to test the reachability of ejpc5.wind.surfnet.nl, please do so, I leave it on until 5:30 pm local time (4:30 pm UTC, or 11:30 am EST). --- Start of table NET ASN REGIONAL COUNTRY RESULT ------------ -------- -------------------- ------------- --------- 133.11.0.0 AS 372 NSN-AMES-AS JP Unreach 128.250.0.0 AS 372 NSN-AMES-AS AU Unreach 130.217.0.0 AS 372 NSN-AMES-AS NZ Unreach 128.171.0.0 AS 372 NSN-AMES-AS Hawaii, US Unreach 192.12.192.0 AS 137 GARR IT Reach (%) 130.59.0.0 AS 559 SWITCH CH Reach (*) 158.152.0.0 AS2529 Demon Internet Ltd UK Reach (&) 193.63.94.0 AS 786 JANET IP UK Reach (&) 193.1.193.0 AS1213 HEAnet IE Reach (#) 193.124.134.0 AS2683 RADIO-MSU Network RU Reach (^) 192.36.125.0 AS1653 SUNET SE Reach 130.43.0.0 AS 714 APPLE-ENGINEERING-AS US Reach 192.87.45.0 AS1104 NIKHEF-H NL Reach 147.32.1.0 AS2605 CESNET backbone B CZ Reach 130.206.0.0 AS 766 RedIRIS ES Reach (*) Path from mentioned network to laptoy is through Washington2.Dante.net and icm-dc-1-E0.icp.net. (%) Path from mentioned network to laptoy is through ESnet and NSFnet (San Francisco) and Washington2.Dante.net. (&) Path from mentioned network to laptoy is through ICM. (#) Path from mentioned network to laptoy is through Ebone (although a direct path through EMPB exists). (^) Between Hamburg and Amsterdam is a non-revealed path (all routers return "*" in the traceroute. --- End of table __ Erik-Jan.

5 6

Re: Reachability of a host in CIDR-The Netherlands
by Erik-Jan Bos 22 Mar '94

22 Mar '94

Jeff, > > These now should be reachable to you, 192.87.108/22 was included in > > the reconfiguration of ANS' network done this morning. Also, many fewer > > packets should end up at Washington2.Dante.net since the default has been > > eliminated. > > Thank you very much for the explanation. I'll sleep much better now > (whenever I get to sleep tonight :-( ). Networks MUST be configured in > the Merit/NSFnet PRDB before NSI will route to them. Thanks for this information. Sleep well :-). If you feel up to it, have a look at the following long traceroute output: survis bos % t -m 50 -g munnari.oz.au 192.87.111.59 traceroute to 192.87.111.59 (192.87.111.59), 50 hops max, 40 byte packets 1 Utrecht1.router.surfnet.nl (145.41.49.161) 5 ms 4 ms 4 ms 2 Amsterdam1.router.surfnet.nl (145.41.1.193) 9 ms 9 ms 8 ms 3 Amsterdam1.dante.net (192.87.4.35) 15 ms 10 ms 16 ms 4 194.41.0.18 (194.41.0.18) 591 ms 605 ms 622 ms 5 icm-dc-2-E1.icp.net (192.157.65.225) 576 ms 575 ms 579 ms 6 icm-fix-e-H0-T3.icp.net (192.157.65.122) 1095 ms 719 ms 586 ms 7 192.203.229.246 (192.203.229.246) 579 ms 576 ms 583 ms 8 t3-1.Washington-DC-cnss58.t3.ans.net (140.222.58.2) 590 ms 640 ms 615 ms 9 mf-0.Washington-DC-cnss56.t3.ans.net (140.222.56.222) 588 ms 580 ms 652 ms 10 t3-0.New-York-cnss32.t3.ans.net (140.222.32.1) 591 ms 587 ms 588 ms 11 t3-1.Cleveland-cnss40.t3.ans.net (140.222.40.2) 657 ms t3-0.New-York-cnss32.t3.ans.net (140.222.32.1) 588 ms 651 ms 12 t3-1.Cleveland-cnss40.t3.ans.net (140.222.40.2) 668 ms 597 ms 596 ms 13 t3-2.Chicago-cnss24.t3.ans.net (140.222.24.3) 604 ms 603 ms 609 ms 14 * mf-0.San-Francisco-cnss9.t3.ans.net (140.222.8.193) 795 ms 727 ms 15 t3-0.enss144.t3.ans.net (140.222.144.1) 860 ms 660 ms 652 ms 16 ARC5.NSN.NASA.GOV (192.203.230.12) 653 ms 661 ms 654 ms 17 usa.gw.au (132.160.240.2) 875 ms 832 ms 817 ms 18 national.gw.au (139.130.4.1) 836 ms * 1074 ms 19 rb2.rtr.unimelb.EDU.AU (192.43.209.7) 836 ms 1308 ms 914 ms 20 * itee.rtr.unimelb.EDU.AU (128.250.3.8) 832 ms 1107 ms 21 mulkirri.cs.mu.OZ.AU (128.250.29.2) 855 ms 833 ms 914 ms 22 munnari.OZ.AU (128.250.1.21) 841 ms 943 ms 826 ms 23 mulkirri.cs.mu.OZ.AU (128.250.1.1) 827 ms 856 ms 823 ms 24 itee.rtr.unimelb.EDU.AU (128.250.29.1) 846 ms * 916 ms 25 rb2.rtr.unimelb.EDU.AU (128.250.3.7) 827 ms 854 ms 853 ms 26 vic.GW.AU (192.43.209.1) 920 ms 827 ms 837 ms 27 usa.gw.au (139.130.4.5) 1005 ms 856 ms 842 ms 28 132.160.240.1 (132.160.240.1) 845 ms 842 ms 845 ms 29 * t3-0.enss144.t3.nsf.net (192.203.230.253) 880 ms 832 ms 30 t3-1.San-Francisco-cnss9.t3.ans.net (140.222.9.2) 825 ms 830 ms 866 ms 31 mf-0.San-Francisco-cnss8.t3.ans.net (140.222.8.222) 897 ms * 904 ms 32 t3-0.Chicago-cnss24.t3.ans.net (140.222.24.1) 841 ms * * 33 * t3-0.Cleveland-cnss40.t3.ans.net (140.222.40.1) 1028 ms 831 ms 34 t3-1.New-York-cnss32.t3.ans.net (140.222.32.2) 832 ms 868 ms 832 ms 35 t3-1.Washington-DC-cnss56.t3.ans.net (140.222.56.2) 881 ms 836 ms 1189 ms 36 mf-0.Washington-DC-cnss58.t3.ans.net (140.222.56.194) 836 ms 832 ms 831 ms 37 t3-0.enss145.t3.ans.net (140.222.145.1) 1088 ms 842 ms 832 ms 38 192.203.229.245 (192.203.229.245) 953 ms 963 ms 841 ms 39 icm-dc-2-H0-T3.icp.net (192.157.65.121) 839 ms 831 ms * 40 icm-dante-E0.icp.net (192.157.65.226) 833 ms 916 ms 873 ms 41 194.41.0.17 (194.41.0.17) 830 ms 829 ms 978 ms 42 Amsterdam2.router.surfnet.nl (192.87.4.24) 903 ms 990 ms 997 ms 43 Amsterdam1.router.surfnet.nl (145.41.9.129) 839 ms 838 ms * 44 Utrecht1.router.surfnet.nl (145.41.1.194) 842 ms 840 ms 857 ms 45 ejpc5.wind.surfnet.nl (192.87.111.59) 929 ms 1667 ms 1007 ms Ergo, ejpc5 (in 192.87.111.0) is reachable from Australia. __ Erik-Jan.

1 0

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

21 Mar '94

Damir, > thank you for the explanation. I was affraid that networks 109 and 111 are > populated also. As far as they are empty I am not worried any more. Well, not for these two nets. But you should be worried. > > 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. > > We will probably load our cisco with a new version at the end of this week and > will be able to catch your CIDR route. That's good news. Since EMPB has proven to be BGP4 capable this means that you could be in good shape in the next weeks. > > 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? > > Our default points to ESnet i.e. 3425 293, 3425 291. So I can reach your laptoy > but passing over US. Please send me the output of "prtraceroute ejpc5.wind.surfnet.nl". Thanks. __ Erik-Jan.

1 0

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