vrrp problems
Andrea Venturoli
ml.ventu at flashnet.it
Sun Jul 6 07:14:32 PDT 2003
Hello.
I'm trying to set up vrrp on two machines and while it seems to work on one, it
does not on the other.
Here's my config:
# This is a simple configuration file for freevrrpd
# Please read the documentation before modifying these parameters
# I recommend to not set addr to the unique and real ip of your server because
# if freevrrpd will shutdown, your server will don't have any IP address.
# a good utilization is to set a real IP address not managed by freevrrpd and
# then choosing an alias for the virtual IP address managed by freevrrpd
#
# Each VRID Section must begin with [VRID] keyword
[VRID]
# serverid is needed to specify the number of the VRID, here VRID = 1
serverid = 1
# you must set interface with a real interface name of your system
interface = xl0
# priority = 255 is a MASTER of the VRID
# priority < 255 is a BACKUP with a priority 0 to 254
# 254 is a higher BACKUP priority
priority = 254
# addr option is need to specify ip address(es) associated with the VRID
# you can specify multiple addresses separated by ','
# netmask is specified with CIDR notation so number after '/' represent the
# number of bits set to 1 for the netmask.
# eg: /24 is 11111111 11111111 11111111 00000000 = 255.255.255.0
addr = 10.1.2.127/32
# if you want to authenticate your VRRP packets you can set a password
# associated with this VRID. this is not required but is you don't set a
# password, everybody in your LAN can generate VRRP packets without
# authentification. If you set this, you must set it to BACKUP VRID too, if you
# don't, all BACKUP VRRP packets will be rejected.
password = xxx
# now, you can specify a script name to execute when this host became master
# of this VRID
#masterscript = "/usr/local/bin/master_script.sh"
# and you can specify a script name to execute when this host became backup
# too
#backupscript = "/usr/local/bin/backup_script.sh"
# if physical interface attached to VRID 1 fail you can specify one or more
# VRIDs that must go to backup state in the same time. (monitored circuits)
# in this example if rl0 is faulty, xl0 and bge0 go to backup state mode
# This is extremly useful to avoir blackhole with Firewalls with two interfaces
#vridsdep = 2, 3
#[VRID]
serverid = 2
interface = xl0
priority = 255
addr = 10.1.2.126/32
password = xxx
As you can see I defined two VRID, but also tried the first one alone (and also
as a master).
And here's what I see when I do freevrrp -F:
initialize !
VServer ID : 2
VServer PRIO : 255
VServer ETHADDR : 00:00:5e:00:01:02
VServer CNT_IP : 1
VServer IPs :
10.1.2.126
VServer ADV_INT : 1
VServer MASTER_DW_TM : 3
VServer SKEW_TIME : 0
VServer State : 0
Server IF_NAME : xl0
Server NB_IP : 1
Server IPs :
10.1.2.15
Server ETHADDR : 00:50:04:22:a9:c0
but then nothing's happen. Is it normal that only one VRID is displayed?
I see igmp packet going out on xl0 (which I happened sometimes to block with
ipfw) and vrrp packets going out (which ipfw should not allow, but pass
anyway), but ifconfig gives:
xl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=3<rxcsum,txcsum>
inet 10.1.2.15 netmask 0xffffff00 broadcast 10.1.2.255
ether 00:50:04:22:a9:c0
media: Ethernet 10baseT/UTP (10baseT/UTP <half-duplex>)
ed0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.0.255
ether 52:54:40:28:e5:a2
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
What I would expect is that xl0 gets both 10.1.2.126 and 10.1.2.127, since I've
not started vrrp on the other machine yet.
In the log I see:
freevrrpd[532]: initializing threads and all VRID
freevrrpd[532]: reading configuration file /usr/local/etc/freevrrpd.conf
and when I quit:
freevrrpd[532]: restoring real MAC address: 00:50:04:22:A9:C0 for interface xl0
Sometimes, but not often, a message will appear like:
freevrrpd[15704]: interface xl0 is faulty, deactivated from VRRP VRIDs
So my question is: how do I start debugging this?
bye & Thanks
av.
More information about the freebsd-net
mailing list