On 10/23/19 8:18 PM, Constantine A. Murenin wrote:
A long message about how sending arbitrary operational text data to gmail can
cause unsuspected problems
This is a perfect example of why service providers, IT consulting
outfits, etc. really need to either run their own mail infrastructure o
On Wednesday, 23 October, 2019 18:36, Brandon Applegate
wrote:
>Bigger picture, I think that (unfortunately) we will see more and more
>problems like this. With the large providers running so much (as you
>mentioned - “monoculture”), and their services tending toward the “black
>box” ... I do
> On Oct 23, 2019, at 8:18 PM, Constantine A. Murenin
> wrote:
>
I’d recommend posting this over on the mailop list as well. Lots of
discussions about issues like this there.
I too send myself various cron/*nix emails. The difference is I send to my own
domain on my own server so I don’t s
Dear NANOG@,
I'm not sure where else to post this, and this is not really new, either,
but I think I have a new take here.
I use my own personal domain name for various UNIX stuff, including sending
log-related things to myself out of cron, which end up in my own Gmail.com
account, either directl
Dear Stephen,
I’ll work with you off-list to investigate! :-)
Kind regards,
Job
NTT / AS 2914
On Wed, Oct 23, 2019 at 14:23 Ross Tajvar wrote:
> What was the source/destination?
>
> On Wed, Oct 23, 2019, 2:10 PM Stephen Satchell wrote:
>
>> Routing loop
>>
>> > 11.|-- 129.250.24.196
What was the source/destination?
On Wed, Oct 23, 2019, 2:10 PM Stephen Satchell wrote:
> Routing loop
>
> > 11.|-- 129.250.24.196 0.0% 1 28.9 28.9 28.9 28.9
> 0.0
> > 12.|-- 129.250.130.2540.0% 1 29.0 29.0 29.0 29.0
> 0.0
> > 13.|-- 129.250.130.253
Routing loop
> 11.|-- 129.250.24.196 0.0% 1 28.9 28.9 28.9 28.9 0.0
> 12.|-- 129.250.130.2540.0% 1 29.0 29.0 29.0 29.0 0.0
> 13.|-- 129.250.130.2530.0% 1 29.4 29.4 29.4 29.4 0.0
> 14.|-- 129.250.130.2540.0% 1
On Wed, Oct 23, 2019 at 11:18 AM Alain Hebert wrote:
>
> I do not have much to contribute but this.
>
> We already have ( choose your poison(s) )
>
> Dark Fiber + MACsec + BCP38 + ACL + MD5 + MPLS + IRRD + GRE + IPsec +
> yadi yada
much of this isn't solving the problem though, a
On Wed, Oct 23, 2019 at 10:43 AM wrote:
>
> > Sent: Tuesday, October 22, 2019 8:26 PM
> > To: Keith Medcalf
> >
> > No,
> >
> >
> > > On Oct 22, 2019, at 2:08 PM, Keith Medcalf
> > wrote:
> > >
> > > At this point further communications are encrypted and secure against
> > eavesdropping.
> >
> >
On 10/23/19 8:18 AM, Grant Taylor via NANOG wrote:
> I suspect things like NetworkManager are somewhat at a disadvantage in
> that they are inherently machine local and don't have visibility beyond
> the directly attached network segments. As such, they can't /safely/
> filter something that may b
On Wed, 23 Oct 2019 09:09:05 -0600, Grant Taylor via NANOG said:
> > Easing the operation of CGN at scale serves no purpose except stalling
> > necessary change. It is like installing an electric blanket to cure the
> > chill from bed-wetting.
>
> Much like humans can move passenter plains, even an
thanks. constructive folk reached out.
randy
On 10/22/19 11:38 PM, Stephen Satchell wrote:
So, to the reason for the comment request, you are telling me not
to blackhole 100.64/10 in the edge router downstream from an ISP as
a general rule, and to accept source addresses from this netblock.
Do I understand you correctly?
It depends.
I
I do not have much to contribute but this.
We already have ( choose your poison(s) )
Dark Fiber + MACsec + BCP38 + ACL + MD5 + MPLS + IRRD + GRE +
IPsec + yadi yada
PS: Yup, I have SRX300s doing BGP over NNI -and- a GRE + IPsec
on LTE as a backup.
What is the re
On 10/23/19 12:16 AM, Måns Nilsson wrote:
I understand the reasoning. I appreciate the need. I just do not agree
with the conclusion to waste a /10 on beating a dead horse. A /24 would
have been more appropriate way of moving the cost of ipv6 non-deployment
to those responsible. (put in RFC tim
> Sent: Tuesday, October 22, 2019 8:26 PM
> To: Keith Medcalf
>
> No,
>
>
> > On Oct 22, 2019, at 2:08 PM, Keith Medcalf
> wrote:
> >
> > At this point further communications are encrypted and secure against
> eavesdropping.
>
> The problem isn't the protocol being eavesdropped on. The data i
would appreciate unicast contact with someone withq 70x deep routing clue.
researchers want to confirm possible causes of some phemnomona we think
we see. thanks.
randy
On 2019-10-22 22:38 -0700, Stephen Satchell wrote:
> So, to the reason for the comment request, you are telling me not to
> blackhole 100.64/10 in the edge router downstream from an ISP as a
> general rule, and to accept source addresses from this netblock. Do I
> understand you correctly?
Depen
Folks,
Your input would be very welcome. Preferably on the v6ops wg
mailing-list (https://www.ietf.org/mailman/listinfo/v6ops), but also on
this list or multicast to us (authors).
Thanks!
Forwarded Message
Subject: SLAAC renum: Problem Statement & Operational workarounds
Date:
19 matches
Mail list logo
