- routing-wg - mailman.ripe.net

RIPE NCC Region Weekly Routing Report
by Routing Analysis 07 Sep '00

07 Sep '00

This is an automated weekly mailing sent to the RIPE Routing WG e-mail list describing the state of the Internet Routing Table in Europe, Middle East and North Africa. Daily listings are sent to bgp-stats(a)lists.apnic.net For a graphical representation, please see http://www.apnic.net/stats/bgp. If you have any comments please contact Philip Smith <pfs(a)cisco.com>. Europe, Middle East, North Africa Report 08 Sep, 2000 Analysis Summary ---------------- BGP routing table entries examined: 87190 Origin ASes present in the Internet Routing Table: 8426 Origin ASes announcing only one prefix: 2843 Transit ASes present in the Internet Routing Table: 1155 Average AS path length visible in the Internet Routing Table: 5.3 Max AS path length visible: 16 Illegal AS announcements present in the Routing Table: 11 Non-routable prefixes present in the Routing Table: 1 Prefixes being announced from the IANA Reserved Address blocks: 1 Number of addresses announced to Internet: 1169561017 Equivalent to 69 /8s, 182 /16s and 21 /24s Percentage of available address space announced: 31.6 Percentage of allocated address space announced: 61.9 Percentage of available address space allocated: 51.0 RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 13603 Prefixes being announced from the RIPE address blocks: 10610 RIPE Region origin ASes present in the Internet Routing Table: 2260 RIPE Region origin ASes announcing only one prefix: 1085 RIPE Region transit ASes present in the Internet Routing Table: 442 Average RIPE Region AS path length visible: 5.9 Max RIPE Region AS path length visible: 16 Number of RIPE addresses announced to Internet: 75991720 Equivalent to 4 /8s, 135 /16s and 138 /24s Percentage of available RIPE address space announced: 64.7 RIPE AS Blocks 1877 - 1901, 2042, 2047, 2107 - 2136, 2585 - 2614 2773 - 2822, 2830 - 2879, 3154 - 3353, 5377 - 5631 6656 - 6911, 8192 - 9215, 12288 - 13311, 15360 - 16383 RIPE Address Blocks 62/8, 193/8, 194/7, 212/7 and 217/8 RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /19 equiv Description 3301 389 298 TeliaNet Sweden 1257 337 264 Swipnet AB 1270 249 398 UUNET Germany 1849 238 303 PIPEX 702 218 431 UUNET Technologies, Inc. 786 180 959 JANET IP Service 719 177 137 LANLINK 1275 172 834 DFN IP Service 5515 170 354 Sonera Finland 517 153 182 Xlink 3320 151 315 Deutsche Telekom AG 3215 142 144 RAIN 9057 128 42 Level 3 public IP n 2609 127 4 EUnet-TN 2856 125 263 BTnet UK Regional network 3303 120 276 Swisscom 8895 114 28 Saudi Arabia AS 1901 101 76 EUnet Austria 1267 93 955 IUnet S.p.A Global Per AS prefix count summary ---------------------------------- ASN No of nets /19 equiv Description 701 2012 5468 UUNET Technologies, Inc. 1 922 4519 BBN Planet 1221 920 976 Telstra 7018 834 3026 AT&T 2914 713 1343 Verio, Inc. 7046 683 515 UUNET Technologies, Inc. 1239 677 1585 Sprint ICM-Inria 1785 667 803 Sprint ICM 705 637 44 UUNET Technologies, Inc. 3561 622 1527 Cable & Wireless USA 174 604 2741 PSINet Inc. 3549 495 419 Frontier GlobalCenter 271 467 380 BCnet Backbone 2764 462 130 connect.com.au pty ltd 209 460 531 Qwest 3908 443 277 Supernet, Inc. 3602 437 80 Sprint Canada 4293 429 63 Cable & Wireless USA 816 427 177 UUNET Canada4 List of Illegal AS's (Global) ----------------------------- Bad AS Designation Network Transit AS Description 18435 UNALLOCATED 63.102.178.0/23 701 UUNET Technologies, 18436 UNALLOCATED 63.147.24.0/22 701 UUNET Technologies, 18437 UNALLOCATED 63.163.130.0/24 701 UUNET Technologies, 64602 PRIVATE 63.236.57.0/24 209 Qwest 65500 PRIVATE 130.133.0.0/16 12732 V-SPAN 65500 PRIVATE 130.149.0.0/16 12732 V-SPAN 65500 PRIVATE 160.45.0.0/16 12732 V-SPAN 65500 PRIVATE 192.109.42.0/24 12732 V-SPAN 18435 UNALLOCATED 206.137.4.0/22 6347 SAVVIS Communication 18437 UNALLOCATED 207.247.21.0/24 1239 Sprint ICM-Inria 64605 PRIVATE 208.47.206.0/24 209 Qwest Prefixes from private and non-routed address space (Global) ----------------------------------------------------------- Prefix Origin AS Description 169.254.0.0/16 705 UUNET Technologies, Inc. Advertised IANA Reserved Addresses ---------------------------------- Network Origin AS Description 220.10.56.0/24 3215 RAIN Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:22 /9:4 /10:5 /11:9 /12:26 /13:55 /14:179 /15:288 /16:6617 /17:923 /18:1796 /19:5869 /20:3612 /21:3711 /22:5644 /23:7528 /24:50097 /25:147 /26:188 /27:84 /28:70 /29:99 /30:120 /31:0 /32:97 End of report

