[j-nsp] JunOS QPPB

[Ezequiel Carson]

Dave, guys:

        is there anyway to force a recursive route lookup so junos could
add the DCU flag to the packet. structure and then applying the match
criteria over this traffic?
          
         Configuring L3VPN (VRF) over dot1 interface.... we had the
problem with 3 ways header packet loookup (MPLS LABEL,IP DEST and MAC
ADDRESS) and applying a static route /32 to the same host was the
solution, i.e.: 192.168.0.1/32 next-hop 192.168.0.1.  

         i was trying to force some kind of recursive lookup and then
send the flow to a routing instance or logical router where a
fowarding-option can be configured.



what do you think?

Thanks
ezequiel



    

On Tue, 2006-01-03 at 14:38 -0800, Dave McGaugh wrote:

> >
> > I think this doesnt work because the destination-class is applied  
> > after a routing-lookup, and the firewall filter is applied when the  
> > packet arrives to the interface, so the filter doesnt know to what  
> > destination-class the packet will be classified. I'm pretty sure of  
> > this because i can see that the source-class and destination-class  
> > is working with the command 'sh interfaces ge-0/0/0.x statistics'  
> > and not in the counter of my filter.
> >
> > Anybody have made something like this? Is this the correct way to  
> > perform what i want to do? Help will be apreciated :)
> >
> > Thanks in advance,
> 
> you are correct, check out this page:
> http://www.juniper.net/techpubs/software/junos/junos74/swconfig74- 
> policy/html/firewall-config15.html#1043613
> 
> "The class-based filter match condition works only for output filters  
> because the source class usage (SCU) and destination class usage  
> (DCU) is determined after route lookup."
> 
> Ways to get around this, but still have your filter work based on  
> your ingress customer interface are to:
> 
> 1) Identify all your egress interfaces where packets you wish to  
> filter pass -- and then apply the filter on those but now with an  
> interface match condition as well (matching your original ingress  
> interface). i.e.
> term CUST-1 {
>      from {
>          interface <customer interface 1>;
>          destination-class BAR;
>      }
>      then {
>          policer 256Kbps;
>          accept;
>      }
> 
> }
> term CUST-2 {
>      from {
>          interface <customer interface 2>;
>          destination-class BAR;
>      }
>      then {
>          policer 256Kbps;
>          accept;
>      }
> 
> }
> 
> 
> 2) Or if trying to identify all possible egress interfaces doesn't  
> sound like fun, wait for JunOS 7.5 where you can apply an egress  
> forwarding table filter, then make your DCU match with your interface  
> match as above, and never worry about where your egress interface is,  
> because it will filter anything that the box has to forward.
> forwarding-options {
>      family inet {
>          filter {
>              output CUST-TRAFFIC-OUT;
>          }
>      }
> }
> filter CUST-TRAFFIC-OUT {
> term CUST-1 {
>      from {
>          interface <customer interface 1>;
>          destination-class BAR;
>      }
>      then {
>          policer 256Kbps;
>          accept;
>      }
> 
> }
> term CUST-2 {
>      from {
>          interface <customer interface 2>;
>          destination-class BAR;
>      }
>      then {
>          policer 256Kbps;
>          accept;
>      }
> 
> }
> }
> 
> 
> -Dave
> --Apple-Mail-53--893105494--
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp