Hi Andrea,

Typically a tunnel used for tx/rx of L3/IP payload would have IP address and 
optionally table-id set on the interface.  It will then allow packets to be 
routed into the tunnel for tx and, for rx packets, forward the payload IP 
packets using the correct fib-index.

I see that you are inserting FIB entries for tx to the tunnel. Then, you also 
need to enable the tunnel for IP forwarding on rx packets. The functions for it 
is ip4_sw_interface_enable_disable() or ip6_sw_interface_enable_disable() from 
ip4.h and ip6.h respectively.  If routine for IP into and from the tunnel is 
other than the global table, you still need to set tunnel interface with the 
desired table index and the programmed FIB entries.

Regards,
John

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Andreas Schultz
Sent: Thursday, January 25, 2018 11:34 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Howto implement L3 p2p tunnel interface without assigning IP 
to the interface?

Hi,

Short story:

The VPP tunnel implementation HOWTO [1] says that a L3 tunnel needs an IP 
address. How do I implement a P2P tunnel interface without assigning an IP 
address to it?

Long story:

I'm implementing a GTP-U User Plane Node that conforms to 3GPP TS 29.244 [2] & 
[3]. For each Sx Session a VPP tunnel interface is created (a Sx Session can 
consist of multiple GTP tunnels that all belong to the same UE IP). A reverse 
route for the UE IP is inserted into the FIB pointing to the session tunnel 
interface.
So far this all works nicely. However when a GTP-U packet arrives, a trace 
shows that it is decapsulated, handed to ip4-input and the immediatly dropped 
without any error indication:

00:00:59:474894: ip4-udp-lookup
  UDP: src-port 2152 dst-port 2152
00:00:59:474902: gtpu4-input
  GTPU decap from gtpu_session0 teid 1 next 1 error 0
00:00:59:474942: ip4-input
  ICMP: 10.180.125.105 -> 8.8.8.8
    tos 0x00, ttl 63, length 84, checksum 0xa484
    fragment id 0xfef7, flags DONT_FRAGMENT
  ICMP echo_request checksum 0xc7d
00:00:59:475013: ip4-drop
    ICMP: 10.180.125.105 -> 8.8.8.8
      tos 0x00, ttl 63, length 84, checksum 0xa484
      fragment id 0xfef7, flags DONT_FRAGMENT
    ICMP echo_request checksum 0xc7d
00:00:59:475020: error-drop
  ip4-input: valid ip4 packets
I have traced the cause of the drop to vnet_feature_arc_start and from there to 
vnet_get_config_data. It turns out the IP feature is not configured on the 
ARC/sw_if_index combination.
When I manually add a IP address to the tunnel interface it starts to work.

I already looked at the PPPoE and the IPSec plugins, They must be doing 
something simmilar, but I can't spot the difference.

So how do I get the tunnel interface to work without having to add an IP 
address to it? Or, do I need to handle the input/decap chain differently?

My current code is at: 
https://github.com/RoadRunnr/vpp/tree/feature/gtp-dp/src/plugins/gtpdp

Thanks
Andreas

1: https://wiki.fd.io/view/VPP/How_to_add_a_tunnel_encapsulation
2: https://github.com/RoadRunnr/vpp/tree/feature/gtp-dp
3: 
http://www.etsi.org/deliver/etsi_ts/129200_129299/129244/14.01.00_60/ts_129244v140100p.pdf

_______________________________________________
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Reply via email to