[j-nsp] Setting forwarding-class in firewall filter, non-match behaviour

[Derick Winkworth]

i wonder what the real world performance implications are on an ASIC forwarding platform...  We really haven't seen any issues with the way we are doing it.

I think I prefer the flexibility for later



________________________________
From: "Richmond, Jeff" <Jeff.Richmond at frontiercorp.com>
To: Addy Mathur <addy.mathur at gmail.com>
Cc: Derick Winkworth <dwinkworth at att.net>; "juniper-nsp at puck.nether.net" <juniper-nsp at puck.nether.net>
Sent: Sun, June 20, 2010 11:18:40 AM
Subject: Re: [j-nsp] Setting forwarding-class in firewall filter, non-match  behaviour

I agree. One thing that we do fairly often is create a multifield classifier like this to just accept a couple of values to place into the appropriate forwarding-class, then for a default action reset to BE forwarding-class for all non-matching traffic. This works well in situations where you may not want to use a BA classifier as you don't trust the markings or you want them rewritten on egress.

Regards,
-Jeff

On Jun 20, 2010, at 6:47 AM, Addy Mathur wrote:

> I personally think Dale's firewall configuration is better.  The
> config allows for a packet to exit fw filter evaluation once a match
> condition is met, by being subjected to a single action.  Derick's FW
> filter forces a packet to traverse all terms regardless of a match,
> and is subjected to at least two actions via two different terms
> (fwd-class + next-term AND accept).  And there's no real need for the
> latter.
> 
> Regards,
> Addy.
> 
> 
> On 6/20/10, Derick Winkworth <dwinkworth at att.net> wrote:
>> This is probably better:
>> 
>> term BEST-EFFORT
>> thenforwarding-class best-effort
>> next-term
>> term DSCP-EF
>> fromdscp ef
>> thenforwarding-class expedited-forwarding
>> next-term
>> term default-accept
>> thenaccept
>> 
>> 
>> You can insert additional terms later to modify loss-priority, sampling,
>> etc... after the classification portion of the filter but before the
>> default-accept.  I would use a rewrite rule to modify DSCP on egress, so
>> that its consistent across platforms.
>> 
>> 
>> 
>> 
>> 
>> ________________________________
>> From: Dale Shaw <dale.shaw+j-nsp at gmail.com>
>> To: juniper-nsp at puck.nether.net
>> Sent: Sun, June 20, 2010 3:59:12 AM
>> Subject: [j-nsp] Setting forwarding-class in firewall filter, non-match
>> behaviour
>> 
>> Hi all,
>> 
>> Re: setting the forwarding-class of a packet through a firewall filter.
>> 
>> Many (almost all) of the examples I've looked at do not include a
>> catch-all term to handle packets not matched by any explicitly-defined
>> terms. At the risk of exposing myself as a J-noob...
>> 
>> Is it safe to assume that, if the desired result is that packets NOT
>> matched by explicitly-defined terms are permitted, a catch-all term
>> must be configured with an 'accept' (or some other non-terminating)
>> action?
>> 
>> Using this input filter example:
>> (stolen from
>> http://www.juniper.net/techpubs/en_US/junos10.2/topics/usage-guidelines/policy-configuring-actions-in-firewall-filter-terms.html)
>> 
>> firewall {
>> filter filter1 {
>>  term 1 {
>>   from {
>>    dscp 2;
>>   }
>>   then {
>>    dscp 0;
>>    forwarding-class best-effort;
>>   }
>>  }
>>  term 2 {
>>   from {
>>    dscp 3;
>>   }
>>   then {
>>    forwarding-class best-effort;
>>   }
>>  }
>> }
>> }
>> 
>> I read this as:
>> 
>> - if the packet is marked DSCP 2, set DSCP to 0 and place in
>> 'best-effort' forwarding class and accept the packet.
>> - if the packet is marked DSCP 3, place in 'best-effort' forwarding
>> class and accept the packet.
>> - discard all other packets
>> 
>> Am I missing something?
>> 
>> I think what I really want, to avoid dropping traffic, is something like:
>> 
>> firewall {
>> filter FILTER1 {
>>  term TERM1 {
>>   from {
>>    dscp ef;
>>   }
>>   then forwarding-class expedited-forwarding;
>>  }
>>  term DEFAULT {
>>   then forwarding-class best-effort;
>>   accept;
>>  }
>> }
>> }
>> 
>> ...then rewrite DSCP bits on egress based on the forwarding-class, or
>> do it all within the firewall filter (depending on platform).
>> 
>> (I know I don't strictly need the 'accept;' command in the DEFAULT
>> term, but for the sake of clarity, I think it's a good option)
>> 
>> Cheers,
>> Dale
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>> 
> 
> -- 
> Sent from my mobile device
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp