Re: Verizon 701 Route leak?

[Randy Bush]

> Good use-case for
> https://datatracker.ietf.org/doc/draft-ietf-grow-bmp-adj-rib-out and
> snapshot auditing before and after changes. Leak didn't last long but
> it could have been caught within milliseconds verses minutes via oh
> sh** alarms.

[ i happen to like bmp, but ... ]

if the sender did not have the automation or the mops to not leak in the
first place, how well will they apply post hoc detection and repair?

if the receiver did not filter, and an tier-1 as-path filter would have
sufficed in this case, how well do you think they will be at applying
post hoc detection and repair?

this was an easily preventable ops failure.  but what we will do is go
to idr and grow and invent 42 more hacks, kinda like ipv6 transition
mechanisms.  

randy

Re: Verizon 701 Route leak?

[Randy Bush]

>> Damn you Google.. yup.  Thanks for links.
> A public post-mortem would be highly appreciated (from all parties).

there has been more press hysteria on this than actual packet droppage.

goog fat fingered or otherwise misannounced a numer of large consumer
isp's prefixes.  the leak was for aybe 20 minutes.

almost no one over here noticed.

but the press, isoc, ... said "japan knocked off the internet."  take
that as a calibration of the press, isoc, ...

randy

Re: Hurricane Harvey - Network Status (FCC)

[Timothy Sesow]

Tegna, ownership group of KHOU, had a news report
that the news studio for KHOU was setup at a "PBS station
in Dallas", with satellite uplink to KUSA (Denver).
Master Control is running at KUSA Denver for KHOU
service area, with satellite back to the transmitter
for KHOU.

According to the FCC filing, the transmitter is located SW of Houston 
near Fresno, TX

at 29deg 33min 40secN  95deg 30min 4sec W
Google Maps does show a tower there.



On 08/28/2017 10:51 AM, Jean-Francois Mezei wrote:

On 2017-08-27 20:58, Tim Jackson wrote:

KHOU's local transmitter (Missouri City I think is where it's at) seems to
be back on the air, but with all production from WFAA out of Dallas.


KHOU had a tweet with video showing the water flooding into their
offices/studios and staff having to leave.

https://twitter.com/sallykhou11/status/901805513905668096

I guess this is where disaster tolerance/recovery plans really kick in.



--
---
Timothy Sesow
tse...@osstorage.com
Cell:  303-803-3506
Main Support Number 800-570-3624

Open Source Storage, Inc.
7950 S. Lincoln Street
Unit B104
Littleton, Colorado 80122

Max Prefix Out, was Re: Verizon 701 Route leak?

[Michael Still]

I agree a max-prefix outbound could potentially be useful and would
hopefully not be too terribly difficult to implement for most vendors.

Perhaps RFC4486 would need to be updated to reflect this as a
possibility as well?



On Mon, Aug 28, 2017 at 5:41 PM, Julien Goodwin  wrote:
> On 28/08/17 18:34, Job Snijders wrote:
>> Finally, it may be worthwhile exploring if we can standardize and
>> promote maximum prefix limits applied on the the _sending_ side. This
>> way you protect your neighbor (and the Internet at large) by
>> self-destructing when you inadvertently announce more than what you'd
>> expect to announce. BIRD has this functionality
>> http://bird.network.cz/?get_doc=bird-3.html#proto-export-limit
>> however I am not aware of other implementations. Feedback welcome!
>
> Having just dug up the reference for some strange reason...
>
> Back at NANOG38 (2006) Tom Scholl mentioned in a talk on max prefix:
> "Perhaps maximum-prefix outbound?
> (Suggested by Eric Bell years ago)"
> https://www.nanog.org/meetings/nanog38/presentations/scholl-maxpfx.pdf
>
> Notably Juniper does now have prefix-export-limit, but only for
> readvertisement into IS-IS or OSPF:
> https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/prefix-export-limit-edit-protocols-isis.html



-- 
[stillwa...@gmail.com ~]$ cat .signature
cat: .signature: No such file or directory
[stillwa...@gmail.com ~]$

Re: Cogent BCP-38

[Rob Evans]

> Well, if you are using public IP addresses for infra you are violating your 
> RIR’s policy more than likely.

[Citation needed.] :)

Rob

RE: Verizon 701 Route leak?

[Mikael Abrahamsson]

On Mon, 28 Aug 2017, Marcus Josephson wrote:


Damn you Google.. yup.  Thanks for links.


A public post-mortem would be highly appreciated (from all parties).

--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Cogent BCP-38

[Job Snijders]

On Tue, Aug 29, 2017 at 08:41:12AM -0400, Robert Blayzor wrote:
> > On 29 August 2017 at 03:38, Robert Blayzor  wrote:
> > 
> >> Well not completely useless. BCP will still drop BOGONs at the edge
> >> before they leak into your network.
> > 
> > Assuming you don't use them in your own infra. And cost of RPF is lot
> > higher than cost of ACL. Them being entirely static entities they
> > should be in your edgeACL. The only real justification for loose RPF
> > is source based blackholing.
> 
> Well, if you are using public IP addresses for infra you are violating
> your RIR’s policy more than likely. 

There may be some miscommunication here or confusion on terminology
used. But for instance using public, globally unique addresses for your
router's loopback addresses, or router-to-router linknets is fine and
not a violation.

> And if you’re using RFC1918 space in your global routing table, then
> thats another fiasco you’ll have to deal with.

Then don't do that! :)

> Managing ACL’s for customer routes has far more overhead (and cost,
> ie: time, human error, etc) than to just use RPF on an edge port. I
> believe the OP was talking about multi-homed, in that case if run a
> tight ship in your network RPF loose is probably a good choice.  It at
> least gives you an easy way to not accept total trash at the edge. 

I am not sure what "RPF loose" offers that can't be done with a static
general purpose edge ACL can't offer to protect your infrastructure and
deny obvious bogons.

Kind regards,

Job

Re: Cogent BCP-38

[Robert Blayzor]

> On 29 August 2017 at 03:38, Robert Blayzor  wrote:
> 
>> Well not completely useless. BCP will still drop BOGONs at the edge before 
>> they leak into your network.
> 
> Assuming you don't use them in your own infra. And cost of RPF is lot
> higher than cost of ACL. Them being entirely static entities they
> should be in your edgeACL. The only real justification for loose RPF
> is source based blackholing.
> 
> -- 
>  ++ytti


Well, if you are using public IP addresses for infra you are violating your 
RIR’s policy more than likely. And if you’re using RFC1918 space in your global 
routing table, then thats another fiasco you’ll have to deal with. Managing 
ACL’s for customer routes has far more overhead (and cost, ie: time, human 
error, etc) than to just use RPF on an edge port. I believe the OP was talking 
about multi-homed, in that case if run a tight ship in your network RPF loose 
is probably a good choice. It at least gives you an easy way to not accept 
total trash at the edge. 

--
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://inoc.net/~rblayzor/

Re: Cogent BCP-38

[Saku Ytti]

On 29 August 2017 at 03:38, Robert Blayzor  wrote:

> Well not completely useless. BCP will still drop BOGONs at the edge before 
> they leak into your network.

Assuming you don't use them in your own infra. And cost of RPF is lot
higher than cost of ACL. Them being entirely static entities they
should be in your edgeACL. The only real justification for loose RPF
is source based blackholing.

-- 
  ++ytti