Re: Networks ignoring prepends?

[James Jun]

On Wed, Jan 24, 2024 at 09:22:06AM -0800, William Herrin wrote:
> On Wed, Jan 24, 2024 at 8:39???AM James Jun  wrote:
> > On Wed, Jan 24, 2024 at 08:16:56AM -0800, William Herrin wrote:
> > > Sophistry. I buy IP transit from 3 providers, one of which has a 3 AS
> > > path to 3356.
> >
> > Again you omit context.
> 
> What you're calling context, I call deceptive.
> 
> For one thing, Centurylink's process is, like a spammer, opt-out
> rather than opt-in. 

Nope. Your allegation that Lumen (Centurylink)'s "process" is out-out like a 
spammer is factually and historically incorrect.  However, Lumen's practice is 
complaint with best common practices and experiences as documented on RFC 4277 
and provided by RFC 4271.

Lumen/Centurylink's alleged "opt-out spamming" practice predates their very 
existence and was established during the NSFNET, with an operational need at 
the time to differenciate commercial networks from R networks. Just as R 
networks needed to treat commercial network traffic differently during the 
needs of the NSFNET, commercial operators of the Internet are also expected and 
demanded to prioritize traffic by their paying customers, over non-paying 
customers.

> 3356 enables the local pref unless told through a
> BGP community not to. There's no evidence that 47787 even knows that
> Centurylink is preferring them despite shorter AS paths elsewhere, let
> alone desires that behavior. Indeed, given the prepends that 47787
> added, it's quite possible they desire the opposite.

The evidence is widely documented and is in best common practices of every 
major ASN exercising routing policy and subsequent RFCs and BCPs published 
concerning discussions herein.  Internet standards and documented widely 
accepted current practices exist for a good reason.  Your, or alleged 47787's 
possibility of failure, ignorance or act of ommission in being informed of how 
the current practices work does not make you any less responsible in 
identifying the problem at hand.  Your allegation and arguments that currently 
adopted and documented inter-AS traffic engineering practices are deceptive and 
"opt-out" in a bad-faith nature are simply too tenuous a connection and amount 
to reductio ad absurdum.  You are however welcome to participate in IETF 
process to propose to alter the way BGP practices work for the better, as you 
wish.  That's what's so great about community input-based policy development 
processes.

> 
> For another, a key implication in your "context" is that if one
> customer intentionally pays 3356 to intentionally send another
> customer's packets on a longer, slower trip than 3356 otherwise would,
> that's a legitimate above-board business transaction. Not obviously
> corrupt.

False.  None of the parties described herein, neither 47784, nor 3356 are 
liable in "intentionally" sending traffic of another customer on a longer, less 
efficient path.  What they are however likely liable for, are contractual 
obligations and commercial expectations of bilateral parties engaged in an 
ongoing transaction.  You fit into the chain of buying from 53356 without 
understanding the underlying infrastructure and connectivity relationships that 
53356 has toward 3356.  And you're now litigating that it's corrupt and is 
possibly some kind of a coordinated scheme or a racket without your consent.  
You gave your consent by agreeing to run BGP with 53356 as your vendor, which 
you awarded that business to, and began advertising your prefix.  It's not 
working the way you want, so engage with your vendor to fix it, or fire them.  
This is not hard.

James

Re: Networks ignoring prepends?

[James Jun]

On Wed, Jan 24, 2024 at 08:16:56AM -0800, William Herrin wrote:
> On Wed, Jan 24, 2024 at 8:11???AM James Jun  wrote:
> > You (AS11875) have an operational need for good connectivity
> > into 3356 but, you made a poor purchasing decision by buying
> > IP transit for 11875 from a provider who has 10-AS path into
> > 3356 instead of <=3 AS path. You've done a _bad_ job here
> > in selecting an inferior pathway into 3356, and what you
> > SHOULD have done is to select an IP transit provider who
> > has an optimal AS-path into 3356 to meet your operational
> > need of having good connectivity into 3356.
> 
> Sophistry. I buy IP transit from 3 providers, one of which has a 3 AS
> path to 3356.

Again you omit context.

We've already established as per the RFC, that calculation of degree of 
preference takes precedence over and overrides AS_PATH (Phase 1 decision).  

Therefore, let's rephrase what you've just said above:

You're buying IP transit from 3 providers, two of which are configured with the 
following known constraints:

- 20473 who buys from 1299, who has lower degree of preference into 3356, as 
1299 and 3356 are interconnection (could be settlement-free or paid-peer) 
peering partners.
- 53356 who buys from 47787 as a prioritized downstream customer, and then 
47787 too subsequently connects into 3356 as a prioritized downstream customer.

It's obviously clear that 53356 path you've bought has a priority ticket into 
3356 no matter how inferior or long its AS_PATH may be, and the solution is 
right in front of you.  Next.

James

Re: Networks ignoring prepends?

[James Jun]

On Wed, Jan 24, 2024 at 07:25:42AM -0800, William Herrin wrote:

[ snip ]

> or I chose my words poorly. What I did say, and stand behind, was that
> applying local prefs moves BGP's route selection off the _defaults_,
> and if Centurylink was routing to me based instead on the defaults
> they'd have made a _good_ route selection instead of a _bad_ one.

This cuts both ways Bill.  First, 3356 is making an intended route selection, 
their customer who interconnects directly into 3356 demands this.  That 
customer who connects into 3356 probably had no idea that you (AS11875) would 
someday decide to take IP transit from a downstream AS of them, and your 
situation was likely never in their minds of consideration in their network 
planning.

_You_ want better connectivity from 3356 to 11875 for the explicit benefit of 
11875, which _you_ operate and control.  That's good, so let's continue.


> 
> I do care whether you're routing packets in a reasonable way. When you
> pick the 10-AS path over the 3-AS path because the 10-AS path arrives
> from a customer, the odds that you're routing those packets in a
> _good_ way are very low. I get that a lot of you do that. I'm telling
> you that when you do, you're doing a _bad_ job. If you think you're
> justified, well, it's your business. But don't doubt for a second that
> you've served your customers poorly.

Conversely at the same time, the below is also equally true:

You (AS11875) have an operational need for good connectivity into 3356 but, you 
made a poor purchasing decision by buying IP transit for 11875 from a provider 
who has 10-AS path into 3356 instead of <=3 AS path.  You've done a _bad_ job 
here in selecting an inferior pathway into 3356, and what you SHOULD have done 
is to select an IP transit provider who has an optimal AS-path into 3356 to 
meet your operational need of having good connectivity into 3356.


> And before you suggest that I'm not your customer, let me point out
> what should be obvious: if none of your paying customers were trying
> to reach my network, I wouldn't notice which direction you routed my
> packets, let alone care. It's not about serving me, it's about serving
> your paying customers. My packets are their packets, and when you send
> _their_ packets along the scenic route, you have done a bad job.

We can do this all day long.  You (AS11875) also have the responsibility to 
yourself and your end-users to select and award business to an IP transit 
provider and make every reasonable efforts to ensuer that 11875 has good 
connectivity into 3356 as your operational needs require.  You've abrogated 
that responsibility in your own AS and decided to spew non-sense over the most 
critical and important knob that is more important than AS_PATH (LOCAL_PREF) in 
BGP-4 that was developed since NSFNET days and are telling us that we're doing 
a poor job.  Your argument fails.

The internet works upon the principle of "best-effort."  What you're describing 
is the net effect of that "best-effort", and you, as the operator and 
controller of AS11875 which is involved in the path are just as culpable and 
responsible.  Moreover, you, by being the operator of an AS in the problematic 
path, have the wherewithal and commercial ability to fix it, without involving 
the rest of us.  The answer right is in front of you.

James

Re: Networks ignoring prepends?

[James Jun]

s as clearly 
specified in the RFC is to determine the degree of preference to meet local 
routing policy.


The degree of preference differs greatly depending on what type of network you 
run.  If you're an edge consumer ASN (such as multi-homed stub enterprise 
running BGP), without providing any downstream IP transit to other BGP 
customers, and not peering with other networks (at an IX or otherwise), then 
your network probably doesn't have a lot of need to apply administrative policy 
to determine a degree of preference, and you can be happy fiddling with just 
AS_PATH.

But if you're running a network which provides transit to other ASNs and 
peering with other networks, then suddenly, applying administrative policy is 
not only desirable, but operationally required.  This isn't solely a 
revenue/greed problem as some have cynically stated, but it's actually also a 
critical service availiability and reliability issue, because not having degree 
of preference pursuant to established routing policy in an IP network 
completely eliminates the ability to implement a desired predictability in 
traffic engineering to meet capacity planning objectives for network 
interconnections.

Are there exceptions, pitfalls to this, where poorly designed or thought-out 
networks suffer in certain routing situations?  Absolutely.  But that's the 
Internet-- it's not perfect, but it works very well most of the time for most 
situations.  

Your desired 'policy-free, AS_PATH-only' world may solve your particular 
complaint at hand, but it absolutely would break the rest of the Internet, with 
no effective ways to implement routing policy for large-scale network 
interconnections that make the Internet tick.  BGP exists to provide anchors to 
apply routing policy into the path selection process at scale.  It is wrong to 
assume that AS_PATH is the first thing and the only thing which matters in BGP, 
through incorrect and out-of-context parsing of the RFC to fit your desired 
narrative.  

In operational realities, backed by the history and the RFCs themselves, the 
single most important and influencial knob in BGP is actually arguablely the 
LOCAL_PREF, more so than AS_PATH.  Sadly, most people won't get to experience 
this until they've run or dealt with operational realities of managing a large 
IP network.  The problem you're complaining about is an exception, primarily 
caused by your poor selection of IP transit provider at the data center which 
you're running AS11875, and you're demanding everyone else to take 
responsibility for the purchasing decision you've made.  There are some good 
proposals, such as commonly accepted wide communities for commonly encountered 
traffic-engineering scenarios to help improve upon this, and make BGP a better 
experience for the end-user in situations like the one you're having, but we're 
not quite there today, and it's understandably not going to be a quick process.

In the meantime, in the immediate short term, glad to hear that your route 
pollution announcement solved the issue for you.  In the medium-term, you 
should get a new transit provider for AS11875 with better connectivity into 
3356.  Long-term, perhaps commonly accepted wide communities could become a 
standard some day to improve knobs in situations like this.


James

Re: Networks ignoring prepends?

[James Jun]

rs like yourself who are not subject to capacity 
or comercial interconnection disputes), and going forward, this is one area of 
requirements to be checked for during the RFQ process for procuring enterprise 
BGP-based IP transit.


> 
> > 5. Keep yelling at the clouds about 3356 , even though they are doing the 
> > same thing that (to the best of my knowledge) every large transit provider 
> > does.
> 
> 6. Pollute the DFZ because in light of what "every large transit
> provider does," that's the solution that actually works.

We've done our part to factually inform you on why BGP works the way it is 
using LOCAL_PREF, and why it is a very bad idea and actually operationally 
harmful to assume that AS_PATH should be the only metric that matters.  
Assuming that AS_PATH is the only metric that would matter demonstrates 
complete misunderstanding and misrepresentation of facts regarding the history 
of BGP and what the protocol is supposed to do.  

Your answer to these facts is to claim that we're defending 3356, perhaps there 
is some kind of a coordinated scheme by old school boyz club or something, and 
that you'll simply pollute everyone's routing table (either to spite or because 
that is the only option that works for you) because BGP is broken or is being 
"tampered with" for profit-driven reasons by your opinions held in view.  
You're welcome to do what you feel you'd need to do to meet your 
traffic-engineering requirements and hold whatever opinions you so desire, but 
you're not entitled to your own set of facts.  I'm sure this will be an amusing 
case example for FIB compression algorithms to automatically filter out your 
said 'polluting' route, but that's a different conversation entirely.  ;-)


Regards,
James

Re: Networks ignoring prepends?

[James Jun]

On Mon, Jan 22, 2024 at 02:03:48PM -0800, William Herrin wrote:
> 
> It offends my pride to handle it this way, but -you- shoulder the cost.
>

You're misdiagnosing the issue at hand.

CL is choosing 3356 47787[x3] 53356 11875[x3] over better path via 1299:

What you need to be doing is reaching out to AS53356 (your upstream provider 
supposedly) to assist with traffic engineering.  Given the # of prepends that 
53356 added themselves, it looks like you're using their communities to prepend 
on top of your own prepends (wasted effort), or they've attempted to help you 
by prepending manually, but to no avail (see our prior discussion).  The next 
level of escalation is for 53356 to now work with 47787 to implement the 
correct traffic engineering policy facing 3356.

This is really something your IP transit providers should be assisting you 
with.  You're misdiagnosing and complaining about something which BGP is 
supposed to be doing, instead of escalating with the right parties who are in 
the best position to be assisting you.

Believe it or not, there are small-medium IP transit providers who are _very 
good_ at assisting their BGP customers in traffic engineering efforts, 
especially with extensive BGP community options, competent network engineers, 
automation and the likes.  Your upstream providers need to step up their game 
to help you out here.  This is not a Lumen/CenturyLink/Level 3 problem.

HTH,
James

Re: Networks ignoring prepends?

[James Jun]

On Mon, Jan 22, 2024 at 06:02:53AM -0800, William Herrin wrote:
> On Mon, Jan 22, 2024 at 5:24???AM Patrick W. Gilmore  
> wrote:
> > Standard practice is to localpref your customers up, which makes prepends 
> > irrelevant. Why would anyone expect different behavior?
> 
> It gives me, your paying customer, less control over my routing
> through your network than if I wasn't your paying customer. That
> seems... backwards.
>

Nope, that is not at all backwards.

Have you actually wondered what would happen, if every major ISP stopped 
classifying routes with localpref, and treated every route received by them 
(including customers and external peers) on same local-pref, so your AS 
prepending can work easily?

Some 21 years ago, there was this little known story during early stages of the 
IPv6 development, called 6bone.  Aside from the lack of native IPv6 (where 
everything had to be tunneled), the #1 issue that guaranteed IPv6 sucked many 
times worse than IPv4 back in the day was the lack of BGP clue by most of IPv6 
DFZ participants at that time, where nobody classified any of their routes 
accordingly with localpref and communities.

Not classifying your routes with local-pref leads to complete operational 
chaos, including world-tour hair-pin sightseeing becoming very common with IPv6 
during 6bone days (which resulted in rise of as30071/occaid to dominate the 
IPv6 DFZ for several years for many to transition out of 6bone).  Not 
classifying routes with local-pref means you do not care whether a particular 
peer is a settlement-free peer or a customer-- this lack of relationship 
classifiction leads to operational harm:  A customer may be paying you $/bits 
expecting you to deliver your on-net traffic onto them over their paid peering 
(or transit) link they bought from you, except, only to find you preferring an 
IX peer (e.g. Hurricane Electric, etc. over IX) as best-path, even without any 
AS Path prepending involved. 

Further, not classifying routes with local-pref and ident communities means you 
are entirely at the mercy of prefix-lists applied on your export policy.  A 
very common occurrence is often a rookie ISP appeared to be giving "transit" to 
a major Tier-1 backbone on a route that was supposed to be customer-originated 
route, but this network selected AS-Path via its uptream provider as best-path, 
instead of direct connection into the said customer.  This happens a lot on a 
route that is "downstream of a downstream" customer, who is also multi-homed 
with the said rookie ISP's upstream Tier-1 provider, thereby resulting in 
equidisant AS-Paths to what is supposed to be a customer-originated route.  
Scale this up to many routes and you have complete chaos and breakdown of your 
BGP routing table.



So, as a customer, you actually SHOULD be demanding your ISPs to positively 
identify and categorize their routes using local-pref and communities.  In 
fact, I will never purchase IP transit with BGP from a provider who doesn't 
categorize routes with local-pref.  As a customer, if you want more control 
over your network's incoming traffic, you need to instead ask your upstream 
providers about their BGP routing policy and how well they support BGP 
communities to let you steer traffic, and use those communities to make 
absolute traffic decisions.



Always remember this #1 rule of BGP decision process:  AS Path is a 
**tie-breaker** to local-pref classification.  When you prepend AS Path, your 
goal is to try to steer traffic from routes that are in the same category (i.e. 
customer or peer) as you.  When your goal is absolute steering (i.e. absolute 
as in, do not advertise to a particular peer, or make your connection standby 
backup where no traffic ever comes until there is complete outage on the other 
path, etc), you absolutely SHOULD be using BGP communities provided by your 
upstream IP provider.  If your IP transit provider does not provide extensive 
BGP communities to meet your requirements, cancel their service and give your 
business to someone else.

A rookie BGP mistake that is commonly made made by those without real-world 
experience, is the assumption that AS Path prepending should deliver absolute 
traffic steering -- it does not, and should NOT, by design.  The BGP Best-Path 
Selection Algorithm is taught very well in the CCIE curriculum, but last I 
looked, they don't teach you on the _why_, only on on the how.  So it's common 
to see enterprise CCIE's working for VARs often falling into the false 
assumption of AS Path.  See 
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html#toc-hId-1778347102

Hope this clarifies.

James

Re: Stealthy Overlay Network Re: 202401100645.AYC Re: IPv4 address block

[James R Cutler]

compatible with devices that do not support it.  it would not be 
>>> appropriate to expect every device vendor to support it.  ...   ":
>>> Perhaps we have some offset about the terminology of "who supports 
>>> whom?" My understanding of the OpenWrt project is that it is an open-source 
>>> program code that supports a long list (but not all) of primarily 
>>> commercial RGs (Residential/Routing Gateways) and WiFi routers that serve / 
>>> support CPE devices (on-premises IoTs). Its basic purpose is to let private 
>>> network owners to replace the firmware code in the RGs with the OpenWrt 
>>> equivalent so that they will have full control of their RGs and then modify 
>>> them if desired. Thus, the basic release of each OpenWrt code maintains 
>>> most of the original functionalities in the OEM device. So, neither the 
>>> original RG nor any IoT manufacturers need be involved with the OpenWrt, 
>>> let alone supporting it. My reference to its V19.07.3 was the version that 
>>> expanded its usable address pool to include 240/4. That was all.
>>> 
>>> For sure, OpenWrt does not run on all RGs in the field. But, this does 
>>> not restrict an overlay network like RAN from starting to network only 
>>> those premises with RGs that run on OpenWrt (plus those RGs compatible with 
>>> 240/4 from the factories). Since the existing CG-NAT is not disturbed and 
>>> daily Internet services are going normally, RAN growth can take its time.
>>> 
>>> 3)" You've provided a link to a D-Link managed switch, not a router. 
>>> Just because it can support L2 routing, doesn't make it a router.   ":
>>> Correct, this is just a basic example for networking the RGs to 
>>> experiment the RAN configuration. It is not intended to be a full-fledged 
>>> router which will have other considerations that are way beyond what EzIP 
>>> should be involved with.
>>> 
>>> 
>>> 
>>> Regards,
>>> 
>>> 
>>> Abe (2024-01-18 22:48)
>>> 
>>> 


Wow, changes happen when one is busy. When was the acronym "RAN" applied to a 
"Stealthy Overlay Network"? In my experience RAN is most often a Radio Access 
Network (military and cellular nets). Return Authorization Number is accepted 
usage in commerce.  I now have several questions:

Shouldn't the acronym be SON, except that is also used many places?
Why are we discussing a "Stealthy Overlay Network" anyway? If truly is 
stealthy, it is probably not guided by RFC.
What does OpenWRT have to do with this? 
I saw the beginning of this discussion long long ago. I still do not understand 
the merits of messing with IPv4 address allocations, especially comparing cost 
of a limited lifetime "Stealthy Overlay Network" as comparted to actually 
deploying and using IPv6. Where will be the long term savings? IPv6 has an 
expected lifetime far in excess of any hacks to extend IPv4 lifetime.
Show me the money.
-
James R Cutler
james.cut...@consultant.com

Re: How threading works (was Re: Root Cause Re: 202401102221.AYC Re: Streamline The CG-NAT Re: 202401100645.AYC Re: IPv4 address block)

[James R Cutler]

On Sat, Jan 13, 2024 at 12:58 PM Bryan Fields mailto:br...@bryanfields.net>> wrote:
> On 1/12/24 3:04 PM, Mu wrote:
>> Would it be possible for you to reply in-thread, rather than creating a new 
>> thread with a new subject line every time you reply to someone?
>> 
>> Trying to follow the conversation becomes very difficult for no reason.
> 
> Threading has nothing to do with subject lines.  RFC822 (now 5822) specifies
> how this works based on message ID.  This thread displays fine in threaded
> mode in my MUA and in the archives.

Bryan,

My personal use of email agents involves ordering incoming messages by date 
sent. Many others order their inbox by date received. I don't use MUA ordering 
by thread or conversation because I must use MUAs on many diverse systems. So 
for many decades, I have continued to use my own mental programming to sort and 
group messages by subject. This, by the way, is akin to aural conversations 
between persons where announcing a change of subject is expected to be followed 
by a new topic.

For those of us on OCD, ADD, or Autism spectrums, multiple subjects lines cause 
cognitive dissonance - sometimes damaging comprehension of the continuing 
thread (conversation). I don't claim it violates the ADA, but it should 
especially when willfully continued after requests for amended behavior. 
Lazarus Long would probably express this more cogently.

In the interest of polite conversation,
-
James R. Cutler
james.cut...@consultant.com

Re: 165 Halsey recurring power issues

[James Jun]

On Mon, Oct 23, 2023 at 03:31:21PM -0400, Babak Pasdar wrote:
> 
> Is the UPS the battery or the battery and controller combined?

"N+1" nominally means you're connected to the same UPS system/complex, but each 
of your feed is on a different module.  Your other leg will be diverse from a 
failure in that module, or downstream PDU/panel work fed by that module.  A 
common failure mode in the UPS system itself hosting the different modules can 
knock out both of your circuits.  It sounds like this is how you are configured 
presently.

"2N" generally means you're connected to completely different UPS 
system/complex and corresponding distribution systems for each of your circuit. 
 This is ideal configuration for most critical loads.

James

Re: 165 Halsey recurring power issues

[James Jun]

On Mon, Oct 23, 2023 at 10:38:09AM -0400, Babak Pasdar wrote:
> I wanted to get some feedback as to what is considered standard A/B 
> power setup when data centers sell redundant power.?? It has always been 
> my understanding that A/B power means individually unique and preferably 
> alternate path connections to disparate UPS units.

Generally speaking, the definition of A/B has become muddied in recent decades. 
 It has almost become an inaccurate marketing term. 

Most sane people have the opinion (myself included) that when "A/B" power is 
offered, it is at minimum offererd as 2N UPS (different building entrance and 
MSBs and even physically separate UPS rooms are also desired on a true 2N A/B, 
but may not always be available).  Some data center operators go even further 
and architect load switching within their distribution, thereby preventing 
single-side/one-leg power outages for customers during most of their power 
maintenance activities

Some data center operators treat "A/B" as convenience for them to undertake 
maintenance and offload uptime responsibilities to their own customers, and 
require them to either undertake their own transfer switching and/or dual-cord 
every equipment, so that they can keep taking one side of the power system down 
for repeated maintenance.  This does not scale well for retail colo, as not 
every customer is going to be good at maintaining two PSUs for every single 
piece of equipment.

Some data centers also view "N+1" system deployment at the UPS as an acceptable 
form of A/B protection, as long as customer circuits are on different PDUs.

Long story short, whether you're receiving N+1 or 2N or 1N, it's important to 
inquire about how your power circuits will be architected and delivered by the 
data center, and either have that codified in the contract or reflected 
appropriately in SLA offering.  There is nothing wrong with the data center 
providing N+1 or 1N power, as long as they're transparent about it and that it 
is what you're willing to accept for the right terms.  However, simply 
accepting "we are providing you A/B power" or "we've never had primary power 
failure" are not sufficient to meet proper due diligence during a site 
selection process, unless you can accept the site outage occurring from time to 
time, or you're deploying your own power plant (i.e. DC power and batteries) to 
supplant data center's own power protection scheme.

James

Re: NTP Sync Issue Across Tata (Europe)

[James R Cutler]

> On Aug 14, 2023, at 3:07 AM, Forrest Christian (List Account) 
>  wrote:
> 
> I've responded in bits and pieces to this thread and haven't done an 
> excellent job expressing my overall opinion.   This is probably because my 
> initial goal was to point out that GPS-transmitted time is no less subject to 
> being attacked than your garden variety NTP-transmitted time. Since this 
> thread has evolved, I'd like to describe my overall position to be a bit 
> clearer.
> 

> 
> And finally, as a sort of a tl;dr; Summary:  Each operator needs to decide 
> how critical time is to their network and pick a solution that works for them 
> and fits the organization's budget.   Some operators might point everything 
> at pool.ntp.org <http://pool.ntp.org/> and not run their own servers.  Others 
> might run their own time lab and use that time to provide NTP time and 
> precision time and frequency via various methods.  Most will be somewhere in 
> between. But regardless of which you choose, please be aware that GPS isn't 
> 100% secure, and neither is NTP. If attack resilience matters to you, you 
> should think about all of the attack vectors and design something that is 
> robust enough to meet your use case.
> 
This has been an interesting thread. I consider Forrest Christian’s note to be 
most cogent. Much of the GPS vs Internet sourcing arguments can probably be 
found in NANOG archives from many years ago. The threat list is longer now, but 
the problem of providing Time Service is still the same.

Twenty-five or so years ago my design process for providing Network Time 
Service to a large company intranet started with the business requirements for 
time service. The Management practice of “Not in my cost center” was 
fundamental to NOT attempting GPS-based deployment. The internal enterprise 
network provided a set of geographically distributed Stratum 2 servers having 
carefully firewalled access to a similar set of Stratum 1 servers with Internet 
access. The Stratum 0 server set list included NIST, USNO, and other similar 
sources distributed globally.

The magic of Dr. Mills algorithm made truechimers of the intranet NTP server 
set which did serve well for the lifetime of the company.

-
James R. Cutler 

Re: NTP Sync Issue Across Tata (Europe)

[James R Cutler]

A carefully selected set of stratum 0 sources for a set of stratum 1 servers is 
the heart of good NTP source design. With at least four “local” stratum 1 
servers, Dr. Mills algorithm is excellent at distinguishing truechimers from 
falsetickers and providing a reliable source of monotonic time. DOS is a 
separate problem.

My NTP network deployment experience for a major auto manufacturer, among 
others, is in agreement with William Herin. A GPS NTP source is a valid Stratum 
0 source, but relying on a single instance for local time is not exceedingly 
better than querying time.apple.com <http://time.apple.com/> or a similar 
source.
-
James R. Cutler 
> 
> William,
> 
> Due to flaws in the NTP protocol, a simple UDP filter is not enough. These 
> flaws make it trivial to spoof NTP packets, and many firewalls have no 
> specific protection against this. in one attack the malefactor simply fires a 
> continuous stream of NTP packets with invalid time at your firewall. When 
> your NTP client queries the spoofed server, the malicious packet is the one 
> you likely receive.
> 
> That’s just one attack vector. There are several others, and all have complex 
> remediation. Why should people bother being exposed to the risk at all? 
> Simply avoid Internet-routed NTP. there are many solutions, as I’ve already 
> described. Having suffered through such attacks more than once, I can say 
> from personal experience that you don’t want to risk it.
> 
> -mel 
> 
>> On Aug 6, 2023, at 10:53 AM, William Herrin  wrote:
>> 
>> On Sat, Aug 5, 2023 at 7:24 PM Mel Beckman  wrote:
>>> That still leaves you open to NTP attacks. The USNO accuracy and monitoring 
>>> is worthless if you suffer, for example, an NTP DDoS attack.
>> 
>> Hi Mel,
>> 
>> From what I can tell, a fairly simple firewall policy of allow UDP 123
>> from known NTP clients and established connections (I sent them a UDP
>> packet recently) stops every one of those attacks (that's actually an
>> NTP attack and not something else like a DNS attack) except for
>> upstream address hijack that happens to coincide with your system
>> boot. And it still depends on the attacker executing an additional
>> sophisticated attack to do more than cause you a denial of service.
>> 
>> The links you sent are very interesting, at least in an academic
>> sense, but they don't cause me to be unduly concerned about employing
>> NTP.
>> 
>> 
>>> if you can eliminate such security problems for $400, I say it’s cheap at 
>>> twice the price.
>> 
>> Except you can't. Redundancy is required for any critical service. At
>> the $400 price point, your approach has multiple
>> single-points-of-failure. The device itself of course. Your ability to
>> receive continuous non-jammed GPS signals at the location where you're
>> able to place an antenna. And in your plan you'll need one of these in
>> every discontiguous network where you have equipment since you're not
>> doing NTP over the Internet.
>> 
>> Not to mention the operations cost. Keeping track of a six inch brick
>> with a wall wart and an antenna installed at a remote site is... not
>> entirely abnormal but it's a one-off that consumes manpower.
>> 
>> And then you're only vulnerable to the litany of Internet attacks
>> which don't involve NTP. Yay!
>> 
>> Don't get me wrong: the Time Machines TM1000A you recommended looks
>> like a cool little device well worth checking into. As a supplement to
>> Internet NTP, not a replacement.
>> 
>> Regards,
>> Bill Herrin
>> 
>> 
>> --
>> William Herrin
>> b...@herrin.us
>> https://bill.herrin.us/

Re: 365 Datacenters Tampa AC Failure

[James Ashton]

Hello all, 
>From our side (365 Data Centers) We saw the issue start at a little after 6:30 
>PM yesterday. We had a component failure and we saw a rise in temperature. We 
>brought additional capacity online while we were working with our vendors on 
>getting replacement hardware. 
The hardware has now been replaced and the system is back online. 
This unit and others in this suite are on the block for replacement this year 
as we add cooling capacity to our various spaces within the Franklin Exchange 
building. 

On a side note, this was not related to the issue mentioned from earlier in the 
month. This was a straight component failure and replacement. 

Any customers impacted can reach out to the 365 Customer Service Center for 
details and documentation. 

Thank you, 
James Ashton 
VP Network Engineering 
365 Data Centers 





From: "NANOG mailing list"  
To: "George Herbert"  
Cc: "NANOG mailing list"  
Sent: Monday, June 12, 2023 8:03:10 PM 
Subject: Re: 365 Datacenters Tampa AC Failure 

Issue started a little after 2am, I was hard down till about 11:30am (servers 
did a high temp shutdown) 

On Jun 12, 2023 8:01 PM, Michael Spears  wrote: 



Yep there's issues over there. They had some compressors go down. Should be 
getting back to normal now... Hasn't been a good month for them in regards to 
cooling.. 

On Jun 12, 2023 7:15 PM, George Herbert  wrote: 

BQ_BEGIN


Oof. Get ready to replace all spinning media you may have there. 

-George 

Sent from my iPhone 

> On Jun 12, 2023, at 4:06 PM, Nick Olsen  wrote: 
> 
> 
> Just a heads up to anyone else colo'd at 365 TPA1/TAMSFLDE. Currently seeing 
> floor temps of ~105F as reported by equipment. Started yesterday at ~5:30PM 
> eastern. 2nd AC failure in the last 30 days. They have not sent any advisory 
> notices as of yet. 





BQ_END

Re: Conduit Lease/IRU Pricing

[James Jun]

On Mon, Feb 06, 2023 at 06:57:27AM -0500, Fletcher Kittredge wrote:
> A big issue you don't mention is the easement, the legal right to place
> conduit. What does it mean to buy conduit if you don't have an easement on
> the property to use the conduit?

Typically, in large telecom installs like this (esp. for joint trench builds), 
the lead company obtains an Easement Agreement which allows "other 
telecommunications providers", "licensees" or "other designated agents" of the 
lead company to access and use the full enjoyment of the easement areas.  If 
you dig up registry of deeds for some large telecom joint trench builds (I can 
think of at least two examples), you'll find that these come pretty standard.

Further, conduit lease and license agreements of these sort for the buyer 
typically include Underlying Rights clause that also requires the trench system 
owner (the seller) to maintain underlying rights for the purchaser of rights to 
the conduit.  Seller is required to ensure that the buyer has proper legal 
rights to enter and make full enjoyment of the conduit capacity it purchased or 
otherwise licensed from the seller.

For constructions occuring outside of private property, the lead company is 
responsible for engaging local authorities owning the public right-of-way to 
propose the system installation in a multi-tenancy nature (i.e. the system 
meets and exceeds Dig Once and joint trench requirements set out by the 
municipality and so forth); as such, the right-of-way siting permits are 
developed to allow construction of the entire system and with the understanding 
of access by all users, in principle and procedures as provided under 
respective state laws.


James

Re: Conduit Lease/IRU Pricing

[James Jun]

rs and hardballers are going to be involved.  In many situations, 
sellers may start by wanting to make you pay for 100%+ of their costs of doing 
construction/business (typical investor/short return model), where you're 
effectively paying not only for your own conduit, but for their conduits as 
well-- sellers will call this an acceptable "cost recovery model".  Their 
position may hold true if you're the only primary tenant of the proposed duct 
system, or not, if there are other tenants also joining.  For the seller, it 
will largely come down to justifying their capital and operating costs and 
depreciation expected over time.  If the buyer has a good faith reason to 
believe that seller is attempting to make opportunistic profits beyond 'just 
and reasonable costs' not to exceed capital and operating expenses, it could 
potentially result in disputes and regulatory complaints.  This is one of the 
reasons on why a conduit license/recurring lease scheme is more 
straight-forward for duct access in existing systems.

One commonly accepted principle to determine pricing for conduit access is to 
apply the energy utility industry's method of using Rate of Return formula, 
where owner of the system keeps to an allowed Rate of Return of reasonable 
percentage, and then plays with depreciation expenses to get some wiggle room 
in how they would compute for costs.  It's a complex topic.


James

Re: Conduit Lease/IRU Pricing

[James Jun]

On Sun, Feb 05, 2023 at 12:36:27PM -0800, William Herrin wrote:
> 
> One quick note: conduit on private property, such as the tail of a
> telco conduit serving a small office complex, is almost always a
> fixture of the property belonging to whoever owns the land. Even
> though the telco installed it for free. It's just too expensive for
> them to dot the i's and cross the t's legally when installing the
> conduit tail, so they generally just do it realizing there's low odds
> of anyone hijacking it from them.
> 

This is an important point that does come up.  In commercial property 
installations, telcos often choose to look over this just like you 
stated--since they control the mainline system out in the street anyway, they 
feel that provides enough of security and not enough of a concern to lose sleep 
over it.

However, in valuable multi-tenant facilities (carrier hotels, data centers, and 
large commercial/urban developer projects), you will also find that telecom 
carriers can, and often will, absolutely enforce their rights to their conduit 
systems (including tails) being placed upon private property.  Access and 
Easement Agreements are frequently used to enforce the purpose of the wayleave 
for large telecom installations occuring upon private property.  Therefore, it 
is important to contact the property owner and the owner of the wayleave (i.e. 
carrier owning the conduit system on private property) for permission/license 
to enter, and never assume that just because a conduit is in private property 
and the landlord thinks you're ok, yo're good to go.  More often than not, it 
is not ok, and you will likely end up getting nasty surprises from the said 
carrier's legal department, when they decide to enforce their rights.

This happened to a large Tier-1 carrier who was pulling fiber into a new 
developer project here.  The property owner told them it was ok to use the 
conduit, and all of the manholes were simply labeled 'FIBER OPTIC' engraved on 
them, so the carrier thought they had permission to pull fiber.  They never 
realized that the ILEC had an easement agreement and those conuits and manholes 
were paid for by the ILEC for installation.  Their fiber cable was discovered 
about a week later when ILEC crews were working to pull their own cable in-- 
the rest is hitory, they had to make amends to obtain proper authorization and 
pay fees, etc. after being discovered.  After this happened, the ILEC also 
replaced all manhole covers in the property with their name and logo engraved 
on them.

