Re: Tierpoint abuse contact

[Jay Farrell via NANOG]

On Wed, May 27, 2020 at 11:29 AM David Shaw  wrote:

> Hi,
>
> I could really use some help reaching someone at Tierpoint for a spam
> problem coming from 216.27.63.177, 216.27.63.154, 216.27.63.196, and other
> addresses in that block.  I've sent countless emails to their abuse contact
> with no response, had daily calls with their NOC (very polite, but
> ultimately unable to do more than take a message).  It's been almost a
> month now, and while I don't like asking on NANOG, after emailing and
> calling for weeks, I'm out of other options.
>
> Any pointers would be very welcomed.
>
> David
>

Hi David,

I'm just a data center ops guy at Tierpoint, but I've forwarded your email
to someone who may be able to help. But did you also try abuse@ the domain
to which the rDNS resolves?

Re: South Africa On Lockdown - Coronavirus - Update!

[Jay Farrell via NANOG]

On Tue, Mar 31, 2020 at 6:56 AM Mark Tinka  wrote:

> Also, considering everyone is, pretty much, working from home, the
> Internet isn't dying as it randomly does throughout a typical working
> week. Human MIT (maintenance-induced trouble) continues to be the
> leading cause of outages, it seems :-).
>

'Provocative maintenance' is the term I recall from back in the day.
Basically, "It isn't broken, but we can fix that." :-)

Re: free collaborative tools for low BW and losy connections

[Jay Farrell via NANOG]

On Mon, Mar 30, 2020 at 8:56 AM Rich Kulawiec  wrote:

> On Mon, Mar 30, 2020 at 06:30:16AM -0500, Joe Greco wrote:
> > Actual text traffic has been slowly dying off for years as webforums
> > have matured and become a better choice of technology for nontechnical
> > end users on high speed Internet connections.
>
> My view is that the move to web forums is a huge downgrade.  Mailing lists
> are vastly superior.
>

Are web forums even still much of a thing in recent years? My own
experience in several non-networking realms, where I was active in a number
of web-based forums, is that over the past 4 or 5 years facebook groups,
both public and private, have siphoned off the bulk of the former
discussion traffic of once-thriving web forums, with few exceptions. Talk
about a huge downgrade. While facebook's groups allow for virtually
unlimited image uploads, the are extremely lacking in features such as
threaded discussion and searching. I grudgingly live in a number of
facebook groups, including one I admin, but only because all the people I
know from usenet, and then later in forums, have migrated to facebook
groups. One popular city-based discussion group withered away from hundreds
of posts and comments daily to sometimes several days with NO comments at
all. Network effect is in full effect.

Re: Facebook outage

[Jay Farrell via NANOG]

On Sun, Apr 14, 2019 at 7:33 AM Siyuan Miao  wrote:

> Dear community,
>
> It seems that Facebook network is partially down.
>

I wouldn't say partially. And just a month and a day since their 10+ hour
record-breaking outage. Of course FB will downplay it in their eventual RFO
as "some users" had difficulty connecting. ;-)

Re: Catalyst 4500 listening on TCP 6154 on all interfaces

[Jay Farrell via NANOG]

I saw that list, but understood the numbers there to be IDS signature
numbers, rather than port numbers. Am I misreading something?

On Mon, May 7, 2018 at 12:24 PM, Curtis, Bruce 
wrote:

> Some Cisco devices use 6154 for ypxfrd.
>
>
> 6154 ypxfrd Portmap Request (Info, Atomic*)
>
> Triggers when a request is made to the portmapper for the YP transfer
> daemon (ypxfrd) port.
>
> https://www.cisco.com/c/en/us/td/docs/ios/12_2/security/
> configuration/guide/fsecur_c/scfids.html
>
> https://www.cisco.com/c/en/us/td/docs/security/asa/asa84/
> configuration/guide/asa_84_cli_config/protect_tools.html
>
>

Re: Catalyst 4500 listening on TCP 6154 on all interfaces

[Jay Farrell via NANOG]

Just a wild thought – why not open a TAC case with Cisco and ask them?

On Mon, May 7, 2018 at 3:06 AM, frederic.jut...@sig-telecom.net <
frederic.jut...@sig-telecom.net> wrote:

> > - a nsa backdoor :-)
>
> it would be a very bad backdoor as it's really easy to see the port
> listening...
>
>
> > - a default active service
>
> Maybe, but a service which is not officially registered:
> https://www.iana.org/assignments/service-names-port-numbers/service-names-
> port-numbers.xhtml?search=6154
>
> in contrary to the SMI (zero touch feature on tcp 4786) which is
> registered since almost 10y:
> https://www.iana.org/assignments/service-names-port-numbers/service-names-
> port-numbers.xhtml?search=4786
>
>
>
> Could it be possible that this kind of tcp port is not registered by
> Iana because it meant to be used for internal communication only
> (internal to the device), or should you register any port usage (even
> 'private') ?
>
>
> And yes I've tried to reset to default the config, shutdown all
> interface, remove all L3 ip/feature (no ip blabla), and I still see by
> default 2 TCP ports on listening state:
>
> Cat4500-SUP7L-E#sh ip prot
> *** IP Routing is NSF aware ***
>
> Cat4500-SUP7L-E#
> Cat4500-SUP7L-E#sh run | in ip
>  address-family ipv4
>  address-family ipv6
> no ip routing
> ip vrf Liin-vrf
> no ip mfib
> no ip bootp server
> no ip dhcp-client broadcast-flag
> no ip igmp snooping
> no ipv6 traffic interface-statistics
>  no ip address
>  no ip route-cache
>  no ip address
>  no ip route-cache
> no ip forward-protocol nd
> no ip http server
> no ip http secure-server
> Cat4500-SUP7L-E#
> Cat4500-SUP7L-E#
> Cat4500-SUP7L-E#show tcp br all
> TCB   Local Address   Foreign Address (state)
> 5B40BB30  0.0.0.0.4786   *.* LISTEN
> 5CD5D2D8  0.0.0.0.6154   *.* LISTEN
> Cat4500-SUP7L-E#
>
>
>
> I will now try to negate all potential active service from the 'show run
> all' config but it's not optimal as for example 'vstack' (port 4786)
> does not appear in the default config so it would not be disable by this
> trivial method.
>
>
> Fred
>
>
> On 05.05.2018 13:22, marcel.durega...@yahoo.fr wrote:
> > As the zero touch feature is on TCP 4786 (SMI), I vote for either:
> >
> > - a nsa backdoor :-)
> > - a default active service
> >
> > Have you tried to zeroize the config and restart then check if TCP 6154
> > is still on LISTEN state ?
> >
> >
> > -
> > Marcel
> >
> >
> >
> > On 03.05.2018 06:51, frederic.jut...@sig-telecom.net wrote:
> >> Hi,
> >>
> >> We have Cat 4500 series on SUP7L-E with IOS/XE 03.06.02.E/152(2).E2
> >> which have TCP port 6154 listening on all interfaces.
> >>
> >> Any idea what it could be ?
> >>
> >> #show tcp brief all
> >> TCB   Local Address   Foreign Address
>  (state)
> >> ...
> >> 5A529430  0.0.0.0.6154
> >>
> >>
> >> #show tcp tcb 5A529430
> >> Connection state is LISTEN, I/O status: 1, unread input bytes: 0
>
> >> Connection is ECN Disabled, Mininum incoming TTL 0, Outgoing TTL 255
> >> Local host: 0.0.0.0, Local port: 6154
> >> Foreign host: UNKNOWN, Foreign port: 0
> >> Connection tableid (VRF): 1
> >> Maximum output segment queue size: 50
> >>
> >> Enqueued packets for retransmit: 0, input: 0  mis-ordered: 0 (0 bytes)
> >>
> >> Event Timers (current time is 0xF58354):
> >> Timer  StartsWakeupsNext
> >> Retrans 0  0 0x0
> >> TimeWait0  0 0x0
> >> AckHold 0  0 0x0
> >> SendWnd 0  0 0x0
> >> KeepAlive   0  0 0x0
> >> GiveUp  0  0 0x0
> >> PmtuAger0  0 0x0
> >> DeadWait0  0 0x0
> >> Linger  0  0 0x0
> >> ProcessQ0  0 0x0
> >>
> >> iss:  0  snduna:  0  sndnxt:  0
> >> irs:  0  rcvnxt:  0
> >>
> >> sndwnd:  0  scale:  0  maxrcvwnd:   4128
> >> rcvwnd:   4128  scale:  0  delrcvwnd:  0
> >>
> >> SRTT: 0 ms, RTTO: 2000 ms, RTV: 2000 ms, KRTT: 0 ms
> >> minRTT: 6 ms, maxRTT: 0 ms, ACK hold: 200 ms
> >> uptime: 0 ms, Sent idletime: 0 ms, Receive idletime: 0 ms
> >> Status Flags: gen tcbs
> >> Option Flags: VRF id set, keepalive running, nagle, Reuse local address
> >>   Retrans timeout
> >> IP Precedence value : 0
> >>
> >> Datagrams (max data segment is 516 bytes):
> >> Rcvd: 0 (out of order: 0), with data: 0, total data bytes: 0
> >> Sent: 0 (retransmit: 0, fastretransmit: 0, partialack: 0, Second
> >> Congestion: 0), with data: 0, total data bytes: 0
> >>
> >>  Packets received in fast path: 0, fast processed: 0, slow path: 0
> >>  fast lock acquisition failures: 0, slow path: 0
> >> TCP Semaphore  0x5BEB9B10  FREE
> >>
> >>
> >>
> >>
> >>
> >> 

US-CERT: Alert (TA18-106A) Russian State-Sponsored Cyber Actors Targeting Network Infrastructure Devices

[Jay Farrell via NANOG]

https://www.us-cert.gov/ncas/alerts/TA18-106A

Re: Broadcast television in an IP world

[Jay Farrell via NANOG]

On Fri, Nov 17, 2017 at 5:45 PM, Jameson, Daniel <
daniel.jame...@tdstelecom.com> wrote:

> In the US certain channels have the *must Carry* designation.  Which puts
> a retransmitter in a poor negotiating position,  essentially the provider
> can charge whatever they want.


Under must-carry a station cannot charge the cable companies a fee. But the
station can waive must-carry and then can negotiate fees. The cable company
can decline to carry under those circumstances, if they don't want to pay
the fee.

Re: Anyone from AT DNS?

[Jay Farrell via NANOG]

Yep, the notation with the slash used to be ATT's standard method. At my
job (where we had some customers with ATT MIS T1 circuits) we transitioned
to a web front end for our DNS that didn't allow for the slash, so we had
to nudge ATT to allow us to use a dash notation instead for delegations.

As far as to what can appear in a DNS entry, you'd be amazed. I encountered
a PTR record containing a full URL, http:// and everything; it didn't
actually work of course, but bind allowed it to exist. When I tracked down
the cow-orker who had entered it, he said he knew it wasn't valid, but he
did it that way when the customer insisted it had to be thus. :-D

On Wed, Oct 4, 2017 at 11:33 PM, Matt Peterman  wrote:

