[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: multi-homed,masquerading
On Mon, Jul 31, 2000 at 03:06:39PM +0200, Lawrence Mashungwa wrote:
> > IBGP runs between two routers within the same AS. So if you have only one
> > router, you can't run IBGP.
> >
> True.. get two routers..
Doesn't really help you much :-)
The problem is that the upstream connections are both wireless bridged LANs.
Let's imagine that you got your own router, and you put it between the two
segments you have access to:
Upstream Upstream
^ ^
| |
^ +-----+ +-----+
ISPs | R1 | | R2 |
v +-----+ +-----+
| NET1 | NET2
^ ******************* *********************
Wireless * | | * | |
v * C1a C1b * C2a C2b
* *
| |
^ | +---+ |
Your +------+----| R |----+---+---+----+
Network | +---+ | | |
v PC1 PC2 PC3 PC4
(C1a, C1b are customers of ISP1; R1 is ISP1's router. C1a/C1b point default
route at R1, and C2a/C2b point default route at R2). R is your new router.
Now, it is easy to arrange on R so that traffic bound for NET1 goes out of
the left interface, and traffic to NET2 goes out of the right interface. In
fact, this will happen automatically, because they are both connected
routes.
So, a ping from (say) PC2 to C1a will go the right way, if PC2 points
default route at R.
The problem is that the return traffic from C1a to PC2 will take the long
way round. C1a points default route at R1, so the traffic will go to R1, out
through the Internet, back through the Internet onto NET2, onto PC2's
interface.
Now, there are a few solutions here:
(1) you can individually BGP peer with all of the customers C1a, C1b, etc,
so they learn the route back to you. (This is unlikely to happen, especially
since in your environment I think they are connecting mainly just PCs
directly onto the wireless network, not routers)
(2) my preferred solution: persuade ISP1 and ISP2 to peer with each other,
by running a link from R1 to R2 (or even having a presence on each other's
wireless segments). Then traffic between C1a and C2a will also take the
shorter path, rather than going to the Internet and back.
(3) set up all your servers with dual IP addresses:
^ | +---+ |
Your +--+---+----| R |----+---+--------+
Network | | +---+ | |
v | | | |
| +---- PC1 ----+ |
+-------- PC2 --------+
Then when PC1 sends a ping to C1a it will use one source address, but when
it pings C2a it will use the other source address (the source address is the
IP address of the interface which the packet leaves through). That solves
the problem of outgoing connections, but not incoming ones from C1a to PC1,
which may still go to the 'wrong' interface and therefore go the long way
round.
(4) Do NAT in your router. So if a packet starts at PC2 but is heading
towards C1a, then as it goes through it is translated to R's own address.
This again allows you to do 'outgoing' connections with a short path, but
does not fix 'incoming' connections.
So in summary - doing routing frigs at your side is likely to be very
complicated. See if you can persuade your ISPs to peer with each other. They
don't need any special hardware to do this: if they are in the same
building, and have a spare router port each, then a crossed ethernet cable
is fine. If not, and one of them has a spare ethernet port, they can put up
a radio node on the other ISP's network.
By the way, whatever you do, under no circumstances connect both ISP
connections into the same switch or hub!!! In the best case - broadcast
packets from one segment will appear on the other segment, wasting bandwidth
for both ISPs. In the worst case - if someone else is also doing this, you
will set up a layer 2 forwarding loop and flood both networks with
broadcasts.
Cheers,
Brian.
-----
This is the afnog mailing list, managed by Majordomo 1.94.4
To send a message to this list, e-mail afnog at afnog.org
To send a requet to majordomo, e-mail majordomo at afnog.org and put
your request in the body of the message (i.e use "help" for help)
This list is mantained by owner-afnog at afnog.org