1 0

Routing comment
by Morgan Dollard 06 Sep '00

06 Sep '00

Hello, In reading the IOS Essentials for ISP's PDF, ver 2.84 http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip i came across something I believe might need a little bit of clarification. I dont know if many ISP's use this method or not, but i find it particularly usefull. On page 29, under the Caveats section, specifically the routing protocols part, it is stated that : ". Routing Protocols. If a routing protocol needs to be run over this link, it is operationally much easier to use IP addresses. Don't use "ip unnumbered" if the customer is peering with you using BGP across the link, or if the link is an internal backbone link. Simply use a network with a /30 address mask. (Routing will work over unnumbered links but the extra management and operational complexity probably outweighs the small address space advantage gained.) " Using Ip unnumbered and BGP is something that works extremely well, in the following case. The wan interface is unnumbered to the ethernet interface. The ethernet interface is using a primary IP that is the one that should be configured on the WAN interface, and a secondary IP that is the LAN IP In most cases, the Provider will want to peer its BGP session to the IP it assigned the customer. This setup allows the BGP session to be peered to the Ethernet interface, which in turns leeds to an end to end point of failure, from the Ethernet Interface, to the Wan Interface. This succesfully allows the ISP to monitor the customer's network availability without the use of piningin methods, and relying solely upon the well being of the BGP session. If this message is off list topic, i apologize for the inconvenience. Morgan Dollard Disclaimer ---------- This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication represents the originator's personal views and opinions, which do not necessarily reflect those of the NSC Group. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify administrator(a)nscglobal.com.

4 3

RE: Routing comment
by Morgan Dollard 04 Sep '00

04 Sep '00

-----Original Message----- From: Mark Lastdrager [mailto:mark@pine.nl] Sent: Monday, September 04, 2000 11:40 To: Morgan Dollard Cc: 'routing-wg(a)ripe.net' Subject: Re: Routing comment At Mon, 4 Sep 2000, owner-routing-wg(a)ripe.net wrote: >In most cases, the Provider will want to peer its BGP session to the IP it >assigned the customer. This setup allows the BGP session to be peered to the >Ethernet interface, which in turns leeds to an end to end point of failure, >from the Ethernet Interface, to the Wan Interface. This succesfully allows >the ISP to monitor the customer's network availability without the use of >piningin methods, and relying solely upon the well being of the BGP session. >But what if the ethernet interface dies? Your BGP session dies with it. >For that reason it is advised to assign the BGP peer address to your >loopback device and set the peering from that address. Exactly, why would you want to keep sending trafic over that WAN link when the router's conection to the lan has failed? MOrgan Mark Lastdrager Pine Internet -- email: mark(a)lastdrager.nl :: ML1400-RIPE :: tel. +31-70-3111010 http://www.pine.nl :: RIPE RegID nl.pine :: fax. +31-70-3111011 PGP key ID 92BB81D1 :: Dutch security news @ http://security.nl Today's excuse: Electrons on a bender Disclaimer ---------- This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication represents the originator's personal views and opinions, which do not necessarily reflect those of the NSC Group. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify administrator(a)nscglobal.com.

