https://twitter.com/jhackenthal/status/799091998594650112
> On Nov 12, 2016, at 22:05, J. Hellenthal wrote:
>
> That is a very cool contribution you've made. Let me run it through some
> tests and put it to work right away and see if I can provide some feedback
> and maybe possible patches or
The good news is that I reported this particular site as a problem two and
three years ago, both, and it isn't any worse.
Matthew Kaufman
On Wed, Nov 16, 2016 at 6:29 PM Mark Andrews wrote:
>
> In message , JORDI
> PALET M
> ARTINEZ writes:
> > I think it is not just a matter of testing behind a
On Sun, Nov 13, 2016 at 3:57 PM, Christopher Morrow wrote:
> So... actually someone did tell arin to aim these at ns1/2google.com...
> I'll go ask arin to 'fix the glitch'.
>
>
the glitch got fixed, shortly after this message, but not by my/our
doing... hrm.. I see passive dns data:
bailiwick 136
In message , JORDI PALET M
ARTINEZ writes:
> I think it is not just a matter of testing behind a 1280 MTU, but about makin
> g sure that PMTUD is not broken, so it just works in any circumstances.
>
> Regards,
> Jordi
If you don't do MSS fix up a 1280 link in the middle will find PMTUD issues
p
I think it is not just a matter of testing behind a 1280 MTU, but about making
sure that PMTUD is not broken, so it just works in any circumstances.
Regards,
Jordi
-Mensaje original-
De: NANOG en nombre de Mark Andrews
Responder a:
Fecha: jueves, 17 de noviembre de 2016, 9:26
Para: L
I'm in Chicago and I saw mine going to Miami as well (per rDNS). Haven't looked
into it at all.
I did see a video where they said they occasionally purposely give people less
than ideal facilities to test connectivity. Maybe that process buggered up?
-
Mike Hammett
Intelligent Comput
Hello,
Does anybody have a contact I could use at Facebook to get a routing issue
resolved?
Some of our networks are being routed to Miami, rather than using the much
closer PoP of Sydney, and it's obviously causing significant performance
issues when browsing Facebook.
In message
, Lee writes:
> On 11/16/16, Mark Andrews wrote:
> >
> > In message <1479249003.3937.6.ca...@ns.five-ten-sg.com>, Carl Byington
> > writes
> > :
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA512
> >>
> >> Following up on a two year old thread, one of my clients just hit this
>
It happens too often, unfortunately.
People deploying IPv6 at web sites and other services, don’t check if PMTUD is
broken by filtering, ECMP, load balancers, etc.
This is the case here:
tbit from 2001:df0:4:4000::1:115 to 2605:3100:fffd:100::15
server-mss 1440, result: pmtud-fail
app: http, ur
On 11/16/16, Mark Andrews wrote:
>
> In message <1479249003.3937.6.ca...@ns.five-ten-sg.com>, Carl Byington
> writes
> :
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> Following up on a two year old thread, one of my clients just hit this
>> problem. The failure is not that www.pay.go
> On Nov 15, 2016, at 5:30 PM, Carl Byington wrote:
>
> openssl s_client -connect www.pay.gov:443
I’m not seeing the issue here, but they do have some possible issues the way
they’re setting cookies (See details below).
What path are you seeing to them? I’m also not having the issue from t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Wed, 2016-11-16 at 20:59 +, Matthew Kaufman wrote:
> I fixed it (and Netflix) by turning off IPv6 for all my users... but
> any chance this is a path MTU issue causing the apparent hang?
I fixed it by using the rpz feature of bind to disable
I fixed it (and Netflix) by turning off IPv6 for all my users... but any
chance this is a path MTU issue causing the apparent hang?
Matthew Kaufman
On Wed, Nov 16, 2016 at 12:26 PM Mark Andrews wrote:
>
> In message <1479249003.3937.6.ca...@ns.five-ten-sg.com>, Carl Byington
> writes
> :
> > ---
In message <1479249003.3937.6.ca...@ns.five-ten-sg.com>, Carl Byington writes
:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Following up on a two year old thread, one of my clients just hit this
> problem. The failure is not that www.pay.gov is not reachable over ipv6
> (2605:3100:fff
Looks likeAS26272 and 198.154.60.0/22 have been deregistered about a
week ago.
In ARIN delegation statistics from Nov 8,
ftp://ftp.arin.net/pub/stats/arin/delegated-arin-extended-20161108 these
are listed as assigned and allocated but in later files that changed to
'reserved'.
RIPEstat sho
We have actively started to block 23/tcp to our customer's CPEs
Huge amounts of connection attempts / scans over our prefixes. All IPv4,
zero on IPv6 (not yet at least).
On Wed, Nov 16, 2016 at 8:12 PM, Otto Monnig wrote:
> We’ve been monitoring/logging/blocking ports 23 and 2323 at our si
Hum,
Its a 6 weeks old entries in my routers.
Even "oddish" its 26272 coming of GTT & HE.
26272 is unassigned at ARIN.
--
My experience with GTT & HE find it curious that they let that happen.
-
Alain Hebertaheb...@pubnix.net
PubN
We’ve been monitoring/logging/blocking ports 23 and 2323 at our site for the
past several weeks, after remediating a 60-75 Mbps attack on a 100 Mbps fiber
feed.
On port 23, we have accumulated 377,319 different IP addresses hitting our
systems. For port 2323, 42,913 different IP addresses.
Th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Following up on a two year old thread, one of my clients just hit this
problem. The failure is not that www.pay.gov is not reachable over ipv6
(2605:3100:fffd:100::15). They accept (TCP handshake) the port 443
connection, but the connection then hang
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Following up on a two year old thread, one of my clients just hit this
problem. The failure is not that www.pay.gov is not reachable over ipv6
(2605:3100:fffd:100::15). They accept (TCP handshake) the port 443
connection, but the connection then hang
Probably best to go with A) what we could do in the best of situations and B)
what the rest will do.
Some of us are last mile networks and *DO* care.
-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
Midwest-IX
http://www.midwest-ix.com
- Original Message
It's pretty much part of the IBR now. And what can a provider do, really? It's
not likely he will expend much effort blocking customers. Maybe we should all
start filtering 2323?
-mel via cell
> On Nov 16, 2016, at 11:53 AM, Stephen Satchell wrote:
>
> I've been seeing a lot of rejections in
I've been seeing a lot of rejections in my logs for 2323/tcp. According
to the Storm Center, this is what the Mirai botnet scanner uses to look
for other target devices.
Is it worthwhile to report sightings to the appropriate abuse addresses?
(That assumes there *is* an abuse address associated
24 matches
Mail list logo
