On May 19, 2012, at 3:53 PM, Yaron Sheffer wrote:
Hi Vishwas, Yoav,
Check Point (IIRC) supports communities of IPsec endpoints, arranged
either as a star or a full mesh. This is nice and simple to configure
but obviously does not cover all use cases. Some networks cannot be
represented
But this quickly reduces to hierarchical routing: consider 3
communities, C1, C2, C3. Connectivity is C1 == C2 == C3 (i.e. no
direct connectivity between C1 and C3). The connecting member between
C1 and C2 needs to know everybody in C1 and C2 - that's clear. But it
also needs to know endpoints
Hi.
I think it should be more complicated than this. The suggested solution has a
dichotomy of either a full mesh or a start topology. The requirements should
cover scenarios such as a mesh within an organization connecting to a hub to
gateways outside the organization, or multiple hubs
Hi Yaov,
If I udnerstand correctly, what you seem to be talking about is a
Star-of-meshes or a mesh-of-star topology.
In my view this would be dealt with in 2 different iterations of the Mesh
VPN topology. So there would be a Mesh VPN for the Star topology and a
separate instance of the Mesh VPN
I might have put it like this if it wan't so similar to the way things are
configured on Check Point gateways :-)
It makes sense to me, but I'm not sure it covers all the use cases. Imagine a
topology that is entirely mesh, except for HTTP(S) traffic that is routed to a
central site because
Hi,
I would like to start off by trying to resolve the issue. The notes from
the IETF are attached below.
Description:Some admins prefer a star topology so they can inspect traffic.
They may not want to use this technology.
Detail arguments: My take is similar to what Yaron and Yaov seem to
