Hi Mukesh,
I am by no means an expert on the matter but after talking to some folks
my understanding is that it is a common feature (uRPF).
This issue has nothing to do with IPsec though, I am pretty sure you
could reproduce the issue with other tunnels too.
Note that uRPF would apply to packets with local destination, in this
case the inner address is also the interface address.
I think it makes sense that the packet was drop given that we did not
have any default route.
Thanks,
Sergio
On 09/09/2017 10:44, Mukesh Yadav (mukyadav) wrote:
HI Sergio,
Thanks with changes as below, IPSec worked in tunnel mode as well.
Is this restriction right?
i.e dropping packet in Rx processing if there is no route for Source IP.
In normal linux machine we simply process the packet and in TX we 1st Make a
packet and then route matter when we do forward.
Specially in IPSec use-case, why should route of Inner Source IP matter at all.
It’s anyway going to be encrypted and sent across.
Route of Outer IP is what shall matter, not the Inner Peer IP in tunnel mode.
Thanks
Mukesh
On 07/09/17, 5:55 PM, "Sergio Gonzalez Monroy"
<sergio.gonzalez.mon...@intel.com> wrote:
Hi Mukesh,
I think the problem is that we do not have fib entry for 1.1.1.1 network.
I guess there are different ways to fix the issue, I did the following
(already updated interface name to match your config):
set ip arp GigabitEthernet0/8/0 2.2.2.254 be:ef:00:00:00:02
ip route add 1.1.1.0/24 via 2.2.2.254 GigabitEthernet0/8/0
Let me know if it does the trick.
Thanks,
Sergio
_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev
