- Test - lists.nanog.org

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

Re: PMTU-D: remember, your load balancer is broken
by Richard A. Steenbergen 16 Jun '00

16 Jun '00

On Wed, 14 Jun 2000 Valdis.Kletnieks(a)vt.edu wrote: > On Tue, 13 Jun 2000 22:36:08 MDT, Marc Slemko said: > > Except that, technically, you are not permitted to just blindly send > > segments of such size. Well, you can but systems in the middle don't > > have to handle them. No? > > Hmm.. either I did a bad job of explaining or I haven't had enough caffiene > to parse what you said. Given that you also suggest going to a 1460 MSS, > I suspect that we're actually violently in agreement here. > > Now if I can remember why I chose 1396 for a default MSS.... ;) > > > It is also a concern that, in my experience, many of the links with > > MTUs <1500 are also the links with greater packet loss, etc. so > > you really don't want fragmentation on them. > > The worst part here is that I suspect that most of these links (just on > sheer numbers of shipped product) are the aformentioned Win98 576-MTU. > > However, in this case, the fragmentation happens in a terminal server on > the last hop, and hopefully the case of a terminal server running out of > queueing buffers and having to drop one of the 2 remaining fragments of > a 1500->576 split after sending the first one is pretty rare.... > > I seem to remember that the *original* motivation for slow-start and > all that was Van Jacobson's observation that the most common cause of > a TCP retransmit was that an *entire* packet had been silently dropped > due to queueing congestion, and could thus be treated identical to > an ICMP Source Quench. > > Has this changed? Has "fragmentation" become a Great Evil, rather than > an annoyance that some links have to deal with? Anything not in the fast-path (fragmentation, IP options, etc) is a scourge to all that is good and rightous about networking. In other words, if it isn't an every day occurance people seem to forget that it needs to be cared about, checked for "issues", DoS potential, etc (I just heard about a DoS potential against a popular unix stack because of lack of bounds checking in the IP options this evening in fact). I'm hoping IPv6 will fix some of that for IP options, since they're a bit more usable and a bit more important, but I doubt anything will change the mentality. Fortunantly it seems that the backbone links are all running larger MTUs then the hosts (PoS, FDDI, jumbo frame support for gige, even if it isn't standard). As long as its the hosts shrinking the MTU and not the network in-between things are better, its just less then "optimal" thruput. Simple WFQ would be of more use to those poor bastard souls on dialup though. If you are a provider running the tunnel (not on an end host where MSS can be set), you would do well to keep the available MTU post-tunnel >= 1500 to keep everyone happy, if at all possible. Just a quick 5:30AM thought, but it seems like a better solution would be to have the hosts signal that fragmentation was encountered on the ACK, so if ICMP discovery is not possible the packets are not lost with no idea why (it can go right next to the ECN bit :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)

2 1

RE: Application versimilitude (was RE: PMTU-D: remember, your loa d balancer is broken )
by rdobbins＠netmore.net 16 Jun '00

16 Jun '00

-----Original Message----- From: Roeland Meyer (E-mail) [mailto:rmeyer@mhsc.com] Sent: Friday, June 16, 2000 12:28 AM To: rdobbins(a)netmore.net; ssprunk(a)cisco.com Cc: nanog(a)merit.edu Subject: RE: Application versimilitude (was RE: PMTU-D: remember, your load balancer is broken ) >snip< >Actually, this is simplistic. There are many cases where you have >either binary-only (as in the case of Oracle) or the code has >been thorugh the QA cycle and one is not allowed to touch it >(even if one is allowed, hopefully one would know better). Oh, I agree with that. In the binary-only or past-QA instances, one must do lots of sniffing and tweaking. I guess all this "let's go to big MTUs NOW" talk just struck me as a bit premature. ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice

1 0

Re: exchange point media (was: Re: MAE-EAST Moving? ...)
by Richard A. Steenbergen 16 Jun '00

16 Jun '00

On Thu, 15 Jun 2000, Simon Lockhart wrote: > > >The other question is what is the actual capability of the GigaE cards in > >a cisco box? I have been told (not played with GigaE on cisco yet and for > >that matter, neither has the person who told me) that it is limited to > >around 400Mb/s. > > On a 7xxx Cisco, yes, it's limited to 400Mb/s, due to limitations on the > interface to the backplane (or VIP2 in the 75xx). > > On the Cisco 12000, the backplane interface is 2.5Gb/s, so the GigE cards > can run at full speed. On 12008's and 12012's with older SFCs. The backplane on the 12016 supports 10Gbps each direction. Interestly, Cisco is doing 3 port gige cards which oversubscribe the older SFCs. Last I heard they were doing updated SFCs for the 12012 but not the 12008. At any rate, Cisco does support jumbo frames, which can be up to 9k (just set the mtu to 10240), but if I recall correctly jumbo frames were not standard in 802.3z? http://grouper.ieee.org/groups/802/3/ -- 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

Application versimilitude (was RE: PMTU-D: remember, your load ba lancer is broken )
by rdobbins＠netmore.net 16 Jun '00

16 Jun '00

>snip< >Without doing performance analysis on the actual running code, >there really isn't a lot else to look at. Shouldn't that be the first step in the optimization process? Finding out if the code and the server itself are are operating as efficiently as possible -prior to- mucking about with the network (this assumes a bit of thought and planning and maintenance have gone into the network beforehand, so that there're no glaring, generic things which ought to be fixed)? Knowing what your application(s) - or your customers' application(s) - look like on the wire can be an invaluable aid in the code-optimization process, in my experience. Of course, in a public environment, one's options are restricted by the limits of currently-deployed-and-accepted technology. ----------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice

2 1