Hi Andreas, There are binary API equivalent messages to the CLI commands I gave. For a non-interface based encap scheme you could reference as an example src/vnet/udp/udp_encap.[ch]. Not having an interface means there is no attachment point for features (like ACLs, NAT, etc) and you’ll need a do-it-yourself stats scheme.
/neale From: Andreas Schultz <andreas.schu...@travelping.com> Date: Friday, 26 January 2018 at 13:55 To: "Neale Ranns (nranns)" <nra...@cisco.com> Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, Ole Troan <otr...@employees.org> Subject: Re: [vpp-dev] Howto implement L3 p2p tunnel interface without assigning IP to the interface? Hi Neale, Neale Ranns (nranns) <nra...@cisco.com<mailto:nra...@cisco.com>> schrieb am Fr., 26. Jan. 2018 um 11:27 Uhr: Hi Andreas, Ip[46]_sw_interface_enable_disable() are the internal APIs that enable/disable IP forwarding on an interface. There is an equivalent MPLS one too. The commands I listed previously are external means by which these internal APIs are invoked. It would not be acceptable to use these APIs to automatically IP enable GTP interfaces on interface creation. The tunnels are not static, they are create through a management protocol over the 3GPP Sx reference point. Having to add manual configuration steps to make the tunnels work is not acceptable. So I have to use API's to setup things the ways I need them. I'm not really sure the interface model is even correct my use case. I don't need to support L2 forwarding, so L2 bridging argument from the Wiki article does not apply. Regards, Andreas Regards, neale From: Andreas Schultz <andreas.schu...@travelping.com<mailto:andreas.schu...@travelping.com>> Date: Thursday, 25 January 2018 at 23:47 To: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" <vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>> Cc: "Neale Ranns (nranns)" <nra...@cisco.com<mailto:nra...@cisco.com>>, Ole Troan <otr...@employees.org<mailto:otr...@employees.org>> Subject: Re: [vpp-dev] Howto implement L3 p2p tunnel interface without assigning IP to the interface? Ole Troan <otr...@employees.org<mailto:otr...@employees.org>> schrieb am Do., 25. Jan. 2018 um 22:07 Uhr: > Not accepting IP[46] packets on any interface type that is not IP[46] enabled > is a basic security feature. To IP4 enable an interface you have two option; > 1) Assign it an IP address > 2) Make it IP unnumbered to another interface that does have an > address, e.g. > set int ip addr loop0 some-private-addr/32 > set int unnumbered gtpu-tunnel-0 use loop0 > set int unnumbered gtpu-tunnel-1 use loop0 > set int unnumbered gtpu-tunnel-2 use loop0 > etc… > It doesn’t have to be a loopback, I use that only as an example. > > To IP6 enable an interface instead of the unnumbered trick one can just do; > 1) enable ip6 interface gtpu-tunnel0 Although all IPv6 interfaces by definition have an IPv6 address (the IPv6 link-local) I do wonder if we shouldn't allow for IP processing to be enabled for both IP4 and IP6 independently of having an address configured. (Of course that would imply that some protocols wouldn't work.) ip4_sw_interface_enable_disable() and/or ip6_sw_interface_enable_disable() did the trick. It works now without having to use the unnumbered option or having to assign a IPv4 address. I didn't check IPv6, though. Thanks for the help, Andreas Cheers, Ole
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
