date:20201009

Re: Centurylink Boise Networking Oddness

2020-10-09 Thread Brielle

It is a tad bit unusual yes, but not surprising from Boise.  Our connections 
have to go out to Seattle or other neighboring states before hitting any major 
IX.

Well, that and basing issues solely on ICMP echos and trace routes can be 
tricky, given that they are low priority and require hitting the CPU on 
routers...

Glad the issue seems to be resolved though.

Sent from my iPhone

> On Oct 9, 2020, at 5:44 PM, Laurent Dumont  wrote:
> 
> 
> 100ms to twitch for continental USA seems a bit absurd!
> 
>> On Fri, Oct 9, 2020 at 10:56 AM Brielle  wrote:
>> 
>> Im on a CenturyLink fiber connection in Boise.  What is the problem you are 
>> seeing exactly?  Traceroute doesn’t look odd really.
>> 
>> 
>> Sent from my iPhone
>> 
 On Oct 9, 2020, at 8:40 AM, Allen Smith via NANOG  wrote:
 
>>> 
>>> 
>>> I apologize for the noise, this seems like the kind of thing where it 
>>> actually isn't possible to get a message to the right folks through the 
>>> front door. Hoping someone subscribed here can take a look.
>>> 
>>> Looks like something here in Boise is squirrelly. 
>>> 
>>> fw1$ traceroute -A -I twitch.tv 
>>> traceroute: Warning: twitch.tv has multiple addresses; using 151.101.66.167 
>>> traceroute to twitch.tv (151.101.66.167), 64 hops max, 60 byte packets 
>>> 1  boid-dsl-gw17.boid.qwest.net (184.99.64.17) [AS209, AS209]  10.036 ms  
>>> 9.39 ms  9.633 ms 
>>> 2  184-99-65-133.boid.qwest.net (184.99.65.133) [AS209, AS209]  108.501 ms  
>>> 96.669 ms  92.894 ms
>>> 3  4.68.63.137 (4.68.63.137) [AS3356]  117.743 ms  125.807 ms  127.163 ms 
>>> 4  * * * 
>>> 5  4.31.15.194 (4.31.15.194) [AS3356]  125.038 ms  113.778 ms  102.7 ms 
>>> 6  151.101.66.167 (151.101.66.167) [AS54113]  115.716 ms  121.388 ms  
>>> 118.879 ms
>>> 
>>> Using lookingglass.centurylink.com I see the same thing from the other 
>>> direction.
>>> 
>>> Tracing route to 184.99.65.134
>>> 1 ae-2-3615.edge6.Seattle1.Level3.net (4.69.219.210) 0ms 0ms 0ms
>>> 2 4.68.63.134 (4.68.63.134) 10ms 10ms 10ms
>>> 3 boid-agw2.inet.qwest.net (205.171.94.2) 26ms 26ms 26ms
>>> 4 184-99-65-134.boid.qwest.net (184.99.65.134) 126ms 118ms
>>> 
>>> All of this is around Thu Oct  8 12:10:31 MDT 2020
>>> 
>>> Thanks,
>>> -Allen

Re: Centurylink Boise Networking Oddness

2020-10-09 Thread Laurent Dumont

100ms to twitch for continental USA seems a bit absurd!

On Fri, Oct 9, 2020 at 10:56 AM Brielle  wrote:

>
> Im on a CenturyLink fiber connection in Boise.  What is the problem you
> are seeing exactly?  Traceroute doesn’t look odd really.
>
>
> Sent from my iPhone
>
> On Oct 9, 2020, at 8:40 AM, Allen Smith via NANOG  wrote:
>
> 
>
> I apologize for the noise, this seems like the kind of thing where it
> actually isn't possible to get a message to the right folks through the
> front door. Hoping someone subscribed here can take a look.
>
> Looks like something here in Boise is squirrelly.
>
> fw1$ traceroute -A -I twitch.tv
> traceroute: Warning: twitch.tv has multiple addresses; using
> 151.101.66.167
> traceroute to twitch.tv (151.101.66.167), 64 hops max, 60 byte packets
> 1  boid-dsl-gw17.boid.qwest.net (184.99.64.17) [AS209, AS209]  10.036 ms
>  9.39 ms  9.633 ms
> 2  184-99-65-133.boid.qwest.net (184.99.65.133) [AS209, AS209]  108.501
> ms  96.669 ms  92.894 ms
> 3  4.68.63.137 (4.68.63.137) [AS3356]  117.743 ms  125.807 ms  127.163 ms
> 4  * * *
> 5  4.31.15.194 (4.31.15.194) [AS3356]  125.038 ms  113.778 ms  102.7 ms
> 6  151.101.66.167 (151.101.66.167) [AS54113]  115.716 ms  121.388 ms
>  118.879 ms
>
> Using lookingglass.centurylink.com I see the same thing from the other
> direction.
>
> Tracing route to 184.99.65.134
> 1 ae-2-3615.edge6.Seattle1.Level3.net (4.69.219.210) 0ms 0ms 0ms
> 2 4.68.63.134 (4.68.63.134) 10ms 10ms 10ms
> 3 boid-agw2.inet.qwest.net (205.171.94.2) 26ms 26ms 26ms
> 4 184-99-65-134.boid.qwest.net (184.99.65.134) 126ms 118ms
>
> All of this is around Thu Oct  8 12:10:31 MDT 2020
>
> Thanks,
> -Allen
>
>

Re: Securing Greenfield Service Provider Clients

2020-10-09 Thread Billy Crook

On Fri, Oct 9, 2020 at 2:27 PM Christopher J. Wolff 
wrote:

> Without setting up SSL encrypt/decrypt through a MITM setup and handing
> certificates out to every client, is there any other software/hardware that
> can perform DPI and/or ssl analysis[...]?
>

No.  That was kind of the point of SSL.

Re: Juniper configuration recommendations/BCP

2020-10-09 Thread Eric Kuhnke

I guess he never saw a Juniper M40, it's literally an i686/x86 32-bit
motherboard for the routine engine, glued to a chassis with linecards
containing custom ASICs and optics. As I recall it was a moderate speed
Pentium 2 with some average amount of RAM and a 2.5" 44pin ATA66 laptop
hard drive.

Or a M20 or so on...  The entire origin of JunOS is with FreeBSD.

On Thu, Oct 8, 2020 at 3:51 PM Chris Boyd  wrote:

>
>
> > On Oct 8, 2020, at 10:55 AM,   wrote:
> >
> > JunOS is so linux based
>
> Um, my MX-204 says FreeBSD amd64.
>

Re: Securing Greenfield Service Provider Clients

2020-10-09 Thread Curtis, Bruce via NANOG

If you search for this phrase 

During 2020 more than fifty percent of new malware campaigns will use 
various forms of encryption and obfuscation to conceal delivery, and to conceal 
ongoing communications, including data exfiltration.

you will find lots of vendors of decryption have the phrase from Gartner 
mentioned prominently on their web site.

I don’t think TLS decryption would be viable in our university environment.

Your email address indicates that you are in a government environment and if so 
you might have more control over devices and could have a better chance of 
making decryption work.
On the other hand if you have more control over devices a better choice might 
be to spend your resources on implementing whitelisting rather than decryption.

Keep in mind that if you implement decryption your decryption device is in 
scope for PCI and subject to the various PCI duding and logging requirements.

Attackers abuse Google DNS over HTTPS to download malware

https://www.bleepingcomputer.com/news/security/attackers-abuse-google-dns-over-https-to-download-malware/

More general and as focused on decryption but I recommend you watch these 
sessions from RSA conferences.

https://www.youtube.com/watch?v=d90Ov6QM1jE

https://www.youtube.com/watch?v=qzI-N0p9hFk

And also the NIST draft on Zero Trust Architecture.  The document is mainly 
about Zero Trust but does briefly mention decryption.

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf

https://csrc.nist.gov/publications/detail/sp/800-207/final

> On Oct 9, 2020, at 2:09 PM, Christopher J. Wolff  wrote:
> 
> Dear Nanog;
>  
> Hope everyone is getting ready for a good weekend.  I’m working on a 
> greenfield service provider network and I’m running into a security 
> challenge.  I hope the great minds here can help.
>  
> Since the majority of traffic is SSL/TLS, encrypted malicious content can 
> pass through even an “NGFW” device without detection and classification.
>  
> Without setting up SSL encrypt/decrypt through a MITM setup and handing 
> certificates out to every client, is there any other software/hardware that 
> can perform DPI and/or ssl analysis so I can prevent encrypted malicious 
> content from being downloaded to my users?
>  
> Have experience with Palo and Firepower but even these need the MITM 
> approach.  I appreciate any advice anyone can provide.
>  
> Best,
> CJ

Bruce Curtis
Network Engineer  /  Information Technology
NORTH DAKOTA STATE UNIVERSITY
phone: 701.231.8527
bruce.cur...@ndsu.edu

Re: Securing Greenfield Service Provider Clients

2020-10-09 Thread Baldur Norddahl

Are you really suggesting decrypting customer traffic? In most parts of the
world that act falls in one of two categories: it is either required by law
or it is illegal.

Offer your customers a good virus scanner to install instead.

Regards

Baldur


fre. 9. okt. 2020 21.27 skrev Christopher J. Wolff :

