Jason Costomiris writes: > On Saturday, February 1, 2003, at 09:31 PM, Dick St.Peters wrote:
> > 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. > > 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. :) A DMZ with RFC1918 private-IP-space addressing? I'll grant that's imaginative ... kinda useless though. > > 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. > > 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. Routes are not the issue. You need multiple routes with any VPN technology, but routes are cheap, and multiple routes don't matter until you get into hundreds or thousands of them. The issue is that with VPN technologies other than IPsec you can point multiple routes through a single tunnel, whereas with IPsec you need a separate tunnel for each route ... for each pair of subnets or gateways you want to connect. Other VPN technologies create tunnels that act like virtual wires. IPsec creates tunnels that act like virtual wires with filters that limit the connection to a specific subnet/gateway pair. With other VPN technologies you can add such filters if you want them, but with IPsec you can't remove them if you don't want them. As for interoperability, tunnels that act like virtual wires interoperate with anything wires do. IPsec tells you what you can't do. When dealing with real life networking, you want solutions you don't have to work around. You want to build your networking around your company's needs, not around IPsec's needs. Personally, I suspect that in the long run, IPsec transport mode will prove more important than IPsec tunnel mode. -- Dick St.Peters, [EMAIL PROTECTED] -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
