Re: Protecting 1Gb Ethernet From Lightning Strikes

2019-08-13 Thread Larry Smith
You might look at mccowntech.com,
they make surge suppressors geared toward
the wireless provider market which are pretty good.
(not associated, we just use their products).

-- 
Larry Smith
lesm...@ecsis.net

On Tue August 13 2019 13:22, Javier J wrote:
> I'm working with a client site that has been hit twice, very close by
> lightening.
>
> I did lots of electrical work/upgrades/grounding but now I want to focus on
> protecting Ethernet connections between core switching/other devices that
> can't be migrated to fiber optic.
>
> I was looking for surge protection devices for Ethernet but have never
> shopped for anything like this before. Was wondering if anyone has deployed
> a solution?
> They don't have a large presence on site (I have been moving all of their
> core stuff to AWS) but they still have core networking / connectivity and
> PoE cameras / APs around the property.
> Since migrating their onsite servers/infra to the cloud, now their
> connectivity is even more important.
>
> This is a small site, maybe about 200 switch ports, but I would only need
> to protect maybe 12 core ones. but would be something I could use in the
> future with larger deployments.
> it's just a 1Gbe network BTW.
>
> Hope someone with more experience can help make hardware recommendations?
>
> Thanks in advance.
>
> - Javier


Re: Subsea Cable Status Map Update - September 2018

2018-09-24 Thread Larry Smith
It seems to work http and redirects to the original server.michogarcia.org
link.

-- 
Larry Smith
lesm...@ecsis.net

On Mon September 24 2018 11:35, Edward Dore wrote:
> Is that URL correct? https://beta.networkatlas.org/ isn’t working for me –
> I can’t establish a TLS connection:
>
> ~ edward$ openssl s_client -connect beta.networkatlas.org:443 -servername
> 443 CONNECTED(0005)
> 140735891764168:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3
> alert handshake
> failure:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-2
>2.50.2/libressl/ssl/s23_clnt.c:541: ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 7 bytes and written 330 bytes
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> ---
>
> http://beta.networkatlas.org/ redirects me to
> http://server.michogarcia.org/ which does give me a map.
>
> Edward Dore
> Freethought Internet
>
> From: NANOG  on behalf of Mehmet Akcin
>  Date: Monday, 24 September 2018 at 17:25
> To: nanog 
> Subject: Subsea Cable Status Map Update - September 2018
>
> Subsea Cable Status Map now aka Network Atlas is now in beta, and further
> details below. Visit https://beta.networkatlas.org to view our v0.1
>
> Please feel free to add feature requests to below sheet.
>
> We are still looking for people who can provide high level kmz data.
>
> A quick reminder if you want to support coding/development of the
> underlying software, drop me a note privately.
>
> Thank you
>
> -- Forwarded message -
> From: Mehmet Akcin mailto:meh...@akcin.net>>
> Date: Sat, Sep 22, 2018 at 6:51 AM
> Subject: Beta updates - Sept 22
> To: Submarine Cable Map Status & Development
> mailto:sub...@kapany.net>>
>
> Hello there,
>
> Our beta can be accessed here<http://server.michogarcia.org/>. Screenshot
> attached.
>
> [Screen Shot 2018-09-22 at 6.45.26 AM.png]
>
> now we are working on adding as many as cable systems possible to the map.
> If you are able to help with a system , please do let us know.
>
> We are going to be able to let registered users to update cable status very
> soon. Next week we hope to present this project in Submarine Networks World
> Conference and seek some support for development funding and network KMZ
> gathering efforts.
>
> in the mean time if you have feature suggestions you can enter them
> here<https://docs.google.com/spreadsheets/d/1Q4-BiLd2q1wzTjq_tjb5G6o8G_q0yE
>6CMz1gboRbAvc/edit#gid=253592441>.
>
> thank you and have a nice day.
> --
> Mehmet
> +1-424-298-1903


Re: routeviews.org pending delete

2018-12-20 Thread Larry Smith
It has been updated it appears:

Registry Expiry Date: 2019-12-14T23:05:47Z

-- 
Larry Smith
lesm...@ecsis.net

On Mon December 17 2018 06:34, Siyuan Miao wrote:
> All,
>
> routeviews.org is pending delete now.
>
> Domain Name: ROUTEVIEWS.ORG
> Registry Domain ID: D48496876-LROR
> Registrar WHOIS Server: whois.networksolutions.com
> Registrar URL: http://www.networksolutions.com
> Updated Date: 2018-12-17T09:33:18Z
> Creation Date: 2000-12-14T23:05:47Z
> Registry Expiry Date: 2019-12-14T23:05:47Z
> Registrar Registration Expiration Date:
> Registrar: Network Solutions, LLC
> Registrar IANA ID: 2
> Registrar Abuse Contact Email: ab...@web.com
> Registrar Abuse Contact Phone: +1.8003337680
> Reseller:
> Domain Status: clientTransferProhibited
> https://icann.org/epp#clientTransferProhibited
> Domain Status: autoRenewPeriod https://icann.org/epp#autoRenewPeriod
> Registrant Organization: Network Solutions LLC
> Registrant State/Province: FL
> Registrant Country: US
> Name Server: NS1.PENDINGRENEWALDELETION.COM
> Name Server: NS2.PENDINGRENEWALDELETION.COM
> DNSSEC: unsigned
> URL of the ICANN Whois Inaccuracy Complaint Form
> https://www.icann.org/wicf/ )
>
> >>> Last update of WHOIS database: 2018-12-17T12:28:37Z <<<
>
> routeviews.org. 86400 IN NS ns2.pendingrenewaldeletion.com.
> routeviews.org. 86400 IN NS ns1.pendingrenewaldeletion.com.
>
> I was wondering if there is anyone here can contact them to renew it if
> this project is still alive.
>
> Regards,
> Siyuan


Re: Auto ACL blocker

2011-01-18 Thread Larry Smith
On Tue January 18 2011 13:12, Brian R. Watters wrote:
> We are looking for the following solution.
>
> Honey pot that collects attacks against SSH/FTP and so on
>
> Said attacks are then sent to a master ACL on a edge Cisco router to block
> all traffic from these offenders ..
>
> Of course we would require a master whitelist as well as to not be blocked
> from our own networks.
>
> Any current solutions or ideas ??

Private BGP session with Zebra or Quagga on a linux box
adding the selected IP to a null route.

-- 
Larry Smith
lesm...@ecsis.net



Re: Understanding reverse DNS better

2011-01-25 Thread Larry Smith
I use Squish (www.squish.net/dnscheck) for this purpose.  Reasonable
web interface and gives lots of info about where things are breaking
down...

-- 
Larry Smith
lesm...@ecsis.net

On Tue January 25 2011 08:38, p8x wrote:
> +1, also a quick check to make sure your name servers are actually set
> can be done with host..  host -t ns 0.168.192.in-addr.arpa
>
> On 25/01/2011 10:34 PM, Jared Mauch wrote:
> > I suggest doing something like:
> >
> > dig +trace -x 204.42.254.5
> >
> > You can watch the delegation authority for the in-addr at each stage.
> >
> > - Jared
> >
> > On Jan 25, 2011, at 9:30 AM, Caleb Tennis wrote:
> >> We have a /24 from one of our upstream providers that we handoff to a
> >> customer.  The /24 has been SWIPd to us, and we have nameservers setup
> >> with ARIN against that record.
> >>
> >> Twice now this information has just "disappeared".  That is, if do
> >> reverse DNS lookups, they returns nothing, whereas they were just
> >> working fine earlier.  If you do an NS lookup on the block, it returns
> >> nothing.  The /24 blocks immediately surrounding us continue to work
> >> just fine.  If we do a lookup directly against our nameserver, it works
> >> just fine.
> >>
> >> It's like the nameserver information against that reverse DNS is just
> >> magically gone.
> >>
> >> The ARIN record looks good, nothing has changed. Last time, our upstream
> >> resubmitted the info so it would repopulate, and it started working
> >> again soon there after.  I admit to not being the smartest one with how
> >> these records work: is the problem with the upstream, or ARIN's
> >> database, or is there not enough information to tell?
> >>
> >> Thanks,
> >> Caleb



Re: Performance Issues - PTR Records

2011-11-02 Thread Larry Smith
On Wed November 2 2011 20:27, Matt Chung wrote:
> I assumed that the applications would take absent records into
> consideration instead of waiting and timing out before responding with
> data. Trying to troubleshoot this issue from the limited visibility is
> difficult ; the latency the application is introducing is abstracted
> (unless I am unaware of that troubleshooting technique).

