[j-nsp] Per next-hop or MAC accounting/firewall/policer onsameinterface

[Jiri Sane]

> I read some doc and in your case:
>
> > > I created a policy-statement called to classify routes:
> > >
> > >      policy-statement classes-in {
> > >          term from-peer-1 {
> > >              from neighbor 1.2.3.1;
> > >              then {
> > >                  destination-class dst-1;
> > >                  source-class src-1;
> > >                  accept;
> > >              }
> > >          }
> > >          term from-peer-2 {
> > >              from neighbor 1.2.3.2;
> > >              then {
> > >                  destination-class dst-2;
> > >                  source-class src-2;
> > >                  accept;
> > >              }
> > >          }
> > >        (etc ...)
> > >       }
> > >
> > > Then added this to the forwarding table export action:
> > >
> > > routing-options {
> > >       forwarding-table {
> > >          export classes-in;
> > >      }
> > > }
> > >
> > > Trying to put that policy-statement in "protocols bgp group peers
> > > neighbor xxxx" produced no errors, but never applied the
> > classes to
> > > anything.
>
> That is correct. class  action is allowed only under forwarding-table.
>
> > > We have two interfaces, one is a "WAN" interface(ge-0/0/0.40) with
> > > lots of peers, the other is a "LAN"(ge-0/0/0.0) interface to our
> > > servers. I turned on accounting on both:
> > >
> > > ge-0/0/0 {
> > >      unit 0 {
> > >          family inet {
> > >              accounting {
> > >                  source-class-usage {
> > >                      input;
>                            ^^^^^^-- this is not needed. Your servers
> probably newer send packet with source address matching in src-1/src-2
class
>
> > >                      output;
> > >                  }
> > >                  destination-class-usage;
> > >              }
> > >          }
> > >      }
> > >      unit 40 {
> > >          family inet {
> > >              accounting {
> > >                  source-class-usage {
> > >                      input;
> > >                      output;
>                            ^^^^^^^^---- this is not needed.
> > >                  }
> > >                  destination-class-usage;
> > >              }
> > >          }
> > >      }
> > > }
> > >
> > > For some reason, nothing gets accounted on the interface directly
> > > facing the peers (ge-0/0/0.40):
>
> Works as designed. On this interface you will see somthing if yo define
> class (source nad destination) couvering addresses accesable via LAN
> (addresses of your servers).[BUT, not sure if DCU/SCU works for direct
> routes]
>
> > >
> > >  > show interfaces ge-0/0/0.40
> > >        Flags: DCU, SCU-in, SCU-out
> > >        Destination class
> > > Packets                Bytes
> > >                            dst-1
> > > 0                    0
> > >                            dst-2
> > > 0                    0
> > > (snip)
> > >        Source class
> > > Packets                Bytes
> > >                            src-1
> > > 0                    0
> > >                            src-2
> > > 0                    0
> > > (snip)
> > >
> > > It does work on my "LAN" interface(ge-0/0/0.0) that the
> > traffic ends
> > > up passing through, though.
> > >
> > > BUT, if I want to put any firewall rules based on the classes, like:
> > >
> > > term peer-2-out-police {
> > >      from {
> > >          destination-class dst-2;
> > >      }
> > >      then {
> > >          policer peer-2-out-limit;
> > >      }
> > > }
>
>
> On your LAN interface filter shoukld match source-class, and be applied in
> output direction.
> IFAIK this should work.
>
> > >
> > > It must be placed on the output firewall of ge-0/0/0.40 - if
> > > I put it
> > > on the "LAN" side, it never matches anything.
>
> If you apply filter peer-2-out-police on LAN interface in input direction,
> then will not work at all. This is docummentde that you can match base on
> class only in output filters.
>
> If you apply filter peer-2-out-police on LAN interface in output
direction,
> then match never occures, because destination address is your server
> address, not addres annouced by peer2 (which can be in source address of
> packet, but this field is not checked by filter peer-2-out-police).

Rafal,

I have been trying to do something very similar myself, but instead of
applying a policy to class-matched traffic, I need to forward it to
particular host (10.0.10.1). I've had no luck with setting firewall rule
like this to output direction of my "lan-interface" (like in Kevin's setup)

term foo {
    from {
       source-class bar-source;
    }
    then {
          log;
          count foo;
          routing-instance foo-forward;
    }

along with

routing-instances {
     foo-forward {
             instance-type forwarding;
             routing-options {
                  static {
                       route 0.0.0.0/0  next-hop 10.0.10.1;
                  }
            }

Without "then routing-instance" I can see that all correct traffic is
matched but when "then routing-instance" is applied, logging stops and
foo-count goes crazy (hundreds of megs in seconds on a box with like
10Mbit/s traffic) I would quess this to-be-forwarded traffic loops between
output firewall filter and routing-instance?
Any suggestions of how this shoud/could be achieved?

Thanks,

-- 
Jiri