> Dear Nanog;
>
>
>
> Hope everyone is getting ready for a good weekend.  I’m working on a
> greenfield service provider network and I’m running into a security
> challenge.  I hope the great minds here can help.
>
>
>
> Since the majority of traffic is SSL/TLS, encrypted malicious content can
> pass through even an “NGFW” device without detection and classification.
>
>
>
> Without setting up SSL encrypt/decrypt through a MITM setup and handing
> certificates out to every client, is there any other software/hardware that
> can perform DPI and/or ssl analysis so I can prevent encrypted malicious
> content from being downloaded to my users?
>
>
>
> Have experience with Palo and Firepower but even these need the MITM
> approach.  I appreciate any advice anyone can provide.
>
>
>
> Best,
>
> CJ
>

Charter/spectrum contact (AS20115)

2020-10-09 Thread Ross Tajvar

Hi, can someone reach out off-list please? We are seeing very high latency
to Spectrum residential users from LAX.

RE: Securing Greenfield Service Provider Clients

2020-10-09 Thread Kevin Burke

Agreed DNS/IP reputation is still about the best.  Then move on with everything 
else we should be doing.

Decrypting the content would bring us to the next problem.  Malware is commonly 
encrypted to prevent AntiVirus from pattern matching or hash matching.

Decrypting the content always struck me as something that is better suited for 
spotting exfiltration.  Searching for known clear text similar to “FBI 
Classified” or a watermark in documents sounded like an attainable goal from 
SSL decryption.

Kevin Burke
802-540-0979
Burlington Telecom
200 Church St, Burlington, VT

From: NANOG  On Behalf Of 
Jared Geiger
Sent: Friday, October 9, 2020 3:45 PM
To: nanog@nanog.org
Subject: Re: Securing Greenfield Service Provider Clients

WARNING!! This message originated from an External Source. Please use proper 
judgment and caution when opening attachments, clicking links, or responding to 
this email.
DNS filtering might be an easier option to get most of the bad stuff with 
services like 9.9.9.9 and 1.1.1.2. Paid options like 
dnsfilter.com will give you better control. Cloudflare 
Gateway might also be an option.

On Fri, Oct 9, 2020 at 12:29 PM Christopher J. Wolff 
mailto:cjwo...@nola.gov>> wrote:
Dear Nanog;

Hope everyone is getting ready for a good weekend.  I’m working on a greenfield 
service provider network and I’m running into a security challenge.  I hope the 
great minds here can help.

Since the majority of traffic is SSL/TLS, encrypted malicious content can pass 
through even an “NGFW” device without detection and classification.

Without setting up SSL encrypt/decrypt through a MITM setup and handing 
certificates out to every client, is there any other software/hardware that can 
perform DPI and/or ssl analysis so I can prevent encrypted malicious content 
from being downloaded to my users?

Have experience with Palo and Firepower but even these need the MITM approach.  
I appreciate any advice anyone can provide.

Best,
CJ

Re: Securing Greenfield Service Provider Clients

2020-10-09 Thread Matthias Luft via NANOG


CJ,

On 09.10.20 15:09, Christopher J. Wolff wrote:

Dear Nanog;

Hope everyone is getting ready for a good weekend.ï¿½ Iï¿½m working on a 
greenfield service provider network and Iï¿½m running into a security 
challenge.ï¿½ I hope the great minds here can help.


Since the majority of traffic is SSL/TLS, encrypted malicious content 
can pass through even an ï¿½NGFWï¿½ device without detection and classification.


Without setting up SSL encrypt/decrypt through a MITM setup and handing 
certificates out to every client, is there any other software/hardware 
that can perform DPI and/or ssl analysis so I can prevent encrypted 
malicious content from being downloaded to my users?


Have experience with Palo and Firepower but even these need the MITM 
approach.ï¿½ I appreciate any advice anyone can provide.


I think this most likely needs to develop into a bigger discussion, but 
TLS introspection will (and must, otherwise we would have big problems ) 
rely on a MITM setup.


DNS- and reputation-based filtering was already mentioned, there is also 
this work on detecting malware aspects by TLS anomalies:

https://www.imperial.ac.uk/media/imperial-college/faculty-of-engineering/computing/public/1819-pg-projects/Detecting-Malware-in-TLS-Traf%EF%AC%81c.pdf

I'm not aware whether there are service provider network-grade tools for 
this available though.


Thanks,
Matthias

Re: Securing Greenfield Service Provider Clients

2020-10-09 Thread Jared Geiger

DNS filtering might be an easier option to get most of the bad stuff with
services like 9.9.9.9 and 1.1.1.2. Paid options like dnsfilter.com will
give you better control. Cloudflare Gateway might also be an option.

On Fri, Oct 9, 2020 at 12:29 PM Christopher J. Wolff 
wrote:

> Dear Nanog;
>
>
>
> Hope everyone is getting ready for a good weekend.  I’m working on a
> greenfield service provider network and I’m running into a security
> challenge.  I hope the great minds here can help.
>
>
>
> Since the majority of traffic is SSL/TLS, encrypted malicious content can
> pass through even an “NGFW” device without detection and classification.
>
>
>
> Without setting up SSL encrypt/decrypt through a MITM setup and handing
> certificates out to every client, is there any other software/hardware that
> can perform DPI and/or ssl analysis so I can prevent encrypted malicious
> content from being downloaded to my users?
>
>
>
> Have experience with Palo and Firepower but even these need the MITM
> approach.  I appreciate any advice anyone can provide.
>
>
>
> Best,
>
> CJ
>

Re: Securing Greenfield Service Provider Clients

2020-10-09 Thread Matt Harris

On Fri, Oct 9, 2020 at 2:27 PM Christopher J. Wolff 
wrote:

> Dear Nanog;
>
>
>
> Hope everyone is getting ready for a good weekend.  I’m working on a
> greenfield service provider network and I’m running into a security
> challenge.  I hope the great minds here can help.
>
>
>
> Since the majority of traffic is SSL/TLS, encrypted malicious content can
> pass through even an “NGFW” device without detection and classification.
>
>
>
> Without setting up SSL encrypt/decrypt through a MITM setup and handing
> certificates out to every client, is there any other software/hardware that
> can perform DPI and/or ssl analysis so I can prevent encrypted malicious
> content from being downloaded to my users?
>
>
>
> Have experience with Palo and Firepower but even these need the MITM
> approach.  I appreciate any advice anyone can provide.
>

Do you really want to do this? Ask yourself not whether you want to protect
your users from malicious content, but rather ask yourself do you want to
expose all of their financial, medical, and other personal details to
anyone who may have access (including potentially unauthorized access) to
this system? As a service provider with a customer/user base that you do
not directly control, the answer should almost certainly always be "no."

It's one thing to implement this sort of snooping in an office/corporate
environment: there you have direct control over systems to install MITM CA
certificates, and the ability to set policies like "don't view personal
websites or enter personal financial, medical, or other private details on
a work computer outside of communicating with HR" or somesuch.

Instead, I'd recommend distributing good anti-malware software that
provides endpoint protection for their devices and teaching security best
practices to your users. You can also block access to known-bad hosts and
addresses either at your border via packet filtering, or via the recursive
DNS servers that you feed to clients. This may have the unintended
consequence of false positives resulting in additional support inquiries,
but overall is much better than trying to MITM secure connections from your
customer/user base.

Good luck!

Matt Harris|Infrastructure Lead Engineer
816-256-5446|Direct
Looking for something?
Helpdesk Portal|Email Support|Billing Portal
We build and deliver end-to-end IT solutions.

Securing Greenfield Service Provider Clients

2020-10-09 Thread Christopher J. Wolff

Dear Nanog;

Hope everyone is getting ready for a good weekend.  I'm working on a greenfield 
service provider network and I'm running into a security challenge.  I hope the 
great minds here can help.

Since the majority of traffic is SSL/TLS, encrypted malicious content can pass 
through even an "NGFW" device without detection and classification.

Without setting up SSL encrypt/decrypt through a MITM setup and handing 
certificates out to every client, is there any other software/hardware that can 
perform DPI and/or ssl analysis so I can prevent encrypted malicious content 
from being downloaded to my users?

Have experience with Palo and Firepower but even these need the MITM approach.  
I appreciate any advice anyone can provide.

Best,
CJ

Weekly Routing Table Report

2020-10-09 Thread Routing Analysis Role Account

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 10 Oct, 2020

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  826062
Prefixes after maximum aggregation (per Origin AS):  316047
Deaggregation factor:  2.61
Unique aggregates announced (without unneeded subnets):  398199
Total ASes present in the Internet Routing Table: 69603
Prefixes per ASN: 11.87
Origin-only ASes present in the Internet Routing Table:   59808
Origin ASes announcing only one prefix:   24791
Transit ASes present in the Internet Routing Table:9795
Transit-only ASes present in the Internet Routing Table:304
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  30
Max AS path prepend of ASN ( 45582)  27
Prefixes from unregistered ASNs in the Routing Table:   947
Number of instances of unregistered ASNs:   948
Number of 32-bit ASNs allocated by the RIRs:  33749
Number of 32-bit ASNs visible in the Routing Table:   27899
Prefixes from 32-bit ASNs in the Routing Table:  127659
Number of bogon 32-bit ASNs visible in the Routing Table:16
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:518
Number of addresses announced to Internet:   2861122816
Equivalent to 170 /8s, 137 /16s and 69 /24s
Percentage of available address space announced:   77.3
Percentage of allocated address space announced:   77.3
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.5
Total number of prefixes smaller than registry allocations:  278612

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   215567
Total APNIC prefixes after maximum aggregation:   63344
APNIC Deaggregation factor:3.40
Prefixes being announced from the APNIC address blocks:  211259
Unique aggregates announced from the APNIC address blocks:86600
APNIC Region origin ASes present in the Internet Routing Table:   10908
APNIC Prefixes per ASN:   19.37
APNIC Region origin ASes announcing only one prefix:   3069
APNIC Region transit ASes present in the Internet Routing Table:   1584
Average APNIC Region AS path length visible:4.5
Max APNIC Region AS path length visible: 30
Number of APNIC region 32-bit ASNs visible in the Routing Table:   6023
Number of APNIC addresses announced to Internet:  778576512
Equivalent to 46 /8s, 104 /16s and 34 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-141625
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:241395
Total ARIN prefixes after maximum aggregation:   111284
ARIN Deaggregation factor: 2.17
Prefixes being announced from the ARIN address blocks:   239104
Unique aggregates announced from the ARIN address blocks:116911
ARIN Region origin ASes present in the Internet Routing Table:18600
ARIN Prefixes per ASN:12.86
ARIN

