SRX IPv6 flow based processing

One of our plans is to consolidate as many of the egress trafic paths as possible.  To facilitate this, we had to do some things like buy carrier grade equipment.  Enter the SRX 5800.  No one really does IPS/IDP+Firewall quite like the SRX.  After extensive research and exhaustive hands on testing with quite a bit of equipment, that is what we settled on.  Even the IBM “technical evangelist” guy that came to talk to us said “No one really does it like they do” when referring to Juniper and 10G firewall/IPS.

Lets make one thing clear, IPv6 isn’t going away.  We’ll all be using in in the next few years, and so, to that end, it needs to work through our network as closely to the way folks are using the current resources as we can make it….within the confines of our resources and the limitations of IPv4 and IPv6 respectively.

To make IPv6 process similarly to IPv4 on the SRX 5800 cluster, we have to enable flow based security processing for it.  To make that happen, you have to do the following things, as documented here:

set security forwarding-options family inet6 mode flow-based


Enabling this actually requires a reboot of the boxes, and on a chassis cluster, I’ve been told by our Agility JTAC guy (and learned the herd way because I’m stubborn like that) that you need to reboot both cluster nodes at the same time (which I find dumb since the purpose of a firewall cluster is almost always redundancy).

Regardless, I used the recommended method and kicked the boxes after a commit check.

commit check


The router then spits out the following information after the commit check:

node0:
warning: You have enabled/disabled inet6 flow.
You must reboot the system for your change to take effect.
If you have deployed a cluster, be sure to reboot all nodes.
configuration check succeeds




node1:
warning: You have enabled/disabled inet6 flow.
You must reboot the system for your change to take effect.
If you have deployed a cluster, be sure to reboot all nodes.
configuration check succeeds




From here I like to comment all of my commits, as it’s just good practice and it will be logged on your handy syslog server for later use or reference.


commit comment “Enabling Flow-Based Processing for IPv6 Traffic”


And from there, a reboot of both nodes (at the same time) is necessary..

request system reboot


And then, we wait……

…..and wait some more…

….and then…..the prompt on the console is back.

………..and after about 6-7 minutes, we have OSPF adjacencies and packets are flowing.  The SPCs take a bit to self test, fully boot and start processing traffic, as I would expect from something processing so many pieces of so much traffic.  

Now we need to verify that what we did actually worked.  From the SRX, check the security flow status:


show security flow status

node0:
————————————————————————–
  Flow forwarding mode:
    Inet forwarding mode: flow based
    Inet6 forwarding mode: flow based
    MPLS forwarding mode: drop
    ISO forwarding mode: drop
    Flow trace status
    Flow tracing status: off


node1:
————————————————————————–
  Flow forwarding mode:
    Inet forwarding mode: flow based
    Inet6 forwarding mode: flow based
    MPLS forwarding mode: drop
    ISO forwarding mode: drop
    Flow trace status
    Flow tracing status: off

We’re looking for:

    Inet6 forwarding mode: flow based

This would have said “drop” before the change. 

We hope to actually swing over our IPv6 traffic soon and start processing it on the SRXs.  I’ll post notes as soon as we go forward with that.  





[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

One thought on “SRX IPv6 flow based processing

  1. We’ve found a at least one issue after this change. Apparently, our IKE ALG is no longer functioning as it was before.
    I’m not terribly confident in the SRX ALG implementations, so I’ll be poking at juniper a but about that as I get time. they’ve been very responsive to our questions and issues so ar, I expect that this will either be fixed ASAP or pointed out as a problem on our end.

Comments are closed.