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 <[email protected]>
---
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
From: Ahmed Abdelsalam <[email protected]>
Date: Sat, 25 Aug 2018 16:15:41 +0200
> This patch makes sure that "rt_gateway" has the value of
> the next-hop configured from the control plane.
You can't change the rt_gateway field of an existing route,
this will change the value for unrelated users trying to
reach the same destination.