On 14/02/13 14:41, Andrew Miehs wrote:
When the specific route re-appeared, the firewall continued to send the traffic via the default route as the "flow" had not expired.
It is a bit of a shame that so many firewalls rely *entirely* on the flow module to forward packets, and in such a dumb (sticky) way. It can be a real pain in cases where the device unconditionally sends return packets back out the input interface for the session (regardless of routing table) in some topologies, or if the device barfs when packets come in via >1 interface (multipath). I'd be much happier if the firewalls had some form of FIB as well as their flow table, but I guess I understand why this isn't the case.
I have seen another setup where you use a router for your "fusion"/intervrf router and the run layer 2 firewalls on that link.
From what I can tell, that's something firewall vendors seem to be moving away from; routed rather than transparent mode seems to be the "preferred" mode for many devices and vendors now (or at least, the ones I've dealt with; I can't claim exhaustive knowledge!)
This however has the disadvantage that all your traffic needs to flow through 2 firewalls (or twice through the one firewall)...
This is definitely an issue at high throughput - we couldn't afford to take the performance hit, for example.
You also "lose" some information, specifically you don't know the final destination zone on the 1st pass, or the original source zone on the 2nd. In some cases this is good, others bad - it depends on how you are writing your policies, and whether you've got nice/neat address ranges mapping to security zones (we don't).
If you do you layer2 firewalls between VRFs on a PE, you also end up having to form routing adjacencies "with yourself". This can be a bit icky at best, and outright unworkable at worst, depending on your platform, OS version and choice of routing protocol.
As with all things, there's no one right answer ("it depends") but here, we've had good luck with BGP and routing. Some lucky guesses early on and suitable mandatories in the procurement yielded good results.
_______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
