On Monday, April 25, 2016 11:56 CEST, Martin Pieuchot <[email protected]>
wrote:
> On 25/04/16(Mon) 11:35, Kim Zeitler wrote:
> > Hello Martin
> >
> >
> > On 04/25/16 11:12, Martin Pieuchot wrote:
> > >On 25/04/16(Mon) 10:47, Kim Zeitler wrote:
> >
> > >>He is running a carp interface on top of a vlan interface. In this
scenario
> > >>the carp interface can not be pinged but the vlan interfaces can.
> > >
> > >Do you mean the CARP node does not answer to ping with a destination
> > >address on the carp(4) interfaces? Is it for MASTER, BACKUP or both?
> > >
> > em2 (no ip) ---> vlan100 (192.168.150.200) ---> carp2 (192.168.150.1)
> > \
> > --> vlan101 (192.168.151.200) ---> carp3 (192.168.151.1)
> >
> > This is my setup
> > if I ping either address assigned to carp2 or carp3 from a host on the
> > network I do not get an answer, pinging the vlan address answers.
>
> When doing so, please use "# tcpdump -nvei carp2 icmp" to see if the
> echo request/reply reach/leave the interface.
I tried again this morning, but I unfortunately messed up with the tcpdump,
the produced file has 0 size :(
I did shut down the "old" 5.2 master node, and restarted the "backup" node,
just to be sure to have a clean state.
I did this on carp90, and then pinging my default gateway.
again like yesterday, I saw this in the dmesg of the default gateway:
Apr 26 05:02:00 srv93 /bsd: arp info overwritten for 172.16.99.1 by
90:e2:ba:2c:b5:08 on trunk0
Apr 26 05:05:43 srv93 /bsd: arp info overwritten for 172.16.99.1 by
00:00:5e:00:01:01 on trunk0
Apr 26 05:06:27 srv93 /bsd: arp info overwritten for 172.16.99.1 by
90:e2:ba:2c:b5:08 on trunk0
Apr 26 05:06:28 srv93 /bsd: arp info overwritten for 172.16.99.1 by
00:00:5e:00:01:01 on trunk0
Apr 26 05:23:32 srv93 /bsd: arp info overwritten for 172.16.99.1 by
90:e2:ba:2c:b5:08 on trunk0
Apr 26 05:23:32 srv93 /bsd: arp info overwritten for 172.16.99.1 by
00:00:5e:00:01:01 on trunk0
Apr 26 05:27:38 srv93 /bsd: arp info overwritten for 172.16.99.1 by
90:e2:ba:2c:b5:08 on trunk0
Apr 26 05:27:42 srv93 /bsd: arp info overwritten for 172.16.99.1 by
00:00:5e:00:01:01 on trunk0
On the problematic firewall, I see this arp entry for the upstream firewall:
172.16.99.2 00:00:5e:00:01:03 carp90 13m55s
which looks good to me.
Unfortunately the tcpdump is missing, seeing the MAC addresses that go out :(
anyways, attached netstat -rn -f inet directly after startup of the firewall,
before the ping
to the default gateway, as well as after pinging the default gateway.
However, what I did from a desktop to the firewall:
Desktop IP: 10.10.0.31/24
FW IP: 10.10.0.1/24
arp on the Carp Firewall:
10.10.0.31 88:51:fb:56:30:3b carp7 19m55s
arp on the desktop (a windows box):
Internet Address Physical Address Type
10.10.0.1 00-00-5e-00-01-01 dynamic
That seems to be fine, and arp resolution should work.
Then I pinged from the desktop the 10.10.0.1, but did not receieved any answer
packet.
On the firewall, at least that I rememver, I ran tcpdump on carp7, as well as
on vlan7,
but I did not saw any packets flying by. I messed a bit with tcpdump on the
underlying trunk,
only ran tcpdump -n -i trunk0 -e -v icmp, so I missed the vlan packets and
cannot say if
these showed up there.
here the ifconfig output again:
default gateway stack:
ix0 and ix1 -> trunk0 -> vlan90 -> carp90
stack to the desktop:
ix0 and ix1 -> trunk0 -> vlan7 -> carp7
ix0:
flags=18b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST,MPSAFE>
mtu 1500
lladdr 90:e2:ba:2c:b5:08
description: PHYS_INT_TRK
priority: 0
trunk: trunkdev trunk0
media: Ethernet autoselect
status: no carrier
root@srv80:~# ifconfig ix1
ix1:
flags=18b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST,MPSAFE>
mtu 1500
lladdr 90:e2:ba:2c:b5:08
description: PHYS_INT_TRK
priority: 0
trunk: trunkdev trunk0
media: Ethernet autoselect (10GSFP+Cu full-duplex)
status: active
root@srv80:~# ifconfig trunk0
trunk0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
lladdr 90:e2:ba:2c:b5:08
description: INTERNAL_TRUNK
priority: 0
trunk: trunkproto lacp
trunk id: [(8000,90:e2:ba:2c:b5:08,4045,0000,0000),
(FFFF,00:00:00:00:00:00,0000,0000,0000)]
trunkport ix1 active,collecting,distributing
trunkport ix0
groups: trunk
media: Ethernet autoselect
status: active
inet 192.168.9.252 netmask 0xffffff00 broadcast 192.168.9.255
root@srv80:~# ifconfig vlan90
vlan90: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
lladdr 90:e2:ba:2c:b5:08
description: NKE_IPB_VLAN
priority: 0
vlan: 90 parent interface: trunk0
groups: vlan
root@srv80:~# ifconfig carp90
carp90: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:00:5e:00:01:01
description: NKE_IPB
priority: 15
carp: BACKUP carpdev vlan90 vhid 1 advbase 1 advskew 100
groups: carp
status: backup
inet 172.16.99.1 netmask 0xffffff00 broadcast 172.16.99.255
root@srv80:~# ifconfig vlan7
vlan7: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
lladdr 90:e2:ba:2c:b5:08
description: IT_VLAN
priority: 0
vlan: 7 parent interface: trunk0
groups: vlan
inet 10.148.242.3 netmask 0xfffffe00 broadcast 10.148.243.255
root@srv80:~# ifconfig carp7
carp7: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
lladdr 00:00:5e:00:01:01
description: IT
priority: 15
carp: BACKUP carpdev vlan7 vhid 1 advbase 1 advskew 100
groups: carp
status: backup
inet 10.10.0.1 netmask 0xffffff00 broadcast 10.10.0.255
inet 10.148.242.1 netmask 0xfffffe00 broadcast 10.148.243.255
Then I added a 10.10.0.166 IP on the vlan7 interface, that I could ping
without issues, but the 10.10.0.1 carp interface was not pingable from
the desktop.
even with the missing tcpdump, hope it may shed a bit more light?
Sebastian
>
> > One node is clearly in MASTER, the other in BACKUP, demote works.
>
> The routing table correspond to which node? MASTER or BACKUP? There's
> something really weird in it, the RTF_CLONING routes are done.
>
> Could you include your whole routing table? Do you have an entry for
> the machine initiating the ping?
>
> > The host also has two further carp interfaces sitting directly on a
physical
> > interface which work as expected.
>
> Then why excluding this information from the table?
[demime 1.01d removed an attachment of type application/octet-stream]
[demime 1.01d removed an attachment of type application/octet-stream]