3 2

1st draft agenda Routing WG
by SchmitzJo＠aol.com 04 Sep '00

04 Sep '00

Dear colleagues, please find enclosed the first draft of the agenda for the session of the routing working group at RIPE 37, Amsterdam. The session will be held Thursday, 14-September, 9:00 Routing WG session As announced previously, I would also like to point out that this time we have organized a workshop on multicast applications, which will be held Tuesday, 12-September, 10:00 workshop on multicast applications Details of this workshop are listed on the RIPE web pages. As usual comments, additions, changes to the agenda of the Routing WG welcome! --- R I P E 3 7 A M S T E R D A M Routing Working Group Session 14-September-2000 Draft Agenda A. Preliminaries (Joachim Schmitz) (5min) - introduction - participants' list - volunteering of scribe - agenda bashing - RIPE 36 minutes - actions from earlier meetings B. RIPE Database Software Re-Implementation and Transition to RPSL (Andrei Robachevski, Joao Luis Silva Damas) (40min) C. RADB Update (Gerald Winters) (20min) D. Database Operations Update (Andrei Robachevski, Joao Luis Silva Damas) (10min) E. RIS, Status and Plans (Antony Antony, Henk Uijterwaal) (10min) F. Routing Registry Consistency Project (Andrei Robachevski, Joao Luis Silva Damas) (10min) G. Study of BGP Convergence (Abha Ahuja) (20min) H. Internet Routing Table Analysis Update (Philip Smith) (20min) I. RIPE-210 - Updates with contributions from the audience (Christian Panigl, Philip Smith) (20min) Y. General I/O with Other WGs Z. AOB --- Regards Joachim --- JS395-RIPE -- standard disclaimer ---

1 0

RE: Routing comment
by Morgan Dollard 04 Sep '00

04 Sep '00

-----Original Message----- From: Mark Lastdrager [mailto:mark@pine.nl] Sent: Monday, September 04, 2000 11:48 To: Morgan Dollard Cc: 'routing-wg(a)ripe.net' Subject: RE: Routing comment At Mon, 4 Sep 2000, Morgan Dollard wrote: >>But what if the ethernet interface dies? Your BGP session dies with it. >>For that reason it is advised to assign the BGP peer address to your >>loopback device and set the peering from that address. > > >Exactly, why would you want to keep sending trafic over that WAN link when >the router's conection to the lan has failed? ;-) Routers can have more than one ethernet interface. Agreed, maybe i should have made a visio diagram to explain what i meant. I do agree that with 2 or more int interface you would have to use a loopback. In the case however (which is common practice for a lot of isps) where u have 2 paralel routers with 2 different bgp sessions over separate wan links to 2 different pops, runing HSRP between each other and single eth interface on each, the best way for the ISP to make sure that the customer site is still alive without having to use ping's is to make sure that is the eth goes down, the bgp sesion goes down, and the local pref at the POP will then send packets to the second pop's, without having to use back to back's between customer routers. Morgan Mark Lastdrager Pine Internet -- email: mark(a)lastdrager.nl :: ML1400-RIPE :: tel. +31-70-3111010 http://www.pine.nl :: RIPE RegID nl.pine :: fax. +31-70-3111011 PGP key ID 92BB81D1 :: Dutch security news @ http://security.nl Today's excuse: You've been infected by the Telescoping Hubble virus. Disclaimer ---------- This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication represents the originator's personal views and opinions, which do not necessarily reflect those of the NSC Group. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify administrator(a)nscglobal.com.

