[Pacemaker] IPaddr2 between eth1 e bond1

[Michael Schwartzkopff]

Am Montag, 7. Oktober 2013, 15:38:32 schrieb Jelle de Jong:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 06/10/13 23:27, Andreas Kurz wrote:
> > On 2013-10-05 02:04, Charles Mean wrote:
> >> Hello guys,
> >> 
> >> I have a cluster with 2 nginx sharing one VIP:
> >> 
> >> primitive VIP_AD_SRV ocf:heartbeat:IPaddr2 params ip="X.Y.Z.W"
> >> cidr_netmask="30" nic="eth1" op monitor interval="1s"
> >> 
> >> 
> >> The problem is that I have replaced on of those two server and
> >> the new one can't connect over eth1 just over bond1, so, when I
> >> move the resource to this new server it creates a virtual
> >> interface at eth1 and I never reach it. Is there a way to solve
> >> this situation ?
> > 
> > Simply don't specify "nic" if you don't have several interfaces in
> > the same network. The resource agent will find the interface by
> > looking at interfaces having already an IP in the same network
> > configured ... no matter whether they are simple/bond/bridges/vlan
> > interfaces.
> 
> So the bellow is wrong? Just wondering here.....
> 
> primitive ip_virtual0 ocf:heartbeat:IPaddr2 \
>         params nic="vlan10" ip="192.168.35.10" cidr_netmask="28" \
>         op monitor interval="10s"
> 
> When vlan10 also uses IP 192.168.35.4/28, 192.168.35.10 is my tgtd IP.
> 
> # ip addr show vlan10
> 9: vlan10 at bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc
> noqueue state UP
>     link/ether 00:1e:67:6b:f7:14 brd ff:ff:ff:ff:ff:ff
>     inet 192.168.35.4/28 brd 192.168.35.15 scope global vlan10
>     inet 192.168.35.10/28 brd 192.168.35.15 scope global secondary vlan10
>     inet6 fe80::21e:67ff:fe6b:f714/64 scope link
>        valid_lft forever preferred_lft forever
> 
> Kind regards,
> 
> Jelle de Jong

Looks OK.

-- 
Dr. Michael Schwartzkopff
Guardinistr. 63
81375 München

Tel: (0163) 172 50 98
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20131007/628059bc/attachment-0003.html>