Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Secondary addresses not ping-able #23

Closed
tkurbad opened this issue Apr 12, 2013 · 1 comment
Closed

Secondary addresses not ping-able #23

tkurbad opened this issue Apr 12, 2013 · 1 comment

Comments

@tkurbad
Copy link

tkurbad commented Apr 12, 2013

Hi,

I've successfully set up keepalived's VRRP component to implement an active/standby firewall configuration.

Everything works as expected, however one thing puzzles me:

We've got 64 external IP addresses, thus in my keepalived.conf, I've got sth. like:

# Primary IP
virtual_ipaddress {
     1.2.3.1/26 dev vrrp_extern_0
}

# Secondary IPs (got several of those blocks, each with 20 addresses)
virtual_ipaddress_excluded {
    1.2.3.2/26 dev vrrp_extern_0
    1.2.3.3/26 dev vrrp_extern_0
    1.2.3.4/26 dev vrrp_extern_0
    ...

Additionally, there's an iptables rule to open up ICMP:

iptables -t filter -A INPUT -p icmp -j ACCEPT

Now, from the outside, if I ping the primary address, I get a reply - everything works smoothly.
If, on the other hand, I ping one of the secondary addresses, I don't get a reply.

What am I doing wrong here?

Best,
Torsten

PS: iptables OUTPUT policy is ACCEPT.

@tkurbad
Copy link
Author

tkurbad commented Apr 12, 2013

My bad - the problem was hidden deep in my iptables rules.

@tkurbad tkurbad closed this as completed Apr 12, 2013
MiaoheLin added a commit to MiaoheLin/keepalived that referenced this issue Mar 8, 2019
It's unsafe to use syslog in signal_handler,it may cause deadlock:
#0  0x00007f7d1242248c in __lll_lock_wait_private () from /lib64/libc.so.6
acassen#1  0x00007f7d1239e3cd in _L_lock_15626 () from /lib64/libc.so.6
acassen#2  0x00007f7d1239b4d3 in malloc () from /lib64/libc.so.6
acassen#3  0x00007f7d1238da5a in open_memstream () from /lib64/libc.so.6
acassen#4  0x00007f7d1240e32a in __vsyslog_chk () from /lib64/libc.so.6
acassen#5  0x00007f7d1240e922 in __syslog_chk () from /lib64/libc.so.6
acassen#6  0x000055691ddd60bf in syslog (__fmt=0x55691dddeb6f "%s", __pri=6) at /usr/include/bits/syslog.h:31
acassen#7  vlog_message (facility=6, format=<optimized out>, args=args@entry=0x7ffe4c1b8900) at logger.c:50
acassen#8  0x000055691ddd6184 in log_message (facility=facility@entry=6, 
    format=format@entry=0x55691dde5d50 "BUG - write to signal_pipe[1] error %s - please report") at logger.c:59
acassen#9  0x000055691ddd5805 in signal_handler (sig=1) at signals.c:100
acassen#10 <signal handler called>
acassen#11 0x00007f7d1242248a in __lll_lock_wait_private () from /lib64/libc.so.6
acassen#12 0x00007f7d1239e3cd in _L_lock_15626 () from /lib64/libc.so.6
acassen#13 0x00007f7d1239b4d3 in malloc () from /lib64/libc.so.6
acassen#14 0x00007f7d1238da5a in open_memstream () from /lib64/libc.so.6
acassen#15 0x00007f7d1240e32a in __vsyslog_chk () from /lib64/libc.so.6
acassen#16 0x00007f7d1240e922 in __syslog_chk () from /lib64/libc.so.6
acassen#17 0x000055691ddd60bf in syslog (__fmt=0x55691dddeb6f "%s", __pri=6) at /usr/include/bits/syslog.h:31
acassen#18 vlog_message (facility=6, format=<optimized out>, args=args@entry=0x7ffe4c1b9380) at logger.c:50
acassen#19 0x000055691ddd6184 in log_message (facility=facility@entry=6, 
    format=format@entry=0x55691dde5d50 "BUG - write to signal_pipe[1] error %s - please report") at logger.c:59
acassen#20 0x000055691ddd5805 in signal_handler (sig=17) at signals.c:100
acassen#21 <signal handler called>
acassen#22 0x00007f7d12398de4 in _int_malloc () from /lib64/libc.so.6
acassen#23 0x00007f7d1239bf04 in calloc () from /lib64/libc.so.6
acassen#24 0x00007f7d13e5f409 in __nlmsg_alloc () from /lib64/libnl-3.so.200
acassen#25 0x00007f7d13e5f846 in nlmsg_convert () from /lib64/libnl-3.so.200
acassen#26 0x00007f7d13e61daf in nl_recvmsgs_report () from /lib64/libnl-3.so.200
acassen#27 0x00007f7d13e624a9 in nl_recvmsgs () from /lib64/libnl-3.so.200
acassen#28 0x00007f7d13e62511 in nl_wait_for_ack () from /lib64/libnl-3.so.200
acassen#29 0x00007f7d14073ad0 in genl_ctrl_probe_by_name () from /lib64/libnl-genl-3.so.200
acassen#30 0x00007f7d14073ceb in genl_ctrl_resolve () from /lib64/libnl-genl-3.so.200
acassen#31 0x000055691dda0b55 in ipvs_nl_send_message (msg=msg@entry=0x556924f077a0, 
    func=func@entry=0x55691dda0b00 <ipvs_nl_noop_cb>, arg=arg@entry=0x0) at libipvs.c:302
acassen#32 0x000055691dda515f in ipvs_add_laddr (svc=0x55692fc2ac10, laddr=0x5569359d34e0) at libipvs.c:930
acassen#33 0x000055691dd9d273 in ipvs_talk (cmd=cmd@entry=1168, daemonrule=daemonrule@entry=0x0, 
    ignore_error=ignore_error@entry=false) at ipvswrapper.c:255
acassen#34 0x000055691dd9d614 in ipvs_laddr_group_cmd (cmd=cmd@entry=1168, laddr_group=laddr_group@entry=0x556932f1b4e0)
    at ipvswrapper.c:626
acassen#35 0x000055691dd9f24a in ipvs_laddr_cmd (vs=0x55692fc2ac10, cmd=1168) at ipvswrapper.c:804
acassen#36 ipvs_cmd (cmd=cmd@entry=1168, vs=vs@entry=0x556931f77e70, rs=rs@entry=0x0) at ipvswrapper.c:874
acassen#37 0x000055691dd9b610 in init_service_laddr (vs=0x556931f77e70) at ipwrapper.c:672
acassen#38 init_service_vs (vs=0x556931f77e70) at ipwrapper.c:762
acassen#39 0x000055691dd9baa1 in init_services () at ipwrapper.c:815
acassen#40 0x000055691dd8dc45 in start_check () at check_daemon.c:277
---Type <return> to continue, or q <return> to quit---
acassen#41 0x000055691dd8dfe5 in reload_check_thread (thread=<optimized out>) at check_daemon.c:399
acassen#42 0x000055691ddd3bde in thread_call (thread=0x7ffe4c1ba010) at scheduler.c:963
acassen#43 launch_scheduler () at scheduler.c:986
acassen#44 0x000055691dd8e1af in start_check_child () at check_daemon.c:522
acassen#45 0x000055691dd89340 in start_keepalived () at main.c:337
acassen#46 keepalived_main (argc=2, argv=<optimized out>) at main.c:1064
acassen#47 0x00007f7d12338455 in __libc_start_main () from /lib64/libc.so.6
acassen#48 0x000055691dd879fe in _start ()
I wonder if we can use fprintf instead of log_message ? fprintf is safe in signal handler.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant