Re: DPDK and energy efficiency

2021-02-23 Thread William Herrin
On Tue, Feb 23, 2021 at 2:22 PM Etienne-Victor Depasquale
 wrote:
>> DPDK doesn't inherently do much in the way of power management.
>
> I agree - it doesn't. That's not what it was made for.
>
>>  Note that DPDK applications are usually intended to run in very-high
>
> data rate environments where no gains are likely to be realized by
> avoiding a busy-wait loop.
>
> That's not what research shows.
>
> Use of LPI states is proposed for power management under high data rate 
> conditions in [5] and
> in [6], use of the low-power instruction halt  is investigated and found to 
> save power under such conditions.

Howdy,

This is way too deep in the weeds of developing with the DPDK
libraries for your audience here to have much in the way of useful
comment.  This is an operators group.

If anyone is interested, the techniques DPDK offers application
authors to manage power on the dataplane cores are described here:

https://doc.dpdk.org/guides/prog_guide/power_man.html

The main thing devs do, since it's easy, is add a call to rte_pause()
in any empty polling loop. IIRC, that just calls the CPU PAUSE
instruction which doesn't actually pause anything but saves a little
power by de-pipelining and, if hyperthreading is enabled, releasing
the core to run the alternate thread.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: DPDK and energy efficiency

2021-02-23 Thread William Herrin
On Mon, Feb 22, 2021 at 11:24 PM Etienne-Victor Depasquale
 wrote:
>>
>> Beyond RX/TX CPU affinity, in DANOS you can further tune power consumption 
>> by changing the adaptive polling rate.  It doesn’t, per the survey, "keep 
>> utilization at 100% regardless of packet activity.”
>
> Robert, you seem to be conflating DPDK
> with DANOS' power control algorithms that modulate DPDK's default behaviour.
> Keep in mind that this is a bare-bones survey intended for busy, 
> knowledgeable people (the ones you'd find on NANOG) -

Hi,

Since you understand that, I'm not really clear what you're asking in
the survey.

DPDK doesn't inherently do much in the way of power management. The
polling loops are in the application side of the software, not the
DPDK libraries or NIC driver. It's up to the application author to
decide to detect idleness in the polling loop and take action to
reduce CPU load. If they go for a simple busy-wait, the dataplane
cores run at 100% all the time regardless of packet load. This has the
expected impact on the server's power consumption.

Note that DPDK applications are usually intended to run in very-high
data rate environments where no gains are likely to be realized by
avoiding a busy-wait loop.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: AWS contact?

2021-02-20 Thread William Herrin
On Fri, Feb 19, 2021 at 4:18 PM Andras Toth  wrote:
> Given the fact that the TCP 3-way handshake is established, sounds like some 
> Path MTU blackholing happening. Due to it happening during TLS handshake it's 
> likely from the server towards you.


Could also be another case of botched anycast TCP where packet #2
arrived at a different server than packet #1.

-Bill



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: dumb question: are any of the RIR's out of IPv4 addresses?

2021-02-16 Thread William Herrin
On Tue, Feb 16, 2021 at 4:47 PM Michael Thomas  wrote:
> So aside from Afrinic, this is all being done on the gray market?

Hi Mike,

No. The market is fully above board with policies written into the RIR
operations to intentionally support its existence. In the ARIN region
that's things like the "specified transfer" policy.

> Wouldn't you expect that price to follow something like an exponential
> curve as available addresses become more and more scarce and unavailable
> for essentially any price?

Most likely, but it's a long curve and we're very, very early on it.
Still lots of eyeballs using public IPv4 addresses who wouldn't be
significantly inconvenienced if they had to share an IPv4 address with
their neighbors. Eventually we'll reach a sharper part of the curve
and suddenly: IPv6.

Regards,
Bill Herrin

On Tue, Feb 16, 2021 at 4:47 PM Michael Thomas  wrote:
>
>
> On 2/16/21 4:18 PM, Fred Baker wrote:
> > You may find this article interesting:
> > https://blog.apnic.net/2019/12/13/keep-calm-and-carry-on-the-status-of-ipv4-address-allocation/
> > <https://blog.apnic.net/2019/12/13/keep-calm-and-carry-on-the-status-of-ipv4-address-allocation/>
> >
> So aside from Afrinic, this is all being done on the gray market?
> Wouldn't you expect that price to follow something like an exponential
> curve as available addresses become more and more scarce and unavailable
> for essentially any price?
>
> Mike
>
>
> > Sent from my iPad
> >
> >> On Feb 16, 2021, at 3:07 PM, Michael Thomas  wrote:
> >>
> >> 
> >> Basically are there places that you can't get allocations? If so,
> >> what is happening?
> >>
> >> Mike
> >>



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: dumb question: are any of the RIR's out of IPv4 addresses?

2021-02-16 Thread William Herrin
On Tue, Feb 16, 2021 at 3:07 PM Michael Thomas  wrote:
> Basically are there places that you can't get allocations?

All of them except possibly Afrinic.

> If so, what
> is happening?

You find someone who has listed their IP addresses for sale via a
broker, buy them, and then request a specified transfer at the RIR
which transfers those addresses to you.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Texas internet connectivity declining due to blackouts

2021-02-16 Thread William Herrin
On Mon, Feb 15, 2021 at 8:18 PM Robert Jacobs 
wrote:

> How about letting us Texans have more natural gas power plants or even let
> the gas be delivered to the plants we have so they can provide more power
> in an emergency. Did not help that 20% of our power is now wind which of
> course in an ice storm like we are having is shut off... Lots of issues and
> plenty of politics involved here..
>

CNN reports that some natural gas and oil plants as well as one nuclear
plant have gone offline because the water source they depend on froze.

"Natural gas and coal-fired power plants need water to stay online. Yet
those water facilities froze in the cold temperatures"

https://www.cnn.com/2021/02/16/business/texas-power-energy-nightmare/index.html

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
<https://bill.herrin.us/>
https://bill.herrin.us/


Re: DoD IP Space

2021-02-15 Thread William Herrin
On Mon, Feb 15, 2021 at 7:49 AM Valdis Klētnieks
 wrote:
> On Sun, 14 Feb 2021 22:25:56 -0800, William Herrin said:
> > This particular problem could be quickly resolved if the OSes still
> > getting updates were updated to default name resolution to prioritize
> > the IPv4 addresses instead. That would allow broken IPv6
> > configurations to exist without breaking the user's entire Internet
> > experience. Which would allow them to leave it turned on so that it
> > resumes working when the error is eventually found and fixed.
>
> Oh, come on Bill.  This ain't your first rodeo.  You know damned well
> that if we do that, the errors are in fact *not* eventually found and fixed.

I don't know that and neither do you. That remains an untested theory.
What I do know, with the perfection of 20/20 hindsight, is that
v6-first has impeded deployment for two decades by routinely giving
folks a reason to turn IPv6 back off.

Hard headed.

Regards,
Bill Herrin




-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: DoD IP Space

2021-02-15 Thread William Herrin
On Sun, Feb 14, 2021 at 11:01 PM Mark Andrews  wrote:
> Complain to your vendors about not implementing RFC 8305, RFC 6724, and
> RFC 7078.  RFC 8305 or RFC6724 + RFC 7078 would fix your issue.
>
> Thats Happy Eyeballs and tuneable address selection rules.
>
> You don’t have to perform the naive connection from getaddrinfo() man page.

Hi Mark,

When I said bull-headed, this is exactly what I had in mind. Happy
eyeballs and things like
https://bill.herrin.us/freebies/libeasyv6-0.1/ aren't first-class
citizens in the APIs. Their code has to be independently added to each
application individually. Getaddrinfo() is core standard. Fix the
problem in the place that fixes it in every place or else it's never
really fixed.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: DoD IP Space

2021-02-14 Thread William Herrin
On Sun, Feb 14, 2021 at 8:27 PM Mark Tinka  wrote:
> Dropping a few feet from cloud nine, there, really, is no other thing
> that will facilitate or hold back the adoption of IPv6, like money.

Well actually, that's not entirely true. One thing holding back IPv6
is the unfortunately routine need to turn it off in order to get one
or another IPv4 thing back working again. Like the disney thing
earlier in this thread. Or like my experience yesterday where I had to
disable IPv6 to fetch files on a particular server because SLAAC was
serving up invalid addresses but the app insisted on trying all 8 IPv6
addresses before it would attempt any of the IPv4 addresses. And of
course I can't call my ISP and say: you're causing my Linux box to
pick up bad IPv6 addresses. Front line support can barely handle IPv4
and Windows.

I stuck with it for a couple hours and figured out how to disable
SLAAC without disabling DHCP-PD so that I could turn IPv6 back on with
addresses which worked. But really, how many people are going to do
that? Most tick the IPv6 checkbox to off and are done with it.

This particular problem could be quickly resolved if the OSes still
getting updates were updated to default name resolution to prioritize
the IPv4 addresses instead. That would allow broken IPv6
configurations to exist without breaking the user's entire Internet
experience. Which would allow them to leave it turned on so that it
resumes working when the error is eventually found and fixed.

Prioritizing IPv6 over IPv4 for newly initiated connections is one of
the trifecta of critical design errors that have been killing IPv6 for
two decades. One of the two that if key folks weren't being so
bull-headed about it, it would be trivial to fix.

Regards,
Bill Herrin

--
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: DoD IP Space

2021-02-11 Thread William Herrin
On Thu, Feb 11, 2021 at 5:52 PM Izaac  wrote:
> On Thu, Feb 11, 2021 at 09:53:56AM -0800, William Herrin wrote:
> > In other words, it proves the exact opposite of your assertion.
>
> Golly.  Do you want to tell the 1M+ AWS customers that the services they
> paid ~$280B for last year don't work, or should I?

You moved the goal post there, Izaac with a z. Your original claim:

On Tue, Feb 9, 2021 at 3:46 PM Izaac  wrote:
> On Fri, Feb 05, 2021 at 02:36:57PM -0800, Owen DeLong wrote:
> > it is definitely possible to run out of RFC-1918 space with scale and no 
> > incompetence.
>
> No, it isn't.

Yes, it is. Amazon did. And you seem to agree they're competent.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: DoD IP Space

2021-02-11 Thread William Herrin
On Thu, Feb 11, 2021 at 6:13 AM Izaac  wrote:
> On Wed, Feb 10, 2021 at 10:38:00AM -0800, William Herrin wrote:
> > None whatsoever. You just have to be really big.
>
> Hi Beel,

That was unnecessary. Sorry I used an S instead of a Z.

> Thanks for backing me up with an example of an organization with
> competent network engineering.  Their ability to almost infinitely
> leverage the existing rfc1918 address space to serve an appreciable
> fraction of all Internet attached hosts is a real demonstration of the
> possible.

Except they don't. One of the reasons you can't put vms in multiple
regions into the same VPC is they don't have enough IP addresses to
uniquely address the backend hosts in every region. They end up with a
squirrelly VPC peering thing they relies on multiple gateway hosts to
overcome the address partitioning from overlapping RFC1918.

In other words, it proves the exact opposite of your assertion.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: DoD IP Space

2021-02-10 Thread William Herrin
On Fri, Jan 22, 2021 at 12:30 PM Izaac  wrote:
> On Wed, Jan 20, 2021 at 02:47:32PM +0100, Cynthia Revström via NANOG wrote:
> > certain large corporations that have run out of RFC1918, etc. space
>
> At what level of incompetence must an organization operate to squander
> roughly 70,000 /24 networks?

Hi Isaac,

None whatsoever. You just have to be really big.

Imagine you're Amazon. You have this insanely large deployment of
servers. Your customers have this virtual concept you've presented
them called a "VPC" but there are no wires or routers. The subnets
only exist as bits in memory. The Virtual Private Cloud is a ruleset
in the network adapter of every physical machine running one of the
VMs that participate in the VPC. A big, flat network where every one
of these servers has a need to talk to every other server that could
possibly be tasked to run a VM in that VPC.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Half Fibre Pair

2021-01-26 Thread William Herrin
On Tue, Jan 26, 2021 at 12:52 PM Rod Beck
 wrote:
> Can someone explain to me what is a half fibre pair? I took it
> literally to mean a single fibre strand but someone insisted it
> was a large quantity of spectrum. Please illuminate.


Maybe it's like half a pair of glasses, the perfect accessory for the
one-eyed man who's king.

Seriously though, it sounds like a bad language construction. If a
vendor is offering you that, I'd ask for clarification. Are they
leasing a dedicated strand of fiber end-to-end? Dedicated wavelength
directions delivered by fiber? Something else?

If you're thinking of offering it, find better words.

Regards,
Bill Herrin


Re: gofundme Medical Expenses - Ed Hew

2021-01-25 Thread William Herrin
On Mon, Jan 25, 2021 at 10:08 AM Jim Mercer  wrote:
> On Mon, Jan 25, 2021 at 09:23:11AM -0800, William Herrin wrote:
> > On Mon, Jan 25, 2021 at 8:40 AM Jim Mercer  wrote:
> > > unsure if this is allowed or not, but, here goes.
> >
> > This is a lie.
>
> there have been any number of threads, short, or overly long about the
> deaths of contributors, so, i don't feel the least bit guilty for starting
> this one about someone not quite there.

And I generally don't complain. It's not as if every one of my posts
has been flawlessly on topic. But when I do deliberately break the
rules, I try not to prefix it by pretending otherwise. And you're not
reporting on Ed's passing, you're making a money pitch on an
ends-justify-the-means basis.

Regards,
Bill Herrin


Re: gofundme Medical Expenses - Ed Hew

2021-01-25 Thread William Herrin
On Mon, Jan 25, 2021 at 8:40 AM Jim Mercer  wrote:
> unsure if this is allowed or not, but, here goes.

Hi Jim,

This is a lie. If you weren't sure, you'd have asked if it was ok to
do the thing without actually doing the thing. That you went ahead and
did it says you were pretty sure it was against the rules and figured
you could get away with it. You may be right but the lie compounds the
offense.

I'm sorry to hear about Ed. Nevertheless, a lot of us are getting on
in age and health and the Internet doesn't need another mailing list
about how sad it is to grow old.

May I suggest: spend a line in your signature block on the off-topic
things you want folks on this group to know. And then attach it only
to messages which are on topic.

Regards,
Bill Herrin


Re: USENET peers?!

2021-01-20 Thread William Herrin
On Wed, Jan 20, 2021 at 12:40 PM  wrote:
> 2. Usenet is dead and besides a full feed is 20+TB/day because it's
> dead, but 20TB/day...

Hi Barry,

How much is it per day if you skip the groups distributing
finger-quote "linux isos"?

Regards,
Bill Herrin


Re: Hosting recommendations ... ?

2021-01-19 Thread William Herrin
On Tue, Jan 19, 2021 at 9:18 AM Bryan Holloway  wrote:
> Perhaps I'm missing something, but in your #1 example "Cloud", what
> prevents me from running a Proxmox ISO (which is more or less Debian)
> vs. a "standard" Debian install on the provider's virtual server?

Hi Bryan,

I haven't used Proxmox but from a 60 second glance through Google that
looks like you're asking for nested virtualization. If it works at
all, you'd take a double-hit on everything that wants to run in ring
0, a double-hit on virtualized I/O and a double-hit for OS overhead
making the result more than a little sluggish. Kinda has "bad idea"
written all over it.

As I understand it, you can "cat /sys/module/kvm*/parameters/nested"
in one of the service provider's VMs and if the answer is "1" or "Y"
for the CPU type which matches the exposed CPU then what you're asking
for will probably work. For some definition of work anyway.


I use Vultr for my primary BGP exit and have found it largely
painless. The VMs I have there DO NOT support nested virtualization.
They do claim a bare metal offering but it's currently listed as sold
out in all of their data centers. They also claim to provide mountable
block storage for compute instances up to 10TB per, but I haven't
worked with that feature, I presume it only applies to virtual
servers, and it looks like it's only available in one of their data
centers.

Regards,
Bill Herrin



--
Hire me! https://bill.herrin.us/resume/


Re: Hosting recommendations ... ?

2021-01-19 Thread William Herrin
On Tue, Jan 19, 2021 at 8:31 AM Bryan Holloway  wrote:
> I would like to stop personally dealing with bare-metal. That's what I'm
> doing now.

Hi Bryan,

Cloud = you get virtual servers with virtual storage, generally
adjustable to meet your needs. You manage the operating systems and
storage within the virtual environment. You DO NOT manage the host
operating systems or hypervisors.

Bare metal = you lease physical equipment. You manage all software on
the equipment including any hypervisors needed to run virtual servers.
You DO NOT deal with hardware break/fix, that problem belongs to the
service provider.

Colocation = You lease space in a data center. You provide physical
equipment in your custom configuration.

With this terminology, at least one of your requirements is unmeetable
for contradicting the others. So I ask again for clarification: which
of these do you seek?

Regards,
Bill Herrin


Re: Hosting recommendations ... ?

2021-01-19 Thread William Herrin
On Tue, Jan 19, 2021 at 8:20 AM Josh Luthman
 wrote:
> I'm kind of confused when your concern is the reputability and yet you're 
> providing your own IP space.

Hi Josh,

I'm not above discarding announcements with a "bulletproof" hoster in
the AS path. Are you?

Regards,
Bill Herrin

On Tue, Jan 19, 2021 at 8:20 AM Josh Luthman
 wrote:
>
> I'm kind of confused when your concern is the reputability and yet you're 
> providing your own IP space.
>
> It sounds more to me like you want to put 2-3 boxes in a data center.  For 
> that pretty much any decent sized data center in any state would work for the 
> US.
>
> Josh Luthman
> 24/7 Help Desk: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
>
>
> On Tue, Jan 19, 2021 at 11:14 AM William Herrin  wrote:
>>
>> On Tue, Jan 19, 2021 at 7:45 AM Bryan Holloway  wrote:
>> > Looking for a reputable (i.e., no hosting of spammers or other
>> > ne'er-do-wells) hosting provider with possibly a global footprint. If
>> > not, US is #1 desire; EU #2.
>> >
>>
>> > * Desire to host 2-3 hypervisors, probably running something akin to
>> > Proxmox ...
>> > * ~5-10TB storage with the possibility of expansion ...
>>
>> Howdy,
>>
>> You should clarify what sort of hosting service you're looking for. A
>> normal cloud service won't see you running your own hypervisors. A
>> server farm will see you deploy your own hardware with whatever
>> storage you choose to install. Only a "bare metal" cloud service would
>> meet both of your listed requirements, where you lease both the
>> equipment and hosting service from the provider. However, combined
>> with your BGP requirement your options are very limited and expanding
>> storage usually means "lease a different one of our servers."
>>
>> Regards,
>> Bill Herrin
>>
>>
>>
>> --
>> Hire me! https://bill.herrin.us/resume/



-- 
Hire me! https://bill.herrin.us/resume/


Re: Hosting recommendations ... ?

2021-01-19 Thread William Herrin
On Tue, Jan 19, 2021 at 7:45 AM Bryan Holloway  wrote:
> Looking for a reputable (i.e., no hosting of spammers or other
> ne'er-do-wells) hosting provider with possibly a global footprint. If
> not, US is #1 desire; EU #2.
>

> * Desire to host 2-3 hypervisors, probably running something akin to
> Proxmox ...
> * ~5-10TB storage with the possibility of expansion ...

Howdy,

You should clarify what sort of hosting service you're looking for. A
normal cloud service won't see you running your own hypervisors. A
server farm will see you deploy your own hardware with whatever
storage you choose to install. Only a "bare metal" cloud service would
meet both of your listed requirements, where you lease both the
equipment and hosting service from the provider. However, combined
with your BGP requirement your options are very limited and expanding
storage usually means "lease a different one of our servers."

Regards,
Bill Herrin



-- 
Hire me! https://bill.herrin.us/resume/


Re: Issues with NANOG mailing list operations and subscriptions

2021-01-17 Thread William Herrin
On Sun, Jan 17, 2021 at 1:37 PM Sean Donelan  wrote:
> Some people think its funny to ghost subscribe email addresses, and
> the NANOG mailing list auomation doesn't catch them in the verification
> process.

Hi Sean,

How is that possible? This is exactly what a correctly implemented
confirmed opt-in procedure is designed to prevent.

Regards,
Bill Herrin



-- 
Hire me! https://bill.herrin.us/resume/


Re: Parler

2021-01-17 Thread William Herrin
On Wed, Jan 13, 2021 at 3:41 PM Matt Corallo  wrote:
> $ dig parler.com ns
> parler.com. 300 IN  NS  ns4.epik.com.
> parler.com. 300 IN  NS  ns3.epik.com.

Looks like Parler managed to bring up a placeholder web site via a
Belize (LACNIC) registered IP address managed by someone with a
Russian email address.

nslookup parler.com
Name:   parler.com
Address: 190.115.31.151

whois 190.115.31.151
inetnum: 190.115.16.0/20
status:  allocated
aut-num: AS262254
owner:   DDOS-GUARD CORP.
ownerid: BZ-DALT-LACNIC
responsible: Evgeniy Marchenko
address: 1/2Miles Northern Highway, --, --
address: -- - Belize - BZ
country: BZ
phone:   +7 928 2797045
owner-c: HUN8
tech-c:  HUN8
abuse-c: HUN8

nic-hdl: HUN8
person:  Huan Nadas
e-mail:  xeng...@mail.ru
address: Avenue Jorge Perez Concha, 712, -
address: 090511 - Guayaquil -
country: EC
phone:   +7  9282797045 []


Re: Re Parler

2021-01-14 Thread William Herrin
On Thu, Jan 14, 2021 at 10:13 AM  wrote:
> (b) Termination for Cause.
> (i) material breach remains uncured for a period of 30 days from receipt of 
> notice

It's fairly clear from Amazon's communications that this is their
basis for terminating Parler. They began notifying Parler in September
that Parler's content moderation efforts were not acceptable, offered
examples and used progressively stronger language to express their
dissatisfaction with Parler's remedies. I suppose it remains to be
seen whether a court will accept the argument but there's no need to
speculate about what their argument is.

Regards,
Bill Herrin


-- 
Hire me! https://bill.herrin.us/resume/


Re: Parler

2021-01-14 Thread William Herrin
On Thu, Jan 14, 2021 at 8:47 AM Matt Erculiani  wrote:
> Is there a remote possibility here that Verisign might say "yeah, we're gonna 
> glue this domain down to 0.0.0.0 and not allow registration"?

Absent a court order? No, not a chance. Verisign is not parler's
registrar. They'd be inviting twelve different kinds of liability
interfering without government sanction.

Regards,
Bill Herrin


Re: Parler

2021-01-13 Thread William Herrin
On Wed, Jan 13, 2021 at 9:22 PM Matt Corallo  wrote:
> Sure, I just found it marginally comical that amazon, after making a big 
> stink about kicking them off, is still providing them service, even if it’s 
> one-hop indirect. That said, someone else suggested that Epik is denying that 
> they will host the site, only providing registrar services for the domain, so 
> it’s not as comparable as I understood it to be.

Hi Matt,

I'm not sure I agree with characterizing DNS hosting as a registrar
service. It makes sense to sell them together but they're not
classically the same thing.

Epik is also entangled with Clouthub which I hear is where Trump landed.

Regards,
Bill Herrin



-- 
Hire me! https://bill.herrin.us/resume/


Re: Parler

2021-01-13 Thread William Herrin
On Wed, Jan 13, 2021 at 9:02 PM Valdis Klētnieks
 wrote:
> On Wed, 13 Jan 2021 18:41:55 -0500, Matt Corallo said:
> > parler.com.   300 IN  NS  ns4.epik.com.
> > parler.com.   300 IN  NS  ns3.epik.com.
> > ...
> > ns3.epik.com. 108450  IN  A   52.55.168.70
>
> It's quite possible that Amazon is playing this *entirely* by the book, and
> the Parler crew haven't violated the terms of the nameserver hosting
> agreement so Amazon hasn't cut that off.

No, they were hosted on Route53 back on Sunday. Now they're hosted by
Epik which implements their own DNS servers using the AWS
infrastructure.

Regards,
Bill Herrin


-- 
Hire me! https://bill.herrin.us/resume/


Re: End-user Alert Delivery (was Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study)

2021-01-13 Thread William Herrin
On Wed, Jan 13, 2021 at 7:58 PM Jay R. Ashworth  wrote:
> Last time I looked, consumer residential smoke detectors were still running
> off 9V alkaline batteries, which are expected to run the device for 6 months
> of 1/99 duty cycle (or less, probably *way* less).

Ordinary ionization-based smoke detectors use a 10-year lithium
battery, which is about the same lifespan as the americium-based
detector circuit as it begins to decay into neptunium.

You may now resume your argument over how much battery drain is too much.

Regards,
Bill Herrin


-- 
Hire me! https://bill.herrin.us/resume/


Re: DMVPN via Internet or Private APN

2021-01-12 Thread William Herrin
On Tue, Jan 12, 2021 at 8:55 AM Sean Kelly  wrote:
> The real debate arrives when it's time to choose a carrier to host the
> router. I choose to go with a major cell carrier using a "private"
> APN. It allows me to connect my cell routers to a private layer 2
> network and my private IP addresses will be used to provide layer 3
> connectivity. I know that there will be outliers that can't use this
> carrier or cellular at all. These outliers, in my opinion, shouldn't
> have a majority stake in the overall design. The APN overall cost is
> low and so is the data plan for the hosted routers. The private APN
> also eliminates the router as an internet attack vector. I don't
> believe routers are appropriate security appliances to defend and
> monitor against network threats.

Hi Sean,

You want vendor lock-in on your emergency access path? Are you sure?

> Some of my colleagues believe that the flexibility of public cellular
> access outweighs the security risks.

I think your colleagues are correct. Shoot for an OOB solution that
allows you to pick the best technology and vendor for each site you
choose to protect. That won't necessarily even be cellular everywhere.

Regards,
Bill Herrin


-- 
Hire me! https://bill.herrin.us/resume/


Re: Parler

2021-01-11 Thread William Herrin
On Mon, Jan 11, 2021 at 8:46 PM Matthew Petach  wrote:
> ...unless the higher calling of "religious freedom" is at stake,
> in which case, sure, it's OK to exclude entire classes of people,
> if serving them would go against your religious beliefs.
> precedent set by
> Masterpiece Cakeshop v. Colorado Civil Rights Commission, 584 U.S. ___ (2018)

Hi Matt,

As I recall, the finding in Masterpiece Cakeshop was that the
commission screwed up the execution of their process so badly that the
result was void. Although both sides badly wanted the court to set a
precedent around excluding customers on a religious basis, it did not
do so.

Regards,
Bill Herrin

-- 
Hire me! https://bill.herrin.us/resume/


Re: more bad lawyering about Parler

2021-01-11 Thread William Herrin
On Mon, Jan 11, 2021 at 2:51 AM Joe Greco  wrote:
> Are there examples that do not conflate other areas of the law?

Hi Joe,

I expect so. Maynard v. Snapchat, for example, in which the court
found that snapchat had no section 230 immunity in a lawsuit related
to its speed overlay feature for user-generated content. Snapchat
eventually won the case on a different theory.

I don't expect to find much if anything that's both directly on point
for Amazon/Parler and contrary to John's citations. But then I didn't
claim there would be. What I actually said was that the "courts have
been all over the place" on how much control an online service had to
have over third-party content before section 230 no longer applied. I
think the three cases I've now cited for you illustrate that.

Regards,
Bill Herrin

--
Hire me! https://bill.herrin.us/resume/


Re: more bad lawyering about Parler

2021-01-11 Thread William Herrin
On Mon, Jan 11, 2021 at 2:19 AM Danny O'Brien  wrote:
> On Sun, Jan 10, 2021 at 8:54 PM William Herrin  wrote:
>> there have been some real post-CDA head scratchers where
>> a court decided that an online service exercised sufficient control of
>> the content to have made itself a publisher.
>
> You really need to give citations here, because IMHO not only is this 
> *exactly* the scenario that Section 230 was intended to provide legal clarity 
> regarding (and so protect service providers from this kind of moderation 
> double-bind), but as I understand it pretty much all the subsequent caselaw 
> has *strengthened* the ability for providers to moderate and manage content, 
> including user-generated content, without triggering liability.

Well, for example, Oberdorf v. Amazon.com, No. 18-1041 (3rd Cir. July
3, 2019) which found that Amazon was a seller of goods and not merely
hosting information about a third party's sale, and thus subject to
product liability law for the product that was sold. But in the Erie
Insurance case, with similar circumstances, the court found the
opposite, that section 230 barred the plaintiff from suing Amazon over
a defective third-party product.

Regards,
Bill Herrin


-- 
Hire me! https://bill.herrin.us/resume/


Re: Parler

2021-01-10 Thread William Herrin
On Sun, Jan 10, 2021 at 8:32 PM  wrote:
> > On Jan 10, 2021, at 1:45 PM, Michael Thomas  wrote:
> >> On 1/10/21 10:21 AM, William Herrin wrote:
> >> Are you sure about that? Consider your database. Suppose you want to
> >> run your primary database in AWS with a standby replica in Azure. As
> >> long as you install your own database software in both, you can do
> >> that. But if you want to leverage AWS' RDS products too, you're mostly
> >> out of luck.
> >
> > Is RDS based on something else? I find it hard to believe that they wrote a 
> > rdb from scratch. But yes, once they own your db they own you. I've looked 
> > before how to migrate from mysql to postgres and was shocked at how little 
> > there seems to be out there to even do even the easier stuff let alone the 
> > proprietary extensions.

> They have Amazon Aurora versions of many popular databases which are binary 
> compatible with the standard versions. So you can run standard Postgres on 
> one cloud and Aurora Postgres in AWS.


Look closer. The AWS RDS version of mysql is unable to replicate with
your version of mysql. The configuration which would permit it is not
exposed to you.

Unless something has changed in the last couple years?

Regards,
Bill Herrin



-- 
Hire me! https://bill.herrin.us/resume/


Re: more bad lawyering about Parler

2021-01-10 Thread William Herrin
On Sun, Jan 10, 2021 at 8:13 PM John Levine  wrote:
>
> In article 
>  you 
> write:
> >With private organizations it gets much more complicated. No
> >organization is compelled to publish anything. But then section 230 of
> >the DMCA comes in and says: if you exercise editorial control over
> >what's published then you are liable for any unlawful material which
> >is published. ...
>
> Sigh. This is false. 100% false. It is the exact opposite of what 47
> USC 230 really says. Also, it's the CDA, not the DMCA.

Hi John,

I conflated some of the DMCA safe harbor stuff with the CDA publisher
stuff. My bad.

I stand by the gist of what I said which, while imprecise, is
consistent with what you posted. The common law precedent is that
publishers are liable for what they publish. Section 230 carves out
the rules for when an online service is not a publisher (which is
decidedly not "always"), and while I don't have the cases on the tip
of my tongue, there have been some real post-CDA head scratchers where
a court decided that an online service exercised sufficient control of
the content to have made itself a publisher.

That said, I encourage folks to refer to your message for the
excellent quotes and references.

Regards,
Bill Herrin


-- 
Hire me! https://bill.herrin.us/resume/


Re: Parler

2021-01-10 Thread William Herrin
On Sun, Jan 10, 2021 at 6:58 PM Matthew Petach  wrote:
> Private businesses can engage in prior restraint all they want.

Hi Matt,

You've conflated a couple ideas here. Public accommodation laws were
passed in the wake of Jim Crow to the effect that any business which
provides services to the public must provide services to all the
public. Courts have found such laws constitutional. Not to mention the
plethora of common-law precedent in this area. You can set rules and
enforce them but those rules can't arbitrarily exclude whole classes
of people nor may they be applied capriciously.

Businesses which post the sign that starts, "we reserve the right,"
are quite mistaken. If a customer is rejected and removed without good
cause and thereby injured, a business can find itself on the losing
end of a lawsuit.

"No shirt, no shoes, no service," on the other hand, is entirely
enforceable so long as that enforcement is consistent.

The legal term "prior restraint" is even more narrowly focused. It
refers only to blocking publication on the grounds that the material
to be published is false or otherwise harmful. The government is
almost never allowed to do so. Instead, remedies are available only
after the material is published.

With private organizations it gets much more complicated. No
organization is compelled to publish anything. But then section 230 of
the DMCA comes in and says: if you exercise editorial control over
what's published then you are liable for any unlawful material which
is published. More precisely, common law precedent says you're liable
for what you publish. Section 230 grants immunity to organizations who
_do not_ exercise editorial control. But what is editorial control?
The courts have been all over the place on that one.

Regards,
Bill Herrin



Regards,
Bill Herrin

--
Hire me! https://bill.herrin.us/resume/


Re: Parler

2021-01-10 Thread William Herrin
On Sun, Jan 10, 2021 at 7:05 AM  wrote:
> Another interesting angle here is that it as ruled President couldn’t
> block people, because his Tweets were government communication.
> So has Twitter now blocked government communication?

Howdy,

The President is a government official. Government officials may not
obstruct access to public government communication.

Twitter is a private enterprise. Outside of things like the emergency
broadcast system or a consensual contract, no private enterprise is
compelled to publish or circulate any government communication.

Regards,
Bill Herrin


-- 
Hire me! https://bill.herrin.us/resume/


Re: Parler

2021-01-10 Thread William Herrin
On Sun, Jan 10, 2021 at 9:55 AM Töma Gavrichenkov  wrote:
> I'd say it starts to be "inconvenient approaching impossible" only at
> the point where you begin to use Cloudformation — or when you don't
> have automated deployment at all.  While the provisioning tools are
> provider agnostic, a move from a provider to a provider would take
> days at most.

Hi Töma,

Are you sure about that? Consider your database. Suppose you want to
run your primary database in AWS with a standby replica in Azure. As
long as you install your own database software in both, you can do
that. But if you want to leverage AWS' RDS products too, you're mostly
out of luck.

Regards,
Bill Herrin


-- 
Hire me! https://bill.herrin.us/resume/


Re: Parler

2021-01-10 Thread William Herrin
On Sun, Jan 10, 2021 at 5:43 AM Mike Bolitho  wrote:
> Can we please not go down this rabbit hole on here? List admins?

Hi Mike,

While there's certainly an opportunity to get political, there are
some obviously apolitical issues worth discussing here as well.

First, this would appear to be an illustration of the single-vendor
problem. You don't have a credible continuity of operations plan if a
termination by a single vendor can take you and keep you offline. It's
the single point of failure that otherwise intelligent system
architects fail to consider and address. But more than that, cloud
providers like Amazon tend to make it inconvenient approaching
impossible to build cross-platform services. I kinda wonder what a
cloud services product would look like that was actively trying to
facilitate cross-platform construction?

Second, Amazon strongly encourages customers to build use of its
proprietary services and APIs into the core of the customer's product.
That's quite devastating when there's a need to change vendors.
Parler's CEO described Amazon's action as requiring them to "rebuild
from scratch," so I wonder just how tightly tied to such Amazon APIs
they actually are. And if there isn't a lesson there for the rest of
us.

These two issues, at least, are technical in nature and on topic for
this forum. You may choose not to discuss them if they don't interest
you, of course.

Regards,
Bill Herrin


-- 
Hire me! https://bill.herrin.us/resume/


Parler

2021-01-10 Thread William Herrin
Anybody looking for a new customer opportunity? It seems Parler is in
search of a new service provider. Vendors need only provide all the
proprietary AWS APIs that Parler depends upon to function.

https://www.washingtonpost.com/technology/2021/01/09/amazon-parler-suspension/

Regards,
Bill HErrin


Re: nike.com->nike.com/ca

2021-01-06 Thread William Herrin
On Wed, Jan 6, 2021 at 2:32 PM Kain, Becki (.)  wrote:
> Yet I could goto the site, via Ford's network (h, shopping at home) and 
> I'm in the same city as Ford.

Hi Becki,

A couple basic things you could try: plug your public IP address into
Whois and see what comes back. Plug it into the Maxmind database and
see what comes back. Poke your ISP if either one says Canada.

Unless you are the Internet provider, I'd stop there, open a trouble
ticket with my ISP and let them worry about it. I'd be dripping with
sarcasm if I said that identifying the current physical location of an
IP address is an inexact science.

Regards,
Bill Herrin


-- 
Hire me! https://bill.herrin.us/resume/


Re: nike.com->nike.com/ca

2021-01-06 Thread William Herrin
On Wed, Jan 6, 2021 at 2:00 PM Christopher Morrow
 wrote:
> quite possible' :) (you don't normally, but I think the HTTP thing is
> the 'gotcha')

Yeah, it got me. I realized it shortly after sending the email.


> (also, typical geo ip problems :( bummer!)

Yeah, likely still qualifies as Using GeoIP For Customer-Visible
Purposes Is Doomed To Failure. Though with web there could be a number
of alternate explanations. Stale or misinterpreted cookies. Browser
add-ons that proxy requests. Viruses or anti-virus programs that
intercept and proxy requests. The number of squirrelly things that
browsers and web sites do boggles the mind.

Regards,
Bill Herrin



-- 
Hire me! https://bill.herrin.us/resume/


Re: nike.com->nike.com/ca

2021-01-06 Thread William Herrin
On Wed, Jan 6, 2021 at 1:48 PM William Herrin  wrote:
> On Wed, Jan 6, 2021 at 1:42 PM Kain, Becki (.)  wrote:
> > At home, using 8.8.8.8, if I goto www.nike.com, I get rerouted to 
> > nike.com/ca. I cleared the dns cache (I’m running Catalina macos) and 
> > rebooted just because.  Anyone else seen a weirdism on this?  thanks
>
> Welcome to Why You Shouldn't Make Customer-Visible Decisions Based On
> DNS Resolver Geolocation or DNS Load Balancing Sucks 101.
>
> Nike.com is geolocating the server IP address which requests the web
> site address. This isn't yours or 8.8.8.8 but instead some unicast IP
> address to which your 8.8.8.8 packet was routed. Possibly in Canada.
> Nike appears to think so.

Though I'm probably talking out my tail since this is an HTTP redirect
which would know your originating IP address (unless you're knowingly
or unknowingly using a proxy).

-Bill



-- 
Hire me! https://bill.herrin.us/resume/


Re: nike.com->nike.com/ca

2021-01-06 Thread William Herrin
On Wed, Jan 6, 2021 at 1:42 PM Kain, Becki (.)  wrote:
> At home, using 8.8.8.8, if I goto www.nike.com, I get rerouted to 
> nike.com/ca. I cleared the dns cache (I’m running Catalina macos) and 
> rebooted just because.  Anyone else seen a weirdism on this?  thanks

Welcome to Why You Shouldn't Make Customer-Visible Decisions Based On
DNS Resolver Geolocation or DNS Load Balancing Sucks 101.

Nike.com is geolocating the server IP address which requests the web
site address. This isn't yours or 8.8.8.8 but instead some unicast IP
address to which your 8.8.8.8 packet was routed. Possibly in Canada.
Nike appears to think so.

Regards,
Bill Herrin




-- 
Hire me! https://bill.herrin.us/resume/


Re: [EXTERNAL]Need someone with clue @ Network Solutions.

2020-12-15 Thread William Herrin
On Tue, Dec 15, 2020 at 9:41 AM Matthew Crocker
 wrote:
> It appears I should have been looking for clue in my own network.  Amazon 
> hosts crocker.com and they have the glue records.  Apparently left over from 
> when the domain was with Network Solutions.   I have tickets open with Amazon 
> to get them removed/updated.


Yeah, the basic problem you have is that AWS is not a full service
registrar, so when you register and host your domain in Route53, you
don't have access to some of the tools a normal registrar gives you.
Namely creating and deleting glue records associated with your domain.
Even when you host with AWS you're kinda better off registering
somewhere else.

Regards,
Bill Herrin


-- 
Hire me! https://bill.herrin.us/resume/


Re: Weather Service faces Internet bandwidth shortage, proposes limiting key data

2020-12-10 Thread William Herrin
On Thu, Dec 10, 2020 at 12:14 AM Rich Kulawiec  wrote:
> > Weather Service faces Internet bandwidth shortage, proposes limiting key 
> > data
> > The National Weather Service is proposing to place limits on accessing its
> > life-saving weather data in a bid to fix Internet outages.
> > By Jason Samenow and Andrew Freedman
> >
> > https://www.washingtonpost.com/weather/2020/12/09/nws-data-limits-internet-bandwidth/

> This seems like a problem that this group could solve rather rapidly with 
> minimal
> incremental expense.  It also seems like one that's very much worth solving.


If I had to venture a guess, it's not a network problem it's a web
server problem. It's far too easy to design a web server where each
request consumes 10 to 100 times the processing that it absolutely
needs to, often with database bottlenecks that further constrain
scalability. Put such a system under broad load and of course it
collapses.

Regards,
Bill Herrin


-- 
Hire me! https://bill.herrin.us/resume/


Re: A letter from the CEO

2020-11-22 Thread William Herrin
On Sun, Nov 22, 2020 at 10:37 PM Carsten Bormann  wrote:
> On 2020-11-20, at 23:18, 6x7 Networks - Lady Benjamin, CEO  
> wrote:
> > 8tbps (8 terrabits per second).
> I don’t expect the majority of nanog people to know the intended data rate 
> would properly be notated as 8 Tbit/s, but a space after the number, an upper 
> case T, and not confusing Tera (SI prefix for 1 Trillion) with Terra (earth), 
> is about the minimum I would expect from a technical person.

Hi Carsten,

You must be talking the "new" comm-speak because "bps" has been the
conventional abbreviation for "bits per second" since at least the
modem days of the 1980s with the "thousands" modifier typically
offered lower case so as not to distract from or be confused with the
digits: kbps, mbps, gbps, tbps. The lack of a space between the digits
and letters also follows convention.

There's nothing wrong with saying "8 Tbit/s" instead. It's just as
clear and no one sensible cares. But complaining about others using
the normal convention frankly makes you look like a doofus.

Regards,
Bill Herrin


Re: AFRINIC IP Block Thefts -- The Saga Continues

2020-11-16 Thread William Herrin
On Sun, Nov 15, 2020 at 10:58 PM Elad Cohen  wrote:
> Anyone that is interested to receive any answer from me, please email me 
> directly, I will say that Ronald Guilmette is intentionally spreading lies, 
> and for the sake of Nanog community I will not reply to him over and over in 
> the same coin, I was gladly interested in the past to share all the 
> information (including AfriNIC legal proceedings) with a person respected by 
> the Nanog community (and I'm still interested to do so today), such as 
> William Herrin, or to anyone else respected by the Nanog community.

Ugh. I don't suppose I can gracefully decline this honor?


>  legacy netblocks that I purchased legally, in what AfriNIC and Ronald 
> Guillmette and Jan Vermeulen are calling "misappropriation". If anyone can 
> explain that to me I will be thankful.
> Ronald Guilmette match one by one to the description of the lawless one in 
> old scriptures:

If AfriNIC says your "purchases" are misappropriation you'll have to
do a lot better than conspiracy theories and phrenology in counter
argument.

You could probably have picked a better venue for it too, one whose
participants aren't presently being treated to an exhausting quantity
of whack-job conspiracy theories every time they turn on the news.
You'll find us predisposed to believe the peddler of a conspiracy
theory to be a fool.

Regards,
Bill Herrin

P.S. Ronald, I know you've been spoken to about ad hominem attacks.
You could have stopped after the first two paragraphs and the link.
Your screed and faux questions about what crooks you thought these
folks to be added exactly nothing to the conversation you hoped to
start.


Re: Technology risk without safeguards

2020-11-06 Thread William Herrin
On Fri, Nov 6, 2020 at 12:00 PM Rich Kulawiec  wrote:
> p.s.2: The large quantities of power conduits, cables, shelving, racks,
> HVAC ductwork, etc. that are typical of datacenters constitute a haphazard
> but modestly effective EM shield, as measured on an ad hoc basis by anyone
> who tries to receive external signals inside them (even when everything
> is powered down) will quickly discover.

Hi Rich,

I expect that has more to do with the windowless concrete-and-steel
construction of the data center building.

Regards,
Bill Herrin



-- 
Hire me! https://bill.herrin.us/resume/


Re: Technology risk without safeguards

2020-11-05 Thread William Herrin
On Thu, Nov 5, 2020 at 5:59 AM Tom Beecher  wrote:
> Let's say roughly half of the science says the hypothesis is false, and half 
> says it is true. It is absolutely fair in this case to state "We don't know 
> enough."

Hi Tom,

Strictly speaking, if a hypothesis is disproven by even one repeatable
experiment then the hypothesis is disproven. It doesn't rule out that
a similar hypothesis could be true but that particular one is false.

Suresh's case can also be dismissed with Security 101: never spend
more protecting an asset than the value of the asset. Practically
speaking this means you assign a risk cost to a particular kind of
attack and then consider whether there are any protections from the
attack which cost less than the risk. That's Vulnerability * Threat *
Incident Cost.

The vulnerability to someone tunnelling under your data center to set
up an RF generator is not high. The logistics of such an effort are
very complicated and the inverse square law dictates that the power in
an RF signal deteriorates quickly with distance even in free air, let
alone with ground between you and the recipient. It is, in a nutshell,
impractical.

The threat for someone tunnelling under your data center to set up an
RF generator is basically zero. There are examples of tunnelling in
crime and war but both involve clandestinely overcoming a superior
force, such as breaking someone out of prison, evading detection by
authorities when smuggling or destroying a fortified military position
with explosives. There is no superior force guarding a data center.
Following staff home and picking them off with a rifle is so much
cheaper and carries a better probability of success.

Nearly zero times zero times some possibly high incident cost still
equals zero. The risk-cost from Suresh's scenario is zero. Hence the
security efforts it justifies are zero.

Regards,
Bill Herrin

-- 
Hire me! https://bill.herrin.us/resume/


Re: Technology risk without safeguards

2020-11-04 Thread William Herrin
On Wed, Nov 4, 2020 at 11:37 AM Suresh Kalkunte  wrote:
> Your comments gives me an overall impression that data center equipment are 
> on average adequately protected, that is good. Also, public discussion on the 
> risk of intentional EMI is a big positive.

I watched a T.V. program a few years ago where an investigative
reporter did a piece on the risks of malicious electromagnetic
interference (EMI). He did a demonstration where he tried to cause a
car to malfunction. A bad actor could cause highway crashes! He had a
great big apparatus about the size of the car's engine compartment and
pointed at the car. Nothing happened. So he moved it about 3 feet from
the car. Nothing happened. So he opened the car's hood and pointed it
right at the engine. Finally the engine started sputtering and the
dashboard electronics malfunctioned. The car, of course, remained
completely controllable and when the EMI generator was turned off it
resumed normal operation undamaged.

I've also had lightning hit about 50 feet from my unshielded computer
room. It fried a little plastic COTS router that was connected by
about 100 feet of UTP ethernet to my core router. The core router
crashed but worked fine after a reboot. No other equipment was
affected.

Vulnerability to EMI is a lot less than folks imagine.

> However, targeting a human using powerful RF is uncharacterized (please see 
> https://github.com/sureshs20/De_Risk_Technology). If the RF emitters 
> conducive for getting re-purposed for malice were prohibitively expensive 
> _or_ the expertise to re-purpose RF for malice was very complex _or_ if there 
> were diagnostic/forensic tests to detect foul-play using powerful RF, I would 
> not be pursuing this initiative to safeguard unsuspecting/defenseless targets 
> of opportunity.

Malicious use of EMI emitters to harm human health is definitely out
of scope for this list.

Regards,
Bill Herrin

-- 
Hire me! https://bill.herrin.us/resume/


Re: Technology risk without safeguards

2020-11-04 Thread William Herrin
On Wed, Nov 4, 2020 at 8:49 AM Suresh Kalkunte  wrote:
> I believe the below described method of causing intentional (1) damage to 
> equipment in data centers and (2) physical injury to a person at the 
> workplace is on-topic for the NANOG community, if not, I look forward to your 
> feedback. As a software developer who has subscribed to the NANOG mailing 
> list for a number of years, I post this note relying on intellectual honesty 
> that I have had the opportunity to observe since 1996-97.

Hello,

Did you test against common equipment deployments or did you just
measure the field strength?

In common equipment deployments, the electronics are wrapped in two
layers of Faraday cage: the steel case of the equipment itself and the
steel cabinet into which the equipment is installed, both well
grounded. Penetration from even strong EM fields is limited.

Also, if you go to the expense of boring under someone's data center I
have to think dynamite will be more effective at disabling it.

Regards,
Bill Herrin


-- 
Hire me! https://bill.herrin.us/resume/


Re: att or sonic "residential" fiber service at a "nontraditional" residence.

2020-11-01 Thread William Herrin
On Sun, Nov 1, 2020 at 5:22 PM Mark Seiden  wrote:
> if i don’t want an SLA, does anything keep a non-profit organization from 
> ordering (from att or sonic) residential service at what normally would be 
> considered a business location?

Hi Mark,

Generally speaking, the residential and business services are
constructed differently. The residential service will be PON while the
business service will be a classic fiber pair. Passive optical
networking (PON) is a single-fiber that splits a number of times
between you and the company's equipment. The classic fiber pair is two
strands of fiber direct between you and the company's equipment.

Since they won't have built the PON-based service to the business
location, they won't sell it to you there. And nothing you can do will
force them to re-purpose the fiber they did build to the business
location.

Regards,
Bill Herrin


-- 
Hire me! https://bill.herrin.us/resume/


Re: Asus wifi AP re-writing DNS packets

2020-10-28 Thread William Herrin
On Wed, Oct 28, 2020 at 1:57 PM Anurag Bhatia  wrote:
> No such feature when running in AP mode. AP mode gives options of wireless 
> settings (SSID etc) and IP for management of the device.

I don't know about this case but I've occasionally noticed devices
where you have to put the device into the mode where the feature
config shows up in the UI in order to disable it. The feature itself
acts independent of whether it shows up in the UI.

Does the asus AP have an "nvram" command? That's likely where the
config is stored.

Regards,
Bill Herrin



-- 
Hire me! https://bill.herrin.us/resume/


Re: FCC FUSF charges clarification

2020-10-14 Thread William Herrin
On Wed, Oct 14, 2020 at 2:16 PM Nuno Vieira via NANOG  wrote:
> Need some help/insight from you guys on this:
>
> Company A is an incorporated in Europe, where it main business is,
> however it has some pops within USA.

If you're complying with all the laws then you've also filed the
various documents to do business in the localities where you have the
pops, putting you on the hook for the relevant taxes. Don't worry
about this too much; hand it to your lawyer.


> for IP Transit (other charges representing roughly 6%)

This is a common bad behavior, like a "fuel surcharge" on an airline
ticket. I try to avoid the companies that pull these shenanigans but
it's not always possible.


> for the wavelenght (a lot of charges, such as the ones described below)
>
> - FCC Regulatory Fee (wireline)
> - Fed Universal Service Fund
> - CA High Cost Fund A
> - CA Teleconnect Fund
> - CA TRS
> - CASF
> - Universal Lifeline Telephone Service Charge
> - Utility Users Tax

THIS is an error. Most of these charges are only supposed to apply to
voice telephony services. I've seen the ILECs (classic telephone
companies) apply these charges by default, argue with you and then
give you a form to sign where you state unequivocally that you're not
doing a telephone service. You should challenge it.


> So... my question IS:   Is an European company (or whatsoever foreign
> wholesale company) WITHOUT ANY customers in USA liable to pay those
> taxes to the carrier ?

Anywhere you have a physical presence you owe taxes. The correct
question is: which ones?

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Gaming Consoles and IPv4

2020-09-27 Thread William Herrin
On Sun, Sep 27, 2020 at 10:52 AM Matt Hoppes
 wrote:
> I’m curious if anyone here knows why gaming consoles are so stupid when it 
> comes to IPv4?

They're trying to give your salesmen an opportunity to upsell. "Oh you
have an Z-Console? Those need a gaming enhanced IP address which we'll
happily sell you for an extra $5/month. You have three Z-Consoles? At
the same time? We gotcha covered!"

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: cloud automation BGP

2020-09-27 Thread William Herrin
On Sun, Sep 27, 2020 at 8:53 AM Dmitry Sherman  wrote:
> Can you recommend software or cloud based solution which monitors if a prefix 
> is advertised to a peer (via his Looking Glass for example) & if traffic is 
> passing thru an interface and if one of them is false it announce this prefix 
> via other upstream providers & remove blackholes?

Hello,

You seem to be looking for external automation to do something that's
baked into BGP. Any particular reason?

* Announce to all upstreams all the time.
* Use prepends on the less-preffered upstreams.
* If the less preferred upstream is localprefing to use your routes
despite the prepend, ask them what BGP community you should set to
disable that behavior.
* If an upstream propagates your route without passing your packets
often enough to need automation, cancel the contract.


I could see value in something local that measures things like packet
loss rates and cuts the primary if they get higher than acceptable,
but that wouldn't be a cloud service because the cloud wouldn't be
reliably reachable when you need to act on that information.

Regards,
Bill Herrin




--
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: curious spam...

2020-09-15 Thread William Herrin
On Tue, Sep 15, 2020 at 12:39 AM David Hubbard
 wrote:
> Here in Florida the self-preservation interests of the two party system have 
> resulted in all voter registrations being made public, including email, 
> d/o/b, phone, home address (since you can't legally register any other), 
> party affiliation.  If you used your private email for

Nothing. I used the gmail address for nothing. Ever. Not even when I
first got it many years ago. I provide an @herrin.us or @dirtside.com
address which my server later forwards to gmail for my perusal. I
usually use a custom address so I can figure out who broke my trust. I
have a couple of generic addresses (like b...@herrin.us) for mailing
lists and situations where I don't have a custom address ready. But I
simply don't give out the gmail address. I treat it as a back-end
mailbox for my own smtp server. 100% of email that reaches my gmail
box without going to another address at my mail server first is spam.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


curious spam...

2020-09-14 Thread William Herrin
Howdy,

I've noticed something odd. When I lived in Virginia, I started
receiving email directly to my gmail box from my U.S. Representative.
Unsolicited spam from Congressmen is nothing new but it was a little
odd that they found my gmail box (which I don't give out) and not one
of the hundreds of aliases at herrin.us or dirtside.com which I do
give out. The gmail box exists only in mail headers; "From" is always
a different address.

I moved to Seattle. Today I found my grmail box subscribed to a
congressman's list from a nearby Washington jurisdiction. Not some
random congressman. And not any of the addresses I give out; my gmail
box's address which I don't.

Anyone else have a similar experience? Any idea how a hidden address
is making it on to relevant congressmens' lists but not any others?
That's weird right?

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Wildfires: Reminder smart devices don't include emergency warnings while streaming

2020-09-11 Thread William Herrin
On Fri, Sep 11, 2020 at 11:58 AM Sean Donelan  wrote:
> you won't get emergency alerts on those streaming devices.
> Amazon Fire TV, Apple TV and Alphabet Android TV executives don't see a
> need to support emergency alerts on their products.

Also worth noting that you won't get emergency alerts on your stove,
refrigerator, dish washer, washing machine or dryer. So, when cooking
or doing laundry make sure you have an alternate source of emergency
alerts available.

Shockingly, your alarm clock won't automatically turn on when there's
an emergency alert over the radio either nor will your smoke and fire
alarms go off except in the immediate presence of smoke and fire, so
be sure to have an always-on source of alerts while you're sleeping
too.

tl;dr: keep your cell phone on and with you 'cause only a few things
get emergency alerts and only when they're turned on.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: TCP and UDP Port 0 - Should an ISP or ITP Block it?

2020-08-25 Thread William Herrin
On Tue, Aug 25, 2020 at 4:15 AM Douglas Fischer
 wrote:
> a) Should an ISP block that Kind of traffic?

Hi Douglas,

Generally speaking the answer is NO, You should not presume that your
understanding of your customers' data traffic is sufficiently complete
or correct to make blocking decisions for them.

There are some major exceptions to this rule:

1. If your customer has directed you to apply your expertise and make
blocking decisions for you.

2. For commodity dynamic-IP (residential) accounts only, there is a
small set of "attractive nuisance" ports which it's reasonable to
exclude from your service offering. Generally email server to server
(port 25) and the historically poorly secured MS Windows LAN ports
(135-139, 445, and 1900). It's fair to tell these customers that (A)
they don't want to use those ports and (B) if they do want to use
those ports, buy the SOHO offering.

3. For low-dollar virtual server products it's not unreasonable to
block the same ports by default and for the same reasons, as long as
you're prepared to promptly remove the blocks upon request.


> b) Should a Transit Provider block that Kind of traffic?

Preemptively? Never. If I found my business transit provider was doing
this, I'd treat it as a breach of contract.


As for port 0 specifically, it doesn't really fit the attractive
nuisance mold. It's about as harmless (or harmful) as any random TCP
port. It doesn't particularly have a history of doing harm.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Fiber Automatic Transfer Switch

2020-08-17 Thread William Herrin
On Mon, Aug 17, 2020 at 11:15 AM Tim Nowaczyk
 wrote:
> I am new to the world of layer-1optical failover solutions. Can anyone
> recommend a similar 1U product that can transfer an optical signal to
> a secondary path when there’s been a break?


Hi Tim,

I want to dissuade you from using this architecture. When you have two
paths, it's important to keep them both lit so that you can detect
faults and correct them in a timely manner. The most intractable
problem with active/failover architectures is that the failover proves
inoperable when it's needed. The old backup tape that doesn't restore.
Keep your layer-1's active all the time and do fault handling at a
higher layer.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Bottlenecks and link upgrades

2020-08-13 Thread William Herrin
On Wed, Aug 12, 2020 at 12:33 AM Hank Nussbacher  wrote:
> At what point do commercial ISPs upgrade links in their backbone as well as 
> peering and transit links that are congested?  At 80% capacity?  90%?  95%?

Hi Hank,

As others have noted, the answer is rarely that simple.

First, what is your consumption? 90th or 95th percentile usually,
after all 100% between 9 and 5 is 100% not 33% but 100% for two
minutes is not 100%. It gets more complicated if any kind of QoS is in
play because capacity-wise QoS essentially gives you not a single
fixed-speed line but many interdependent variable-speed lines.

Next, capacity is not the only question. Here are some of the other factors:

1) A residential customer on the cheapest plan does not merit as clean
a channel as a high-paying business customer you'd like to keep
milking.

2) Upgrades can take months of planning so the capacity now is beside
the point. You'll use your best-guess projection for the capacity at
the time an upgrade can be complete.

3) Some upgrades tend to be significantly more expensive than others.
Lit service to dark fiber, for example. It's pretty ordinary to run
closer to the limit before making an expensive upgrade than a modest
upgrade.

4) A dirty link merits replacement sooner than a clean one. If the
higher-capacity service also clears up packet loss, you'll want to
trigger the decision at a lower consumption threshold.

5) Switching a single path to two paths is more valuable than
switching two paths to three. It has priority at a lower level of
consumption.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


cloudflare 1.1.1.2 filtered DNS

2020-08-11 Thread William Herrin
Howdy,

Is there an RBL lookup that provides information on why Cloudflare has
elected to block a name lookup via the "1.1.1.1 for Families" service
or is it a black box where you can only complain via
https://report.teams.cloudflare.com/ and maybe they'll do something
about it?

Thanks,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: questions asked during network engineer interview

2020-07-24 Thread William Herrin
On Fri, Jul 24, 2020 at 12:44 AM Mark Tinka  wrote:
> On 24/Jul/20 09:32, William Herrin wrote:
> > Choosing not to mash one's fingers with a hammer is not an absence of
> > curiosity about carpentry. It's merely an understanding that doing
> > carpentry well involves -not- mashing one's fingers with a hammer.
>
> You mean like not poking your finger into the wall socket, or in the
> fire, unless you're 2?
>
> I'm not sure how to parse your comment. But in case you are wondering, I
> am talking about network engineering, which is not common sense.

Hi Mark,

How you parse it depends on your intention when quoting my interview
story with a response about exhibiting curiosity. It was either full
agreement about the value of curiousity or a pointed retort about the
difference between curiosity and irresponsibility.

Regards,
Bill

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: questions asked during network engineer interview

2020-07-24 Thread William Herrin
On Fri, Jul 24, 2020 at 12:08 AM Mark Tinka  wrote:
> I prefer to have staff that are burdened with being curious, rather than
> staff who think they don't. After all, all the information is already
> out there. Having experience is just as important as being diligent to
> obtain it.

Choosing not to mash one's fingers with a hammer is not an absence of
curiosity about carpentry. It's merely an understanding that doing
carpentry well involves -not- mashing one's fingers with a hammer.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: questions asked during network engineer interview

2020-07-23 Thread William Herrin
On Thu, Jul 23, 2020 at 6:33 AM Michael Douglas
 wrote:
> One time I got asked in an interview how to estimate the number of manholes 
> in a city.  I replied that I would google 'pretentious interview questions' 
> for a problem solving methodology.

Many moons ago, I interviewed at Google. During one of the afternoon
sessions the interviewer and I spent about half an hour spitballing
approaches for system monitoring problem at scale. I no longer
remember the details. With a little over 15 minutes remaining he
handed me a marker and said, "Okay, now write code for that on the
whiteboard." For an abstract problem without foundation that I had
never considered prior to that discussion. I said, "I really don't
think I can do a credible job of that in the time we have." He says,
"Well it's okay to use pseudocode. Don't you want to try?" I think
you're missing the point dude. It's still an abstract problem and
after half an hour's discussion I might be ready to draw boxes and
arrows. I'm certainly not ready to reduce it to code.

