Re: allow bgpd to reject AS_SET segemnts (enforce RFC6472)
On Thu, Jan 14, 2021 at 04:28:42PM +0100, Claudio Jeker wrote:
> This diff adds 'reject as-set yes' as an option to filter out AS paths
> with AS_SET segement elements. In bgpctl they show up with {} elements,
> e.g. 174 6762 24835 { 36893 }.
>
> This diff uses the soft-error path from RFC7606 and because of this
> prefixes that have such an AS_SET segment will be removed via
> treat-as-withdraw. These prefixes can be seen in `bgpctl show rib in error`.
>
> By default this is turned off.
This version includes the printconf.c bits to show the setting in bgpd -nv.
--
:wq Claudio
Index: bgpctl/output.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/output.c,v
retrieving revision 1.11
diff -u -p -r1.11 output.c
--- bgpctl/output.c 30 Dec 2020 07:31:19 - 1.11
+++ bgpctl/output.c 14 Jan 2021 14:31:45 -
@@ -647,8 +647,8 @@ show_attr(u_char *data, size_t len, stru
case ATTR_ASPATH:
case ATTR_AS4_PATH:
/* prefer 4-byte AS here */
- e4 = aspath_verify(data, alen, 1);
- e2 = aspath_verify(data, alen, 0);
+ e4 = aspath_verify(data, alen, 1, 0);
+ e2 = aspath_verify(data, alen, 0, 0);
if (e4 == 0 || e4 == AS_ERR_SOFT) {
path = data;
} else if (e2 == 0 || e2 == AS_ERR_SOFT) {
Index: bgpctl/output_json.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/output_json.c,v
retrieving revision 1.5
diff -u -p -r1.5 output_json.c
--- bgpctl/output_json.c30 Dec 2020 07:31:19 - 1.5
+++ bgpctl/output_json.c14 Jan 2021 14:31:57 -
@@ -598,8 +598,8 @@ json_attr(u_char *data, size_t len, stru
case ATTR_ASPATH:
case ATTR_AS4_PATH:
/* prefer 4-byte AS here */
- e4 = aspath_verify(data, alen, 1);
- e2 = aspath_verify(data, alen, 0);
+ e4 = aspath_verify(data, alen, 1, 0);
+ e2 = aspath_verify(data, alen, 0, 0);
if (e4 == 0 || e4 == AS_ERR_SOFT) {
path = data;
} else if (e2 == 0 || e2 == AS_ERR_SOFT) {
Index: bgpd/bgpd.conf.5
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
retrieving revision 1.205
diff -u -p -r1.205 bgpd.conf.5
--- bgpd/bgpd.conf.516 May 2020 16:58:11 - 1.205
+++ bgpd/bgpd.conf.514 Jan 2021 14:30:43 -
@@ -330,6 +330,20 @@ This renders the decision process nondet
The default is
.Ic ignore .
.Pp
+.It Xo
+.Ic reject Ic as-set
+.Pq Ic yes Ns | Ns Ic no
+.Xc
+If set to
+.Ic yes ,
+.Em AS paths
+attributes containing
+.Em AS_SET
+path segements will be rejected and
+all prefixes will be treated as withdraws.
+The default is
+.Ic no .
+.Pp
.It Ic router-id Ar dotted-quad
Set the BGP router ID, which must be non-zero and should be unique
within the AS.
@@ -1086,6 +1100,21 @@ statement defines the maximum hops the n
.Pp
.It Ic passive
Do not attempt to actively open a TCP connection to the neighbor system.
+.Pp
+.It Xo
+.Ic reject Ic as-set
+.Pq Ic yes Ns | Ns Ic no
+.Xc
+If set to
+.Ic yes ,
+.Em AS paths
+attributes containing
+.Em AS_SET
+path segements will be rejected and
+all prefixes will be treated as withdraws.
+The default is inherited from the global
+.Ic reject Ic as-set
+setting.
.Pp
.It Ic remote-as Ar as-number
Set the AS number of the remote system.
Index: bgpd/bgpd.h
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
retrieving revision 1.409
diff -u -p -r1.409 bgpd.h
--- bgpd/bgpd.h 4 Jan 2021 13:40:32 - 1.409
+++ bgpd/bgpd.h 14 Jan 2021 14:05:58 -
@@ -65,6 +65,7 @@
#defineBGPD_FLAG_DECISION_ROUTEAGE 0x0100
#defineBGPD_FLAG_DECISION_TRANS_AS 0x0200
#defineBGPD_FLAG_DECISION_MED_ALWAYS 0x0400
+#defineBGPD_FLAG_NO_AS_SET 0x0800
#defineBGPD_LOG_UPDATES0x0001
@@ -427,6 +428,7 @@ struct peer_config {
#define PEERFLAG_TRANS_AS 0x01
#define PEERFLAG_LOG_UPDATES 0x02
+#define PEERFLAG_NO_AS_SET 0x04
enum network_type {
NETWORK_DEFAULT,/* from network statements */
@@ -1346,7 +1348,7 @@ intaspath_snprint(char *, size_t, voi
int aspath_asprint(char **, void *, u_int16_t);
size_t aspath_strlen(void *, u_int16_t);
u_int32_t aspath_extract(const void *, int);
-int aspath_verify(void *, u_int16_t, int);
+int aspath_verify(void *, u_int16_t, int, int);
#define AS_ERR_LEN -1
#define AS_ERR_TYPE-2
#define AS_ERR_BAD -3
Index: bgpd/parse.y
===
RCS file: /cvs/src/usr.sbin/bgpd/parse.y,v
retrieving
Re: Change bgpd_addr encoding of VPN v4 and v6 addresses
On Thu, Jan 14, 2021 at 08:22:45PM +0100, Denis Fondras wrote: > Le Tue, Jan 12, 2021 at 10:06:46AM +0100, Claudio Jeker a écrit : > > On Tue, Jan 05, 2021 at 11:17:22AM +0100, Claudio Jeker wrote: > > > While changing log_addr() I noticed that struct bgpd_addr could benefit > > > from changing the encoding of AID_VPN_IPv4 and AID_VPN_IPv6 addrs. > > > Instead of having independent route distinguishers and labelstacks use > > > common fields for those and use the v4 and v6 addresses for the prefix. > > > This is a bit more compact but also simplifies some code since the > > > handling of AID_VPN_IPv4 and AID_VPN_IPv6 can be handled in the same > > > switch case. > > > > > > I reduced the labelstack size from 21 to 18 (6 instead of 7 labels). Now > > > in theory you could pack 7 labels into an IPv4 VPN NLRI (8bit prefixlen + > > > 64bit RD + 16bit prefix + 21 * 8bit label = 256) but that is quite silly. > > > Even 6 labels is more than enough. bgpd itself only allows a single MPLS > > > label when announcing such networks. > > > > Ping > > > > Index: bgpd/util.c > > === > > RCS file: /cvs/src/usr.sbin/bgpd/util.c,v > > retrieving revision 1.58 > > diff -u -p -r1.58 util.c > > --- bgpd/util.c 5 Jan 2021 10:00:28 - 1.58 > > +++ bgpd/util.c 5 Jan 2021 10:05:15 - > > @@ -666,9 +669,17 @@ prefix_compare(const struct bgpd_addr *a > > mask = htonl(prefixlen2mask(prefixlen)); > > aa = ntohl(a->v4.s_addr & mask); > > ba = ntohl(b->v4.s_addr & mask); > > - if (aa != ba) > > - return (aa - ba); > > - return (0); > > + if (aa > ba) > > + return (1); > > + if (aa < ba) > > + return (1); > > I guess it is -1 here. > > Otherwise OK denis@ Thanks for spotting this glitch. That would have caused some havoc for sure. -- :wq Claudio
68.html: fix typo
Hi, I spotted a typo in www/68.html and this patch will fix it. Index: 68.html === RCS file: /cvs/www/68.html,v retrieving revision 1.85 diff -u -r1.85 68.html --- 68.html 3 Jan 2021 14:19:20 - 1.85 +++ 68.html 14 Jan 2021 23:14:45 - @@ -925,7 +925,7 @@ To install, write install68.img or miniroot68.img to a -USB stick, plug it into the machine and coose the OpenBSD +USB stick, plug it into the machine and choose the OpenBSD install menu item in Petitboot. Refer to the instructions in INSTALL.powerpc64 for more details.
Update model and resolution details for Loongson Lynloong
Hi, The following patches will update the hardware note file and loongson.html with the corrent screen resolution and model details for Loongson Lynloong. Index: distrib/notes/loongson/hardware === RCS file: /cvs/src/distrib/notes/loongson/hardware,v retrieving revision 1.11 diff -u -r1.11 hardware --- distrib/notes/loongson/hardware 10 Aug 2019 17:58:57 - 1.11 +++ distrib/notes/loongson/hardware 15 Jan 2021 01:19:47 - @@ -6,9 +6,9 @@ onboard display is only supported in the video mode setup by the firmware (usually 640x400x8), without acceleration. - Lemote Lynloong + Lemote Lynloong (LM9001 and LM9002 models) onboard audio, USB and Ethernet are supported; - onboard display is only supported in the 1360x768x16 video mode + onboard display is only supported in the 1368x768x16 video mode set up by the firmware, without acceleration. Lemote Yeeloong (8.9" and 10.1" models) Index: loongson.html === RCS file: /cvs/www/loongson.html,v retrieving revision 1.67 diff -u -r1.67 loongson.html --- loongson.html 18 Oct 2020 02:37:42 - 1.67 +++ loongson.html 15 Jan 2021 01:01:19 - @@ -80,8 +80,8 @@ to the 640x400x8 video mode set up by the firmware. http://zkml.lemote.com/en/products/all-in-one/2010/0311/122.html;>Lemote Lynloong all-in-one-PC -All on-board devices are supported, but the framebuffer is currently limited -to the 1360x768x16 video mode set up by the firmware. +All on-board devices on LM9001/LM9002 are supported, but the framebuffer is currently limited +to the 1368x768x16 video mode set up by the firmware. http://zkml.lemote.com/en/products/Notebook/2010/0310/112.html;>Lemote Yeeloong netbook
loongson.html: update link for PMON repository
Hi, The following patch will update the link for PMON on loongson.html. The existing site for PMON seems to be abandoned now and development of pmon on loongson continues in Loongnix's git repository. Index: loongson.html === RCS file: /cvs/www/loongson.html,v retrieving revision 1.67 diff -u -r1.67 loongson.html --- loongson.html 18 Oct 2020 02:37:42 - 1.67 +++ loongson.html 15 Jan 2021 00:50:52 - @@ -21,7 +21,7 @@ OpenBSD/loongson is a port intended to run on systems based upon the Loongson (also known as Godson) 2E and 2F MIPS-compatible processors, using the -http://www.opsycon.se/PMON2000/Main;>PMON firmware and boot loader. +http://cgit.loongnix.org/cgit/pmon-2HSoc/;>PMON firmware and boot loader.
Suggestions for /usr/sbin/config
So I recently read most of the source for config (only stuff needed
for kernel compilation), and I'm certainly no expert, but I have a few
suggestions.
The first is that pathnames in gram.y should probably use right
recursion, correct? Unless you want to be limited to pathname lists
of length two. It doesn't matter anywhere yet, but it might someday.
The second is that one could add a precedence to the negation operator
so that you can negate an fexpr instead of just an fatom. I have to
admit I'm a little uncertain about using %nonassoc vs %right, but both
seem to work in toy parsers that I've written to emulate/check this.
Third, you would probably want pathtab to hold all the pathnames, but
it seems that, if we have more than one pathname, not all get put there
during addfile. I don't know how to deal with this exactly, but maybe
just putting it all in a for loop is okay.
Lastly, the emitlocnames function gets some things wrong. (It
sets the i_locnami field according to the i_plocnami field of the
first parent, and because i_plocnami is set according to locators of
its first child found in the packed devi list, things go awry). For
example, my ioconf.c file says that pci* has a sigle locname of "bus",
but because its first parent is mainbus0, and bios0 (with its single
locname of apid) is the first entry in packed with mainbus0 as a
parent, pci has the same index into the locnames array as bios0, which
means it appears to have an "apid" locname.
This last one seems as if it was written correctly 20 years ago and
then changed in the name of optimizing space. I say who cares about
optimizing this much space, keep it simple.
Anyway, that's all I can remember. I've applied the patches below, and
then made a new kernel with it, and everything seems to be working
okay. The locnamp array could definitely be compressed more, but at
least it's correct now.
Thank you,
Chris Waddey
Index: gram.y
===
RCS file: /cvs/src/usr.sbin/config/gram.y,v
retrieving revision 1.24
diff -u -p -r1.24 gram.y
--- gram.y 16 Jan 2015 06:40:16 - 1.24
+++ gram.y 14 Jan 2021 21:48:13 -
@@ -107,6 +107,7 @@ static voidcheck_maxpart(void);
%left '|'
%left '&'
+%nonassoc '!'
%typepathnames
%typefopts fexpr fatom
@@ -169,7 +170,7 @@ dev_eof:
pathnames:
PATHNAME{ $$ = new_nsi($1, NULL, 0); } |
- pathnames '|' PATHNAME { ($$ = $1)->nv_next = new_nsi($3,
NULL, 0); };
+ PATHNAME '|' pathnames { ($$ = new_nsi($1, NULL, 0))->nv_next
= $3; };
/*
* Various nonterminals shared between the grammars.
@@ -187,7 +188,7 @@ fopts:
fexpr:
fatom { $$ = $1; } |
- '!' fatom { $$ = fx_not($2); } |
+ '!' fexpr { $$ = fx_not($2); } |
fexpr '&' fexpr { $$ = fx_and($1, $3); } |
fexpr '|' fexpr { $$ = fx_or($1, $3); } |
'(' fexpr ')' { $$ = $2; };
Index: files.c
===
RCS file: /cvs/src/usr.sbin/config/files.c,v
retrieving revision 1.20
diff -u -p -r1.20 files.c
--- files.c 16 Jan 2015 06:40:16 - 1.20
+++ files.c 14 Jan 2021 21:49:15 -
@@ -143,13 +143,16 @@ addfile(struct nvlist *nvpath, struct nv
* will be used after all.
*/
fi = emalloc(sizeof *fi);
- if (ht_insert(pathtab, path, fi)) {
- free(fi);
- if ((fi = ht_lookup(pathtab, path)) == NULL)
- panic("addfile: ht_lookup(%s)", path);
- error("duplicate file %s", path);
- xerror(fi->fi_srcfile, fi->fi_srcline,
- "here is the original definition");
+ for (nv = nvpath; nv; nv = nv->nv_next) {
+ path = nv->nv_name;
+ if (ht_insert(pathtab, path, fi)) {
+ free(fi);
+ if ((fi = ht_lookup(pathtab, path)) == NULL)
+ panic("addfile: ht_lookup(%s)", path);
+ error("duplicate file %s", path);
+ xerror(fi->fi_srcfile, fi->fi_srcline,
+ "here is the original definition");
+ }
}
memcpy(base, tail, baselen);
base[baselen] = 0;
Index: mkioconf.c
===
RCS file: /cvs/src/usr.sbin/config/mkioconf.c,v
retrieving revision 1.38
diff -u -p -r1.38 mkioconf.c
--- mkioconf.c 28 Jun 2019 13:33:55 - 1.38
+++ mkioconf.c 14 Jan 2021 21:49:57 -
@@ -230,42 +230,29 @@ emitlocnames(FILE *fp)
struct devi **p, *i;
struct nvlist *nv;
struct attr *a;
- int added, start;
- int v, j, x;
+ int j, x, added;
addlocnami(-1);
for (p = packed; (i = *p) !=
bpf_mtap_ether doesnt need to encode packet priority
bpf should be showing what will be or has been on the wire, which is what the ether_vtag in the mbuf has. the prio is either about to be decoded from the tag on the wya into the stack, or has been encoded by vlan(4) on the way out of the stack. ok? Index: bpf.c === RCS file: /cvs/src/sys/net/bpf.c,v retrieving revision 1.201 diff -u -p -r1.201 bpf.c --- bpf.c 2 Jan 2021 07:25:42 - 1.201 +++ bpf.c 15 Jan 2021 01:12:31 - @@ -1444,7 +1444,6 @@ bpf_mtap_ether(caddr_t arg, const struct #if NVLAN > 0 struct ether_vlan_header evh; struct m_hdr mh, md; - uint8_t prio; if ((m->m_flags & M_VLANTAG) == 0) #endif @@ -1455,15 +1454,10 @@ bpf_mtap_ether(caddr_t arg, const struct #if NVLAN > 0 KASSERT(m->m_len >= ETHER_HDR_LEN); - prio = m->m_pkthdr.pf.prio; - if (prio <= 1) - prio = !prio; - memcpy(, mtod(m, char *), ETHER_HDR_LEN); evh.evl_proto = evh.evl_encap_proto; evh.evl_encap_proto = htons(ETHERTYPE_VLAN); - evh.evl_tag = htons(m->m_pkthdr.ether_vtag | - (prio << EVL_PRIO_BITS)); + evh.evl_tag = htons(m->m_pkthdr.ether_vtag); mh.mh_flags = 0; mh.mh_data = (caddr_t)
Re: all platforms: isolate hardclock(9) from statclock()
On Wed, Jan 13, 2021 at 9:38 PM Scott Cheloha wrote: snip > Do we need to properly set stathz for each platform in *this* diff? > Or can it wait? > > I was hoping to do a sweep of the tree in a later patch and ensure > that stathz is non-zero everywhere and simultaneously remove code like > this: > > int realstathz = stathz ? stathz : hz; > > Near as I can tell, stathz doesn't need to be nonzero for statclock() > to work correctly. Also, setstatclockrate() doesn't even run unless > stathz is non-zero, so there are no issues with the profiling clock > stuff yet. > > > This isn't to say that removing the stathz== 0 magic should not be done, > > but if done, make certain that stathz and profhz are properly > > updated/configured. > Every driver which is being modified to call both hardclock() and statclock() will need to be modified again to set stathz, then you will need to verify with the rest of the system that there is no other places that stathz init was previously forgotten. Therefore, why not correctly modify each driver now?
Re: bgpd adjust aspath_neighbor to follow RFC more closely
Le Thu, Jan 14, 2021 at 02:20:26PM +0100, Claudio Jeker a écrit :
> The aspath_neighbor function returns the first AS of a path. Now if the
> first element is an AS_SET then this does not really make sense.
> RFC4271 has this bit in section 9.1.2.2
>
> Similarly, neighborAS(n) is a function that returns the
> neighbor AS from which the route was received. If the route is
> learned via IBGP, and the other IBGP speaker didn't originate
> the route, it is the neighbor AS from which the other IBGP
> speaker learned the route. If the route is learned via IBGP,
> and the other IBGP speaker either (a) originated the route, or
> (b) created the route by aggregation and the AS_PATH attribute
> of the aggregate route is either empty or begins with an
> AS_SET, it is the local AS.
>
> bgpd uses aspath_neighbor() in a few spots:
> - in the decision process to decide if MED should be compared or not
> - in filters using 'peer-as'
> - in the enforce neighbor-as check
>
> I think the above mentioned behaviour is valid for all these cases and so
> here is a diff that adjust aspath_neighbor().
>
OK denis@
> --
> :wq Claudio
>
> Index: rde_attr.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/rde_attr.c,v
> retrieving revision 1.123
> diff -u -p -r1.123 rde_attr.c
> --- rde_attr.c24 Jun 2019 06:39:49 - 1.123
> +++ rde_attr.c14 Jan 2021 13:13:15 -
> @@ -673,8 +673,13 @@ aspath_length(struct aspath *aspath)
> u_int32_t
> aspath_neighbor(struct aspath *aspath)
> {
> - /* Empty aspath is OK -- internal AS route. */
> - if (aspath->len == 0)
> + /*
> + * Empty aspath is OK -- internal AS route.
> + * Additionally the RFC specifies that if the path starts with an
> + * AS_SET the neighbor AS is also the local AS.
> + */
> + if (aspath->len == 0 ||
> + aspath->data[0] != AS_SEQUENCE)
> return (rde_local_as());
> return (aspath_extract(aspath->data, 0));
> }
>
Re: Change bgpd_addr encoding of VPN v4 and v6 addresses
Le Tue, Jan 12, 2021 at 10:06:46AM +0100, Claudio Jeker a écrit : > On Tue, Jan 05, 2021 at 11:17:22AM +0100, Claudio Jeker wrote: > > While changing log_addr() I noticed that struct bgpd_addr could benefit > > from changing the encoding of AID_VPN_IPv4 and AID_VPN_IPv6 addrs. > > Instead of having independent route distinguishers and labelstacks use > > common fields for those and use the v4 and v6 addresses for the prefix. > > This is a bit more compact but also simplifies some code since the > > handling of AID_VPN_IPv4 and AID_VPN_IPv6 can be handled in the same > > switch case. > > > > I reduced the labelstack size from 21 to 18 (6 instead of 7 labels). Now > > in theory you could pack 7 labels into an IPv4 VPN NLRI (8bit prefixlen + > > 64bit RD + 16bit prefix + 21 * 8bit label = 256) but that is quite silly. > > Even 6 labels is more than enough. bgpd itself only allows a single MPLS > > label when announcing such networks. > > Ping > > Index: bgpd/util.c > === > RCS file: /cvs/src/usr.sbin/bgpd/util.c,v > retrieving revision 1.58 > diff -u -p -r1.58 util.c > --- bgpd/util.c 5 Jan 2021 10:00:28 - 1.58 > +++ bgpd/util.c 5 Jan 2021 10:05:15 - > @@ -666,9 +669,17 @@ prefix_compare(const struct bgpd_addr *a > mask = htonl(prefixlen2mask(prefixlen)); > aa = ntohl(a->v4.s_addr & mask); > ba = ntohl(b->v4.s_addr & mask); > - if (aa != ba) > - return (aa - ba); > - return (0); > + if (aa > ba) > + return (1); > + if (aa < ba) > + return (1); I guess it is -1 here. Otherwise OK denis@
Re: all platforms: isolate hardclock(9) from statclock()
On Thu, Jan 07, 2021 at 11:15:42AM -0600, Scott Cheloha wrote:
> Hi,
>
> I want to isolate statclock() from hardclock(9). This will simplify
> the logic in my WIP dynamic clock interrupt framework.
>
> Currently, if stathz is zero, we call statclock() from within
> hardclock(9). It looks like this (see sys/kern/kern_clock.c):
>
> void
> hardclock(struct clockframe *frame)
> {
> /* [...] */
>
> if (stathz == 0)
> statclock(frame);
>
> /* [...] */
>
> This is the case on alpha, amd64 (w/ lapic), hppa, i386 (w/ lapic),
> loongson, luna88k, mips64, and sh.
>
> (We seem to do it on sgi, too. I was under the impression that sgi
> *was* a mips64 platform, yet sgi seems to it have its own clock
> interrupt code distinct from mips64's general clock interrupt code
> which is used by e.g. octeon).
>
> However, if stathz is not zero we call statclock() separately. This
> is the case on armv7, arm, arm64, macppc, powerpc64, and sparc64.
>
> (The situation for the general powerpc code and socppc in particular
> is a mystery to me.)
>
> If we could remove this MD distinction it would make my MI framework
> simpler. Instead of checking stathz and conditionally starting a
> statclock event I will be able to unconditionally start a statclock
> event on all platforms on every CPU.
>
> In general I don't think the "is stathz zero?" variance between
> platforms is useful:
>
> - The difference is invisible to userspace, as we hide the fact that
> stathz is zero from e.g. the kern.clockrate sysctl.
>
> - We run statclock() at some point, regardless of whether stathz is
> zero. If statclock() is run from hardclock(9) then isn't stathz
> effectively equal to hz?
>
> - Because stathz might be zero we need to add a bunch of safety checks
> to our MI code to ensure we don't accidentally divide by zero.
>
> Maybe we can ensure stathz is non-zero in a later diff...
>
> --
>
> Anyway, I don't think I have missed any platforms. However, if
> platform experts could weigh in here to verify my changes (and test
> them!) I'd really appreciate it.
>
> In particular, I'm confused about how clock interrupts work on
> powerpc, socppc, and sgi.
Updated diff.
- As noted by visa@, loongson already has a distinct statclock
interrupt, so remove the changes to arch/loongson/dev/glxclk.c.
I have successful tests on these platforms:
- amd64
- luna88k
- hppa
Still need tests on these platforms:
- alpha
- i386
- mips64 (octeon will be sufficient)
- sgi
- sh
Related: is there a way to test i386 on amd64 hardware?
Index: sys/kern/kern_clock.c
===
RCS file: /cvs/src/sys/kern/kern_clock.c,v
retrieving revision 1.102
diff -u -p -r1.102 kern_clock.c
--- sys/kern/kern_clock.c 13 Jan 2021 16:28:49 - 1.102
+++ sys/kern/kern_clock.c 14 Jan 2021 18:39:03 -
@@ -160,12 +160,6 @@ hardclock(struct clockframe *frame)
}
}
- /*
-* If no separate statistics clock is available, run it from here.
-*/
- if (stathz == 0)
- statclock(frame);
-
if (--ci->ci_schedstate.spc_rrticks <= 0)
roundrobin(ci);
Index: sys/arch/alpha/alpha/clock.c
===
RCS file: /cvs/src/sys/arch/alpha/alpha/clock.c,v
retrieving revision 1.24
diff -u -p -r1.24 clock.c
--- sys/arch/alpha/alpha/clock.c6 Jul 2020 13:33:06 - 1.24
+++ sys/arch/alpha/alpha/clock.c14 Jan 2021 18:39:04 -
@@ -136,6 +136,13 @@ clockattach(dev, fns)
* Machine-dependent clock routines.
*/
+void
+clockintr(struct clockframe *frame)
+{
+ hardclock(frame);
+ statclock(frame);
+}
+
/*
* Start the real-time and statistics clocks. Leave stathz 0 since there
* are no other timers available.
@@ -165,7 +172,7 @@ cpu_initclocks(void)
* hardclock, which would then fall over because the pointer
* to the virtual timers wasn't set at that time.
*/
- platform.clockintr = hardclock;
+ platform.clockintr = clockintr;
schedhz = 16;
evcount_attach(_count, "clock", _irq);
Index: sys/arch/amd64/amd64/lapic.c
===
RCS file: /cvs/src/sys/arch/amd64/amd64/lapic.c,v
retrieving revision 1.57
diff -u -p -r1.57 lapic.c
--- sys/arch/amd64/amd64/lapic.c6 Sep 2020 20:50:00 - 1.57
+++ sys/arch/amd64/amd64/lapic.c14 Jan 2021 18:39:04 -
@@ -452,6 +452,7 @@ lapic_clockintr(void *arg, struct intrfr
floor = ci->ci_handled_intr_level;
ci->ci_handled_intr_level = ci->ci_ilevel;
hardclock((struct clockframe *));
+ statclock((struct clockframe *));
ci->ci_handled_intr_level = floor;
clk_count.ec_count++;
Index: sys/arch/hppa/dev/clock.c
===
RCS file:
allow bgpd to reject AS_SET segemnts (enforce RFC6472)
This diff adds 'reject as-set yes' as an option to filter out AS paths
with AS_SET segement elements. In bgpctl they show up with {} elements,
e.g. 174 6762 24835 { 36893 }.
This diff uses the soft-error path from RFC7606 and because of this
prefixes that have such an AS_SET segment will be removed via
treat-as-withdraw. These prefixes can be seen in `bgpctl show rib in error`.
By default this is turned off.
--
:wq Claudio
Index: bgpctl/output.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/output.c,v
retrieving revision 1.11
diff -u -p -r1.11 output.c
--- bgpctl/output.c 30 Dec 2020 07:31:19 - 1.11
+++ bgpctl/output.c 14 Jan 2021 14:31:45 -
@@ -647,8 +647,8 @@ show_attr(u_char *data, size_t len, stru
case ATTR_ASPATH:
case ATTR_AS4_PATH:
/* prefer 4-byte AS here */
- e4 = aspath_verify(data, alen, 1);
- e2 = aspath_verify(data, alen, 0);
+ e4 = aspath_verify(data, alen, 1, 0);
+ e2 = aspath_verify(data, alen, 0, 0);
if (e4 == 0 || e4 == AS_ERR_SOFT) {
path = data;
} else if (e2 == 0 || e2 == AS_ERR_SOFT) {
Index: bgpctl/output_json.c
===
RCS file: /cvs/src/usr.sbin/bgpctl/output_json.c,v
retrieving revision 1.5
diff -u -p -r1.5 output_json.c
--- bgpctl/output_json.c30 Dec 2020 07:31:19 - 1.5
+++ bgpctl/output_json.c14 Jan 2021 14:31:57 -
@@ -598,8 +598,8 @@ json_attr(u_char *data, size_t len, stru
case ATTR_ASPATH:
case ATTR_AS4_PATH:
/* prefer 4-byte AS here */
- e4 = aspath_verify(data, alen, 1);
- e2 = aspath_verify(data, alen, 0);
+ e4 = aspath_verify(data, alen, 1, 0);
+ e2 = aspath_verify(data, alen, 0, 0);
if (e4 == 0 || e4 == AS_ERR_SOFT) {
path = data;
} else if (e2 == 0 || e2 == AS_ERR_SOFT) {
Index: bgpd/bgpd.conf.5
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.conf.5,v
retrieving revision 1.205
diff -u -p -r1.205 bgpd.conf.5
--- bgpd/bgpd.conf.516 May 2020 16:58:11 - 1.205
+++ bgpd/bgpd.conf.514 Jan 2021 14:30:43 -
@@ -330,6 +330,20 @@ This renders the decision process nondet
The default is
.Ic ignore .
.Pp
+.It Xo
+.Ic reject Ic as-set
+.Pq Ic yes Ns | Ns Ic no
+.Xc
+If set to
+.Ic yes ,
+.Em AS paths
+attributes containing
+.Em AS_SET
+path segements will be rejected and
+all prefixes will be treated as withdraws.
+The default is
+.Ic no .
+.Pp
.It Ic router-id Ar dotted-quad
Set the BGP router ID, which must be non-zero and should be unique
within the AS.
@@ -1086,6 +1100,21 @@ statement defines the maximum hops the n
.Pp
.It Ic passive
Do not attempt to actively open a TCP connection to the neighbor system.
+.Pp
+.It Xo
+.Ic reject Ic as-set
+.Pq Ic yes Ns | Ns Ic no
+.Xc
+If set to
+.Ic yes ,
+.Em AS paths
+attributes containing
+.Em AS_SET
+path segements will be rejected and
+all prefixes will be treated as withdraws.
+The default is inherited from the global
+.Ic reject Ic as-set
+setting.
.Pp
.It Ic remote-as Ar as-number
Set the AS number of the remote system.
Index: bgpd/bgpd.h
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
retrieving revision 1.409
diff -u -p -r1.409 bgpd.h
--- bgpd/bgpd.h 4 Jan 2021 13:40:32 - 1.409
+++ bgpd/bgpd.h 14 Jan 2021 14:05:58 -
@@ -65,6 +65,7 @@
#defineBGPD_FLAG_DECISION_ROUTEAGE 0x0100
#defineBGPD_FLAG_DECISION_TRANS_AS 0x0200
#defineBGPD_FLAG_DECISION_MED_ALWAYS 0x0400
+#defineBGPD_FLAG_NO_AS_SET 0x0800
#defineBGPD_LOG_UPDATES0x0001
@@ -427,6 +428,7 @@ struct peer_config {
#define PEERFLAG_TRANS_AS 0x01
#define PEERFLAG_LOG_UPDATES 0x02
+#define PEERFLAG_NO_AS_SET 0x04
enum network_type {
NETWORK_DEFAULT,/* from network statements */
@@ -1346,7 +1348,7 @@ intaspath_snprint(char *, size_t, voi
int aspath_asprint(char **, void *, u_int16_t);
size_t aspath_strlen(void *, u_int16_t);
u_int32_t aspath_extract(const void *, int);
-int aspath_verify(void *, u_int16_t, int);
+int aspath_verify(void *, u_int16_t, int, int);
#define AS_ERR_LEN -1
#define AS_ERR_TYPE-2
#define AS_ERR_BAD -3
Index: bgpd/parse.y
===
RCS file: /cvs/src/usr.sbin/bgpd/parse.y,v
retrieving revision 1.411
diff -u -p -r1.411 parse.y
--- bgpd/parse.y29 Dec 2020 15:30:34 - 1.411
+++ bgpd/parse.y14 Jan 2021 14:17:19 -
@@ -623,6
Re: behaviour of openssl s_server and certificate chains on 6.8
On 14/01/21 14:50 +0100, Theo Buehler wrote: > On Thu, Jan 14, 2021 at 02:37:20PM +0100, Robert Nagy wrote: > > On 14/01/21 14:27 +0100, Robert Nagy wrote: > > > On 14/01/21 14:20 +0100, Theo Buehler wrote: > > > > On Thu, Jan 14, 2021 at 01:32:41PM +0100, Matthieu Herrb wrote: > > > > > Hi, > > > > > > > > > > I'm trying to debug strange beahaviour changes with certificates on a > > > > > systemc after upgrading it from 6.7 to 6.8... > > > > > > > > > > On 6.7, If I run : > > > > > > > > > > openssl s_server -cert mycert.pem -key mykey.pem -CAfile CA.pem > > > > > > > > > > then openssl s_client -showcerts -connect localhost:4433 > > > > > > > > > > returns the full certificate chain mycert->CA > > > > > > > > > > With the same commands on 6.8, I don't get the CA certificate. > > > > > > > > > > Is this a known issue, and how can I get the chain with 6.8 ? > > > > > > > > > > (my real application is sendmail...) > > > > > > > > In short: Yes, this is known. You can't get the chain in 6.8. > > > > > > > > This is the reason why ajacoutot switched sendmail to link against > > > > eopenssl11 as a workaround in -stable. As your thread on ports shows, > > > > this workaround doesn't work if you add something that links against > > > > LibreSSL to the mix. > > > > > > > > There are several layers of unexpected things/bugs involved. The two > > > > main points are: > > > > > > > > 1. The TLSv1.3 server in 6.8 does not do auto chain since we hoped to > > > >be able to avoid it. This was addressed post release when people > > > >using OpenLDAP ran into it. > > > >https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.62 > > > > > > > > 2. The new verifier doesn't behave as it should when auto chain is > > > >enabled. As a workaround -current switches to the legacy verifier in > > > >this situation for about a week now. The proper fix in the new > > > >verifier is under discussion. > > > >https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.65 > > > > > > > > I don't know whether/when there will be backports of some fixes to 6.8. > > > > As sthen said in the thread on ports, right now the simplest fix is to > > > > run -current. > > > > > > > > > > i think this should be an errata for 6.8 > > Not exactly sure what you mean by "this," but I emphatically agree, > errata are long overdue. It would be desirable to avoid an outright > switch back to the legacy verifier if that's what you mean by the below. > > > I am also getting this problem with bacula using TLS < 1.3, reported to Bob > > already, and I am currently running with the legacy verifier. > > FWIW this is a different issue that was also adressed in -current. > https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/x509/x509_verify.c#rev1.26 Well we either do a big errata consisting of all these fixes or switch back to the legacy one in 6.8 with one small errata. People rely on stable, so we should act accordingly.
Re: behaviour of openssl s_server and certificate chains on 6.8
On Thu, Jan 14, 2021 at 02:37:20PM +0100, Robert Nagy wrote: > On 14/01/21 14:27 +0100, Robert Nagy wrote: > > On 14/01/21 14:20 +0100, Theo Buehler wrote: > > > On Thu, Jan 14, 2021 at 01:32:41PM +0100, Matthieu Herrb wrote: > > > > Hi, > > > > > > > > I'm trying to debug strange beahaviour changes with certificates on a > > > > systemc after upgrading it from 6.7 to 6.8... > > > > > > > > On 6.7, If I run : > > > > > > > > openssl s_server -cert mycert.pem -key mykey.pem -CAfile CA.pem > > > > > > > > then openssl s_client -showcerts -connect localhost:4433 > > > > > > > > returns the full certificate chain mycert->CA > > > > > > > > With the same commands on 6.8, I don't get the CA certificate. > > > > > > > > Is this a known issue, and how can I get the chain with 6.8 ? > > > > > > > > (my real application is sendmail...) > > > > > > In short: Yes, this is known. You can't get the chain in 6.8. > > > > > > This is the reason why ajacoutot switched sendmail to link against > > > eopenssl11 as a workaround in -stable. As your thread on ports shows, > > > this workaround doesn't work if you add something that links against > > > LibreSSL to the mix. > > > > > > There are several layers of unexpected things/bugs involved. The two > > > main points are: > > > > > > 1. The TLSv1.3 server in 6.8 does not do auto chain since we hoped to > > >be able to avoid it. This was addressed post release when people > > >using OpenLDAP ran into it. > > >https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.62 > > > > > > 2. The new verifier doesn't behave as it should when auto chain is > > >enabled. As a workaround -current switches to the legacy verifier in > > >this situation for about a week now. The proper fix in the new > > >verifier is under discussion. > > >https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.65 > > > > > > I don't know whether/when there will be backports of some fixes to 6.8. > > > As sthen said in the thread on ports, right now the simplest fix is to > > > run -current. > > > > > > > i think this should be an errata for 6.8 Not exactly sure what you mean by "this," but I emphatically agree, errata are long overdue. It would be desirable to avoid an outright switch back to the legacy verifier if that's what you mean by the below. > I am also getting this problem with bacula using TLS < 1.3, reported to Bob > already, and I am currently running with the legacy verifier. FWIW this is a different issue that was also adressed in -current. https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libcrypto/x509/x509_verify.c#rev1.26
Re: behaviour of openssl s_server and certificate chains on 6.8
On 14/01/21 14:27 +0100, Robert Nagy wrote: > On 14/01/21 14:20 +0100, Theo Buehler wrote: > > On Thu, Jan 14, 2021 at 01:32:41PM +0100, Matthieu Herrb wrote: > > > Hi, > > > > > > I'm trying to debug strange beahaviour changes with certificates on a > > > systemc after upgrading it from 6.7 to 6.8... > > > > > > On 6.7, If I run : > > > > > > openssl s_server -cert mycert.pem -key mykey.pem -CAfile CA.pem > > > > > > then openssl s_client -showcerts -connect localhost:4433 > > > > > > returns the full certificate chain mycert->CA > > > > > > With the same commands on 6.8, I don't get the CA certificate. > > > > > > Is this a known issue, and how can I get the chain with 6.8 ? > > > > > > (my real application is sendmail...) > > > > In short: Yes, this is known. You can't get the chain in 6.8. > > > > This is the reason why ajacoutot switched sendmail to link against > > eopenssl11 as a workaround in -stable. As your thread on ports shows, > > this workaround doesn't work if you add something that links against > > LibreSSL to the mix. > > > > There are several layers of unexpected things/bugs involved. The two > > main points are: > > > > 1. The TLSv1.3 server in 6.8 does not do auto chain since we hoped to > >be able to avoid it. This was addressed post release when people > >using OpenLDAP ran into it. > >https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.62 > > > > 2. The new verifier doesn't behave as it should when auto chain is > >enabled. As a workaround -current switches to the legacy verifier in > >this situation for about a week now. The proper fix in the new > >verifier is under discussion. > >https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.65 > > > > I don't know whether/when there will be backports of some fixes to 6.8. > > As sthen said in the thread on ports, right now the simplest fix is to > > run -current. > > > > i think this should be an errata for 6.8 > I am also getting this problem with bacula using TLS < 1.3, reported to Bob already, and I am currently running with the legacy verifier.
Re: behaviour of openssl s_server and certificate chains on 6.8
On 14/01/21 14:20 +0100, Theo Buehler wrote: > On Thu, Jan 14, 2021 at 01:32:41PM +0100, Matthieu Herrb wrote: > > Hi, > > > > I'm trying to debug strange beahaviour changes with certificates on a > > systemc after upgrading it from 6.7 to 6.8... > > > > On 6.7, If I run : > > > > openssl s_server -cert mycert.pem -key mykey.pem -CAfile CA.pem > > > > then openssl s_client -showcerts -connect localhost:4433 > > > > returns the full certificate chain mycert->CA > > > > With the same commands on 6.8, I don't get the CA certificate. > > > > Is this a known issue, and how can I get the chain with 6.8 ? > > > > (my real application is sendmail...) > > In short: Yes, this is known. You can't get the chain in 6.8. > > This is the reason why ajacoutot switched sendmail to link against > eopenssl11 as a workaround in -stable. As your thread on ports shows, > this workaround doesn't work if you add something that links against > LibreSSL to the mix. > > There are several layers of unexpected things/bugs involved. The two > main points are: > > 1. The TLSv1.3 server in 6.8 does not do auto chain since we hoped to >be able to avoid it. This was addressed post release when people >using OpenLDAP ran into it. >https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.62 > > 2. The new verifier doesn't behave as it should when auto chain is >enabled. As a workaround -current switches to the legacy verifier in >this situation for about a week now. The proper fix in the new >verifier is under discussion. >https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.65 > > I don't know whether/when there will be backports of some fixes to 6.8. > As sthen said in the thread on ports, right now the simplest fix is to > run -current. > i think this should be an errata for 6.8
Re: behaviour of openssl s_server and certificate chains on 6.8
On Thu, Jan 14, 2021 at 02:20:38PM +0100, Theo Buehler wrote: > On Thu, Jan 14, 2021 at 01:32:41PM +0100, Matthieu Herrb wrote: > > Hi, > > > > I'm trying to debug strange beahaviour changes with certificates on a > > systemc after upgrading it from 6.7 to 6.8... > > > > On 6.7, If I run : > > > > openssl s_server -cert mycert.pem -key mykey.pem -CAfile CA.pem > > > > then openssl s_client -showcerts -connect localhost:4433 > > > > returns the full certificate chain mycert->CA > > > > With the same commands on 6.8, I don't get the CA certificate. > > > > Is this a known issue, and how can I get the chain with 6.8 ? > > > > (my real application is sendmail...) > > In short: Yes, this is known. You can't get the chain in 6.8. > > This is the reason why ajacoutot switched sendmail to link against > eopenssl11 as a workaround in -stable. As your thread on ports shows, > this workaround doesn't work if you add something that links against > LibreSSL to the mix. > > There are several layers of unexpected things/bugs involved. The two > main points are: > > 1. The TLSv1.3 server in 6.8 does not do auto chain since we hoped to >be able to avoid it. This was addressed post release when people >using OpenLDAP ran into it. >https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.62 > > 2. The new verifier doesn't behave as it should when auto chain is >enabled. As a workaround -current switches to the legacy verifier in >this situation for about a week now. The proper fix in the new >verifier is under discussion. >https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.65 > > I don't know whether/when there will be backports of some fixes to 6.8. > As sthen said in the thread on ports, right now the simplest fix is to > run -current. Ok, thanks. Not the easiest for me, but I wont try to build a frankenstein system. In the mean time it looks like switching to insecure ldap connections for sendmail works (the ldap server is on localhost so the risk is not very high) -- Matthieu Herrb
Re: behaviour of openssl s_server and certificate chains on 6.8
On Thu, Jan 14, 2021 at 01:32:41PM +0100, Matthieu Herrb wrote: > Hi, > > I'm trying to debug strange beahaviour changes with certificates on a > systemc after upgrading it from 6.7 to 6.8... > > On 6.7, If I run : > > openssl s_server -cert mycert.pem -key mykey.pem -CAfile CA.pem > > then openssl s_client -showcerts -connect localhost:4433 > > returns the full certificate chain mycert->CA > > With the same commands on 6.8, I don't get the CA certificate. > > Is this a known issue, and how can I get the chain with 6.8 ? > > (my real application is sendmail...) In short: Yes, this is known. You can't get the chain in 6.8. This is the reason why ajacoutot switched sendmail to link against eopenssl11 as a workaround in -stable. As your thread on ports shows, this workaround doesn't work if you add something that links against LibreSSL to the mix. There are several layers of unexpected things/bugs involved. The two main points are: 1. The TLSv1.3 server in 6.8 does not do auto chain since we hoped to be able to avoid it. This was addressed post release when people using OpenLDAP ran into it. https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.62 2. The new verifier doesn't behave as it should when auto chain is enabled. As a workaround -current switches to the legacy verifier in this situation for about a week now. The proper fix in the new verifier is under discussion. https://cvsweb.openbsd.org/src/lib/libssl/tls13_server.c#rev1.65 I don't know whether/when there will be backports of some fixes to 6.8. As sthen said in the thread on ports, right now the simplest fix is to run -current.
bgpd adjust aspath_neighbor to follow RFC more closely
The aspath_neighbor function returns the first AS of a path. Now if the
first element is an AS_SET then this does not really make sense.
RFC4271 has this bit in section 9.1.2.2
Similarly, neighborAS(n) is a function that returns the
neighbor AS from which the route was received. If the route is
learned via IBGP, and the other IBGP speaker didn't originate
the route, it is the neighbor AS from which the other IBGP
speaker learned the route. If the route is learned via IBGP,
and the other IBGP speaker either (a) originated the route, or
(b) created the route by aggregation and the AS_PATH attribute
of the aggregate route is either empty or begins with an
AS_SET, it is the local AS.
bgpd uses aspath_neighbor() in a few spots:
- in the decision process to decide if MED should be compared or not
- in filters using 'peer-as'
- in the enforce neighbor-as check
I think the above mentioned behaviour is valid for all these cases and so
here is a diff that adjust aspath_neighbor().
--
:wq Claudio
Index: rde_attr.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_attr.c,v
retrieving revision 1.123
diff -u -p -r1.123 rde_attr.c
--- rde_attr.c 24 Jun 2019 06:39:49 - 1.123
+++ rde_attr.c 14 Jan 2021 13:13:15 -
@@ -673,8 +673,13 @@ aspath_length(struct aspath *aspath)
u_int32_t
aspath_neighbor(struct aspath *aspath)
{
- /* Empty aspath is OK -- internal AS route. */
- if (aspath->len == 0)
+ /*
+* Empty aspath is OK -- internal AS route.
+* Additionally the RFC specifies that if the path starts with an
+* AS_SET the neighbor AS is also the local AS.
+*/
+ if (aspath->len == 0 ||
+ aspath->data[0] != AS_SEQUENCE)
return (rde_local_as());
return (aspath_extract(aspath->data, 0));
}
behaviour of openssl s_server and certificate chains on 6.8
Hi, I'm trying to debug strange beahaviour changes with certificates on a systemc after upgrading it from 6.7 to 6.8... On 6.7, If I run : openssl s_server -cert mycert.pem -key mykey.pem -CAfile CA.pem then openssl s_client -showcerts -connect localhost:4433 returns the full certificate chain mycert->CA With the same commands on 6.8, I don't get the CA certificate. Is this a known issue, and how can I get the chain with 6.8 ? (my real application is sendmail...) -- Matthieu Herrb
bgpd fix route decision for strict med
Currently bgpd does not properly handle strict med route decisions.
The problem is that the strict MED check only matters for aspaths with the
same neighbor as. The route decision process currently stops as soon as
the current prefix is better then the one checked in the list of prefixes.
Now in some cases this results in unstable decisions because the order of
insertions matter. Depending on the order any route may be selected.
The med.sh regress test I added shows this issue. Depending on the order
any of the 3 routes can be selected as best:
1:
flags ovs destination gateway lpref med aspath origin
*> N 10.12.1.0/24 10.12.57.410050 64501 64510 i
* N 10.12.1.0/24 10.12.57.2100 100 64501 64510 i
* N 10.12.1.0/24 10.12.57.3100 100 64502 64510 i
2:
flags ovs destination gateway lpref med aspath origin
*> N 10.12.1.0/24 10.12.57.2100 100 64501 64510 i
* N 10.12.1.0/24 10.12.57.3100 100 64502 64510 i
* N 10.12.1.0/24 10.12.57.410050 64501 64510 i
3 (and the actual expected result):
flags ovs destination gateway lpref med aspath origin
*> N 10.12.1.0/24 10.12.57.3100 100 64502 64510 i
* N 10.12.1.0/24 10.12.57.410050 64501 64510 i
* N 10.12.1.0/24 10.12.57.2100 100 64501 64510 i
Additionally removing a route requires to reevaluate part of the routes in
some cases. For examle in case 3 if the middle route (with med 50) is
removed then the last route actually becomes best (bgpid is lower).
The following diff fixes this issue hopefully. On insertion if decisions
happen at or after the MED check (step 5) then all remaining routes need
to be checked (until a check before step 5 happens). Routes matching on
med that need to be re-evaluated are put on a redo queue and at the end of
the decision process are put back to get their order right.
Something similar happens when removing a prefix. If the next prefix
differ on a check after the MED check then again all those prefixes need
to be rechecked and maybe re-evaluated.
This change is important but also rather complex. Please test and if
possible validate that it does not cause troubles in your setup.
Btw. this only matters for 'rde med compare strict' (default).
--
:wq Claudio
Index: rde_decide.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde_decide.c,v
retrieving revision 1.80
diff -u -p -r1.80 rde_decide.c
--- rde_decide.c14 Jan 2021 08:29:26 - 1.80
+++ rde_decide.c14 Jan 2021 10:16:30 -
@@ -26,7 +26,9 @@
#include "rde.h"
#include "log.h"
-intprefix_cmp(struct prefix *, struct prefix *);
+intprefix_cmp(struct prefix *, struct prefix *, int *);
+void prefix_insert(struct prefix *, struct prefix *, struct rib_entry *);
+void prefix_remove(struct prefix *, struct rib_entry *);
/*
* Decision Engine RFC implementation:
* Phase 1:
@@ -107,7 +109,7 @@ int prefix_cmp(struct prefix *, struct p
* already added prefix.
*/
int
-prefix_cmp(struct prefix *p1, struct prefix *p2)
+prefix_cmp(struct prefix *p1, struct prefix *p2, int *testall)
{
struct rde_aspath *asp1, *asp2;
struct rde_peer *peer1, *peer2;
@@ -115,6 +117,16 @@ prefix_cmp(struct prefix *p1, struct pre
u_int32_tp1id, p2id;
int p1cnt, p2cnt, i;
+ /*
+* If a match happens before the MED check then the list is
+* correctly sorted. If a match happens after MED then it
+* may further elements need to be checked to make sure that
+* all path are considered that could affect this path.
+* If the check happens to be on MED signal this by setting
+* testall to 2.
+*/
+ *testall = 0;
+
if (p1 == NULL)
return -1;
if (p2 == NULL)
@@ -166,10 +178,14 @@ prefix_cmp(struct prefix *p1, struct pre
/*
* 5. MED decision
* Only comparable between the same neighboring AS or if
-* 'rde med compare always' is set.
+* 'rde med compare always' is set. In the first case
+* set the testall flag since further elements need to be
+* evaluated as well.
*/
if ((rde_decisionflags() & BGPD_FLAG_DECISION_MED_ALWAYS) ||
aspath_neighbor(asp1->aspath) == aspath_neighbor(asp2->aspath)) {
+ if (!(rde_decisionflags() & BGPD_FLAG_DECISION_MED_ALWAYS))
+ *testall = 2;
/* lowest value wins */
if (asp1->med < asp2->med)
return 1;
@@ -177,6 +193,9 @@ prefix_cmp(struct prefix *p1, struct pre
return -1;
}
+ if (!(rde_decisionflags() & BGPD_FLAG_DECISION_MED_ALWAYS))
+
Re: all platforms: isolate hardclock(9) from statclock()
> My understanding is that HZ=100 was a practical choice because the > machines of the day could not reliably drive a faster clock interrupt. The VAX architecture defines a 100Hz timer, which is the only timer you can be sure will be available to the kernel. A few of the later models (VAXstation 4000 comes to mind) have a so-called diagnostic timer with a better precision. Thus when BSD was ported to VAX, there was no choice but have HZ=100. And when it was ported to other platforms (such as hp300), that value was kept because there was no good reason to change it. The value of hz became adjustable because some hardware came with clocks which required a power-of-two divider, such as the 4.4BSD pmax port which had HZ=64. And of course, later, alpha was architected to have a 1024Hz timer, so HZ=1024 on these systems as well.
Re: tpm(4): don't use tvtohz(9)
> Date: Wed, 13 Jan 2021 21:39:37 -0600 > From: Scott Cheloha > > On Fri, Jan 08, 2021 at 08:21:14PM +0100, Florian Obser wrote: > > > > My x1 gen 2 seems to have a TPM 1.2 chip. Or can emulate one? > > The bios is confusing. I had it disabled until now. > > It seems to be able to suspend/resume just fine with this. > > > > It shows up like this: > > > > tpm0 at acpi0 TPM_ addr 0xfed4/0x5000, device 0x104a rev 0x4e > > > > No idea what this does, I'm going to disable it again, but let me know > > if you want further tests. > > kettenis, jcs: Is this sufficient? Or do I need more tests? Good enough for me.
