[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20180825141541.960-1-amsalam20@gmail.com>
Date: Sat, 25 Aug 2018 16:15:41 +0200
From: Ahmed Abdelsalam <amsalam20@...il.com>
To: davem@...emloft.net, dlebrun@...gle.com, netdev@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, amsalam20@...il.com
Subject: [net-next] ipv6:sr: Use the right next-hop value for neighbor discovery in End.DX4
The SRv6 End.DX4 behaviour supports the use-case of L3VPN,
where a FIB lookup in a specific tenant table at the egress
PE is not required [1].
In the implementation of the behaviour, after the packet being
decapsulated, the lookup in the routing sub-system is done based
on next-hop specified form the control plane (using iproute2) or
the destination address of the packet.
However, the neighbour discovery process always fall back on the
destination address of the packet (in ip_finish_output2 ()),
if "rt_gateway" value is not present in the "struct rtable rt".
nexthop = (__force u32) rt_nexthop(rt, ip_hdr(skb)->daddr);
This patch makes sure that "rt_gateway" has the value of
the next-hop configured from the control plane.
The patch is tested for inner IPv4 packets having destination
address different from the next-hop configured using iproute2
[1] https://tools.ietf.org/html/draft-filsfils-spring-srv6-network-programming-05
Signed-off-by: Ahmed Abdelsalam <amsalam20@...il.com>
---
net/ipv6/seg6_local.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c
index 60325dbfe88b..d346f0d19c09 100644
--- a/net/ipv6/seg6_local.c
+++ b/net/ipv6/seg6_local.c
@@ -374,6 +374,8 @@ static int input_action_end_dx4(struct sk_buff *skb,
if (err)
goto drop;
+ ((struct rtable *)skb_dst(skb))->rt_gateway = nhaddr;
+
return dst_input(skb);
drop:
--
2.11.0
Powered by blists - more mailing lists