Soheil, Others my correct me, but as far as I know IPv4 options are for all practical purposes deprecated. Lots of forwarding planes do a validation check of 0x45 on the first octet. Likewise for middleboxes (e.g. NAT). Have you tried if you can get these packets passed any routers / across the Internet?
Not impossible to change the IP4 VPP path, although it would require fixing all
code that finds the L4 header. But I think you would end up in horrific
deployment issues...
Cheers,
Ole
> On 29 Jun 2017, at 02:21, Soheil Abbasloo <ab.soh...@gmail.com> wrote:
>
> Hi all,
>
> This is Soheil. We are working on a project involving the IPv4 In-Band OAM.
>
> I have tried to use VPP in a simple scenario (like the simple
> switching/routing tutorial in fd.io) to pass IPv4-Options (in out case
> TIMESTAMP option) between two containers. However, packets having IP-Option
> field will be dropped by VPP due to the checksum error.
>
> I have checked the source code (17.04) and found that VPP only handles fixed
> 20 Bytes IP headers (there is a header size check in ipv4-input node
> {<>!=0x45}). Which might indicate that VPP doesn't handle IP-options; hence
> the source of wrong checksum calculations in VPP.
>
> So is there any plan for support IPv4-Option fields in VPP? Is there any
> reason for not supporting it?! Or maybe I'm doing something wrong, can you
> please tell me what I have missed here?
>
> (
> Just a few things:
> 1- I have checked checksum calculations in my server where I insert
> IP-options and they are fine!
> 2- When I don't insert options, everything is fine and packets can be
> received at client
> )
>
> Thanks,
> Soheil
> _______________________________________________
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
