Hi Subrata, In terms of GTP4.D, you don’t need to configure GTP-U tunnel. The following configuration should be ok.
vppctl sr policy add bsid <GTP4.D Locator> next <SID0> next <SID1> vppctl sr policy add bsid <Binding SID> behavior t.m.gtp4.d <GTP4.D Locator> v6src_prefix <IPv6 source prefix> nhtype ipv4 vppctl sr steer l3 <GTP-U destination address>/32 via bsid <Binding SID> In terms of GTP-U destination address in sr steering configuration, this destination address should not be a part of VPP container address. When VPP receives GTP-U packet with a given destination address, this packet is routed to GTP4.D plugin module. Then GTP4.D plugin module can translate GTP-U packet into SRv6 packet. In the above case, Binding SID is pointing to a specific SR Policy. Then GTP4.D plugin module is using GTP4.D locator (IPv6 prefix) in order to generate the SID for GTP4.D and also using <IPv6 Source prefix> in order to generate the IPv6 source address which is used for SRv6 packet. Also, if having another policy corresponding to GTP4.D Locator, GTP4.D plugin module can specify other SIDs when translating GTP-U to SRv6. Here is the sample configuration. # vppctl sr policy add bsid D4:: next D2:: next D3:: # vppctl sr policy add bsid D5:: behavior t.m.gtp4.d D4::/32 v6src_prefix C1::/64 nhtype ipv4 # vppctl sr steer l3 172.20.0.1/32 via bsid D5:: Thanks, Tetsuya > On Jul 24, 2021, at 1:06 AM, Subrata Nath <subratanat...@gmail.com> wrote: > > Hi, > I am trying the configuration for the GTP_U to SRv6 function T.M.GTP4.D. > > Here is my setup > > Trex container -------- > VPP Container ----->SrV6 end point containers > GTP-U pkt > > The VPP container has two interfaces provided by K8s IPVLAN CNI. One is with > Ipv6 address and the other one is IPv4 which is in the same subnet as the > Trex container interface. > > GTP tunnel is created between the interfaces of Trex and IPv4 interface of > VPP container. > > command => vppctl create gtpu tunnel src <Trex Ipv4 addr> dst <VPP container > ipv4 addr> teid 13 > > "vppctl show int addr" shows all the interfaces including gtp tunnel > interface is UP. > > Now created the SR policy rule- > command_1 => vppctl sr policy add bsid fcf0:12::109 next fcf0:12::100 next > fcf0:12::101 next fcf0:12::104:0E01:2042:D:1 behavior t.m.gtp4.d > fcf0:12::104/64 v6src_prefix fcf0:12::109/64 nhtype ipv4 > > command2 => vppctl sr steer l3 <local ipv4 IP of VPP>/32 via bsid fcf0:12::109 > > command3 => vppctl set sr encaps source addr fcf0:12::109 > > Here fcf0:12::109 is the local sid of VPP container. fcf0:12::100/64 and > fcf0:12::101/64 are the intermediate SIDs of the SRv6 end points. > fcf0:12::104:0E01:2042:D:1 is the final destination SID. > As per https://docs.fd.io/vpp/20.05/d7/d3c/srv6_mobile_plugin_doc.html > <https://docs.fd.io/vpp/20.05/d7/d3c/srv6_mobile_plugin_doc.html>, its coded > as destination prefix fcf0:12::104/64 followed by destination ipv4 ip, > Teid(13=0xD) and QFI. > > From VPP container, "ip -6 route" is executed to the SID of the next endpoint > fcf0:12::100 over the ipv6 subnet. > > Issue is when GTP-U packet with outer IP address as VPP destination ipv4 > address is sent through Trex container, it reaches VPP but VPP is not > de-encapsulating GTP-U pkt received and sent over the SRv6 network. > > Can anyone pls let me know what is missing in the commands. > > VPP version v21.06-release. > > Regards, > Subrata > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#19865): https://lists.fd.io/g/vpp-dev/message/19865 Mute This Topic: https://lists.fd.io/mt/84417565/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
