Hello,
proposed diff follows stuff discussed here [1] (pf route-to issues). I think
we've reached a consensus to change route-to/reply-to such the only supported
option will be next-hop (and list and table of next-hop addresses).
I think bluhm@ and dlg@ have committed part of that change
This diff changes two things:
- First, it move the kroute update into rde_generate_updates() simplifying
prefix_evaluate a little bit.
- Second, it changes prefix_evaluate to take an additional argument for the
old prefix (to be removed). Instead of doing this outside of
prefix_evaluate() with
Diff below moves `access_type' to the context structure passed down to
the various routines and fix a regression introduced in a previous
refactoring.
`access_type' is overwritten for wired mapping and the value of
`enter_prot' is used instead.
ok?
Index: uvm/uvm_fault.c
Claudio Jeker(cje...@diehard.n-r-g.com) on 2021.01.12 10:07:57 +0100:
> On Wed, Jan 06, 2021 at 01:02:50PM +0100, Claudio Jeker wrote:
> > The code in ospf6d is a bit broken when it comes to point-to-point links.
> > This diff fixes this by a) using the neighbor address instead of the unset
> >
On Wed, Jan 06, 2021 at 01:02:50PM +0100, Claudio Jeker wrote:
> The code in ospf6d is a bit broken when it comes to point-to-point links.
> This diff fixes this by a) using the neighbor address instead of the unset
> interface destination address and by b) matching the incomming packet
> against
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