1 0

The Cidr Report
by Tony Bates 01 Sep '00

01 Sep '00

This is an auto-generated mail on Fri Sep 1 12:00:00 PDT 2000 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 01Sep00 0) General Status Table History ------------- Date Prefixes 250800 85144 260800 91672 270800 91299 280800 91282 290800 85417 300800 85709 310800 85345 010900 85543 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 6240 Number of ASes announcing only one prefix: 3082 (1039 cidr, 2043 classful) Largest number of cidr routes: 589 announced by AS705 Largest number of classful routes: 1076 announced by AS701 1) Gains by aggregating at the origin AS level --- 01Sep00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS10476 2 1 1 50.0% Sinfonet,S.A Panama AS10039 2 1 1 50.0% mire.net AS9983 1 1 0 0.0% Australian Bureau of Statistics. AS9982 1 1 0 0.0% PAICHAI UNIVERSITY AS9981 1 1 0 0.0% Iworld Networking, Inc. AS9979 1 1 0 0.0% KOREA EXCHANGE BANK AS9978 1 1 0 0.0% The University of Seoul AS9977 1 1 0 0.0% IOSYSTEM AS9974 1 1 0 0.0% KOREA SECURITIES COMPUTER CORP. B AS9973 1 1 0 0.0% KEB Futures Co. AS9968 1 1 0 0.0% Kyobo Life Insurance AS9966 1 1 0 0.0% KORAMBANK AS9962 1 1 0 0.0% Sunchon National University AS9960 1 1 0 0.0% NEW C&C CO.,LTD. AS9954 1 1 0 0.0% Kunsan National University AS9953 1 1 0 0.0% Hyundai Eng. & Const. Co., Ltd. AS9951 1 1 0 0.0% D3C Net AS9950 1 1 0 0.0% INT Co.,Ltd. AS9935 1 1 0 0.0% AGNS-Customer-KW AS9927 1 1 0 0.0% A Multihomed ISP Company AS9912 1 1 0 0.0% Quality Internet Services AS9891 1 1 0 0.0% iGreatLink.com AS9879 1 1 0 0.0% OGILVY ASIA/PACIFIC AS9877 1 1 0 0.0% Ngee Ann Polytechnic Computer Cen AS9871 1 1 0 0.0% JC Entertainment Co. AS9868 1 1 0 0.0% Catholic University of TAEGU HYOS AS9866 1 1 0 0.0% LGCAPITAL AS9862 1 1 0 0.0% YES24 CO. LTD AS9859 1 1 0 0.0% ChungCheong College AS9856 1 1 0 0.0% ec-Bank co., Ltd. For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

RE: Routing parts of another LIR's PA block
by Morgan Dollard 01 Sep '00

01 Sep '00

The major problem with Must nots and Should nots, are the underlying assumptions made by vendors. Most vendors will take a should not, and force a Must not so as to be as compliant to RFC specs as possible, and thereafter the feature will slowly become a known Must Not when in fact it is only a Should Not. This has happened before, on a number of different topics, but in the end, we are all subject to misunderstandings. I do agree though, that the practice of origininating prefixes in different AS's, needs to be established as either a should not or must not, and be applied as such. Jay, i do believe that a lack of clarification on such topics in the specs can only cause more ambiguity than anything else, and will lead to uncommon practices beign used. RFC's are documents that are used as reference, and therefor should be as clear as possible on every aspect, so as not to leave ambiguities. Thx, Morgan Dollard -----Original Message----- From: Jay Borkenhagen [mailto:jayb@braeburn.org] Sent: Friday, September 01, 2000 14:40 To: routing-wg(a)ripe.net Subject: Re: Routing parts of another LIR's PA block >> this is not bgp spec. it is rfc 1930, see appended, and is not a >> MUST NOT. Bovio> As you can see above Randy wrote that this is *NOT* a MUST NOT, Bovio> and not the opposite as people seem to believe. However, rfc1930 pre-dates rfc2119/bcp0014. Even though some authors may have used the MUST / MUST NOT / etc. notation prior to rfc2119, not all did: for example rfc1918, a prime candidate for a bunch of MUST NOTs if ever there was one, does not use such notation. Admittedly rfc1930 and rfc1918 are not documents in the standards track for which rfc2119 is most targetted, but that further implies that we can't put too much weight on a missing MUST NOT in rfc1930. I'm sure that if I'm off-base here, Randy will gently correct me. :-) Regardless, I feel that clarification on the correctness of the practice of orginating a prefix in multiple ASes is called for. On this I agree with Philip: Philip> Not commenting on the rights and wrong, but if this is really Philip> a "MUST NOT" it needs to be documented as such. Thanks. Jay B. -- Jay Borkenhagen jayb(a)braeburn.org Disclaimer ---------- This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication represents the originator's personal views and opinions, which do not necessarily reflect those of the NSC Group. If you are not the original recipient or the person responsible for delivering the email to the intended recipient, be advised that you have received this email in error, and that any use, dissemination, forwarding, printing, or copying of this email is strictly prohibited. If you received this email in error, please immediately notify administrator(a)nscglobal.com.

1 0

Re: Routing parts of another LIR's PA block
by Bovio＠aol.com 01 Sep '00

01 Sep '00

In a message dated 8/31/00 7:59:51 PM W. Europe Daylight Time, randy(a)psg.com writes: Folks, I think there is a misunderstanding here: << this is not bgp spec. it is rfc 1930, see appended, and is not a MUST NOT. >> As you can see above Randy wrote that this is *NOT* a MUST NOT, and not the opposite as people seem to believe. Cheers

2 1

Routing parts of another LIR's PA block
by Jacques Caron 01 Sep '00

01 Sep '00

Hi, We have the usual case of a customer asking us to route a /24 out of somebody else's PA block, which I was about to send back to the customer (or at least have him ask for authorization from the "owner" of that range to have it routed as a more specific), but I wanted to give our support people the right RIPE document that says we're not allowed to do that, and I didn't find it... The docs I found (mainly ripe-185) talk about the assignment of the address space, but do not talk about the routing of such blocks. So, is there really a document saying so, or is a customer allowed to ask that as long as he keeps a contractual relationship with the other ISP that allows him to keep the address space? Any pointers welcome. Thanks, Jacques. --- Jacques Caron PSINetworks Europe Network Engineer PSINet Europe Regional Peering Coordinator Mail: Rue Friz-Courvoisier 103 - CH-2100 La Chaux-de-Fonds Phone: +41 32 967 5418

7 9

Re: Routing parts of another LIR's PA block
by Sascha E. Pollok 31 Aug '00

31 Aug '00

Jacques, >Note also that in the case of a multi-homed customer not using BGP, the >route would indeed appear in multiple ASes, and would require the other ISP >to announce its whole PA block _and_ the more specific for load-sharing to >occur... Indeed. I missed that point since we (before becoming a LIR) got an own AS-Number before having any own PA networks except the prefixes from our upstream. The difference there, of course, is the own AS-number. Since there ain't very much AS-numbers (as 2-byte counter, am I right?), no ISP should ever consider getting an own ASN for their to-be multihomed customers. Sure... >It looks to me like it should be prohibited to announce parts of a PA >block. If the customer needs to announce addresses via multiple providers, >he should switch to PI, shouldn't he? Sounds good for me. As long the customer doesn't have an own ASN. Imagine the setup of ISP1, Customer and ISP2. ISP1 has a /19. Customer has a /24 out of the /19. ISP2 is the new upstream to give redundancy / multihoming to Customer. ISP1 announces the /24 as addition to the /19 to their upstreams AND announces the /24 to ISP2. Most companies wouldn't do that because their customer is "Customer" and not ISP1. Anyway, this should work. What do you think? With that setup you wouldn't have inconsistent-ASes. Ok. Redundancy is a little bit complicated, that way. The BGP-speaking router of ISP1 should be physically located at "Customer". GNgh... that is getting too far. >Jacques. Sascha

1 0