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

[Rafal Szarecki (WA/EPO)]

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).


Rafa³ Szarecki JNCIE

skype me <callto://Rafal_Szarecki/>