- Test - lists.nanog.org

Current filters for BGP announcements
by darren＠bolding.org 03 Aug '99

03 Aug '99

Hello all, I'm sure most, if not all of you are familiar with the filters that various ISP's and NSP's have placed on received BGP announcements. Most famous for this is/was? SprintLinks filter policy, which is documented at http://www.sprintlink.net/filter.htm Recently the subject of announcement filters and route-dampening policy has become increasing relevant to a number of my customers, especially when making sound architecture decisions. Unfortunately, few providers have documented their filter policies (to my knowledge) as well as SprintLink. I'm not even sure Sprint follows the policy anymore. I have specific knowledge of several cases where they are listening to /24's announced by some companies (albeit these are very high profile, and would easily be justified as exceptions to the rule) My question to you, and I believe NANOG to be the most appropriate forum I know of in this regard, is the perenial "what is the current general policy" in this regard. I can think of a few ways to get limitted knowledge about providers policies by checking for received-announcements on edge routers/looking glasses which receive transit from other providers (e.g. go to an MCI customer and look for short prefix announcements known to be announced at, say, Mae-East). Unfortunately, this is not particularly sound, and is high-effort. Further, it does nothing to address the second question of mine, which is what the current typical route-dampening policies are. Third, and this isn't North-American related, so please refer me to better sources, should they exist, are these policies any different for other geographic areas? (e.g. will people listen to smaller announcements at international peering points, do people place different filters for APNIC address space, etc.) Finally, what is the typical reconvergence time for BGP in the global Internet today? For full disclosure, my company makes high availability and load balancing products, and I would certainly prefer these questions be answered in certain ways. I am, however, most interested in the truth so I can give educated advice to my customers. It seems like it is no longer reasonable to keep constant track of who is doing what with routing policies, as it isn't a simple matter of keeping state on 4-8 providers. At least not unless driving BGP sessions is your day-to-day job. Currently, my best answers (qualified with "I may be out of date" are (1) Varies, but a /19 is probably safe, any smaller likely depends on who you buy transit from. (2) Default dampening settings. (3) I don't remember, several ideas were kicked around. (4) 15-20 minutes, depending on lots of variables. Thanks for everyones input on this, any pointers are greatly appreciated. --D -- -- Darren Bolding darren(a)f5.com -- -- Principal Consultant --

1 0

The Cidr Report
by Tony Bates 02 Aug '99

02 Aug '99

