OSPFv3-AF can handle multiple topologies of diferent address families
(IPv4, IPv6, both unicast and multicast) using separate instances
distinguished by instance ID ranges.
Adapt the naming conventions to be a bit closer to the other protocols.
proto_radv -> radv_proto
struct radv_proto *ra -> struct radv_proto *p
struct proto *p -> struct proto *P
Adapt the naming conventions to be a bit closer to the other protocols.
proto_radv -> radv_proto
struct radv_proto *ra -> struct radv_proto *p
struct proto *p -> struct proto *P
Add proper support for per-nexthop onlink flag in routes to handle next
hop addresses that are not covered by interface IP ranges. Supported by
kernel and static protocols.
Thanks to Vincent Bernat for the idea.
The subtlv parsing code was doing byte-based arithmetic with non-void pointers,
causing it to read beyond the end of the packet.
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
RFC6126bis formally introduces sub-TLVs to the Babel protocol, including
mandatory sub-TLVs. This adds support for parsing sub-TLVs to the Babel
protocol and skips TLVs that contain mandatory sub-TLVs, as per the spec.
For details, see section 4.4 of
https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis-02
Thanks to Toke Høiland-Jørgensen <toke@toke.dk> for the patch.
Previously, the Babel protocol would never use prefix compression on outgoing
updates (but would parse it on incoming ones). This adds compression of IPv6
addresses of outgoing updates.
The compression only works to the extent that the FIB is walked in lexicographic
order; i.e. a prefix is only compressed if it shares bytes with the previous
prefix in the same packet.
Thanks to Toke Høiland-Jørgensen <toke@toke.dk> for the patch.
This adds support for dual-stack v4/v6 operation to the Babel protocol.
Routing messages will be exchanged over IPv6, but IPv4 routes can be
carried in the messages being exchanged. This matches how the reference
Babel implementation (babeld) works.
The nexthop address for v4 can be configured per interface, and will
default to the first available IPv4 address on the given interface. For
symmetry, a configuration option to configure the IPv6 nexthop address
is also added.
Thanks to Toke Høiland-Jørgensen <toke@toke.dk> for the patch.
Covers IPv4/VPNv4 routes with IPv6 next hop (RFC 5549), IPv6 routes with
IPv4 next hop (RFC 4798) and VPNv6 routes with IPv4 next hop (RFC 4659).
Unfortunately it also makes next hop hooks more messy.
Each BGP channel now could have two IGP tables, one for IPv4 next hops,
the other for IPv6 next hops.
Basic support for SAFI 4 and 128 (MPLS labeled IP and VPN) for IPv4 and
IPv6. Should work for route reflector, but does not properly handle
originating routes with next hop self.
Based on patches from Jan Matejka.
When a BGP session with ADD_PATH is restarted and the neighbor do not
announce ADD_PATH capability during reconnect, the accept_ra_types is
still set to RA_ANY.
Thanks to Lennert Buytenhek for the bugreport
The patch fixes several bugs introduced in previous changes, simplifies
the protocol by handing routes uniformly, introduces asynchronous route
processing to avoid issues with separate notifications for each next-hop
in ECMP routes, and makes reconfiguration faster by avoiding quadratic
complexity.
During reconfiguration, old and new filter expressions in static routes
are compared using i_same() function. When filter expressions contain
function calls, it is necessary that old filter expressions are the
second argument in i_same(), as it is internally modified by i_same().
Otherwise pointers to old (and freed) data appear in the config
structure.
Thanks to Lennert Buytenhek for tracking and reporting the bug.
Dropped struct mpnh and mpnh_*()
Now struct nexthop exists, nexthop_*(), and also included struct nexthop
into struct rta.
Also converted RTD_DEVICE and RTD_ROUTER to RTD_UNICAST. If it is needed
to distinguish between these two cases, RTD_DEVICE is equivalent to
IPA_ZERO(a->nh.gw), RTD_ROUTER is then IPA_NONZERO(a->nh.gw).
From now on, we also explicitely want C99 compatible compiler. We assume
that this 20-year norm should be known almost everywhere.
