Discussion:
[j-nsp] dsc interface on qfx5100
Jason Healy
2018-10-12 01:36:57 UTC
Permalink
I'm more of a layer-2 guy, but I'm trying to tighten up a few things on our qfx5100 that acts as our l3 core here at our campus. We use RFC1918 space internally, but I'd like to discard any traffic to these ranges if they aren't one of our known subnets. I have that working with standard "discard" routes.

I've seen some best-practice documents where you can set up the discard (dsc) interface to blackhole traffic, rather than using a direct "discard" route. I thought it might be nice to use that so I could analyze the stuff that's getting discarded (count packets, maybe even mirror or analyze the traffic).

TL;DR: I got dsc working and it is discarding, but the counters aren't incrementing. I need to know if I'm doing it wrong or if this is a "feature" of the qfx5100 similar to its inability to count ipv6 packets...

I've created the interface and assigned an IP with a "destination" I can route to, and a filter to count packets:

dsc {
unit 0 {
family inet {
filter {
output sa-discard-v4;
}
address 10.255.254.2/32 {
destination 10.255.254.1;
}
}
}
}


The filter just counts:

filter sa-discard-v4 {
term default-discard {
then {
count discard-v4-default;
/* Not supported on egress on this platform */
inactive: log;
}
}
}


And I've added some rules to discard the traffic:

[edit routing-options rib inet.0 static]
+ route 10.0.32.64/32 next-hop 10.255.254.1;


That's a live IP on my network, and I've confirmed that traffic is discarded with that route active. Alas, the counters on the interface don't budge:

qfx> show interfaces dsc
Physical interface: dsc, Enabled, Physical link is Up
Interface index: 5, SNMP ifIndex: 5
Type: Software-Pseudo, MTU: Unlimited
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Link flags : None
Last flapped : Never
Input packets : 0
Output packets: 0

Logical interface dsc.0 (Index 548) (SNMP ifIndex 709)
Flags: Down Point-To-Point SNMP-Traps Encapsulation: Unspecified
Protocol inet, MTU: Unlimited
Flags: Sendbcast-pkt-to-re
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.255.254.1, Local: 10.255.254.2


Nor do the firewall counters:

qfx> show firewall filter sa-discard-v4 counter discard-v4-default

Filter: sa-discard-v4
Counters:
Name Bytes Packets
discard-v4-default 0 0



Has anyone set this up with static routing? All the examples use BGP, but I can't imagine why that would make a difference for the reporting if the traffic is correctly discarded.

Thanks,

Jason
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Niall Donaghy
2018-10-12 13:07:06 UTC
Permalink
Hi Jason,

Yes we (large ISP) tried using dsc interfaces (MX series) to count RTBH
traffic and found, 1) they don't count, and 2) IPv6 is unsupported for dsc.
As with many Junos features, there is not parity between IPv4 and IPv6.
That alone bugged us, but especially as the counters did not work, we
abandoned dsc and just made the IPv4 RTBH sink a discard route:

#
# Adjust to suit for VRFs / redistribute to your VRFs
#
set routing-options static route 192.0.2.101/32 discard
set routing-options static route 192.0.2.101/32 no-readvertise
set routing-options rib inet6.0 static route 0100::/64 discard
set routing-options rib inet6.0 static route 0100::/64 no-readvertise

So at the moment, you've got a dsc.0 which is about as useful as static
discard.

If anyone has gotten dsc counting with IPv4, and/or if things have changed
and IPv6 is supported, I'm curious to know.
Right now we're on 15.1F6-S10.4 targeting 17.4R2.4 for our next upgrade -
retesting dsc functionality is somewhat lower than low priority.

Br,
Niall

-----Original Message-----
From: juniper-nsp [mailto:juniper-nsp-***@puck.nether.net] On Behalf Of
Jason Healy
Sent: 12 October 2018 02:37
To: juniper-nsp <juniper-***@puck.nether.net>
Subject: [j-nsp] dsc interface on qfx5100

I'm more of a layer-2 guy, but I'm trying to tighten up a few things on our
qfx5100 that acts as our l3 core here at our campus. We use RFC1918 space
internally, but I'd like to discard any traffic to these ranges if they
aren't one of our known subnets. I have that working with standard
"discard" routes.

I've seen some best-practice documents where you can set up the discard
(dsc) interface to blackhole traffic, rather than using a direct "discard"
route. I thought it might be nice to use that so I could analyze the stuff
that's getting discarded (count packets, maybe even mirror or analyze the
traffic).

TL;DR: I got dsc working and it is discarding, but the counters aren't
incrementing. I need to know if I'm doing it wrong or if this is a
"feature" of the qfx5100 similar to its inability to count ipv6 packets...

I've created the interface and assigned an IP with a "destination" I can
route to, and a filter to count packets:

dsc {
unit 0 {
family inet {
filter {
output sa-discard-v4;
}
address 10.255.254.2/32 {
destination 10.255.254.1;
}
}
}
}


The filter just counts:

filter sa-discard-v4 {
term default-discard {
then {
count discard-v4-default;
/* Not supported on egress on this platform */
inactive: log;
}
}
}


And I've added some rules to discard the traffic:

[edit routing-options rib inet.0 static]
+ route 10.0.32.64/32 next-hop 10.255.254.1;


That's a live IP on my network, and I've confirmed that traffic is discarded
with that route active. Alas, the counters on the interface don't budge:

qfx> show interfaces dsc
Physical interface: dsc, Enabled, Physical link is Up
Interface index: 5, SNMP ifIndex: 5
Type: Software-Pseudo, MTU: Unlimited
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Link flags : None
Last flapped : Never
Input packets : 0
Output packets: 0

Logical interface dsc.0 (Index 548) (SNMP ifIndex 709)
Flags: Down Point-To-Point SNMP-Traps Encapsulation: Unspecified
Protocol inet, MTU: Unlimited
Flags: Sendbcast-pkt-to-re
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.255.254.1, Local: 10.255.254.2


Nor do the firewall counters:

qfx> show firewall filter sa-discard-v4 counter discard-v4-default

Filter: sa-discard-v4
Counters:
Name Bytes
Packets
discard-v4-default 0
0



Has anyone set this up with static routing? All the examples use BGP, but I
can't imagine why that would make a difference for the reporting if the
traffic is correctly discarded.

Thanks,

Jason
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Tom Beecher
2018-10-12 15:20:52 UTC
Permalink
I’m pretty sure we drilled Juniper about the IPv6 discard interface thing a
few months ago and got a feature request in for that. One of our guys
wasted about 2 weeks on that.
Post by Niall Donaghy
Hi Jason,
Yes we (large ISP) tried using dsc interfaces (MX series) to count RTBH
traffic and found, 1) they don't count, and 2) IPv6 is unsupported for dsc.
As with many Junos features, there is not parity between IPv4 and IPv6.
That alone bugged us, but especially as the counters did not work, we
#
# Adjust to suit for VRFs / redistribute to your VRFs
#
set routing-options static route 192.0.2.101/32 discard
set routing-options static route 192.0.2.101/32 no-readvertise
set routing-options rib inet6.0 static route 0100::/64 discard
set routing-options rib inet6.0 static route 0100::/64 no-readvertise
So at the moment, you've got a dsc.0 which is about as useful as static
discard.
If anyone has gotten dsc counting with IPv4, and/or if things have changed
and IPv6 is supported, I'm curious to know.
Right now we're on 15.1F6-S10.4 targeting 17.4R2.4 for our next upgrade -
retesting dsc functionality is somewhat lower than low priority.
Br,
Niall
-----Original Message-----
Jason Healy
Sent: 12 October 2018 02:37
Subject: [j-nsp] dsc interface on qfx5100
I'm more of a layer-2 guy, but I'm trying to tighten up a few things on our
qfx5100 that acts as our l3 core here at our campus. We use RFC1918 space
internally, but I'd like to discard any traffic to these ranges if they
aren't one of our known subnets. I have that working with standard
"discard" routes.
I've seen some best-practice documents where you can set up the discard
(dsc) interface to blackhole traffic, rather than using a direct "discard"
route. I thought it might be nice to use that so I could analyze the stuff
that's getting discarded (count packets, maybe even mirror or analyze the
traffic).
TL;DR: I got dsc working and it is discarding, but the counters aren't
incrementing. I need to know if I'm doing it wrong or if this is a
"feature" of the qfx5100 similar to its inability to count ipv6 packets...
I've created the interface and assigned an IP with a "destination" I can
dsc {
unit 0 {
family inet {
filter {
output sa-discard-v4;
}
address 10.255.254.2/32 {
destination 10.255.254.1;
}
}
}
}
filter sa-discard-v4 {
term default-discard {
then {
count discard-v4-default;
/* Not supported on egress on this platform */
inactive: log;
}
}
}
[edit routing-options rib inet.0 static]
+ route 10.0.32.64/32 next-hop 10.255.254.1;
That's a live IP on my network, and I've confirmed that traffic is discarded
qfx> show interfaces dsc
Physical interface: dsc, Enabled, Physical link is Up
Interface index: 5, SNMP ifIndex: 5
Type: Software-Pseudo, MTU: Unlimited
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Link flags : None
Last flapped : Never
Input packets : 0
Output packets: 0
Logical interface dsc.0 (Index 548) (SNMP ifIndex 709)
Flags: Down Point-To-Point SNMP-Traps Encapsulation: Unspecified
Protocol inet, MTU: Unlimited
Flags: Sendbcast-pkt-to-re
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.255.254.1, Local: 10.255.254.2
qfx> show firewall filter sa-discard-v4 counter discard-v4-default
Filter: sa-discard-v4
Name Bytes
Packets
discard-v4-default 0
0
Has anyone set this up with static routing? All the examples use BGP, but I
can't imagine why that would make a difference for the reporting if the
traffic is correctly discarded.
Thanks,
Jason
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Niall Donaghy
2018-10-12 15:23:57 UTC
Permalink
Funny, I think we did the same thing.

