June 2000 - Test - lists.nanog.org

Re: San Francisco power outages imminent
by Jason Legate 15 Jun '00

15 Jun '00

We spoke with SVP, and they said that they are performing rolling 2 hour blackouts in "grid sections". They are on the Bellevue section right now they said. On Wed, Jun 14, 2000 at 04:25:30PM -0700, Pete Bowden wrote: > There was apparently a momentary outage in Santa Clara (less than 5 minutes) > at my home, and there was a large area of Santa Clara (around Lafayette, > El Camino Real to the West of the Santa Clara University) which had a power > outage... I'm not sure the duration, or if it is still out. Santa Clara > has its own power company (Silicon Valley Power, owned by the City) but they > participate in the California Independent System Operator of power system > so they too will likely be impacted. -- /--------------------------/ Jason Legate \------------------------\ | jlegate(a)sitesmith.com | SiteSmith, Inc. | | 24x7 Call Center | http://www.sitesmith.com | | 888.898.7667 | PGP Key ID - 0xA855AAC3 | +---------------------------------+--------------------------------+ | Fingerprint - 2D5F 87A0 26E6 A65B 6837 D100 FB54 A972 A855 AAC3 | \------------------------------------------------------------------/

10 13

Re: in-addr.arpa?
by Vadim Antonov 15 Jun '00

15 Jun '00

Hank Nussbacher <hank(a)att.net.il> wrote: > Why would 216.136.44.104 do something like this? Aside from DNS glitch this traceroute has other funnies: > 10 sl-inetconn-1-0-0-T3.sprintlink.net (144.228.207.46) [AS 1239] 200 msec 204 msec 208 msec > 11 pa1-atm0-6-bbr01.alby.twtelecom.net (207.250.101.2) [AS 4323] 244 msec 264 msec 248 msec > 12 pa1-atm0-5-acr01.alby.twtelecom.net (216.136.44.242) [AS 4323] 256 msec 252 msec 252 msec > 13 learnl-ppp-1130-09-u242.alby.twtelecom.net (207.250.24.30) [AS 3857] 256 msec 260 msec 256 msec > 14 ip104.44.136.216.in-addr.arpa (216.136.44.104) [AS 4323] 404 msec 400 msec 380 msec Look at the ASNs, particluarly hops 12-13-14 :) --vadim

2 1

RE: PMTU-D: remember, your load balancer is broken
by rdobbins＠netmore.net 15 Jun '00

15 Jun '00

The 576 value of the MS PPP MTU is merely a default - it can be changed with a registry hack. Yes, fragmentation has indeed become a Great Evil due to the large amounts of data we're pushing, and the time/resources required for fragmentation/defragmentation. Forcing excessive fragmentation/defragmentation is an effective DoS. As far as increasing the MTU size on your LAN links, you need to exercise a lot of care when so doing. I personally have never tried to change the MTU size on an Ethernet segment of any type (Ethernet_II/1500 has worked admirably, and I'm unsure of the result if I tried it); on Token Ring, going up to 4096 has indeed been beneficial in the past when dealing with large database writes, etc. Of course, the protocol I was using at the time supported 4096-byte frame sizes on Token Ring. I thought the frame-size limits for Gigabit Ethernet were 64-1518/1522 bytes? And isn't that the limit on most host IP stacks for Ethernet media? Or am I off in left field, here? Finally, I would say that on any medium, <100% utilization in and of itself isn't grounds for fiddling with the MTU. There are lots of other things to look at, first. --------------------------------------------------------------- Roland Dobbins <rdobbins(a)netmore.net> // 818.535.5024 voice -----Original Message----- From: Roeland Meyer (E-mail) [mailto:rmeyer@mhsc.com] Sent: Wednesday, June 14, 2000 9:07 AM To: Valdis.Kletnieks(a)vt.edu; 'Marc Slemko' Cc: nanog(a)merit.edu Subject: RE: PMTU-D: remember, your load balancer is broken > Valdis.Kletnieks(a)vt.edu: Wednesday, June 14, 2000 8:07 AM > > On Tue, 13 Jun 2000 22:36:08 MDT, Marc Slemko said: > > 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. I just set my dial PPP ports to MTU=512+40=552, is this wrong? Where does the MTU=576 number come from? > 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? I'm having some trouble getting full throughput from a GigE pipe. Even in the 100baseTX/FDX down-stream, I'm not getting full link utilization (everything on switches, Cat6509 and 3512XLs). I'm considering increasing MTU sizes to MTU=4096+40, or even larger. Most of the data transmissions fall into the 5KB-50KB range. The site can be considered a large portal. What would be the effect on my upstream? Would it create problems? The only systems that see the Internet are the web-servers (dual NICs).

6 5

MAE-EAST Moving? from Tysons corner to reston VA.
by Vinny India 15 Jun '00

15 Jun '00

Has anyone else heard this?

20 27

in-addr.arpa?
by Hank Nussbacher 15 Jun '00

15 Jun '00

Why would 216.136.44.104 do something like this? 10 sl-inetconn-1-0-0-T3.sprintlink.net (144.228.207.46) [AS 1239] 200 msec 204 msec 208 msec 11 pa1-atm0-6-bbr01.alby.twtelecom.net (207.250.101.2) [AS 4323] 244 msec 264 m sec 248 msec 12 pa1-atm0-5-acr01.alby.twtelecom.net (216.136.44.242) [AS 4323] 256 msec 252 msec 252 msec 13 learnl-ppp-1130-09-u242.alby.twtelecom.net (207.250.24.30) [AS 3857] 256 mse c 260 msec 256 msec 14 ip104.44.136.216.in-addr.arpa (216.136.44.104) [AS 4323] 404 msec 400 msec 3 80 msec -Hank

5 4

Re: in-addr.arpa?
by sthaug＠nethelp.no 15 Jun '00

15 Jun '00

> Why would 216.136.44.104 do something like this? ... > 14 ip104.44.136.216.in-addr.arpa (216.136.44.104) [AS 4323] 404 msec 400 > msec 380 msec Because the people who run the name servers for 44.136.216.in-addr.arpa, for unknown reasons, have added entries of the form 104.44.136.216.in-addr.arpa. PTR ip104.44.136.216.in-addr.arpa. I guess they want to hide something, and still have a DNS reverse entry. It's rather pointless IMHO, since we can use whois to get Learn Linc (NETBLK-TWTC-ALBY-C-LRNLINC-0) 385 Jordan Rd Troy, NY 12180 US Netname: TWTC-ALBY-C-LRNLINC-0 Netblock: 216.136.44.96 - 216.136.44.127 Coordinator: Hostmaster (HOS8-ORG-ARIN) hostmaster(a)INC.NET (800)974-4266 Fax: (414)476-2403 Steinar Haug, Nethelp consulting, sthaug(a)nethelp.no

2 1

Re: in-addr.arpa?
by trall＠almaden.ibm.com 15 Jun '00

15 Jun '00

On 06/14/2000 at 08:04:34 ZE2, Hank Nussbacher <hank(a)att.net.il> wrote: > Why would 216.136.44.104 do something like this? > 14 ip104.44.136.216.in-addr.arpa (216.136.44.104) [AS 4323] 404 msec 400 Do you mean why is its name shown as ip104.44.136.216.in-addr.arpa? It is a strange name, but it simply means that the 44.136.216.in-addr.arpa zone has a record like this: 104.44.136.216.in-addr.arpa. PTR ip104.44.136.216.in-addr.arpa. Doing a whois on 216.136.44, we find: Internet Connect, Inc. (NETBLK-INCNET-BLK-4) INCNET-BLK-4 216.136.0.0 - 216.136.127.255 Time Warner Telecom, Inc. (NETBLK-TWTC-BLOCK-01) TWTC-BLOCK-01 216.136.32.0 - 216.136.63.255 Andrew F. Capoccia Law Centers (NETBLK-TWTC-ALBY-C-CAPOCCI-0) TWTC-ALBY-C-CAPOCCI-0 216.136.44.0 - 216.136.44.15 Farm Family Casualty Ins. (NETBLK-TWTC-ALBY-C-FARMFAM-0) TWTC-ALBY-C-FARMFAM-0 216.136.44.16 - 216.136.44.31 Global Spec (NETBLK-TWTC-ALBY-C-GLBLSPC-0) TWTC-ALBY-C-GLBLSPC-0 216.136.44.32 - 216.136.44.47 James McGuinness & Assoc (NETBLK-TWTC-ALBY-C-JMCGNSS-0) TWTC-ALBY-C-JMCGNSS-0 216.136.44.48 - 216.136.44.63 Learn Linc (NETBLK-TWTC-ALBY-C-LRNLINC-0) TWTC-ALBY-C-LRNLINC-0 216.136.44.96 - 216.136.44.127 LaCorte Companies Inc (NETBLK-TWTC-ALBY-C-LACORTE-0) TWTC-ALBY-C-LACORTE-0 216.136.44.128 - 216.136.44.159 New Horizons Computer Learning (NETBLK-TWTC-ALBY-C-NEWHORZ-0) TWTC-ALBY-C-NEWHORZ-0 216.136.44.168 - 216.136.44.175 Rupprecht %26 Patashnick Co. Inc. (NETBLK-TWTC-ALBY-C-RUPPPAT-0) TWTC-ALBY-C-RUPPPAT-0 216.136.44.176 - 216.136.44.191 Phelan%2C Burke %26 Scolamiero (NETBLK-TWTC-ALBY-C-PBSLAW--0) TWTC-ALBY-C-PBSLAW--0 216.136.44.192 - 216.136.44.199 and conclude that Time Warnet Telecom has subdivided their /19 into a bunch of /28s (or smaller). Rather than hassle with doing classless in-addr.arpa delegation (rfc2317?) they've just used placeholder nanes for all the addresses. Tony Rall

1 0

RE: PMTU-D: remember, your load balancer is broken
by jhsu＠mur.com 15 Jun '00

15 Jun '00

: I thought the frame-size limits for Gigabit Ethernet were 64-1518/1522 : bytes? And isn't that the limit on most host IP stacks for Ethernet media? : Or am I off in left field, here? for backbone applications, at least, many hardware vendors support large frames [>1500] on GigE. _k

3 2

San Francisco power outages imminent
by J.D. Falk 15 Jun '00

15 Jun '00

I've seen a few messages forwarded from friends at various SF companies, especially South of Market, saying that PG&E has been calling them and asking that they reduce power utilization. Word is they're not capable of handling the current demand (it is the second day of what feels like a serious heat wave, with temperatures over 90 degrees all over the Bay Area), and power may be shut off on a rotating basis, a block or a few blocks at a time, if the load cannot be reduced. There're a lot of "big name" companies in that area, including Looksmart, Critical Path, Organic Online, Topica, and many, many more. Not sure how many of them have production servers in/near their offices, but it's not uncommon for startups (or recently-past-startup-phase companies) to stupidly have their production machines rely on being able to exchange data with their offices, so who knows what might happen. Mmm, fun! Any word on how San Jose is holding up? Got a lot of data- centers there.... -- J.D. Falk "Practice random funk and senseless disco moves." <jdfalk(a)cybernothing.org> -- Koz

12 16

Re: exchange point media (was: Re: MAE-EAST Moving? ...)
by Steven M. Bellovin 14 Jun '00

14 Jun '00

In message <Pine.LNX.4.10.10006142245540.750-100000(a)uplift.swm.pp.se>, Mikael A brahamsson writes: > >Gigabit ethernet sounds nice but the MTU of 1500 is really restricting >that technology. I have heard rumours that 10gig ethernet will have at >least 4000+ byte MTU, probably 9000+ which might make it viable to use for >a shared medium exchange point as the hardware probably will be fairly >cheap and/as it will be widely available supported by many vendors. How will that type of MTU help an exchange point? Aren't you really limited by what size packets the customers are originating and/or can pass through the net to that point? --Steve Bellovin

2 1