1. 13 Feb, 2019 1 commit
  2. 09 Feb, 2019 2 commits
  3. 05 Feb, 2019 2 commits
    • Ondřej Zajíček's avatar
      Nest: Improve export counter handling · 6e8fb668
      Ondřej Zajíček authored
      One of previous workarounds for phantom route avoidance breaks export
      counters by expanding sending of spurious withdraws, which are send when
      we are not sure whether we have advertised that routes in the past.
      If not, then export counter is decreased, but it was not increased
      before, so it overflows under zero.
      
      The patch fixes that by sendung spurious withdraws, but not counting them
      on export counter. That may lead to error in the other direction, but that
      happens only as a race condition (i.e., in normal operation filters
      return proper values about old route export state).
      6e8fb668
    • Ondřej Zajíček's avatar
      Nest: Report preferred counters also when 'import keep filtered' is enabled · 52fdd1cb
      Ondřej Zajíček authored
      Thanks to Michal Nowak for reporting the issue.
      52fdd1cb
  4. 03 Feb, 2019 4 commits
  5. 02 Feb, 2019 1 commit
  6. 01 Feb, 2019 1 commit
  7. 31 Jan, 2019 4 commits
  8. 30 Jan, 2019 1 commit
    • Ondřej Zajíček's avatar
      Nest: Prevent withdraws from propagation back to source protocol · e84c81b7
      Ondřej Zajíček authored
      The earlier fix loosen conditions for not running filters on old
      route when deciding about route propagation to a protocol to avoid
      issues with ghost routes in some race conditions.
      
      Unfortunately, the fix also caused back-propagation of withdraws. For
      regular updates, back-propagation is prevented in import_control hooks,
      but these are not called on withdraws. For them, import_control hooks
      are called on old routes instead, changing (old, NULL) notification
      to (NULL, NULL), which is ignored. By not calling export processing
      in some cases, the withdraw is not ignored and is back-propagated.
      
      This patch fixes that by contract conditions so the earlier fix is not
      applied to back-propagated updates.
      e84c81b7
  9. 26 Jan, 2019 3 commits
  10. 24 Jan, 2019 1 commit
  11. 17 Jan, 2019 1 commit
  12. 05 Jan, 2019 1 commit
  13. 04 Jan, 2019 2 commits
  14. 03 Jan, 2019 1 commit
    • Ondřej Zajíček's avatar
      Doc: README and INSTALL update · 4d9049dc
      Ondřej Zajíček authored
      Minor cleanups, updates and clarifications. Also removes (incomplete
      and well-known) build steps from README, as they are better described
      in INSTALL.
      4d9049dc
  15. 02 Jan, 2019 2 commits
    • Ondřej Zajíček's avatar
      BGP: Better dispatch of incoming connections · 470740f9
      Ondřej Zajíček authored
      Since v2 we have multiple listening BGP sockets, and each BGP protocol
      has associated one of them. Use listening socket that accepted the
      incoming connection as a key in the dispatch process so only BGP
      protocols assocaited with that listening socket can be selected.
      This is necesary for proper dispatch when VRFs are used.
      470740f9
    • Ondřej Zajíček's avatar
      BGP: Postpone setting link_addr · e16b0aef
      Ondřej Zajíček authored
      It may happen that the LLv6 address for given iface is not defined during
      BGP start, so we postpone the check to the the session establishment.
      e16b0aef
  16. 28 Dec, 2018 1 commit
  17. 18 Dec, 2018 4 commits
  18. 17 Dec, 2018 1 commit
    • Ondřej Zajíček's avatar
      OSPF: Fix wrong LSA collisions detection · cea2e25f
      Ondřej Zajíček authored
      In some circumstances (old LSA flushed but not acknowledged and not
      removed) origination of a new LSA may wrongly triggers LSA collision
      code. The patch fixes that.
      
      Thanks to Asbjorn Mikkelsen for the bugreport and @mdelagueronniere
      for the original patch.
      cea2e25f
  19. 16 Dec, 2018 4 commits
  20. 14 Dec, 2018 2 commits
  21. 12 Dec, 2018 1 commit
    • Ondřej Zajíček's avatar
      BGP: Do not prepend ASN in export from non-RS EBGP to RS EBGP · 532116e7
      Ondřej Zajíček authored
      When route is exported to regular EBGP, local ASN should be prepended to
      AS_PATH. When route is propagated by route server (between RS-marked
      EBGP peers), it should not change AS_PATH. Question is what to do in
      other cases (from non-RS EBGP, IBGP, or locally originated to RS EBGP).
      
      In 1.6.x, we did not prepend ASN in non-RS EBGP or IBGP to RS EBGP, but
      we prepended in local to RS EBGP.
      
      In 2.0.x, we changed that so only RS-EBGP to RS-EBGP is not prepended.
      We received some negative responses (thanks to heisenbug and Alexander
      Zubkov), we decided to change it back. One reason is that it is simple
      to modify the AS_PATH by filters, but not possible to un-modify
      changes done by BGP itself. Also, as 1.6.x behavior was not really
      consistent, the final behavior is that ASN is never prepended when
      exported to RS EBGP, like to IBGP.
      
      Note that i do not express an opinion about whether such configurations
      are even reasonable.
      532116e7