This is an auto-generated mail on Fri Jul 30 12:00:00 PDT 1999 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 30Jul99 0) General Status Table History ------------- Date Prefixes 230799 61494 240799 61486 250799 61391 260799 61592 270799 61488 280799 61707 290799 61808 300799 61912 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: 5372 Number of ASes announcing only one prefix: 2813 (1550 cidr, 1263 classful) Largest number of cidr routes: 461 announced by AS701 Largest number of classful routes: 841 announced by AS701 1) Gains by aggregating at the origin AS level --- 30Jul99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 348 147 201 57.8% BCnet Backbone AS2609 121 28 93 76.9% EUnet-TN AS174 578 486 92 15.9% Performance Systems International AS1221 537 445 92 17.1% TELSTRA-AS AS577 280 189 91 32.5% Bell Canada Backbone AS3749 153 63 90 58.8% TECNET AS4293 235 149 86 36.6% IMCI AS7046 322 237 85 26.4% UUNET-CUSTOMER AS4200 182 103 79 43.4% AGIS (Apex Global Information Ser AS7545 141 66 75 53.2% TPG Internet Pty Ltd AS7496 108 34 74 68.5% Power Up AS7657 229 156 73 31.9% The Internet Group Limited AS10928 119 49 70 58.8% UNKNOWN AS9269 76 16 60 78.9% Hong Kong CTI AS4755 138 79 59 42.8% Videsh Sanchar Nigam Ltd. India AS6944 63 6 57 90.5% RapidSite, Inc. AS4740 307 253 54 17.6% Ozemail Pty Ltd (ASN-OZEMAIL) AS719 458 406 52 11.4% LANLINK autonomous system AS2493 159 110 49 30.8% iSTAR Internet, Inc. AS684 91 46 45 49.5% Manitoba Regional Network Backbon AS803 78 34 44 56.4% SaskNet Backbone AS549 215 172 43 20.0% ONet Backbone AS3737 108 67 41 38.0% PenTeleData Inc. (ASN-PTD) AS1785 253 215 38 15.0% NYSERNet Backbone AS209 251 216 35 13.9% Qwest Communications AS1 495 460 35 7.1% BBNPLANET AS10724 42 8 34 81.0% UNKNOWN AS6762 33 2 31 93.9% Telecom Italia international high AS4307 32 1 31 96.9% SVINET-1 AS11515 32 1 31 96.9% UNKNOWN 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

3 2

IMHO, a summary of Y2K statements from around the net
by Sean Donelan 02 Aug '99

02 Aug '99

Last updated August 1, 1999. All information subject to changes and corrections at any time. Verify any information before making any decisions or taking any action. This is not an official statement by any organization listed. Some organizations may be further along than indicated here due to delays updating web pages, or since the last presentation at a public meeting. Exchange Points AMS-IX http://www.ams-ix.net/y2k.html Has arranged for Y2K upgrades LINX http://www.linx.net/Y2Kconf.html Upgrades and/or testing for Y2K completed MAEs EAST http://www.mae.net/ WEST Scheduled to be completed by June 30, 1999 etc. Some have battery backup, some have generators NAPs Chicago http://www.aads.net/ Upgrades and/or testing for Y2K completed Y2K statement available on paper SanFrancisco http://www.pacbell.com/products/business/fastrak/networking/nap/index.html Upgrade in progress NewYork(Pensauken) http://www.sprint.com/ Officially, no comment on NAP readiness Unofficially Y2K ready PAIX Upgrade in progress Battery backup and generator On-site staff and radio backup Address and Name Registries APNIC http://www.apnic.com/statement.html Scheduled to be complete by July 1, 1999 ARIN http://www.arin.net/ Scheduled to be complete by June 30, 1999 Plan to mirror database at RIPE and APNIC NSI http://www.netsol.com/ Scheduled to be completed by June 30, 1999 Battery backup and generator Root servers Not broken out by location Upgrades and/or testing completed Backup power available -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Martian and RFC1918 addresses
by rfuller＠3x.com 31 Jul '99

31 Jul '99

I have been reading Cisco's "Essential IOS Features Every ISP Should Consider" document and came across a section called Martian and RFC1918 networks. It is discussing different bogus or reserved networks that should be filtered by every ISP. In the list are some addresses I thought were legal and after checking the ARIN Whois database, some of them seem to be. Can anyone give me some additional information as to the need to filter the following networks: 1.0.0.0 reserved for IANA 19.255.0.0 this belongs to Ford 59.0.0.0 reserved for IANA 129.156.0.0 this belongs to SUN 169.254.0.0 IANA use for local link numbers??? 192.0.2.0 reserved for IANA 192.5.0.0 no ARIN match 192.9.200.0 no ARIN match 192.9.99.0 this belongs to SUN If you can elaborate on what they are used for and if any problems would arise from filtering these networks, it would be appreciated. If you could also please include where you found the information, I would appreciate it. Some of them belong to companies, so why would you filter them? Are they development networks for Ford and SUN? Are there any other martian networks that should be filtered? Here is the URL for the doc if anyone is interested: http://www.cisco.com/public/cons/isp/documents/IOSEssentialsPDF.zip Thanks in advance! Ron Fuller, CCDP, CCNP-ATM, MCNE, MCP 3X Corporaton rfuller(a)3x.com

3 2

Can someone PLEASE fix this?
by John Fraizer 30 Jul '99

30 Jul '99

Will someone please remove steve.murray(a)wcom.com from the nanog list until he or his provider learns how to properly route email? Every message I send to NANOG results in a bounce from his provider: ----- The following addresses had permanent fatal errors ----- shmurray(a)gwsmtp.wcom.com (expanded from: <steve.murray(a)wcom.com>) ----- Transcript of session follows ----- 554 Too many hops 26 (25 max): from <John.Fraizer(a)EnterZone.net> via gwsmtp2.wcom.com, to <steve.murray(a)wcom.com> Reporting-MTA: dns; ndcrelay.mcit.com Received-From-MTA: DNS; gwsmtp2.wcom.com Arrival-Date: Fri, 30 Jul 1999 22:40:54 GMT Final-Recipient: RFC822; steve.murray(a)ndcrelay.mcit.com X-Actual-Recipient: RFC822; shmurray(a)gwsmtp.wcom.com Action: failed Status: 5.0.0 ------------ John Fraizer ------------ mailto:john.fraizer@EnterZone.Net http://www.EnterZone.Net http://www.EZ-Hosting.Net http://www.EZ-IP.Net ------------------------------------------ | __ _ | | | / / (_)__ __ ____ __ | The choice | | / /__/ / _ \/ // /\ \/ / | of a GNU | | /____/_/_//_/\_,_/ /_/\_\ | Generation | | | | ------------------------------------------

1 0

IS-IS and OSPF
by Johnson Kuruvila 30 Jul '99

30 Jul '99

Hi All, I hope this mail is appropriate for the charter of Nanog. Pardon me if it is not. Could someone comment on: Normally, is there is a need to run both IS-IS and OSPF on the same interface on a router? How does the vendors today support this? Thanks a million, --Johnson

2 1

Open Access debate out of hand?
by David Brouda 30 Jul '99

30 Jul '99

News.com has posted a Reuters story titled "Cisco under fire from "open access" groups" <http://www.news.com/News/Item/0,4,39939,00.html?st.ne.fd.tohhed.ni> Here's one sample statement: Referring to product literature passed out at a recent industry trade show by Cisco, one representative said, "This is the owner's manual that they're providing to the cable industry to monopolize the Internet," according to Jeff Chester, executive director of the Center for Media Education. The claims are that QoS gives companies too much control. I think it's time someone with a clue help them right a story. Perhaps this has gotten out of hand? -David

1 0

Sprint duplicate packets
by bcurnow 30 Jul '99

30 Jul '99

I don't have any NOC contacts, but since I saw the other post about Sprint duplicates, I thought I would mention that the following Sprint router also appears to have a problem: # ping 144.232.9.86 PING 144.232.9.86 (144.232.9.86): 56 data bytes 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=86.4 ms 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=92.0 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=110.3 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=121.5 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=162.7 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=168.4 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=174.9 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=195.5 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=233.8 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=239.5 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=247.0 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=263.7 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=281.4 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=299.7 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=318.0 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=335.6 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=375.5 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=406.4 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=412.1 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=438.1 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=443.8 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=449.6 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=471.8 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=478.1 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=495.3 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=513.3 ms (DUP!) 64 bytes from 144.232.9.86: icmp_seq=0 ttl=243 time=551.4 ms (DUP!) Traffic going through that router only seems to double once, though. It has been doing it for at least two days. ----------------- Brian Curnow ----------------

2 1

Mysterious Mae-East Packets
by Deepak Jain 29 Jul '99

29 Jul '99

On our interface(s) at Mae-East we have been seeing some of the following: Jul 29 17:09:51: %SEC-6-IPACCESSLOGP: list 103 denied udp 0.0.0.0(1610) (Fddi1/1/0 0040.0bc0.6c25) -> 255.255.255.255(67), 1 packet Anyone know who belongs to/masquerades behind ARP address 0040.0bc0.6c25? Thanks for any assistance/advice. Deepak Jain AiNET

1 0

InterNIC oddities
by Daniel Senie 29 Jul '99

29 Jul '99

The WHOIS database seems to be updated at random intervals. Today, it never did get updated. The data is more than 24 hours stale in the WHOIS database, and the "last updated" time is being reported as yesterday, mid-morning. The name servers do appear to be up-to-date, though. The F.ROOT-SERVERS.NET machine has an out-of-date com. zone. The other name servers seem to be up-to-date, and the F server is OK for the net and org domains, and the root domain. Only the com TLD is out of date (5 days old). On a positive note, the domain name modification forms appear to be back from the dead. -- ----------------------------------------------------------------- Daniel Senie dts(a)senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com

5 6