On 04/02/11 16:12, Ryan Goldberg wrote: > watchguard a) is the outbound nat box for about 70 small offices (we are a > small ISP too, these are fiber-connected customers). it also handles some > amount of inbound nat for those customer's various servers, which may be in > the customers office, or a virtual host in our racks. and maybe a half dozen > ssl-vpn road-warrior types. There's also a dozen or so lan-to-lan ipsec > tunnels on it. sustained 2-20 inbound. light outbound.
That's an odd setup. > watchguard b) is for internet facing windows boxes. lotsa inbound nat. > sustained 2-20Mbit outbound > watchguard c) is for our office, 55ish users. some inbound nat too. > 0-50Mbit inbound, widely varying > watchguard d) is for one particular hosting customer where stability is > paramount. The other firewalls get touched a lot (and as of late, have been > puking when they feel like it). 2-15Mbit of sustained web traffic, with the > odd spike or lull. These three are fairly trivial. > a 2821) terminates a bunch of lan-to-lan ipsec tunnels (VTI style) to 1841s > all over the place. box is completely VRFed, no global table, all the > tunnels land in the INTERNET vrf and pop out in customer vlans, each their > own vrf. 10-30Mbit > > So - goal is to collapse all this onto a single pair of boxes running in an > HA config. Watchguard a, b, and c are problematic, and are becoming more > problematic. watchguard d is pretty quiet, but we are contractually > obligated to remove all SPOF from that clients setup. the 2821 is very > quiet, no troubles. > My main question revolves around number of virtual routers. We can't afford > a big enough box to stuff everything (as in, every customer network) in its > own vrf/routing-instance. I will admit that I've become hooked on using vrfs > in cisco land on ISRs (a lot of double-ISP configs, random dirty hacks). But > for our future firewall setup, I don't know what a bunch of routing-instances > really buys us, if anything (aside from the psychological aspect). All we > really need is for all the private networks behind this thing to get natted > to their corresponding public ip(s), and if something behind the firewall > needs to talk to something else behind the firewall, it should go out and > back in (getting source nattted, then dest natted). If the J-boxes can do > that without separate routing-instances, then we're good. You only need instances (on SRX) for two things: * Overlapping IP's need forwarding instances * Multiple protocol instances (eg, seperate OSPF on either side) take non-forwarding instances > My other question involves HA stability. I've seen instances with other kit > where introducing "HA" actually reduced availability. SRX boxes like running > in HA, or are they fussy? I don't run SRX's in HA, the only issues I've had in production are firmware related (note that you can't do an online firmware upgrade of a HA cluster, there's still a hit). I would suggest an SRX650 over the SRX240, would be far more confident in that handling your traffic load (on the services side, forwarding should be trivial for even an SRX100). -- Julien Goodwin Studio442 "Blue Sky Solutioneering"
signature.asc
Description: OpenPGP digital signature
_______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
