[j-nsp] Flowspec not filtering traffic.

Gustavo Santos gustkiller at gmail.com
Sun Sep 18 15:01:06 EDT 2022


Weird, show route flow validation detail came out empty.

But on PFE looks like rules are been accepted.

But when DDoS traffic comes with high volume, all of them are forwarded to
customers instead of being dropped at the edge..

{master}
gustavo at MX10K3> show route flow validation detail

inet.0:

{master}

show filter inside pfe ( shows only this index for flowspec)

65024  Classic    -         __flowspec_default_inet__

SMPC0(MX10003-CORE vty)# show filter index 65024 program
Filter index = 65024
Optimization flag: 0xf7
Filter notify host id = 0
Pfe Mask = 0xFFFFFFFF
jnh inst = 0x0
Filter properties: None
Filter state = CONSISTENT
term interface-group
term priority 0
    interface-group
         0
        2-255
        true branch to match action in rule default-term
        false branch to match protocol in rule 4?.1?3.1?9.2?9,*,proto=1
term 4?.1?3.1?9.209,*,proto=1
term priority 0
    protocol
         1
        6  -> port in 1?8.2?8.?4.15,*,proto=6,port=123
        17  -> port in 1?8.2?8.?4.15,*,proto=17,port=123
        false branch to match action in rule default-term
    destination-address
        45.1?3.1?9.209/32
        1?8.2?8.8?.4/32 -> action in 168.228.84.4,*,proto=1
        1?8.2?8.8?.15/32 -> action in 168.228.84.15,*,proto=1
        1?8.2?8.8?.34/32 -> action in 168.228.84.34,*,proto=1
        1?8.2?8.8?.61/32 -> action in 168.228.84.61,*,proto=1
        false branch to match action in rule default-term

    then
        discard
        count 4?.1?3.1?9.209,*,proto=1
term 1?8.2?8.8?.4,*,proto=1
term priority 0

    then
        discard
        count 1?8.2?8.84.4,*,proto=1
term 1?8.2?8.84.15,*,proto=1
term priority 0

    then
        discard
        count 168.228.84.15,*,proto=1
term 168.228.84.15,*,proto=6,port=123
term priority 0
    port
         123
        false branch to match action in rule default-term
    destination-address
        1?8.2?8.?4.15/32
        false branch to match action in rule default-term

    then
        discard
        count 1?8.2?8.?4.15,*,proto=6,port=123
term 1?8.2?8.?4.15,*,proto=17,port=123
term priority 0
    port
         123
        false branch to match port in rule 1?8.2?8.?4.34,*,proto=17,port=0
    destination-address
        1?8.2?8.34.15/32
        false branch to match port in rule 1?8.2?8.84.34,*,proto=17,port=0

    then
        discard
        count 1?8.2?8.84.15,*,proto=17,port=123
term 1?8.2?8.84.34,*,proto=1
term priority 0

    then
        discard
        count 1?8.2?8.84.34,*,proto=1
term 1?8.2?8.84.34,*,proto=17,port=0
term priority 0
    port
         0
        false branch to match port in rule 1?8.2?8.84.34,*,proto=17,port=123
    destination-address
        1?8.2?8.84.34/32
        false branch to match port in rule 1?8.2?8.84.34,*,proto=17,port=123

    then
        discard
        count 1?8.2?8.84.34,*,proto=17,port=0
term 1?8.2?8.84.34,*,proto=17,port=123
term priority 0
    port
         123
        false branch to match port in rule
1?8.2?8.84.190,*,proto=17,port=9001
    destination-address
        1?8.2?8.84.34/32
        false branch to match port in rule
1?8.2?8.84.190,*,proto=17,port=9001

    then
        discard
        count 1?8.2?8.84.34,*,proto=17,port=123
term 1?8.2?8.84.61,*,proto=1
term priority 0

    then
        discard
        count 1?8.2?8.84.61,*,proto=1
term 1?8.2?8.84.190,*,proto=17,port=9001
term priority 0
    port
         9001
        false branch to match action in rule default-term
    destination-address
        1?8.2?8.84.190/32
        false branch to match action in rule default-term

    then
        discard
        count 1?8.2?8.84.190,*,proto=17,port=9001
term default-term
term priority 0

    then
        accept


Em dom., 18 de set. de 2022 às 03:57, Saku Ytti <saku at ytti.fi> escreveu:

> Actually I think I'm confused, I'm just not accustomed to seeing other
> than 0:0 as rate, but it may be thaat the first 0 doesn't matter.
>
> I would verify 'show route flow validation detail' as well as verify
> presence of policers if any (in PFE 'show filter counters').
>
> I'd also look at the filter more closely at PFE:
> - show filter (get the index)
> - show filter index X program
>
>
>
> On Sun, 18 Sept 2022 at 09:39, Saku Ytti <saku at ytti.fi> wrote:
> >
> > Are you exceeding the configured rate for the policer? Did you expect
> > to drop at any rate? The rule sets a non-0 policing rate.
> >
> > On Sat, 17 Sept 2022 at 17:42, Gustavo Santos <gustkiller at gmail.com>
> wrote:
> > >
> > > Hi Saku,
> > >
> > > PS: Real ASN was changed to 65000 on the configuration snippet.
> > >
> > >
> > >
> > > show route table inetflow.0 extensive
> > >
> > > 1x8.2x8.84.34,*,proto=17,port=0/term:7 (1 entry, 1 announced)
> > > TSI:
> > > KRT in dfwd;
> > > Action(s): discard,count
> > > Page 0 idx 0, (group KENTIK_FS type Internal) Type 1 val 0x63b7c098
> (adv_entry)
> > >    Advertised metrics:
> > >      Flags: NoNexthop
> > >      Localpref: 100
> > >      AS path: [65000 I
> > >      Communities: traffic-rate:52873:0
> > >     Advertise: 00000001
> > > Path 1x8.2x8.84.34,*,proto=17,port=0
> > > Vector len 4.  Val: 0
> > >         *Flow   Preference: 5
> > >                 Next hop type: Fictitious, Next hop index: 0
> > >                 Address: 0x5214bfc
> > >                 Next-hop reference count: 22
> > >                 Next hop:
> > >                 State: <Active SendNhToPFE>
> > >                 Local AS: 65000
> > >                 Age: 8w0d 20:30:33
> > >                 Validation State: unverified
> > >                 Task: RT Flow
> > >                 Announcement bits (2): 0-Flow 1-BGP_RT_Background
> > >                 AS path: I
> > >                 Communities: traffic-rate:65000:0
> > >
> > > show firewall
> > >
> > > Filter: __flowspec_default_inet__
> > > Counters:
> > > Name                                                Bytes
> Packets
> > > 1x8.2x8.84.34,*,proto=17,port=0               19897391083
> 510189535
> > >
> > >
> > > BGP Group
> > >
> > > {master}[edit protocols bgp group KENTIK_FS]
> > > type internal;
> > > hold-time 720;
> > > mtu-discovery;
> > > family inet {
> > >     unicast;
> > >     flow {
> > >         no-validate flowspec-import;
> > >         }
> > >     }
> > > }
> > >
> > >
> > >
> > > Import policy
> > > {master}[edit]
> > > gustavo at MX10K3# edit policy-options policy-statement flowspec-import
> > >
> > > {master}[edit policy-options policy-statement flowspec-import]
> > > gustavo at MX10K3# show
> > > term 1 {
> > >     then accept;
> > > }
> > >
> > > IP transit interface
> > >
> > > {master}[edit interfaces ae0 unit 10]
> > > gustavo at MX10K3# show
> > > vlan-id 10;
> > > family inet {
> > >     mtu 1500;
> > >     filter {
> > >         inactive: input ddos;
> > >     }
> > >     sampling {
> > >         input;
> > >     }
> > >     address x.x.x.x.x/31;
> > > }
> > >
> > >
> > > Em sáb., 17 de set. de 2022 às 03:00, Saku Ytti <saku at ytti.fi>
> escreveu:
> > >>
> > >> Can you provide some output.
> > >>
> > >> Like 'show route table inetflow.0 extensive' and config.
> > >>
> > >> On Sat, 17 Sept 2022 at 05:05, Gustavo Santos via juniper-nsp
> > >> <juniper-nsp at puck.nether.net> wrote:
> > >> >
> > >> > Hi,
> > >> >
> > >> > We have noticed that flowspec is not working or filtering as
> expected.
> > >> > Trying a DDoS detection and rule generator tool, and we noticed
> that the
> > >> > flowspec rule is installed,
> > >> > the filter counter is increasing , but no filtering at all.
> > >> >
> > >> > For example DDoS traffic from source port UDP port 123 is coming
> from an
> > >> > Internet Transit
> > >> > facing interface AE0.
> > >> > The destination of this traffic is to a customer Interface
> ET-0/0/10.
> > >> >
> > >> > Even with all information and "show" commands confirming that the
> traffic
> > >> > has been filtered, customer and snmp and netflow from the customer
> facing
> > >> > interface is showing that the "filtered" traffic is hitting the
> destination.
> > >> >
> > >> > Is there any caveat or limitation or anyone hit this issue? I tried
> this
> > >> > with two MX10003 routers one with 19.R3-xxx and the other one with
> 20.4R3
> > >> > junos branch.
> > >> >
> > >> > Regards.
> > >> > _______________________________________________
> > >> > juniper-nsp mailing list juniper-nsp at puck.nether.net
> > >> > https://puck.nether.net/mailman/listinfo/juniper-nsp
> > >>
> > >>
> > >>
> > >> --
> > >>   ++ytti
> >
> >
> >
> > --
> >   ++ytti
>
>
>
> --
>   ++ytti
>


More information about the juniper-nsp mailing list