RE: Juniper configuration recommendations/BCP

2020-10-09 Thread t...@pelican.org

On Thursday, 8 October, 2020 10:37, "Forrest Christian (List Account)" 
 said:

> I've done a bit of googling and am either finding stuff that is largely
> Cisco-specific or which is generic - all of which I'm rather familiar with
> based on my past history.   Is there anything I should worry about which is
> Juniper-specific?

Very-specifically for the MX204, not all the possible port combinations work.  
Check https://apps.juniper.net/home/port-checker/index.html, if you haven't 
already.


Juniper more generally, the big one that bit me coming from Cisco-land is that 
lots of the config telling you what the interface is doing isn't under the 
interface config, nor is it findable at all without some magic pipelines.  If 
you're used to seeing:

#show run int gi0/0/0

interface gi0/0/0
 ip vrf forwarding blah

To tell you what VRF the interface is in, you may be annoyed by:

#show configuration routing-instances | display set | m gi0/0/0

routing-instance blah interface gi0/0/0

Similarly for QoS / service policies.  They're not attached to the interface at 
the interface level.


There are some BGP differences that may or may not hurt your brain depending on 
what you're offering in your network and how you build it.  Loop-detection is 
the opposite way around across the two platforms.  Juniper won't send to a 
neighbour whose AS is already in the path unless you specifically tell it to; 
Cisco sends everything regardless, but does the path check and drops on receipt 
unless you configure 'allow-as-in'.

From memory, default behaviour for EBGP is also different, absent any filtering 
policy.  Juniper works like IOS XR and fails closed - no policy = send nothing. 
 Vanilla IOS (and XE) fail open - no policy = send all the routes.


Mostly, though, quality-of-life improvements around tab-completion of named 
objects, atomic commit, rollback, etc are good.  "Commit confirm" is less of a 
blunt tool than "reload in..." before you start configuring.  Less of a 
revelation if you're coming from XR.

Regards,
Tim.

Re: Centurylink Boise Networking Oddness

2020-10-09 Thread Brielle


Im on a CenturyLink fiber connection in Boise.  What is the problem you are 
seeing exactly?  Traceroute doesn’t look odd really.


Sent from my iPhone

> On Oct 9, 2020, at 8:40 AM, Allen Smith via NANOG  wrote:
> 
> 
> 
> I apologize for the noise, this seems like the kind of thing where it 
> actually isn't possible to get a message to the right folks through the front 
> door. Hoping someone subscribed here can take a look.
> 
> Looks like something here in Boise is squirrelly. 
> 
> fw1$ traceroute -A -I twitch.tv 
> traceroute: Warning: twitch.tv has multiple addresses; using 151.101.66.167 
> traceroute to twitch.tv (151.101.66.167), 64 hops max, 60 byte packets 
> 1  boid-dsl-gw17.boid.qwest.net (184.99.64.17) [AS209, AS209]  10.036 ms  
> 9.39 ms  9.633 ms 
> 2  184-99-65-133.boid.qwest.net (184.99.65.133) [AS209, AS209]  108.501 ms  
> 96.669 ms  92.894 ms 
> 3  4.68.63.137 (4.68.63.137) [AS3356]  117.743 ms  125.807 ms  127.163 ms 
> 4  * * * 
> 5  4.31.15.194 (4.31.15.194) [AS3356]  125.038 ms  113.778 ms  102.7 ms 
> 6  151.101.66.167 (151.101.66.167) [AS54113]  115.716 ms  121.388 ms  118.879 
> ms
> 
> Using lookingglass.centurylink.com I see the same thing from the other 
> direction.
> 
> Tracing route to 184.99.65.134
> 1 ae-2-3615.edge6.Seattle1.Level3.net (4.69.219.210) 0ms 0ms 0ms
> 2 4.68.63.134 (4.68.63.134) 10ms 10ms 10ms
> 3 boid-agw2.inet.qwest.net (205.171.94.2) 26ms 26ms 26ms
> 4 184-99-65-134.boid.qwest.net (184.99.65.134) 126ms 118ms
> 
> All of this is around Thu Oct  8 12:10:31 MDT 2020
> 
> Thanks,
> -Allen

