NANOG Mailing List

The North American Network Operators' Group discusses fundamental Internet infrastructure issues such as routing, IP address allocation, and containing malicious activity.

List Archives

Latest Posts

Re: BGP Stuck Routes Operational Experience Survey Hank Nussbacher via NANOG (Jun 25)
Hi,

When a zombie route appears in some stub or esoteric ASN, the damage is
minimal.
But when a zombie route appears in someone as large as AS3356, that
causes chaos.
Here is a traceroute for 128.139.7.0/24 - 30 minutes after a withdrawal
was issued:

  1 vl-51-gw.uoregon.edu (128.223.51.1) [AS 3582] 116 msec 48 msec 48 msec
  2 10.252.19.140 48 msec 48 msec 48 msec
  3 10.252.10.177 48 msec 48 msec
    10.252.9.177 48 msec
  4...

Server boxes/packing request Tom Storey via NANOG (Jun 24)
Hi all, would anyone in the Los Angeles area happen to have recently taken
a delivery of, or will be taking an imminent delivery of, Dell PowerEdge
740xd servers and have their boxes and foam inserts available that you'd
like to get rid of?

We're looking to ship about 14 of these and need boxes and foam inserts to
pack them up.

Thanks

Re: BGP user friendliness (was Re: IPv4 flag day) Tom Beecher via NANOG (Jun 24)
I'm unclear what you mean 'just works' with current products.

I'm also unclear what v4 / v6 usage %'s has to do with this subject (
single vs dual ISP/uplink).

Re: BGP user friendliness (was Re: IPv4 flag day) Saku Ytti via NANOG (Jun 23)
When measuring use, we shouldn't measure bytes moved per AFI.

Because if you care about bytes moved, you can pick some big tech that
loads their global caches over IPv6 and you might be confused to think
that traction is good.

We should be looking at SRC,DST pairs over all traffic, billion bytes
is the same as 1 byte, the internet is still sometimes used for
something else than looking at big tech ads, not much by byte count,
but by...

OARC 47 Call for Contribution Willem Toorop via NANOG (Jun 23)
This workshop will be a hybrid event.

Date - 09-10 November 2026
Location - Vancouver, British Columbia
Times - approximately 10:00-17:00 PDT (Local time PDT is UTC -7; note
that British Columbia has opted to remain on PDT all year round)

Deadline for Submissions - 2026-08-24 23:59 UTC

https://indico.dns-oarc.net/event/58/abstracts/

All DNS-related subjects and discussion topics are welcome although
we're particularly keen to hear more...

Re: BGP user friendliness (was Re: IPv4 flag day) Arie Vayner via NANOG (Jun 23)
Tom,

a certain way, that may require more complexity that has to be paid for. (
in equipment or expertise.) Or > they can just swap cables and reboot
something once in a while, and find that acceptable.

I don't think this is a valid expectation.

The reality is they just make it work with current products, over IPv4, and
the IPv6 usage graph is stuck at 50% and doesn't really move up (at least
not fast enough).

Tnx
Arie

Re: BGP user friendliness (was Re: IPv4 flag day) Shane Ronan via NANOG (Jun 23)
But when something works with IPv4, we shouldn't expect that the user
experience is reduced when moving to IPv6.

Shane

Re: BGP user friendliness (was Re: IPv4 flag day) Tom Beecher via NANOG (Jun 23)
This is just the standard complexity vs cost question.

If someone wants 2 upstreams , that's easy. If they expect it to function a
certain way, that may require more complexity that has to be paid for. ( in
equipment or expertise.) Or they can just swap cables and reboot
something once in a while, and find that acceptable.

Re: BGP user friendliness (was Re: IPv4 flag day) Nick Hilliard via NANOG (Jun 23)
Gary Sparkes via NANOG wrote on 23/06/2026 03:54:

Surely what you mean is: "They just won't support my software. It's
simple enough"?

Nick

Re: BGP user friendliness (was Re: IPv4 flag day) Saku Ytti via NANOG (Jun 23)
Available solution in the toolbox.

Re: BGP user friendliness (was Re: IPv4 flag day) andrew--- via NANOG (Jun 23)
I'm amazed anyone in this list would consider PAT in IPv6 as a preferred solution.

If you need fast failover multihoming with consumer-class connections (ignoring the fact that connections will still
break when failover occurs), then use NPT between the two providers. Pick your primary ISPs prefix as your internal
prefix, NPT to the other one, no port translation needed. Or use ULA, whatever.

This multihoming issue could have been solved...

Re: BGP user friendliness (was Re: IPv4 flag day) Saku Ytti via NANOG (Jun 23)
I think it's entirely fair to want for A but know that B must be done.

Like of course I always wanted that IPv6 would bring some brave new
world of end-to-end Internet. But I want a lot of good things for this
world, which are naive things to want under the incentives the world
has.

And in this case, not budging on our principles which cannot be
achieved is causing tremendous harm.

IPv4 market size is about size of Portugal or New...

Re: LAG/ECMP and 'exact-route' Pedro Prado via NANOG (Jun 22)
Arista does have a command that does exactly this (?)

*Pedro Martins Prado*
pedro.prado () gmail com / +353 83 036 1875 (FaceTime & WhatsApp)

Re: BGP user friendliness (was Re: IPv4 flag day) Arie Vayner via NANOG (Jun 22)
I think I see a misalignment with reality:

Yes, anyone using "BGP to connect to the Internet" is required to have some
level of competence, agreed.

BUT: we can't expect everyone who wants to connect to the Internet to have
that level of competence.
If someone's a graphic designer working from home, and they want resiliency
with 2x ISPs, I don't think we can expect them to have (or be able to
afford) the level of...

RE: BGP user friendliness (was Re: IPv4 flag day) Gary Sparkes via NANOG (Jun 22)
And for those customers who do 1:many nat, my software just won't support them. It's simple enough.

NPT/1:1 NAT is fine. PAT 1:many is not. The "NAT is cancer" statement is entirely relevant.

NPT for SMB stuff is braindead simple - click a few checkboxes. That's the 1:1 scenario that just works and doesn't
require extra code (outside of external address detection) to support unlike 1:many PAT.

-----Original...

More Lists

Dozens of other network security lists are archived at SecLists.Org.