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 <niall.dona...@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 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-boun...@puck.nether.net] On Behalf > Of > Jason Healy > Sent: 12 October 2018 02:37 > To: juniper-nsp <juniper-nsp@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-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 > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp