From owner-freebsd-hackers@freebsd.org Mon Jan 14 18:21:35 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5483B1482C96 for ; Mon, 14 Jan 2019 18:21:35 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 657636F19A for ; Mon, 14 Jan 2019 18:21:34 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x0EILVLS036357; Mon, 14 Jan 2019 10:21:31 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x0EILVem036356; Mon, 14 Jan 2019 10:21:31 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201901141821.x0EILVem036356@pdx.rh.CN85.dnsmgr.net> Subject: Re: Removing an alias can remove routes ? In-Reply-To: To: Mark Saad Date: Mon, 14 Jan 2019 10:21:31 -0800 (PST) CC: FreeBSD Hackers X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 657636F19A X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.51 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.63)[0.625,0]; IP_SCORE(-0.01)[ip: (0.03), ipnet: 69.59.192.0/19(0.01), asn: 13868(-0.02), country: US(-0.08)]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.18)[0.185,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: pdx.rh.CN85.dnsmgr.net]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.82)[0.825,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2019 18:21:35 -0000 > On Mon, Jan 14, 2019 at 11:59 AM Rodney W. Grimes > wrote: > > > > > All > > > I ran into a peculiar over the weekend on two FreeBSD 10-STABLE > > > servers that has me at a loss. Both servers have the same setup lacp > > > lagg wtih vlans using the lagg as a parent dev. > > > On the vlans I have some alias along with the primary ip. When a > > > alias was added or deleted routes that sourced out of the primary ip > > > on that vlan were dropped from the routing table. > > > > > > > > > So for example. I have lagg0.vlan1044 . (both servers are similarly > > > configured as routers / firewalls ) > > > > > > [root@pineapple01 ~]# ifconfig lagg0.vlan1044 > > > lagg0.vlan1044: flags=8843 > > > metric 0 mtu 1500 > > > options=300 > > > ether 00:0f:53:20:9b:d0 > > > inet6 fe80::20f:53ff:fe20:9bd0%lagg0.vlan1044 prefixlen 64 > > > scopeid 0x80 > > > inet 10.24.213.84 netmask 0xffffffe0 broadcast 10.24.213.95 > > > inet 10.24.212.129 netmask 0xffffffff broadcast 10.24.212.129 > > > inet 10.24.213.163 netmask 0xfffffff0 broadcast 10.24.213.175 > > > inet 10.24.213.76 netmask 0xffffffe0 broadcast 10.24.213.95 > > > inet 10.24.213.94 netmask 0xffffffe0 broadcast 10.24.213.95 > > > inet 10.24.213.89 netmask 0xffffffe0 broadcast 10.24.213.95 > > > inet 10.24.213.75 netmask 0xffffffe0 broadcast 10.24.213.95 > > > nd6 options=21 > > > media: Ethernet autoselect > > > status: active > > > vlan: 1044 parent interface: lagg0 > > > > > > [root@pineapple01 ~]# netstat -nr4Wl > > > ... > > > 192.168.144.32/27 10.24.213.65 UGS 0 1500 lagg0.vlan1044 > > > 192.168.144.96/27 10.24.213.65 UGS 0 1500 lagg0.vlan1044 > > > 192.168.23.0/24 10.24.213.65 UGS 0 1500 lagg0.vlan1044 > > > 192.168.120.0/21 10.24.213.65 UGS 0 1500 lagg0.vlan1044 > > > > > > > > > So I wanted to remove the alias ended in 163 and fix its netmask back to /32 > > > > > > I ran this > > > > > > ifconfig lagg0.vlan1044 inet 10.24.213.163/24 -alias && ifconfig > > ^ delete? > > I use -alias which is an alias of -delete > > > > > > lagg0.vlan1044 inet 10.24.213.163/32 -alias This is also a delete? I am concerend that what you think the command you typed is not actually the command you typed and what you did actually type has the bad side effects. > > > and shortly there after all of the routes that went out lagg0.vlan1044 > > > were gone . I quickly undid my change and put the routes back but I am > > > not sure what caused this ? Anyone have any ideas I have done this in > > > the past with out issue and I am unsure whats changed other then the > > > box have a long up time of 463 days . > > > > I believe what happened here is that 10.24.213.163/24 when reduced > > to a network address is 10.24.213.0/24, which probably got sent to > > the route removal code, which since the route to that covers the > > gateway at 10.24.213.65 that gateway was no longer accessable > > so all routes via it got removed. > > > > ok I see what you are saying and it makes sense to me; do you know why > the routing code does not see the primary ip ( the non-alias one) is > still > live on the interface before deciding to drop the routes associated with it ? It should, but I can not see enough of your routing table to guess as to exactly what the kernel did when you removed this interface. The routes I see above all would go through the interface you showed you removed, thus they would all go away. -- Rod Grimes rgrimes@freebsd.org