Re: MSA’s and network architecture

[Etienne-Victor Depasquale via NANOG]

>
> In your fair proposal, MSA is related to network architecture as a way
> to standardise pluggable (optics). But as always standards are
> incomplete, ambiguous and do not guarantee interoperability, so it
> will take some time for industry to decide what is 'correct'
> interpretation of MSA. Implying when you buy early in life cycle new
> optics, you may want to source more carefully and test, compared to
> buying later in life cycle sourcing pluggables anywhere with 0 testing
> is relatively low risk.
>

Amen to that.

Cheers,

Etienne

On Wed, May 18, 2022 at 8:39 AM Saku Ytti  wrote:

> We could also add an explanation to our proposals for the acronym. :)
>
> In your fair proposal, MSA is related to network architecture as a way
> to standardise pluggable (optics). But as always standards are
> incomplete, ambiguous and do not guarantee interoperability, so it
> will take some time for industry to decide what is 'correct'
> interpretation of MSA. Implying when you buy early in life cycle new
> optics, you may want to source more carefully and test, compared to
> buying later in life cycle sourcing pluggables anywhere with 0 testing
> is relatively low risk.
>
>
> On Wed, 18 May 2022 at 09:32, Etienne-Victor Depasquale via NANOG
>  wrote:
> >
> > Just to add a bit of fun to the mix - perhaps multi-source agreement was
> intended :)
> >
> > Cheers,
> >
> > Etienne
> >
> > On Wed, May 18, 2022 at 3:59 AM Martin Hannigan 
> wrote:
> >>
> >>
> >>
> >> All,
> >>
> >> Why do MSA’s matter as related to network architecture?
> >>
> >> Thanks all —
> >>
> >> -M<
> >>
> >>
> >>
> >
> >
> > --
> > Ing. Etienne-Victor Depasquale
> > Assistant Lecturer
> > Department of Communications & Computer Engineering
> > Faculty of Information & Communication Technology
> > University of Malta
> > Web. https://www.um.edu.mt/profile/etiennedepasquale
>
>
>
> --
>   ++ytti
>


-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale

Re: MSA’s and network architecture

[Saku Ytti]

We could also add an explanation to our proposals for the acronym. :)

In your fair proposal, MSA is related to network architecture as a way
to standardise pluggable (optics). But as always standards are
incomplete, ambiguous and do not guarantee interoperability, so it
will take some time for industry to decide what is 'correct'
interpretation of MSA. Implying when you buy early in life cycle new
optics, you may want to source more carefully and test, compared to
buying later in life cycle sourcing pluggables anywhere with 0 testing
is relatively low risk.


On Wed, 18 May 2022 at 09:32, Etienne-Victor Depasquale via NANOG
 wrote:
>
> Just to add a bit of fun to the mix - perhaps multi-source agreement was 
> intended :)
>
> Cheers,
>
> Etienne
>
> On Wed, May 18, 2022 at 3:59 AM Martin Hannigan  wrote:
>>
>>
>>
>> All,
>>
>> Why do MSA’s matter as related to network architecture?
>>
>> Thanks all —
>>
>> -M<
>>
>>
>>
>
>
> --
> Ing. Etienne-Victor Depasquale
> Assistant Lecturer
> Department of Communications & Computer Engineering
> Faculty of Information & Communication Technology
> University of Malta
> Web. https://www.um.edu.mt/profile/etiennedepasquale



-- 
  ++ytti

Re: MSA’s and network architecture

[Etienne-Victor Depasquale via NANOG]

Just to add a bit of fun to the mix - perhaps multi-source agreement was
intended :)

Cheers,

Etienne

On Wed, May 18, 2022 at 3:59 AM Martin Hannigan  wrote:

>
>
> All,
>
> Why do MSA’s matter as related to network architecture?
>
> Thanks all —
>
> -M<
>
>
>
>

-- 
Ing. Etienne-Victor Depasquale
Assistant Lecturer
Department of Communications & Computer Engineering
Faculty of Information & Communication Technology
University of Malta
Web. https://www.um.edu.mt/profile/etiennedepasquale

Re: MSA’s and network architecture

[Saku Ytti]

Asking good questions is much harder than answering good questions.

You could have improved the quality of question here by staging what
MSA is and in what context you've run into this.

I am assuming MSA here is a metro statistical area, and if so, I can
answer for the context of my employer, where MSA has similar functions
as your region (roughly continent), country and pop. MSA is a way to
discuss and name areas, between pop and country for us, not much
different to city in our use.


On Wed, 18 May 2022 at 04:59, Martin Hannigan  wrote:
>
>
>
> All,
>
> Why do MSA’s matter as related to network architecture?
>
> Thanks all —
>
> -M<
>
>
>


-- 
  ++ytti

Re: MSA’s and network architecture

[Mark Tinka]

On 5/18/22 03:55, Martin Hannigan wrote:




All,

Why do MSA’s matter as related to network architecture?


As in "Master Services Agreement"?

Mark.

MSA’s and network architecture

[Martin Hannigan]

All,

Why do MSA’s matter as related to network architecture?

Thanks all —

-M<

Re: Free-ish Linux Netflow collector/analyser options

[Peter Phaal]

Juniper added sFlow support to MX routers in Junos 18.1R1,
https://blog.sflow.com/2018/04/sflow-available-on-juniper-mx-series.html

You might want to consider deploying sFlow instead of IPFIX, particularly
if you are interested in DDoS mitigation where low latency and visibility
into packet headers can be helpful.

-Peter

On Mon, May 16, 2022 at 11:36 AM Matthew Crocker 
wrote:

>
>
> I’m looking for a free-ish Linux open sources Netflow collector/analyser.
> I have 5 Juniper MX routers that will send IPFIX flows to for an ISP
> network.I’m hoping it is something I can run in AWS/EC2 as I don’t want
> to worry about storage again in my lifetime.  Does anyone have any
> recommendations?
>
>
>
> For reporting I would like to generate basic  usage reports to/from
> IP/Subnet/ASN.  It would be great if it could also detect DDoS and activate
> flowspec back into my core routers but that isn’t a requirement
>
>
>
> Thanks
>
>
>
> -Matt
>
>
>

Re: [EXTERNAL] Re: Free-ish Linux Netflow collector/analyser options

[Compton, Rich A]

The ELK stack does a good job of collecting netflow records with the addition 
of Filebeat.  Check out my tattle-tale tool that collects netflow data: 
https://github.com/racompton/tattle-tale It has numerous rules in 
logstash/conf.d to try to just look for spoofed DDoS amplification requests but 
if you remove those rules (except for 
40-ifName.conf
and 
50-reverse-dns.conf)
 it should be a pretty nice netflow collection solution.  If you are looking 
for a free solution to identify DDoS attacks from netflow and generate Flowspec 
rules, check out https://github.com/pavel-odintsov/fastnetmon
Also, here’s a doc for best practices when implementing Flowspec: 
https://www.m3aawg.org/flowspec-BP

-Rich

From: NANOG  on behalf of Joe 
Loiacono 
Date: Monday, May 16, 2022 at 1:11 PM
To: NANOG list , Matthew Crocker 
Subject: [EXTERNAL] Re: Free-ish Linux Netflow collector/analyser options

CAUTION: The e-mail below is from an external source. Please exercise caution 
before opening attachments, clicking links, or following guidance.

Try FlowViewer (analyzing, graphing, tending software) + SiLK (robust, 
high-performance capture software from Carnegie-Mellon).

Pretty full netflow analysis package; free.

See: http://flowviewer.net

Joe
On 5/16/2022 2:34 PM, Matthew Crocker wrote:

I’m looking for a free-ish Linux open sources Netflow collector/analyser.  I 
have 5 Juniper MX routers that will send IPFIX flows to for an ISP network.
I’m hoping it is something I can run in AWS/EC2 as I don’t want to worry about 
storage again in my lifetime.  Does anyone have any recommendations?

For reporting I would like to generate basic  usage reports to/from 
IP/Subnet/ASN.  It would be great if it could also detect DDoS and activate 
flowspec back into my core routers but that isn’t a requirement

Thanks

-Matt