We got two of these yesterday for addresses that are not ours. One was
sort of adjacent... and seemed plausibly fat-fingered.
204.144.161.0 ≠ 204.144.151.0
We will definitely filter out anything further. Thanks for the heads-up.
On May 30, 2024, at 10:12 AM, Christopher Paul via NANOG
wrote:
>
> I propose that there be a national LDAP service, with OUs for each zipcode
> (ou=20500,dc=us,dc=gov). A household could register at USPS.gov and then be
> given
> write access to a household OU ("ou=1600 Pennsylvania Ave
> NW
That postal database is especially problematic for those who live in rural
areas with no postal delivery. We need a better database system than the one
that USPS maintains because it affects a wider range of services.
Two years ago I moved to a house with no postal service, so I got a PO box in
On Tue, 05 Mar 2024 12:17 -0700, Michael Rathbun wrote:
> What I found intriguing was that I was logged out by Google Docs at the same
> moment FB logged me out. Downdetector showed a number of other supposedly
> unrelated services with large outage report spikes at roughly the same time.
I w
I can confirm we started seeing this on Nov 9th at 19:10 UTC across all markets
from a variety of sources.
If you want to filter it with ingress ACLs they need to include subnet base and
broadcast addresses in addition to interface address, so a router at
192.168.1.1/30 with a customer potentia
> We are using Okta's RADIUS service for 2fa to network gear currently,
> but looking to switch to tacacs+ for many reasons. Would prefer to
> implement tacacs+ with two-factor if possible.
tac_plus-ng from https://www.pro-bono-publico.de/projects/tac_plus-ng.html has
LDAP and PAM backends, amo
> https://www.shrubbery.net/tac_plus/
That tac_plus has python 2 dependencies and so has been removed from Debian
packages. That's not surprising given the last update was 2015 and Python 2 was
EOL in 2020: https://www.python.org/doc/sunset-python-2/
Currently I favor this one which is still b
Ooof.
https://www.freebsd.org/security/advisories/FreeBSD-SA-22:15.ping.asc
Some hope here: "The ping process runs in a capability mode sandbox on all
affected versions of FreeBSD and is thus very constrainted in how it can
interact with the rest of the system at the point where the bug can occ
Precedent?
https://blog.codinghorror.com/revisiting-the-black-sunday-hack/
> Do you know if this was codified prior to 1.1.1.1 being taken over by
> Cloudflare?
Yes, I'm sure it was.
On a related note, I just discovered a NID that has 1.1.1.1 assigned to the
outband interface by default, and it is apparently not user modifiable. So, not
only can these devices never use 1.1.1.1 for name resolution, but attempts to
determine "is the circuit up" by pinging it will always return
> What else is like that and easy to remember and isn’t 1.1.1.1 ?
4.2.2.1, which IIRC predates both 8.8.8.8 and 1.1.1.1.
Muscle memory still favors it. I think 4.2.2.2 might be anycast the same but
never really looked hard at it.
Anyone swinging a clue-by-four it going to hit Meraki real hard.
https://community.meraki.com/t5/Switching/Switch-Constantly-Pings-8-8-8-8/m-p/31491
I can confirm this issue exists at several sites in the Denver area with this
same IPSEC issue, all routing between Level3/Lumen and Comcast.
I was told by one customer that it resolved late yesterday afternoon but I
haven't been able to confirm that.
Mike
-Original Message-
From: NAN
14 matches
Mail list logo