James

Re: Conduit Lease/IRU Pricing

[James Jun]

On Sun, Feb 05, 2023 at 11:21:09AM -0600, Mike Hammett wrote:
> I know that location matters, but I hope to be location agnostic.
> 
> How have you seen empty conduits sold? Entire route only, or is a partial 
> route okay? Twenty years only or less? Price compared to cost of 
> construction? Ongoing maintenance costs?

Yes and yes.  Yes on both partial and full route conduits.

Generally speaking, most telcos and utility owners will not sell you conduits.  
The commonly opportune time for you to "buy" a conduit or buy rights to use a 
conduit in perpetuity or for long periods is to join into a common trench when 
a joint trench construction is proposed in the area.  In this instance, in most 
cases, you don't even have to do any construction yourself, you simply specify 
the size/number of ducts you want as a customer and you pay pro-rata share of 
the joint trench construction costs.

Where you can buy an existing conduit, from published projects, I've seen them 
going for sale usually between $100 to $290 per linear foot, this is in Boston. 
 If you do the fine prints and math, when purchasing an empty conduit (even 
buying a municipal conduit), you may find that post-construction conduit sales 
are generally higher in price than what it costed to build it in the first 
place.  This is because most sellers will consider the current market rates and 
field conditions (i.e., they will approximate how painful and costly will be 
for you to re-open the street and build a new duct system for yourself, and 
whether local authorities would even allow that to happen based on how full the 
street is, and based on that difficulty, price will often commensurate 
accordingly).  

One thing to note here is that federal law stipulates (47 USC Sec. 224) that 
attachment rates shall be 'just and reasonable' (Note:  I am not a lawyer, seek 
legal advice from an actual attorney).  As such, this is one point of 
consideration that sellers do often consider, when developing pricing for 
selling a conduit-- attempting to make high-return profits off of an empty 
conduit that is in multiples of construction costs (e.g. many PE or investor 
backed companies will demand high returns in short term after construction), 
could potentially subject them to a regulatory complaint by a telecom attacher 
to the state PUC.  This is one of the reasons that was cited by one 
investor-backed utility in my area, as to why they will refuse to 'sell' empty 
conduits-- however, they will lease conduit space to you for annual recurring 
fee at reasonable rates, so they're compliant with the law.


So, often more common approach to acquiring access to ducts is leasing at a 
recurring fee, as outright purchasing them post-construction is not something 
many utility owners do.  Here, most conduit leases from publicized figures go 
from $0.05/ft/year to $3.5/ft/year for leases by privately held or investor 
owned utilities, and $1-$100/ft/year from state transit agencies.

If you lease a conduit, usually ongoing maintenance costs are baked into the 
cost of your annual lease.  If you purchase an empty conduit outright, or buy 
long-term rights to use it in lump sum, you are often charged pro-rata share of 
O costs, similar to that of condominium fee, to cover ongoing expenses, such 
as utility costs to invest in crew safety training programs, plant protection 
(Dig Safe/USA/one-call locate responses to mark the trench, etc), weekly trench 
patrols, manhole inspections, etc.  You will also pay an inspection fee every 
time you enter and work in a utility-owned manhole, generally priced similar to 
that of hiring a police detail.  These are all reasonable costs and you should 
expect to pay them accordingly when working in a utility conduit system.


You will also find that leasing conduit is a difficult topic in itself.  
Usually it may be easier to engage a heavily regulated incumbent LEC or another 
public utility who is regulated to provide telecom duct space (electric 
transmission owners providing UG duct space for telecom, etc).  Process will 
take long, but these guys are regulated and required by law to provide you 
conduit license at affordable, "just and reasonable" rates.

Another aspect that cannot be ignored when it comes to obtaining duct space, is 
asset trading/exchange agreements.  Telcos (both ILECs and CLECs) love this, as 
much as we network operators in NANOG love peering--you can propose to give 
them duct space in conduits you already have that they don't have (or even 
fiber optic cable capacity in some cases), in exchange for them giving you 
their conduit space to you, in a trade.  Just like IP peering, many asset 
exchange/trade agreements are often settlement-free, but commercially settled 
exchange arrangements are also very popular, specific terms of these agreements 
and negotiations are often confidential.

James

Sites blocking ISP Addresses

[James Dexter]

Dear list,
We have address ranges that are being blocked by sites like Ticketmaster.
Customer support is able to assist, and unable to receive a response from
legal or hostmaster emails. What are the recommendations for requesting a
removal from the blocked list at these sites?

Re: Normal ARIN registration service fees for LRSA entrants after 31 Dec 2023 (was: Fwd: [arin-announce] Availability of the Legacy Fee Cap for New LRSA Entrants Ending as of 31 December 2023)

[babydr DBA James W. Laferriere]

On Tue, 13 Sep 2022, Randy Bush wrote:

We strongly encourage all legacy resource holders who have not yet
signed an LRSA to cover their legacy resources to


consult a competent lawyer before signing an LRSA
randy

I concur ,  And seconded .

Hth ,  JimL
--
+-+
| James   W.   Laferriere| SystemTechniques | Give me VMS |
| Network & System Engineer  | 3237 Holden Road |  Give me Linux  |
| j...@system-techniques.com | Fairbanks, AK. 99709 |   only  on  AXP |
+-+

Re: RFC: BOGONs over BGP, adding some ranges

[James Shank]

Hi John!

Thanks for the comments!

If you're in Hollywood for N86, perhaps we can pour one our for 
multicast together... ;)


Cheers!

James

On 8/30/22 4:21 PM, John Kristoff wrote:

On Tue, 30 Aug 2022 13:15:40 -0400
James Shank  wrote:


224/4

If any were to cause a problem, I'd think this is the one that would be
most likely.  While inter-domain IP multicast is practically dead and
so the impact might not be so great (sorry multicast-wg and mboned
friends), there may be pockets of RP and link-local and site-local
GLOP-like things (e.g., for system imaging) things that I could imagine
might break.  Then again, break it, break it in a million little pieces,
ip.idr-multicast.die.die.die! :-)

John


--
*James Shank*
Chief Architect of Community Services and Sr. Security Evangelist
e: jsh...@cymru.com
o: +1 847 378-3365

RFC: BOGONs over BGP, adding some ranges

[James Shank]

Dear NANOG!

As many of you know, Team Cymru runs a free service delivering updated 
BOGONS to networks around the world. We've been doing this for decades 
at this point. For more information about this service, please see 
https://www.team-cymru.com/bogon.


Recently, we've discussed internally a discrepancy between our BGP based 
feed and the other formats we deliver for our Traditional BOGONS feed. 
For historic reasons, we previously omitted delivery of some ranges that 
are BOGONS from our BGP advertisements. We are considering adding the 
below ranges back in, but want to hear feedback from the community on 
these ranges prior to advertising them, out of an abundance of caution.


The below ranges are what we are currently considering advertising:
0/8 (this one we already have concluded is safe as it is already 
advertised in our "FULL BOGONS" set.)

127/8
224/4
240/4

Note that 224/4 and 240/4 may be aggregated differently in our 
advertisement, but are broken out here to facilitate discussion.


So, fellow NANOGers, what say ye? I would love to hear your feedback, 
pro or con, well-reasoned with data points or general "argh! there be 
dragons!" sentiments.


Looking forward to seeing folks in Hollywood for N86!

Cheers!

James

--
*James Shank*
Chief Architect of Community Services and Sr. Security Evangelist
e: jsh...@cymru.com
o: +1 847 378-3365

Frontier Temecula CA outage

[James Laszko via NANOG]

Anyone able to give any insight into Frontier FIOS outage in the Temecula area? 
 Our team can’t get past level 1 support with unknown ETTR times for hundreds 
of customers.  Over 16 hours down so far.  Any info appreciated!


Thanks,


James Laszko
P 951-813-2674
F 951-252-6210
Helpdesk 951-813-2685
jam...@mythostech.com
mythostech.com

Re: 400G forwarding - how does it work?

[James Bensley]

On Tue, 26 Jul 2022 at 21:39, Lawrence Wobker  wrote:
> So if this pipeline can do 1.25 billion PPS and I want to be able to forward 
> 10BPPS, I can build a chip that has 8 of these pipelines and get my 
> performance target that way.  I could also build a "pipeline" that processes 
> multiple packets per clock, if I have one that does 2 packets/clock then I 
> only need 4 of said pipelines... and so on and so forth.

Thanks for the response Lawrence.

The Broadcom BCM16K KBP has a clock speed of 1.2Ghz, so I expect the
J2 to have something similar (as someone already mentioned, most chips
I've seen are in the 1-1.5Ghz range), so in this case "only" 2
pipelines would be needed to maintain the headline 2Bpps rate of the
J2, or even just 1 if they have managed to squeeze out two packets per
cycle through parallelisation within the pipeline.

Cheers,
James.

Re: 400G forwarding - how does it work?

[James Bensley]

On Wed, 27 Jul 2022 at 15:11, Masataka Ohta
 wrote:
>
> James Bensley wrote:
>
> > The BCM16K documentation suggests that it uses TCAM for exact
> > matching (e.g.,for ACLs) in something called the "Database Array"
> > (with 2M 40b entries?), and SRAM for LPM (e.g., IP lookups) in
> > something called the "User Data Array" (with 16M 32b entries?).
>
> Which documentation?
>
> According to:
>
> https://docs.broadcom.com/docs/16000-DS1-PUB
>
> figure 1 and related explanations:
>
> Database records 40b: 2048k/1024k.
> Table width configurable as 80/160/320/480/640 bits.
> User Data Array for associated data, width configurable as
> 32/64/128/256 bits.
>
> means that header extracted by 88690 is analyzed by 16K finally
> resulting in 40b (a lot shorter than IPv6 addresses, still may be
> enough for IPv6 backbone to identify sites) information by "database"
> lookup, which is, obviously by CAM because 40b is painful for
> SRAM, converted to "32/64/128/256 bits data".

Hi Masataka,

Yes I had read that data sheet. If you have 2M 40b entries in CAM, you
could also have 1M 80 entries (or a mixture); the 40b CAM blocks can
be chained together to store IPv4/IPv6/MPLS/whatever entries.

Cheers,
James.

Re: 400G forwarding - how does it work?

[James Bensley]

Hi Lawrence, thanks for your response.

On Mon, 25 Jul 2022 at 15:34, Lawrence Wobker  wrote:
> This is the parallelism part.  I can take multiple instances of these 
> memory/logic pipelines, and run them in parallel to increase the throughput.
...
> I work on/with a chip that can forwarding about 10B packets per second… so if 
> we go back to the order-of-magnitude number that I’m doing about “tens” of 
> memory lookups for every one of those packets, we’re talking about something 
> like a hundred BILLION total memory lookups… and since memory does NOT give 
> me answers in 1 picoseconds… we get back to pipelining and parallelism.

What level of parallelism is required to forward 10Bpps? Or 2Bpps like
my J2 example :)

Cheers,
James.

Re: 400G forwarding - how does it work?

[James Bensley]

Thanks for the responses Chris, Saku…

On Mon, 25 Jul 2022 at 15:17, Chris Adams  wrote:
>
> Once upon a time, James Bensley  said:
> > The obvious answer is that it's not magic and my understanding is
> > fundamentally flawed, so please enlighten me.
>
> So I can't answer to your specific question, but I just wanted to say
> that your CPU analysis is simplistic and doesn't really match how CPUs
> work now.

It wasn't a CPU analysis because switching ASICs != CPUs.

I am aware of the x86 architecture, but know little of network ASICs,
so I was deliberately trying to not apply my x86 knowledge here, in
case it sent me down the wrong path. You made references towards
typical CPU features;

> For example, it might take 4 times as long to process the first packet,
> but as long as the hardware can handle 4 packets in a queue, you'll get
> a packet result every cycle after that, without dropping anything.  So
> maybe the first result takes 12 cycles, but then you can keep getting a
> result every 3 cycles as long as the pipeline is kept full.

Yes, in the x86/x64 CPU world keeping the instruction cache and data
cache hot indeed results in optimal performance, and as you say modern
CPUs use parallel pipelines amongst other techniques like branch
prediction, SIMD, (N)UMA, and so on, but I would assume (because I
don’t know) that not all of the x86 feature set map nicely to packet
processing in ASICs (VPP uses these techniques on COTS CPUs, to
emulate a fixed pipeline, rather than run to completion model).

You and Saku both suggest that heavy parallelism is the magic source;

> Something can be "line rate" but not push the first packet
> through in the shortest time.

On Mon, 25 Jul 2022 at 15:16, Saku Ytti  wrote:
> I.e. say JNPR Trio PPE has many threads, and only one thread is
> running, rest of the threads are waiting for answers from memory. That
> is, once we start pushing packets through the device, it takes a long
> ass time (like single digit microseconds) before we see any packets
> out. 1000x longer than your calculated single digit nanoseconds.

In principal I accept this idea. But lets try and do the maths, I'd
like to properly understand;

The non-drop rate of the J2 is 2Bpps @ 284 bytes == 4.8Tbps, my
example scenario was a single J2 chip in a 12x400G device. If each
port is receiving 400G @ 284 bytes (164,473,684 pps), that’s one every
6.08 nanoseconds coming in. What kind of parallelism is required to
stop from ingress dropping?

It takes say 5 microseconds to process and forward a packet (seems
reasonable looking at some Arista data sheets which use J2 variants),
which means we need to be operating on 5,000ns / 6.08ns == 822 packets
per port simultaneously, so 9868 packets are being processed across
all 12 ports simultaneously, to stop ingress dropping on all
interfaces.

I think the latest generation Trio has 160 PPEs per PFE, but I’m not
sure how many threads per PPE. Older generations had 20
threads/contexts per PPE, so if it hasn’t increased that would make
for 3200 threads in total. That is a 1.6Tbps FD chip, although not
apples to apples of course, Trio is run to completion too.

The Nokia FP5 has 1,200 cores (I have no idea how many threads per
core) and is rated for 4.8Tbps FD. Again doing something quite
different to a J2 chip, again its RTC.

J2 is a partially-fixed pipeline but slightly programmable if I have
understood correctly, but definitely at the other end of the spectrum
compared to RTC. So are we to surmise that a J2 chip has circa 10k
parallel pipelines, in order to process 9868 packets in parallel?

I have no frame of reference here, but in comparison to Gen 6 Trio of
NP5, that seems very high to me (to the point where I assume I am
wrong).

Cheers,
James.

400G forwarding - how does it work?

[James Bensley]

Hi All,

I've been trying to understand how forwarding at 400G is possible,
specifically in this example, in relation to the Broadcom J2 chips,
but I don't the mystery is anything specific to them...

According to the Broadcom Jericho2 BCM88690 data sheet it provides
4.8Tbps of traffic processing and supports packet forwarding at 2Bpps.
According to my maths that means it requires packet sizes of 300Bs to
reach line rate across all ports. The data sheet says packet sizes
above 284B, so I guess this is excluding some headers like the
inter-frame gap and CRC (nothing after the PHY/MAC needs to know about
them if the CRC is valid)? As I interpret the data sheet, J2 should
supports chassis with 12x 400Gbps ports at line rate with 284B packets
then.

Jericho2 can be linked to a BCM16K for expanded packet forwarding
tables and lookup processing (i.e. to hold the full global routing
table, in such a case, forwarding lookups are offloaded to the
BCM16K). The BCM16K documentation suggests that it uses TCAM for exact
matching (e.g.,for ACLs) in something called the "Database Array"
(with 2M 40b entries?), and SRAM for LPM (e.g., IP lookups) in
something called the "User Data Array" (with 16M 32b entries?).

A BCM16K supports 16 parallel searches, which means that each of the
12x 400G ports on a Jericho2 could perform an forwarding lookup at
same time. This means that the BCM16K "only" needs to perform
forwarding look-ups at a linear rate of 1x 400Gbps, not 4.8Tbps, and
"only" for packets larger than 284 bytes, because that is the Jericho2
line-rate Pps rate. This means that each of the 16 parallel searches
in the BCM16K, they need to support a rate of 164Mpps (164,473,684) to
reach 400Gbps. This is much more in the realm of feasible, but still
pretty extreme...

1 second / 164473684 packets = 1 packet every 6.08 nanoseconds, which
is within the access time of TCAM and SRAM but this needs to include
some computing time too e.g. generating a key for a lookup and passing
the results along the pipeline etc. The BCM16K has a clock speed of
1Ghz (1,000,000,000, cycles per second, or cycle every 1 nano second)
and supports an SRAM memory access in a single clock cycle (according
to the data sheet). If one cycle is required for an SRAM lookup, the
BCM16K only has 5 cycles to perform other computation tasks, and the
J2 chip needs to do the various header re-writes and various counter
updates etc., so how is magic this happening?!?

The obvious answer is that it's not magic and my understanding is
fundamentally flawed, so please enlighten me.

Cheers,
James.

Re: FCC proposes higher speed goals (100/20 Mbps) for USF providers

[babydr DBA James W. Laferriere]

Hello Jason & All ,

On Thu, 26 May 2022, Livingood, Jason via NANOG wrote:


Latency is a limitation for things that are generally relatively low bandwidth 
(interactive audio, zoom, etc.).
Higher bandwidth won?t solve the latency problem


+1


You Mean something a little less than ...

   My traceroute  [v0.94]
replaceme (192.168.253.147) -> Snipped   
2022-05-26T13:06:34-0800
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
Packets   Pings
 Host   Loss%Snt Drop   Rcv   Last  Avg  Best  Wrst 
StDev
 1. ...Snip...
 2. AS???192.168.251.1   0.0%890891.3   1.3   0.8   1.9   
0.2
 3. AS???10.5.5.227  1.1%89188  227.5 123.9  31.1 276.5  
69.8
 4. AS???10.5.5.185  2.2%89287   43.5  48.7  28.5  72.0  
10.3
 5. AS???10.5.21.241 1.1%89188   36.6  40.3  30.5  64.3   
5.7
 6. AS???10.128.88.234   2.2%89287   52.9  39.8  31.8  63.8   
5.3
 7. AS???10.128.128.125  10.1%   89980   42.5  40.0  29.6  55.7   
4.7
 8. AS???10.128.118.217  72.7%   89   6424   36.7  39.6  29.7  49.8   
4.8
 9. AS???10.128.0.16631.5%   89   2861   60.0  58.8  45.8  86.5   
8.0
10. AS???10.128.0.17085.2%   89   7513  101.1  81.7  70.7 101.1   
9.7
...snip...

Oh ,  Sorry you were talking about latncy not Packet loss .
	While I do understand that icmp responses ARE Low priority the above 
still gives some useful info .  IMO Packet losses like the above are far worse 
than latency ,  But as far as an eyeball networks users experience makes 
absolutely no difference .


IMO as we enter the 'post-gigabit era', an extra 1 Gbps to the home will 
matter less than 100 ms or 500 ms lower working latency (optimally sub-50 ms, 
if not sub-25 ms). The past is exclusively speed-focused -- the future will be


Speed + working latency + reliability/resiliency + consistency of QoE + 
security/protection + WiFi LAN quality.


	One more set of nit's ,  "security/protection" by who's standard should 
this be taken from ,  Eyeball users ,  Eyeball network Operators ,  His 
upstreams ,  US Gov ,  Nato , ... ?


	Where can each of those mentioned in the above have their input listened 
too & acted apon ?




--
+-+
| James   W.   Laferriere| SystemTechniques | Give me VMS |
| Network & System Engineer  | 3237 Holden Road |  Give me Linux  |
| j...@system-techniques.com | Fairbanks, AK. 99709 |   only  on  AXP |
+-+

Re: Fwd: Fw: HOST IRR Retirement

[babydr DBA James W. Laferriere]

Hello Ross ,  I do not see a host name or IP4or6 in the below .
Hth ,  JimL

On Mon, 11 Apr 2022, Ross Tajvar wrote:

I tried sending the below message from my work account, but it's not a
nanog subscriber, so the email was rejected. If anyone doubts the
authenticity, feel free to reach out to me at rtaj...@365datacenters.com.


--
*From:* Ross Tajvar
*Sent:* Monday, April 11, 2022 3:53 PM
*To:* nanog@nanog.org 
*Subject:* HOST IRR Retirement

Hi all,

We (365 Datacenters) inherited the HOST IRR. We have removed all stale
objects from it, and moved all valid objects to other IRRs. We will
eventually (hopefully soon) turn it off altogether. Please, if you are
mirroring it, stop doing that. If you maintain documentation that lists
IRRs, please update it to reflect that HOST is no longer in use.

Thanks!

P.S. If anyone thinks I should also announce this somewhere else, please
let me know.

*Ross Tajvar*

Network Engineer

Office: (571)-341-8899

Support: (866)-365-6246



--
+-+
| James   W.   Laferriere| SystemTechniques | Give me VMS |
| Network & System Engineer  | 3237 Holden Road |  Give me Linux  |
| j...@system-techniques.com | Fairbanks, AK. 99709 |   only  on  AXP |
+-+

Re: 2749 routes AT RISK - Re: TIMELY/IMPORTANT - Approximately 40 hours until potentially significant routing changes (re: Retirement of ARIN Non-Authenticated IRR scheduled for 4 April 2022)

[babydr DBA James W. Laferriere]

Hello Job ,

On Tue, 5 Apr 2022, Job Snijders via NANOG wrote:

...snip...


I think there clearly is an industry-wide trend to move away from
'unsigned plain-text non-authoritative' datasets, towards better sources
of truth such as the VRP data available through the RIR RPKI Trust
Anchors.

There are variances in how stakeholders implement this paradigm shift:
some operators move towards wholesale ignorance of non-auth databases
(like Tata); some operators use softer transition mechanisms (examples:
what RIPE NCC did in lieu of RIPE-731, or how IRRd v4 in its default
configuration magically makes RPKI-invalid IRR objects disappear).

I think all of us recognize a need to declaw "third party" IRR databases
like RADB and ALTDB ("declawing" meaning that it is not desirable that
anyone can just register *anything*); on the other hand our community
also has to be cognizant about there being parts of the Internet which
are not squatting on anyone's numbers *and* also are not contracted to a
specific RIR.
Kind regards,
Job
	Your final paragraph hits directly on my situation ,  That is as soon as 
I can get my small network connected again via hardline connections again .

I am not a customer of ARIN except for one asn .
I hold maintainership a couple of pre-arin /24's .

	And until a (imo) reasonable contract with pre-arin holders can be 
created AND a reasonable fund dispersement calculation with HARD Set $ values 
assigned ,  I will not be a Arin customer except for my one little ASN .  Which 
when I was assigned that resource was just $100/yr ,  Imo a reasonable cost . 
that cost has now only gone up 50% ,  Again somewhat reasonable cost ,  BUT that 
cost going UP is of concern to my meager financial status .


	I am greatly exasperated that I am not hearing about Public versions of 
RPKi repositories in the veign of ALTDB .

In other words a Publicly held and Volunteer based entity .

	Blast I wish I had the financial witheral to back such an enterprise . 
If I did it would remain totally vounteer & a not for profit & I'd really like 
it to be Voluntarilly funded by the Community .


	I ask the Community why someone or some entity IS not coming forward and 
doing so ?


Sorry about the rambling .

Twyl ,  JimL
--
+-----+
| James   W.   Laferriere| SystemTechniques | Give me VMS |
| Network & System Engineer  | 3237 Holden Road |  Give me Linux  |
| j...@system-techniques.com | Fairbanks, AK. 99709 |   only  on  AXP |
+-+

Re: Let's Focus on Moving Forward Re: V6 still not supported

[James R Cutler]

On Mar 31, 2022, at 11:51 PM, Masataka Ohta  
wrote:
> 
> Owen DeLong wrote:
> 
>> It still suffers from a certain amount of opacity across administrative 
>> domains.
> 
> So, if an IPv6 prefix is assigned to an apartment building and
> the building has no logging mechanism on how addresses are used
> within the building, the problem of audit trail opacity is
> suffered.
> 
> Thank you very much to have proven IPv6 useless.
> 
>   Masataka Ohta

You appear to attribute to IPv6 a problem due to building management. Please 
explain how IPv6 is “useless” by some other measure that that of building 
management errors.

Re: V6 still not supported

[James R Cutler]

On Mar 24, 2022, at 9:25 PM, Owen DeLong via NANOG  wrote:
> 
> I think that we’re still OK on allocation policies. What I’d like to see is 
> an end to the IPv4-think in large ISPs, such as Comcast’s continued micro 
> allocations to their customers.

What exactly is your definition of “micro allocations”? Is a prefix/56 a “micro 
allocation”? In over nine years of being an active forum participant and 
customer of Comcast, I can not recall the usage of the term.

Re: BOOTP & ARP history

[James R Cutler]

> On Mar 19, 2022, at 2:49 PM, Michael Thomas  wrote:
> 
> IPv6 in comparison was very familiar ground. To me it seemed that it was ipv4 
> with bigger addresses and that was about it. But I've never understood all of 
> the strum und drang about ipv6.

As one tightly involved in multiprotocol networking in the '90s, I viewed with 
interest the evolution of IPv6. Nothing about IPv6 changed fundamental physical 
network design principals, except to remove IPv4 limits on the number of 
subnetworks. Oh, and the removal of coordinated RFC1918 addressing between 
members of the ever active merger and acquisition world. Life became much 
rosier. One could concievably deploy a plant floor with a million IPv6 globally 
unique device address without kludges required by IPv4.

I never ran into Sturm und Drang about IPv6 itself, only about the required 
investment in people and hardware, which I considered a short term bump with a 
long term payoff.

That, I discovered, was the true barrier to IPv6 planning and deployment — 
middle management, especial account managers. The basic argument was “The 
customer must first ask for it and sign a contract, then we will prepare for 
it.” Too much “not in my cost center” mentality crippled the ability of network 
implementers to even deploy IPv6 for demonstration purposes, as well as for 
learning. The idea that “my investment” might also benefit others, even in my 
own company was anathema. I have never become short sighted enough to endorse 
such idiocy.

As one experience with ‘joys’ of end to end connections between NATted networks 
with overlapping RFC1918 space, The advent of CGNAT and various pipe dreams 
(mostly in the US) of extending IPv4 address space offends my business sense 
and technical sense for wasting time, materials, and money.

RE: VPN recommendations?

[James R. Price]

I’ll second PFsense, done quite a bit of this in hub and spoke topologies, 
spokes being behind NAT (permitted the upstream fw allows udp 500,4500), on a 
dynamic.  The hub or hubs are ideally on a static. Set the hub site up as 
responder only, the remotes initiate the tunnel.  Peers are validated either by 
dynamic name or you simply allow peers sourcing from 0.0.0.0 at the hub site.

This is not limited to PF, I’ve gotten this to work on Cisco firewalls, 
routers, and other Linux based firewalls.

From: NANOG  On Behalf Of 
William Herrin
Sent: Thursday, February 10, 2022 12:02 PM
To: nanog@nanog.org
Subject: VPN recommendations?

Hi folks,

Do you have any recommendations for VPN appliances? Specifically: I need to 
build a site to site VPNs at speeds between 100mpbs and 1 gbit where all but 
one of the sites are behind an IPv4 NAT gateway with dynamic public IP 
addresses.

Normally I'd throw OpenVPN on a couple of Linux boxes and be happy but my 
customer insists on a network appliance. Site to site VPNs using IPSec and 
static IP addresses on the plaintext side are a dime a dozen but traversing NAT 
and dynamic IP addresses (and automatically re-establishing when the service 
goes out and comes back up with different addresses) is a hard requirement.

Thanks in advance,
Bill Herrin

--
William Herrin
b...@herrin.us

https://bill.herrin.us/

need commercial connection in elkton, fl

[james jones]

Anyone have coverage on county road 305 in elkton, fl 32033.If so,
please contact me off list.

-James

Re: questions about ARIN ipv6 allocation

[babydr DBA James W. Laferriere]

Hello Randy ,

On Mon, 6 Dec 2021, Randy Bush wrote:

You could transfer the resources to RIPE... :-)


been there.  done that.  2016.

"A Happy Story of Inter-RIR Transfer of Legacy Blocks from ARIN to RIPE"

https://archive.psg.com/160524.ripe-transfer.pdf
	In your slides above you mentioned '... just pay ...' ,  Most of the 
RIR's webpages (at least to me) are a warren of forward and backward references 
.
	Could you or any kind soul post a url that diffinatively defines the fee 
structure for services provided for Ripe members ?



randy


Tia ,  JimL

--
+-----+
| James   W.   Laferriere| SystemTechniques | Give me VMS |
| Network & System Engineer  | 3237 Holden Road |  Give me Linux  |
| j...@system-techniques.com | Fairbanks, AK. 99709 |   only  on  AXP |
+-+

Re: private 5G networks?

[James Jun]

On Wed, Dec 01, 2021 at 12:23:46PM +0100, Baldur Norddahl wrote:

[ snip ]

> 
> And yes these are low bandwidth but on the other hand often stretch wifi to
> the very limits on the distance between bases. I am not claiming this is
> the same use case as a warehouse. I am pointing out that the argument that
> a system critical implementation _must_ be based on licensed frequencies
> does not hold as nothing could be more critical than a system that prevents
> trains from colliding.


The public transit market of rail industry has been in discussions for a while 
re:
mitigation measures (such as licensed band) against possible interference on 
CBTC
signalling data links.  It is however a standardization issue (much like we here
in internet infrastructure continue to discuss improvements to BGP and its 
lingering
security issues, nothing is perfect in every industry I suppose..).

> 
> I do claim that the reason these metro train systems can boast of a very
> high uptime is not that it would be especially hard to jam their wifi based
> systems.

Moreover, the degree of disruption to loss of data on CBTC is further dependent 
upon
individual deployment cases.  One example is system falling back to ABS 
(non-moving
block) operation during loss of confirmations on movement authorities, with 
trains
continuing to run, albeit at reduced capacity.

Anyhow it has not been a serious enough issue from operational and security 
standpoints
to date to warrant immediate concern.  It's a standardization matter.

James

Re: private 5G networks?

[James Jun]

On Tue, Nov 30, 2021 at 05:48:28PM -0500, Shane Ronan wrote:
> Please provide details on public transit systems that are controlled via
> Wifi, I find that very interesting.
> 

He's talking about CBTC running on 2.4Ghz band for DCS.  And yes he is right, 
numerous metro subway systems use this.

For heavy rail deployments, ETCS Level 2 uses GSM-R.


James

Re: Validating multi-path in production?

[James Bensley]

On Fri, 12 Nov 2021 at 16:54, Adam Thompson  wrote:

> The best I've come up with so far is to have two test systems (typically
> VMs) that use adjacent IP addresses and adjacent MAC addresses, and test
> both inbound and outbound to/from those, blindly trusting/hoping that
> hashing algorithms will *probably* exercise both paths.
>

If the goal is to test that traffic *is* being distributed across multiple
links based on traffic headers, then you can definable roll your own. I
think the problem is orchestrating it (feeding your topology data into the
tool, running the tool, getting the results out, and interpreting the
results etc).

A coupe of public examples:
https://github.com/facebookarchive/UdpPinger
https://www.youtube.com/watch?v=PN-4JKjCAT0

If you do roll your own, you need to taylor the tests to your topology and
your equipment. For example, you can have two VMs as you mentioned, each at
opposite ends of the network. Then, if your network uses a 5-tuple for ECMP
inside the core for example, you could send many flows between the two VMs,
rotating the sauce port for example, to ensure all links in a LAG or all
ECMP paths are used.

It's tricky to know the hashing algo for every type of device you have in
your network, and for each traffic type for each device type, if you have a
multi vendor network. Also, if your network carries a mix of IPv4, IPv6,
PPP, MPLS L3 VPNs, MPLS L2 VPNs, GRE, GTP, IPSEC, etc. The number of
permutations of tests you need to run and the result sets you need to
parse, grows very rapidly.

Cheers,
James.

Re: verizon fios, northeast, routing issues?

[James Jun]

> On Sat, Oct 9, 2021, 13:45 Miles Fidelman 
>
>
> 2. origin - alter.net - level.3 - endpoint is just bizarre, one would
> think that the regional FIOS network has a direct connection to level.3

No.  Former verizon-gni backbone (where FiOS sits) takes transit solely from 
VZB (now UUNET), 
this has been the case for many many years, but most people get confused when 
interpretting
traceroutes due to mpls no-ttl-propagate on VZ networks.


> (it also seems kind of odd that the packets are flowing from Acton MA,
> to Boston, and back out to Marlboro MA - there's an awful lot of fiber
> running along Rt. 495, and the networks are fairly dense around here)

Level3-VZB-px is at 300 Bent Street, Cambridge, MA, where both parties have 
peering routers installed
(bear1.Boston1.Level3.net and BR1.BOS30.ALTER.NET).  It makes perfect sense for 
interconnection to occur
in Cambridge/Boston, rather than maintaining peering routers out in the suburb 
within the same metro.


None of these are contributory factors to the issues you're describing.

James

Anyone else expereincing phone line issues from west to east ?

[babydr DBA James W. Laferriere]

Hello All ,  Anyone else expereincing phone line issues from west to 
east ?
Just tried calling back east and not even a all lines are busy signal .

Tia ,  JimL
--
+-+
| James   W.   Laferriere| SystemTechniques | Give me VMS |
| Network & System Engineer  | 3237 Holden Road |  Give me Linux  |
| j...@system-techniques.com | Fairbanks, AK. 99709 |   only  on  AXP |
+-+

Re: IPv6 woes - RFC

[James R Cutler]

On Sep 25, 2021, at 8:44 PM, Valdis Klētnieks  wrote:
> 
> On Sat, 25 Sep 2021 23:20:26 +0200, Baldur Norddahl said:
> 
>> We should remember there are also multiple ways to print IPv4 addresses.
>> You can zero extend the addresses and on some ancient systems you could
>> also use the integer value.
> 
> 19:17:38 0 [~] ping 2130706433
> PING 2130706433 (127.0.0.1) 56(84) bytes of data.
> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.126 ms
> 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.075 ms
> 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.063 ms
> 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.082 ms
> ^C
> --- 2130706433 ping statistics ---
> 4 packets transmitted, 4 received, 0% packet loss, time 84ms
> rtt min/avg/max/mdev = 0.063/0.086/0.126/0.025 ms
> 
> Works on Fedora Rawhide based on RedHat, Debian 10, and Android 9.
> 
> That's a bit more than just 'some ancient systems' - depending whether
> it works on other Android releases, and what IoT systems do, we may have
> more systems today that support it than don't support it.

It also works on this 'ancient' macOS Monterey system.

Last login: Sat Sep 25 20:50:00 on ttys000
xz4gb8 ~ % ping 2130706433
PING 2130706433 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.047 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.111 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.103 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.109 ms
^C
--- 2130706433 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.047/0.092/0.111/0.026 ms
xz4gb8 ~ % 

Re: VoIP Provider DDoSes

[james jones]

Brandon,

Actually, i work for a company that just purchased a start up that deals
with DDOS for WebRTC, Websockets and grpc.

Mike,

I could see that, especially since HTTP 3.0 is UDP.

On Tue, Sep 21, 2021 at 9:47 PM Brandon Svec via NANOG 
wrote:

> Never heard of that one. WebRTC is maybe easier to protect from DDOS?
>
> Brandon
>
> > On Sep 21, 2021, at 5:37 PM, Michael Thomas  wrote:
> >
> > Which makes SIPoHTTP an inevitability.
> >
> > Mike
>

Re: Voice Middleware

[james jones]

Owen,

Do you mean this
https://www.voip-info.org/asterisk-how-to-connect-to-metaswitch/?
I am not sure that is what he is looking for, but it could be. It has been
a while for me as well :)

Mike,

Could you give a little more context in what you are trying to do? Are you
looking for something that can manage all those devices via their web APIs?

-James

On Fri, Sep 10, 2021 at 12:39 PM Owen DeLong via NANOG 
wrote:

> I don’t know the current state, but I believe Asterisk was going down that
> road for a while.
>
> Owen
>
>
> On Sep 10, 2021, at 05:26 , Mike Hammett  wrote:
>
> Before we build something from scratch, are there platforms that do the
> heavy lifting of talking to the Metaswitch API, Peerless's API, various LSR
> APIs, etc.?
>
> I mean this for provisioning purposes.
>
>
>
> -
> Mike Hammett
> Intelligent Computing Solutions
> http://www.ics-il.com
>
> Midwest-IX
> http://www.midwest-ix.com
>
>
>

Re: Outbound Route Filtering (ORF) vendor support

[james jones]

PCRE or death. Tell me if I am wrong, but I thought PCRE was the most widely 
used regex lib these day anyways. I also thought it was already in Junos.

Sent from my iPhone

> On Aug 19, 2021, at 7:56 AM, Jeffrey Haas  wrote:
> 
> ORFs are a challenging feature and haven't gotten a lot of deployment for a 
> number of reasons.
> 
> At a high level, they're a very coarse filter.  Since each new ORF type adds 
> to the logical AND condition, you start having to be more and more permissive 
> in what you permit in the policy.  Since a significant amount of common ISP 
> policies require matching things in tuples, this doesn't translate super well 
> into many types of automatically generated ORFs.
> 
> The ext-community-orf feature was effectively supplanted by Rt-Constrain (RFC 
> 4684).
> 
> The as-path ORF was challenging because different vendors have different 
> ideas about what "regex" means and what the input tokens are.  Consider for 
> example Juniper vs. Cisco regex matching.  The abstract fix would have been 
> to define a regex that is for the feature.  I half suspect if people pushed 
> on this these days, they'd want PCRE. :-)
> 
> The RD-ORF work is part of some ongoing discussion about how to deal with VRF 
> overwhelm (prefix-limit exceed).
> 
> -- Jeff (IDR co-chair)
> 
>> On Aug 18, 2021, at 1:10 PM, Douglas Fischer  
>> wrote:
>> 
>> Hello!
>> 
>> I also found a recent draft(expires Novembre 2021) about using Route 
>> Distinguisher as a Value on ORF.
>> https://datatracker.ietf.org/doc/draft-wang-idr-rd-orf/
>> 
>> 
>> 
>> 
>> Em qua., 18 de ago. de 2021 às 11:41, Humberto Galiza 
>>  escreveu:
>>> Hi,
>>> 
>>> Is anyone aware of any vendor that supports Outbound Route Filtering
>>> (ORF) based on anything other than prefix-lists?
>>> 
>>> I found these two old IETF drafts (both expired :-/) which supported
>>> the idea of filtering based on community and as-path respectively, but
>>> I wasn't able to understand if they were ever discussed at the WG and
>>> if there was any outcome of the discussion (I suspect the authors are
>>> no longer even working with the mentioned companies in the drafts):
>>> 
>>> - https://datatracker.ietf.org/doc/html/draft-chen-bgp-ext-community-orf-02
>>> - https://datatracker.ietf.org/doc/html/draft-ietf-idr-aspath-orf-13
>>> 
>>> Any info is very much appreciated.
>>> 
>>> Thanks,
>> 
>> 
>> -- 
>> Douglas Fernando Fischer
>> Engº de Controle e Automação
> 

Where to get IPv4 block these day

[james jones]

hey everyone,

Been a while since I had to deal with NetOps stuff. Was wondering, where do
you go these days to get IPv4 blocks? It seems like getting assignments is
hard due to exhaustion. I have found some "Auction" sites but it all feels
very scammy. Any info would be appreciated.


-James

aggregation tool that allows a bit of fuzz to aggregating ?

[babydr DBA James W. Laferriere]

	Hello All ,  google foo isn't pulling up anything but drivel about ip 
aggregation in cisco and describing the word 'fuzz' .


	I am looking for a tool such as 'aggregate' ,  this one is written in 
c .  Which has been a very good tool to me .


	I use this tool to aggregate ip addresses snagged out of various logs to 
insert into iptables filtering .  Again the afore mentioned tool has work well .


	But now I am seeing a new trick fro some entities that are transmitting 
from every other ipv4 address such as (*) below .  And the trust (& crusty) 
ol'tool just doesn't allow for a bitt of fuzz in its aggregation filter .


	Hoping someone knows of such a tool and or may have patched the 
aggregate tool to accopmlish such a task .


(*)
...
63.81.88.116/32
63.81.88.118/32
63.81.88.120/32
63.81.88.122/32
63.81.88.124/32
63.81.88.126/32
...

Tia ,  JimL

--
+-+
| James   W.   Laferriere| SystemTechniques | Give me VMS |
| Network & System Engineer  | 3237 Holden Road |  Give me Linux  |
| j...@system-techniques.com | Fairbanks, AK. 99709 |   only  on  AXP |
+-+

Re: DANE of SMTP Survey

[babydr DBA James W. Laferriere]

Hello Mr. Tinka & Mr. Andrews ,  Please see below .

On Thu, 3 Jun 2021, Mark Tinka wrote:

On 6/3/21 00:25, babydr DBA James W. Laferriere wrote:


The Below is to keep thread of thought accurate ...

On Wed, 2 Jun 2021, Mark Tinka wrote:

* Step 2 - take your time cluing up on getting your zone signed, and
 being part of the solution toward a more secure Internet. No
 pressure, at your pace.




Again ,  Will this handle the case of self-signed only ?


Not sure I understand your question, in both cases of recursion and 
authoritative.


	The Signing of the 'Zone' ,  Can the 'Zone' be signed by a self-signed 
key ?  Or MUST I (and others) rely on a external certificate authority ?


Mind you I notice in rfc6487 (note(s)) about self-signed certificates .
	So Maybe I am being a bit over worried about having to spend more money 
just to keep my 2 ip-ranges routing in light of the RPKI initative(s) .


Which Mr. Andrews response below answers quite succinctly ,

On Thu, 3 Jun 2021, Mark Andrews wrote:

DANE works with self generated CERTs.  The TLSA record provides the 
cryptographic link back to the DNSSEC root.


Thank You Mr. Andrews ,  Muchly . Is what I was hoping for .

Thank You Both .  JimL
--
+-+
| James   W.   Laferriere| SystemTechniques | Give me VMS |
| Network & System Engineer  | 3237 Holden Road |  Give me Linux  |
| j...@system-techniques.com | Fairbanks, AK. 99709 |   only  on  AXP |
+-+

Re: DANE of SMTP Survey

[babydr DBA James W. Laferriere]

Hello Mark ,

On Wed, 2 Jun 2021, Mark Tinka wrote:

On 6/2/21 11:07, Jeroen Massar via NANOG wrote:

As for solutions: better education, more improvements to the tools & making 
it easier. CDS records already help a lot. But we might also need to 
improve recovery mechanisms, as f-ups are made, and you don't want to be 
off this Internet thing for too long.


I think DNSSEC implementation needs to be made less scary for folk who are 
apprehensive, and broken down into two steps, where step 1 is most 
emphasized:


* Enable DNSSEC on your resolvers. Does not require you to sign your
  zones. Does not require you to read up on what it takes to sign and
  maintain your zones. Does not require you to worry and test for the
  next 60 days whether DNSSEC will break your e-mail delivery, e.t.c.:

         dnssec-enable yes;
 dnssec-validation auto;

        Done! Two lines (BIND, in this case), and off you go.


Will this handle the case of self-signed only ?
	And as Jeroen Massar mentioned the resignation of a certificate is a tad 
troubles some for both DNSSEC & DANE .



* Step 2 - take your time cluing up on getting your zone signed, and
  being part of the solution toward a more secure Internet. No
  pressure, at your pace.


Again ,  Will this handle the case of self-signed only ?


Mark.

Tia ,  JimL
--
+-+
| James   W.   Laferriere| SystemTechniques | Give me VMS |
| Network & System Engineer  | 3237 Holden Road |  Give me Linux  |
| j...@system-techniques.com | Fairbanks, AK. 99709 |   only  on  AXP |
+-+

Re: Tier1 BGP filter generation data sources & frequency

[babydr DBA James W. Laferriere]

Hello Jon ,

On Mon, 24 May 2021, Jon Lewis wrote:

On Mon, 24 May 2021, Job Snijders via NANOG wrote:


On Mon, May 24, 2021 at 02:04:32PM -0400, Luca Salvatore wrote:

Curious if anyone is aware of other Tier1s deprecating support for RADB?


Rather than deprecating RADB, I think the industry would be better off
if either RADB or the Tier1s (in their local caching layer) deploy IRR
database software capable of RPKI Origin Validation ala RIPE-731.


I suspect the attitude is "why bother when we can just require that everyone 
use the IRR run by their RIR, rely on the RIR to not allow bogosity in thier 
IRR, and keep using our existing software, just limiting the IRR sources from 
which it'll accept objects?"


	While I am not a big player (or even a bump in the road) in this group I 
do find it rather odd that people & corporate entities allow (& sponsor) 
another grab at ,  imo ,  taking over the proper way we as players in this 
arena should be working WITH each other .  The "just leave it to big brother" 
is just plain a cop out to laziness (agn imo) .


Sorry I'll say no more on the above as I'd just rant .


BTW...speaking of MANRS, if there's someone on-list who can help out with 
some questions, I'd appreciate the contact.  For $work, I'd been talking to 
Kevin Meynell about our joining.  It fell through the cracks and recently 
popped back up.  Recent email to Kevin got no reply.  The MANRS web site 
could use quite a bit of clarification (or maybe just toss it and start 
over).


	To be honest the manrs site left me feeling rather blase' ,  The place 
that interested me is the Implementation Guide .  Which seems to be a compendium 
of the [RFC|BCP]'s of the Proper way to maintain records at and with the entity 
that dispenses the resource(s) being used .



Also, I'm curious how common it is for networks to build IRR-based 
prefix-list filters for all their peers (i.e. IX peers, where you have lots 
of peers)?


--
Jon Lewis, MCP :)   |  I route
StackPath, Sr. Neteng   |  therefore you are
_ http://www.lewis.org/~jlewis/pgp for PGP public key_



Twyl ,  Back to silent mode .  JimL
--
+-----+
| James   W.   Laferriere| SystemTechniques | Give me VMS |
| Network & System Engineer  | 3237 Holden Road |  Give me Linux  |
| j...@system-techniques.com | Fairbanks, AK. 99709 |   only  on  AXP |
+-+

Re: Zayo or HE for IP transit

[James Jun]

On Tue, Apr 20, 2021 at 04:28:12PM +, Luke Guillory wrote:
> No issues with HE, only gripe was that if you had transit along with IX 
> peering, traffic will always prefer transit over IX ports.
> 
> 

That's how it's supposed to work, and is not specific to HE.

Customer routes > peer routes

Most providers wouldn't allow simultaneous peer + customer relationship, but in 
this case, I would argue that HE is doing you a favor by leaving your 
settlement-free peering adjacency in place, for you to dump outbound traffic 
toward their customers for free.

James

Zayo or HE for IP transit

[James Lumby]

What is the current experience with Zayo or HE?  I'm looking at possibly adding 
one of them into a mix of cogent and a mix from my datacenter.  Would be using 
BGP full routes.  Any experiences would be appreciated.

Sincerely,
James

Re: wow, lots of akamai

[james jones]

On Thu, Apr 1, 2021 at 11:16 AM Töma Gavrichenkov  wrote:

> Peace,
>
> On Thu, Apr 1, 2021, 6:09 PM  wrote:
>
>> That was a lot of traffic coming out of akamai aanp clusters the last
>> couple nights!  What was it?
>>
> "Call of Duty" update again, obviously.
>
>
> https://www.eurogamer.net/articles/2021-03-29-this-weeks-call-of-duty-warzone-update-is-over-50gb
>
> --
> Töma
>

HAHA

Re: Is there an established method for reporting/getting removed a company with 100% false peeringdb entries?

[James Breeden]

Yeah, I know a couple of people who have thrown massive peeringdb operations up 
just to make them look big but their routing table analysis looks nothing like 
what they say they have.


James W. Breeden

Managing Partner



[cid:3c34773f-9c3e-42cf-87ba-144ee1fa163f]

Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media | Atheral 
| BlueNinja

PO Box 1063 | Smithville, TX 78957

Email: ja...@arenalgroup.co<mailto:ja...@arenalgroup.co> | office 512.360. 
| cell 512.304.0745 | www.arenalgroup.co<http://www.arenalgroup.co/>
Executive Assistant: Chelsea Nichols: chel...@arenalgroup.co | 737.302.8742


From: NANOG  on behalf of Eric 
Kuhnke 
Sent: Thursday, March 4, 2021 6:14 PM
To: nanog@nanog.org list 
Subject: Is there an established method for reporting/getting removed a company 
with 100% false peeringdb entries?

First, take a look at this:

https://www.peeringdb.com/asn/18894


Now look at these (or use your own BGP table analysis tools):

https://bgp.he.net/AS18894

https://stat.ripe.net/18894

The claimed prefixes announced, traffic levels and POPs appear to have no 
correlation with reality in global v4/v6 BGP tables.

It is also noteworthy that I have inquired with a number of persons I know who 
are active in network engineering in NYC, and nobody has ever encountered this 
company.

Roblox Security and Saftey

[james jones]

Need a contact for Security and Safety at Roblox.

Re: Parler

[james jones]

God I miss that man!

On Wed, Jan 13, 2021 at 11:28 PM Jay R. Ashworth  wrote:

> - Original Message -
> > 2. Where do we expect legit insurrections to communicate?  Should
> > AWS/Facebook/Twitter boot those calling for violent uprisings in Hong
> Kong
> > (for example).
> >
> > I suppose #2 is simply one mans freedom fighter is another criminal.
>
> https://youtu.be/isMm2vF4uFs?t=281
> --
> Jay R. Ashworth  Baylink
> j...@baylink.com
> Designer The Things I Think   RFC
> 2100
> Ashworth & Associates   http://www.bcp38.info  2000 Land
> Rover DII
> St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647
> 1274
>

Looking for alternate providers

[james jones]

Greetings,

Looking for upstream alternatives in Ayer, MA (01432). Need a gigabit link.
Can be async but needs to be at least 35Mb up.

Comcast need not apply.

-James

Unimus Network Automation https://unimus.net/

[James Braunegg]

Dear All

Anyone using Unimus for Network Automation ? https://unimus.net/

i.e. mass configuration / push / pull configurations looking for something more 
powerful than rconfig for a Cisco Nexus and Juniper environment.

And or happy with any other suggestions

Kindest Regards

James Braunegg



[cid:image001.png@01D280A4.01865B60]

1300 769 972 / 0488 997 207

ja...@micron21.com<mailto:ja...@micron21.com>

www.micron21.com/<http://www.micron21.com/>


[cid:image002.png@01D280A4.01865B60]<http://www.micron21.com/>


[cid:image003.png@01D280A4.01865B60]<https://www.facebook.com/micron21/>

[cid:image004.png@01D280A4.01865B60]<https://twitter.com/micron21>

Follow us on Twitter<https://twitter.com/micron21> for important service and 
system updates.


This message is intended for the addressee named above. It may contain 
privileged or confidential information. If you are not the intended recipient 
of this message you must not use, copy, distribute or disclose it to anyone 
other than the addressee. If you have received this message in error please 
return the message to the sender by replying to it and then delete the message 
from your computer.

Re: 10g residential CPE

[James R Cutler]

On Dec 29, 2020, at 11:53 AM, Michael Thomas  wrote:
> 
> On 12/29/20 8:42 AM, Aaron Wendel wrote:
>> Oh, we still get calls about speed issues. It's always wonderful when 
>> someone puts their own 10 year old Linksys WRT54G and double NATs behind our 
>> CPE then sends in a speed test wondering why they're only getting 10Mbits on 
>> their Gbit line.  We get those ALL the time. :)
>> 
> Does your CPE not have wireless? If it's double NAT'ing it's at least a 
> router. If it doesn't have wireless, wouldn't it be cheaper to add it so you 
> don't get the support calls?
> 
> Mike
> 
Supplying any configurable residential CPE would not necessarily be cheaper. 
The tracking and accounting for the hardware and qualifying said hardware, not 
to mention truck rolls for hardware updates, could well be more costly than 
fielding support calls (which would likely not decrease anyway).

An intangible benefit of ‘free residential service’ is creation of good will 
far exceeding that received by many other ISPs.  
-
James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net

Announcing UKNOF46

[James Bensley]

Dear Colleagues,

We are pleased to announce UKNOF46, taking place online, on 19th
January followed by an online social event.

The meeting website is live and both the Call for Presentations and
Registrations are now open.


[ REGISTRATION ]

There are a limited number of Free Registration spaces - 50 in total.
Paid tickets are £50 each including VAT and the Eventbrite fee. You
may also pay extra as an add-on to your registration.

Registration is required to participate in the meeting. A recording of
the proceedings will be made available on the UKNOF YouTube channel
for viewing at a later time.

Please register via:

 <https://uknof.uk/register46>


[ CALL FOR PRESENTATIONS ]

The Programme Committee are seeking content for UKNOF46, which takes
place online, from the community for this meeting.

UKNOF's remit is "distribution of clue", and for our first meeting of
2021, we are looking for content which is both operationally timely
and our 'normal' operational remit.

The whole session is planned for 3 - 5 hours. We are looking for a mix
of formats

  * 15 or 25 minute presentations (with 5 minutes for Q)
  * 5 minute lightning talks (no Q)
  * 45 minute panel sessions

We are keen for talks and panels in these subject areas:

  * 2020 retrospective and forward looking to 2021
  * Confessions & War Stories / Lessons learnt from the field
  * Data centre design and operations
  * DNS infrastructure
  * Impact of public policy of network operations
  * IPv6 deployment
  * Network Automation and Tooling including SDN, Open Source initiatives
  * Network hardware/software/configuration architecture, design and operations
  * Open protocol standards and best practise initiatives
  * Peering and interconnection / routing.
  * Personal/Network security, inclusiveness and abuse prevention


Please submit your proposals at

 <https://uknof.uk/cfp46>

**Submissions** are welcome at any time, but for UKNOF46 we would like
to have them **no later than 7 January 2021** (We have published an
initial set of accepted talks in the "Confirmed Speakers" section on
the meeting website <https://uknof.uk/46>.


Our expected timeline is:

7 December 2020 - Submissions open via Indico
18 December 2020 - Initial Submission Deadline
22 December 2020 - Initial Contribution list published
7 January 2021 - Final Deadline for submission (23:59 GMT)
12 January 2021 - Full agenda published
13 January 2021- Deadline for slides submission and planned rehearsal date
19 January 2021 - Meeting

Information for speakers about presenting and what to expect at UKNOF
is available at <https://wiki.uknof.org.uk/Speaker_Information>

Additional information for speakers of UKNOF46:

  * your talk will be live broadcast and recorded for future reference
  * your presentation slides will be available for delegates and
others to download and refer to, before, during and after the meeting
  * you will be expected to attend a rehearsal in the week running up
to the workshop.  This has been tentatively scheduled for Wednesday 13
January. It would be very useful to have your slides (even if draft)
ready for this.

To preserve editorial neutrality, the UKNOF PC does not accept
abstract submissions for presentations by commercial organisations
that are also sponsors of the same UKNOF event. If you would like one
of our sponsored presentation slots, please contact
[spon...@uknof.org.uk]

UKNOF is run on a non-profit basis and is not in a position to
reimburse expenses or time for speakers at its meetings.

Regards
James
UKNOF Programme Committee Member

Re: Don't need someone with clue @ Network Solutions.

[James Cloos]

>>>>> "JL" == John Levine  writes:

JL> Right. When I query the .COM zone servers, they say quite clearly that
JL> there is no crocker.com glue in the .COM zone. See below.

a czds dl, however, shows:

:; zgrep -E ^dns-auth.\.crocker\.com com.txt.gz
dns-auth1.crocker.com.  172800  in  a   66.59.48.87
dns-auth2.crocker.com.  172800  in  a   66.59.48.88
dns-auth3.crocker.com.  172800  in  a   66.59.48.94
dns-auth4.crocker.com.  172800  in  a   66.59.48.95

and leaving off the ^ shows that a large number of zones use those.

-JimC
-- 
James Cloos  OpenPGP: 0x997A9F17ED7DAEA6

Re: Are the days of the showpiece NOC office display gone forever?

[James R Cutler]

> On Dec 16, 2020, at 7:25 PM, Randy Bush  wrote:
> 
>> In the traditional sense, by "showpiece NOC" I mean a room designed for the
>> purpose of having large situational awareness displays on a wall, network
>> weathermaps and charts, alerting systems, composed of four or more big flat
>> panel displays. Ideally configured to be actually useful for NOC purposes
>> and also something impressive looking for customer tours.
> 
> though your message has a current date, its content seems to be at least
> 15 years old
> 
> randy

The EDS Network Management Center, or IMS, had multiple large screens, 
shadow-free lighting, and lots of console positions and a visitor gallery with 
curtained window overlooking the operations room. We finished it right around 
1990. Right when the suburban sprawl ws starting to hit Plano. After so much 
there during construction, I was taken aback when I realized I did not 
recognize the inside the building with it’s finished walls.

That implies “at least 15 years” could well be “30 years”
.

James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net

Re: "Hacking" these days - purpose?

[James R Cutler]

The probable "purpose of obtaining illicit access to random devices on the 
Internet these days” is to create botnets to attack more lucrative targets or 
to employ them as gateway devices to provide access to local networks which may 
contain targets of interest.

James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net



> On Dec 12, 2020, at 5:26 PM, Peter E. Fry  wrote:
> 
> 
> Simple question: What's the purpose of obtaining illicit access to random 
> devices on the Internet these days, considering that a large majority of 
> attacks are now launched from cheap, readily available and poorly 
> managed/overseen "cloud" services?  Finding anything worthwhile to steal on 
> random machines on the Internet seems unlikely, as does obtaining access 
> superior (in e.g. location, bandwidth, anonymity, etc.) to the service from 
> which the attack was launched.
> 
> 
> I was thinking about this the other day as I was poking at my firewall, and 
> hopped onto the archives (here and elsewhere) to see if I could find any 
> discussion.  I found a few mentions (e.g. "Microsoft is hacking my 
> Asterisk???"), but I didn't catch any mention of purpose.  Am I missing 
> something obvious (either a purpose or a discussion of such)?  Have I lost my 
> mind entirely?  (Can't hurt to check, as I'd likely be the last to know.)
> 
> 
> Peter E. Fry
> 
> 

Re: AFRINIC IP Block Thefts -- The Saga Continues

[James R Cutler]

DELIBERATE TOP POST

It would be helpful to the NANOG list if posters could try to follow posting 
guidelines and discuss technical (not personal) topics.

James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net



> On Nov 16, 2020, at 10:04 AM, Elad Cohen  wrote:
> 
> Tom,
> 
> Until today all I wrote was facts and evidence, in the contrary to 
> Pore-spilling Ronald. When Ronald keeps defaming me here non-stop, Yes my 
> full right is to sue him, even if you prefer that my blood will be shed here 
> by his filthy soul and pores. And you can be sure that I will respond to any 
> of his defamation messages.
> 
> "No value to the community" - there is value to the community, anyone which 
> is following Pore-spilling Ronald is following the ancient snake, it is not 
> written in Old Testament, it is written in Old Scripture, go ahead and check, 
> Ronald visual appearance match one by one to the lawless one description 
> (lawless one is a term of New Testament) according to Old Scripture.
> 
> Go swim in Ronald juicy pores if you would like.
> 
> 
> From: Tom Beecher mailto:beec...@beecher.cc>>
> Sent: Monday, November 16, 2020 4:54 PM
> To: Elad Cohen mailto:e...@netstyle.io>>
> Cc: nanog@nanog.org <mailto:nanog@nanog.org>  <mailto:nanog@nanog.org>>; adm...@nanog.org <mailto:adm...@nanog.org> 
> mailto:adm...@nanog.org>>
> Subject: Re: AFRINIC IP Block Thefts -- The Saga Continues
>  
> I would like to formally request that Mr. Cohen's privileges to post to this 
> list be revoked, or otherwise curtailed.
> 
> It's one thing to dispute facts with evidence, or generally disagree on a 
> topic. However , threats of legal action and personal attacks citing Old 
> Testament mumbo jumbo, while creative, provide no value to the community. 
> 
> As Mr. Herrin stated well, we are all swimming in enough nutter butter 
> conspiracy theory nonsense every day. I hope we don't normalize it here too. 
> 
> On Mon, Nov 16, 2020 at 4:24 AM Elad Cohen  <mailto:e...@netstyle.io>> wrote:
> 
> If AfriNIC says your "purchases" are misappropriation you'll have to do a lot 
> better than conspiracy theories and phrenology in counter argument.
> 
> 
> Why are you using the word "purchases" with quotation marks, it seems that 
> you are a victim of your next paragraph, and I'm writing it with all due 
> respect.
> 
> Did I start legal proceedings with AfriNIC with conspiracy theories or with 
> facts and data?
> 
> Phrenology (and racism) is the field of Coconut Guilmette, according to his 
> own quotes right here in Nanog.
> 
> "If AfriNIC says" - AfriNIC, nor Spamhaus, nor Ops-Trust, nor MyBroadband, 
> are not the word of god and are not above law and justice.
> 
> To remind to everyone: AfriNIC filed a police complaint on themselves. And 
> AfriNIC CEO lied to the community in the following link when he wrote that I 
> was given a chance to respond when in reality all my emails were ignored. And 
> AfriNIC CEO is intentionally hiding from the community that any AfriNIC 
> policy is applied also to any legacy netblock that even don't have a signed 
> RSA (according to the legal proceedings against AfriNIC, and in contradiction 
> to AfriNIC "Legacy Resource Holders" webpage: 
> https://afrinic.net/membership/legacy-resource 
> <https://afrinic.net/membership/legacy-resource> ), it have implications on 
> each and every legacy resource holder all over the world (that a RIR can just 
> delete a legacy netblock).
> 
> https://lists.afrinic.net/pipermail/community-discuss/2020-January/003458.html
>  
> <https://lists.afrinic.net/pipermail/community-discuss/2020-January/003458.html>
>  - "We are also ensuring that the current holder/contact of the resources are 
> provided with the opportunity of proving their ownership."
> 
> 
> Besides the above, AfriNIC also have a financial motive in their actions, 
> approximately up to more $4M per year from assets that they illegaly and 
> unjustifiably took from me (by sub-allocating them to AfriNIC members), while 
> writing lies to their community and playing a long with the "community 
> pressure" game.
> 
> 
> I find the actions of AfriNIC to be very dangerous, because they are not 
> based on facts and data and law and justice, but only on community pressure. 
> Any network operator, that can elevate himself/herself from bad habits (like 
> enjoying seeing blood spilled and jealousy), would know that today it is me 
> but tomorrow it can be you.
> 
> 
> 
> From: NANOG  <mailto:netstyle...@nanog.org>> on behalf of William Herrin  <

Re: Linux router network cards

[james jones]

I wonder if they are going to get CUDA cores on the next version since they
are owned by NVIDIA now. That would be a powerful little package.


On Wed, Oct 21, 2020 at 1:42 AM Raymond Burkholder 
wrote:

> On 2020-10-20 22:37, Philip Loenneker wrote:
> > Take a look at the Mellanox ConnectX 5 series of cards. They handle
> DPDK, PVRDMA (basically SR-IOV that allows live migration between hosts),
> and can even process packets within the NIC for some models. They did a
> fantastic presentation at AusNOG 2019 which showed off a lot of the
> features. We tried some out with Vmware and could get 20Gbps throughput
> (limited by the 2x 10G NICs we had configured) to a VM running Linux with
> DPDK+VPP.
>
> Plus Mellanox introduced the SwitchDev capability which provides for
> offloading flow management to the hardware.
>

Re: Cogent Layer 2

[James Jun]

On Wed, Oct 14, 2020 at 10:54:49AM -0700, Ryan Hamel wrote:
> 
> One would think that with 100GE interfaces, it would not be possible to 
> overrun the interface if we allowed full 10Gbps/flow, however most 100GE 
> interfaces, at the chip level are broken down into 10Gbps lanes and the 
> interfaces do not have a way to easily determine that a lane through the 
> interface is at capacity, so as new flows enter the interface, they could get 
> allocated to a lane that is already full and therefore experience packet loss.

This does raise an interesting point regarding ASR9K platform.  IIRC, older 
Typhoon/NP4c 100GE cards (e.g. Juggernaut A9K-2X100GE-TR) had problems where on 
a 100GE port, you can't sustain more than 10-12 Gbps per individual flow.  You 
had to hash to achieve aggregate bandwidth, which became a significant issue if 
you were trying to transport 10G L2 pseudowires with limited flow visibility.

I'm not aware that it is an issue any longer on newer Tomahawk/NP5c cards?

James

Re: Passive Wave Primer

[James Jun]

On Tue, Oct 13, 2020 at 12:27:44PM +, Rod Beck wrote:
> Dear Network Gurus,
> 
> Looking for a tutorial on passive waves. How it works. Pros and cons. .
>

Essentially, you're providing a channel off of your DWDM filters for someone 
else to pass light.

Commonly in the market, a "wavelength" product generally isn't a true 
wavelength, especially on long-haul segments.
The 'wavelength' market really is an evolution of the old SONET market in some 
ways -- carriers will typically light a channel (either in fixed grid filter or 
flex grid) and that single channel is usually an X-gigabaud (e.g. 35-95Gbd) 
that uses coherent modulation on line side for say 200-800Gbps and multiplexing 
for tributary channels (such as TDM) on client side ports to break away a 100GE 
circuit for the customer end-user.

As far as technicalities are concerned, most 'wavelength' products that behave 
as described above, ought to be called "dedicated circuits" or 
"circuit-switched transport" if we're anal about its operating principles.

As for 'true' wavelength service, that brings us to your question:

When you're talking about passive wave or 'alien wave', what you're doing is 
you're providing a wavelength frequency assignment on your photonic filter 
system (a channel on your 100 Ghz fixed grid DWDM filter, or bandwidth 
assignment window on your flex grid ROADM) to the customer, which would 
typically be another network provider, or a very clued enterprise customer that 
wants to run his own optical transport but can't justify the economics of full 
dark fiber over the said span, and doesn't need more than <=95Gbd max of 
modulation bandwidth.

The customer would pass traffic similarly to how you yourself would light a 
channel, installing a coherent transponder for 200-800Gbps wave facing the line 
side, and breaking it out to Nx100GE for end-user traffic.

James 
 

Re: telia selling carrier ops to polhem infra

[James Breeden]

Still smells Swedish to me. Probably will end up with a different name, but 
other than that I don't see much changing. Sounds more like a spinoff than 
acquisition.


James W. Breeden

Managing Partner



[cid:0fd85346-f2b0-4a58-b98a-468c53bb9ef8]

Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media | Atheral 
| BlueNinja

PO Box 1063 | Smithville, TX 78957

Email: ja...@arenalgroup.co<mailto:ja...@arenalgroup.co> | office 512.360. 
| cell 512.304.0745 | www.arenalgroup.co<http://www.arenalgroup.co/>
Executive Assistant: Chelsea Nichols: chel...@arenalgroup.co | 737.302.8742


From: NANOG  on behalf of 
aar...@gvtc.com 
Sent: Tuesday, October 6, 2020 9:36 AM
To: Nanog@nanog.org 
Subject: telia selling carrier ops to polhem infra


I wonder how this will affect those who have Telia as an upstream Internet 
provider?  Will it be business as usual and just different company name?  Or 
maybe other changes to come?



Telia Company today (10-06-2020) announces that it has reached an agreement 
with Polhem Infra for the sale of its international carrier business, Telia 
Carrier...

https://www.teliacompany.com/en/news/press-releases/2020/10/telia-company-reaches-agreement-to-sell-its-carrier-operation-to-polhem-infra-and-proposes-to-reinstate-the-original-dividend-for-2019/







Aaron

aar...@gvtc.com

Re: SRv6

[James Bensley]

On 19 September 2020 03:23:15 BST, Randy Bush  wrote:
>> Information can be in plaintext and private
>
>Three can keep a secret, if two of them are dead.  -- franklin
>
>i know you truely believe the tunnel k00laid.  the security
>community does not.

Hi Randy,

I'm not sure what you're saying here, I never said MPLS VPNs are secure, only 
private. I hope others recognise that they are different concepts.

Cheers,
James.

Re: SRv6

[James Bensley]

On 16 September 2020 22:38:38 CEST, Randy Bush  wrote:
>> Privacy != encryption.
>
>cleartext == privacy * 0
>
>cleartext * complexity == privacy * 0

False. Cleartext and privacy are two different things which are not mutually 
exclusive. Information can be in plaintext and private, it can also be 
encrypted and not private.

Consider multiple devices connected to a single customer instance (A) on an 
MPLS L2 VPN provider's network, consisting of a single VLAN/broadcast domain, 
all the connected devices are able to send information to each other, and they 
can receive the information sent to other devices not intended for itself. Any 
device, for example, can send a gratuitous ARP, update the control plane of the 
switch and pull traffic towards itself and have visibility of all the 
conversation on the VLAN/broadcast domain. Even if the conversations are 
encrypted, meaning no plaintext, which you seem to suggest means privacy, this 
receiving device sees all the conversations which take place, when they are 
taking place, between whom, for how long, how often, and so on. Encryption 
hasn't provided privacy if someone can see all that information.

Now consider a second customer (B) connected to a separate customer instance on 
the same L2 VPN provider network. Customer A can send any traffic they like and 
they can listen all day until the cows come home; they will never be able to 
send traffic to a customer B device in a separate L2 VPN instance, and they 
will never receive any traffic from a customer B device, they can't even see 
that customer B exists, if they are having any conversations, when, for how 
long etc, nothing.

That is privacy, which is completely different to plaintext and ciphertext.

Cheers,
James

Re: SRm6 (was:SRv6)

[James Bensley]

On 17 September 2020 11:05:24 CEST, Saku Ytti  wrote:
>On Thu, 17 Sep 2020 at 11:03, James Bensley 
>wrote:
>
>> MPLSoUDP lacks transport engineering features  like explicit paths,
>FRR LFA and FRR rLFA, assuming only a single IP header is used for the
>transport abstraction [1]. If you want stuff like TI-LFA (I assume this
>is supported in SRm6 and SRv6, but I'm not familiar with these, sorry
>if that is a false assumption) you need additional transport headers or
>a stack of MPLS labels encapped in the UDP header and then you're back
>to square one.
>
>One of us has confusion about what MPLSoUDP is. I don't run it, so
>might be me.
>
>SPORT == Entropy (so non-cooperating transit can balance)
>DPORT == 6635 (NOT label)
>Payload = MPLS label(s)
>
>Whatever MPLS can do MPLSoUDP can, by definition, do. It is just
>another MPLS point-to-point adjacency after the MPLSoUDP
>abstraction/tunnel.

Nope, we have the same understanding. But the email I was responding to was 
talking about using MPLSoUDP for service label encapsulation *only*, not 
transport & services labels:


>>  If you want an IPv6 underlay for a network offering VPN services 
>
> And what's wrong again with MPLS over UDP to accomplish the very same with 
> simplicity ? 
>
> MPLS - just a demux label to a VRF/CE
> UDP with IPv6 header plain and simple 
> 
> + minor benefit: you get all of this with zero change to shipping hardware 
> and software ... Why do we need to go via decks of SRm6 slides and new wave 
> of protocols extensions ???


Cheers,
James.

Re: SRm6 (was:SRv6)

[James Bensley]

On 16 September 2020 23:51:03 CEST, Robert Raszuk  wrote:
>Hi Ron,
>
>>  If you want an IPv6 underlay for a network offering VPN services
>
>And what's wrong again with MPLS over UDP to accomplish the very same
>with
>simplicity ?
>
>MPLS - just a demux label to a VRF/CE
>UDP with IPv6 header plain and simple
>
>+ minor benefit: you get all of this with zero change to shipping
>hardware
>and software ... Why do we need to go via decks of SRm6 slides and new
>wave
>of protocols extensions ???
>
>Best,
>Robert.
>
>

>>
>>
>> Please consider the TE mechanism described in
>> draft-bonica-6man-comp-rtg-hdr and the service labeling mechanism
>described
>> in draft-bonica-6man-vpn-dest-opt. These can be deployed on a mix and
>match
>> basis. For example can deploy:
>>
>>
>>
>>- Draft-bonica-6man-vpn-dest-opt only, allowing traffic to follow
>the
>>least-cost path from PE to PE.
>>- Deploy draft-bonica-6man-vpn-dest-opt only, using a legacy
>method
>>(VXLAN, RFC 4797) to label services.
>>
>>
>>
>> In all cases, the semantic of the IPv6 address is unchanged. There is
>no
>> need to encode anything new in the IPv6 address.

MPLSoUDP lacks transport engineering features  like explicit paths, FRR LFA and 
FRR rLFA, assuming only a single IP header is used for the transport 
abstraction [1]. If you want stuff like TI-LFA (I assume this is supported in 
SRm6 and SRv6, but I'm not familiar with these, sorry if that is a false 
assumption) you need additional transport headers or a stack of MPLS labels 
encapped in the UDP header and then you're back to square one.

Cheers,
James.

[1] I'm interested to hear if anyone has done any large scale MPLSoUDP work. 
Did you hack in this functionality with static egress interface entries/static 
routes pushed from a central controller for specific IPs reserve as "path" IPs?

Re: SRv6

[James Bensley]

On Tue, 15 Sep 2020 at 19:14, Randy Bush  wrote:
>
> > I'm still learning, but, It does seem interesting that the IP layer
> > (v6) can now support vpn's without mpls.
>
> as the packet payload is nekkid cleartext, where is the P in vpn?

Define "privacy". In the kind of VPN I think you're suggesting (e.g.
an IPSEC based VPN) they implement the classic CIA acronym
(Confidentiality, Integrity and Authentication, with the "C"
essentially meaning "encrypted" in practice however, privacy requires
all three of "CIA", encryption alone isn't privacy). "VPN" is not
mutually dependent on "CIA", the two things can and do exist
separately.

WIth MPLS L3 VPNs for example, the traffic isn't encrypted, but by
creating a layer of abstraction (at the control plane, by signalling
via MP-BGP using RDs and RTs, and at the forwarding plane by using
MPLS tunneling) a customer's routing data and forwarding data is kept
private (not encrypted!) from my physical infa forwarding- and
control-planes, and from each other L3 VPN customer on my infra [1].

In fact, the point that customer (control- and forwarding-plane) data
is kept private from MY INFRA, is *the* fundamental aspect of MPLS L3
VPNs; they wouldn't scale at all without it. Privacy != encryption.

Cheers,
James.

[1] This doesn't mean there aren't security flaws in MPLS (there are,
but there are in things like IPSEC too), and "how secure" it is, is a
separate subject.

Re: SRv6

[James W. Laferriere]

Hello All ,

On Tue, 15 Sep 2020, Mark Tinka wrote:


On 15/Sep/20 11:53, Saku Ytti wrote:


I think SRv6 is an
abomination, it is complex SW, and very complex HW, because it exists.
We pay the premium to add HW support for it.


And that is what the vendor(s) pushing this hope operators "realize"...
that SRv6 is a complex mess that needs some kind of centralized system
to manage. But wait, the centralized system is, itself, quite complex
that no operator would dare spend time installing, commissioning or
maintaining it themselves.

So what ever shall we do, as operators?

Simple, pay the vendor(s) to take care of all of it for you... planning,
design, spec'ing, bill of materials, deployment, operation and refresh
programs... lock that vendor top and bottom line in for them for the
next 10 years, while they find some other RFC to create in order to keep
the cycle going 11 years later.

Mark.


	So then here we are back at the older days of hard wired devices 
configured on site by vendor 'X' to do what buyer 'Y' was told it would do .
	And Buyer 'Y' is still wondering WHEN it will be that kitchen sink it 
ordered .


Twyl ,  JimL

--
+-----+
| James   W.   Laferriere| SystemTechniques | Give me VMS |
| Network & System Engineer  | 3237 Holden Road |  Give me Linux  |
| j...@system-techniques.com | Fairbanks, AK. 99709 |   only  on  AXP |
+-+

Re: Fiber Automatic Transfer Switch

[James Jun]

On Mon, Aug 17, 2020 at 02:14:13PM -0400, Tim Nowaczyk wrote:
> I am new to the world of layer-1optical failover solutions. I came across the 
> NTT-AT Intelligent Optical Switch [1] while researching products that can be 
> used to automatically switch a fiber path on link failure. Do any of you have 
> experience with this particular product? Can anyone recommend a similar 1U 
> product that can transfer an optical signal to a secondary path when 
> there???s been a break?

Essentially, all you're looking for is a 1+1 optical splitter on transmit and 
photonic switch on receive.  
Many vendors make this, including from cheap sources[1] to optical protection 
cards from big vendors[2].

I'd also recommend Huhber+Suhner (Cube Optics) - these guys can customize 
optical line protection package, we use them ourselves.

[1]:  http://www.tryincn.com/olp-optical-line-protector-card/
[1]:  https://www.fs.com/products/66010.html
[2]:  https://myriad360.com/product/ciena-ntk554ta/

James

Looking for 1G / 10G IP Transit LA

[James Braunegg]

Dear NANOG

I am looking to add another IP Transit provider to our current mix in LA for 
AS38880, with services delivered at One Wilshire (Core Site)

If you can provide IP transit services (Either a Tier 1 provider or a blended 
Tier 2 service) then please contact me off list.

BGP community support for traffic engineering is a requirement, if you want any 
more details please contact me

Kindest Regards

James Braunegg



[cid:image001.png@01D280A4.01865B60]

1300 769 972 / 0488 997 207

ja...@micron21.com<mailto:ja...@micron21.com>

www.micron21.com/<http://www.micron21.com/>


[cid:image002.png@01D280A4.01865B60]<http://www.micron21.com/>


[cid:image003.png@01D280A4.01865B60]<https://www.facebook.com/micron21/>

[cid:image004.png@01D280A4.01865B60]<https://twitter.com/micron21>

Follow us on Twitter<https://twitter.com/micron21> for important service and 
system updates.


This message is intended for the addressee named above. It may contain 
privileged or confidential information. If you are not the intended recipient 
of this message you must not use, copy, distribute or disclose it to anyone 
other than the addressee. If you have received this message in error please 
return the message to the sender by replying to it and then delete the message 
from your computer.

Re: 60ms cross continent

[james jones]

"In Theroy" -- ROFL

Don't get me wrong it would be awesome if that turns out to be the case.

On Mon, Jul 6, 2020 at 10:05 PM joe mcguckin  wrote:

> Theoretically, Starlink should be faster cross country than terrestrial
> fiber.
>
>
> Joe McGuckin
> ViaNet Communications
>
> j...@via.net
> 650-207-0372 cell
> 650-213-1302 office
> 650-969-2124 fax
>
>
>
>

Re: Devil's Advocate - Segment Routing, Why?

[James Bensley]

On Tue, 30 Jun 2020 at 22:07, Mark Tinka  wrote:
>
>
>
> On 30/Jun/20 20:37, James Bensley wrote:
>
> > Mark, does someone have a gun to your head? Are you in trouble? Blink
> > 63 times for yes, 64 times for no ;)
>
> You're pretty late to this party, mate...

True, but what's changed in two weeks with regards to LDv6 and SR?

What was your use case / requirement for LDv6 - to remove the full
table v6 feed from your core or to remove IPv4 from your IGP or both?

Cheers,
James.

Re: Devil's Advocate - Segment Routing, Why?

[James Bensley]

On Wed, 17 Jun 2020 at 23:19, Mark Tinka  wrote:
> Yes, we all love less state, I won't argue that. But it's the same question 
> that is being asked less and less with each passing year - what scales better 
> in 2020, OSPF or IS-IS. That is becoming less relevant as control planes keep 
> getting faster and cheaper.
>
> I'm not saying that if you are dealing with 100,000 T-LDP sessions you should 
> not consider SR, but if you're not, and SR still requires a bit more 
> development (never mind deployment experience), what's wrong with having 
> LDPv6? If it makes near-as-no-difference to your control plane in 2020 or 
> 2030 as to whether your 10,000-node network is running LDP or SR, why not 
> have the choice?

I'm going to kick the nest in the other direction now :D ... There
would be no need to massively scale an IGP or worry about running
LDPv4 + LDv6 or SR MPLS if we had put more development time into MPLS
over UDP. I think it's a great technology which solves a lot of
problems and I've been itching to deploy it for ages now, but vendor
support for it is nowhere near the level of MPLS over Ethernet.

Cheers,
James.

Re: Devil's Advocate - Segment Routing, Why?

[James Bensley]

On Wed, 17 Jun 2020 at 18:08, Mark Tinka  wrote:
>
> Hi all.
>
> When the whole SR concept was being first dreamed up, I was mildly excited 
> about it. But then real life happened and global deployment (be it basic 
> SR-MPLS or SRv6) is what it is, and I became less excited. This was back in 
> 2015.
>
> All the talk about LDPv6 this and last week has had me reflecting a great 
> deal on where we are, as an industry, in why we are having to think about SR 
> and all its incarnations.
>
> So, let me be the one that stirs up the hornets' nest...
>
> Why do we really need SR? Be it SR-MPLS or SRv6 or SRv6+?

I am clearly very far behind on my emails, but of the emails I've read
so far in this thread though you have mentioned at least twice:

On Wed, 17 Jun 2020 at 18:08, Mark Tinka  wrote:
> What I am less enthused about is being forced

On Wed, 17 Jun 2020 at 23:22, Mark Tinka  wrote:
> it tastes funny when you are forced

Mark, does someone have a gun to your head? Are you in trouble? Blink
63 times for yes, 64 times for no ;)

Cheers,
James.

Re: Devil's Advocate - Segment Routing, Why?

[James Bensley]

On Wed, 17 Jun 2020 at 22:09,  wrote:
>
> > From: NANOG  On Behalf Of Mark Tinka
> > Sent: Wednesday, June 17, 2020 6:07 PM
> >
> >
> > I've heard a lot about "network programmability", e.t.c.,
> First of all the "SR = network programmability" is BS, SR = MPLS, any 
> programmability we've had for MPLS since ever works the same way for SR.

It works because SR != MPLS.

SR is a protocol which describes many aspects, such as how traffic
forwarding decisions made at the ingress node to a PSN can be
guaranteed across the PSN, even though the nodes along the PSN path
use per-hop forwarding behaviour and different nodes along the path
have made different forwarding decisions.

When using SR MPLS segment IDs are used as an index into the label
range (SRGB) and so SIDs don't correlate 1:1 to MPLS labels, equally
with SRv6 the segment IDs are encoded as IPv6 addresses and don't
correlate 1:1 to an IPv6 address. There is a venn diagram with an
overlapping section in the middle which is "generic SR" with a bunch
of core features that are supported agnostic of the encoding
mechanism.

Cheers,
James.

Europe IP Transit Provider Ideas ?

[James Braunegg]

Dear Nanog

For those running a AS with multiply POP locations around the world who would 
you recommend as a strong tier 1 transit provider in Europe (good routes to 
Africa would be a bonus)

We currently take full table feeds from Telia, GTT, Cogent, Retn, tisparkle 
(Seabone) we are also looking at adding NTT in the USA and maybe also in Europe 
but any other recommendations ?

Happy to be contacted by transit providers off list, thanks in advance

Kindest Regards


James Braunegg



[cid:image001.png@01D280A4.01865B60]

1300 769 972 / 0488 997 207

ja...@micron21.com<mailto:ja...@micron21.com>

www.micron21.com/<http://www.micron21.com/>


[cid:image002.png@01D280A4.01865B60]<http://www.micron21.com/>


[cid:image003.png@01D280A4.01865B60]<https://www.facebook.com/micron21/>

[cid:image004.png@01D280A4.01865B60]<https://twitter.com/micron21>

Follow us on Twitter<https://twitter.com/micron21> for important service and 
system updates.


This message is intended for the addressee named above. It may contain 
privileged or confidential information. If you are not the intended recipient 
of this message you must not use, copy, distribute or disclose it to anyone 
other than the addressee. If you have received this message in error please 
return the message to the sender by replying to it and then delete the message 
from your computer.

NTT IP Transit

[James Braunegg]

Dear Nanog

I am looking for some NTT IP transit delivered in LA for our network AS38880, 
if you know a NTT sales rep could you please either pass on this email to them, 
and or provide me their contact details !

Thanks in advance

Kindest Regards

James Braunegg



[cid:image001.png@01D280A4.01865B60]

1300 769 972 / 0488 997 207

ja...@micron21.com<mailto:ja...@micron21.com>

www.micron21.com/<http://www.micron21.com/>


[cid:image002.png@01D280A4.01865B60]<http://www.micron21.com/>


[cid:image003.png@01D280A4.01865B60]<https://www.facebook.com/micron21/>

[cid:image004.png@01D280A4.01865B60]<https://twitter.com/micron21>

Follow us on Twitter<https://twitter.com/micron21> for important service and 
system updates.


This message is intended for the addressee named above. It may contain 
privileged or confidential information. If you are not the intended recipient 
of this message you must not use, copy, distribute or disclose it to anyone 
other than the addressee. If you have received this message in error please 
return the message to the sender by replying to it and then delete the message 
from your computer.

Re: Outsourced NOC Solutions

[James Jun]

On Mon, Jun 08, 2020 at 06:12:12PM -0400, Dave Cohen wrote:
> There is a middle ground between ???not managing customer light??? and ???not 
> managing anything??? though. The Adva ALM solution that a few folks that have 
> mentioned, along with others like Lucent SmartLGX, effectively bridge this 
> gap by helping trace the precise location of cuts and even smaller scale 
> incidents like microbends to expedite diagnosis and repair to the extent 
> possible. It???s not a panacea and definitely not a substitute for managing 
> the hardware at the endpoints, but it does improve operational responsiveness 
> in a measurable way. And yes, there are dark fiber providers in the Northeast 
> that leverage this technology, at least on some portion of their fiber 
> plants. 
>

Agreed that there is a middle ground.  Devices like these are something that 
customers can individually deploy on their lit fibers (then again, many optical
vendors now include automatic fault location (e.g. OTDR function) into their 
line interface cards with OSC add/drop filters (e.g. Ciena ESAM, etc).)

And ofcourse, I think it's great for carriers to deploy these on their own 
internal circuits for telemetry purposes and improve fault location response.

But as far as dark fiber pair that's being leased out to an end-user customer 
or another entity, I for one, do not want any carrier equipment whatsoever
on any fiber spans we obtain from another party (be it fiber swap with a 
carrier, or leased segment otherwise), full stop.   Everything else besides 
glass
is more attenuation to me, and with data center MMRs along the eway, there are 
already enough insertion losses as is.

James

Re: Outsourced NOC Solutions

[James Jun]

On Mon, Jun 08, 2020 at 08:10:44PM +, Mel Beckman wrote:
> 
> I???m not talking about a full-time engineer for the life of the network, 
> just for designing the infrastructure management before first customer light.
> 
> -mel via cell
>

Dude, it's dark fiber.

I for one, do _NOT_ in any shape or form, want my DF provider to put any 
equipment (monitoring, or otherwise) on strands I lease, period.  I just want
tubes in the ground, end of story.  This is certainly not an airplane and does 
not need a pilot.  It's passive tubes sitting on right of way and customer
is licensed to pass light thru that passive tube.  Everything else is extra, 
and I want no active service whatsoever (besides for power capacity at
regen plant colo).

If there is a disturbance event that creates LOS alarm on customer equipment, 
they will call in and open a ticket to begin troubleshooting.

Name me one dark fiber provider in northeast that (unless you buy their managed 
dark fiber solution) will monitor your fiber strands and the customer
light for you.  I can tell you, major fiber providers in northeast are all the 
same:  the customer is the monitoring system.  If fiber is down, customers
call in.  In fact, I can't recount how many times I've had dealing with a large 
fiber provider here (unnamed to protect the guilty) who also requests
and asks customers to shoot OTDR for them.

Generally speaking, dark fiber providers who also compete with their customers 
(e.g. fiber provider that sells lit services) have tendency to react
faster to certain fiber cuts on certain routes, if their backbone links are 
sitting in them.  But for specialty dark fiber providers who only sell dark,
it's not a bad idea to light one of the strands for internal continuity checks; 
but at worst case scenario, when a customer calls in to report an LOS
alarm and suspects fiber disturbance, that's usually enough information to 
start sending your crews out and begin taking traces.

James

Partial vs Full tables

[James Breeden]

I have been doing a lot of research recently on operating networks with partial 
tables and a default to the rest of the world. Seems like an easy enough 
approach for regional networks where you have maybe only 1 upstream transit and 
some peering.

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

And before I get asked why not just run full tables, I'm looking at regional 
approaches to being able to use smaller, less powerful routers (or even layer3 
switches) to run some areas of the network where we can benefit from 
summarization and full tables are really overkill.



James W. Breeden

Managing Partner



[logo_transparent_background]

Arenal Group: Arenal Consulting Group | Acilis Telecom | Pines Media

PO Box 1063 | Smithville, TX 78957

Email: ja...@arenalgroup.co<mailto:ja...@arenalgroup.co> | office 512.360. 
| www.arenalgroup.co<http://www.arenalgroup.co/>

Clueful Domain Name Expert from Network Solutions Needed

[james jones]

Greetings,

Hope everyone is staying healthy and safe. I am really looking for help
from someone clueful at Network Solutions. I am having major issues with
transferring a domain away from them. Turns out the primary contact on the
account has been the same for over a 15+ years. That person has not been
involved with the organization for decade and was never updated. I have
been getting the run around from customer service to for 4 months trying to
update the primary contact. I have provided all the information that has
been requested multiple times . Is there anyone on the list that might be
able to help.

P.S. Sorry for have to do this here.

-James

Re: LiquidWeb contact re phishing 24 days

[James Shank]

ation of Phishing Materials*:
> 
> hxxps://zionhighschools[dot]com/wp-content/themes/ivy-school/vc_templates/american-express/home/?cmd=www.ssaonline-account-service.com-update_submit&%3bid=93dd5ecd270aecd21435f29da5626bcb93dd5ecd270aecd21435f29da5626bcb&%3bsession=93dd5ecd270aecd21435f29da5626bcb93dd5ecd270aecd21435f29da5626bcb
> hxxp://zionhighschools[dot]com/wp-content/themes/ivy-school/vc_templates/american-express/home/
> hxxps://zionhighschools[dot]com/wp-content/themes/ivy-school/vc_templates/american-express/home/?cmd=www.ssaonline-account-service.com-update_submit=93dd5ecd270aecd21435f29da5626bcb93dd5ecd270aecd21435f29da5626bcb=93dd5ecd270aecd21435f29da5626bcb93dd5ecd270aecd21435f29da5626bcb
> hxxps://zionhighschools[dot]com/wp-content/themes/ivy-school/vc_templates/american-express/home/?cmd=www.ssaonline-account-service.com-update_submit=93dd5ecd270aecd21435f29da5626bcb93dd5ecd270aecd21435f29da5626bcb=93dd5ecd270aecd21435f29da5626bcb93dd5ecd270aecd21435f29da5626bcb
> hxxp://zionhighschools[dot]com/wp-content/themes/ivy-school/vc_templates/american-express/home/?cmd=www.ssaonline-account-service.com-update_submit=93dd5ecd270aecd21435f29da5626bcb93dd5ecd270aecd21435f29da5626bcb=93dd5ecd270aecd21435f29da5626bcb93dd5ecd270aecd21435f29da5626bcb
> 
> 
> (individually or collectively, “*Phishing Materials*”)
> 
> *** * * ** 
> 
> Greetings,
> 
> Per the above summary, we write on behalf of American Express to request
> your assistance to mitigate a confirmed threat that appears to utilise your
> network resources for fraudulent purposes by hosting the Phishing Materials
> as identified above.
> 
> We would appreciate it if you would take all reasonable and appropriate
> steps to ensure your network resources are no longer being used to
> facilitate or contribute to this confirmed threat, which may include
> temporarily suspending the account until the Phishing Materials have been
> removed.
> 
> If you need any support or additional information during the course of your
> investigation, please let us know by reply email at your earliest
> convenience.
> 
> Thank you for your support in safeguarding the public.
> 
> Sincerely,
> 
> Digital Threat Incident Response Team
> 
> RiskIQ, Inc.
> 
> 22 Battery St., 10th Floor, San Francisco CA 94111 USA
> www.riskiq.com
> Incident 54873584
> 

-- 
James Shank
Senior Security Evangelist; Chief Architect, Community Services
Team Cymru, Inc.
jsh...@cymru.com; +1-847-378-3365; http://www.team-cymru.com/

Re: dot-org TLD sale halted by ICANN

[james jones]

I don't know if this feasible, I would rather see the ORG TLD in the hands
of a nonprofit. That is just a personal feeling. I don't how practical that
would be though.

-James

On Fri, May 1, 2020 at 7:20 AM Lee  wrote:

> On 5/1/20, Bill Woodcock  wrote:
> >
> >
> >> On May 1, 2020, at 6:19 AM, Andy Ringsmuth  wrote:
> >> https://www.theregister.co.uk/2020/05/01/icann_stops_dot_org_sale/
> >> I know this has been bantered about on the list in the past. Great
> (IMHO)
> >> to see this happen.
> >
> > Yeah, this is an excellent result in the first-half of the fight. Now
> that
> > we know who won’t be acting AGAINST non-profits, we need ICANN to run the
> > competitive process again to find who will act FOR non-profits.
>
> Wasn't the price cap removal what started this mess in for first place?
>
> Put the price cap back on for .org domains and then start the process
> for finding a new home for .org
>
> Regards,
> Lee
>

Re: CGNAT Solutions

[james jones]

How big is your ip pool for CGNAT?

On Wed, Apr 29, 2020 at 10:17 AM Robert Blayzor 
wrote:

> On 4/28/20 11:01 PM, Brandon Martin wrote:
> > Depending on how many IPs you need to reclaim and what your target
> > IP:subscriber ratio is, you may be able to eliminate the need for a lot
> > of logging by assigning a range of TCP/UDP ports to a single inside IP
> > so that the TCP/UDP port number implies a specific subscriber.
> >
> > You can't get rid of all the state tracking without also having the CPE
> > know which ports to use (in which case you might as well use LW4o6 or
> > MAP), but at least you can get it down to where you really only need to
> > log (or block and dole out public IPs as needed) port-less protocols.
>
>
> I'm wondering if there are any real world examples of this, namely in
> the realm of subscriber to IP and range of ports required, etc.  ie: Is
> is a range of 1000 ports enough for one residential subscriber? How
> about SMB where no global IP is required.
>
> One would think a 1000 ports would be enough, but if you have a dozen
> devices at home all browsing and doing various things, and with IOT,
> etc, maybe not?
>
>
> --
> inoc.net!rblayzor
> XMPP: rblayzor.AT.inoc.net
> PGP:  https://pgp.inoc.net/rblayzor/
>
-- 
Sent from Gmail Mobile

SINGLEHOP-LLC AS32475 - Contact

[James Braunegg]

Dear All

Does anyone have a contact at SingleHop AS32475 which you can share with me ?

Looking for someone who is responsible for BGP / Routing / AS Path etc ?

Looking forward to hearing from you

Kindest Regards

James Braunegg



[cid:image001.png@01D280A4.01865B60]

1300 769 972 / 0488 997 207

ja...@micron21.com<mailto:ja...@micron21.com>

www.micron21.com/<http://www.micron21.com/>


[cid:image002.png@01D280A4.01865B60]<http://www.micron21.com/>


[cid:image003.png@01D280A4.01865B60]<https://www.facebook.com/micron21/>

[cid:image004.png@01D280A4.01865B60]<https://twitter.com/micron21>

Follow us on Twitter<https://twitter.com/micron21> for important service and 
system updates.


This message is intended for the addressee named above. It may contain 
privileged or confidential information. If you are not the intended recipient 
of this message you must not use, copy, distribute or disclose it to anyone 
other than the addressee. If you have received this message in error please 
return the message to the sender by replying to it and then delete the message 
from your computer.

Re: Sunday traffic curiosity

[james jones]

I know Facebook live had some congestion/capacity issues in some geographical 
regions this AM. 

Sent from my iPhone

> On Mar 22, 2020, at 2:59 PM, Andy Ringsmuth  wrote:
> 
> Fellow NANOGers,
> 
> Not a big deal by any means, but for those of you who have traffic data, I’m 
> curious what Sunday morning looked like as compared to other Sundays. Sure, 
> Netflix and similar companies have no doubt seen traffic increase, but I’m 
> wondering if an influx of church service streaming was substantial enough to 
> cause a noticeable traffic increase.
> 
> We livestream our services and have been for about a year or so, but normally 
> average just a handful of viewers. Today, we were around 150 watching live.
> 
> 
> Andy Ringsmuth
> a...@andyring.com
> 

Re: DHS letters for fuel and facility access

[james jones]

I get that thanks, wasn’t trying to be snarky just genuinely curious.

Sent from my iPhone

> On Mar 16, 2020, at 4:46 PM, Sean Donelan  wrote:
> 
> 
> In response to a snarky question offlist.  Yes, the DHS letters are just 
> copies.  Yes, the DHS letters are easy to counterfeit.
> 
> Not a lawyer, but counterfeiting an official federal document during a 
> national state of emergency likely violates many federal and state laws.
> 
> DON'T DO IT.
> 
> 
>> On Mon, 16 Mar 2020, Sean Donelan wrote:
>> On some other mailing lists, FCC licensed operators are reporting they have 
>> received letters from the Department of Homeland Security authorizing 
>> "access" and "fuel" priority.
>> 
>> Occasionally, DHS issues these letters after natural disasters such as 
>> hurricanes for hospitals and critical facilities.  I haven't heard of them 
>> issued for pandemics.

Re: DHS letters for fuel and facility access

[james jones]

Got it!

Sent from my iPhone

> On Mar 16, 2020, at 4:26 PM, Jared Mauch  wrote:
> 
> 
> 
>> On Mar 16, 2020, at 4:24 PM, james jones  wrote:
>> 
>> Fuel priority? They expecting shortage and/or power outages?
>> 
> 
> I suspect it’s more to solve issues with truck drivers going to work and 
> their job is to deliver fuel.  Some areas have been instituting curfews and 
> this would satisfy the local authorities who may stop such a driver.
> 
> - Jared
> 

Re: DHS letters for fuel and facility access

[james jones]

Fuel priority? They expecting shortage and/or power outages?

-James

On Mon, Mar 16, 2020 at 4:21 PM Sean Donelan  wrote:

>
> On some other mailing lists, FCC licensed operators are reporting they
> have received letters from the Department of Homeland Security authorizing
> "access" and "fuel" priority.
>
> Occasionally, DHS issues these letters after natural disasters such as
> hurricanes for hospitals and critical facilities.  I haven't heard of them
> issued for pandemics.
>
>

Re: Chairman Pai Proposes Mandating STIR/SHAKEN To Combat Robocalls

[James R Cutler]

In this case, “ebony phone” refers to the (usually) black housing of landline 
phones, either dial or manual that your parents probably used for years. Caller 
ID has long been supplied (for extra cost) to subscribers as a signal 
interspersed with the ring signal.

The answer to “what about ebony phones” is to require telcos to verify the 
Caller ID which is delivered to landline telephones along with the ring signal.

Again, this is not likely since it would impact the telco’s profit margin.


James R. Cutler
james.cut...@consultant.com
GPG keys: hkps://hkps.pool.sks-keyservers.net



> On Mar 9, 2020, at 9:25 PM, Ross Tajvar  wrote:
> 
> What is an "ebony phone"? (Google results for that phrase are mostly porn.)
> 
> On Sat, Mar 7, 2020 at 12:55 PM Christopher Morrow  <mailto:morrowc.li...@gmail.com>> wrote:
> On Sat, Mar 7, 2020 at 4:10 AM Bryan Holloway  <mailto:br...@shout.net>> wrote:
> >
> >
> > On 3/7/20 8:03 AM, Christopher Morrow wrote:
> > > On Fri, Mar 6, 2020 at 11:05 PM Brian J. Murrell  > > <mailto:br...@interlinx.bc.ca>> wrote:
> > >
> > >> So, if my telco can bill the callers for those premium calls, they
> > >> surely know who they are, or at least know where they are sending the
> > >> bill and getting payment from.
> > >
> > > You are mistaken, billing is very hard.
> > > Telcos show this regularly.
> > >
> >
> > On the contrary: billing is easy. Getting it right is hard.
> 
> You are technically correct, the best kind of correct.
> 
> Seriously though, a bunch of the conversation about shaken/stir and
> various problems with spam callers reveals:
>   "telcos don't care (for any reason you can imagine)"
>   "gov't mandates aren't  really going to help"
>   "people care as recipients of these calls, but really there are
> options for them as well to not get the calls (or not answer them)"
> 
> I like that Mr Thomas's answer: "Why can't we just cryptpgraphically
> sign the caller's ANI and use that as a method to ID real callers we
> care about?"
> since that was my suggestion to the stir folk in their very first
> meeting... "what about ebony phones!" said the lawyer from
> telco-ville.

Legacy Concentric/XO Web Services Blocking?

[James Breeden]

NANOG,

Looking for anyone from XO or Legacy Concentric web hosting services (now 
VDMS). I have a mutual customer that is getting caught at some form of Web App 
firewall coming from a specific IP range.

Thank you!


James W. Breeden
Managing Partner

[logo_transparent_background]
Arenal Group: Arenal Consulting Group | Atheral | Ceteris Coin | Acilis Telecom 
| Pines Events and Media | BlueNinja
Corporate: PO Box 1063 | Smithville, TX 78957
Email: ja...@arenalgroup.co<mailto:ja...@arenalgroup.co> | office 512.360. 
| www.arenalgroup.co<http://www.arenalgroup.co/>

Re: AFRINIC: The Saga Continues

[James Shank]

Hi all,

I am still looking into the history of this issue, but presently, the
prefix Chris shared with us is not on our IPv4 BOGON list.

For those wanting to see the list, it is available in plain text here:

https://www.team-cymru.org/Services/Bogons/fullbogons-ipv4.txt

I welcome input on this as I look into the history a little more.

Cheers!

James

On 1/29/20 7:27 AM, Chris Knipe wrote:
> Hi All,
> 
> http://ftp.afrinic.net/stats/afrinic/delegated-afrinic-extended-20200129
> 
> Another thing that stuck it's head out today now.  No ASN, nor IP prefixes
> allocated since 2019/05/15 is listed in the delegated text files.  Our (and
> I am sure others) prefixes is now null routed at team CYMRU (contacted
> them, waiting for response).
> 
> Yesterday's file was incomplete (looks like there were errors with the
> script perhaps), and today's file is missing an enormous amount of data (1
> ASN, 163 IPv4 allocations, and 272 IPv6 allocations). This is comparing the
> data file from 2020/01/29 (today) to 2020/01/27 (two days ago).
> 
> We also have a ticket with AfriNIC (no response yet), and when we called
> them there was no one "available" to assist.
> 
> 
> On Wed, Jan 29, 2020 at 1:20 AM Ronald F. Guilmette 
> wrote:
> 
>> In message ,
>> thomas brenac  wrote:
>>
>>> Thank you Ronald, I also heard of governance issue in AFRINIC by some
>>> people during the last RIPE meeting so the word is spreading. Now is
>>> there any other /16 impacted to your knowledge ? Would be worth pushing
>>> to have them in as many Drop list as possible maybe :)
>>
>> As reported in Jan Vermeulen's article on the web site mybroadband.co.za
>> published December 4, there has been, and continues to be a large number
>> of blocks, both "legacy" blocks and other blocks, that were stolen from
>> the Afrinic free pool.  These blocks are of varying sizes, generally /16
>> blocks but also some larger ones as well as a few smaller ones.
>>
>> The list of affected legacy blocks from Jan's article are as follows:
>>
>> 196.10.64.0/19
>> 196.10.61.0/24
>> 196.10.62.0/23
>> 160.121.0.0/16
>> 155.235.0.0/16
>> 152.108.0.0/16
>> 155.237.0.0/16
>> 169.129.0.0/16
>> 165.25.0.0/16
>> 160.122.0.0/16
>> 168.80.0.0/15
>> 165.3.0.0/16
>> 165.4.0.0/16
>> 165.5.0.0/16
>> 160.115.0.0/16
>>
>> In addition to all of the above, I have some reason to believe that the
>> following additional legacy block WAS (past tense) stolen, but has now
>> been reclaimed by, and ressigned to its rightful modern owner:
>>
>> 152.108.0.0/16
>>
>> It is highly probable that there are other and additional legacy blocks
>> that have also been stolen.  I have been prevented from fully completing
>> my research work on this part of the problem by ongoing stonewalling by
>> Afrinic.  Specifically, despite Afrinic having a defined protocol whereby
>> legitimate researchers may request confidential access to the unredacted
>> Afrinic WHOIS data base for legitimate research purposes... a protocol
>> and a process which is fully supported and operational at all of the other
>> four global RIRs... Afrinic has, for reasons unknown, elected to only
>> provide redacted versions of its WHOIS data base which are identical
>> to what may be obtained at any time, and without any special protocol,
>> directly from Afrinic's FTP server (via anonymous FTP).  Because the
>> accurate identification of stolen Afrinic legacy blocks involves the
>> careful analysis of the *unredacted* contact person: records, access to
>> only the redacted data base is of no value whatsoever in the task of
>> identifying stolen Afrinic legacy blocks.
>>
>> Here is the page on the Afrinic web site where they needlessly torment
>> legitimate researchers into believing that they will be able to get the
>> same kind of unredacted WHOIS data base access as is provided, upon
>> vetting and approval, by all of the other RIRs:
>>
>> https://www.afrinic.net/services/207-bulk-whois-access
>>
>> The list of blocks that appear to have been stolen from the Afrinic free
>> pool, as published in Jan's Dec 4 article are as follows:
>>
>> "Infoplan"/"Network and Information Technology Limited":
>> 196.16.0.0/14
>> 196.4.36.0/22
>> 196.4.40.0/22
>> 196.4.44.0/23
>>
>> "Cape of Good Hope Bank"/"CGHB":
>> 165.52.0.0/14
>> 137.171.0.0/16
>> 160.184.0.0/16
>> 168.211.0.0/16
>> 192.96.146.0/24  -- NOTE!!  -- 100% legitimate legacy allocation!
>&g

Re: Reminiscing our first internet connections (WAS) Re: akamai yesterday - what in the world was that

[james jones]

Does AOL count? If my first real internet connection was dial up 3600 baud
through compuserv. When I finally upgraded to 56K I thought it was light
speed.

On Mon, Jan 27, 2020 at 9:01 AM Bruce H McIntosh  wrote:

> On 1/27/20 7:59 AM, Bryan Holloway wrote:
> > [External Email]
> >
> > ... and disabling call-waiting ... ;)
> >
> We had a separate line (paid for by our work) without call-bothering on it
> for the modem.
>
> --
> 
> Bruce H. McIntosh
> Network Engineer II
> University of Florida Information Technology
> b...@ufl.edu
> 352-273-1066
>