Fix use of lookup_next_index in LISP src/dst FIB

Adjacencies in LISP src/dst FIB store the index of the LISP output
interface (next node after lookup) in the lookup_next_index. Since the
values of interface node indexes are not constrained, they can collide
with the 'special' adjacencies IP_LOOKUP_NEXT_LOCAL and
IP_LOOKUP_NEXT_DROP. As a result, at allocation time, LISP ajacencies
may be automatically shared with the previous two, predefined
adjacencies and all LISP specific state stored in the rewrite area is
lost.

This fixes the problem by 'hijacking' the explicit_fib_index instead
of the lookup_next_index field.

Change-Id: I3c59121dcf0851decf5c08004143d1201dbd1ece
Signed-off-by: Florin Coras <fcoras@cisco.com>

1 files changed, 7 insertions, 2 deletions

diff --git a/vnet/vnet/lisp-gpe/lisp_gpe.c b/vnet/vnet/lisp-gpe/lisp_gpe.c
index 35e16bbcf7c..f594e927ea8 100644
--- a/vnet/vnet/lisp-gpe/lisp_gpe.c
+++ b/vnet/vnet/lisp-gpe/lisp_gpe.c
@@ -243,7 +243,11 @@ vnet_lisp_gpe_add_del_fwd_entry (vnet_lisp_gpe_add_del_fwd_entry_args_t * a,
   /* setup adjacency for eid */
   memset (&adj, 0, sizeof(adj));
   adj.n_adj = 1;
-  adj.explicit_fib_index = ~0;
+
+  /* fill in lookup_next_index with a 'legal' value to avoid problems */
+  adj.lookup_next_index = (ip_ver == IP4) ?
+          lgm->ip4_lookup_next_lgpe_ip4_lookup :
+          lgm->ip6_lookup_next_lgpe_ip6_lookup;
 
   if (a->is_add)
     {
@@ -261,7 +265,8 @@ vnet_lisp_gpe_add_del_fwd_entry (vnet_lisp_gpe_add_del_fwd_entry_args_t * a,
       ASSERT(lookup_next_index != 0);
       ASSERT(lgpe_sw_if_index != 0);
 
-      adj.lookup_next_index = lookup_next_index[0];
+      /* hijack explicit fib index to store lisp interface node index */
+      adj.explicit_fib_index = lookup_next_index[0];
       adj.rewrite_header.node_index = tun_index;
       adj.rewrite_header.sw_if_index = lgpe_sw_if_index[0];
     }