| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Note that recurrent timers are currently limited to ~1 hour.
|
|
|
|
|
|
|
|
|
|
|
|
Date/time output (e.g. in logs, show commands) can use %f to specify
subsecond time. By default, millisecond precision is used in output.
|
|
The old timer interface is still kept, but implemented by new timers. The
plan is to switch from the old inteface to the new interface, then clean
it up.
|
|
|
|
Also redesign preferred address selection and update protocols to use
appropriate preferred address.
Based on a previous work by Jan Maria Matejka.
|
|
|
|
|
|
The TTL check must be done after instance ID dispatch to avoid warnings
when a physical iface is shared by multiple instances and some use TTL
security and some not.
|
|
In such case, next hop has to be taken from Link-LSA like in broadcast
case, not from neighbor source address like in other PtP cases.
Also add some checks, comments and code cleanup.
|
|
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.
|
|
Lexer always parsed numbers as unsigned, but parser handled them as
signed and grammar contained many unnecessary checks for negativity.
|
|
|
|
|
|
|
|
|
|
Allow to define static roa/flow routes without dest.
|
|
Which, in contrast to SAFI 128, does not use MPLS labels.
|
|
When recursive routes with hybrid next hops (e.g. IPv6 route with IPv4 next
hop) are allowed, we need both IPv4 and IPv6 IGP tables.
|
|
|
|
|
|
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.
|
|
|
|
|
|
This may be useful if multple interfaces share the same network range.
Thanks to Fritz Grimpen for the original patch.
|
|
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.
|
|
|
|
|
