[Dnsmasq-discuss] [FEAT.REQ] Further localisation of --localise-queries

[Alex Hermann]

--nextPart1733351.IQZJTnlbps
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Sunday 01 May 2005 14:19, Luca Landi wrote:
> Alex Hermann ha scritto:
> > >> server: eth0 192.168.1.1 <---> client1 : 192.168.1.101
> > >>         eth1 192.168.1.2 <---> client2 : 192.168.1.102
> > >>         eth2 192.168.1.3 <---> client3 : 192.168.1.103
> > >>         eth3 public ip   <---> inet
>
> Why do you need such a garbled topology? you want your server to act as a
> switch (a Layer-2 switch) but you configured it much like as if it was a
> router (a Layer-3 switch), that is, with an IP address assigned to each
> of its interfaces. To my humble opinion there is a misconception here: if
> you want your server to play the role of the switch then all you have to
> do is to bring up a bridge interface, which means to enslave the physical
> devices (eth0,1,2) to a logical one (traditionally a logical net device
> named something like "br0") and then assign ONE single IP address to the
> *logical* device only.

Sadly enough, some things aren't possible with the (linux) bridging code. M=
y=20
connections are a horrible mix of Gbit, 100Mbit, 10Mbit and wifi. To get=20
the max out of the Gbit connection I need a high MTU on that iface. The=20
bridging code doesn't support a MTU other than 1500 at all (or just not=20
across different bandwidth devices). Also, there seem to be some more=20
problems with my nics and bridging that need some further investigation. I=
=20
still think that my setup is most suitable for my situation and allows for=
=20
maximum performance on every iface.=20

It seems this setup is not common enough to warrant implementation in=20
dnsmasq, so I will look for some workaround.


Alex.

--nextPart1733351.IQZJTnlbps
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQBCdQQ252oeXEXzEHYRAvWAAJ9VJNzsoFz3BdJRjud+UxXbvEY94gCbBK4f
PDBEewWsIlydhejSuqqi5LI=
=Fu+r
-----END PGP SIGNATURE-----

--nextPart1733351.IQZJTnlbps--