All of lore.kernel.org
 help / color / mirror / Atom feed
From: Grant Taylor <gtaylor@riverviewtech.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] Bridging two subnets selectively using routing
Date: Sun, 04 Nov 2007 20:14:14 +0000	[thread overview]
Message-ID: <472E2816.5070301@riverviewtech.net> (raw)
In-Reply-To: <20071101005039.GA4906@triplehelix.org>

On 11/2/2007 11:35 PM, Corey Hickey wrote:
> I meant to do both, which I think is necessary in order to make the 
> OPs proposed scheme work without modification. I'll defer if I'm 
> wrong, though--I haven't tested it, and, as you said in your other 
> email, it's "a very weird scenario."

As long as there are routes in both directions there should be no need 
for SNATing.

> I don't think this will work unless BR has a route like:
> 
> # ip route add 192.168.4.0/24 via 10.3.0.13 dev eth0
> 
> ...whereas the OP only specified wanting routes to a few specific 
> machines rather than the whole networks.
> 
> In any case, debating that is probably academic, since I agree with 
> you in principle. It should be cleaner to set up routes for the whole 
> networks and use iptables rules on A1 to only allow traffic to/from 
> specified hosts.

Agreed.  I mis read the routes on the two routers AR and BR to be for 
the entire networks.  Though again presuming there are routes, things 
should work.  This is more just a semantical mis-interpretation on the 
scope of what the routes are for.

> There are certainly different ways to do it, and I furthermore agree 
> with you that using a separate link between AR and BR (as you 
> suggested in your earlier message) is cleaner still.
> 
> I prefer bridging in this situation mostly because it distributes 
> traffic and reduces the load on the routers.

I can see how this would reduce load on the routes, but I don't believe 
that load on routers will be much of a concern.  (At least the routers 
that I use (pick any box (less than 10 years old) and install Linux) 
would do just fine.

However I would be concerned about broadcast storms being propagated 
across the bridge unnecessarily.  But if steps are taken to mitigate 
that then it is probably not that big of an issue.

> The two networks in question are rather small and occupy adjoining 
> buildings. Network A had to be rebuilt after getting torn out while 
> the corresponding building underwent a very intrusive retrofit and 
> remodeling. Prior to that, the two networks were bridged and shared 
> the same subnet. I don't know if the OP has a reason to isolate them 
> from each other now.

Ok...  Obviously you are probably in a very unique position knowing the 
history of the network.

> I guess I'll go ahead and describe the former setup in a little 
> detail.
> 
> Every host in the entire bridged network was given an IP address 
> within the subnet 10.0.0.0/8. The bridge was configured to drop all 
> DHCP packets, so there was a DHCP server on network A and another on 
> network B.

Ok...

> Hosts on network A were given addresses in the following ranges[1]:
> 
> 10.0.0.0/16
> 10.1.0.0/16
> 10.2.0.0/16
> 
> Hosts on network B were given addresses in the following range: 
> 
> 10.3.0.0/16
> 
> ...but, regardless of which network a host was on, it still was given 
> the /8 subnet, so hosts could communicate over the bridge without any 
> further configuration.

Ok, you chose to do in bridging what most people do in routing.  Seeing 
as how things were bridged you had to put things in place to stop things 
that would naturally leave the subnet.  Your preference to have and work 
with.

> Since each network had its own router to the Internet, the DHCP 
> servers also specified separate gateways. The bridge was configured 
> to drop packets with sources or destinations that didn't match the IP 
> ranges corresponding to the source/destination networks[2].

Ok...

> That's all.

So let me get this right, you did bridging rather than routing to avoid 
load on the router(s)?  Yet you had to put more load on the bridging 
host to segregate the networks like they would be if they were routed 
while still allowing host to host communications between the two buildings?

<personal opinion> Strange </personal opinion>

> My philosophy was to allow unrestricted communication over the bridge 
> and gently LART users that caused trouble (always inadvertently; 
> Windows worms and such). If the OP wants to allow communication only 
> to a few hosts, that's no more difficult--just write a few rules to 
> accept desired traffic and then drop/reject the rest.

Ok.

> [1] Given the chance to do it over, I would have allocated addresses 
> to network A from 10.0.0.0/18 and network B from 10.4.0.0/18 in order 
> to simplify a little bit. Also, I should mention that the use of 
> several /16 ranges doesn't mean we had anywhere near that many hosts; 
> the separation was just for management.

*nod*

> [2] Just in case some users on network B tried to manually set their 
> IP address and gateway in order to use the better Internet access of 
> network A. Of course, they could still have tunneled through the 
> bridge to an accomplice on network A, but they could have also used 
> an accomplice's wireless router, or CAT-5 strung between rooftops, or 
> RFC 1149, etc. I dealt with such things on a case-by-case basis. :)

That's what a "Clue-by-4" is used for.  ;)

All in all you chose to implement a solution in one way that very like 
did exactly what you needed even if it was a bit different than what the 
industry norm would have been.  Either way, bridging or routing, they 
both would have / do / will work.



Grant. . . .
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

      parent reply	other threads:[~2007-11-04 20:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-01  0:50 [LARTC] Bridging two subnets selectively using routing Joshua Kwan
2007-11-02 20:24 ` Corey Hickey
2007-11-03  0:39 ` Grant Taylor
2007-11-03  0:51 ` Grant Taylor
2007-11-03  4:35 ` Corey Hickey
2007-11-04 20:14 ` Grant Taylor [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=472E2816.5070301@riverviewtech.net \
    --to=gtaylor@riverviewtech.net \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.