From owner-freebsd-net@FreeBSD.ORG Sun Jun 22 08:43:17 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74C5B106568C for ; Sun, 22 Jun 2008 08:43:17 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from aurynhome1sv1.zirakzigil.org (mail.zirakzigil.org [82.63.178.63]) by mx1.freebsd.org (Postfix) with SMTP id A4E1C8FC19 for ; Sun, 22 Jun 2008 08:43:15 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: (qmail 11756 invoked by uid 98); 22 Jun 2008 08:43:14 -0000 Received: from 192.168.229.11 by aurynhome1sv1.zirakzigil.org (envelope-from , uid 89) with qmail-scanner-1.25 ( Clear:RC:1(192.168.229.11):. Processed in 0.038991 secs); 22 Jun 2008 08:43:14 -0000 X-Qmail-Scanner-Mail-From: auryn@zirakzigil.org via aurynhome1sv1.zirakzigil.org X-Qmail-Scanner: 1.25 (Clear:RC:1(192.168.229.11):. Processed in 0.038991 secs) Received: from unknown (HELO aurynhome1ws2.zirakzigil.org) (postmaster@zirakzigil.org@192.168.229.11) by 0 with SMTP; 22 Jun 2008 08:43:13 -0000 Message-ID: <485E109C.9060705@zirakzigil.org> Date: Sun, 22 Jun 2008 10:43:08 +0200 From: Giulio Ferro User-Agent: Thunderbird 2.0.0.0 (X11/20070513) MIME-Version: 1.0 To: Primeroz lists References: <4859877A.3020300@zirakzigil.org> <4859A3A1.6070105@pce-net.com> <485A28ED.9020103@zirakzigil.org> <55b8c6fe0806190330p225ec6d1g65f8424efeab9b41@mail.gmail.com> <485A3DC6.2030500@zirakzigil.org> <55b8c6fe0806190417r440045e6ncf6e99945c453f10@mail.gmail.com> In-Reply-To: <55b8c6fe0806190417r440045e6ncf6e99945c453f10@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, Han Hwei Woo Subject: Re: Problems with vlan + carp + alias X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jun 2008 08:43:17 -0000 Primeroz lists wrote: > What is tcpdump showing for ping on 192.168.10.11 > ? can you see echo reply exiting vlan10 > interface ? > > what if you try from your server to "ping -S 192.168.10.11 > 192.168.10.254 " ? > > > First of all I'm sorry for the late reply. Yesterday I could do some more in-depth test to analyze this strange behavior of my firewall. The 192.168.10.0/24 range I used in the previous example isn't the real one, I just used it for simplicity´s sake. The true range, the one which has been assigned by the ISP to my customer is: x.y.z.128/27. (x.y.z corresponds to a true public IP address) I've deactivated the firewall, so we have one less thing to worry about: /etc/rc.d/pf stop This is a pure network configuration issue. Here is the relevant part in /etc/rc.conf: --------------------------------------------------- ... ifconfig_bce0="inet 192.168.26.1 netmask 255.255.255.0" ... cloned_interfaces="vlan5 vlan25 vlan30 vlan40 vlan128 carp5 carp25 carp30 carp40 carp128" ... ifconfig_vlan128="inet x.y.z.157 netmask 255.255.255.224 vlan 128 vlandev bce0" ... ifconfig_carp128="vhid 128 pass qweq x.y.z.132 netmask 255.255.255.255" ifconfig_carp128_alias0="x.y.z.133 netmask 255.255.255.255" ifconfig_carp128_alias1="x.y.z.134 netmask 255.255.255.255" ifconfig_carp128_alias2="x.y.z.135 netmask 255.255.255.255" ifconfig_carp128_alias3="x.y.z.136 netmask 255.255.255.255" ifconfig_carp128_alias4="x.y.z.137 netmask 255.255.255.255" ifconfig_carp128_alias5="x.y.z.138 netmask 255.255.255.255" ifconfig_carp128_alias6="x.y.z.139 netmask 255.255.255.255" ifconfig_carp128_alias7="x.y.z.140 netmask 255.255.255.255" ifconfig_carp128_alias8="x.y.z.141 netmask 255.255.255.255" ... defaultrouter="x.y.z.129" --------------------------------------------------- On my managed switch I've set 2 ports: 1) the one where the bce0 interface is plugged in : mode trunk with all the vlans above 2) the one where the ISP internet is plugged in : mode access with vlan 128 I've also set the ip interface of my switch to x.y.z.155 vlan 128 Here is the relevant part of netstat -rn on my machine --------------------------------------------------- default x.y.z.129 UGS 0 13966 vlan12 x.y.z/27 link#11 UC 0 0 vlan12 x.y.z.132 x.y.z.132 UH 0 0 carp12 x.y.z.133 x.y.z.133 UH 0 0 carp12 x.y.z.134 x.y.z.134 UH 0 0 carp12 x.y.z.135 x.y.z135 UH 0 0 carp12 x.y.z.136 x.y.z.136 UH 0 0 carp12 x.y.z.137 x.y.z.137 UH 0 0 carp12 x.y.z.138 x.y.z.138 UH 0 0 carp12 x.y.z.139 x.y.z.139 UH 0 0 carp12 x.y.z.140 x.y.z.140 UH 0 0 carp12 x.y.z.141 x.y.z.141 UH 0 0 carp12 x.y.z.155 00:1e:c9:90:4a:c0 UHLW 1 8 vlan12 1183 --------------------------------------------------- Here come the tests. 1) From the firewall : basic I can ping both the default gateway (x.y.z.129) and the switch interface (x.y.z.155) I can ping a generic internet address (a.b.c.d) With tcpdump I can see the packets leaving as x.y.z.157 and coming with the same address 2) from the switch : basic I can ping the firewall's vlan address (x.y.z.157) I can ping _ALL_ the carp interfaces, base and alias: ping x.y.z.157 -> OK ping x.y.z.132 -> OK ping x.y.z.133 -> OK ... ping x.y.z.141 -> OK 3) from the internet : basic From an external internet address I can ping the vlan address: ping x.y.z.157 -> OK 4) from the firewall : advanced From the firewall I can ping the switch address from one of the carp base and aliased address: ping -S x.y.z.132 x.y.z.155 -> OK ping -S x.y.z.133 x.y.z.155 -> OK I _cannot_ ping the default router from one of the carp addresses: ping -S x.y.z.132 x.y.z.129 -> NOT OK ping -S x.y.z.133 x.y.z.129 -> NOT OK By using tcpdump on the vlan128 interface I can see the packets _BOTH_ leaving and coming from the carp addresses. It just seems that the carp interfaces can't process the packets properly. 5) from the internet : advanced From an external internet address I _cannot_ ping the carp addresses (x.y.z.132 and up) As above, I can see the incoming packets with tcpdump -i vlan128 -n icmp Ok, that was long. I hope someone can help to shed light into this, to see whether this is a bug or not. I stress again that the _same_ configuration works as it should on a physical (non-vlan) interface.