It’s not worth waiting ?? - 48 months for Enhancement Requests to manifest in software.

Even when they do, you have to wait for the bugs to be discovered and fixed, too.



Are you planning to discard the dsc interface (ha!), as we have done?



Br,

Niall





From: Tom Beecher [mailto:***@beecher.cc]
Sent: 12 October 2018 16:21
To: Niall Donaghy <***@geant.org>
Cc: Jason Healy <***@logn.net>; juniper-nsp <juniper-***@puck.nether.net>
Subject: Re: [j-nsp] dsc interface on qfx5100



I’m pretty sure we drilled Juniper about the IPv6 discard interface thing a few months ago and got a feature request in for that. One of our guys wasted about 2 weeks on that.



On Fri, Oct 12, 2018 at 09:07 Niall Donaghy <***@geant.org <mailto:***@geant.org> > wrote:

Hi Jason,

Yes we (large ISP) tried using dsc interfaces (MX series) to count RTBH
traffic and found, 1) they don't count, and 2) IPv6 is unsupported for dsc.
As with many Junos features, there is not parity between IPv4 and IPv6.
That alone bugged us, but especially as the counters did not work, we
abandoned dsc and just made the IPv4 RTBH sink a discard route:

#
# Adjust to suit for VRFs / redistribute to your VRFs
#
set routing-options static route 192.0.2.101/32 <http://192.0.2.101/32> discard
set routing-options static route 192.0.2.101/32 <http://192.0.2.101/32> no-readvertise
set routing-options rib inet6.0 static route 0100::/64 discard
set routing-options rib inet6.0 static route 0100::/64 no-readvertise

So at the moment, you've got a dsc.0 which is about as useful as static
discard.

If anyone has gotten dsc counting with IPv4, and/or if things have changed
and IPv6 is supported, I'm curious to know.
Right now we're on 15.1F6-S10.4 targeting 17.4R2.4 for our next upgrade -
retesting dsc functionality is somewhat lower than low priority.

Br,
Niall

-----Original Message-----
From: juniper-nsp [mailto:juniper-nsp-***@puck.nether.net <mailto:juniper-nsp-***@puck.nether.net> ] On Behalf Of
Jason Healy
Sent: 12 October 2018 02:37
To: juniper-nsp <juniper-***@puck.nether.net <mailto:juniper-***@puck.nether.net> >
Subject: [j-nsp] dsc interface on qfx5100

I'm more of a layer-2 guy, but I'm trying to tighten up a few things on our
qfx5100 that acts as our l3 core here at our campus. We use RFC1918 space
internally, but I'd like to discard any traffic to these ranges if they
aren't one of our known subnets. I have that working with standard
"discard" routes.

I've seen some best-practice documents where you can set up the discard
(dsc) interface to blackhole traffic, rather than using a direct "discard"
route. I thought it might be nice to use that so I could analyze the stuff
that's getting discarded (count packets, maybe even mirror or analyze the
traffic).

TL;DR: I got dsc working and it is discarding, but the counters aren't
incrementing. I need to know if I'm doing it wrong or if this is a
"feature" of the qfx5100 similar to its inability to count ipv6 packets...

I've created the interface and assigned an IP with a "destination" I can
route to, and a filter to count packets:

dsc {
unit 0 {
family inet {
filter {
output sa-discard-v4;
}
address 10.255.254.2/32 <http://10.255.254.2/32> {
destination 10.255.254.1;
}
}
}
}


The filter just counts:

filter sa-discard-v4 {
term default-discard {
then {
count discard-v4-default;
/* Not supported on egress on this platform */
inactive: log;
}
}
}


And I've added some rules to discard the traffic:

[edit routing-options rib inet.0 static]
+ route 10.0.32.64/32 <http://10.0.32.64/32> next-hop 10.255.254.1;


