Dear all,
Has anyone experienced this whilst running DRBD over eth1 between two CentOS 5.7 servers?
eth1 is a private IP address, unroutable. eth0 is the public address. CentOS will reply sometimes once every 3 days or every 14mins~ saying "My public IP is on eth1" to arp requests when it's not, it's eth0.
This freezes traffic and causes issues. We've looked at arp* /etc/sysctl.conf etc. and arptables, but wondered if anyone had a recipe?
We have this already which didn't help as it happened Christmas Eve too as we kept eth1 up for a few days to test:
# For the dual interface - 06.12.12 net.ipv4.conf.eth0.arp_filter = 1 net.ipv4.conf.eth0.arp_ignore = 1 net.ipv4.conf.eth1.arp_filter = 1 net.ipv4.conf.eth1.arp_ignore = 1 net.ipv4.conf.all.arp_filter = 1
eth0 and eth1 are on the same VLAN/broadcast domain, but eth1 is a 169.xx and eth0 is a routable public IP.
We're having to shut eth1 down and bring it up for sync at night.
Thanks,
Gavin.
On 12/26/2012 04:33 AM, Mike Burger wrote:
169.xxx.xxx.xxx is most certainly a "routable" IP block, as far as internet standards go.
Most of 169/8 is, but presumably he meant 169.254.0.0/16.
The only "non-routable" (i.e. reserved for private networks) IP blocks are:
The list is slightly longer than that: http://en.wikipedia.org/wiki/Reserved_IP_addresses#Reserved_IPv4_addresses
On 12/26/2012 04:33 AM, Mike Burger wrote:
169.xxx.xxx.xxx is most certainly a "routable" IP block, as far as internet standards go.
Most of 169/8 is, but presumably he meant 169.254.0.0/16.
The only "non-routable" (i.e. reserved for private networks) IP blocks are:
The list is slightly longer than that: http://en.wikipedia.org/wiki/Reserved_IP_addresses#Reserved_IPv4_addresses
Fair enough...I've just never seen anyone actually use it.
On Wed, Dec 26, 2012 at 12:25 PM, Mike Burger mburger@bubbanfriends.orgwrote:
On 12/26/2012 04:33 AM, Mike Burger wrote:
169.xxx.xxx.xxx is most certainly a "routable" IP block, as far as internet standards go.
Most of 169/8 is, but presumably he meant 169.254.0.0/16.
The only "non-routable" (i.e. reserved for private networks) IP blocks are:
The list is slightly longer than that:
http://en.wikipedia.org/wiki/Reserved_IP_addresses#Reserved_IPv4_addresses
Fair enough...I've just never seen anyone actually use it.
I've only ever seen 169.254.0.0/16 used by ZeroConf on Windows boxes and I expect Avahi (zero conf alternative) on Linux does the same.
-- Mike Burger http://www.bubbanfriends.org
"It's always suicide-mission this, save-the-planet that. No one ever just stops by to say 'hi' anymore." --Colonel Jack O'Neill, SG1
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Most of 169/8 is, but presumably he meant 169.254.0.0/16.
The only "non-routable" (i.e. reserved for private networks) IP blocks are:
The list is slightly longer than that: http://en.wikipedia.org/wiki/Reserved_IP_addresses#Reserved_IPv4_addresses
No, Mike was right. 169.x.x.x which is wrong, but will be a local static route so won't matter localling, but the switch may not do anything to private vs publically assigned IP addresses as it's layer 2.
Thanks,
Gavin.
We're having to shut eth1 down and bring it up for sync at night.
To what type of equipment are your ethernet devices connected?
I'm asking now.
Are they both connected to the same device?
Same VLAN, not sure about same device yet. Checking.
I've seen some devices (particularly 2Wire) that do not like two interfaces from the same system connected to them.
Reading the arp_filter settings it does match what we're experiencing, but I've never seen it before, but haven't ever been looking for it. Maybe because this is SIP/RTP traffic vs normal data traffic which when the switch switches the MAC <-> IP ARP mappings the voice traffic drops.
You wouldn't noticed that on normal data traffic. arpwatch is picking up the flip flops.
You note that eth1 is on a 169.xx IP, and earlier in your email, you note that it's non-routable. Perhaps that's not the wording you wished, to use, or perhaps you meant that it's not routed out to the internet, however, 169.xxx.xxx.xxx is most certainly a "routable" IP block, as far as internet standards go.
You're right. We're using 169.0.0.1-2 when we shouldn't be! It should be either in the ranges below or 169.254.x.x. Doh!
The only "non-routable" (i.e. reserved for private networks) IP blocks are:
10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255
While certainly not an undertaking to be done lightly, you may wish to renumber your internal network.
For two DRBD interfaces this will be fine but will need an umount or schedule reboot for the pair.
Thanks,
Gavin.
On 12/26/2012 02:06 AM, Gavin Henry wrote:
# For the dual interface - 06.12.12 net.ipv4.conf.eth0.arp_filter = 1 net.ipv4.conf.eth0.arp_ignore = 1 net.ipv4.conf.eth1.arp_filter = 1 net.ipv4.conf.eth1.arp_ignore = 1 net.ipv4.conf.all.arp_filter = 1
First things first... Can you confirm that those are still the values in place?
cat /proc/sys/net/ipv4/conf/eth0/arp_filter cat /proc/sys/net/ipv4/conf/eth0/arp_ignore cat /proc/sys/net/ipv4/conf/eth1/arp_filter cat /proc/sys/net/ipv4/conf/eth1/arp_ignore cat /proc/sys/net/ipv4/conf/all/arp_filter
First things first... Can you confirm that those are still the values in
place?
cat /proc/sys/net/ipv4/conf/eth0/arp_filter cat /proc/sys/net/ipv4/conf/eth0/arp_ignore cat /proc/sys/net/ipv4/conf/eth1/arp_filter cat /proc/sys/net/ipv4/conf/eth1/arp_ignore cat /proc/sys/net/ipv4/conf/all/arp_filter
Obviously when we ifdown eth1 the eth1 statements above are 0. Right now eth1 is up with a sysctl -p and all set to 1.
Thanks,
Gavin.
Couldn't get this to work so had to disable it.
On 26 December 2012 19:47, Gavin Henry gavin.henry@gmail.com wrote:
First things first... Can you confirm that those are still the values in
place?
cat /proc/sys/net/ipv4/conf/eth0/arp_filter cat /proc/sys/net/ipv4/conf/eth0/arp_ignore cat /proc/sys/net/ipv4/conf/eth1/arp_filter cat /proc/sys/net/ipv4/conf/eth1/arp_ignore cat /proc/sys/net/ipv4/conf/all/arp_filter
Obviously when we ifdown eth1 the eth1 statements above are 0. Right now eth1 is up with a sysctl -p and all set to 1.
Thanks,
Gavin.
-
Gavin Henry -
Gordon Messmer -
Mike Burger -
SilverTip257