> I can now confirm that Christopher is right about everything (not that I
> had any doubts! Just wanted to confirm all is working!!)
>
> ATT is now following the RFC (apparently has changed since November 2016
> and June 2017 allocations and DNS changes) and that Route53 WebUI displays
> things strangely, however technically works fine on the backend. rDNS is
> now working properly. Thank you Christopher very much! I learned a lot in
> the last hour I can sure say that!
>
> Matt
>
>
>
> > On Oct 4, 2017, at 11:20 PM, Christopher Morrow 
> wrote:
> >
> >
> >
> > On Wed, Oct 4, 2017 at 11:18 PM, Matt Peterman  > wrote:
> > Got it! You’re the winner here. I just setup both of my zones the name
> way and obviously AT changed the way they did RDNS entries from when I
> got a /25 last November and this second /25 in June. Oh well!
> >
> > Now I am running into the challenge of Route53 does seem to support
> creating an authoritative zone for "128/25.168.207.107.in-addr.arpa.” It
> changes it to "128\05725.168.207.107.in-addr.arpa.” every time… *sigh* If
> it isn't one thing its something else.
> >
> >
> > I've not messed with route53 but fortunately you are treading on well
> trodden ground:
> >   https://forums.aws.amazon.com/thread.jspa?messageID=674778 <
> https://forums.aws.amazon.com/thread.jspa?messageID=674778>
> >
> > have a happy evening! (and I hope that the above works.. again I haven't
> and can't actually try it)
>
>

Re: YouTube streaming failures

[Jay Farrell via NANOG]

Youtube is aware, according to a boilerplate message in their support forum:

Hi there, welcome to the YouTube Help Forum!

"YouTube is aware of the issue. Please stay tuned to YouTube's social media
and the forums for any announcement of a fix.

Thanks for reporting!"

On Sun, Feb 12, 2017 at 9:32 PM, Jay Farrell  wrote:

> Downdetector shows a big spike in reports for youtube in the past several
> hours.
>
> http://downdetector.com/status/youtube
>
> On Sun, Feb 12, 2017 at 9:06 PM, Christopher Morrow <
> morrowc.li...@gmail.com> wrote:
>
>> verizon wired, comcast (on a mobile device) both work in IAD's area.
>>
>> On Sun, Feb 12, 2017 at 8:53 PM, Patrick W. Gilmore 
>> wrote:
>>
>> > I cannot stream on AppleTV or iPhone. Works on my laptop.
>> >
>> > Comcast, Massachusetts.
>> >
>> > --
>> > TTFN,
>> > patrick
>> >
>> > > On Feb 12, 2017, at 8:08 PM, Brett A Mansfield <
>> > li...@silverlakeinternet.com> wrote:
>> > >
>> > > I'm seeing this as well, but only on Apple and Linux products. Seems
>> to
>> > be working fine on Windows.
>> > >
>> > > Thank you,
>> > > Brett A Mansfield
>> > >
>> > >> On Feb 12, 2017, at 5:30 PM, Mel Beckman  wrote:
>> > >>
>> > >> We are getting many customer reports of YouTube streaming failures.
>> The
>> > content directory and search work, but attempts to view videos results
>> in
>> > "something went wrong, click to try again" error messages. We've
>> reproduced
>> > the problem on AT, Level3, Frontier, Cox and Comast networks. We are
>> also
>> > seeing it on cellular data connections, which tends to rule out geo-IP
>> > errors. Is anyone else seeing this?
>> > >>
>> > >> -mel beckman
>> >
>> >
>>
>
>

Re: YouTube streaming failures

[Jay Farrell via NANOG]

Downdetector shows a big spike in reports for youtube in the past several
hours.

http://downdetector.com/status/youtube

On Sun, Feb 12, 2017 at 9:06 PM, Christopher Morrow  wrote:

> verizon wired, comcast (on a mobile device) both work in IAD's area.
>
> On Sun, Feb 12, 2017 at 8:53 PM, Patrick W. Gilmore 
> wrote:
>
> > I cannot stream on AppleTV or iPhone. Works on my laptop.
> >
> > Comcast, Massachusetts.
> >
> > --
> > TTFN,
> > patrick
> >
> > > On Feb 12, 2017, at 8:08 PM, Brett A Mansfield <
> > li...@silverlakeinternet.com> wrote:
> > >
> > > I'm seeing this as well, but only on Apple and Linux products. Seems to
> > be working fine on Windows.
> > >
> > > Thank you,
> > > Brett A Mansfield
> > >
> > >> On Feb 12, 2017, at 5:30 PM, Mel Beckman  wrote:
> > >>
> > >> We are getting many customer reports of YouTube streaming failures.
> The
> > content directory and search work, but attempts to view videos results in
> > "something went wrong, click to try again" error messages. We've
> reproduced
> > the problem on AT, Level3, Frontier, Cox and Comast networks. We are
> also
> > seeing it on cellular data connections, which tends to rule out geo-IP
> > errors. Is anyone else seeing this?
> > >>
> > >> -mel beckman
> >
> >
>

Re: ChangeIP.com has been down for 20+ hours

[Jay Farrell via NANOG]

See their twitter: https://twitter.com/changeipcom

ChangeIP.com ‏@ChangeIPcom  Dec 13

DNS Service functions restored, website, dynamic dns, and control panel
functions remain offline as we continue DB restore process.

On Mon, Dec 12, 2016 at 11:35 AM, Brian J. Dent  wrote:

>

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Jay Farrell via NANOG]

And of course Brian Krebs has a thing or two to say, not the least is which
to push for BCP38 (good luck with that, right?).

https://krebsonsecurity.com/2016/09/the-democratization-of-censorship/

On Sun, Sep 25, 2016 at 12:43 AM, Jay R. Ashworth <j...@baylink.com> wrote:

> - Original Message -
> > From: "Jay Farrell via NANOG" <nanog@nanog.org>
>
> > And of course on windows ipconfig /flushdns
> >
> > Still I had to wait for my corporate caching servers to update; I think
> the
> > TTL on the old A record was an hour.
>
> Are big eyeball networks still flooring A record TTLs on resolution?
>
> Cheers,
> -- jra
> --
> Jay R. Ashworth  Baylink
> j...@baylink.com
> Designer The Things I Think   RFC
> 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land
> Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647
> 1274
>

Re: Krebs on Security booted off Akamai network after DDoS attack proves pricey

[Jay Farrell via NANOG]

And of course on windows ipconfig /flushdns

Still I had to wait for my corporate caching servers to update; I think the
TTL on the old A record was an hour.

On Sat, Sep 24, 2016 at 9:51 PM, Jared Mauch  wrote:

>
> > On Sep 24, 2016, at 9:28 PM, Justin Paine via NANOG 
> wrote:
> >
> >
> > DNS Results for query A krebsonsecurity.comAnswer:krebsonsecurity.com
> 157 IN A 130.211.45.45
>
>
> I recommend running this command (or similar):
>
> rndc flushname krebsonsecurity.com
>
> if you still see 127.0.0.1
>
> - Jared

Re: Need abuse/postmaster contact for AT to resolve IP block

[Jay Farrell via NANOG]

Interestingly, your mail to the nanog list went to my spam folder, rather
than my nanog folder (I'm using gmail or domains for my mail.) That rarely
happens.

On Tue, Aug 30, 2016 at 9:22 AM, Webhosting.net Admin 
wrote:

> A few of our exchange IPs get blocked intermittently, but only by ATT. Ips
> are clean, no issues, we’re diligent about finding and fixing these types
> of issues as it has a large impact.
>
> It would be very helpful to know why the IP below got blocked so we can
> find and fix the problem to prevent further listing. We have a few ips in
> rotation and some have no issue. It’s a “blind” listing, so we only find
> out about it when customers complain that they getting blocked.
>
> ff-ip4-mx-vip1.prodigy.net # 5.3.0 flph399 DNSBL:ATTRBL 521< 67.215.167.170 >_is_blocked.__For_
> information_see_http://att.net/blocks> #SMTP#
>
> Any info/help would be most helpful.
>
> Many thanks,
>
> Webhosting.net Postmaster
>
>
>
>
>
>
>

Re: Regulators now regulating Internet History? Really?

[Jay Farrell via NANOG]

The article is nothing more or less than what you'd expect to read from the
American Enterprise Institute. All regulation totally sucks is their only
message ever.

On Mon, Jun 8, 2015 at 6:56 AM, Fletcher Kittredge fkitt...@gwi.net wrote:

 On Mon, Jun 8, 2015 at 6:01 AM, Larry Sheldon larryshel...@cox.net
 wrote:

  Looks to me that there are issues of interest here.
 
 
 
 http://www.aei.org/publication/tom-wheeler-tries-to-rewrite-internet-history/


 This isn't a very good article.

 At best, it is a set of unsubstantiated claims regarding events of
 undefined correlation. Change in regulation Y led to less investment in
 [bad sector] and more investment in [good sector]. Really? Details of how
 much more? How much less? Why was this better? How did you measure that?
 There are only vague figures without attribution and no establishment of
 causal link. The assumption is just made that investment decisions are made
 for regulatory reasons. This is particularly suspect because, as you may
 recall, there were other things going on in that period. Like the Internet
 Bubble.

 The timeline of events is screwed with. He uses the period between 1996 and
 2000, when the Internet Bubble popped, and compares it to 1996 to 2005,
 when Powell/Martin did away with pro-competitive regulation. Yes, during
 the bubble, which ended in 2000, there was a huge investment in fiber, but
 it is a difficult argument to make that the investment was because of
 regulation since the regulatory change happened in 2005. If it was the
 regulatory change, why didn't investment happen during the missing five
 years? Since it is a widely held thesis that the fiber bubble popped
 because of a huge oversupply of dark fiber, why is that not directly
 addressed.

 Yes, after 2005 cable companies invested in broadband, but again that
 market wasn't technologically developed yet in say, 1999. Further, how can
 you focus only the rate of change in cable investment without considering
 the rate of change in DSL?

 Claiming the Internet bubble popped because of a change in telco regulatory
 regime in the US is ridiculous, as is ignoring the effect of underlying
 technology on the appearance and disappearance of markets. Regulators,
 lawyers and politicians need to get over themselves and have a measured
 perspective on their importance.

 The argument that killing competition from the CLECs led to more investment
 and a better network is a difficult one to make. Particularly during a
 period where the US's network lost is speed/quality advantage compared to
 other advanced countries. There is a strong set of opinions that killing
 CLEC competition was retardant on network speed/quality growth. I don't see
 how articles like this are going to change minds.

 Disclaimer: I am a computer scientist. In general, I find public policy
 arguments deeply annoying because they have flaws similar to the above.

 --
 Fletcher Kittredge
 GWI
 8 Pomerleau Street
 Biddeford, ME 04005-9457
 207-602-1134