- NANOG - lists.nanog.org

Re: value of co-location
by Kent W. England 20 Jan '96

20 Jan '96

At 12:24 PM 1/19/96 -0500, Stephen Balbach wrote: > >Get a 100Mb FDDI or Ethernet connection between the two colocated >routers. > >Then bring in multiple Fast packet services into your router which then >aggregates out the LAN port. > > This breaks down when the connection speed goes from DS-3 to OC-3. --Kent

4 3

Re: .com pollution
by Joe Pruett 20 Jan '96

20 Jan '96

for sites that don't want to restart dns, you can usually clean things out of the cache by doing something like: repeat 500 dig ns com. becaused cached data has its ttl dropped by 10% each time it is used (at least in bind-4.9.3-beta34 and above).

1 0

Re: .com pollution
by Alan＠PeachNet.EDU 20 Jan '96

20 Jan '96

I found corruption in 198.72.72.10 (my server) and killed/started BIND at 17:50 EST. My other servers 131.144.4.10 and 131.144.4.9 were not affected. I saw trash like this via nslookup/dig: "com nameserver = H.RÔT-SERVERS.NET". I did not dump the db so I can't compare TTL, etc with you. A-I were also all corrupt. Any idea how it started? Alan At 7:06 PM 1/19/96, Kobi wrote: >...and, on our resolvers.... > >com. 321028 NS H.RÔT-SERVERS.NET. > 320919 IN NS H.R\357^?T-SERVERS.NET. ;Cr=addtnl [198.72.72.10] > >[B., C., D., E., all corrupted from the same source] > >I have killed and restarted named on ours... > >_k

1 0

Re: .com pollution
by Kobi 20 Jan '96

20 Jan '96

...and, on our resolvers.... com. 321028 NS H.R�T-SERVERS.NET. 320919 IN NS H.R\357^?T-SERVERS.NET. ;Cr=addtnl [198.72.72.10] [B., C., D., E., all corrupted from the same source] I have killed and restarted named on ours... _k

1 0

.com pollution
by Per Gregers Bilse 19 Jan '96

19 Jan '96

(Credit for spotting this goes to Dima Volodin from Sprint.) Please check your nameservers for .com NS bogus data. I had a look around after Dima pointed out the bogus data in ns.EU.net, and over 3/4 of the nameservers I checked were infected (sprint, merit, mci, ans, net99, janet ...). ;; ANSWERS: com. 467325 NS E.ROOT-SERVERS.NET. com. 467325 NS I.ROOT-SERVERS.NET. com. 467325 NS F.ROOT-SERVERS.NET. com. 467325 NS G.ROOT-SERVERS.NET. com. 467325 NS A.ROOT-SERVERS.NET. com. 467325 NS H.ROOT-SERVERS.NET. com. 77377 NS ari.ari.NET. com. 77377 NS ns2.sprintlink.NET. com. 77377 NS ns1.sprintlink.NET. com. 77377 NS ns.peach.NET. com. 467325 NS B.ROOT-SERVERS.NET. com. 77377 NS k2.ari.net. com. 325800 NS H.RoT-SERVERS.NET. com. 324155 NS B.RoT-SERVERS.NET. com. 324155 NS C.RoT-SERVERS.NET. com. 324155 NS D.RoT-SERVERS.NET. com. 324155 NS E.RoT-SERVERS.NET. com. 324155 NS I.RoT-SERVERS.NET. com. 324155 NS F.RoT-SERVERS.NET. com. 324155 NS G.RoT-SERVERS.NET. com. 324155 NS A.RoT-SERVERS.NET. com. 467325 NS C.ROOT-SERVERS.NET. com. 467325 NS D.ROOT-SERVERS.NET. 'rot-server' ... -- ====== ___ === Per G. Bilse, Mgr Network Operations Ctr ===== / / / __ ___ _/_ ==== EUnet Communications Services B.V. ==== /--- / / / / /__/ / ===== Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / ====== tel: +31 20 6233803, fax: +31 20 6224657 === ======= 24hr emergency number: +31 20 421 0865 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse(a)EU.net