When you mis-place your keys do you only look in one place and then give
up?  The calling server does not know there is "no" record until it exhausts
its list of DNS servers, which is probably what is introducing the delay you
are seeing (each server trying to find a PTR with each of its upsteams) until
they all time out...

-- 
Larry Smith
lesm...@ecsis.net



Re: Looking for some diversity in Alabama that does not involve ATT Fiber

2012-03-21 Thread Larry Smith
On Wed March 21 2012 10:44, Joe Maimon wrote:
> Hey All,
>
> I have a site in Alabama that could really use some additional
> diversity, but apparently ATT fiber is the only game in town.
>
> If anybody has any options, such as fixed wireless in the 10-50mbs,
> please reply to me, off-list.
>

Any realistic answers are probably going to require an address or physical
location to be able to quote services.  Know there are several Fixed wireless
providers in AL, you might look at www.wispa.org as I believe they have some
information as to which wisps service which areas.

-- 
Larry Smith
lesm...@ecsis.net



Re: Copyright infringement notice

2012-08-22 Thread Larry Smith
On Wed August 22 2012 14:07, Robert Bonomi wrote:
> I'm NOT SURE whether the ISP has any potential liability in _this_
> situation -- there's nothing 'published' by their customer for them to
> 'take down', etc.

Actually, I believe in most cases the only way "they" (DMCA) see the
data is that it _is_ published as a bittorrent file, meaning that others
can leach or download from that location as well as the originating
(or original) file itself.  In almost all cases that I have received these,
I can open my torrent, search for that file, and the IP address mentioned
shows up as a possible download (almost, not all)...

-- 
Larry Smith
lesm...@ecsis.net



Re: CALEA options for a small ISP/ITSP