I said, "No," and needless to say I didn't get an offer. And I'm okay
with that. I really didn't fancy making a career of competing to be
the first to write poorly considered software.

The booby prize for failing the interview was a Google coffee mug. I
still have it in storage somewhere.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: questions asked during network engineer interview

2020-07-22 Thread William Herrin
On Wed, Jul 22, 2020 at 12:41 AM Mark Tinka  wrote:
> I'll try this again...
>
> There will be tooling required to operate your network. Cloud,
> connectivity, content, e.t.c.
>
> The tooling will help the operator accomplish the task required as
> efficiently as possible, as long as they keep investing in and improving it.
>
> I don't want to box that tooling into "SDN tech". It is tooling. It may
> or may not smell like "SDN". All I care about is that it helps me
> achieve my objectives. If it is internal to my operation and not
> standardized with a ton of other operators, that's fine too.

Hi Mark,

Who said anything about boxing your tooling in to SDN tech? You
described Software Defined Networking as a rabbit hole and snake oil.
It isn't. It's a class of tools in the networking toolbox and an
increasingly useful one.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: questions asked during network engineer interview

2020-07-22 Thread William Herrin
On Tue, Jul 21, 2020 at 9:50 AM  wrote:
> One can't be an expert in many areas, (like CCIE-everything... folks)
> Same as Usain Bolt can't swim like Michael Phelps...

Polymaths are a thing but they have better use for the space on their
resumes than telling you about the certificates they hold.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: questions asked during network engineer interview

2020-07-21 Thread William Herrin
On Tue, Jul 21, 2020 at 2:55 PM Mark Tinka  wrote:
> For the avoidance of doubt, "we still don't know what SDN means to us"
> means "we are not sold on the snake oil".

Hi Mark,

I suppose it depends what you're trying to accomplish. If you're a
hosting provider and you want to provide a capability both similar to
AWS VPCs and strong enough to not be a joke, you won't get there on
the tools Linux or VMWare provide. You'll have to invest in SDN tech.
If you're hooking up residential subscribers to the Internet... it's
less obvious how SDN would be of use to you.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: questions asked during network engineer interview

2020-07-21 Thread William Herrin
On Mon, Jul 20, 2020 at 9:57 PM Mark Tinka  wrote:
> Suffice it to say, to this day, we still don't know what SDN means to
> us, hehe.

Hi Mark,

The Software Defined Network concept started as, "Let's use commodity
hardware running commodity operating systems to form the control plane
for our network devices." The concept has expanded somewhat to: "Lets
use commodity hardware running commodity operating systems AS our
network devices." For example, if you build a high-rate firewall with
DPDK on Linux, that's now considered SDN since its commodity hardware,
commodity OS and custom packet handling (DPDK) that skips the OS.

This is happening a lot in the big shops like Amazon that can afford
to employ software developers to write purpose-built network code.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: questions asked during network engineer interview

2020-07-20 Thread William Herrin
On Mon, Jul 20, 2020 at 5:09 AM Mark Tinka  wrote:
> We'll probably spend 95% of the time just talking about who they are,
> and 5% on the role. That has worked well for me in the past decade, and
> none of those hires had any "certificates" to impress me with, even
> though those that didn't make it, did.

I find there's a strong INVERSE correlation between the quantity of
certificates on an applicant's resume and their ability to do the job.
I still have to laugh about the guy who let me know via his resume
that he was certified in setting up Kentrox CSU/DSUs.

-Bill

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: questions asked during network engineer interview

2020-07-14 Thread William Herrin
On Tue, Jul 14, 2020 at 1:26 PM  wrote:
> > William Herrin
> > Sent: Tuesday, July 14, 2020 8:32 PM
> >
> > On Tue, Jul 14, 2020 at 12:17 PM Michael Thomas  wrote:
> > > On 7/14/20 12:09 PM, William Herrin wrote:
> > > > On Mon, Jul 13, 2020 at 3:12 PM Mehmet Akcin 
> > wrote:
> > > >> I am hosting a live show a few times a month about internet
> > > >> infrastructure and today's topics were, your favorite questions
> > > >> asked network engineers - you can watch the recording here
> > > >>
> > > >> https://www.youtube.com/watch?v=o3pvikTrF0M
> > > >>
> > > >> if you have suggestions on topics to cover helping network operations
> > engineering that you want to see in here, please feel free to contact me 
> > off-
> > list, and let's create unique content that can be helpful to others.
> > > >
> > > > "What happens when you type www.google.com in your browser bar
> > and
> > > > hit enter?" is one of my favorite questions. Half the field of
> > > > computing happens next. Keyboard interrupts fire. Bits are poked in
> > > > dram, sram, maybe even tcam. Packets are sent. Fonts are composed
> > into pixels.
> > > > There's a crazy amount you can talk about and the right answer is:
> > > > string things together in order for 5 or 10 minutes without getting
> > > > anything horribly wrong.

> The question is vague enough for the candidate to start talking just about 
> anything they like.
> What happens where? In the world? In the universe? In my body?
> Depending on the position you're hiring for you may want to include the 
> "where" as well to narrow down the scope of the talk (to say "finger tips" if 
> you hire a brain surgeon or 2020 laureate of Kavli Prize for Neuroscience for 
> discover of pressure receptors, or simply to "network" if hiring network 
> engineer, etc...).


You know what job you're interviewing for. What you choose to talk
about tells me volumes about how you think.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: questions asked during network engineer interview

2020-07-14 Thread William Herrin
On Mon, Jul 13, 2020 at 3:12 PM Mehmet Akcin  wrote:
> if you have suggestions on topics to cover helping network operations 
> engineering that you want to see in here, please feel free to contact me 
> off-list, and let's create unique content that can be helpful to others.

I'm also a fan of Amazon's STAR approach: Situation, Task, Activity,
Result. They didn't invent it but they're really good at it. STAR is
where you ask the candidate to tell you about some situation they
encountered in their work, what they did, and how it turned out
(including what they learned and would do differently). It's open
ended and bias-neutral. Which is a big deal.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: questions asked during network engineer interview

2020-07-14 Thread William Herrin
On Tue, Jul 14, 2020 at 10:59 AM Ahmed elBorno  wrote:
>
> 15 years ago, I applied to a network admin role at Google, it was for their 
> corporate office, not even the production network.
>
> I had less than two years experience.
>
> The interviewer asked me:
>
> 1) What is the difference between flow balancing techniques on Cisco IOS and 
> Linux?
> 2) If we had a 1GB file that we need to transfer between America and Europe, 
> how much time do we need, knowing that we start with a TCP size of X?

Hi Ahmed,

Those are terrible questions. I've been in the business for a quarter
century, a Linux and Cisco IOS user for most of that and I don't, off
hand, know the answer to #1. As for number #2, it's highly variable
depending on when you lose the first packet, ending fast window
growth. And you will. On a gigabyte transfer over any real-world
network, you will lose some packets both to congestion and bit errors.
And that's before you consider the long-fat-pipe problem. Trying to
treat it like a math train problem is bizarre.

My Google interviewers asked much better questions, along the lines of
"build me this" or "debug this problem." Even then they fell in to one
of the traps with that methodology: on the "debug this problem"
question, the interviewer wasn't familiar with one of the diagnostic
commands I went to, so he guessed at what the output would be. His
guess was just enough wrong to eliminate the cause he wanted me to
find. The command should have hung accessing a faulty NFS mount but in
his version of the story it didn't.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: questions asked during network engineer interview

2020-07-14 Thread William Herrin
On Tue, Jul 14, 2020 at 12:17 PM Michael Thomas  wrote:
> On 7/14/20 12:09 PM, William Herrin wrote:
> > On Mon, Jul 13, 2020 at 3:12 PM Mehmet Akcin  wrote:
> >> I am hosting a live show a few times a month about internet infrastructure 
> >> and today's topics were, your favorite questions asked network engineers - 
> >> you can watch the recording here
> >>
> >> https://www.youtube.com/watch?v=o3pvikTrF0M
> >>
> >> if you have suggestions on topics to cover helping network operations 
> >> engineering that you want to see in here, please feel free to contact me 
> >> off-list, and let's create unique content that can be helpful to others.
> >
> > "What happens when you type www.google.com in your browser bar and hit
> > enter?" is one of my favorite questions. Half the field of computing
> > happens next. Keyboard interrupts fire. Bits are poked in dram, sram,
> > maybe even tcam. Packets are sent. Fonts are composed into pixels.
> > There's a crazy amount you can talk about and the right answer is:
> > string things together in order for 5 or 10 minutes without getting
> > anything horribly wrong.
>
> Oh, I thought this was a trick question of whether it takes you directly
> to google, or does a search.

That's a good start. First thing the browser does decide whether
that's a URL or a search question. How does it decide? And then what
happens?

I will prompt you to keep talking. After all, I'm rooting for you to
succeed so that I can hire you.

-Bill



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: questions asked during network engineer interview

2020-07-14 Thread William Herrin
On Mon, Jul 13, 2020 at 3:12 PM Mehmet Akcin  wrote:
> I am hosting a live show a few times a month about internet infrastructure 
> and today's topics were, your favorite questions asked network engineers - 
> you can watch the recording here
>
> https://www.youtube.com/watch?v=o3pvikTrF0M
>
> if you have suggestions on topics to cover helping network operations 
> engineering that you want to see in here, please feel free to contact me 
> off-list, and let's create unique content that can be helpful to others.


"What happens when you type www.google.com in your browser bar and hit
enter?" is one of my favorite questions. Half the field of computing
happens next. Keyboard interrupts fire. Bits are poked in dram, sram,
maybe even tcam. Packets are sent. Fonts are composed into pixels.
There's a crazy amount you can talk about and the right answer is:
string things together in order for 5 or 10 minutes without getting
anything horribly wrong.

And the best parts:

With the choices they make, they'll tell you exactly how deep their
knowledge goes. So it works for all tech hires, junior to senior,
sysadmin, developer, network engineer, whatever.

It's an oral question, you don't have to write or draw anything to
answer, so you can use it in a phone screen.

Regards,
Bill Herrin


--
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: netflix proxy/unblocker false detection

2020-06-26 Thread William Herrin
On Fri, Jun 26, 2020 at 12:34 PM Grant Taylor via NANOG  wrote:
> I want to agree, but I can't.  Move up the stack.  I pay my bill with a
> CC which has my billing address.  I would even be willing to tell
> Netflix my home address directly.
>
> If they are willing to trust the CC information to take my money, then
> they should also be willing to trust the information for my service address.
>
> If I want to use my Hurricane Electric IPv6 tunnel, to watch content
> that matches my stated address which matches my CC billing address,
> which matches my IPv4 address (region), then why the REDACTED can't I do
> so over my HE IPv6 tunnel?

Hi Grant,

Philosophically, Netflix agrees with you. Unfortunately they have to
keep the studios happy or many of their content contracts evaporate.
And too many content owners care very much where you are right this
instant. Because they are unreasonable luddites who think that
geographic monopolies make good business sense.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Is there any data on packet duplication?

2020-06-23 Thread William Herrin
On Mon, Jun 22, 2020 at 10:21 PM Saku Ytti  wrote:
> On Tue, 23 Jun 2020 at 08:12, William Herrin  wrote:
> > That's what spanning tree and its compatriots are for. Otherwise,
> > ordinary broadcast traffic (like those arp packets) would travel in a
> > loop, flooding the network and it would just about instantly collapse
> > when you first turned it on.
>
> Metro: S1-S2-S3-S1
> PE1: S1
> PE2: S2
> Customer: S3
> STP blocking: ANY
>
> S3 sends frame, it is unknown unicast flooded, S1+S2 both get it
> (regardless of which metro port blocks), which will send it via PE to
> Internet.

There's a link in the chain you haven't explained. The packet which
entered at S3 has a unicast destination MAC address. That's what was
in the arp table. If they're following the standards, only one of PE1
and PE2 will accept packets with that destination mac address. The
other, recognizing that the packet is not addressed to it, drops it.

Recall that ethernet worked without duplicating packets back in the
days of hubs when all stations received all packets. This is how.


That having been said, I've seen vendors creatively breach the
boundary between L2 and L3 with some really peculiar results. AWS VPCs
for example. But then this ring configuration doesn't exist in an AWS
VPC and I've not particularly observed a lot of packet duplication out
of Amazon.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Is there any data on packet duplication?

2020-06-22 Thread William Herrin
On Mon, Jun 22, 2020 at 9:43 PM Saku Ytti  wrote:
> I can't tell you how common it is, because that type of visibility is
> not easy to acquire, But I can explain at least one scenario when it
> occasionally happens.
>
> 1) Imagine a ring of L2 metro ethernet
> 2) Ring is connected to two PE routers, for redundancy
> 3) Customers are connected to ring ports and backhauled over VLAN to PE
>
> If there is very little traffic from Network=>Customer, the L2 metro
> forgets the MAC of customer subinterfaces (or VRRP) on the PE routers.
> Then when the client sends a packet to the Internet, the L2 floods it
> to all eligible ports, and it'll arrive to both PE routers, which will
> continue to forward it to the Internet.

Hi Saku,

That's what spanning tree and its compatriots are for. Otherwise,
ordinary broadcast traffic (like those arp packets) would travel in a
loop, flooding the network and it would just about instantly collapse
when you first turned it on.

A slightly more likely scenario is a wifi link. 802.11 employs layer-2
retries across the wireless segment. When the packet is successfully
transmitted but the ack is garbled, the packet may be sent a second
time.

Even then I wouldn't expect duplicated packets to be more than a very
small fraction of a percent. Hal, if you're seeing a non-trivial
amount of identical packets, my best guess is that the client is
sending identical packets for some reason. NTP you say? How does
iburst work during initial sync up?

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


60 ms cross-continent

2020-06-20 Thread William Herrin
Howdy,

Why is latency between the east and west coasts so bad? Speed of light
accounts for about 15ms each direction for a 30ms round trip. Where
does the other 30ms come from and why haven't we gotten rid of it?

c = 186,282 miles/second
2742 miles from Seattle to Washington DC mainly driving I-90

2742/186282 ~= 0.015 seconds

Thanks,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Google captcha issue

2020-06-19 Thread William Herrin
On Fri, Jun 19, 2020 at 9:15 AM Christopher Tyler
 wrote:
> We run a smaller ISP of about 7.5k customers and the other day we got an 
> email (excerpt below) from one of Google's automated tools.
>
> We are seeing automated scraping of Google Web Search from a large
> number of your IPs.  Automated scraping violates our /robots.txt file
> and also our Terms of Service.  We request that you terminate this
> traffic immediately.  Failure to do so may cause your network to be
> blocked by our abuse systems.
>
> To allow you to identify the traffic, we are providing a list of
> your IPs they used today (Source field), as well as the most common
> destination (Google) IP and port and a timestamp of a recent request
> (in UTC) to aid in your identification.  Note that this list may not
> be exhaustive, and we request that you terminate all such traffic, not
> just traffic from IPs in this list.
>
> All of the destination ports are either 80 or 443, so they at least appear to 
> be legit web traffic on the surface. They are obviously spoofed IP address as 
> there are network addresses in the list and the IP belongs to a router that 
> doesn't appear to be compromised in any way. The initial letter included 700+ 
> IP addresses from our network.

Hi Christopher,

Presumably Google is smart enough to know the difference between
spoofed port scanning and completed TCP connections performing a web
search. If you take Google's report at face value, the addresses
aren't spoofed; something else is happening. The question is how.

There was a company revealed on Nanog earlier this year (or maybne
last year, I'm not great with dates) which contracts small ISPs and
virtual server providers to use their "spare bandwidth" to
pseudonymously originate web requests. They don't require you to
assign them IP addresses because they overload their activity on all
of your IP addresses. In theory they do this without disturbing your
customers and only access web sites whose owners have contracted them
to do so, generally to test connectivity. In practice, there's a
device inline with your traffic flow that injects TCP connections and
captures the associated return packets across your entire address
space. Including, for example, your routers' IP addresses.

Do you, or perhaps your upstream have such a contract?

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Network card with relay in case of power failure

2020-06-18 Thread William Herrin
On Wed, Jun 17, 2020 at 1:15 PM Dovid Bender  wrote:
> I am sorry if this is off topic.I was once demoed a network device
> that had two interfaces. The traffic would go through the device.
> If there was a power cut or some other malfunction there would be
> a relay that would physically bridge the two network interfaces so the
> traffic would flow as if it was just a network cable. Is anyone aware of
> such a network card or device?

You can also do this with any routing protocol by including a bypass
link and declaring the bypass higher cost than the one through your
potentially malfunctioning device. This has the benefit of not having
to care about whether the nature of the failure will affirmatively
trigger the bypass since it'd negatively triggered on the absence of
packets.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Partial vs Full tables

2020-06-11 Thread William Herrin
On Thu, Jun 11, 2020 at 9:35 AM Brian Johnson  wrote:
> You are a dismissive little twit aren’t you. :/

Someone stood up and said, "Nope, nothing I did could possibly have
broken anything." I'm pretty sure that someone was you but feel free
to call me on it if I'm mistaken.

Look, at the risk of doing further offense, it's like I said: it's one
thing to educate yourself about a topic and then make a judgement call
about what's acceptable. It's quite another to remain willfully
ignorant in service of your preferred view. I just got through
describing specific scenarios where loose urpf fails when you
responded that no, it doesn't break anything. If you'd said, "no, that
breakage is a small price worth paying," I'd have debated the merits
with you or simply let it stand as a contrary opinion. Refusing to
acknowledge the breakage is worth only dismissal.

Regards,
Bill

--
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Partial vs Full tables

2020-06-11 Thread William Herrin
On Thu, Jun 11, 2020 at 9:08 AM brad dreisbach  wrote:
> uRPF absolutely kills the pps performance or your hardware due to the packet
> having to be recirculated to do the check(at least this is the case on every
> platform that ive ever tested it on). use acl's to protect your edge.

Hi Brad,

Don't the ACLs generally live in a partition of the TCAM too? So
you're going from two constant-time TCAM lookups per packet (route,
acls) to three (route, urpf, acls)? Not rhetorical; getting close to
the edge of my knowledge here.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Partial vs Full tables

2020-06-11 Thread William Herrin
On Thu, Jun 11, 2020 at 6:25 AM Brian Johnson  wrote:
> I fully understand that I have not “broken” anything.

Handwaving, la la la, only sunshine in the sky. Got it.

-Bill



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Partial vs Full tables

2020-06-10 Thread William Herrin
On Wed, Jun 10, 2020 at 3:02 PM Baldur Norddahl
 wrote:
> Am I correct in assuming loose mode RPF only drops packets from unannounced 
> address space in the global routing table?

Actually, I'm not sure since my plan around RPF is "10 foot pole." Is
"loose mode" really just filtering packets the current routing table
deems to be bogons? If it's not tied in any way to the actual routing
paths then it seems poorly named.

> And the downside of doing so is that sometimes we do receive packets from 
> that address space, usually back scatter from traceroute or other ICMP 
> messages.

Those "other" ICMP messages are kinda important since TCP fails if
they're discarded. If it's just a bogon filter then by definition only
simplex communications can be impacted since there's known to be no
way for duplex communication to occur. PMTUD and traceroute responses
are examples: a router telling a host information but expecting no
response. SNMP traps are simplex though it's not obvious to me how
that would matter here. What else can you think of that's simplex?

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Partial vs Full tables

2020-06-10 Thread William Herrin
On Wed, Jun 10, 2020 at 11:20 AM Brian Johnson  wrote:
> Disagree with Bill here. It will depend on the complexity of the network as 
> to use of uRPF in any mode (loose or strict). In general, I never use uRPF on 
> transit links and use pure filters to ensure accurate filters are in place. 
> uRPF may be used internally in either mode to great advantage and I’ve done 
> it both ways.


Hi Brian,

Do you know and understand what you broke? It's one thing to make a
judgement call. Quite another to wave your hands and say, "Oh well,
nobody complained so it must be OK."


> If you are looking for corner cases, avoid networking. I do not know of a 
> protocol or a technique that I cannot find a corner case for.

Not sure what you're saying here. Corner cases aren't a bad thing.
They're just the point where a technology or technique is most likely
to break. If you want reliability, you're supposed to identify the
corner cases and then you're supposed to game out what happens in
those corner cases. A result will be acceptable or unacceptable and if
it's unacceptable you don't do that. If you haven't identified and
gamed the corner cases then (A) you can't prove your stuff is reliable
and (B) it probably isn't.

With RPF, the corner cases you're looking for are: what situations
would cause a packet to come from the wrong interface? For example, if
you had some sort of routing loop where router A thought it could get
to a destination via router B but router B thinks that destination
unreachable so it returns the packet to its default route at router A.
RPF then drops the packet because router B isn't an acceptable source.
That's a corner case for RPF but it's an acceptable case because the
packet would be dropped regardless.

Another corner case with strict RPF is that your best route to a
destination is transit C but a packet with that source arrives from
transit D. That's broken, it causes significant problems for the
network and as a result it constrains you to not use strict RPF in
network scenarios where that's possible.

Loose mode RPF tries to overcome the limitation by saying: as long as
there's a route announced from D we'll accept packets from D even if C
is the best route.


So loose mode changes the nature of the corner cases you're looking
for. Instead of looking for situations where the packet came from
somewhere other than the best route, you're looking for situations
where the packet came from an interface that advertises no return
route at all. What are these situations?

You may have gotten a packet from a reciprocal peer whose customer has
told them not to advertise their route to you. Your peer isn't
policy-routing deep in their core, so no matter what their customer
instructs their packets to you will follow your peer's preferred path.
If you use loose RPF there, you will black-hole that network's
packets.

You may have gotten an ICMP TTL expired from a router on a distant
peering lan whose operator doesn't announce the lan's route for
security purposes. After all, those routers don't need to be reached
from the Internet. If you lose that packet, traceroute fails to reveal
the hop.

You may have gotten an ICMP fragmentation needed message from a router
on the same distant peering lan. If you drop that packet, path MTU
discovery fails and everything beyond that router is unreachable with
TCP.

So you might want to consider whether any of these corner cases is
activated by the way you use loose mode RPF.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Partial vs Full tables

2020-06-10 Thread William Herrin
On Wed, Jun 10, 2020 at 9:43 AM William Herrin  wrote:
> The answer is "no," you're not running reverse-path filtering on a BGP
> speaker, not even in loose mode, because that's STUPID.

Sorry, it'd be pre-coffee if I drank coffee and I was overly harsh
here. Let me back up:

The most basic spoofing protection is: don't accept remote packets
pretending to be from my IP address.

Strict mode URPF extends this to networks: don't accept packets on
interfaces where I know for sure the source host isn't in that
direction. It works fine in network segments whose structure requires
routes to be perfectly symmetrical: on every interface, the packet for
every source can only have been from one particular next hop, the same
one that advertises acceptance of packets with that destination. The
use of BGP breaks the symmetry requirement so close to always that you
may as well think of it as always. Even with a single transit or a
partial table. Don't use strict mode URPF on BGP speakers.

Loose mode URPF is... broken. It was a valiant attempt to extend
reverse path filtering into networks with asymmetry but I've yet to
discover a use where there wasn't some faulty corner case. If you
think you want to use loose mode RPF, trust me: you've already passed
the point where any RPF was going to be helpful to you. Time to set it
aside and solve the problem a different way.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Partial vs Full tables

2020-06-10 Thread William Herrin
On Wed, Jun 10, 2020 at 9:25 AM Robert Blayzor  wrote:
> One caveat that may or may not play into this is if you use uRPF (loose)
> on your transit links.

Hi Robert,

The answer is "no," you're not running reverse-path filtering on a BGP
speaker, not even in loose mode, because that's STUPID.  At the very
best you're tying up router resources on a very large filtering table
without measurable benefit. More likely you're blackholing packets you
failed to think about, like ICMPs from routers on peering lans whose
route is intentionally not introduced to the Internet at large. I
suppose the customers don't really need pmtud or traceroute...

Regards,
Bill Herrin




--
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Partial vs Full tables

2020-06-08 Thread William Herrin
On Mon, Jun 8, 2020 at 10:52 AM  wrote:
> Every "fast" FIB implementation I'm aware of takes a set of prefixes, stores 
> them in some sort of data structure, which can perform a longest-prefix 
> lookup on the destination address and eventually get to an actual physical 
> interface for forwarding that packet.  Exactly how those prefixes are stored 
> and exactly how load-balancing is performed is *very* platform specific, and 
> has tons of variability.  I've worked on at least a dozen different hardware 
> based forwarding planes, and not a single pair of them used the same set of 
> data structures and design tradeoffs.

Howdy,

AFAIK, there are two basic approaches: TCAM and Trie.  You can get off
in to the weeds fast dealing with how you manage that TCAM or Trie and
the Trie-based implementations have all manner of caching strategies
to speed them up but the basics go back to TCAM and Trie.

TCAM (ternary content addressable memory) is a sort of tri-state SRAM
with a special read function. It's organized in rows and each bit in a
row is set to 0, 1 or Don't-Care. You organize the routes in that
memory in order from most to least specific with the netmask expressed
as don't-care bits. You feed the address you want to match in to the
TCAM. It's evaluated against every row in parallel during that clock
cycle. The TCAM spits out the first matching row.

A Trie is a tree data structure organized by bits in the address.
Ordinary memory and CPU. Log-nish traversal down to the most specific
route. What you expect from a tree.

Or have I missed one?

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Partial vs Full tables

2020-06-08 Thread William Herrin
On Mon, Jun 8, 2020 at 11:14 AM Nick Hilliard  wrote:
> William Herrin wrote on 08/06/2020 18:53:
> > 4 gigs and 2 cores is more than sufficient for a 1 gbps router at
> > the current 800k routes
> 1gbps is residential access speed.  Is this still useful in the dfz?

Not really the point. You can get 50-100gbps out of an x86 running
DPDK by throwing more cores at it without appreciably changing the
memory and CPU for the BGP load. My little 4 gig generic Linux VMs
that connect my leaf node to the Internet are the ones I have reliable
information on, so that's what I shared.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Partial vs Full tables

2020-06-08 Thread William Herrin
On Sun, Jun 7, 2020 at 11:07 PM Saku Ytti  wrote:
> I'll take my imagination boat from the dry docks and sail to 2035. Lot
> of people still run Jericho ANET, it is the new CAT6500 PFC3. DFZ
> won't fit it anymore without redundant-specifics.
> Are we at all concerned that someone in the DFZ advertises a minimum
> set of prefixes needed to force decompression and if we are, how do we
> protect from it, if we are not, why are we not?

Limit announcements to /24: 2^24 max routes.
Subtract: 0.0.0.0/8, 10.0.0.0/8, 127.0.0.0/8, 224.0.0.0/3 and some
other reserved networks that don't (or at least aren't supposed to)
show up in the DFZ.

Leaves around 14M routes in the table at full disaggregation to /24.

Current TCAM-based equipment supports 1M - 2M routes. The tech readily
scales 7x just by throwing hardware at it (no redesign). Trie-based
equipment already supports 14M routes with sufficient DRAM and CPU (4
gigs and 2 cores is more than sufficient for a 1 gbps router at the
current 800k routes).

And that's the worst case. The IPv4 table will surely saturate and
stabilize long before 14M routes.

No crisis to avert. Just keep up with your upgrade schedules.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: understanding IPv6

2020-06-07 Thread William Herrin
On Sun, Jun 7, 2020 at 3:01 AM Denys Fedoryshchenko
 wrote:
> There are very interesting and unobvious moments on IPv4 vs IPv6, for
> example related to battery lifetime in embedded electronics. In ipv4,
> many devices are forced to send "keepalives" so that the NAT entry does
> not disappear, with IPv6 it is not required and bidirectional
> communications possible at any time.

Hi Denys,

Not exactly. Keepalive requirements are a property of whether or not
you employ stateful firewalls. IPv4's address-overloaded NAT
inherently requires a stateful firewall while that's optional when
you're not using NAT. However, there are great reasons from a security
posture perspective to employ a stateful firewall regardless.

Having an external host be unable to send packets to an internal host
where the internal host didn't initiate the communication is a
relatively solid foundation on which to build a network security
process. It's not always the best answer but if you build your
software with the assumption it won't be there, you're making a
mistake.

Also bear in mind that address-overloaded NAT has a security benefit
over stateful firewalls: it "fails closed" in the sense that mistakes
configuring the firewall tend to leave it incorrectly unable to
deliver a packet rather than incorrectly able to deliver a packet.
Since network products do implement this form of IPv6 NAT (e.g. the
Linux masquerade target exists for ip6tables too) you can expect some
organizations to use it. This is especially true early in their
adoption of IPv6 when they don't understand it as well as IPv4. Many
will want to keep their security posture as closely aligned with IPv4
as possible.

Regards,
Bill Herrin



--
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Partial vs Full tables

2020-06-05 Thread William Herrin
On Fri, Jun 5, 2020 at 6:08 PM Yang Yu  wrote:
> On Fri, Jun 5, 2020 at 10:39 AM William Herrin  wrote:
> > Speak of which, did anyone ever implement FIB compression? I seem to
> > remember the calculations looked really favorable for the leaf node
> > use case (like James') where the router sits at the edge with a small
> > number of more or less equivalent upstream transits. The FIB is the
> > expensive memory. The RIB sits in the cheap part of the hardware.
>
> fib optimize => using LPM table for LEM
> https://www.arista.com/en/um-eos/eos-section-28-11-ipv4-commands#ww1173031

Cool. So for folks who want a nutshell version about FIB compression,
here it is:

Your router has routing information bases (RIB) and a forwarding
information base (FIB). The FIB is what picks where to move the
packet. For each packet you look up the destination address in the FIB
and then send the packet to the next hop that you found in the FIB.
This is the expensive part of the router hardware because it has to do
this for every packet at line speed.

When we talk about the BGP table, we're talking about the RIB. That's
what has AS paths, communities, distances, etc. It's stored in
ordinary DRAM and computed by an ordinary CPU. Before the router can
route packets, the data in the RIB is reduced to a forwarding table
that's stored in the FIB. Normally, this means you take every route in
the RIB, pick the "best" one, figure out the next hop and then store
the result in the FIB.

FIB compression replaces that process with one that's more selective
about which RIB routes get installed in the FIB. The simplest version
works like this:

1. Figure out which next hop has the most routes pointing to it.
2. Add a default route to that next hop
3. Remove all the now-unnecessary more specific routes that go to the
same next hop.

If you have two upstream transit services, you've probably just cut
your FIB table size by more than half. Which means you don't need as
much of the pricey part of the router.

The actual algorithm gets more complex, the computational cost goes up
and the reduction in fib routes improves.

The down side is something you don't usually think about: default is
implicitly routed to reject (respond with icmp unreachable). 0.0.0.0/0
-> reject. You don't see it in your configuration but it's there all
the same. FIB compression eliminates the implicit reject and instead
routes the unroutable packets to a more or less random next hop. If
that next hop is also using FIB compression, it may route them right
back to you, creating a routing loop until the packet's TTL expires.

Happy weekend everybody,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Partial vs Full tables

2020-06-05 Thread William Herrin
On Fri, Jun 5, 2020 at 10:30 AM Tore Anderson  wrote:
> In the end I felt that running in production with the RIB and the FIB
> perpetually out of sync was too much of a hack, something that I would
> likely come to regret at a later point in time. That approach never
> made it out of the lab.

Speak of which, did anyone ever implement FIB compression? I seem to
remember the calculations looked really favorable for the leaf node
use case (like James') where the router sits at the edge with a small
number of more or less equivalent upstream transits. The FIB is the
expensive memory. The RIB sits in the cheap part of the hardware.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Partial vs Full tables

2020-06-05 Thread William Herrin
On Fri, Jun 5, 2020 at 9:49 AM Saku Ytti  wrote:
> The comparison isn't between full or default, the comparison is
> between static default or dynamic default. Of course with any default
> scenario there are more failure modes you cannot route around. But if
> you need default, you should not want to use dynamic default.

It's a little more nuanced than that. You probably don't want to
accept a default from your transit but you may want to pin defaults
(or a set of broad routes as I did) to "representative" routes you do
accept from your transit. By "pin" I mean tell BGP that 0.0.0.0/0 is
reachable by some address inside a representative route you've picked
that is NOT the next hop. That way the default goes away if your
transit loses the representative route and the default pinned to one
of your other transits takes over.

You can craft and tune an effective solution here, but there has to be
an awful lot of money at stake before the manpower is cheaper than
just buying a better router.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Partial vs Full tables

2020-06-05 Thread William Herrin
On Thu, Jun 4, 2020 at 8:02 PM James Breeden  wrote:

> I come to NANOG to get feedback from others who may be doing this. We have
> 3 upstream transit providers and PNI and public peers in 2 locations. It'd
> obviously be easy to transition to doing partial routes for just the peers,
> etc, but I'm not sure where to draw the line on the transit providers. I've
> thought of straight preferencing one over another. I've thought of using
> BGP filtering and community magic to basically allow Transit AS + 1
> additional AS (Transit direct customer) as specific routes, with
> summarization to default for the rest. I'm sure there are other thoughts
> that I haven't had about this as well
>

Hi James,

When I was at the DNC in 2007, we considered APNIC-region /8s lower
priority than ARNI region (for obvious reasons) so I got some extra life
out of our router by pinning most APNIC /8s to a few stable announcements,
preferring one transit to the other with a fallback static route. This
worked in the short term but I wouldn't want to do it as a long term
solution.

As a more generic approach: filter distant (long AS path) routes because
there's a higher probability that they're reachable from any transit with
about the same efficiency.

Any time you summarize routes, you WILL lose connectivity during network
partitions. Which defeats part of the purpose of having BGP with multiple
transits. Partitions are rare but they can persist for days (*cough* cogent
*cough*). So that's a risk you should plan for.

Regards,
Bill Herrin


-- 
William Herrin
b...@herrin.us
<https://bill.herrin.us/>
https://bill.herrin.us/


Re: [Email reenviado] - [GTER] Proposal of enhancement on the RIRs/NRO delegation File format/info

2020-06-02 Thread William Herrin
>  - Any consideration about that?
>  - What is the path to reach the right persons to make a official proposal?
>
>
> P.S.3:
> Yes, I know that we have entered the era of RPKI.
> Yes, I know that probably in 5-6 years we will have another 90% of DFZ as
> VALID.
> But I believe that such an action would require minimal effort, ample
> result, and would also serve as an incentive for the diversifying Owner of
> IP blocks to move and create their ROAs.
>
>
>
> Examples of organizations with multiple sets of AutNumInetNum:
> B.1.a
>   "TELEFÔNICA BRASIL S.A" with 9 ASNs
>   10429, 11419, 16885, 16911, 18881, 19182, 22092, 26599, 27699.
> B.1.b
>   "Telecom Argentina S.A." with 11 ASNs
>   7303, 7934, 10318, 10481, 10895, 10983, 11356, 12264, 21590, 26608, 27871.
> B.2.a
>   "Núcleo de Inf. E Coord. Do Ponto BR - NIC.BR" with 16 ASNs
>   10906, 11284, 11431, 11644, 11752, 12136, 13874, 14026, 14650, 20121,
> 22548, 26162, 263044, 28345, 53035, 61580.
> B.2.b
>   "LACNIC - Latin American and Caribbean IP address" with 7 ASNs.
>   28000, 28001, 28002, 28119, 52224, 264845, 264846
>
>
>
> [2] https://www.nro.net/wp-content/uploads/nro-extended-stats-readme5.txt
> [3] ftp://ftp.lacnic.net/pub/stats/lacnic/delegated-lacnic-extended-latest
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
> --
> gter listhttps://eng.registro.br/mailman/listinfo/gter



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: AS hijacking (Philosophy, rants, GeoMind)

2020-05-30 Thread William Herrin
On Fri, May 29, 2020 at 8:40 AM Justin Wilson (Lists)  wrote:
> Here is where the philosophy comes into play.  The very terse e-mail we 
> received back was basically “As2 gets hijacked a lot and it’s not our 
> problem”. So my question for the NANOG folks.  At what point do you say “it’s 
> not your problem” when it involves your ASN?

The point where someone who isn't you is both hijacking your ASN *and*
someone else's prefix? Have you confirmed that the hijack actually
came from UDel, that the AS path matches one that's legitimate for
UDel? The guy hijacking your route doesn't have to list just one AS as
the origin; he can' list an entire chain.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Friday Reminder: Web Site Security

2020-05-15 Thread William Herrin
On Fri, May 15, 2020 at 4:25 PM Valdis Klētnieks
 wrote:
> On Fri, 15 May 2020 12:15:13 -0700, "Ronald F. Guilmette" said:
> > This is your helpful Friday reminder to always pay close attention to
> > the security settings of all of the web sites under your administration.
> > Otherwise, anonymous skript kiddiez could show up at any moment and
> > deface one or more of your web sites.  (It happens a lot.)
> > https://ipv4.plus/
>
> Just this week, I have seen an (unconfirmed) report that there is an organized
> effort that's abusing SSH keys that lack passphrases - if they pwn a system 
> and
> find one, they go surfing it as far as they can.

You may have missed the schadenfreude in Ronald's post.

Give it a rest Ronald. You won.

Regards,
Bill Herrin

-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


Re: Don't email clients have a kill file?

2020-05-14 Thread William Herrin
On Thu, May 14, 2020 at 11:37 AM Bjørn Mork  wrote:
> At the risk of starting an off topic discussion here, but am I the only
> one who'd like to see more plonks and less troll feeding?

Hi Bjørn,

With gmail, the message drop-down menu has both a "block sender" and a
"filter messages like this."

Personally, I think using it on a mailing list is a mistake. If you
don't want to read a thread, just don't open the thread. Let your eyes
wander past the line of subject and preview text on the off chance you
might want to look at it and then don't. It's not healthy to
completely isolate yourself from being aware of contrary opinion. That
lets nasty surprises sneak up on you.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/


  1   2   3   4   5   6   7   8   9   10   >