Re: [Keepalived-devel] Juniper VRRP Conflicts

[Robert P. <rmp...@gm...>]

The juniper was configured by the book with minimal recommended
configuration. I will have logs soon.
On Jul 22, 2011 7:05 PM, "Perkowski, Karol" <kar...@cb...> wrote:
> Besides LVS (something I don't use), your config seems fine. Maybe the
juniper box was misconfigured with the same VRID.
>
> From: Robert Maris [mailto:rmp...@gm...]
> Sent: Friday, July 22, 2011 5:04 PM
> To: Perkowski, Karol
> Cc: kee...@li...
> Subject: Re: [Keepalived-devel] Juniper VRRP Conflicts
>
> Just in case, I have included the fully scrubbed config here. where the
1's and 2's are those subnets match in real life.
>
> Linux somefirewall 2.6.26-2-686 #1 SMP Sun Jun 21 04:57:38 UTC 2009 i686
>
> The programs included with the Debian GNU/Linux system are free software;
> the exact distribution terms for each program are described in the
> individual files in /usr/share/doc/*/copyright.
>
> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
> permitted by applicable law.
> Last login: Fri Jul 22 15:36:30 2011 from strangeplace
> somefirewall:~# cat /etc/keepalived/keepalived.conf
> global_defs {
> ! this is who emails will go to on alerts
> !notification_email {
> ! boo...@bl...<mailto:boo...@bl...>
> ! add more here, if you like
> !}
> !notification_email_from lvs@somefirewall.blah<mailto:
lvs@somefirewall.blah>
>
> ! local machine relays
> !smtp_server 172.27.1.3
> !smtp_connect_timeout 10
> }
>
> vrrp_sync_group VG1 {
> group {
> VI_ETH0_PUBLIC
> VI_ETH1_PRIVATE
> }
> }
>
> vrrp_instance VI_ETH0_PUBLIC {
> state MASTER
> interface eth0
> lvs_sync_daemon_interface eth0
> virtual_router_id 254
> priority 150
> advert_int 1
> !smtp_alert
> authentication {
> auth_type PASS
> auth_pass abc123DEF
> }
> ! Web VIP
> virtual_ipaddress {
> ! App
> 1.1.1.246
> ! Marketing
> 1.1.1.247
> 1.1.1.248
> ! archive
> 1.1.1.249
> ! deploy
> 1.1.1.250
> ! url
> 1.1.1.251
> ! deploy url
> 1.1.1.252
> ! app cloud
> 2.2.2.90
> ! track
> 2.2.2.64
> 2.2.2.74
> ! community
> 2.2.2.65
> 2.2.2.75
> ! help
> 2.2.2.66
> 2.2.2.76
> ! files
> 2.2.2.67
> 2.2.2.77
> ! api
> 2.2.2.68
> 2.2.2.78
> }
> }
>
> vrrp_instance VI_ETH1_PRIVATE {
> state MASTER
> interface eth1
> lvs_sync_daemon_interface eth1
> virtual_router_id 253
> priority 150
> advert_int 1
> !smtp_alert
> authentication {
> auth_type PASS
> auth_pass def456GHI
> }
> ! INT VIP
> virtual_ipaddress {
> 172.27.1.189
> }
> }
>
>
> On Fri, Jul 22, 2011 at 4:29 PM, Perkowski, Karol <kar...@cb...
<mailto:kar...@cb...>> wrote:
> Ouch!
>
> Hopefully, your juniper gear didn't use the same VRID. In that case that
would explain your issues. It sounds weird, that a unauthenticated device
would affect your authenticated box.
>
> Please do provide a full copy of your config (you can strip your
passwords). May sound like a misconfiguration or some weird version bug.
>
> From: Robert Maris [mailto:rmp...@gm...<mailto:rmp...@gm...
>]
> Sent: Friday, July 22, 2011 4:06 PM
> To: kee...@li...<mailto:
kee...@li...>
> Subject: [Keepalived-devel] Juniper VRRP Conflicts
>
> Here is the scenario the best way I can explain it:
>
> We have at our core network 2 virtual chassis configured Juniper EX4200
switches. We recently implemented VRRP on the switches. Now, in our network
we have a pair of IPTABLES firewalls that also use keepalived for HA. Along
with those we have other Linux LVS load balancers that use keepalived for
redundancy.
>
> The Linux IPTABLES and LVS load balancers have authentication setup
between each of their respective boxes. The Juniper EX4200 switches did NOT
have authentication setup and the router-id's are different from the
IPTABLES and Linux LVS load balancers. The issues is this:
>
> When VRRP was introduced at the switches we verified that the switches
were functioning as designed and as we tested them in a lab (our lab did NOT
include load balancers or IPTABLES firewalls or anything else running VRRP
other than the switches). We found that in /var/log/syslog on the IPTABLES
firewalls and the Linux LVS load balancers that it appeared as if the
IPTABLES and Linux LVS load balancers were processing these VRRP multicast
packets sourced from the Juniper Switches because we saw in the logs where
it was receiving priorities that were lower and was forcing reelection.
>
> Once we rolled back our configuration and turned off VRRP on our Juniper
switches and restarted keepalived everything went back to normal.
>
> Why would the IPTABLES and Linux LVS load balancers respective keepalived
process the unauthenticated VRRP multicast packet from the Juniper switches
when authentication is turned on?
>
> I will post a scurbbed configuration of our keepalived.
>
> vrrp_instance VI_ETH0_PUBLIC {
> state MASTER
> interface eth0
> lvs_sync_daemon_interface eth0
> virtual_router_id 254
> priority 150
> advert_int 1
> authentication {
> auth_type PASS
> auth_pass abc123DEF
>
>
> The ETH0_PUBLIC was shown in the logs. This is the same configuration on
both the IPTABLES and Linux LVS load balancers.
>
> Let me know if you need any other information.
>
> Thanks
>