access restriction - pf vs irule?

That's an interesting question... I haven't had to do packet filters for a long time on F5's (Since 9.1 IIRC).

 

 

However I'm surprised that you found pf's slower and using more cpu consumption than iRules... However,w e probably need someone like Spark or another developer to give us a clear answer on who gets the packets first and what part of the switch/tmm/hostkernel/service kernel gets packets first and where the flowpath goes if you use pf's vs iRules. (I really would have expected iRules to consume more CPU though, especially if you're doing DG lookups).

 

 

Although perhaps it's something strange like the pf has to run as the management host, so packets need to be transported over to it for filtering (Just like tcpdump), vs the optimised paths that would be in place for TMM and iRule processing of packets...

 

 

H

We're having some performance issue with packet filters too. Our current understanding is that packet filters are constrained to 20% of the available CPU power in the box, so you're somewhat likely to encounter issues when using it with any kind of substantial throughput.

 

 

We are currently looking at using pass-through firewalls in between the F5's and our L3 switches so we can provide security completely outside of the F5 itself.

Mmm.... I'd always sandwich external facing BigIP's with firewalls anyway. Because (As Support have told me in the past), they're not intended to be a security device... It's too easy to allow unintended access through an F5. Separating your security to a dedicated firewall and ensuring that the BigIP is there for content delivery is both more secure, and going to provide better performance as each device is optimised for the function they're performing.

 

 

H

just in case anyone was wondering what i found.

 

 

all incoming traffic is filtered with pf before it's handed off to tmm. irules are run in tmm and will only be triggered when the appropriate vip is accessed. this makes pf a vastly inferior solution in terms of both latency and hardware resource usage.