On Mon, May 20, 2019 at 5:59 PM Seth Mattinen wrote:
> On 5/20/19 4:26 PM, John Kristoff wrote:
> > On Mon, 20 May 2019 23:09:02 +
> > Seth Mattinen wrote:
> >
> >> A good start would be killing any /24 announcement where a covering
> >> aggregate exists.
> > I wouldn't do this as a general
NANOG folks - I recognize that this is rather late notice for your travel
schedules but if you happen to be in the region or have teams in India please
do attend, or forward this. Thanks.
INNOG 2: Call for papers
The following is an open call for presentations for the conference and tutorial
On 5/20/19 4:26 PM, John Kristoff wrote:
On Mon, 20 May 2019 23:09:02 +
Seth Mattinen wrote:
A good start would be killing any /24 announcement where a covering
aggregate exists.
I wouldn't do this as a general rule. If an attacker knows networks are
1) not pointing default, 2) dropping
On Mon, May 20, 2019 at 4:09 PM Seth Mattinen wrote:
> On 5/20/19 3:05 PM, William Herrin wrote:
> > The technique you describe was one variant of FIB Compression. It got
> > some attention around 8 years ago on the IRTF Routing Research Group and
> > some more attention about 5 years ago when
On Mon, 20 May 2019 23:09:02 +
Seth Mattinen wrote:
> A good start would be killing any /24 announcement where a covering
> aggregate exists.
I wouldn't do this as a general rule. If an attacker knows networks are
1) not pointing default, 2) dropping /24's, 3) not validating the
On 5/20/19 3:05 PM, William Herrin wrote:
The technique you describe was one variant of FIB Compression. It got
some attention around 8 years ago on the IRTF Routing Research Group and
some more attention about 5 years ago when several researchers fleshed
out the possible algorithms and
Those numbers were subject to fraudulent acquisition. Some end users of
these subject prefixes are victims. This blanket approach victimizes them
further IMHO. My guess is this direction is why ARIN didn't post the
prefixes in their blog post. They are however in the court docs. I don't
recommend
Brocade (now Extreme) does this on their SLX platform to market 1M FIB boxes as
1.3M FIB boxes after compression. We went with the Juniper MX platform instead,
the relatively small FIB size on the SLX being one of the main sticking points
for me personally.
Nowadays there are also some SLX
On Fri, May 17, 2019 at 9:06 AM Baldur Norddahl
wrote:
> Think about this way to save at least half the size of the FIB with two
> transit providers: Find out which provider has the most prefixes going
> their way. Make a default to them and a route-map that drops every route.
> For the other
I've done that a couple ways. I've used a nProbe license to add the ASN
information in. There are other utilities that do this, but I forgot what they
are.
-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
Midwest-IX
http://www.midwest-ix.com
- Original
It specifically states it uses AS data from the netflow source. I don't have
that ☹
FROM website:
collects NetFlow v8/v9 AS aggregation records
Dennis Burgess,
-Original Message-
From: NANOG On Behalf Of na...@jack.fr.eu.org
Sent: Monday, May 20, 2019 8:43 AM
To: nanog@nanog.org
Gracias Alejandro, I had never considered anti-hijack, anti-DoS, or RTBH
advertisements in this equation. Another knock against filtering based
on prefix size is that it may not have the intended outcome on some
platforms. As I recall reading about one vendor's platform (the ASR9k
perhaps?)
Baldur Norddahl wrote on 5/18/2019 3:57 AM:
...
One router knows about 2 paths, the other about 4 paths. Why? Because
BGP only advertises the route that is in use. Everyone here of course
knows this, I am just pointing it out because culling information
before allowing it to be redistributed
Check out AS-Stats¹, with perl-ip2as
[1] https://github.com/manuelkasper/AS-Stats
On 05/20/2019 03:36 PM, Dennis Burgess via NANOG wrote:
> Please let me clarify. Currently the Netflow data that this customer is
> sending does NOT supply AS information. So I need something to generate that
Please let me clarify. Currently the Netflow data that this customer is
sending does NOT supply AS information. So I need something to generate that
AS data and display. The goal is to figure out where we need to peer next.
Where the top traffic is coming in from (what AS) on our paid
15 matches
Mail list logo