2012-11-26 Thread Larry Smith
On Mon November 26 2012 09:38, Matthew Crocker wrote:
> I have a CALEA appliance from BearHill that I 'rent'.  It has been in my
> network for years.  I'm looking for other alternative solutions for CALEA
> compliance with a small ISP.   It looks like OpenCalea is a dead project.  
>  What is everyone else using?
>
> My current solution is $1k/month and I rarely get subpoenas, I've never had
> a wiretap one.
>
> My ISP network is a mix of Cisco and Juniper gear.   I have a couple GigE
> connections to my upstreams and push 300-400mbps through the network.
>
> I would think that wireshark pcap files would be enough :(
>

Believe Mikrotik boxes support CALEA, you might check www.mikrotik.com

-- 
Larry Smith
lesm...@ecsis.net



Re: BGP hijack from 23724 -> 4134 China?

2010-04-08 Thread Larry Smith
+1

On Thu April 8 2010 20:50, Aaron Wendel wrote:
> Please.
>
> -Original Message-
> From: Will Clayton [mailto:w.d.clay...@gmail.com]
> Sent: Thursday, April 08, 2010 8:43 PM
> To: Beavis
> Cc: nanog@nanog.org
> Subject: Re: BGP hijack from 23724 -> 4134 China?
>
> Do share!
>
> On Thu, Apr 8, 2010 at 7:29 PM, Beavis  wrote:
> > Is it possible for you to share that filter list you have for china?
> > im getting bogged down by those ssh-bruts as well coming in from
> > china.
> >
> >
> > -B
> >
> > On Thu, Apr 8, 2010 at 2:36 PM, Brielle Bruns  wrote:
> > > On 4/8/10 2:23 PM, Jay Hennigan wrote:
> > >> We just got Cyclops alerts showing several of our prefixes sourced
> > >> from AS23474 propagating through AS4134.  Anyone else?
> > >>
> > >> aut-num:  AS23724
> > >> as-name:  CHINANET-IDC-BJ-AP
> > >> descr:IDC, China Telecommunications Corporation
> > >> country:  CN
> > >>
> > >> aut-num:  AS4134
> > >> as-name:  CHINANET-BACKBONE
> > >> descr:No.31,Jin-rong Street
> > >> descr:Beijing
> > >> descr:100032
> > >> country:  CN
> > >>
> > >> --
> > >> Jay Hennigan - CCIE #7880 - Network Engineering - j...@impulse.net
> > >> Impulse Internet Service  -  http://www.impulse.net/
> > >> Your local telephone and internet company - 805 884-6323 - WB6RDV
> > >
> > > I'm starting to wonder if someone is 'testing the waters' in China to
>
> see
>
> > > what they can get away with. I hate to be like this, but there's a
>
> reason
>
> > > why I have all of China filtered on my routers.
> > >
> > > Amazing how much  SSH hammering, spam, and other nastiness went away
> > > within minutes of the filtering going in place.
> > > There comes a point where 'accidental' and 'isolated incident' become
> > > "we no
> > > care" and "spam not illegal".  And no, i'm not quoting that to mock,
> > > but rather repeat exactly what admins in China send to me in response
> > > to abuse reports and blocking in the AHBL.
> > >




Re: Starting up a WiMAX ISP

2010-04-27 Thread Larry Smith
On Tue April 27 2010 09:00, Charles Bronson wrote:
> Looking for advice...
>
> I live in central / western New York state (think villages and farms).
> There are a good number of hills but no mountains. I have solid LAN
> experience and experience facing a smaller network to the Internet. I was
> network admin for a medium size enterprise network (I.e. design and
> implementation including LAN, Internet connectivity, VPN, routers, DNS,
> mail, webservers, physical servers, etc). I would like to build a local ISP
> that can serve high speed internet access to the more rural areas whose
> only option is dial up access, well away from the CO. It would also be nice
> to compete with the cable company and DSL for customers in the villages.
>
> I have been researching information for design / implementation of WiMAX,
> equipment suppliers, contractors to help with installation of tower
> equipment and acquiring tower space, but have been coming up empty handed.
>
> What resources are available to help me bridge the gap from where I am to
> what I need to know to get started and what specific technologies would you
> recommend I bone up on? I know beyond the WiMAX specific information, I
> will probably need to cozy up to BGP, maybe MPLS for traffic between the
> core and towers? Also do you have any suggestions on where I can find
> suppliers and service vendors in this field? Networks are my passion and am
> willing to dig in, but I need some direction.
>
> Thanks for you help an insight.
>
>  Charles Bronson

Recommend you look at www.wispa.org (Wireless Internet Service Providers
Association).  Probably have loads of information and resources to get
you pointed in the right direction...

-- 
Larry Smith
lesm...@ecsis.net




Re: CIDR blocks, by country

2010-05-12 Thread Larry Smith
On Wed May 12 2010 11:09, Michael Holstein wrote:
> I am aware of sites that list all the netblocks associated with China
> (for example) .. is there any place that publishes an updated list of
> what netblocks are used by what countries? (all of them) .. CIDR format
> would be ideal.
>
> If it matters, I'm specifically interested APNIC and AFRNIC.
>
> Regards,
>
> Michael Holstein
> Cleveland State Unviersity

Since blackholes.us went away, the only other one I have found
semi-reliable is Country IP Blocks at http://www.countryipblocks.net

-- 
Larry Smith
lesm...@ecsis.net



Re: Intelligent network monitoring systems (commercial/open source, what have you)

2009-09-11 Thread Larry Smith
On Fri September 11 2009 13:59, Drew Weaver wrote:
> Howdy,
>
> Can anyone suggest a network monitoring system that knows the difference
> between a cisco 1701 and a GSR 12810/6500, etc?
>
> What I mean is, many times these days there are several different sub
> systems you have to monitor inside of a router/switch and not just
> interface utilization, the "CPU", and the "RAM".
>
> Statistics such as CEF utilization, fabric utilization, PFC/DFC, various
> line card statistics, etc?
>
> Can anyone recommend anything other than "customize MRTG a lot" that we can
> use to get a better look into these systems?
>
> thanks,
> -Drew

Have you looked at OpenNMS ?? 

-- 
Larry Smith
lesm...@ecsis.net



Re: Broadband Subscriber Management

2009-04-22 Thread Larry Smith
On Wed April 22 2009 11:01, Curtis Maurand wrote:
> I don't understand why DSL providers don't just administratively down
> the port the customer is hooked to rather than using PPPoE which costs
> bandwidth and has huge management overhead when you have to disconnect a
> customer.  I made the same recommendation to the St. Maarten (Dutch)
> phone company several years ago.  They weren't listening either.   That
> way you can rate limit via ATM or by throttling the port administratively.

Most likely because most RADIUS systems can be tied fairly easily directly
to the billing/payment system which enables and disables (adds/removes)
the customer from radius for payment/non-payment and therefore does
not require any "technical" support to turn on/off customers.

-- 
Larry Smith
lesm...@ecsis.net



Re: Broadband Subscriber Management

2009-04-22 Thread Larry Smith
Not disagreeing with you, just that SNMP "write" access is generally something
that admins keep either turned off or very, very tightly controlled.  In that 
context, how many "devices" (dslams, redbacks, etc) would have to 
be "touched" via SNMP to turn off a customer (or customers) versus simply
removing "their" entry from a central radius database.

-- 
Larry Smith
lesm...@ecsis.net

On Wed April 22 2009 12:25, you wrote:
> As opposed to SNMP and a script that would shut the port down via SNMP
> when the customer is disabled?
>
> Larry Smith wrote:
> > On Wed April 22 2009 11:01, Curtis Maurand wrote:
> >> I don't understand why DSL providers don't just administratively down
> >> the port the customer is hooked to rather than using PPPoE which costs
> >> bandwidth and has huge management overhead when you have to disconnect a
> >> customer.  I made the same recommendation to the St. Maarten (Dutch)
> >> phone company several years ago.  They weren't listening either.   That
> >> way you can rate limit via ATM or by throttling the port
> >> administratively.
> >
> > Most likely because most RADIUS systems can be tied fairly easily
> > directly to the billing/payment system which enables and disables
> > (adds/removes) the customer from radius for payment/non-payment and
> > therefore does not require any "technical" support to turn on/off
> > customers.



Re: SORBS on autopilot?

2010-01-11 Thread Larry Smith
On Mon January 11 2010 09:48, Ken Chase wrote:
> Anyone got some pointers on how to get off SORBS' Dynamic IP lists?
>
> We've followed their RFC proposed static reverse DNS assignment naming and
> all elements of their FAQ.
>
> We are not spammers. The /24 in question isnt listed on any RBLs except
> SORBS DUL.
>
> We've submitted requests in various different formats, but get a robot
> reply and -ENOJOY.
>
> We've even had our upstream that is listed at the RIR as managing the
> supernet of our BGP announced prefixes submit requests to delist for the
> /24, but we are only ever replied to by a robot that lists 67.196.137.0/24
> as dynamic except .163 (somehow manually excluded from their db, I think
> when they werent adrift in years past). Our upstream's techs are also at a
> loss now and suggested I seek arcane clue amongst the sages here.
>
> Pointers appreciated.
>
> /kc

Hmmm, probably something to do with your "reverse" naming convention:

host 67.196.137.1
1.137.196.67.in-addr.arpa domain name pointer 
H1.C137.B196.A67.tor.colo.heavycomputing.ca.

host 67.196.137.163
163.137.196.67.in-addr.arpa domain name pointer sizone.org.

host 67.196.137.16
16.137.196.67.in-addr.arpa domain name pointer 
H16.C137.B196.A67.tor.colo.heavycomputing.ca.

host 67.196.137.162
162.137.196.67.in-addr.arpa domain name pointer 
H162.C137.B196.A67.tor.colo.heavycomputing.ca.

IP 67.196.137.163 appears to actually have a "name" and everything
else has Hnnn.C137.B196.A67.tor.colo.heavycomputing.ca (where nnn
is the fourth octet IP).

-- 
Larry Smith
lesm...@ecsis.net



Re: Rwhois not serving all records - it is almost working though.

2011-05-04 Thread Larry Smith
Landon,

  By no means an expert in rwhoisd, but my net directory has the 
following:

atrribute_defs directory
data directory
schema file
soa file

and the DATA directory contains the following:

network directory
org directory
referral directory

From what you describe it sounds like things might not be in the
right places for rwhoisd to find them (but depends upon how heavily
your copy has been modified also)...

-- 
Larry Smith
lesm...@ecsis.net

On Wed May 4 2011 14:40, Landon Stewart wrote:
> Hello NANOG,
>
> I sent this information to the rwhoisd mailing list originally but I've
> been informed that the mailing list is mostly dead now.  I hope this is not
> too far off-topic for NANOG.  One person replied to me off-list from the
> rwhois mailing list and had some help but I haven't found a solution yet.
> Scrapping our entire rwhois implementation and starting from scratch would
> be a shame since I don't have that many free cycles these days.  If anyone
> has any info or can offer some information/help that'd be super duper
> appreciated.
>
> Someone else installed this copy of rwhoisd and then that service was moved
> to a new server.  The rwhois server we maintain is rwhois.hopone.net on
> port 4321.  All of this used to work until the rwhois service and its
> directories were moved to a new server a few months ago.  It hasn't worked
> quite right since then.  I'm really not sure how it all works - I'm jumping
> into the middle of this since the person who set it up isn't around any
> more.  I've checked for things as simple as permissions and file formatting
> but I can't find any problems.
>
> Anyway - The data files are exported from our customer database and look
> OK.  By "OK" I mean they are getting exported, I'm not sure if there's a
> formatting issue or not.  The files are generated regularly on another
> server that hasn't had any changes made to it so they should, in theory, be
> fine.
>
> For this example I'll use 66.36.235.19 as the IP address in question.  This
> is our address.
>
> When doing a lookup I see the following which is incomplete.  Actually I'd
> like it to not display this at all personally.  I'd like the customer
> information to be displayed instead but multiple records is fine (ours for
> the netblock and theirs for their allocation).  See below for more
> information about the data files.
>
> # whois 66.36.235.19
> [Querying whois.arin.net]
> [Redirected to rwhois.hopone.net:4321]
> [Querying rwhois.hopone.net]
> [rwhois.hopone.net]
> %rwhois V-1.5:003fff:00 rwhois.hopone.net (by Network Solutions, Inc.
> V-1.5.9.5)
> network:Class-Name:network
> network:ID:66.36.224.0/19
> network:Auth-Area:66.36.224.0/19
> network:Network-Name:Superb Internet Corporation
> network:IP-Network:66.36.224.0/19
> network:Organization;I:Superb_Internet_Corporation
> network:Tech-Contact:hostmas...@superb.net
> network:Admin-Contact:hostmas...@superb.net
> network:Created:20050124
> network:IP-Total:8192
> network:IP-Used:3578
> network:IP-Available:4614
> network:IP-Usage:43.68
> network:Updated:20110317
> network:Updated-By:rwh...@hopone.com
>
> %referral rwhois://root.rwhois.net:4321/auth-area=.
> %ok
>
> The data files for this 66.36.231.147 are in a directory called
> /usr/local/rwhoisd/net-66.36.224.0-19.  The directory looks like this:
> # pwd
> /usr/local/rwhoisd/net-66.36.224.0-19
> # ls -la
> total 40
> drwxr-xr-x  3 wwwwheel  4096 Mar 17 00:03 .
> drwxr-xr-x 26 rwhois rwhois 4096 Mar 17 00:03 ..
> drwxr-xr-x  3 wwwwheel  4096 Mar 17 00:05 data
> -rw-r--r--  1 wwwwheel   125 Mar 17 00:03 schema
> -rw-r--r--  1 wwwwheel   181 Mar 17 00:03 soa
>
> When changing into /usr/local/rwhoisd/net-66.36.224.0-19/data/network I see
> the data file that contains the information that should be served which is:
> # cat 1230-bakertrg.txt
> ID: 1230.66.36.224.0/19
> Auth-Area: 66.36.224.0/19
> Network-Name: bakertrg
> Network-Block: 66.36.235.19-66.36.235.19
> Organization: Baker_TRG__Inc.
> IP-Used: 1
> Created: 20050124
> Updated: 20110317
> Updated-By: rwh...@hopone.net
>
> The local.db file at
> /usr/local/rwhoisd/net-66.36.224.0-19/data/network/local.db contains the
> following for this which I assume is correct
> type:DATA
> file:net-66.36.224.0-19/data/network/1230-bakertrg.txt
> file_no:0
> size:220
> num_recs:1
> lock:OFF
>
> Does anyone on this list have any idea why this data is not being served as
> expected through rwhois anymore?  Some ideas on what to check would be
> helpful.  I'd like to avoid resetting this up from scratch if there's an
> easy fix somewhere since it seems like its *almost* working.
>
> Thanks for taking the time to read this.  I appreciate any help anyone can
> suggest on or off list.