Mailing List Archive: Decoding DDOS messages

Decoding DDOS messages

Mar 18, 2020, 6:46 AM

Post #1 of 18 (6021 views)

Questions about the ddos-protection "features". We're on a qfx5100-48 running 16.1. I know that folks on the list aren't always big fans of ddos-protection; I'm just trying to understand what is triggering it so I can make decisions about tuning/disabling/ignoring it.

We are not a service provider; we're an end site running a flat L2 network (LAN) with the QFX as our L3 core for IRB and routing to our ISP. Since the QFX is seeing all the BUM traffic I'm curious if ddos-protection is being triggered as a result of seeing all the L2 packets.

In the past month we've seen violations for the following packet types:

IPMCAST-miss (lots of this one!)
ARP
TTL
Redirect
L3MTU-fail
RESOLVE
L3NHOP

I'm trying to figure out if these violations are normal in a LAN environment. For example, we have a lot of Apple devices that are sending mDNS all day long; that might trigger the MCAST counters. When our students change classes (all at the same time), that might cause a spike in ARP traffic as everyone comes online when they open their laptops.

Does anyone have a link to documentation for these packet types? The Juniper docs don't give any examples; you just get descriptions like this:

arp: ARP traffic

So is that all ARP? ARP that the switch needs to answer for? Similar for the other packet types: are these thresholds for packets that the switch is processing (sent to the RE), or just for any traffic that is seen on any interface? If it's just an issue of too much stuff going to the RE I can firewall it off so long as I know it's spurious.

Sorry if I'm not asking the right questions... I'm just trying to figure out if these errors are actually problems that I need to track down, or if the default reporting is just too noisy.

Thanks,

Jason
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: Decoding DDOS messages [ In reply to ]

Mar 18, 2020, 7:39 AM

Post #2 of 18 (6021 views)

Hey Jason,

> Questions about the ddos-protection "features". We're on a qfx5100-48 running 16.1. I know that folks on the list aren't always big fans of ddos-protection; I'm just trying to understand what is triggering it so I can make decisions about tuning/disabling/ignoring it.

I am a big fan, it's great feature everyone should be running and
tuning correctly. Unfortunately even non-broken lo0 filter is
extremely uncommon, even MX book has fundamentally broken example, as
is CYMRU example. And ddos-protection may be even more complicated.

I'm not very familiar how it works on QFX5k, I'm more aware of MX
behaviour, where it's really great.

> We are not a service provider; we're an end site running a flat L2 network (LAN) with the QFX as our L3 core for IRB and routing to our ISP. Since the QFX is seeing all the BUM traffic I'm curious if ddos-protection is being triggered as a result of seeing all the L2 packets.

Your L2 should be in its virtual-switch/vpls (doesn't imply VPLS)
instance with forwarding-plane filter policing BUM. But unrelatd to
subject.

> IPMCAST-miss (lots of this one!)

Probably punts for programming flow, and subsequent will be HW
switched. You may want to have ACL to drop all MCAST traffic at edge.
This should be 0 if you don't actually run multicast.

> ARP

Self-explanatory? You shouldn't want to see this exceeded, ideally you
should police this on IFD level, but I'm not sure if QFX5k can, MX
can.

> TTL

TTL exceeded message. Normal to hit this policer in uloops.

> Redirect

IP redirect, you probably want to disable them at network edge. This
should be 0.

> L3MTU-fail

Egress MTU was too small for packet. It is punted for potentially ICMP
message generation. Depending on config expected or unexpected.

> RESOLVE

Traffic hitting connected DADDR which is not in ARP cache, we need to
punt it for ARP resolution. Normal to see as there is constant
background traffic to every DADDR.

> L3NHOP

Unsure.

> So is that all ARP? ARP that the switch needs to answer for? Similar for the other packet types: are these thresholds for packets that the switch is processing (sent to the RE), or just for any traffic that is seen on any interface? If it's just an issue of too much stuff going to the RE I can firewall it off so long as I know it's spurious.

It's ARP packets verbatim (see RESOLVE which is non ARP packet
triggering ARP resolution). Originally when ddos-protection was
implemented resolve was not implemented, and RESOLVE packet was what
ever classifier it hit, so if you sent BGP packets to unarpable DADDR
it was eating BGP policer PPS, so you could easily get targets core
iBGP down, and there was nothing they could do to stop you.

