1. 18 Dec, 2018 1 commit
  2. 16 Dec, 2018 1 commit
    • Ondřej Zajíček's avatar
      BGP: Extend 'next hop keep' and 'next hop self' options · 1cab2b4a
      Ondřej Zajíček authored
      Extend 'next hop keep' and 'next hop self' options to have boolean values
      (enabled / disabled) and also values 'ibgp'/ 'ebgp' to restrict it to
      routes received from IBGP / EBGP. This allows to have it enabled by
      default in some cases, matches features of other implementations, and
      allows to handle some strange cases like EBGP border router with 'next
      hop self' also doing IBGP route reflecting.
      
      Change default of 'next hop keep' to enabled for route servers, and
      'ibgp' for route reflectors.
      
      Update documentation for these options.
      1cab2b4a
  3. 12 Dec, 2018 2 commits
  4. 06 Dec, 2018 1 commit
    • Maria Matejka's avatar
      Custom route attributes · 265419a3
      Maria Matejka authored
      For local route marking purposes, local custom route attributes may be
      defined. These attributes are seamlessly stripped after export filter to
      every real protocol like Kernel, BGP or OSPF, they however pass through
      pipes. We currently allow at most 256 custom attributes.
      
      This should be much faster than currently used bgp communities
      for marking routes.
      265419a3
  5. 04 Dec, 2018 1 commit
    • Ondřej Zajíček's avatar
      Unix: Change debugging options · 3fda08e4
      Ondřej Zajíček authored
      The old behavior was that enabling debugging did many nontrivial changes
      in BIRD behavior. The patch changes it that these changes are generally
      independent. Compiling with --enable-debug now just enables compile-time
      debug macros, but do not automatically activate debug mode (-d) nor local
      mode (-l). Debug mode with output to file (-D) do not force foreground
      mode (-f), therefore there is no need for backgroud option (-b), which is
      removed. Also fixes a bug when the default log target in -D mode was
      stderr instead of given debug file.
      3fda08e4
  6. 21 Nov, 2018 1 commit
  7. 05 Nov, 2018 1 commit
  8. 24 Aug, 2018 1 commit
  9. 21 Aug, 2018 1 commit
  10. 07 Aug, 2018 1 commit
  11. 31 Jul, 2018 1 commit
  12. 24 May, 2018 1 commit
    • Ondřej Zajíček's avatar
      Do not initialize route metrics in import_control hook · feae132e
      Ondřej Zajíček authored
      During route export, the receiving protocol often initialized route
      metrics to default value in its import_control hook before export filter
      was executed. This is inconsistent with the expectation that an export
      filter would process the same route as one in the routing table and it
      breaks setting these metrics before (e.g. for static routes directly in
      static protocol).
      
      The patch removes the initialization of route metrics in import_control
      hook, the default values are already handled in rt_notify hook called
      after export filters.
      
      The patch also changed the behavior of OSPF to keep metrics when a route
      is reannounced between OSPF instances (to be consistent with other
      protocols) and the behavior when both ospf_metric1 and ospf_metric2
      are specified (to have more expected behavior).
      feae132e
  13. 03 May, 2018 1 commit
    • Ondřej Zajíček's avatar
      Babel: Add option to randomize router ID · 70fab178
      Ondřej Zajíček authored
      When a Babel node restarts, it loses its sequence number, which can cause
      its routes to be rejected by peers until the state is cleared out by other
      nodes in the network (which can take on the order of minutes).
      
      There are two ways to fix this: Having stable storage to keep the sequence
      number across restarts, or picking a different router ID each time.
      
      This implements the latter, by introducing a new option that will cause
      BIRD to randomize a high 32 bits of router ID every time it starts up.
      This avoids the problem at the cost of not having stable router IDs in
      the network.
      
      Thanks to Toke Hoiland-Jorgensen for the patch.
      70fab178
  14. 03 Apr, 2018 2 commits
  15. 24 Mar, 2018 1 commit
  16. 21 Mar, 2018 1 commit
  17. 17 Mar, 2018 2 commits
  18. 08 Mar, 2018 1 commit
  19. 16 Jan, 2018 1 commit
  20. 09 Jan, 2018 1 commit
  21. 03 Jan, 2018 1 commit
  22. 21 Dec, 2017 1 commit
  23. 13 Dec, 2017 1 commit
  24. 10 Dec, 2017 2 commits
  25. 08 Dec, 2017 1 commit
  26. 07 Dec, 2017 2 commits
  27. 10 Oct, 2017 3 commits
  28. 13 Sep, 2017 1 commit
  29. 06 Sep, 2017 1 commit
    • Ondřej Zajíček's avatar
      Basic VRF support · 943478b0
      Ondřej Zajíček authored
      Add basic VRF (virtual routing and forwarding) support. Protocols can be
      associated with VRFs, such protocols will be restricted to interfaces
      assigned to the VRF (as reported by Linux kernel) and will use sockets
      bound to the VRF. E.g., different multihop BGP instances can use diffent
      kernel routing tables to handle BGP TCP connections.
      
      The VRF support is preliminary, currently there are several limitations:
      
      - Recent Linux kernels (4.11) do not handle correctly sockets bound
      to interaces that are part of VRF, so most protocols other than multihop
      BGP do not work. This will be fixed by future kernel versions.
      
      - Neighbor cache ignores VRFs. Breaks config with the same prefix on
      local interfaces in different VRFs. Not much problem as single hop
      protocols do not work anyways.
      
      - Olock code ignores VRFs. Breaks config with multiple BGP peers with the
      same IP address in different VRFs.
      
      - Incoming BGP connections are not dispatched according to VRFs.
      Breaks config with multiple BGP peers with the same IP address in
      different VRFs. Perhaps we would need some kernel API to read VRF of
      incoming connection? Or probably use multiple listening sockets in
      int-new branch.
      
      - We should handle master VRF interface up/down events and perhaps
      disable associated protocols when VRF goes down. Or at least disable
      associated interfaces.
      
      - Also we should check if the master iface is really VRF iface and
      not some other kind of master iface.
      
      - BFD session request dispatch should be aware of VRFs.
      
      - Perhaps kernel protocol should read default kernel table ID from VRF
      iface so it is not necessary to configure it.
      
      - Perhaps we should have per-VRF default table.
      943478b0
  30. 30 Aug, 2017 2 commits
  31. 09 Jun, 2017 1 commit
  32. 26 Apr, 2017 1 commit