ospfd: fix behavior of +/-metric

OSPFD uses -1 as a sentinel value for uninitialized metrics. When
applying a route map with a +/-metric to redistributed routes, we were
using -1 as our base value to increment or decrement on, which meant
that if you set e.g. +10, you would end up with a redistributed route of
metric 9.

This patch also removes an off-by-one sanity check that would cause a
set metric +1 or set metric 0 to result in a metric value of 20 :-)

Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>

1 files changed, 0 insertions, 6 deletions

diff --git a/ospfd/ospf_lsa.c b/ospfd/ospf_lsa.c
index c9710e9165..e38193cffc 100644
--- a/ospfd/ospf_lsa.c
+++ b/ospfd/ospf_lsa.c
@@ -1499,12 +1499,6 @@ struct in_addr ospf_get_nssa_ip(struct ospf_area *area)
 	return fwd;
 }
 
-#define DEFAULT_DEFAULT_METRIC	             20
-#define DEFAULT_DEFAULT_ORIGINATE_METRIC     10
-#define DEFAULT_DEFAULT_ALWAYS_METRIC	      1
-
-#define DEFAULT_METRIC_TYPE		     EXTERNAL_METRIC_TYPE_2
-
 int metric_type(struct ospf *ospf, uint8_t src, unsigned short instance)
 {
 	struct ospf_redist *red;