From owner-freebsd-current@freebsd.org Mon Jul 3 04:29:58 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B63909DD5A9 for ; Mon, 3 Jul 2017 04:29:58 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2FC4881181 for ; Mon, 3 Jul 2017 04:29:57 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MeMOx-1d50gF1Wj1-00QEYB; Mon, 03 Jul 2017 06:29:48 +0200 Date: Mon, 3 Jul 2017 06:29:41 +0200 From: "O. Hartmann" To: Milan Obuch Cc: ohartmann@walstatt.org, freebsd-current@freebsd.org Subject: Re: static routes on VLAN on CURRENT Message-ID: <20170703062941.4eb9658d@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20170702211217.0d22b349@zeta.dino.sk> References: <20170702133957.1f337a2e@hermann> <20170702143934.2bbcc98a@zeta.dino.sk> <20170702201344.274eb23d@hermann> <20170702211217.0d22b349@zeta.dino.sk> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:shL/qMMemC7ank1g4nv4sujl2ZXMvkGTYSSnUwJt97RsFtfdmI8 dr+EA44Vijwp99j7aiwDUIo7Tz9wWry6AcsIz/1uE/GvhN5BruFNE/XhMliFIUyUe4Zqpit 4EWwmIL2O3/9m794CfLs0E5+lSI/ectbAy1OR176UoI8mHd5ZhT5YU86wX8kk9Kj4eeLyJe hW2yDcNJRzdhhDREUqqNw== X-UI-Out-Filterresults: notjunk:1;V01:K0:gU1UT+eLcrs=:qzCorfXsgp3189OJLpQ5yu WJ9JFTNAOvjsNAEWIL7xhH992PgrGBXCRuu5oowCN0cK/bhYZJ3u+eu3zdWuYMkpICCXd5274 D5zyXd7iDwVesgGv4culjxRP34QGofa73zzdK052HBDpXAwKc2VAAMhn6mEvpNlHqc1SHJ8lQ eOIWxPPe0xlJ9z0wLx5SOPhlj4PTbiXdI9Dq9WQEThT6VC9WmNJOZ8QO2c2frk0UMjpDyrCBe EtBZEbgkSX367EpvHHZVt6CSBv7GQJJyc1a1sqLPVH0IyxyCXDszCDtPQgEIZMAVaa6AT4Iz0 iudu5sVacx+uRzYpOJmJtElty1GS7f5PKxRhJ0Nbd/NpGE7Sn0tgXS1fkODL1zSg1IHgq3sef VTdf1Bw06gmQWdTy7bRNLbjCiB9n9bsU7T89EGThWrOuvCW7176t1H9n61SC8mwhpp1kO5vJ1 loXlnMSDHakUB/6DgrDRj5hqCBdDLIs8yF5upOLc0mngeZoUaIuqo9nnC/9bn8jD2XRxVmnTi XVmBOs9nxV5Gc8jvRXMHfP/j8c0ZLyk1eDeFObzZxNVe++2mtKyqdlVI9WyOZs84Yph2Zxcza Tajqjc40I42sB8353R4pRl9CdOZT2Md/g/lIYQvdTRKzjLqvHg633aIqWnoKd29Z2VZ7QBd4a uOwlD6mvctmRbLpjB/L+bDhnbMJRyoLALy/hP+hhjgS+uE5wdB9SsHaljWy9FqzdCoNVLFDLS n6CBBtbtyRj/mWbDj4nqoX6mdPV3ABs6AYTikSKJKz7EFIhLpGjviPMNIij3l7CtaRXUOR3VD nkH9GVE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jul 2017 04:29:58 -0000 On Sun, 2 Jul 2017 21:12:17 +0200 Milan Obuch wrote: > On Sun, 2 Jul 2017 20:13:49 +0200 > "Hartmann, O." wrote: > > > On Sun, 2 Jul 2017 14:39:34 +0200 > > Milan Obuch wrote: > > [ snip ] > > > > > To not use a routing daemon due to the small size of my network, I > > > > desided to use static routes, in rc.conf I placed the following > > > > variables: > > > > > > > > static_routes="igb1.2 igb1.10" > > > > route_igb1_2="-net 192.168.2.0/24 -interface igb1.2" > > > > route_igb1_10="-net 192.168.10.0/24 -interface igb1.10" > > > > > > > > igb1 is assigned to IP/NET 192.168.0.1/24 > > > > > > Just to be exact, could you show us ifconfig lines from rc.conf as well? > It is common to have something like I do not have entries in cloned_interfaces="". I use vlans_igb1="2 10" and so forth. > > cloned_interfaces="igb1.2 igb1.10" > ifconfig_igb1_2="192.168.2.1/24" > ifconfig_igb1_10="192.168.10.1/24" ifconfig_igb1_2="inet 192.168.2.1 netmask 0xffffff00" same for igb1.10 Additionally, I had the static route definitions. I deleted them and realised that routing is done automatically - something that is not desired in the first place. The "thinking" behind static routes was not to have routing between those interfaces in an automatic manner, but explicitely allowed via the static route. My bad, FBSD seems to have some surprises left. > > and no static routes as you showed, because address assigned to > interface means automatically line in route table, however, they should > look identical to those shown in your first mail. Yes, they do and the routing seems to be established. > > > > > netstat -Warn gives me (as dummy, since I have no direct access to > > > > the box via serial console from the system I write this mail): > > > > > > > > Internet: > > > > Destination Gateway Flags Use Mtu Netif > > > > 127.0.0.1 link#3 UH 334564 16384 lo0 > > > > 192.168.0.0/24 link#4 U 23452 1500 > > > > igb1 192.168.0.1 link#4 UHS 29734 > > > > 16384 lo0 192.168.2.0/24 link#5 U > > > > 271 1500 igb1.2 192.168.2.1 link#5 UHS 0 > > > > 16384 lo0 > > > > > > I think you did not include network 192.168.10.0/24 on igb1.10... > > > > I skipped that, it is quite the same according to the settings of the > > others and unused for now. So it doesn't matter. But you're right. > > > > This was just for tha sake of completteness, nothing else. > > [ sysctl stuff snipped - not relevant, I think ] > > > > > From the routing device itself, it is possible to ssh into a VoIP > > > > client attached to the switch to which igb1.2 trunks the net. > > > > Pinging is also possible. > > > > > > > > Attached to igb1 is the 192.168.0.1/24 network with a bunch of > > > > hosts. From any host within this network it is possible to ping > > > > the 192.168.2.0/24 network and its hosts within, but no SSH, not > > > > web (80, 443). > > > > > > > > > > Weird - if icmp (ping) works and tcp (web, ssh) not, something is > > > filtering traffic. But with net.inet.ip.forwarding=0, even pinging > > > host should not work. Try tcpdump to see what's going on. > > > > net.inet.ip.forwarding works as expected. See above, I confused the > > OID. > > > > [ snip ] > > > > From network architecture view, there is no difference - vlan is > > > network interface just like physical ethernet. Basically everything > > > is the same (sometimes there is issue with mtu, but this hardware > > > dependent). > > > > Yes, so I thought, but as you stated, something is filtering and I > > have no clue what. > > > > Then I just recommend tcpdump - I would use 'tcpdump -nepi igb1.2 host > 192.168.0.x and host 192.168.2.y' and 'tcpdump -nepi igb1 host > 192.168.0.x and host 192.168.2.y' in two session and compare outputs > when pinging from 192.168.0.x to 192.168.2.y and when trying to ssh > from the former to the later. Also there is a question then what these > two devices are, what OS are they running, their network > configuration... then we can analyse the problem better. Thank you very much for the details of analysing. I regret, at the moment I have no access to the facility. But except the device bearing the IP 192.168.2.y, which is a commercial VoIP endpoint, other parties are 12-CURRENT of a very well known OS. I'll check as soon as I have acces. > > Regards, > Milan > Thank you very much and kind regards, Oliver