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

[Kevin Day]

On Aug 2, 2005, at 3:31 AM, Rafal Szarecki (WA/EPO) wrote:

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

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