Routing

Hi All,

 

I need to create an input firewall filter which always matches on a specific set of source IPs and destination IPs but changes the DSCP markings to various different DSCPs depending on which DSCPs the packets arrive with at the firewall - so I've come up with the config below (Note: the source and destination prefix lists are the same for each term):

 

set firewall family inet filter QoS-IN term BE from source-prefix-list PL_1
set firewall family inet filter QoS-IN term BE from destination-prefix-list PL_2
set firewall family inet filter QoS-IN term BE from dscp-except ef
set firewall family inet filter QoS-IN term BE from dscp-except af31
set firewall family inet filter QoS-IN term BE then loss-priority high
set firewall family inet filter QoS-IN term BE then forwarding-class be
set firewall family inet filter QoS-IN term BE then dscp be
set firewall family inet filter QoS-IN term BE then count BE
set firewall family inet filter QoS-IN term BE then log
set firewall family inet filter QoS-IN term BE then accept
set firewall family inet filter QoS-IN term CS5 source-prefix-list PL_1
set firewall family inet filter QoS-IN term CS5 destination-prefix-list PL_2
set firewall family inet filter QoS-IN term CS5 from dscp af31
set firewall family inet filter QoS-IN term CS5 then loss-priority low
set firewall family inet filter QoS-IN term CS5 then forwarding-class af
set firewall family inet filter QoS-IN term CS5 then dscp cs5
set firewall family inet filter QoS-IN term CS5 then count CS5
set firewall family inet filter QoS-IN term CS5 then log
set firewall family inet filter QoS-IN term CS5 then accept
set firewall family inet filter QoS-IN term EF from source-prefix-list PL_1
set firewall family inet filter QoS-IN term EF from destination-prefix-list PL_2
set firewall family inet filter QoS-IN term EF from dscp ef
set firewall family inet filter QoS-IN term EF then loss-priority low
set firewall family inet filter QoS-IN term EF then forwarding-class ef
set firewall family inet filter QoS-IN term EF then count EF
set firewall family inet filter QoS-IN term EF then log
set firewall family inet filter QoS-IN term EF then accept

 

But is there a better, more efficient, way of constructing this firewall filter where I don't have to repeatedly reference the same prefix lists in each term? - i.e. by using the 'next term' - e.g.:

 

set firewall family inet filter QoS-IN term accept-prefixes from source-prefix-list PL_1
set firewall family inet filter QoS-IN term accept-prefixes from destination-prefix-list PL_2
set firewall family inet filter QoS-IN term accept-prefixes then next term
set firewall family inet filter QoS-IN term BE from dscp-except ef
set firewall family inet filter QoS-IN term BE from dscp-except af31
set firewall family inet filter QoS-IN term BE then loss-priority high
set firewall family inet filter QoS-IN term BE then forwarding-class be
set firewall family inet filter QoS-IN term BE then dscp be
set firewall family inet filter QoS-IN term BE then count BE
set firewall family inet filter QoS-IN term BE then log
set firewall family inet filter QoS-IN term BE then accept
set firewall family inet filter QoS-IN term CS5 from dscp af31
set firewall family inet filter QoS-IN term CS5 then loss-priority low
set firewall family inet filter QoS-IN term CS5 then forwarding-class af
set firewall family inet filter QoS-IN term CS5 then dscp cs5
set firewall family inet filter QoS-IN term CS5 then count CS5
set firewall family inet filter QoS-IN term CS5 then log
set firewall family inet filter QoS-IN term CS5 then accept
set firewall family inet filter QoS-IN term EF from dscp ef
set firewall family inet filter QoS-IN term EF then loss-priority low
set firewall family inet filter QoS-IN term EF then forwarding-class ef
set firewall family inet filter QoS-IN term EF then count EF
set firewall family inet filter QoS-IN term EF then log
set firewall family inet filter QoS-IN term EF then accept

