Re: Protecting 1Gb Ethernet From Lightning Strikes
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: routeviews.org pending delete
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: Subsea Cable Status Map Update - September 2018
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: CALEA options for a small ISP/ITSP
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: Copyright infringement notice
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: Looking for some diversity in Alabama that does not involve ATT Fiber
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: Performance Issues - PTR Records
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: Rwhois not serving all records - it is almost working though.
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.
Re: Understanding reverse DNS better
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: Auto ACL blocker
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: CIDR blocks, by country
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: BGP hijack from 23724 - 4134 China?
+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 pfu...@gmail.com 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 br...@2mbit.com 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: SORBS on autopilot?
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: Intelligent network monitoring systems (commercial/open source, what have you)
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
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
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.
