- NANOG - lists.nanog.org

The Cidr Report
by Tony Bates 19 May '00

19 May '00

This is an auto-generated mail on Fri May 19 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 19May00 0) General Status Table History ------------- Date Prefixes 080400 75151 090400 75137 100400 75215 110400 75403 120400 75730 130400 75919 010500 76182 020500 76265 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: 5027 Number of ASes announcing only one prefix: 1865 (0 cidr, 1865 classful) Largest number of cidr routes: 0 announced by Largest number of classful routes: 1002 announced by AS701 1) Gains by aggregating at the origin AS level --- 19May00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 437 152 285 65.2% BCnet Backbone AS7046 500 336 164 32.8% COQUI-NET PRTC Internet AS9269 167 29 138 82.6% Hong Kong CTI AS9706 153 26 127 83.0% Pusan Metropolitan City Office of AS1221 529 408 121 22.9% TELSTRA-AS AS2609 123 18 105 85.4% EUnet-TN AS7545 164 66 98 59.8% TPG Internet Pty Ltd AS7657 264 168 96 36.4% The Internet Group Limited AS174 552 464 88 15.9% Performance Systems International AS7496 126 39 87 69.0% Power Up AS9304 109 24 85 78.0% Hutchcity AS9557 100 17 83 83.0% Pakistan Telecommunication Compan AS6429 204 121 83 40.7% RDC-INTERNET AS577 248 172 76 30.6% Bell Backbone AS7029 146 71 75 51.4% UNKNOWN AS209 463 392 71 15.3% Qwest Communications AS7018 529 463 66 12.5% AT&T WorldNet Service Backbone AS1727 162 98 64 39.5% MRMS-WEST AS4293 253 190 63 24.9% Internal ASN for C&W AS724 205 143 62 30.2% UNKNOWN AS7260 111 50 61 55.0% NORLIGHT AS705 270 209 61 22.6% UNKNOWN AS3749 121 61 60 49.6% TECNET AS3602 307 249 58 18.9% Sprint Canada Inc. AS6595 107 50 57 53.3% UNKNOWN AS4740 336 279 57 17.0% Ozemail Pty Ltd (ASN-OZEMAIL) AS5106 81 29 52 64.2% UNKNOWN AS7568 63 18 45 71.4% C.S. Communications Co., Ltd. AS816 308 266 42 13.6% UUNET Canada (ASN-UUNETCA-AS4) AS6528 48 6 42 87.5% WORLD-LYNX 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

IGPs and services?
by nicholas harteau 19 May '00

19 May '00

I'm looking for some advice on IGP tricks such that we can give out the same IPs for a specific service (say...DNS) to all of our customers despite geography and have my IGP route those packets to a regional server, thus accomplishing some inherent level of load balancing, and even eventually returning data based on client geography. I understand that nanog may not be the appropriate forum for this discussion, but I thought perhaps that someone could point me to a better place to discuss this? Or perhaps those of you with experience in the area could email me off-list? -- nicholas harteau nrh(a)ikami.com

11 15

Re: CIDR Report
by Danny McPherson 19 May '00

19 May '00

> If we need to go to Cisco and say, "Hey, make a GSR that does BGP > updates faster", then that's what we need to do! Imposing limitations on > end users which make the internet less useful is not a solution to the > problem, at best it's a kludge which reduces the headache for backbone > providers, but doesn't actually solve any long-term problems. Gee..., why didn't anyone else think of that? Cisco, are you listening? You need to make a GSR that does BGP updates faster, ok? While you're at it, you need to write bug-free software and build routers that never fail, ok? As for the "imposing limitations on end-users which make the (I)internet less useful", well, personally, I'd trade "less useful" for "available" is a second. Though you should understand that those limitations aren't imposed because folks have nothing better to do, they're imposed because people with experience attempt to design things that are reliable, scale well, and are manageable. Having worked for several large service providers, I assure you, hacks and one-offs don't scale well. -danny

13 26

Re: BGP filtering of supernets out of classful space
by Danny McPherson 19 May '00

19 May '00

Perhaps once they contact the provider(s) in question, said provider(s) will realize they're filters are broken. -danny > However, they're running into several providers that are filtering > the announcements because they aren't /24. Experimentation has > proven that announcing /24's will solve this problem. This obviously > clutters up the global routing tables.

1 0

Trying to contact the noc of AS2714
by Thomas Kernen 19 May '00

19 May '00

All, does anyone know who I can reach that manages the AS2714, we have a routing problem that needs to be solved. I've sent e-mails based on the info in the ARIN database but no success. Thanks, Thomas

