- Test - lists.nanog.org

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 15 Jun '00

15 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

Re: San Francisco power outages imminent
by Hal Murray 15 Jun '00

15 Jun '00

> Disinformation? Its not on the CAISO web site. Palo Alto runs their own utilities. I work in downtown Palo Alto. The text I quoted was distributed via email to our operations people and they forwarded it to us. I clipped off all the headers to save space and to be polite because I don't have permission to expose the initial sender's email address. Sorry for any confusion or doubts I contributed by not explaining that earlier. The last line of the message I quoted includes their URL: www.cpau.com (That's City of Palo Alto Utilities) Right now, that page says: What's New: STAGE III Alert called at 2:34 p.m. today.Portions of Rotating Outage Block #6 have been shut off for two hours to comply with an mandatory electricity curtailment request of 3 Megawatts of load in Palo Alto. The area affected is bounded by 1) Alma/Middlefield and E. Meadow/El Carmelo and 2) Alma/Middlefield and E. Meadow/Ferne. We will keep you notified of additional changes.

1 0

Re: San Francisco power outages imminent
by Hal Murray 15 Jun '00

15 Jun '00

The view from Palo Alto: ----- Date: Wed, 14 Jun 2000 12:32:44 -0700 STAGE TWO ELECTRIC ALERT! The Cal ISO has declared Stage One and Two Emergencies for today from Noon to 6:00 pm. Demand is exceeding transmission capability in the Bay Area by 250 megawatts. Please reduce electric consumption to the greatest extent possible. If required, Stage 3 (rolling blackouts) may not allow advance notice. You may wish to engage your emergency generators. We will update you as information becomes available. ----- Sent: Wednesday, June 14, 2000 3:26 PM At 2:34 p.m. Palo Alto initiated rolling blackouts to shed 3.3 megawatts of load. Similar action is occurring throughout the Bay Area. Affected outage areas are in residential portions of Block 6 and will be impacted for two hours. Thank you for your efforts. See www.cpau.com for more info.

2 1

Further power updates
by lucifer＠lightbearer.com 15 Jun '00

15 Jun '00

Direct contacts or NANOG readers have provided more information: Confirmation of outages in Cupertino (along De Anza to 85, at least), affecting Apple's main campus, from 13:30 to 15:30. This (or a related) outage are also reported in Sunnyvale. At least one report of outages in Fremont, affecting a service provider. Also, one report of an outage in the China Basin, affecting a circuit to another provider (whether it was a provider or circuit failure wasn't clear from the report). PG&E and the Santa Clara grid have both gone to Stage 3, according http://www.newschannel11.com/MoreNews/readstory.asp?s=0006_rotatingoutages and http://www.pge.com/whats_new/news/releases/2000/quarter02/000614r2.htm Local radio stations are reporting that the rolling blackouts have been extended to 2 hours (per area); I cannot confirm this, however. -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer(a)lightbearer.com http://www.lightbearer.com/~lucifer KF6WAY (Tech) - 146.475 MHz (FM/Phone)

2 1

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

14 Jun '00

Nobody expects anyone to change millions of dial-up MTUs; it was just a response to the original poster's query as to the origin of that figure. I've been DoSed via fragmentation, so it -can- happen. Agreed, it's not all that common. Thanks much for the info on Cisco 'Giant Frame' support; I know that'll come in handy! Server folks will often tell you that they need huge MTUs - and in some cases, they're correct. In other cases, it actually ends up hindering performance, depending upon the application and the entire end-to-end network topology. Playing with MTUs is very much like configuring filesystem block-size, or the application-specific buffering in a big RDBMS like Oracle. The main difference is that although one doesn't often see big RDBMS servers used for other things (allowing the server OS and the applications on it to be tweaked so as to squeeze out every erg of performance for a single purpose), networks in general, and carrier networks in particular, are generally used for all sorts of things. And besides the potential effect of an altered MTU size on application performance, one then runs into the question of whether it's an efficient use of bandwidth overall. So, I guess it makes sense to have a -thorough- understanding of one's topology and application characteristics prior to fiddling about with the MTU size. I can see that it may well offer the potential of a big win at the core, but moving towards the edges, I should think the benefits tend to taper off. There can't really be a rule of thumb for this sort of thing, of course; by nature, it's highly situationally dependent. -----Original Message----- From: Stephen Sprunk [mailto:ssprunk@cisco.com] Sent: Wednesday, June 14, 2000 3:48 PM To: rdobbins(a)netmore.net Cc: North American Noise and Off-topic Gripes Subject: Re: PMTU-D: remember, your load balancer is broken Sez <rdobbins(a)netmore.net> > The 576 value of the MS PPP MTU is merely a default - it can be > changed with a registry hack. Expecting the tens of millions of novice computer users to set their systems for a 1500 byte MTU is irrational. Those who are knowledgeable enough to do so are generally reducing it due to "speed up your modem" articles and programs which improve interactive performance at the expense of throughput. > Forcing excessive fragmentation/defragmentation is an effective DoS. Effective, but a fairly difficult problem to exploit. > 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? IIRC, during development of the GigE spec, several vendors wished to increase the GigE MTU to ~9000 bytes. Due to the technical ramifications of bridging to low-MTU FastE segments, as well as inter-vendor politics, it didn't make it as part of the GigE spec but was later published as an optional extension. There are now several devices on the market that will do Jumbo frames on GigE. For instance, the Catalyst 6000 and GSR do: http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_5/cmd_r efr/set_po_r.htm#xtocid661812 I know there are several other vendors who support Jumbo frames as well. > 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. I hear consistent requests from server folks for higher MTUs; they claim the per-frame CPU hit is significant enough to warrant using Jumbo frames to increase throughput. The results clearly show that it helps. S | | Stephen Sprunk, K5SSS, CCIE #3723 :|: :|: Network Design Consultant, HCOE :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX .:|||||||:..:|||||||:. Email: ssprunk(a)cisco.com

1 0