On 01/07/2010 16:43, Stuart Purdie wrote:
> And that's why I was wanting the NAT configs, so that I can do a comparison. Lanacaster are using -j MASQUERADE on POSTROUTING, we're using -j SNAT; and that might be enough. Certainly, the code for the two modules in 2.6.18 (SL5.3 default kernel) is markedly different; although I've not had time to fully digest it yet.
>
> Of course, that's not really an optimal answer: MASQUERADE will drop all connections in the event of a network blip, which is not desired. In theory at least - in paractice, it seems to be working at Lancaster.
MASQUERADE only drops connections from the table if the associated network
device is actually down, which shouldn't happen too often in our environments,
so in principle we could get away with using MASQUERADE for the most part. But
obviously in those instances where the interface does go down briefly (e.g. if
rebooting a network switch) MASQUERADE will lose all the connections where SNAT
won't (assuming the interface isn't down long enough for everything to timeout
anyway) so yes, SNAT is preferable where the IP is static.
MASQUERADE vs SNAT shouldn't affect the issue we're seeing though - MASQUERADE
should really just get the IP address to use for translation dynamically and
then hand off the rest of the NAT setup to generic routines. They should
essentially be the same.
'Should' doesn't mean 'must' of course. But there's an easy way to test whether
this is a factor - just get Lancaster to switch their '-j MASQUERADE' to a nice
'-j SNAT --to-source <natboxip>' (which they should really be using anyway) and
see if they start having problems... :-)
--
Robert Fay [log in to unmask]
System Administrator office: 220
High Energy Physics Division tel (int): 43396
Oliver Lodge Laboratory tel (ext): +44 (0)151 794 3396
University of Liverpool http://www.liv.ac.uk/physics/hep/
|