That's a live IP on my network, and I've confirmed that traffic is discarded
with that route active. Alas, the counters on the interface don't budge:

qfx> show interfaces dsc
Physical interface: dsc, Enabled, Physical link is Up
Interface index: 5, SNMP ifIndex: 5
Type: Software-Pseudo, MTU: Unlimited
Device flags : Present Running
Interface flags: Point-To-Point SNMP-Traps
Link flags : None
Last flapped : Never
Input packets : 0
Output packets: 0

Logical interface dsc.0 (Index 548) (SNMP ifIndex 709)
Flags: Down Point-To-Point SNMP-Traps Encapsulation: Unspecified
Protocol inet, MTU: Unlimited
Flags: Sendbcast-pkt-to-re
Addresses, Flags: Is-Preferred Is-Primary
Destination: 10.255.254.1, Local: 10.255.254.2


Nor do the firewall counters:

qfx> show firewall filter sa-discard-v4 counter discard-v4-default

Filter: sa-discard-v4
Counters:
Name Bytes
Packets
discard-v4-default 0
0



Has anyone set this up with static routing? All the examples use BGP, but I
can't imagine why that would make a difference for the reporting if the
traffic is correctly discarded.

Thanks,

Jason
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net <mailto:juniper-***@puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net <mailto:juniper-***@puck.nether.net>
https://puck.nether.net/mailman/listinfo/juniper-nsp
Jason Healy
2018-10-12 16:39:30 UTC
Permalink
Post by Niall Donaghy
Yes we (large ISP) tried using dsc interfaces (MX series) to count RTBH
traffic and found, 1) they don't count, and 2) IPv6 is unsupported for dsc.
That's what I needed to know! Back to standard discard routes it is...

Thanks to you and Tom for saving me any more pain trying to figure this out.

Jason
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Tom Beecher
2018-10-12 17:29:39 UTC
Permalink
No problem!

@Niall : I can't remember if there was something under the hood that made
the discard *interface* more preferable than just a discard *route*. In our
implementation we have a qualified next-hop to send flagged traffic to a
local collector box first, and only discard if that's not reachable, and
we're not doing anything on dsc.0 that a straight discard route couldn't
do.

Otherwise yeah, running a count filter on dsc for metrics about what the
traffic was was kinda the entire point I thought. :)
Post by Jason Healy
Post by Niall Donaghy
Yes we (large ISP) tried using dsc interfaces (MX series) to count RTBH
traffic and found, 1) they don't count, and 2) IPv6 is unsupported for
dsc.
That's what I needed to know! Back to standard discard routes it is...
Thanks to you and Tom for saving me any more pain trying to figure this out.
Jason
_______________________________________________
https://puck.nether.net/mailman/listinfo/juniper-nsp
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
Saku Ytti
2018-10-13 09:15:10 UTC
Permalink
Post by Niall Donaghy
Yes we (large ISP) tried using dsc interfaces (MX series) to count RTBH
traffic and found, 1) they don't count, and 2) IPv6 is unsupported for dsc.
As with many Junos features, there is not parity between IPv4 and IPv6.
That alone bugged us, but especially as the counters did not work, we
I'm pretty convinced I've had filter counters work on discard
interface, but it's like 15 years ago, so I may misremember.

Being MX, you can still count the static route discard next hop.

***@r24.labxtx01.us.bb-re1> request pfe execute target fpc0 command
"show jnh 0 exception" |match "discard route"
discard route DISC( 66) 0 0
discard route IPv6 DISC(102) 0 0
dsc ifl discard route DISC( 96) 0 0

We're collecting all of the NPU counters and dumping them into a druid
for visual presentation with pivot.

There is some benefit using this method even if counters would work,
because this method will tell you which linecard and which NPU,
allowing you to discriminate ingress of packets to specific NPU. And
of course in any reasonable collection system, you just ignore the NPU
and LC labels and you'll get aggregate discards.
--
++ytti
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp
s***@nethelp.no
2018-10-13 12:44:33 UTC
Permalink
Post by Saku Ytti
Post by Niall Donaghy
Yes we (large ISP) tried using dsc interfaces (MX series) to count RTBH
traffic and found, 1) they don't count, and 2) IPv6 is unsupported for dsc.
As with many Junos features, there is not parity between IPv4 and IPv6.
That alone bugged us, but especially as the counters did not work, we
I'm pretty convinced I've had filter counters work on discard
interface, but it's like 15 years ago, so I may misremember.
I can confirm that filter counters work on the discard interface at
least for IPv4 and JunOS 15.1R6.

Steinar Haug, Nethelp consulting, ***@nethelp.no
_______________________________________________
juniper-nsp mailing list juniper-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Loading...