June 2000 - Test - lists.nanog.org

Re: MAE-EAST Moving? from Tysons corner to reston VA.
by Richard A. Steenbergen 16 Jun '00

16 Jun '00

On Fri, 16 Jun 2000, Mark Tripod wrote: > ----- Original Message ----- > From: "Richard A. Steenbergen" <ras(a)e-gerbil.net> > To: "ted hardie" <hardie(a)equinix.com> > Cc: "Wayne Bouchard" <web(a)typo.org>; <nanog(a)merit.edu> > Sent: Friday, June 16, 2000 1:49 AM > Subject: Re: MAE-EAST Moving? from Tysons corner to reston VA. > > > | I don't believe its nearly this bad. It seems to me that the VAST majority > | of backbone private peering is still happening at the OC3 level. In a > | public exchange point where you're talking to multiple networks across a > | shared media it makes sense to do GigE, multiple GigE, 10GigE, etc, with > | OC48 or > feeding it, but due to the nature of the beast (the fact that > | you're exchanging traffic in multiple locations with multiple networks), > | private peering is in no such immediate danger. > | > | Infact a lot of "backbone to backbone" peering is still done with DS3s > | (think of the content providers with little need to talk amongst eachother > | in bulk, GlobalCenter, Exodus, AboveNet, etc). The interesting traffic is > | where the data providers (like those mentioned above) meet the data > | suckers (@Home, AOL, etc), especially as streaming media takes off. > > You'd be surprised by how much bandwidth is required between hosting > companies. Companies that host at multiple locations and on different > providers networks require that the connectivity between those networks be > very robust so that they can transfer large amounts of data between their > server farms. http://stats.sjc.above.net/traffic/nyc/nyc-exodus.html http://stats.sjc.above.net/traffic/iad/iad-exodus.html http://stats.sjc.above.net/traffic/sjc2/sjc2-exodus.html http://stats.sjc.above.net/traffic/sjc/sjc-exodus.html http://stats.sjc.above.net/traffic/iad/iad-globalcenter.html Not nearly as much as one would thing, and if nothing else at least not mainly for that reason. Most of this bandwidth could probably be accounted for by the occational customer that doesn't fit the usual webhosting role and is pulling content from the "other" hosting companies. Though I'll be the first to agree that if they were serious about rhobust reliable service this would be more of the case. :P At any rate this is primarily burst traffic, and in the grand scheme of things it probably wouldn't account for a majority of traffic even if many more people were doing this. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

3 3

Re: MAE-EAST Moving? from Tysons corner to reston VA.
by Richard A. Steenbergen 16 Jun '00

16 Jun '00

On Wed, 14 Jun 2000 hardie(a)equinix.com wrote: > In either case, Mark's point about scaling interconnect > bandwidth is a key question. On one hand you have Tier-2 ISPs who > want fast ethernet based systems, because they don't really have an > immediate need to go for anything faster; on the other, you have > backbone-to-backbone traffic that is rapidly moving to the point where > the only thing that will make sense is to trade a lambda. It's hard > to have public exchange that it is a good entry point for a Tier-2 > that also meets the needs of the backbones. Using multiple different > exchange methods to handle the different needs is one way around > the problem, but it comes at a cost in gear, support, and network > engineering. The inertia in existing traffic exchange mechanisms > is also high enough that what tends to happen is that new connections > take new forms but the old mechanisms aren't taken out of service > at any speed--which again has a cost in gear, support, and network > engineering. I don't believe its nearly this bad. It seems to me that the VAST majority of backbone private peering is still happening at the OC3 level. In a public exchange point where you're talking to multiple networks across a shared media it makes sense to do GigE, multiple GigE, 10GigE, etc, with OC48 or > feeding it, but due to the nature of the beast (the fact that you're exchanging traffic in multiple locations with multiple networks), private peering is in no such immediate danger. Infact a lot of "backbone to backbone" peering is still done with DS3s (think of the content providers with little need to talk amongst eachother in bulk, GlobalCenter, Exodus, AboveNet, etc). The interesting traffic is where the data providers (like those mentioned above) meet the data suckers (@Home, AOL, etc), especially as streaming media takes off. If we had a few more PAIX's and Equinix's in strategic locations the internet would be a better place. :P -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

4 3

Re: MAE-EAST Moving? from Tysons corner to reston VA.
by Richard A. Steenbergen 16 Jun '00

16 Jun '00

On Fri, 16 Jun 2000, John Fraizer wrote: > If I'm not mistaken, 9000bytes is the max. > > >From acenic.c (By D.Becker of course) > > * To enable jumbo frames, simply specify an mtu between 1500 and 9000 > * bytes to ifconfig. Jumbo frames can be enabled or disabled at any time > * by running `ifconfig eth<X> mtu <MTU>' with <X> being the Ethernet > * interface number and <MTU> being the MTU value. > > On 16 Jun 2000 michael.dillon(a)gtsip.net wrote: > > > > > On Fri, 16 June 2000, "Richard A. Steenbergen" wrote: > > > > >In a public exchange point where you're talking to multiple networks > > >across a shared media it makes sense to do GigE, multiple GigE, 10GigE, > > >etc, > > > > What is the largest MTU that you can use across a GigE fabric? Jumbo frames are not part of the 802.3z standard. I believe the talk of a standardized length is 9000 bytes, but until then it should be understood that not every vendor will support it, or support the same number (and not every driver for every NIC will support it either). Cisco claims to support up to 10420 bytes, for example. For some of the other arguements about MTU size, take a look at: http://www.columbia.edu/acis/networks/advanced/jumbo/jumbo.html > "Jumbo frames" extends ethernet to 9000 bytes. Why 9000? First because > ethernet uses a 32 bit CRC that loses its effectiveness above about > 12000 bytes. And secondly, 9000 was large enough to carry an 8 KB > application datagram (e.g. NFS) plus packet header overhead. Is 9000 > bytes enough? It's a lot better than 1500, but for pure performance > reasons there is little reason to stop there, though at 64 KB we reach > the limit of an IPv4 datagram. The 32-bit CRC limit though is hard to > change, so for ethernet, don't expect to see frame sizes above 9000 > anytime soon. -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/humble PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

1 0

Re: MAE-EAST Moving? from Tysons corner to reston VA.
by Steven M. Bellovin 16 Jun '00

16 Jun '00

In message <87256900.00780D04.00(a)d53mta03h.boulder.ibm.com>, trall(a)almaden.ibm. com writes: > > > >On 06/16/2000 at 11:10:55 AST, John Fraizer <nanog(a)EnterZone.Net> wrote: >> If I'm not mistaken, 9000bytes is the max. > >I don't understand how ethernets, at the MAC layer, can support frames >greater than 1500 bytes. Looking at the MAC frame format, we have: > >ethernet DIX V2 DA(16 bits), SA(16 bits), type (16 bits), data >IEEE 802.3 DA(16 bits), SA(16 bits), length (16 bits), LPDU (802.2) > >The traditional way to distinguish between the 2 formats depends on the >length value (in 802.3) being no greater than 1500, and on the type value >(in DIX) being greater than 0x05dc (1500 decimal). > >Assuming you're still going to allow both formats on the same lan, how does >it work if the length is greater than 1500? See http://search.ietf.org/internet-drafts/draft-kaplan-isis-ext-eth-02.txt for one proposal. --Steve Bellovin

1 0

Re: MAE-EAST Moving? from Tysons corner to reston VA.
by trall＠almaden.ibm.com 16 Jun '00

16 Jun '00

On 06/16/2000 at 11:10:55 AST, John Fraizer <nanog(a)EnterZone.Net> wrote: > If I'm not mistaken, 9000bytes is the max. I don't understand how ethernets, at the MAC layer, can support frames greater than 1500 bytes. Looking at the MAC frame format, we have: ethernet DIX V2 DA(16 bits), SA(16 bits), type (16 bits), data IEEE 802.3 DA(16 bits), SA(16 bits), length (16 bits), LPDU (802.2) The traditional way to distinguish between the 2 formats depends on the length value (in 802.3) being no greater than 1500, and on the type value (in DIX) being greater than 0x05dc (1500 decimal). Assuming you're still going to allow both formats on the same lan, how does it work if the length is greater than 1500? Tony Rall

1 0

NYC - NYCMNY56 CO
by Charles Sprickman 16 Jun '00

16 Jun '00

We've had two seperate vendors report some type of general outage at this CO in Manhattan, meaning POTS, leased line, colo'd DSL. I can only imagine it's a power issue if such a variety of services are dead. One claims BA has had other outages in the city throughout the day... Charles | Charles Sprickman | Internet Channel | INCH System Administration Team | (212)243-5200 | spork(a)inch.com | access(a)inch.com

1 0

Summary: Bay Area Power (2000-06-14)
by lucifer＠lightbearer.com 16 Jun '00

16 Jun '00

As it finally cools down, and things appear to be back online, here on the late coast... According to CAISO's website, the state-wide grid only reached a "Stage One Electrical Emergency", and no stats that I can find detail the Bay area other than the activation of voluntary interrupt disconnections. According to both PG&E and the media, a Stage Three emergency was declared in the afternoon, resulting in rolling blackouts for 1.5 to 2 hours per block section. The Palo Alto and Santa Clara grids (separate from PG&E) also went to a Stage Three emergency state. All press releases and reports indicate that this was done at the request of CAISO. Cupertino and possibly some of Sunnyvale around De Anza, from Stevens Creek to I-85, including the Apple campus, were under blackout from 13:30 to 15:30. This was before the media informed people of rolling blackouts, and I have not yet heard a clear answer as to whether this was scheduled (though the nature of the timing, and it's coincidence with later blackouts, suggests that it may have been the first block outage). There was one unconfirmed report of an outage of unknown scope, area and duration occuring at 14:30. Many confirmed reports of widespread outages began to come in at roughly 15:00, from the following areas: San Jose, Santa Clara, Palo Alto, Foster City (no confirmed outage, only warnings), Fremont, the China Basin, and parts of San Francisco. At least one major data center disconnected from the grid and went to generator power, prior to the rolling blackouts. The motivation was not stated, but it seems likely that they were requested to do so as part of the voluntary interruption efforts. No interruption of service was seen. 2 ISP failures were reported; no explicit "ISP alive and well" notices came, but the number of people affected by the area, and still able to transit traffic, would indicate a fair number of service providers still up and flinging packets hither and yon. Sean Donelan was not heard from, and we're all hoping the power gnomes didn't get him :) Tomorrows peak power drain is predicted to be somewhat *above* todays peak was predicted for - so, barring a miracle cooling effect in the Bay, you can probably expect more of the same sort of thing tomorrow. Probably with less folks posting about it - unless/until someone's supply gives out and something big falls over, anyway. -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer(a)lightbearer.com http://www.lightbearer.com/~lucifer

6 5

The Cidr Report
by Tony Bates 16 Jun '00

16 Jun '00

This is an auto-generated mail on Fri Jun 16 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 16Jun00 0) General Status Table History ------------- Date Prefixes 090600 78901 100600 79105 110600 79003 120600 79282 130600 79244 140600 79247 150600 79514 160600 80091 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 65.56.64.0/21 from AS2941 AS Summary ---------- Number of ASes in routing system: 7668 Number of ASes announcing only one prefix: 4319 (2370 cidr, 1949 classful) Largest number of cidr routes: 935 announced by AS701 Largest number of classful routes: 1018 announced by AS701 1) Gains by aggregating at the origin AS level --- 16Jun00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 439 151 288 65.6% BCnet Backbone AS1221 580 409 171 29.5% TELSTRA-AS AS7046 504 344 160 31.7% COQUI-NET PRTC Internet AS9269 193 46 147 76.2% Hong Kong CTI AS9706 154 21 133 86.4% Pusan Metropolitan City Office of AS2609 127 8 119 93.7% EUnet-TN AS7657 269 166 103 38.3% The Internet Group Limited AS7545 167 68 99 59.3% TPG Internet Pty Ltd AS6429 208 116 92 44.2% RDC-INTERNET AS9304 117 26 91 77.8% Hutchcity AS7496 125 40 85 68.0% Power Up AS577 286 206 80 28.0% Bell Backbone AS4293 316 238 78 24.7% Internal ASN for C&W AS705 339 262 77 22.7% ALTERNET-AS AS174 522 446 76 14.6% Performance Systems International AS1727 165 92 73 44.2% MRMS-WEST AS9557 84 19 65 77.4% Pakistan Telecommunication Compan AS724 208 146 62 29.8% DLA-ASNBLOCK-AS AS3602 306 246 60 19.6% Sprint Canada Inc. AS3749 118 59 59 50.0% TECNET AS5106 85 27 58 68.2% AADS-COLUMBUS AS6595 104 47 57 54.8% DODDSEUR AS4740 333 277 56 16.8% Ozemail Pty Ltd (ASN-OZEMAIL) AS209 395 339 56 14.2% Qwest Communications AS7568 67 14 53 79.1% C.S. Communications Co., Ltd. AS7018 532 479 53 10.0% AT&T WorldNet Service Backbone AS376 120 68 52 43.3% RISQ AS1591 173 122 51 29.5% HQASC MEDNET-ASN AS1785 364 315 49 13.5% NYSERNet Backbone AS701 1018 970 48 4.7% Alternet 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: MAE-EAST Moving? from Tysons corner to reston VA.
by michael.dillon＠gtsip.net 16 Jun '00

16 Jun '00

On Fri, 16 June 2000, "Richard A. Steenbergen" wrote: >In a > public exchange point where you're talking to multiple networks across a > shared media it makes sense to do GigE, multiple GigE, 10GigE, etc, What is the largest MTU that you can use across a GigE fabric? --- Michael Dillon Phone: +44 (20) 7769 8489 Mobile: +44 (79) 7099 2658 Director of Product Engineering, GTS IP Services 151 Shaftesbury Ave. London WC2H 8AL UK

4 4

Presentations on MPLS TE during NANOG 19
by HANSEN CHAN 16 Jun '00

16 Jun '00

Hi, Can the presentations made during the TE panel in NANOG 19 be posted on NANOG website or somewhere (it's not there the last time I checked)? Thanks, Hansen

1 0