> Sorry if I'm not asking the right questions... I'm just trying to figure out if these errors are actually problems that I need to track down, or if the default reporting is just too noisy.
>
> Thanks,
>
> Jason
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: Decoding DDOS messages [ In reply to ]

beecher at beecher

Mar 18, 2020, 7:51 AM

Post #3 of 18 (6021 views)

This is the most recent Juniper document I had bookmarked for the QFX.

https://www.juniper.net/documentation/en_US/junos/topics/reference/configuration-statement/protocols-edit-ddos-qfx-series.html

I agree with Saku that the ddos-policer is a good tool to use, but as he
said it requires turning for your specific environment to be at its most
useful. I don't want to discount the opinions of those who dislike it, but
many complaints about it seem to boil down to "the defaults didn't work, I
didn't tune it, therefore I hate it".

On Wed, Mar 18, 2020 at 10:42 AM Saku Ytti <saku@ytti.fi> wrote:

> Hey Jason,
>
> > Questions about the ddos-protection "features". We're on a qfx5100-48
> running 16.1. I know that folks on the list aren't always big fans of
> ddos-protection; I'm just trying to understand what is triggering it so I
> can make decisions about tuning/disabling/ignoring it.
>
> I am a big fan, it's great feature everyone should be running and
> tuning correctly. Unfortunately even non-broken lo0 filter is
> extremely uncommon, even MX book has fundamentally broken example, as
> is CYMRU example. And ddos-protection may be even more complicated.
>
> I'm not very familiar how it works on QFX5k, I'm more aware of MX
> behaviour, where it's really great.
>
> > We are not a service provider; we're an end site running a flat L2
> network (LAN) with the QFX as our L3 core for IRB and routing to our ISP.
> Since the QFX is seeing all the BUM traffic I'm curious if ddos-protection
> is being triggered as a result of seeing all the L2 packets.
>
> Your L2 should be in its virtual-switch/vpls (doesn't imply VPLS)
> instance with forwarding-plane filter policing BUM. But unrelatd to
> subject.
>
> > IPMCAST-miss (lots of this one!)
>
> Probably punts for programming flow, and subsequent will be HW
> switched. You may want to have ACL to drop all MCAST traffic at edge.
> This should be 0 if you don't actually run multicast.
>
> > ARP
>
> Self-explanatory? You shouldn't want to see this exceeded, ideally you
> should police this on IFD level, but I'm not sure if QFX5k can, MX
> can.
>
> > TTL
>
> TTL exceeded message. Normal to hit this policer in uloops.
>
> > Redirect
>
> IP redirect, you probably want to disable them at network edge. This
> should be 0.
>
> > L3MTU-fail
>
> Egress MTU was too small for packet. It is punted for potentially ICMP
> message generation. Depending on config expected or unexpected.
>
> > RESOLVE
>
> Traffic hitting connected DADDR which is not in ARP cache, we need to
> punt it for ARP resolution. Normal to see as there is constant
> background traffic to every DADDR.
>
> > L3NHOP
>
> Unsure.
>
> > So is that all ARP? ARP that the switch needs to answer for? Similar
> for the other packet types: are these thresholds for packets that the
> switch is processing (sent to the RE), or just for any traffic that is seen
> on any interface? If it's just an issue of too much stuff going to the RE
> I can firewall it off so long as I know it's spurious.
>
> It's ARP packets verbatim (see RESOLVE which is non ARP packet
> triggering ARP resolution). Originally when ddos-protection was
> implemented resolve was not implemented, and RESOLVE packet was what
> ever classifier it hit, so if you sent BGP packets to unarpable DADDR
> it was eating BGP policer PPS, so you could easily get targets core
> iBGP down, and there was nothing they could do to stop you.
>
> > Sorry if I'm not asking the right questions... I'm just trying to figure
> out if these errors are actually problems that I need to track down, or if
> the default reporting is just too noisy.
> >
> > Thanks,
> >
> > Jason
> > _______________________________________________
> > juniper-nsp mailing list juniper-nsp@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/juniper-nsp
>
>
>
> --
> ++ytti
> _______________________________________________
> juniper-nsp mailing list juniper-nsp@puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: Decoding DDOS messages [ In reply to ]

