On Saturday, February 1, 2003, at 09:31 PM, Dick St.Peters wrote:
Well, I'm sure you mean 3 nics, since you're using one in the internal net, the other in a DMZ, the 3rd on the outside. Aggregate that? Uh, what's the problem? Both networks are connected to the same gateway. You *PLAN* and use adjacent subnets, such as say 192.168.10.0/24 for net2 and 192.168.11.0/24 for net3 (ie. 192.168.10.0/23). Little imagination my foot. :)Jason Costomiris writes:On Saturday, February 1, 2003, at 03:17 PM, Dick St.Peters wrote:No, this requires planning your network around IPsec, which is not thenet1 <--> net2/net3 This requires good network planning.
same thing as good network planning. Other VPN technologies fit into
the network you have ... or that you may want to have for other
reasons.
That's silly. Planning your network so that you can aggregate the networks at each site into a single network has nothing to do with planning your network around IPsec. It has everything to do with minimizing configuration of whatever connectivity solution you deploy, be it IPsec, some random VPN, private links or even frame relay.Oh yee of little imagination ... start with the obvious case: two NICs on the gateway, one in net2, the site's DMZ, another in net3, its internal network. Aggregate that one.
Ok, that's not a big deal either. If both sites are well planned, it doesn't matter that each site came out of different RFC1918 spaces. You don't aggregate both sites into a single route, at least in your example. You'd only do that if you were deploying a hub and spoke and putting routes on the spoke sites. If that's the case, it's one or two extra routes in what would most likely be a fair number already. In our example here, we've been talking about doubling or tripling the size of his routing tables.For another, try having net2 and net3 be at different sites, where the two sites represent two previously different companies that just merged. One numbered out of 192.168.0.0/16, the other out of 10/8.
Layer 8 issues have their place, but if you're a smart network manager, you'll work within them to ensure you don't either create a network that's difficult to maintain or introduce proprietary solutions that don't interoperate when perfectly good interoperable solutions exist.Networks are not planned; networks grow (or shrink or divide) under the influence of things other than networking. People trying to plan networks have never been any better at predicting the future than anyone else.
--
Jason Costomiris <><
E: jcostom {at} jasons {dot} org / W: http://www.jasons.org/
Quidquid latine dictum sit, altum viditur.
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe
https://listman.redhat.com/mailman/listinfo/redhat-list