1 1

Class B address routing
by Kenji Anzai 19 May '00

19 May '00

Hi, All. I'm having problem with our class B address. Last month, we tested our class B address. We announce the address as 2 x /17 from 2 different POP under the same ISP's data center. However, some ISP do NOT accept our route since the address belongs to traditional Class B address, and they told me that they only accept if we announce it as /16. (They filtered out our route…..) I talked to some people, they suggested me that we need to announce the block as /16 from both POP, even though we only like to announce /17 from each POP (Front /17 from one POP, the other /17 from another POP.). How could we do so ? Please help us. |--------- | | POP A | | /17 |------| |----------| | |--------| |-----| ISP C |-- Internet---X----ISP D | ---------| | |--------| Filtered out here… | POP B |------| | /17 | ----------- Regards, Kenji Anzai

2 3

Re[2]: Class B address routing
by Kenji Anzai 18 May '00

18 May '00

Hi, All. Thanks to Todd & All of you helped us. We are really appreciated your help and suggestions. I think that we can do this now. Thanks to all again. Regards, Kenji Anzai On Thu, 18 May 2000 19:33:54 -0400 (EDT) Todd Romero <todd(a)routeflap.net> wrote: > > easily done..redistribute static into bgp with a route map. one /16 static > and one /17 static pointing to Null0. the more specific will override the > /16 always even tho its still there. > > > router bgp xxxx > redistribute static route-map static-to-bgp > ! > ip route x.x.x.x 255.255.0.0 Null0 254 > ip route x.x.x.x 255.255.128.0 Null0 254 > ! > access-list 10 permit x.x.x.x 0.0.255.255 > access-list 10 permit x.x.x.x 0.127.255.255 > ! > route-map static-to-bgp permit 10 > match ip address 10 > ! > > > the only difference at each pop.. your /17 will be different in the static > and ACL. > > > On Thu, 18 May 2000, Kenji Anzai wrote: > > > > > Hi, All. > > > > Thanks for all your replay to help us out. > > They were really helpful. > > > > However, let me add some mor info for this question. > > > > 1. We have 2 routers at each POP, and own AS number. > > 2. The routers use EBGP, and use IBGP between the routers at each POP > > (not between POP). > > 3. 2 POP are located at different location. > > 4. We use same data center company's data center, so our network is > > under the company's network. > > 5. The data center won't aggrigate our netowrk as /16. > > > > After I read all your response, How could we annouce /16 and /17 from > > the same router using BGP ? > > > > Regards, > > > > Kenji > > > > > > On Thu, 18 May 2000 14:04:15 -0400 > > Kenji Anzai <kenji(a)itochu.net> wrote: > > > > > > > > Hi, All. > > > > > > I'm having problem with our class B address. Last month, we tested our class B address. We announce the address as 2 x /17 from 2 different POP under the same ISP's data center. However, some ISP do NOT accept our route since the address belongs to traditional Class B address, and they told me that they only accept if we announce it as /16. (They filtered out our route…..) > > > > > > I talked to some people, they suggested me that we need to announce the block as /16 from both POP, even though we only like to announce /17 from each POP (Front /17 from one POP, the other /17 from another POP.). > > > > > > How could we do so ? Please help us. > > > > > > |--------- | > > > | POP A | > > > | /17 |------| > > > |----------| | |--------| > > > |-----| ISP C |-- Internet---X----ISP D > > > | ---------| | |--------| Filtered out here… > > > | POP B |------| > > > | /17 | > > > ----------- > > > > > > Regards, > > > > > > Kenji Anzai > > > > > > > > > > > > > > > ITIの安齋です。 > > お世話になっております。 > > > > > > ***携帯電話の番号が変わりました*** > > > > *************************************** > > > > Kenji Anzai > > > > Network Engineer > > > > Engineering Department > > Network Operation Group > > > > Itochu Technology, Inc. > > 3100 Patrick Henry Drive > > Santa Clara, CA 94504 > > > > Tel: (408) 653-2817 (Direct) > > Fax: (408) 727-4619 > > Cellular: (408) 910-4170 > > Email: kenji(a)itochu.net > > Pager:1-888-830-3638 > > kenji_pager(a)itochu.net > > (English Only) > > *************************************** > > > > ITIの安齋です。お世話になっております。 ***携帯電話の番号が変わりました*** *************************************** Kenji Anzai Network Engineer Engineering Department Network Operation Group Itochu Technology, Inc. 3100 Patrick Henry Drive Santa Clara, CA 94504 Tel: (408) 653-2817 (Direct) Fax: (408) 727-4619 Cellular: (408) 910-4170 Email: kenji(a)itochu.net Pager:1-888-830-3638 kenji_pager(a)itochu.net (English Only) ***************************************

1 0

Re[2]: Class B address routing
by Kenji Anzai 18 May '00

18 May '00

Hello, Glenn. I already tried it, but they (Our ISP ) told me that they won't do it. At first, they said that they will. However, they said that they won't do it later.... Then, I got this problem... Kenji On Thu, 18 May 2000 17:34:46 -0400 (EDT) Glenn Staniforth <glenns(a)UUNET.CA> wrote: > > > Hello Kenji, > > Do you have your own AS number? Unless I am mistaken, if you do ,the > easiest solution would be to advertise both your /17's vis BGP to your > ISP. So long as they accept them and aggregate your /17's into a /16 you > should have no problems... > > > Glenn Staniforth > MTL CNS Team Lead > UUNET, a Worldcom Company > Tel: (514) 871-2731 > Fax: (514) 875-5735 > http://www.uu.net > http://www.uunet.ca > > On Thu, 18 May 2000, Kenji Anzai wrote: > > > > > Hi, All. > > > > I'm having problem with our class B address. Last month, we tested our class B address. We announce the address as 2 x /17 from 2 different POP under the same ISP's data center. However, some ISP do NOT accept our route since the address belongs to traditional Class B address, and they told me that they only accept if we announce it as /16. (They filtered out our route…..) > > > > I talked to some people, they suggested me that we need to announce the block as /16 from both POP, even though we only like to announce /17 from each POP (Front /17 from one POP, the other /17 from another POP.). > > > > How could we do so ? Please help us. > > > > |--------- | > > | POP A | > > | /17 |------| > > |----------| | |--------| > > |-----| ISP C |-- Internet---X----ISP D > > | ---------| | |--------| Filtered out here… > > | POP B |------| > > | /17 | > > ----------- > > > > Regards, > > > > Kenji Anzai > > > > > > ITIの安齋です。お世話になっております。 ***携帯電話の番号が変わりました*** *************************************** Kenji Anzai Network Engineer Engineering Department Network Operation Group Itochu Technology, Inc. 3100 Patrick Henry Drive Santa Clara, CA 94504 Tel: (408) 653-2817 (Direct) Fax: (408) 727-4619 Cellular: (408) 910-4170 Email: kenji(a)itochu.net Pager:1-888-830-3638 kenji_pager(a)itochu.net (English Only) ***************************************

2 1

Re: IGPs and services?
by ww＠shadowfax.styx.org 18 May '00

18 May '00

-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 >>>>> "Roeland" == Roeland Meyer (E-mail) <rmeyer(a)mhsc.com> writes: >> From: jlewis(a)lewis.org: Wednesday, May 17, 2000 7:15 PM >> Running a routing protocol on a unix box doesn't mean you're >> using it as a router. Roeland> Oh? ... routing, is routing. The distinction is between a device having knowledge of routing tables and forwarding packets -- in fact in most instances where I am doing something like this I have "net.inet.ip.forwarding = 0". - -w - -- Will Waites \________ ww(a)shadowfax.styx.org\____________________________ Idiosyntactix Ministry of Research and Development\ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (OpenBSD) Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/> iQEXAwUBOSQmzQ4cK24IcAwYFAOOlgQAl3Own4xlX5/TkLwwOvHkKdsUHnAY+iBf 2gVYyyvuZ3hoCPvlnOQQkdSFminq7aqPTKldHa1hNkJ7ocoeaYt/9m9/6mXufkHs Z7asWICn6ZkPatOCVr/2fBww8aBATFih7s++j3eXkazc+qBlytPrfhejuFuiy46M vAvGZAKMzDgD/R12yaXjq9kXLD5zWpeBkafWVQvYqfVDDD/oDxFA6mkx/3glCuej xMaj/aOBzHxUGe5AyiKBwHI1i14yElOdvcsmdKLKUKYxyX0dA4cH2DYazfOOgezF 78atAVuDMWD/90IP1blYZnnT13WvS/ULSgpit74L/k87IfBlfugX7Cyu =Rcs6 -----END PGP SIGNATURE-----

2 1

Private ASN suppression
by Howard C. Berkowitz 18 May '00

18 May '00

I'm trying to understand the problem being solved by the Cisco private AS removal feature. In particular, what advantages does it offer over confederations, which would seem to do the same thing when externally advertising customer routes? Is there a performance benefit? RFC1998-style multihoming with a private AS is a possible application, I suppose, for any routes that are NOT marked with NO-EXPORT.

4 5