SRX

last person joined: 3 days ago 

Ask questions and share experiences about the SRX Series, vSRX, and cSRX.
  • 1.  Filter traffic at MTU 1522

    Posted 04-23-2019 12:09
    Is there a way to filter traffic at MTU 1522 ? Is that even possible? Is there any other way with the same effect?

    I don't run any interfaces at MTU 1522.


  • 2.  RE: Filter traffic at MTU 1522
    Best Answer

    Posted 04-24-2019 08:40

    Hello Eugene,

     

    If you don't have higher MTU mentioned on the interface, it should be dropped as "Oversized frames".

     

    Anyways, you should be able to use "packet-length" option in a firewall filter to match the IP length (Not including the L2 overheads).

     

    set firewall filter PL term 1 from packet-length 1000-1518
    set firewall filter PL term 1 then count PL_DROP set firewall filter PL term 1 then discard
    set firewall filter PL term 2 then accept

     

    https://www.juniper.net/documentation/en_US/junos/topics/reference/general/firewall-filter-match-conditions-for-ipv4-traffic.html 

     

    Thanks!



  • 3.  RE: Filter traffic at MTU 1522

    Posted 04-24-2019 10:48
    I want to filter this because of the way electricity runs in my area. If I were to try to filter by saying only 1522, is this possible? I think this is the problem area.

    The electricity is a point to point requirement. All equipment is required to be threaded this way due to fire hazard. This locale has extremely hot weather and a dense population.

    I'm gonna try what you said but does it require a range for the MTU value?

    If so can I say 1522-1522 ?

    Taking into account round trip values may also be part of it. But this suggests that it will be taken care of(round trip).

    Comments about past experience are appreciated.


  • 4.  RE: Filter traffic at MTU 1522

    Posted 04-24-2019 12:04

    Hello Eugene,

     

    I am unable to understand the relation between electricity and MTU.

     

    But to answer your question, you can simply use :-

     

    filter abc {
        term 1 {
            from {
                packet-length 1522;
            }
            then accept;
        }
    }

     

    This is permitted in Junos.

     

    Thanks!



  • 5.  RE: Filter traffic at MTU 1522

    Posted 04-24-2019 12:37
    Thx for the insight 😀. An anomaly in the electrical environment exists. It is by code I think. It isn't irrelevant to the conversation. Anyway, one last question.

    The last code provided,,,, which statement/s does this fall under? Is it still the firewall statement or is it allowed in the general body?

    All comments from anyone is appreciated on this topic. Thx for the code insight to TheDesciple .


  • 6.  RE: Filter traffic at MTU 1522

    Posted 04-24-2019 15:05

    Hello Eugene,

     

    Sorry I should have been thorough in the snippet. 

    This is under the same hierarchy.

     

    set firewall filter PL term 1 from packet-length 1522  <<<<<<<<<<<< Note this is only L-3 length. DOES NOT include L2 headers.
    set firewall filter PL term 1 then count PL_DROP
    set firewall filter PL term 1 then discard
    set firewall filter PL term 2 then accept

     

    If you want this filter to be family specific then you can use the same under "set firewall famlily inet filter PL ..."

     

    Thanks!



  • 7.  RE: Filter traffic at MTU 1522

    Posted 04-24-2019 17:26
    I tried the filter that is ranged. It works and does wonders for me. I will try to use the other code snippet too but this makes my srx hummm. Lovely. It really is an anomaly.

    The answer is most likely solved but I need time to set this in the long term.

    I know the topic is about srx series. I have an srx240b2 with 11.47xx Juno's, but I need to also filter 1522 on AP's that connect to the srx. They are dd-wrt, which is Linux. Anyone know how to filter MTU on dd-wrt or Linux/BusyBox.


  • 8.  RE: Filter traffic at MTU 1522

    Posted 04-25-2019 10:39
    Well I must retract a little on my prior statements. The srx is still quarky but it may be a different problem. I'm still convinced that this helps me because of the anomalies in my services, electrical/isp . I think that this solved a route that is coming from the electric company which keeps fires from happening. Pruning still works but protocols like igmp misfire along this route. I think it solves this as well as other problems with this anomaly.