1 0

Re: value of co-location
by bajaj＠faline.bellcore.com 19 Jan '96

19 Jan '96

> > What's the average packet size now? I think the overhead on DS-3 ATM/SMDS > > is worse than on OC-3, if I recall correctly, because the DS-3 PLCP is so > > wasteful as well. Someone should redo these calculations more accurately. > > With PLCP, maximum bit rate available for ATM cells = > > 53 cells * 12 rows * 8bits / 125us = 40.704 mpbs. > > So, 40.704 * 48/53 = 36.864 mpbs = data rate. > > Now if you use AAL5, then it's another 2 bytes for SAR, and 2 bytes for > CS, so, 40.704 * (48-4)/53 = 33.792 mpbs. You are correct up til you get to the efficiency at the AAL level. AAL-5 does not have any SAR overhead but it does have 8 bytes of CS overhead. Now, this overhead is on a per PDU basis and NOT a per cell basis. Thus, you maximum efficiency will be 36.864 * [(x-8) / x] where x = PDU size in bytes. Thus, if you just send 64-byte packets, your min throughput will be 36.8 * (56 / 64) = 32.3 Mbps. Of course, larger PDUs are more efficient. Shikhar

2 1

value of co-location
by George H. Clapp 19 Jan '96

19 Jan '96

I'm also curious about the value of co-location. Using a fast packet service (Frame Relay, SMDS, or ATM) allows your on-site router to communicate directly with a router of another ISP. There's no need to purchase another router to place at the co-location site. Why incur the additional cost? George Clapp voice: 201-829-4610 fax: 201-829-2504 page: 800-980-1298 email: clapp(a)bellcore.com

5 4

Times for NANOG meeting
by Susan R. Harris 19 Jan '96

19 Jan '96

Greetings - just wanted you to know that we've scheduled more speakers than usual for the February NANOG meeting, and will be running till 1:00 p.m. on Friday, rather than noon, as in previous meetings. --Susan Harris

1 0

PacBell NAP and Co-location
by Warren K. Williams 19 Jan '96

19 Jan '96

Folks, I need to clarify something regarding colocation at Pacific Bell. There has been a great deal of confusion out in the community regarding Pacific Bell's position on Colocation. Let me set the record straight here. For those NAP customers who need to colocate equipment as part of their NAP connection through us ** can ** do so. We have made an arrangement that fits within company guidelines that will allow us to place a customer's router, CSU/DSU... within our facilities for connection to the NAP. The facilities we provide have the standard data center enviromments (i.e. air conditioning, raised floor, standard racks, and monitored power). They also allow access to customer technicians (or their agents) for configuration and repair needs. The question, however, is a bit moot given the way in which customers attach to an ATM NAP. ATM circuits are pulled to wherever the customer is (using the appropriate InterExchange Carrier to do interlata connections, of course). There is no need to co-locate equipment. No need for the additional capital invesment nor the introduction of an additional routing hop. If a customer has no locations in the bay area, it is simply a matter of setting up a "long-distance" connection. A couple of our customers are doing just that today. FYI. Kind regards, Warren ------------------------------------------------------------------------------ Warren K. Williams, Director - Network Access Point Pacific Bell Business Communications Services Email: wkwilli(a)pacbell.com Phone: 510.867.9065 ------------------------------------------------------------------------------

2 1

Nanog mailing list
by Tricia Schibler 17 Jan '96

17 Jan '96

Subject: Time: 8:34 PM OFFICE MEMO Nanog mailing list Date: 1/17/96 I would like to subscribe to the Nanog mailing list and would also like to attend the next Nanog meeting on February 15,16. I look forward to receiving the appropriate information. Thank you, Tricia Schibler

1 0