From owner-freebsd-hackers@freebsd.org Sun Jan 13 22:32:49 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 3510C148B2E5 for ; Sun, 13 Jan 2019 22:32:49 +0000 (UTC) (envelope-from dan@langille.org) Received: from clavin1.langille.org (clavin1.langille.org [162.208.116.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "clavin.langille.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8308294AE4 for ; Sun, 13 Jan 2019 22:32:48 +0000 (UTC) (envelope-from dan@langille.org) Received: from (clavin1.int.langille.org (clavin1.int.unixathome.org [10.4.7.7]) (Authenticated sender: hidden) with ESMTPSA id 2ABE312ED1 for ; Sun, 13 Jan 2019 22:32:46 +0000 (UTC) From: Dan Langille Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: BSDCan 2019 CFP closes on 19 January Message-Id: <49BEE4B4-BF00-403B-9DCE-AA35DBF57958@langille.org> Date: Sun, 13 Jan 2019 17:32:45 -0500 To: freebsd-hackers@freebsd.org X-Mailer: Apple Mail (2.3445.9.1) X-Rspamd-Queue-Id: 8308294AE4 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dmarc=pass (policy=none) header.from=langille.org; spf=pass (mx1.freebsd.org: domain of dan@langille.org designates 162.208.116.86 as permitted sender) smtp.mailfrom=dan@langille.org X-Spamd-Result: default: False [-5.32 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:162.208.116.86]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_DN_NONE(0.00)[]; URI_COUNT_ODD(1.00)[9]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-3.30)[ip: (-9.30), ipnet: 162.208.116.0/22(-3.42), asn: 11403(-3.71), country: US(-0.08)]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MX_GOOD(-0.01)[cached: ALT3.ASPMX.L.GOOGLE.COM]; DMARC_POLICY_ALLOW(-0.50)[langille.org,none]; NEURAL_HAM_SHORT(-0.71)[-0.711,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; ASN(0.00)[asn:11403, ipnet:162.208.116.0/22, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Sun, 13 Jan 2019 22:32:49 -0000 Hello, A reminder that the CFP for BSDCan 2019 closes on 19 January. That's a Saturday, but in reality, we don't start closing access off until Monday, so you have the whole weekend to get your submission in. BSDCan 2019 will be held 17-18 (Fri-Sat) May, 2019 in Ottawa, at the University of Ottawa. It will be preceded by two days of tutorials on 15-16 May (Wed-Thu). NOTE the change of month in 2019 to May Also: do not miss out on the Goat BOF on Tuesday 14 May. We are now accepting proposals for talks. The talks should be designed with a very strong technical content bias. Proposals of a business development or marketing nature are not appropriate for this venue. See http://www.bsdcan.org/2019/ If you are doing something interesting with a BSD operating system, please submit a proposal. Whether you are developing a very complex system using BSD as the foundation, or helping others and have a story to tell about how BSD played a role, we want to hear about your experience. People using BSD as a platform for research are also encouraged to submit a proposal. Possible topics include: * How we manage a giant installation with respect to handling spam. * and/or sysadmin. * and/or networking. * Cool new stuff in BSD * Tell us about your project which runs on BSD * other topics (see next paragraph) =46rom the BSDCan website, the Archives section will allow you to review the wide variety of past BSDCan presentations as further examples. Both users and developers are encouraged to share their experiences. The schedule is: 1 Dec 2018 Proposal acceptance begins 19 Jan 2019 Proposal acceptance ends 19 Feb 2019 Confirmation of accepted proposals See also http://www.bsdcan.org/2019/papers.php = Instructions for submitting a proposal to BSDCan 2019 are available from: http://www.bsdcan.org/2019/submissions.php = --=20 Dan Langille - BSDCan / PGCon dan@langille.org From owner-freebsd-hackers@freebsd.org Mon Jan 14 16:30:12 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 CC8E314A4FB5 for ; Mon, 14 Jan 2019 16:30:11 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B59CC6A0E5 for ; Mon, 14 Jan 2019 16:30:10 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-ed1-x531.google.com with SMTP id f23so135084edb.3 for ; Mon, 14 Jan 2019 08:30:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=KSMZ9nb9h7AYzgceFhkQ9SZaUp0sftAPoWwETecQzYs=; b=ZEouzGYCSbNgeDBm9Ps3QolV7CQfZOnAsDbq6CXBIHm0EcUgfptUAlf+UI47wvCYc4 5EoV8xH3mvRjR3nZFIPFuoiTfmk1p4j4ABZSYQOjNvPfHzdmjUIbn2kktphPVcsGXI9I 8dSSFK5zkkCQBjb9udxguxxJ1Pm2x4QMBme3pJEqWiw86BH3/xlOpXB9JjmARM6v1GRK ZJ/7j5qv3vWxdwQ7TzLU5rWk2dzdNWxq5XBnNIPBsl/Sc/SDPTkOnr3E1XagCrizSjzh phWOUo0nJ9OJQH1Ub6TTfVBVPcqpx/zTDxkmzAnkqIQl7dSjxFaRRq91hpuyPYVIV7hc vqpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KSMZ9nb9h7AYzgceFhkQ9SZaUp0sftAPoWwETecQzYs=; b=kb3xqE3CUcbxCdHWi64/2PObDnD48vWkBojKiN0MAuWkqpX0xsbrIvU1TFrvG3G6sr zoeMimzwLRvIpGfaRoxhMTGXbVOZg2Hx6vXQ+yP24OcmZR9NkkpGUlpN+zhyDySyBqZi FdJw5whC11CtmRITnORUr9V5aEx69E42H1pDARecgm4eiYQ4Uqwln4zKyJFMLTVlMOXA 4wvSFGCnlNyqupWrQ16vORYdcUp5UswioFz7CM+8lj95yP5U9ZGjo6zdHYKoNrgVtmb2 Vs6MQ3oP51M5FP7vsMumrFj9h3c9g9C/vr7q2afWC6otnK7wVZuHnmAfCh+XKTuqZQjn NBIQ== X-Gm-Message-State: AJcUukcMXcvt291DWu29EzhA98u+nLWB5HQepceo566sSneDw1cxjAgN z6uhSqVOzv47FV6JBM4vQpDdXYhDoi+UbneFEwdWB8gQP94= X-Google-Smtp-Source: ALg8bN6mMFuAXVDtv7cc0DL46cdXuaD7jU+iWJzR3deOyJ54kIqr1daXED8jYWqhpk136lhd8jjEbmvquo1B8RiKxoU= X-Received: by 2002:a17:906:f14e:: with SMTP id gw14-v6mr20789340ejb.231.1547483409301; Mon, 14 Jan 2019 08:30:09 -0800 (PST) MIME-Version: 1.0 From: Mark Saad Date: Mon, 14 Jan 2019 11:29:58 -0500 Message-ID: Subject: Removing an alias can remove routes ? To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: B59CC6A0E5 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=longcount-org.20150623.gappssmtp.com header.s=20150623 header.b=ZEouzGYC X-Spamd-Result: default: False [-4.36 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[longcount-org.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[longcount.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[longcount-org.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[alt1.aspmx.l.google.com,aspmx.l.google.com,aspmx5.googlemail.com,aspmx4.googlemail.com,aspmx3.googlemail.com,alt2.aspmx.l.google.com,aspmx2.googlemail.com]; RCVD_IN_DNSWL_NONE(0.00)[1.3.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.47)[-0.468,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-2.58)[ip: (-9.05), ipnet: 2a00:1450::/32(-2.02), asn: 15169(-1.77), country: US(-0.08)] 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 16:30:12 -0000 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 lagg0.vlan1044 inet 10.24.213.163/32 -alias 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 . -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@freebsd.org Mon Jan 14 16:58:52 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 D66F714A5BE7 for ; Mon, 14 Jan 2019 16:58:52 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E43ED6B3F8 for ; Mon, 14 Jan 2019 16:58:41 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x0EGwXuC038117 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Jan 2019 17:58:33 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: nonesuch@longcount.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x0EGwWYf070669 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 14 Jan 2019 23:58:32 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Removing an alias can remove routes ? To: Mark Saad , FreeBSD Hackers References: From: Eugene Grosbein Message-ID: <1a2f60f2-6f78-00d6-9287-eaf3408205fa@grosbein.net> Date: Mon, 14 Jan 2019 23:58:27 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: E43ED6B3F8 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.10 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; MX_INVALID(0.50)[greylisted]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.96)[-0.959,0]; IP_SCORE(-1.54)[ip: (-2.89), ipnet: 2a01:4f8::/29(-2.47), asn: 24940(-2.35), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(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 16:58:53 -0000 14.01.2019 23:29, Mark Saad wrote: > So I wanted to remove the alias ended in 163 and fix its netmask back to /32 And this was right desision. > I ran this > > ifconfig lagg0.vlan1044 inet 10.24.213.163/24 -alias && ifconfig > lagg0.vlan1044 inet 10.24.213.163/32 -alias > > 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 . Wrong original netmask of an alias was a reason of this. You should use /32 only for aliases. Re-add all aliases with /32 then re-add routes and you will be fine. From owner-freebsd-hackers@freebsd.org Mon Jan 14 16:59:49 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 4912414A5C78 for ; Mon, 14 Jan 2019 16:59:49 +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 7C88D6B4CF for ; Mon, 14 Jan 2019 16:59:48 +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 x0EGxkRm035976; Mon, 14 Jan 2019 08:59:46 -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 x0EGxkDl035975; Mon, 14 Jan 2019 08:59:46 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201901141659.x0EGxkDl035975@pdx.rh.CN85.dnsmgr.net> Subject: Re: Removing an alias can remove routes ? In-Reply-To: To: Mark Saad Date: Mon, 14 Jan 2019 08:59:46 -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: 7C88D6B4CF X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.71 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.85)[0.853,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.16)[0.164,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.819,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 16:59:49 -0000 > 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? > lagg0.vlan1044 inet 10.24.213.163/32 -alias > > 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. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Mon Jan 14 17:15:12 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 DB4A714A6BC3 for ; Mon, 14 Jan 2019 17:15:11 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E28AC6C5E0 for ; Mon, 14 Jan 2019 17:15:10 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-ed1-x52b.google.com with SMTP id x30so265185edx.2 for ; Mon, 14 Jan 2019 09:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cb8UmkqzV4CY5fFJUVpgl6ZgnHX9JGK6g3TnGqn3aSo=; b=nUYKXC46JFJ0fqCz3WbqaIgKTPfQfCv63KI6T2f6nxLrH2ohYHnJ996sTmgFIO8BDZ hMI46HMKuONQe65zT9P0cxmyiMgNueEWiSzZrfZaf+91Egxn+ucumZZ83vASzTGZbJOg hXVcccgXIQzNHGohUb5LP78z1IhdDNLns40dR+q0l0SkJRJsJI+tl8cfKjG68TgaJGjH /dxsVubkgyya9EYhObrGiQX9LGICgLrySqFYMMz+8WzI5ow+2CQKBCWPcGMAwdClmSp6 JO0Qs0vbZkSm8Ogb4nbbt6T13t60KmAqjSlDuNohMnwUrBQh8zGsZ2l47YabywGRaHR6 RWCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Cb8UmkqzV4CY5fFJUVpgl6ZgnHX9JGK6g3TnGqn3aSo=; b=IbXMQ5Uydjjk2DoUOXS/i1FnDhRlzDslnzX5h1tyfCitHnwUhlTt9Ory78QJy7gBfW zhJoN8SAeupCsQrGosGYMMKBIRrFSNo5B1iLQZ4ELXnVowT4JmVjaNkdLkJ9wI9SYZzq pKFLHgaOViAXzhAYBJvLb62N201J2PdbXjOuM70jV+br8Vw9X5PfSOZPlpuX9CLoeZEt aFsob4JdXvPGNIJeri8qBZvdJ7xiWEY3lOLqP45zb6IH/5+0BQwlUPc9pZcyqu+gJkDr 5ml3lhrvp74bA6jsELxD8pBpuxHlWHbv4M4FJP74ttpc21kG4iFqpwhSZQKJfZFNmmj6 5OkA== X-Gm-Message-State: AJcUuke18bSkB8z/YqblluzXGseZ6JRVgynqG+Fmb7VT3LsNFQnYpUgj i2JWYGVc/Q9ypd3oJ6v4aGuMjjoIqz5b1uMsyF1nEU+/ X-Google-Smtp-Source: ALg8bN5TtSgDSzRTt/7hAJRU3TW3RN9CcqObDVWGe15RmQHMws71gDeREln9nEd3hI1jQdfkILGUWUkLMNFlqyNHamA= X-Received: by 2002:a50:fb03:: with SMTP id d3mr114695edq.183.1547486109040; Mon, 14 Jan 2019 09:15:09 -0800 (PST) MIME-Version: 1.0 References: <201901141659.x0EGxkDl035975@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201901141659.x0EGxkDl035975@pdx.rh.CN85.dnsmgr.net> From: Mark Saad Date: Mon, 14 Jan 2019 12:14:57 -0500 Message-ID: Subject: Re: Removing an alias can remove routes ? To: "Rodney W. Grimes" Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: E28AC6C5E0 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=longcount-org.20150623.gappssmtp.com header.s=20150623 header.b=nUYKXC46 X-Spamd-Result: default: False [-4.57 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[longcount-org.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; IP_SCORE(-2.55)[ip: (-8.87), ipnet: 2a00:1450::/32(-2.02), asn: 15169(-1.76), country: US(-0.08)]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[longcount.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[longcount-org.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[b.2.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[cached: alt1.aspmx.l.google.com]; R_SPF_NA(0.00)[]; NEURAL_HAM_SHORT(-0.72)[-0.716,0]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; 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 17:15:12 -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 > > > > 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 ? > -- > Rod Grimes rgrimes@freebsd.org -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@freebsd.org Mon Jan 14 18:16:03 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 2392A14828EF for ; Mon, 14 Jan 2019 18:16:03 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 359936EDC4 for ; Mon, 14 Jan 2019 18:16:02 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-ed1-x536.google.com with SMTP id x30so423171edx.2 for ; Mon, 14 Jan 2019 10:16:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=APlEUn+OIC3I94gJVymx+TL6VByMYUYsuVLLnRObcCM=; b=Gm6I+snOTkFSWT7y+EZSNaL4VQjZ2Vj5VUOHf4R/6zVYvtyygt9iY+unc+ez7NALzR LgvNMv7bXBtURXjgrPUDYagQfmfNkCUDDXb+AciBoZpC4yd01dE9dGAQwAxCJwRVijID 22PVw974GA4j2wXymK7jgxvQBxTTVBT4AgjlDTHUIji09HGcf7YxIiyG16vJf0iJmN0a ie3a1OO17Ge+xbkt5MQ3fyY+i7x7iigYrKsGrRvqsoJkcpWCGObrO9b0deY6FUrduV1b THeSIujHFqfevUDyTUAug/gi4jiMPTM/L61L8NK9yolkv0LLQCcO153dsi53I2O6RREw FFzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=APlEUn+OIC3I94gJVymx+TL6VByMYUYsuVLLnRObcCM=; b=AVD04dBJ8OrYZnQV/iFSuE/yQ3gjk391VVmugA3/qQkOLPdQMpWczbmhqIZOCSebSL 6GFIG7AIwumAj4DjXZfBGN4vnZyMTOItO0e8B+yC6qYN9BbvPwGbH0ehBg2v9mAoGjLO 9oAq4ijk0M/NhUyJIMorl8EZCAlYWpuspvYhqP3BwlSAXm+HhT9b7XrDuQJ+A8Qu66so y7KivRRcL2l0v8XGzOf9ADHX48yl3a7tH+qZJ6YZc9JW+64pHn1r2uk+s2Kre/se3Umx 3O6HQ2FsLia8IftHtdkceyb1x7dB/II9y9P/ld1kA2mIWA6vMS/6J4zhg2WZqTsaU/RP fMUA== X-Gm-Message-State: AJcUukdpmV3dK6qwEmTAkQFctw9PWA4RKSFpMok8mHLowx0a9wZb1bq3 KY964OaqZIVuS63j06xYCmP0jMcIhwWndj7zWjG3ym3P X-Google-Smtp-Source: ALg8bN7rY+xlw819LuebEu9ePScEUVchNqKCr57WbOqU+pzq7PBa89fEtp+xciibhT/+qchxoXsa9YzAFVHMioMxTAI= X-Received: by 2002:a17:906:6690:: with SMTP id z16-v6mr308483ejo.142.1547489760929; Mon, 14 Jan 2019 10:16:00 -0800 (PST) MIME-Version: 1.0 References: <1a2f60f2-6f78-00d6-9287-eaf3408205fa@grosbein.net> In-Reply-To: <1a2f60f2-6f78-00d6-9287-eaf3408205fa@grosbein.net> From: Mark Saad Date: Mon, 14 Jan 2019 13:15:48 -0500 Message-ID: Subject: Re: Removing an alias can remove routes ? To: Eugene Grosbein Cc: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 359936EDC4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=longcount-org.20150623.gappssmtp.com header.s=20150623 header.b=Gm6I+snO X-Spamd-Result: default: False [-4.79 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[longcount-org.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; IP_SCORE(-2.58)[ip: (-9.06), ipnet: 2a00:1450::/32(-2.02), asn: 15169(-1.77), country: US(-0.08)]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[longcount.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt1.aspmx.l.google.com]; DKIM_TRACE(0.00)[longcount-org.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[6.3.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; NEURAL_HAM_SHORT(-0.90)[-0.901,0]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; 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:16:03 -0000 On Mon, Jan 14, 2019 at 11:58 AM Eugene Grosbein wrote: > > 14.01.2019 23:29, Mark Saad wrote: > > > So I wanted to remove the alias ended in 163 and fix its netmask back to /32 > > And this was right desision. > > > I ran this > > > > ifconfig lagg0.vlan1044 inet 10.24.213.163/24 -alias && ifconfig > > lagg0.vlan1044 inet 10.24.213.163/32 -alias > > > > 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 . > > Wrong original netmask of an alias was a reason of this. > You should use /32 only for aliases. Re-add all aliases with /32 > then re-add routes and you will be fine. > That's what I was originally attempting to do . What I am now wondering is; Should I follow the convention of the all alias ip in the subnet of the primary (non-alias) address should be /32 . Then the first occurrence of a new subnet as an alias should have its real mask and then all subsequent aliases of the new subnet be /32 or should all aliases just be /32 ? I am going to test this on 10-STABLE in a few mins to see what I get. -- mark saad | nonesuch@longcount.org 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 From owner-freebsd-hackers@freebsd.org Mon Jan 14 19:04:36 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 92BA9148424F for ; Mon, 14 Jan 2019 19:04:36 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [IPv6:2a01:4f8:d12:604::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A895C711B7 for ; Mon, 14 Jan 2019 19:04:25 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13:0:0:0:5]) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id x0EJ4Hxo039366 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Jan 2019 20:04:18 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: nonesuch@longcount.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id x0EJ4Gw4072033 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 Jan 2019 02:04:17 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: Removing an alias can remove routes ? To: Mark Saad References: <1a2f60f2-6f78-00d6-9287-eaf3408205fa@grosbein.net> Cc: FreeBSD Hackers From: Eugene Grosbein Message-ID: <8c73e93c-9da3-37a6-9e3a-27d2723c1ff6@grosbein.net> Date: Tue, 15 Jan 2019 02:04:11 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_00,LOCAL_FROM,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 SPF_PASS SPF: sender matches SPF record * 2.6 LOCAL_FROM From my domains X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on hz.grosbein.net X-Rspamd-Queue-Id: A895C711B7 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; spf=permerror (mx1.freebsd.org: domain of eugen@grosbein.net uses mechanism not recognized by this client) smtp.mailfrom=eugen@grosbein.net X-Spamd-Result: default: False [-3.10 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; MX_INVALID(0.50)[greylisted]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[grosbein.net]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; R_SPF_PERMFAIL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.97)[-0.968,0]; IP_SCORE(-1.54)[ip: (-2.85), ipnet: 2a01:4f8::/29(-2.48), asn: 24940(-2.35), country: DE(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(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 19:04:36 -0000 15.01.2019 1:15, Mark Saad wrote: > That's what I was originally attempting to do . What I am now > wondering is; Should I follow the convention of the all alias ip in > the subnet > of the primary (non-alias) address should be /32 . Then the first > occurrence of a new subnet as an alias should have its real mask > and then all subsequent aliases of the new subnet be /32 or should all > aliases just be /32 ? Right. From owner-freebsd-hackers@freebsd.org Mon Jan 14 21:49:07 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 BFB0A1488EAC for ; Mon, 14 Jan 2019 21:49:07 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A67FD77A0F for ; Mon, 14 Jan 2019 21:49:06 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-ed1-x541.google.com with SMTP id b3so939717ede.1 for ; Mon, 14 Jan 2019 13:49:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=YJzlCGhzydF/i73GuaJG4HRfiFcUvGjSZyn9w+0nBVI=; b=OW99t0N8QqIr5qYnIemgzNCEAXCoNlppJFl8N9V8lp4FMnglelaix5sNUf+gth1NH4 UocL6adJLTp2jJ3/e/7nv1OJLgSnERpLq/j6ZcYdC2Pf7Gwz9UB92rAE96FSymDdUBBb lHmV+hRybhXHhXs74TxtGocJgBpuSW13ghgdO4ZbM0fJX7uM6DhtU473+32g8qtT798R 7IiPQAx4Ihv9vyinSWRHDeHrcg9uBH7G8qu+is2Ncxyqssm3fHqafZCnAEJ0f6Dp2ult 2HNMHku0sJ8k3uv2YwuKHXkzWF32qWynKIst5k1Two62PgATnjihkQzrrgleODvtA38d e0aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=YJzlCGhzydF/i73GuaJG4HRfiFcUvGjSZyn9w+0nBVI=; b=tHhk8a0iZLcGGcUYz9cJ+JOU18aY4z1lJ5aOd0Yf/V766nkevO56e2j0CXm08fX3Ib N9tTYRP3NSIjNlqBb692lBKSI4hR/HT3akixDl82Z9snc5R7Hxvm0F4I3eBAnPCzDaPQ p73TbLKb/9qUbesT7Ljwu82hHgbZa2YSEODyOgum/YYLf0+I7Na3rML5b0R2DLXW0Khv vYxTiSbLlpGKg1Qgi0Kqxb0YPYDbtjrmy1N65V1jhCOkJrkRPYr4rD9IdYgLyF0dYFrO IGRLtYyuvm7G0KceFdHfUxJiwNI41VqCl01FGig6A7U8HYZVNQsk/DnPQHJtTe12KWpP mc+g== X-Gm-Message-State: AJcUukcNf78VU/TzycKXP5cSS+tsucWM8drUVHyYfd5Wp1o3XOuKiX21 GfipHDpwzj/X0ai+MY26zMpGLU3dnhzv4mWt8KEKMZeXiCg= X-Google-Smtp-Source: ALg8bN4UWuoyz5PkElaVIwo9BfYgstquZhMWOX9ziNIoCXLLQzC0hNEhhRX6TXE3KhEhik6HzgETQUPoCtnAXAstGCU= X-Received: by 2002:a50:a622:: with SMTP id d31mr948598edc.228.1547502545097; Mon, 14 Jan 2019 13:49:05 -0800 (PST) MIME-Version: 1.0 References: <201901141821.x0EILVem036356@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201901141821.x0EILVem036356@pdx.rh.CN85.dnsmgr.net> From: Mark Saad Date: Mon, 14 Jan 2019 16:48:53 -0500 Message-ID: Subject: Re: Removing an alias can remove routes ? To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: A67FD77A0F X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=longcount-org.20150623.gappssmtp.com header.s=20150623 header.b=OW99t0N8 X-Spamd-Result: default: False [-2.46 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.986,0]; R_DKIM_ALLOW(-0.20)[longcount-org.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.996,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[longcount.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt1.aspmx.l.google.com]; DKIM_TRACE(0.00)[longcount-org.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[1.4.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.41)[-0.409,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-0.76)[ip: (0.08), ipnet: 2a00:1450::/32(-2.02), asn: 15169(-1.77), country: US(-0.08)] 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 21:49:08 -0000 On Mon, Jan 14, 2019 at 1:21 PM Rodney W. Grimes wrote: > > > 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 Ok some further testing shows what appears to be unintended results. On my test box I do the following ifconfig vlan98 create ifconfig vlan98 vlan 98 vlandev lagg0 ifconfig vlan98 inet 10.1.68.12/26 ifconfig vlan98 inet 10.1.68.13/26 alias ifconfig vlan98 inet 10.1.68.14/28 alias ifconfig vlan98 inet 10.1.68.15/32 alias route add 10.24.213.0/24 10.1.68.11 route add 10.24.214.0/24 10.1.68.11 route add 10.24.215.0/24 10.1.68.11 root@potato2:~ # netstat -nr4Wl Routing tables Internet: Destination Gateway Flags Use Mtu Netif Expire default 10.21.160.1 UGS 1216 1500 igb0 10.1.68.0/26 link#12 U 0 1500 vlan98 10.1.68.12 link#12 UHS 0 16384 lo0 10.1.68.13 link#12 UHS 0 16384 lo0 10.1.68.13/32 link#12 U 0 1500 vlan98 10.1.68.14 link#12 UHS 0 16384 lo0 10.1.68.14/32 link#12 U 0 1500 vlan98 10.1.68.15 link#12 UHS 0 16384 lo0 10.1.68.15/32 link#12 U 0 1500 vlan98 10.21.160.0/21 link#3 U 26985 1500 igb0 10.21.160.85 link#3 UHS 0 16384 lo0 10.24.213.0/24 10.1.68.11 UGS 0 1500 vlan98 10.24.214.0/24 10.1.68.11 UGS 0 1500 vlan98 10.24.215.0/24 10.1.68.11 UGS 0 1500 vlan98 127.0.0.1 link#5 UH 840 16384 lo0 Then I realize that my masks are wrong and I change the aliases back to "/32's" root@potato2:~ # ifconfig vlan98 vlan98: flags=8843 metric 0 mtu 1500 ether 00:0f:53:20:9d:00 inet 10.1.68.12 netmask 0xffffffc0 broadcast 10.1.68.63 inet6 fe80::20f:53ff:fe20:9d00%vlan98 prefixlen 64 scopeid 0xc inet 10.1.68.13 netmask 0xffffffff broadcast 10.1.68.13 inet 10.1.68.14 netmask 0xffffffff broadcast 10.1.68.14 inet 10.1.68.15 netmask 0xffffffff broadcast 10.1.68.15 nd6 options=21 media: Ethernet autoselect status: active vlan: 98 parent interface: lagg0 root@potato2:~ # netstat -nr4Wl Routing tables Internet: Destination Gateway Flags Use Mtu Netif Expire default 10.21.160.1 UGS 1217 1500 igb0 10.1.68.0/26 link#12 U 0 1500 vlan98 10.1.68.12 link#12 UHS 0 16384 lo0 10.1.68.13 link#12 UHS 0 16384 lo0 10.1.68.13/32 link#12 U 0 1500 vlan98 10.1.68.14 link#12 UHS 0 16384 lo0 10.1.68.14/32 link#12 U 0 1500 vlan98 10.1.68.15 link#12 UHS 0 16384 lo0 10.1.68.15/32 link#12 U 0 1500 vlan98 10.21.160.0/21 link#3 U 27166 1500 igb0 10.21.160.85 link#3 UHS 0 16384 lo0 10.24.213.0/24 10.1.68.11 UGS 0 1500 vlan98 10.24.214.0/24 10.1.68.11 UGS 0 1500 vlan98 10.24.215.0/24 10.1.68.11 UGS 0 1500 vlan98 127.0.0.1 link#5 UH 840 16384 lo0 root@potato2:~ # So far no problems. Then I see ohh my primary ip needs to be a "/24" root@potato2~ # ifconfig vlan98 inet 10.1.68.12/24 root@potato2:~ # netstat -nr4Wl Routing tables Internet: Destination Gateway Flags Use Mtu Netif Expire default 10.21.160.1 UGS 1218 1500 igb0 10.1.68.0/24 link#12 U 0 1500 vlan98 10.1.68.12 link#12 UHS 0 16384 lo0 10.1.68.13 link#12 UHS 0 16384 lo0 10.1.68.13/32 link#12 U 0 1500 vlan98 10.1.68.14 link#12 UHS 0 16384 lo0 10.1.68.14/32 link#12 U 0 1500 vlan98 10.1.68.15 link#12 UHS 0 16384 lo0 10.1.68.15/32 link#12 U 0 1500 vlan98 10.21.160.0/21 link#3 U 27230 1500 igb0 10.21.160.85 link#3 UHS 0 16384 lo0 10.24.213.0/24 10.1.68.11 UGS 0 1500 vlan98 10.24.214.0/24 10.1.68.11 UGS 0 1500 vlan98 10.24.215.0/24 10.1.68.11 UGS 0 1500 vlan98 127.0.0.1 link#5 UH 840 16384 lo0 root@potato2:~ # So far so good; then I accidentally hit up arrow and enter / or re-run the promotion to /24 again two times IE: root@potato2:~ # ifconfig vlan98 inet 10.1.68.12/24 root@potato2:~ # ifconfig vlan98 inet 10.1.68.12/24 root@potato2:~ # netstat -nr4Wl Routing tables Internet: Destination Gateway Flags Use Mtu Netif Expire default 10.21.160.1 UGS 1223 1500 igb0 10.1.68.0/24 link#12 U 0 1500 vlan98 10.1.68.12 link#12 UHS 0 16384 lo0 10.1.68.15 link#12 UHS 0 16384 lo0 10.1.68.15/32 link#12 U 0 1500 vlan98 10.21.160.0/21 link#3 U 27847 1500 igb0 10.21.160.85 link#3 UHS 0 16384 lo0 127.0.0.1 link#5 UH 868 16384 lo0 What just happened to my routes and check out what just happened to my aliases root@potato2:~ # ifconfig vlan98 vlan98: flags=8843 metric 0 mtu 1500 ether 00:0f:53:20:9d:00 inet6 fe80::20f:53ff:fe20:9d00%vlan98 prefixlen 64 scopeid 0xc inet 10.1.68.15 netmask 0xffffffff broadcast 10.1.68.15 inet 10.1.68.12 netmask 0xffffff00 broadcast 10.1.68.255 nd6 options=21 media: Ethernet autoselect status: active vlan: 98 parent interface: lagg0 Anyone have an idea what happened here ? -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@freebsd.org Mon Jan 14 21:53:47 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 18FEC148919B for ; Mon, 14 Jan 2019 21:53:47 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F35EB77E07 for ; Mon, 14 Jan 2019 21:53:45 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: by mail-ed1-x542.google.com with SMTP id f9so892572eds.10 for ; Mon, 14 Jan 2019 13:53:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=longcount-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=8/eEi3ZtVPjhVJnS4mECDRCsTPJqkkGXySGWRGa69Qw=; b=Smt+YZ+i/vE7h9xgdedWpsI6kMirrSoOmPJbwd5ZK/wLIGGV34JkJf13rCVBZ+eg69 DKP5ig+nNRBH927wDR9r90lTEJRqUw9sSHowyp4jguQC0ieUiAIwV4B6UJBZbvp38Qhd qdMOGFaVd7dajDLqIfxlt6lG4PcaDToueztOqvdZtJqxw81e+5jlllBziS05aeCvfSXc 2F+crG5KxyRFByAbiQpxxKzsc5KZN0WVG0TSGXZ2anjw0Dxo/NbUFiR/6e0dFCaGq/ym Bd2Re4pe1Ca3dQMMx6T14IH/ft08bQ6huSPFC6VLtt5RxfdnxQ4/CEKIssj3ZR10iilR VxzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=8/eEi3ZtVPjhVJnS4mECDRCsTPJqkkGXySGWRGa69Qw=; b=qz8+ohKvXQianqEAUNposvyJSAqA2uxIhXQSNwushxeXPPLIKScrFFflRfZYS661NU Dv4HDyYM+UCzd6PS5Pp8VWVYSPCy0WZ6nPlK9LHskPJxj+0d4mZwJAK2jXD4Db6weoqQ +C1HAlly2bA4Z1e70oT9fTI14yQECewiDMlaYOl/4jRTMd8NYCxDVsMKZ6u+nuuIS653 bjglahbmdjtuJwNkoyuu6pcCfUNYuq6+wlD39hcK0/q3tUi9d8rRk/i6SrwHwJS4YzDB wQ0Maj8pd+MzrwJvTIio/FymCxdEm4K1bzAwZPt7TYdgtJLCLC/fTjHtS6NWfTd30LZQ DRgg== X-Gm-Message-State: AJcUukeAu4mT0aoQh4cRrJsyMh6kHghfVN7o53L1ceB59WyrAtEOGDlE +6fh2gjrLmZNzZtpFMt0+LkL40S44YnSQoBo6+Y0iEgMcGM= X-Google-Smtp-Source: ALg8bN4CF4U56lJw81hBCBu0psMeAQzdhfs35wxC4CyF8hnB3IvHFmM9OSDgBzoDH2aUZq/Z3xDpZIgFDkabbWtyEwo= X-Received: by 2002:a17:906:b799:: with SMTP id dt25-v6mr796680ejb.217.1547502824618; Mon, 14 Jan 2019 13:53:44 -0800 (PST) MIME-Version: 1.0 References: <201901141821.x0EILVem036356@pdx.rh.CN85.dnsmgr.net> In-Reply-To: From: Mark Saad Date: Mon, 14 Jan 2019 16:53:31 -0500 Message-ID: Subject: Re: Removing an alias can remove routes ? To: FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: F35EB77E07 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=longcount-org.20150623.gappssmtp.com header.s=20150623 header.b=Smt+YZ+i X-Spamd-Result: default: False [-2.40 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.984,0]; R_DKIM_ALLOW(-0.20)[longcount-org.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.995,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; DMARC_NA(0.00)[longcount.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[longcount-org.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: alt1.aspmx.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[2.4.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.37)[-0.372,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; IP_SCORE(-0.73)[ip: (0.20), ipnet: 2a00:1450::/32(-2.02), asn: 15169(-1.77), country: US(-0.08)] 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 21:53:47 -0000 On Mon, Jan 14, 2019 at 4:48 PM Mark Saad wrote: > > On Mon, Jan 14, 2019 at 1:21 PM Rodney W. Grimes > wrote: > > > > > 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 > > > Ok some further testing shows what appears to be unintended results. > > On my test box I do the following > > ifconfig vlan98 create > ifconfig vlan98 vlan 98 vlandev lagg0 > ifconfig vlan98 inet 10.1.68.12/26 > ifconfig vlan98 inet 10.1.68.13/26 alias > ifconfig vlan98 inet 10.1.68.14/28 alias > ifconfig vlan98 inet 10.1.68.15/32 alias > > route add 10.24.213.0/24 10.1.68.11 > route add 10.24.214.0/24 10.1.68.11 > route add 10.24.215.0/24 10.1.68.11 > > root@potato2:~ # netstat -nr4Wl > Routing tables > > Internet: > Destination Gateway Flags Use Mtu Netif Expire > default 10.21.160.1 UGS 1216 1500 igb0 > 10.1.68.0/26 link#12 U 0 1500 vlan98 > 10.1.68.12 link#12 UHS 0 16384 lo0 > 10.1.68.13 link#12 UHS 0 16384 lo0 > 10.1.68.13/32 link#12 U 0 1500 vlan98 > 10.1.68.14 link#12 UHS 0 16384 lo0 > 10.1.68.14/32 link#12 U 0 1500 vlan98 > 10.1.68.15 link#12 UHS 0 16384 lo0 > 10.1.68.15/32 link#12 U 0 1500 vlan98 > 10.21.160.0/21 link#3 U 26985 1500 igb0 > 10.21.160.85 link#3 UHS 0 16384 lo0 > 10.24.213.0/24 10.1.68.11 UGS 0 1500 vlan98 > 10.24.214.0/24 10.1.68.11 UGS 0 1500 vlan98 > 10.24.215.0/24 10.1.68.11 UGS 0 1500 vlan98 > 127.0.0.1 link#5 UH 840 16384 lo0 > > Then I realize that my masks are wrong and I change the aliases back to "/32's" > > root@potato2:~ # ifconfig vlan98 > vlan98: flags=8843 metric 0 mtu 1500 > ether 00:0f:53:20:9d:00 > inet 10.1.68.12 netmask 0xffffffc0 broadcast 10.1.68.63 > inet6 fe80::20f:53ff:fe20:9d00%vlan98 prefixlen 64 scopeid 0xc > inet 10.1.68.13 netmask 0xffffffff broadcast 10.1.68.13 > inet 10.1.68.14 netmask 0xffffffff broadcast 10.1.68.14 > inet 10.1.68.15 netmask 0xffffffff broadcast 10.1.68.15 > nd6 options=21 > media: Ethernet autoselect > status: active > vlan: 98 parent interface: lagg0 > root@potato2:~ # netstat -nr4Wl > Routing tables > > Internet: > Destination Gateway Flags Use Mtu Netif Expire > default 10.21.160.1 UGS 1217 1500 igb0 > 10.1.68.0/26 link#12 U 0 1500 vlan98 > 10.1.68.12 link#12 UHS 0 16384 lo0 > 10.1.68.13 link#12 UHS 0 16384 lo0 > 10.1.68.13/32 link#12 U 0 1500 vlan98 > 10.1.68.14 link#12 UHS 0 16384 lo0 > 10.1.68.14/32 link#12 U 0 1500 vlan98 > 10.1.68.15 link#12 UHS 0 16384 lo0 > 10.1.68.15/32 link#12 U 0 1500 vlan98 > 10.21.160.0/21 link#3 U 27166 1500 igb0 > 10.21.160.85 link#3 UHS 0 16384 lo0 > 10.24.213.0/24 10.1.68.11 UGS 0 1500 vlan98 > 10.24.214.0/24 10.1.68.11 UGS 0 1500 vlan98 > 10.24.215.0/24 10.1.68.11 UGS 0 1500 vlan98 > 127.0.0.1 link#5 UH 840 16384 lo0 > root@potato2:~ # > > So far no problems. > > Then I see ohh my primary ip needs to be a "/24" > > > root@potato2~ # ifconfig vlan98 inet 10.1.68.12/24 > root@potato2:~ # netstat -nr4Wl > Routing tables > > Internet: > Destination Gateway Flags Use Mtu Netif Expire > default 10.21.160.1 UGS 1218 1500 igb0 > 10.1.68.0/24 link#12 U 0 1500 vlan98 > 10.1.68.12 link#12 UHS 0 16384 lo0 > 10.1.68.13 link#12 UHS 0 16384 lo0 > 10.1.68.13/32 link#12 U 0 1500 vlan98 > 10.1.68.14 link#12 UHS 0 16384 lo0 > 10.1.68.14/32 link#12 U 0 1500 vlan98 > 10.1.68.15 link#12 UHS 0 16384 lo0 > 10.1.68.15/32 link#12 U 0 1500 vlan98 > 10.21.160.0/21 link#3 U 27230 1500 igb0 > 10.21.160.85 link#3 UHS 0 16384 lo0 > 10.24.213.0/24 10.1.68.11 UGS 0 1500 vlan98 > 10.24.214.0/24 10.1.68.11 UGS 0 1500 vlan98 > 10.24.215.0/24 10.1.68.11 UGS 0 1500 vlan98 > 127.0.0.1 link#5 UH 840 16384 lo0 > root@potato2:~ # > > > So far so good; then I accidentally hit up arrow and enter / or re-run > the promotion to /24 again two times > > IE: > root@potato2:~ # ifconfig vlan98 inet 10.1.68.12/24 > root@potato2:~ # ifconfig vlan98 inet 10.1.68.12/24 > > root@potato2:~ # netstat -nr4Wl > Routing tables > > Internet: > Destination Gateway Flags Use Mtu Netif Expire > default 10.21.160.1 UGS 1223 1500 igb0 > 10.1.68.0/24 link#12 U 0 1500 vlan98 > 10.1.68.12 link#12 UHS 0 16384 lo0 > 10.1.68.15 link#12 UHS 0 16384 lo0 > 10.1.68.15/32 link#12 U 0 1500 vlan98 > 10.21.160.0/21 link#3 U 27847 1500 igb0 > 10.21.160.85 link#3 UHS 0 16384 lo0 > 127.0.0.1 link#5 UH 868 16384 lo0 > > > > What just happened to my routes and check out what just happened to my aliases > > root@potato2:~ # ifconfig vlan98 > vlan98: flags=8843 metric 0 mtu 1500 > ether 00:0f:53:20:9d:00 > inet6 fe80::20f:53ff:fe20:9d00%vlan98 prefixlen 64 scopeid 0xc > inet 10.1.68.15 netmask 0xffffffff broadcast 10.1.68.15 > inet 10.1.68.12 netmask 0xffffff00 broadcast 10.1.68.255 > nd6 options=21 > media: Ethernet autoselect > status: active > vlan: 98 parent interface: lagg0 > > > > Anyone have an idea what happened here ? > > -- > mark saad | nonesuch@longcount.org To be clear this is on 10-STABLE from 2017 however on 12-STABLE from Dec 2018 this is still acting odd but in a slightly diferent way. When I change the aliases from /28 and /26 back to /32 when I run root@ostrich:~ # ifconfig vlan98 inet 10.1.68.13/32 alias no issues root@ostrich:~ # ifconfig vlan98 inet 10.1.68.14/32 alias poof my routes are removed. Again anyone have any idea whats going on here ? -- mark saad | nonesuch@longcount.org