Mar 18, 2020, 8:01 AM

Post #4 of 18 (6021 views)

On Wed, 18 Mar 2020 14:39:19 +0000
Saku Ytti <saku@ytti.fi> wrote:

> Unfortunately even non-broken lo0 filter is extremely uncommon, even
> MX book has fundamentally broken example, as is CYMRU example.

Team Cymru only lists a Cisco BGP, general NTP (which includes a
Juniper example), and Juniper IP multicast template publicly now:

<https://www.team-cymru.com/templates.html>

If you are referring to one of those, there is an email right on the
page to contact them and you should if there are mistakes and
improvements. They will welcome input. I edited the NTP template and
helped facilitate the IP multicast one Lenny did, so if there is a
problem with either of those I'd be interested to know about it, but I
am no longer an employee of Team Cymru so I can't fix them.

The other templates, including a generic Juniper template you can
find via a net search, but not through Team Cymru's website navigation,
are many years old and no longer maintained. It would be unwise to
trust or relay on those.

I have some example templates for more recent stuff work I've done, but
does not cover currently this thread's case and may be less
generically applicable. They are probably also not perfect, but people
are welcome to submit an issue there and I'll do my best to keep them
maintained:

<https://github.com/jtkristoff/junos>

John
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: Decoding DDOS messages [ In reply to ]

Mar 18, 2020, 9:02 AM

Post #5 of 18 (6020 views)

On Wed, 18 Mar 2020 at 17:01, John Kristoff <jtk@depaul.edu> wrote:

> <https://github.com/jtkristoff/junos>

It is completely broken, you use 'port' so you expose every port in your system.

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: Decoding DDOS messages [ In reply to ]

Mar 18, 2020, 9:16 AM

Post #6 of 18 (6020 views)

On Wed, 18 Mar 2020 16:02:09 +0000
Saku Ytti <saku@ytti.fi> wrote:

> It is completely broken, you use 'port' so you expose every port in your system.

Ha, OK thanks. I think that would require some not so easy spoofing
unless I'm missing something. We can convert any statement that just
uses port to directional, which I think will require additional rules
to tighten it up. Feel free to submit example configs.

John
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: Decoding DDOS messages [ In reply to ]

Mar 18, 2020, 9:18 AM

Post #7 of 18 (6020 views)

I'm your BGP speaker.

I set SPORT to 179
I access your SSH port

On Wed, 18 Mar 2020 at 18:16, John Kristoff <jtk@depaul.edu> wrote:
>
> On Wed, 18 Mar 2020 16:02:09 +0000
> Saku Ytti <saku@ytti.fi> wrote:
>
> > It is completely broken, you use 'port' so you expose every port in your system.
>
> Ha, OK thanks. I think that would require some not so easy spoofing
> unless I'm missing something. We can convert any statement that just
> uses port to directional, which I think will require additional rules
> to tighten it up. Feel free to submit example configs.
>
> John

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: Decoding DDOS messages [ In reply to ]

Mar 18, 2020, 9:19 AM

Post #8 of 18 (6020 views)

This wasn't the only problem, there are many issues, it's normal, I've
not read single lo0 filter in real network which isn't fundamentally
broken. Trying to tactically address the problems is waste of time
when redesign is needed.

On Wed, 18 Mar 2020 at 18:18, Saku Ytti <saku@ytti.fi> wrote:
>
> I'm your BGP speaker.
>
> I set SPORT to 179
> I access your SSH port
>
> On Wed, 18 Mar 2020 at 18:16, John Kristoff <jtk@depaul.edu> wrote:
> >
> > On Wed, 18 Mar 2020 16:02:09 +0000
> > Saku Ytti <saku@ytti.fi> wrote:
> >
> > > It is completely broken, you use 'port' so you expose every port in your system.
> >
> > Ha, OK thanks. I think that would require some not so easy spoofing
> > unless I'm missing something. We can convert any statement that just
> > uses port to directional, which I think will require additional rules
> > to tighten it up. Feel free to submit example configs.
> >
> > John
>
>
>
> --
> ++ytti

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [EXT] Re: Decoding DDOS messages [ In reply to ]

Mar 18, 2020, 9:28 AM

Post #9 of 18 (6020 views)

On Wed, Mar 18, 2020 at 11:16:54AM -0500, John Kristoff wrote:
> On Wed, 18 Mar 2020 16:02:09 +0000
> Saku Ytti <saku@ytti.fi> wrote:
>
> > It is completely broken, you use 'port' so you expose every port in your system.
>
> Ha, OK thanks. I think that would require some not so easy spoofing
> unless I'm missing something. We can convert any statement that just
> uses port to directional, which I think will require additional rules
> to tighten it up. Feel free to submit example configs.

To bypass your filter, just SSH using source port 179 (bgp), destination port 22, and you are in (as long as you are a BGP neighbor for this specific term):

filter loopback-v4 {
term bgp {
from {
source-prefix-list {
bgp-neighbors-v4;
}
protocol tcp;
port bgp;
}
then {
count bgp;
accept;
}
}

Fix:

/* allow inbound BGP connections */
term bgp-inbound {
from {
source-prefix-list {
bgp-neighbors-v4;
}
protocol tcp;
source-port 1024-65535;
destination-port bgp;
}
then {
count bgp;
accept;
}
}
/* allow reply packets to outbound BGP connections */
term bgp-replies {
from {
source-prefix-list {
bgp-neighbors-v4;
}
protocol tcp;
source-port bgp;
destination-port 1024-65535;
tcp-established;
}
then {
count bgp-replies;
accept;
}
}
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: Decoding DDOS messages [ In reply to ]

Mar 18, 2020, 9:30 AM

Post #10 of 18 (6020 views)

On Wed, 18 Mar 2020 16:18:18 +0000
Saku Ytti <saku@ytti.fi> wrote:

> I set SPORT to 179
> I access your SSH port

Yep, I get all that. I can tighten that up. Care to show us how you
do loopback filters?

John
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [EXT] Re: Decoding DDOS messages [ In reply to ]

Mar 18, 2020, 9:33 AM

Post #11 of 18 (6020 views)

On Wed, 18 Mar 2020 at 18:28, Chuck Anderson <cra@wpi.edu> wrote:

> term bgp-inbound {
> from {
> source-prefix-list {
> bgp-neighbors-v4;
> }
> protocol tcp;
> source-port 1024-65535;
This is immaterial, you don't care what this SPORT is. Be liberal.

> term bgp-replies {
> from {
> source-prefix-list {
> bgp-neighbors-v4;
> }
> protocol tcp;
> source-port bgp;
> destination-port 1024-65535;
This you care very much, and ephemeral range in your device is
49125-65535, 1024-49124 could have something listening in them.

If you are in position where you only have customers and RR, no peers
or anything else where there is no 'owner'. You should set your
customer BGP to passive, so customer _always_ starts the BGP, you will
never try to start it. Equally you should set your RR to passive, so
clients always connect to RR, RR never.
This will allow greatly simplified filters for BGP, much safer, as
well as trivial way to police iBGP and eBGP separately, in times when
dddos-protection was not available.

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: Decoding DDOS messages [ In reply to ]

Mar 18, 2020, 9:36 AM

Post #12 of 18 (6020 views)

On Wed, 18 Mar 2020 at 18:30, John Kristoff <jtk@depaul.edu> wrote:

> Yep, I get all that. I can tighten that up. Care to show us how you
> do loopback filters?

It is situational, it's hard to come up with one-size-fits-all. One
approach would be basic skeleton, on top of which people then expand
what they need, which would likely be also then broken. Another option
would be to write exhaustive one, but exhaustive one necessarily has
compromises, so then people who don't need everything still take those
compromises.
Really Juniper would be in the best position to automatically generate
lo0 filter when none is provided, which would be really really good,
not optimal, but really good. Bit of like generated-LPTS.

I'm not sure if there is a utility in public template. But it's
something that I do occasionally think about, not just Junos or just
firewall, but also BGP, to show how to normalise BGP behaviour (no one
knows what their BGP policy is very accurately, as in almost every
case BGP policy is 'what ever is vendor default', and when you have
multivendor network, you have different policy in different devices).

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [EXT] Re: Decoding DDOS messages [ In reply to ]

Mar 18, 2020, 9:53 AM

Post #13 of 18 (6020 views)

On Wed, Mar 18, 2020 at 06:33:11PM +0200, Saku Ytti wrote:
> On Wed, 18 Mar 2020 at 18:28, Chuck Anderson <cra@wpi.edu> wrote:
>
> > term bgp-inbound {
> > from {
> > source-prefix-list {
> > bgp-neighbors-v4;
> > }
> > protocol tcp;
> > source-port 1024-65535;
> This is immaterial, you don't care what this SPORT is. Be liberal.

True--the peer controls it so it doesn't matter what it is.

> > term bgp-replies {
> > from {
> > source-prefix-list {
> > bgp-neighbors-v4;
> > }
> > protocol tcp;
> > source-port bgp;
> > destination-port 1024-65535;
> This you care very much, and ephemeral range in your device is
> 49125-65535, 1024-49124 could have something listening in them.

Thanks, this is useful. From the BSD shell it appears to be 49160-65535:

% sysctl -a | grep -E 'portrange.*(first|last)'
net.inet.ip.portrange.lowfirst: 1023
net.inet.ip.portrange.lowlast: 647
net.inet.ip.portrange.first: 49160
net.inet.ip.portrange.last: 65535
net.inet.ip.portrange.hifirst: 49160
net.inet.ip.portrange.hilast: 65535

> If you are in position where you only have customers and RR, no peers
> or anything else where there is no 'owner'. You should set your
> customer BGP to passive, so customer _always_ starts the BGP, you will
> never try to start it. Equally you should set your RR to passive, so
> clients always connect to RR, RR never.
> This will allow greatly simplified filters for BGP, much safer, as
> well as trivial way to police iBGP and eBGP separately, in times when
> dddos-protection was not available.

Good idea.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [EXT] Re: Decoding DDOS messages [ In reply to ]

Mar 18, 2020, 9:57 AM

Post #14 of 18 (6020 views)

On Wed, 18 Mar 2020 at 18:53, Chuck Anderson <cra@wpi.edu> wrote:

> 49125-65535, 1024-49124 could have something listening in them.
>
> Thanks, this is useful. From the BSD shell it appears to be 49160-65535:

You are correct. I debated between the sysctl or standard, and I'm not
sure if I made the right call by going standard. At the time my
justification was, what if this is platform dependent, and I didn't
want to do the work to figure out if it's always 49160 in every
platfrom and junos and ended up with more liberal standard ephemeral
range.

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [EXT] Re: Decoding DDOS messages [ In reply to ]

Mar 18, 2020, 11:08 AM

Post #15 of 18 (6018 views)

On Wed, Mar 18, 2020 at 06:36:58PM +0200, Saku Ytti wrote:
> On Wed, 18 Mar 2020 at 18:30, John Kristoff <jtk@depaul.edu> wrote:
>
> > Yep, I get all that. I can tighten that up. Care to show us how you
> > do loopback filters?
>
> It is situational, it's hard to come up with one-size-fits-all. One
> approach would be basic skeleton, on top of which people then expand
> what they need, which would likely be also then broken. Another option
> would be to write exhaustive one, but exhaustive one necessarily has
> compromises, so then people who don't need everything still take those
> compromises.
> Really Juniper would be in the best position to automatically generate
> lo0 filter when none is provided, which would be really really good,
> not optimal, but really good. Bit of like generated-LPTS.

I disagree that they would be any good at it--it would likely be filled with the same holes as we've seen here given network vendors' poor history in this area (see bad filters taking out IS-IS, IPv6 ND, and NFS traffic on EX4500 switches for example). As this thread points out, getting the filters right is hard. If they were hardcoded by Juniper, that would just make them opaque and unchangeable. We'd all benefit from much more transparency and sharing of experiences.

> I'm not sure if there is a utility in public template. But it's
> something that I do occasionally think about, not just Junos or just
> firewall, but also BGP, to show how to normalise BGP behaviour (no one
> knows what their BGP policy is very accurately, as in almost every
> case BGP policy is 'what ever is vendor default', and when you have
> multivendor network, you have different policy in different devices).

The utility is in documenting best practices and concepts in how the public template works so that it can be adjusted as necessary. Having something documented, then claiming "that is wrong" without providing concrete corrections/suggestions is not helpful, especially if everyone out there is using the CYMRU templates or the MX book because that is the best information available.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: [EXT] Re: Decoding DDOS messages [ In reply to ]

Mar 18, 2020, 11:24 AM

Post #16 of 18 (6018 views)

On Wed, 18 Mar 2020 at 20:09, Chuck Anderson <cra@wpi.edu> wrote:

> I disagree that they would be any good at it--it would likely be filled with the same holes as we've seen here given network vendors' poor history in this area (see bad filters taking out IS-IS, IPv6 ND, and NFS traffic on EX4500 switches for example). As this thread points out, getting the filters right is hard. If they were hardcoded by Juniper, that would just make them opaque and unchangeable. We'd all benefit from much more transparency and sharing of experiences.

Juniper has hidden group which is applied to your config, default lo0
filter could come from there, when not configured. And it could evolve
via JTAC. It can consume information no external site can consume.

--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: Decoding DDOS messages [ In reply to ]

Mar 18, 2020, 12:31 PM

Post #17 of 18 (6018 views)

Saku,

Thank you for your responses. I'm trying to learn about this as I go...

On Mar 18, 2020, at 10:39 AM, Saku Ytti <saku@ytti.fi> wrote:
>
> Your L2 should be in its virtual-switch/vpls (doesn't imply VPLS)
> instance with forwarding-plane filter policing BUM. But unrelatd to
> subject.

You might need to email me off-list for that one... I'm not sure if I'm following the theory on that.

>> IPMCAST-miss (lots of this one!)
>
> Probably punts for programming flow, and subsequent will be HW
> switched. You may want to have ACL to drop all MCAST traffic at edge.
> This should be 0 if you don't actually run multicast.

We're applying an l2 filter at the vlan level to scrub all but well-known multicast on this switch. Can it still get to the CPU even if blocked in this manner? Or is the flow assignment done prior to l2 firewalling?

>> ARP
>
> Self-explanatory? You shouldn't want to see this exceeded, ideally you
> should police this on IFD level, but I'm not sure if QFX5k can, MX
> can.

Assuming there is not malicious traffic, wouldn't exceeding this counter imply that the defaults are tuned too low? We are a small school with ~1500 devices. While we might get bursts of ARP traffic at peak times (like when students move between classes), I would be surprised if it was so high as to be a concern.

>> TTL
>
> TTL exceeded message. Normal to hit this policer in uloops.

We're spoke-and-hub, static routing, so not expecting a lot of microloops due to convergence. Possible we're seeing this from "lost" packets being misrouted to our ISP (then routed back).

>> Redirect
>
> IP redirect, you probably want to disable them at network edge. This
> should be 0.

Is there an easy way to find/locate IP redirects? I'm curious if these are sourced from our ISP.

>> L3MTU-fail
>
> Egress MTU was too small for packet. It is punted for potentially ICMP
> message generation. Depending on config expected or unexpected.

We should be jumbo (9216) throughout, including uplink to our ISP. Any way to narrow these down?

Thanks for all the replies, I'm starting to get a better idea on this.

Jason
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: Decoding DDOS messages [ In reply to ]

adamv0025 at netconsultings

Mar 22, 2020, 9:57 PM

Post #18 of 18 (5994 views)

> Saku Ytti
> Sent: Wednesday, March 18, 2020 4:37 PM
>
> On Wed, 18 Mar 2020 at 18:30, John Kristoff <jtk@depaul.edu> wrote:
>
> > Yep, I get all that. I can tighten that up. Care to show us how you
> > do loopback filters?
>
> Really Juniper would be in the best position to automatically generate
> lo0 filter when none is provided, which would be really really good, not
> optimal, but really good. Bit of like generated-LPTS.
>
That, but most importantly separate control-plane and management-plane
security like in XR.
If one could do this in Junos:
XR-example: control-plane management-plane inband interface xxxxxxx allow
SSH
-listing only my core facing and/or oob mgmt ports.
Then it would not matter that operator's iACL or lo0 filter has holes
(allowing ssh from BGP source port).

adam

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp