- NANOG - lists.nanog.org

Power Problem at MAE-West
by mwinter＠exodus.net 20 Feb '99

20 Feb '99

Mae-West (MFS location) has currently a power problem (since 9am PST) - in case you have some peers down, this is likely the problem. MFS Master ticket: 383730 - Martin Winter Exodus Communications (yeah.. our router is one of the affected ones :-( )

1 0

The Cidr Report
by Tony Bates 19 Feb '99

19 Feb '99

This is an auto-generated mail on Fri Feb 19 12:00:00 PST 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 19Feb99 0) General Status Table History ------------- Date Prefixes 120299 55713 130299 55907 140299 55818 150299 55997 160299 56035 170299 56178 180299 56403 190299 56528 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: 4569 Number of ASes announcing only one prefix: 2279 (1216 cidr, 1063 classful) Largest number of cidr routes: 353 announced by AS701 Largest number of classful routes: 850 announced by AS701 1) Gains by aggregating at the origin AS level --- 19Feb99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 353 138 215 60.9% BCnet Backbone AS2493 273 155 118 43.2% iSTAR Internet, Inc. AS174 652 536 116 17.8% Performance Systems International AS11305 116 8 108 93.1% UNKNOWN AS3749 149 65 84 56.4% TECNET AS1267 107 29 78 72.9% IUNET-AS AS4293 222 148 74 33.3% IMCI AS4755 151 80 71 47.0% Videsh Sanchar Nigam Ltd. India AS7046 280 215 65 23.2% UUNET-CUSTOMER AS4200 161 98 63 39.1% AGIS (Apex Global Information Ser AS4740 386 325 61 15.8% Ozemail Pty Ltd (ASN-OZEMAIL) AS1239 521 464 57 10.9% SprintLink Backbone AS1221 407 351 56 13.8% AARNET-AS AS7545 110 55 55 50.0% TPG Internet Pty Ltd AS7657 142 90 52 36.6% The Internet Group Limited AS72 89 37 52 58.4% Schlumberger Information Network AS10928 104 53 51 49.0% UNKNOWN AS577 222 172 50 22.5% Bell Canada Backbone AS7496 76 27 49 64.5% Power Up AS719 456 410 46 10.1% LANLINK autonomous system AS852 173 135 38 22.0% AGT Advance Communication AS5674 64 27 37 57.8% PBI-NET-BLK AS803 72 36 36 50.0% SaskNet Backbone AS701 850 814 36 4.2% Alternet AS6897 63 27 36 57.1% Global-One Spain AS7122 112 77 35 31.2% MTS ADVANCED Network Policy AS1785 249 217 32 12.9% NYSERNet Backbone AS6332 97 66 31 32.0% TELNOR AS4307 32 1 31 96.9% SVINET-1 AS2707 63 32 31 49.2% WEC 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: honoring AS-path prepend from a peer or customer?
by Avi Freedman 19 Feb '99

19 Feb '99

In article <99118.183518.5014(a)avi.netaxs.com> you wrote: : If a peer (or transit customer) prepends their own AS to : their route announcements to you, do you ever strip off : the excessive As'es? That is, do you always honor them : in your announcements to your other customers (or peers)? : I do understand that any operator has full control over : deciding his own outbound policy, regardless of the : AS path. : I want to know what the industry practice is and whether : I should stipulate in my next upstream agreement that : they honor my prepends? : Thanks. Standard practice is to accept them, though you may need to tell the peer or upstream what regexps to allow if they filter by as-path as well as by prefix. (Always a good idea...) My side question is - what shipping routers will let you rewrite AS-Paths by doing anything other than just prepending? Just wondering if any 7007-type horrors are lurking in the wings. I believe Criscos, Bays, and gated boxes can't do this (without BGP->IGP->BGP redistribution). Avi

3 4

Re: honoring AS-path prepend from a peer or customer?
by Danny McPherson 19 Feb '99

19 Feb '99

Sanjay Dani wrote: > >If a peer (or transit customer) prepends their own AS to >their route announcements to you, do you ever strip off >the excessive As'es? That is, do you always honor them >in your announcements to your other customers (or peers)? > >I do understand that any operator has full control over >deciding his own outbound policy, regardless of the >AS path. > >I want to know what the industry practice is and whether >I should stipulate in my next upstream agreement that >they honor my prepends? I don't see why any sane provider wouldn't honor AS prepends, although I'm not sure how one could actually manipulate AS_PATH without proxy-aggregation, "private AS" or the like .. or some hack to BGP source code, although it'd be unlikely to run in any production code... Don't believe anyone would do exactly what you suggest here though.. Of interesting things you should ask your provider to to support when considering your ability downstream to influence "upstream" path slection, the RFC1998 stuff is really nice.. -danny

1 0

RE: honoring AS-path prepend from a peer or customer?
by Martin, Christian 19 Feb '99

19 Feb '99

> Criscos, > Bays, and gated boxes can't do this (without BGP->IGP->BGP > redistribution). > > Avi Agreed. There is no provision to do this directly with BGP, although the RFC does not specifically preclude this, as far as I can tell. It does mention truncating AS-PATH information when dealing with Inter-AS multicast routes, but this is a future provision. Chris

1 0

honoring AS-path prepend from a peer or customer?
by Sanjay Dani 18 Feb '99

18 Feb '99

If a peer (or transit customer) prepends their own AS to their route announcements to you, do you ever strip off the excessive As'es? That is, do you always honor them in your announcements to your other customers (or peers)? I do understand that any operator has full control over deciding his own outbound policy, regardless of the AS path. I want to know what the industry practice is and whether I should stipulate in my next upstream agreement that they honor my prepends? Thanks.

1 0

Re: transit across the ixs
by Sanjay Dani 18 Feb '99

18 Feb '99

>> It sounds like Verio (a) didn't know about CIX's next-hop policy at PAIX >> and (b) is about to ask for it to be changed. > >cix? what's cix? some kind of sugared cereal? Think it is a router that many months ago saw tons of traffic pass between 2914 and 701 :-) Just observing as a recreational shell customer of a 2914 subsidiary. Consequently (a) above may not (should not?) hold.

1 0

Lessons, does anyone ever learn?
by Sean Donelan 17 Feb '99

17 Feb '99

Under the heading, the more things change, the more the stay the same... I found this interesting paragraph in a government sponsored research report. To make it more interesting, I'm not going to tell you the date of the report, or the network the authors were talking about. Since the US Government paid for the work, copyright isn't a concern, now if that ain't a hint, I don't know what is :-) "Among them they noted that while worst case analysis had been done, the particular scenario had not been studied. The also suggest operators did not have all the data they needed to make proper decisions. Particularly notable was that no one could see the big picture across the entire system. The authors suggest that there is substantial improvement needed to the modeling process. For example, models used for planning are different than models used for online monitoring and control. Finally, there are thousands of system components, and as many problems waiting to occur. Based on these observations the authors suggest the following: - Online dynamic security assessment tools, and security indices. - Wide area communication network and system monitoring process. - National standards for operations and engineering. - Improved system planning and risk assessment methods. - Standard system planning and operating data models. - Validated data in simulation models. - Wide area measurement and controls." Since there is currently a $2.8billion budget request pending before Congress to fund critical infrastructure protection, do you sometimes get the feeling some researchers just cut & paste their old analysis into whatever today's hot topic is? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Re: transit across the ixs
by Paul Vixie 17 Feb '99

17 Feb '99

>you might be amused to write a bit of code to see if your ix peers are >giving you next-hops of other provider(s). it is clear that a number of >providers are selling transit across the ixs. not at all cool. Note that CIX does this by default at PAIX and on PB-SMDS. Not that those are major exchanges by Randy's likely definition. The only time we force next-hop-self is if the peer deliberately asks the exchange operator for port filtering, or if we're otherwise explicitly requested by a BGP peer send routes with next-hop-self. -- Paul Vixie <paul(a)vix.com>

5 6

FIBER CUT: CSX shovel S.E. United States
by Sean Donelan 17 Feb '99

17 Feb '99

The cut is between Abrial (??) & Fairfax, SC and was caused by a CSX shovel. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0