VPN transport / VPLS solution.
I have 7 sites connected via direct fiber to a FreeBSD router in our
NOC, however we need to turn up a new site that is in a location that
fiber is unavailable.
Currently each site is configured with its own vlan and they all can
"talk" with one another on RFC1918 addresses (192.168.201.0 for site one
192.168.202.0 for site 2, etc). All internet traffic goes through the
fiber as well and NAT is done on the FreeBSD router in our NOC.
This new location has a 6Mb DSL connection to it (This is presented
in our other data center on a RedBack SMS500. 100Mb fiber between the
two data centers) and we would like to present it in the same way as the
fiber connected locations while preferably avoiding any client side
software. There is another FreeBSD router on location at the new site,
however attempts at using ipsec-tools (fka racoon) to achieve the
results desired have proven to be problematic.
Is there another solution you could recommend or any good
documentation on getting racoon configured for transport instead of a
tunnel, or maybe I'm approaching this at entirely the wrong angle...
The end result I'm looking for is something like the following:
firstname.lastname@example.org--(fiber)--( ) [ @192.168.202.254]
email@example.com--(fiber)--( ) [ @192.168.203.254]
firstname.lastname@example.org--(fiber)--(______) [ @192.168.204.254]
.... etc ...
Sorry for the flat cheesy ascii art.. that's 1 switch for all fiber
circuits and the same 1 FreeBSD router with each block on its own vlan.
Thank you in advance for any advice/recommendations.
Re: VPN transport / VPLS solution.
On Tue, 23 Oct 2007 13:31:51 -0500, James <email@example.com> wrote:[color=blue]
> I have 7 sites connected via direct fiber to a FreeBSD router in our
> NOC, however we need to turn up a new site that is in a location that
> fiber is unavailable.[/color]
> Is there another solution you could recommend or any good
> documentation on getting racoon configured for transport instead of a
> tunnel, or maybe I'm approaching this at entirely the wrong angle...[/color]
You're describing something that sounds knowledgeable enough... but
lacks a problem report related to what you are describing. That is,
at this point I don't see how your layer one topology should have any
influence on higher levels.
There are a couple of things I might point you to, but before I mention
those, could you start over and this time begin with a description of
the functionality (not hardware topology) you are trying to implement?
j p d (at) d s b (dot) t u d e l f t (dot) n l .
This message was originally posted on Usenet in plain text.
Any other representation, additions, or changes do not have my
consent and may be a violation of international copyright law.