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

[Rafal Szarecki (WA/EPO)]

Kevin,

- If you want to mach base on source/destination class, then fiilter has to be applied on _egress_. This is because, IP lookap has to be executed to identyfy class for diven packet.
- You can use "forwarding-class" instead of "source/destination class" to match on SA or DA.
- To police traffic going to peer, You should configutr output filer on WAN interface, matching destination-class. To  police traffic going from given prefixes-set routed to by peer , You should configure output filer on LAN interface. The policing/couting should be acurate for traffic gouin too peer.
Please note that:
- if routing to A.A.A.A is via peer1 on your router
- Your configuration classify all perfices from peer1 to class_1
- if peer2 send to you packet with source address of A.A.A.A, then your router will classyfy this packet to class_1, regardless from where they commes in.

This is natyral because PFE(FIB) has no information about routing protovol neighbor. They just inspect IP header, which is identicall regardless from which peer packet comming.

my 2 cents.

Rafa³ Szarecki JNCIE

skype me <callto://Rafal_Szarecki/> 



> > Kevin,
> >
> > 1) You can make MAC-level filtering and rate-limiting on GE-IQ and  
> > GE-SFP PIC. This is not supported on GE PIC with fixed optics such  
> > P-GE-SX-B.
> 
> Yeah, this would be ideal but those are considerably out of 
> our price  
> range.

I do NOT talk about QPP/IQ GE. It is supported on ordynary GE (this chipest) with SFP. Please note that from couple of month the old-style GE with fixed optics are non avaliable. Ordynary GE with SFP ia in almost the same price like their fixed0optics predecessor. In some cases SFP base GE is even chipest.

> 
> >
> > 2) You can use DCU/SCU mechanism to classyfy packet in firewall  
> > filter base on information where/from thay go. This is not direct  
> > but work generaly this way:
> >
> > I assune you has BGP session to each neighbor on LAN.
> > You choud write BGP import Policy which add to each lerned prefic  
> > router-internal market - "destination-class"
> > Then you can write firewall filter which match on 
> destination-class  
> > and them execure action modifier like cout ore policer.
> >
> 
> Thanks for the idea. This works, but was really tricky to get working.
> 
> I'm just documenting this here in case anyone else tries this:
> 
> 
> 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.
> 
> 
> 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;
>                      output;
>                  }
>                  destination-class-usage;
>              }
>          }
>      }
>      unit 40 {
>          family inet {
>              accounting {
>                  source-class-usage {
>                      input;
>                      output;
>                  }
>                  destination-class-usage;
>              }
>          }
>      }
> }
> 
> For some reason, nothing gets accounted on the interface directly  
> facing the peers (ge-0/0/0.40):
> 
>  > 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;
>      }
> }
> 
> 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.
> 
> 
> So, to sum up:
> 
> ge-0/0/0.40: "WAN" interface. Directly facing all of our peers.  
> Accounting in "show interface stat"/etc doesn't work. Firewall rules  
> to match on classes must be here.
> ge-0/0/0.0: "LAN" interface. Packets from peers go here. Accounting  
> in "show interface stat"/etc works. Firewall rules on input/output  
> can't see classes.
> 
> Neither is a problem, but not how I would have expected this to work.
> 
> The other issue is, that according to Juniper's docs, you're limited  
> to 126 source/destination classes. We don't have more than 126 peers  
> right now, but I could see us hitting that limit some day.
> 
> Also keep in mind if anyone else does this to monitor their exchange  
> traffic - this method accounts all inbound traffic is coming from  
> whichever neighbor that you're selecting to send that route to. For  
> us, this is mostly correct and we're more concerned about outbound.
> 
> 
>