From: Charlie Winckless (CharlieW@xxxxxxxxxxx)
Date: Sun Apr 22 2001 - 19:45:48 GMT-3
I'd tend to assume that this is a scenario where you
need to load balance two separate ISP connections and
thus need to run BGP thru' the firewall to pass routes
to your internal network.
I've considered doing this in some large customer designs,
and have seen tunnels for BGP thru' firewalls in the past
for this reason.
-- Charlie
> -----Original Message-----
> From: Peter Van Oene [mailto:pvo@usermail.com]
> Sent: Saturday, April 21, 2001 1:46 PM
> To: Darren Hosking; ccielab@groupstudy.com
> Subject: Re: BGP and NAT
>
>
> You should be able to set next hop addresses on a per peer
> basis and thus achieve your goal. However, routers behind
> firewalls is something I haven't seen much of. What is the
> reasoning for such a design?
>
> Pete
>
> *********** REPLY SEPARATOR ***********
>
> On 4/22/2001 at 2:41 AM Darren Hosking wrote:
>
> >I'm trying to configure BGP with the EBGP connections over
> NAT (ie one BGP
> >router using registered addresses, the other using private
> addresses with a
> >static NAT translation for the EBGP peer to connect to). I
> receive the
> >routes for the other AS no problems but believe I will have
> an issue with
> >the next-hop of routes I advertise.
> >
> >What address is used for the next-hop address by default and
> for neighbor
> >next-hop-self?
> >
> >If I use a route-map to set the next-hop address of outbound
> BGP routes,
> >can
> >I set it to a registered IP address known to the peer but
> not known to the
> >IGP so the neighbor gets the correct registered address for routes
> >advertised?
> >
> >Is BGP with NAT a reasonable thing to do? If not, how can
> you have multiple
> >connections to ISP's behind (say) PIX firewalls?
> >
> > Darren
> >**Please read:http://www.groupstudy.com/list/posting.html
> d
> **Please read:http://www.groupstudy.com/list/posting.html
**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:29:53 GMT-3