- routing-wg - mailman.ripe.net

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 01 Sep '00

01 Sep '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

IP allocs on the NAPs/IXs
by Berislav Todorovic 31 Aug '00

31 Aug '00

Hello, Apologies if this is a FAQ, but I really didn't find any site that contains a list of IP address allocations/assignments for various Internet exchange points worldwide. Is there any list of NAP addresses available? Such a thing would be useful to filter out leaking NAP address announcements from peers. Thanks in advance for any information! Regards, Beri --------- Berislav Todorovic, Network Engineer --------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri(a)kpnqwest.net <=> beri(a)EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. -----

1 0