Or (having read some Juniper firewall tech notes where it's stated that 'next term' is implicit if there are no 'flow control actions' such as 'accept' or 'reject' included in each term):

 

set firewall family inet filter QoS-IN term BE from dscp-except ef
set firewall family inet filter QoS-IN term BE from dscp-except af31
set firewall family inet filter QoS-IN term BE then loss-priority high
set firewall family inet filter QoS-IN term BE then forwarding-class be
set firewall family inet filter QoS-IN term BE then dscp be
set firewall family inet filter QoS-IN term BE then count BE
set firewall family inet filter QoS-IN term BE then log
set firewall family inet filter QoS-IN term CS5 from dscp af31
set firewall family inet filter QoS-IN term CS5 then loss-priority low
set firewall family inet filter QoS-IN term CS5 then forwarding-class af
set firewall family inet filter QoS-IN term CS5 then dscp cs5
set firewall family inet filter QoS-IN term CS5 then count CS5
set firewall family inet filter QoS-IN term CS5 then log
set firewall family inet filter QoS-IN term EF from dscp ef
set firewall family inet filter QoS-IN term EF then loss-priority low
set firewall family inet filter QoS-IN term EF then forwarding-class ef
set firewall family inet filter QoS-IN term EF then count EF
set firewall family inet filter QoS-IN term EF then log
set firewall family inet filter QoS-IN term accept-prefixes from source-prefix-list PL_1
set firewall family inet filter QoS-IN term accept-prefixes from destination-prefix-list PL_2
set firewall family inet filter QoS-IN term accept-prefixes then accept

Any help/advice is greatly appreciated, thanks.

 

Hi Vishaalv,

 

Many thanks for replying.  So, just to confirm, once the packets have been matched by the first term (the specific source and destination prefix list term) then the 'next term' line of the first term will ensure the packets are checked by the nest term in the filter - which in this case is the BE term ... but if the packets don't match against the BE term then the packets will go on to be checked against the next term after that - in this case the CS5 term, and if they don't match against that then they will be checked against the EF term. Correct?

 

So what happens if the packets don't match against the specific source and destination prefix list term (i.e. the very first term) - will they be dropped at that point, or will they also go on to be checked against the second term (BE term), then the third term (CS5 term), then the last term (EF term)?  

Hi,

and by asking "So what happens if the packets don't match against the specific source and destination prefix list term (i.e. the very first term) - will they be dropped at that point, or will they also go on to be checked against the second term (BE term), then the third term (CS5 term), then the last term (EF term)? " you've already spotted a weak point in the proposed "optimized" filter, as "If the packet does not match all the conditions specified in a term, the device proceeds to the next term in the filter ... and evaluates the packet against that term." (from https://www.juniper.net/documentation/en_US/junos/topics/concept/firewall-filter-stateless-evaluate-packets.html )

Regards

Ulf

Thanks Ulf - I did spot that as being the "weak point" in the 'optimized' version of the filter, so thanks for confirming my thoughts.

Hello,

If You are looking at the "best way to construct" the FW filter for Your own readability, then You already posted it in Your OP.

If You are looking at the best way to contruct the FW filter for performance, then 2 points:

1/ don't use "next term" unless You 100% understand what is actually involved here - "next term"  causes complete packet reevaluation which in HW terms means recirculating the packet header|complete packet (depending on HW) inside the forwarding chip. Which means Your HW' PPS performance is halved.

2/ the JUNOS CLI filter code is NOT the actual code that is pushed into the HW. The linecard CPU does FW filter optimization on-the-fly/as it gets committed, which includes summarizing Your prefix-lists as well, so the results could be very different from what You expect.

Example being: 

- I chose following prefixes for this illustration:

 

set policy-options prefix-list PL_1 10.0.2.0/24
set policy-options prefix-list PL_1 10.0.4.0/24
set policy-options prefix-list PL_1 10.0.5.0/24
set policy-options prefix-list PL_1 10.0.6.0/24
set policy-options prefix-list PL_2 172.16.1.0/24
set policy-options prefix-list PL_2 172.16.2.0/24
set policy-options prefix-list PL_2 172.16.3.0/24
set policy-options prefix-list PL_2 172.16.5.0/24

 

 

- Your JUNOS CLI FW filter from OP results in the following optimized filter code:

 

VMX-0(R6 vty)# show filter index 2 program    
Filter index = 2
Optimization flag: 0xf7
Filter notify host id = 0
Filter properties: None
Filter state = CONSISTENT
term BE
term priority 0
    dscp  
         0-25 
        26  -> source-address in CS5
        27-45 
        46  -> source-address in EF
        47-63 
        false branch to match action in rule junos-internal-1
    source-address  
        10.0.2/24   ## summarization done here
        10.0.4/22
        !10.0.7/24
        false branch to match action in rule junos-internal-1
    destination-address  
        172.16.1/24 ## and here as well
        172.16.2/23
        172.16.5/24
        false branch to match action in rule junos-internal-1

    then
        accept
        forwarding-class 0
        loss-priority 3
        log
        dscp 0
        count BE
term CS5    
term priority 0
    source-address  
        10.0.2/24
        10.0.4/22
        !10.0.7/24
        false branch to match action in rule junos-internal-1
    destination-address  
        172.16.1/24
        172.16.2/23
        172.16.5/24
        false branch to match action in rule junos-internal-1

    then
        accept
        forwarding-class 3
        loss-priority 0
        log
        dscp 40
        count CS5
term EF
term priority 0
    source-address  
        10.0.2/24
        10.0.4/22
        !10.0.7/24
        false branch to match action in rule junos-internal-1
    destination-address  
        172.16.1/24
        172.16.2/23
        172.16.5/24
        false branch to match action in rule junos-internal-1

    then
        accept
        forwarding-class 4
        loss-priority 0
        log
        count EF
term junos-internal-1
term priority 0

    then
        discard

 

 

 

 HTH

Thx

Alex

Many thanks aarseniev,

 

That's a very informative reply (especially regarding the 'next term' behaviour with respect to h/w).

 

So, I think you're saying that the filter below is the 'best' version from a performance and readability perspective - is that correct?

 

set firewall family inet filter QoS-IN term BE from source-prefix-list PL_1
set firewall family inet filter QoS-IN term BE from destination-prefix-list PL_2
set firewall family inet filter QoS-IN term BE from dscp-except ef
set firewall family inet filter QoS-IN term BE from dscp-except af31
set firewall family inet filter QoS-IN term BE then loss-priority high
set firewall family inet filter QoS-IN term BE then forwarding-class be
set firewall family inet filter QoS-IN term BE then dscp be
set firewall family inet filter QoS-IN term BE then count BE
set firewall family inet filter QoS-IN term BE then log
set firewall family inet filter QoS-IN term BE then accept
set firewall family inet filter QoS-IN term CS5 source-prefix-list PL_1
set firewall family inet filter QoS-IN term CS5 destination-prefix-list PL_2
set firewall family inet filter QoS-IN term CS5 from dscp af31
set firewall family inet filter QoS-IN term CS5 then loss-priority low
set firewall family inet filter QoS-IN term CS5 then forwarding-class af
set firewall family inet filter QoS-IN term CS5 then dscp cs5
set firewall family inet filter QoS-IN term CS5 then count CS5
set firewall family inet filter QoS-IN term CS5 then log
set firewall family inet filter QoS-IN term CS5 then accept
set firewall family inet filter QoS-IN term EF from source-prefix-list PL_1
set firewall family inet filter QoS-IN term EF from destination-prefix-list PL_2
set firewall family inet filter QoS-IN term EF from dscp ef
set firewall family inet filter QoS-IN term EF then loss-priority low
set firewall family inet filter QoS-IN term EF then forwarding-class ef
set firewall family inet filter QoS-IN term EF then count EF
set firewall family inet filter QoS-IN term EF then log
set firewall family inet filter QoS-IN term EF then accept

Hello,

 

---

@Velociraptor wrote:

 

 

So, I think you're saying that the filter below is the 'best' version from a performance and readability perspective - is that correct?

 

From readability perspective - yes

From performance - it depends on the content of Your prefix-lists.  If they are long (say, 1000 unique prefixes or more) then I'd look at summarizing them , or, if impossible to summarize, then have a look at using SCU/DCU instead.

HTH

Thx

Alex 

 

 

 

Thanks again aarseniev - the prefix lists involved will be quite small: 10-15 unique prefixes at most in each list (but the prefixes are not summarisable).