Failover how much complexity will it add?
adel at baklawasecrets.com
adel at baklawasecrets.com
Sun Nov 8 17:34:08 UTC 2009
Thanks for all your comments guys. With regards to bgp I did
think about placing two bgp routers in front of the ssg's. However
my limited understanding makes me think that if I had two bgp
connections from different providers I would still have issues. So
I guess that if my primary Internet goes down I lose connectivity
to all the publicly addressed devices on that connection. Like
dmz hosts and so on. I would be interested to hear how this
can be avoided if at all or do I have to use the same provider.
I should add that we currently have provisioned two ssg in ha
mode. Also is terminating bgp on the ssg also an option? I really
like the flexibility of route based VPN with addresable tun interfaces.
Thanks
adel
On Sun 3:47 PM , "Joe Maimon" jmaimon at ttec.com sent:
>
>
> [email protected]
> baklawasecrets.com wrote:> HI,
> >
> >
> > Now I couldn't get any good answers as to why
> Internet connections 1 and 2 need to be separate. I think the idea was to
> make sure that there was enough bandwidth for the third party support VPN.
> I feel that I can consolidate this into one connection and just use rate
> limiting to reserve some portion of the bandwidth on the connection and
> this should be fine. Now if I was to do this then I can make a case for
> just having one backup Internet connection. However I'm still concerned
> about failover and reliability issues. So my questions regarding this
> are:>
>
> I wouldnt jump to any conclusions that everything will work properly if
> you are terminating multiple connections directly on the SSG, what with
> egress likely being different than the ingress, even if you are using
> the same IP range (BGP) on all the links.
>
> You could really be asking for trouble if you are planning on using a
> different ISP provided IP range on each connection for each purpose.
>
> Front it all with routers that can policy route, whether or not you also
> use BGP.
>
>
> Joe
>
>
>
>
>
More information about the NANOG
mailing list