Re: Juniper configuration recommendations/BCP

2020-10-09 Thread David Kotlerewsky

Google around for Junos Evolution. Junos is going native Linux.

From: NANOG  on behalf of Matt 
Harris 
Date: Thursday, October 8, 2020 at 4:15 PM
To: Chris Boyd 
Cc: nanog list 
Subject: Re: Juniper configuration recommendations/BCP

Matt Harris
|

Infrastructure Lead Engineer

816‑256‑5446
|

Direct

Looking for something?
Helpdesk Portal
|

Email Support

|

Billing Portal

We build and deliver end‑to‑end IT solutions.
On Thu, Oct 8, 2020 at 5:51 PM Chris Boyd  wrote:

> On Oct 8, 2020, at 10:55 AM,   wrote:
> 
> JunOS is so linux based

Um, my MX-204 says FreeBSD amd64.

Junos has always had a large basis coming from FreeBSD way back when. 

There's no Linux going on in Junos itself as far as I know, however Juniper 
does utilize Wind River Linux as an intermediary virtualization step for some 
of their virtualized products like the vSRX.

Centurylink Boise Networking Oddness

2020-10-09 Thread Allen Smith via NANOG

I apologize for the noise, this seems like the kind of thing where it
actually isn't possible to get a message to the right folks through the
front door. Hoping someone subscribed here can take a look.

Looks like something here in Boise is squirrelly.

fw1$ traceroute -A -I twitch.tv
traceroute: Warning: twitch.tv has multiple addresses; using 151.101.66.167
traceroute to twitch.tv (151.101.66.167), 64 hops max, 60 byte packets
1  boid-dsl-gw17.boid.qwest.net (184.99.64.17) [AS209, AS209]  10.036 ms
 9.39 ms  9.633 ms
2  184-99-65-133.boid.qwest.net (184.99.65.133) [AS209, AS209]  108.501 ms
 96.669 ms  92.894 ms
3  4.68.63.137 (4.68.63.137) [AS3356]  117.743 ms  125.807 ms  127.163 ms
4  * * *
5  4.31.15.194 (4.31.15.194) [AS3356]  125.038 ms  113.778 ms  102.7 ms
6  151.101.66.167 (151.101.66.167) [AS54113]  115.716 ms  121.388 ms
 118.879 ms

Using lookingglass.centurylink.com I see the same thing from the other
direction.

Tracing route to 184.99.65.134
1 ae-2-3615.edge6.Seattle1.Level3.net (4.69.219.210) 0ms 0ms 0ms
2 4.68.63.134 (4.68.63.134) 10ms 10ms 10ms
3 boid-agw2.inet.qwest.net (205.171.94.2) 26ms 26ms 26ms
4 184-99-65-134.boid.qwest.net (184.99.65.134) 126ms 118ms

All of this is around Thu Oct  8 12:10:31 MDT 2020

Thanks,
-Allen

Spoofer Report for NANOG for Sep 2020

2020-10-09 Thread CAIDA Spoofer Project

In response to feedback from operational security communities,
CAIDA's source address validation measurement project
(https://spoofer.caida.org) is automatically generating monthly
reports of ASes originating prefixes in BGP for systems from which
we received packets with a spoofed source address.
We are publishing these reports to network and security operations
lists in order to ensure this information reaches operational
contacts in these ASes.

This report summarises tests conducted within usa, can.

Inferred improvements during Sep 2020:
ASNName   Fixed-By
39939  RISE-CO-AS399392020-09-01
9009   M247   2020-09-02
13857  ONLINEMAC  2020-09-19
10886  MAX-GIGAPOP2020-09-22

Further information for the inferred remediation is available at:
https://spoofer.caida.org/remedy.php

Source Address Validation issues inferred during Sep 2020:
ASNName   First-Spoofed Last-Spoofed
6939   HURRICANE 2016-02-22   2020-09-08
54825  PACKET2016-04-15   2020-09-18
46562  TOTAL-SERVER-SOLUTIONS2016-04-26   2020-09-03
36351  SOFTLAYER 2016-05-10   2020-09-08
13213  UK2NET2016-07-27   2020-09-02
209CENTURYLINK-US-LEGACY-QWEST   2016-08-16   2020-09-25
6128   CABLE-NET-1   2016-09-03   2020-09-30
20412  CLARITY-TELECOM   2016-09-30   2020-09-28
6181   FUSE-NET  2016-10-10   2020-09-28
18451  LESNET2016-10-18   2020-09-09
14971  PINETEL   2016-10-21   2020-09-25
11427  TWC-11427-TEXAS   2016-10-21   2020-09-30
174COGENT-1742016-10-21   2020-09-08
32440  LONI  2016-11-03   2020-09-27
12083  WOW-INTERNET  2016-11-09   2020-09-27
22439  PERFECT-INTERNATIONAL 2016-11-22   2020-09-08
20473  AS-CHOOPA 2017-01-08   2020-09-29
9009   M247  2017-01-10   2020-09-12
63296  AWBROADBAND   2017-09-01   2020-09-29
27589  MOJOHOST  2017-09-20   2020-09-03
546PARSONS-PGS-1 2017-11-20   2020-09-23
20448  VPNTRANET-LLC 2018-09-20   2020-09-05
20278  NEXEON2019-03-05   2020-09-08
8047   GCI   2019-04-11   2020-09-24
62904  EONIX-COMMUNICATIONS-ASBLOCK-62019-07-14   2020-09-08
46375  AS-SONICTELECOM   2019-10-21   2020-09-11
11650  PLDI  2020-05-25   2020-09-11
46816  DSNETWORKS-0012020-08-24   2020-09-08
32489  AMANAHA-NEW   2020-08-24   2020-09-02
7040   NETMINDERS2020-08-31   2020-09-03
206804 EstNOC2020-09-02   2020-09-03
32181  ASN-GIGENET   2020-09-02   2020-09-03
11042  NTHL  2020-09-02   2020-09-02
53340  FIBERHUB  2020-09-02   2020-09-02
32780  HOSTINGSERVICES-INC   2020-09-02   2020-09-02
19318  IS-AS-1   2020-09-03   2020-09-03
398325   2020-09-05   2020-09-26
395111 KVCNET-2009   2020-09-08   2020-09-08
25780  HUGESERVER-NETWORKS   2020-09-08   2020-09-08
207134 PHOENIXNAP-SRB2020-09-08   2020-09-08
62217  VooServers2020-09-08   2020-09-08
206628   2020-09-10   2020-09-10
23393  NUCDN 2020-09-30   2020-09-30
306022020-09-30   2020-09-30

Further information for these tests where we received spoofed
packets is available at:
https://spoofer.caida.org/recent_tests.php?country_include=usa,can_block=1

Source Address Validation issues inferred during Sep 2020
using open resolver tests:
ASNName   Last-Detected
11260  EASTLINK-HSI  2020-09-24
12214  RAPIDDSL--WIRELESS2020-09-24
131284 ETISALATAFG   2020-09-23
40033  RED-SPECTRUM  2020-09-23
53850  GORILLASERVERS2020-09-22
395262 CENTRE-OF-EXCELLENCE-IN-NEXT-G2020-09-22
26166  WATCHCOMM-WEST-OH 2020-09-19
14403  JJI-DEFAULT-002020-09-16
16524  METTEL2020-09-15
32444  SAFELINK-MV   2020-09-11
53338  ITCI  2020-09-10
15081  ASN-CROS-12020-09-07
19257  SUBRIGO   2020-09-07
40447  SKYHAWK-GROUP 2020-09-05
53274

Re: Juniper configuration recommendations/BCP

2020-10-09 Thread Paschal Masha

Above all, JUNOS makes sense when configuring, you literally the software
gives you the feel of talking to the device. If your brain is programmed to
be logically then all pieces and modes easily come to life and adaptation
becomes a zero hustle.



*Paschal Masha*
Lead Network Engineer
6x7 Networks | 1 (831)325-0544
Time Zone: PST


On Thu, Oct 8, 2020 at 6:44 PM Justin Oeder  wrote:

> If you are an OSPF shop, Cisco AD is 110 for internal and external
> routes.  Juniper is 10 for internal and 150 for external.  This can be
> changed via an export (maybe import) policy on the OSPF protocol.
>
> There is no 'network' statement in the Junos world.  There are a few
> different ways to solve this same problem.  Up to you how you do it.
>
> Routing engine protection is much easier.  A firewall filter on the
> loopback interface.  Here is a sample.  This is really where your BCP
> starts.
>
> https://github.com/jcoeder/juniper-configurations/blob/master/protect-re.txt
>
> Dynamic prefix-lists are pretty cool.  They allow you to create prefix-
> list based on other sections of the configuration.
>
> # In this first statement we use wildcards surrounding a . as this is
> the format of an IPv4 address.
> set policy-options prefix-list BGP_PEERS_DYNAMIC apply-path "protocols
> bgp group <*> neighbor <*.*>"
>
> # In this second statement we use wildcards surrounding a : as this is
> the format of an IPv6 address.
> set policy-options prefix-list BGP_PEERS_DYNAMIC_V6 apply-path
> "protocols bgp group <*> neighbor <*:*>"
>
> Justin
>
> On Thu, 2020-10-08 at 03:37 -0600, Forrest Christian (List Account)
> wrote:
> > 
> > After nearly 30 years of being a cisco shop, I'm working on
> > configuring our first pair of Juniper MX204's to replace our current
> > provider-edge cisco.
> >
> > I've worked through enough of the Juniper documentation/books to have
> > a fairly good handle on how to configure these, but I wanted to check
> > with the list to see if there are any Juniper-Specific gotchas I
> > might run into that isn't documented well.
> >
> > I've done a bit of googling and am either finding stuff that is
> > largely Cisco-specific or which is generic - all of which I'm
> > rather familiar with based on my past history.   Is there anything I
> > should worry about which is Juniper-specific?
> >
> > --
> > - Forrest
>
>

The clean network in US

2020-10-09 Thread Danny Pinto via NANOG

Some questions on the clean network program adoption/policy as a network 
operator. https://www.state.gov/the-clean-network/


Looking at some Tier 1 network operator logos and statements on that 
notification, Is this only about choice of network electronics deployment for 
future..



Would this really change Internet interconnection dynamics to 3Cs operators in 
US or adjustments in  EU or Asia also  ? 



How about sub sea capacity into the US. Probably there are many cables owned by 
consortium of Asian operators for many years ... ? 



Danny

Re: Juniper configuration recommendations/BCP

2020-10-09 Thread Alain Hebert


    Yeah, it changes.

    They started with FreeBSD 4.x + their patches, then moved it inside 
a hardened Linux for virtualization functions (watch closely the boot 
sequence).


    uname returns

        MX960 - FreeBSD amd64

        QFX 5100 - JUNOS i386 (build tag show indication its FreeBSD still)

-
Alain Hebertaheb...@pubnix.net
PubNIX Inc.
50 boul. St-Charles
P.O. Box 26770 Beaconsfield, Quebec H9W 6G7
Tel: 514-990-5911  http://www.pubnix.netFax: 514-990-9443

On 2020-10-08 18:50, Chris Boyd wrote:



On Oct 8, 2020, at 10:55 AM,   wrote:

JunOS is so linux based

Um, my MX-204 says FreeBSD amd64.

Re: Florida: Voter registration website overwhelmed at deadline

2020-10-09 Thread Valdis Klētnieks

On Wed, 07 Oct 2020 22:10:07 -0700, "Constantine A. Murenin" said:

> People act like 1.1 million requests per hour is a huge number.
>
> That's only 305 requests per second!
>
> Cheapest NVMe SSDs are capable of 160k+ IOPS.
>
> You can literally serve the whole thing from a single server on a
> 100Mbps line, if you design it properly, and don't waste bandwidth on
> stock images and silly front-ends.

It isn't the stock images and silly front-ends that take all the effort. Those
are pretty damned easy to serve up quickly.

It's the twisty little maze of databases, all different.

You asked for a driver's license number for ID? Well, that just bought you
a call to the DMV's servers to check on the validity/status of that ID.
Vetting the home address gets equally interesting, especially if it's
a PO box or a "suite" at a mailbox-for-rent company.
Vetting the existence of the last employer is going to take time as well.

Are you going to get the unemployment system, the tax system, the DMV
systems, and any others you need to talk to on this "one server"?  Oh, and
don't forget that the systems in the DMV and tax systems almost certainly
have *other* systems they have to talk to

Don't forget that these state agencies usually don't have the budget
that Amazon or other large commercial organizations have, so you're looking
at a *really* high chance that some server in the Department of Revenue
isn't sized big/fast enough, so verifying the employer's existence hangs, so
the front end hangs

On top of all that, even if you're only a *little* bit too slow clearing 
requests,
you end up sitting on a big pile of pending requests, which sucks up memory..
Get 305 requests per second, clear 304 per second, and in a few minutes
you're throwing '502 Gateway Error' left right and center because things are
wedged up



pgpEpdF5UALvs.pgp
Description: PGP signature

Re: Centurylink Boise Networking Oddness

Re: Centurylink Boise Networking Oddness

Re: Securing Greenfield Service Provider Clients

Re: Juniper configuration recommendations/BCP

Re: Securing Greenfield Service Provider Clients

Re: Securing Greenfield Service Provider Clients

Charter/spectrum contact (AS20115)

RE: Securing Greenfield Service Provider Clients

Re: Securing Greenfield Service Provider Clients

Re: Securing Greenfield Service Provider Clients

Re: Securing Greenfield Service Provider Clients

Securing Greenfield Service Provider Clients

Weekly Routing Table Report

RE: Juniper configuration recommendations/BCP

Re: Centurylink Boise Networking Oddness

Re: Juniper configuration recommendations/BCP

Centurylink Boise Networking Oddness

Spoofer Report for NANOG for Sep 2020

Re: Juniper configuration recommendations/BCP

The clean network in US

Re: Juniper configuration recommendations/BCP

Re: Florida: Voter registration website overwhelmed at deadline

22 matches

Site Navigation

Mail list logo

Footer information