Re: [vpp-dev] Crash when using dns_name_server

[Dave Barach via Lists.Fd.Io]

I am trying to use DNS server and on "ping google.com" VPP is crashing

Color me unsurprised. Please fix your configuration, to the point where 
first-order obvious errors have been eliminated. It looks to me like the 
"binary-api dns_name_server_add_del 8.8.8.8" command has been truncated:


Aug 13 21:31:10 test1-vpp vnet[853]: unknown input `add_del 8.8.8.8
Aug 13 21:31:28 test1-vpp vnet[853]: dns cache: add / del / clear required..
Aug 13 21:31:36 test1-vpp vnet[853]:
vl_api_dns_resolve_name_reply_t_handler:2556: ip4 address 23.75.7.244
Aug 13 21:32:24 test1-vpp vnet[853]: dns cache: add / del / clear required..
Aug 13 21:34:43 test1-vpp vnet[853]: resolve_event:247: name server 8.8.8.8 
backfire

Here is the config that I use on my home gateway.

uncomment { nat44 add identity mapping external GigabitEthernet3/0/0 udp 53053 }
uncomment { bin dns_name_server_add_del 8.8.8.8 }
uncomment { bin dns_enable_disable }

$ ping google.com # on my desktop, behind the vpp gateway
PING google.com (172.217.7.174) 56(84) bytes of data.
64 bytes from 172.217.7.174 (172.217.7.174): icmp_seq=1 ttl=54 time=26.3 ms
64 bytes from 172.217.7.174 (172.217.7.174): icmp_seq=2 ttl=54 time=21.5 ms

vpp# sh dns cache
weatherlink.com -> weatherlink.com: 54.172.164.1 [21338]   TTL left 489.9
xxl.trane.com -> xxl.trane.com: 168.65.229.203 [781]   EXPIRED
google.com -> google.com: 172.217.7.174 [189]   TTL left 552.1
www.google.com -> www.google.com: 172.217.164.164 [189]   TTL left 569.6
dns.msftncsi.com -> dns.msftncsi.com: 131.107.255.255 [15]   TTL left 569.9
kv801-prod.do.dsp.mp.microsoft.com -> kv801-prod.do.dsp.mp.microsoft.com: 
23.67.120.218 [19]   TTL left 571.7
geo-prod.do.dsp.mp.microsoft.com -> geo-prod.do.dsp.mp.microsoft.com: 
40.69.221.239 [121]   TTL left 571.1
outlook.office365.com -> outlook.office365.com: 52.96.62.226 [38]   TTL 
left 571.5
174.7.217.172.in-addr.arpa -> 174.7.217.172.in-addr.arpa:   TTL left 573.6
client.wns.windows.com -> client.wns.windows.com: 52.242.211.89 [299]   TTL 
left 574.1
www.nr-extensions.tk -> www.nr-extensions.tk: 165.22.1.78 [190]   TTL left 
589.7
ip-api.com -> ip-api.com: 147.135.15.186 [99]   TTL left 589.9
www.instagram.com -> www.instagram.com: 31.13.65.174 [59]   TTL left 590.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13779): https://lists.fd.io/g/vpp-dev/message/13779
Mute This Topic: https://lists.fd.io/mt/32881233/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

回复: Re: [tsc] [vpp-dev] Project Proposal for uDPI

[Xingfu Li]

If this project will be used with VPP only, vDPI(vector DPI) is another choice.



李幸福/Xingfu Li
山东华辰泰尔信息科技股份有限公司/Shandong Huachentel Information Technology Co., Ltd.
山东省济南市高新区舜泰广场8号楼西区17层 250101/West of F17, Building 8 of Shuntai Square, 
High-tech Zone, Jinan, China 250101
电话/Tel：86-531-62325307 86-531-88877658-8019
网址/Web：www.huachentel.com
 
发件人： Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
发送时间： 2019-08-17 00:02
收件人： 李幸福(Xingfu Li); Ni, Hongjun; Alexey; t...@lists.fd.io
抄送： vpp-dev@lists.fd.io; Wang, Xiang W; Hong, Yang A; Chang, Harry; 
gu.ji...@zte.com.cn; Shan Jianghua; Zhang Yang; Wu Shuai; Xia Yuying; Fan 
Chenggang; ?? , \Liu Zhong\" , \"Zhao Yong\" 
, \"Chen Haiquan\" " 

主题： Re: Re: [tsc] [vpp-dev] Project Proposal for uDPI
> UDPI will be easily misunderstood as UDP+I. 
> uniDPI is ok?

+1 to uniDPI.

Vratko.



From: 李幸福(Xingfu Li) 
Sent: Tuesday, August 13, 2019 12:45
To: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco); Ni, Hongjun; 
Alexey; t...@lists.fd.io
Cc: vpp-dev@lists.fd.io; Wang, Xiang W; Hong, Yang A; Chang, Harry; 
gu.ji...@zte.com.cn; Shan Jianghua; Zhang Yang; Wu Shuai; Xia Yuying; Fan 
Chenggang; ?? , "Liu Zhong" , 
"Zhao Yong" , "Chen Haiquan" 
Subject: Re: Re: [tsc] [vpp-dev] Project Proposal for uDPI 
 
uniDPI is ok? 
UDPI will be easily misunderstood as UDP+I.



李幸福/Xingfu Li
山东华辰泰尔信息科技股份有限公司/Shandong Huachentel Information Technology Co., Ltd.
山东省济南市高新区舜泰广场8号楼西区17层 250101/West of F17, Building 8 of Shuntai Square, 
High-tech Zone, Jinan, China 250101
电话/Tel：86-531-62325307 86-531-88877658-8019
网址/Web：www.huachentel.com
 
From: Vratko Polak -X (vrpolak - PANTHEON TECHNOLOGIES at Cisco)
Date: 2019-08-13 18:34
To: Ni, Hongjun; Alexey; t...@lists.fd.io
CC: vpp-dev@lists.fd.io; Wang, Xiang W; Hong, Yang A; Chang, Harry; 
gu.ji...@zte.com.cn; Shan Jianghua; Zhang Yang; Li Xingfu; Wu Shuai; Xia 
Yuying; Fan Chenggang; Gao Feng; Liu Zhong; Zhao Yong; Chen Haiquan
Subject: Re: [tsc] [vpp-dev] Project Proposal for uDPI
>> uDPI

> microDPI 

Universal Deep Packet Inspection is the new project here.
Would it make sense to use UDPI as its abbreviation
(e.g. capital U, to distinguish from "micro")?

Vratko.



From: t...@lists.fd.io  on behalf of Ni, Hongjun 

Sent: Tuesday, August 13, 2019 03:47
To: Ni, Hongjun; Alexey; t...@lists.fd.io
Cc: vpp-dev@lists.fd.io; Wang, Xiang W; Hong, Yang A; Chang, Harry; 
gu.ji...@zte.com.cn; Shan Jianghua; Zhang Yang; Li Xingfu; Wu Shuai; Xia 
Yuying; Fan Chenggang; Gao Feng; Liu Zhong; Zhao Yong; Chen Haiquan
Subject: Re: [tsc] [vpp-dev] Project Proposal for uDPI 
 
Hi Alexey and all,
 
Alexey and I had a discussion offline.
It seems that we mentioned two different projects except the same project name.
 
The project Alexey mentioned is “microDPI packet inspection for network 
analytics”.
It is developed based on Machine Learning and Python language, using GPL3.0 
License.
Last activity for this project is 10.04.2017, which is 2 years ago. That is why 
Alexey said it is died.
It supports six specific protocols/applications.
 
The project we proposed here is “Universal Deep Packet Inspection”.
It is developed based on industry regex matching library, VPP, and C language, 
using Apache 2.0 License.
We plan to support most industry network protocols/applications.
 
Both have different scopes, features, implementations and Licenses.
 
Thanks,
Hongjun
 
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Ni, Hongjun
Sent: Friday, August 9, 2019 10:03 PM
To: Alexey ; t...@lists.fd.io
Cc: vpp-dev@lists.fd.io; Wang, Xiang W ; Hong, Yang A 
; Chang, Harry ; 
gu.ji...@zte.com.cn; Shan Jianghua ; Zhang Yang 
; Li Xingfu ; Wu Shuai 
; Xia Yuying ; Fan Chenggang 
; Gao Feng ; Liu Zhong 
; Zhao Yong ; Chen Haiquan 

Subject: Re: [vpp-dev] Project Proposal for uDPI
 
Hi Alexey,
 
Could you give some thoughts on this?
 
Thanks,
Hongjun
 
From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Alexey
Sent: Friday, August 9, 2019 6:54 PM
To: Ni, Hongjun ; t...@lists.fd.io
Cc: vpp-dev@lists.fd.io; Wang, Xiang W ; Hong, Yang A 
; Chang, Harry ; 
gu.ji...@zte.com.cn; Shan Jianghua ; Zhang Yang 
; Li Xingfu ; Wu Shuai 
; Xia Yuying ; Fan Chenggang 
; Gao Feng ; Liu Zhong 
; Zhao Yong ; Chen Haiquan 

Subject: Re: [vpp-dev] Project Proposal for uDPI
 
udpi is died
 
 
09.08.2019, 04:11, "Ni, Hongjun" :
Hello FD.io TSCs
 
Please accept this project proposal for uDPI for consideration.
https://wiki.fd.io/view/Project_Proposals/uDPI
 
So far, this project has 11 founders and 15 initial committers from
Intel, ZTE, China Telecom, HuachenTel, Inspur, Yxlink, Sunyainfo, Tencent, 
China Unicom, Huawei, QingCloud.
 
If possible, I would like to present this on TSC meeting.
 
Thanks,
Hongjun
,
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13684): https://lists.fd.io/g/vpp-dev/message/13684
Mute This Topic: https://lists.fd.io/mt/32805807/675634
Group Owner: vpp-dev+ow...@lists.fd.

Re: [vpp-dev] Crash when using dns_name_server

[Dave Wallace]

Hi Carlito,

The standard bug reporting practice is documented on the wiki [0].  
Alternatively, run your debug version of VPP in gdb and report the 
backtrace when vpp crashes.


Thanks,
-daw-

[0] https://wiki.fd.io/view/VPP/BugReports


On 8/16/2019 11:12 PM, carlito nueno wrote:

Hi Dave,

Thanks for the patch. I merged your edits and compiled a debug version
using stable/1908 as base.

Every time a make a ping request from a LAN device, VPP is restarting.
Sometimes vppctl just hangs, but when I do get into vppctl, if I run a
command (ex: sh nat44 address), VPP again restarts.

I know this information is not that helpful. Please let me know what
information you need and, I can also run more tests.

Thanks!


On Thu, Aug 15, 2019 at 12:20 PM Dave Barach via Lists.Fd.Io
 wrote:

See https://jira.fd.io/browse/VPP-1746, and 
https://gerrit.fd.io/r/c/vpp/+/21338 which fixes gross non-operation of the 
name resolver.



Process created on demand, with node index in the main_t. Needed to remove the 
static vlib_node_registration_t and use dm->resolver_process_node_index vs. 
unused_mumble_registration.node_index.



Passing 0 when signaling name resolution events couldn’t possibly work.



D.



From: vpp-dev@lists.fd.io  On Behalf Of Dave Barach via 
Lists.Fd.Io
Sent: Thursday, August 15, 2019 2:54 PM
To: anoopnairh...@gmail.com; vpp-dev@lists.fd.io
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Crash when using dns_name_server



Folks,



I’ll look at these issues. It would be helpful if people would contribute 
patches, or at least write Jira tickets. If we don’t know it’s broken, it won’t 
get fixed...



To level-set: the DNS name resolver has been lightly used. Nothing would 
surprise me at this point.



D.



From: vpp-dev@lists.fd.io  On Behalf Of 
anoopnairh...@gmail.com
Sent: Thursday, August 15, 2019 1:07 PM
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Crash when using dns_name_server



Hi Carlio,
 I had faced a similar crash with DNS module while resolving names.

The dns_cache_lock is in locked state after initialization. Because of this the first 
worker thread which attempts to take this lock will find it in "locked" state 
and spin forever. So the main thread panics when it tries for barrier sync.  Attached the 
patch which solved my problem

I could find couple of other issues in the DNS module and the patch has the fix 
for them as well.

 - DNS lock is not released while processing dns request -> causes deadlock

 - resolve a name from VAT when there is no server configured  -> crash due 
to a NULL pointer deference

 - delete_random_entry() is invoked while holding DNS lock -> a potential 
deadlock

Please check if it helps you.

thanks
Anoop

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13754): https://lists.fd.io/g/vpp-dev/message/13754
Mute This Topic: https://lists.fd.io/mt/32881233/675621
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [carlitonu...@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13771): https://lists.fd.io/g/vpp-dev/message/13771
Mute This Topic: https://lists.fd.io/mt/32881233/675079
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [dwallac...@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13777): https://lists.fd.io/g/vpp-dev/message/13777
Mute This Topic: https://lists.fd.io/mt/32881233/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] VPP 19.08 Release Notes - request for your review

[Andrew Yourtchenko]

Hi all,

As we are approaching the release date of the VPP 19.08 release, I
have prepared the release notes for it for your review:
https://gerrit.fd.io/r/#/c/vpp/+/21366/ - Feel free to have a look and
submit your edits, if any.

I plan to commit it at noon UTC on  Wednesday 21 August.

Thanks!

--a

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13776): https://lists.fd.io/g/vpp-dev/message/13776
Mute This Topic: https://lists.fd.io/mt/32923393/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] [tsc] Project Proposal for uDPI

[Ni, Hongjun]

Hi Ed,

The next TSC meeting on August 29 is preferable.

Thanks,
Hongjun

From: vpp-dev@lists.fd.io [mailto:vpp-dev@lists.fd.io] On Behalf Of Edward 
Warnicke
Sent: Thursday, August 15, 2019 3:13 AM
To: Ni, Hongjun 
Cc: t...@lists.fd.io; vpp-dev@lists.fd.io; Wang, Xiang W 
; Hong, Yang A ; Chang, Harry 
; gu.ji...@zte.com.cn; Shan Jianghua 
; Zhang Yang ; Li 
Xingfu ; Wu Shuai ; Xia Yuying 
; Fan Chenggang ; Gao Feng 
; Liu Zhong ; Zhao Yong 
; Chen Haiquan 
Subject: Re: [vpp-dev] [tsc] Project Proposal for uDPI

Do you have a preference as to dates?

Ed

On Tue, Aug 13, 2019 at 7:44 PM Ni, Hongjun 
mailto:hongjun...@intel.com>> wrote:
Hi Ed,

Thank you for scheduling the proposal review.

I think a TSC meeting after Aug 21 is better, to follow the FD.io TSC policy.

Thanks,
Hongjun

From: Ed Warnicke [mailto:hagb...@gmail.com]
Sent: Wednesday, August 14, 2019 5:09 AM
To: Ni, Hongjun mailto:hongjun...@intel.com>>
Cc: t...@lists.fd.io; 
vpp-dev@lists.fd.io; Wang, Xiang W 
mailto:xiang.w.w...@intel.com>>; Hong, Yang A 
mailto:yang.a.h...@intel.com>>; Chang, Harry 
mailto:harry.ch...@intel.com>>; 
gu.ji...@zte.com.cn; Shan Jianghua 
mailto:shanjia...@chinatelecom.cn>>; Zhang Yang 
mailto:zhangy@chinatelecom.cn>>; Li Xingfu 
mailto:lixin...@huachentel.com>>; Wu Shuai 
mailto:wush...@inspur.com>>; Xia Yuying 
mailto:yuying...@yxlink.com>>; Fan Chenggang 
mailto:fanchengg...@sunyainfo.com>>; Gao Feng 
mailto:davidf...@tencent.com>>; Liu Zhong 
mailto:liuzho...@chinaunicom.cn>>; Zhao Yong 
mailto:zhaoyon...@huawei.com>>; Chen Haiquan 
mailto:o...@yunify.com>>
Subject: Re: [tsc] Project Proposal for uDPI

Hongjun,

You guys are eligible for project creation review starting at the Aug 21 TSC 
meeting I believe (based on sending the notification to the TSC on Aug 8) ... 
when would you like to schedule for that Thu's TSC meeting, or a subsequent one?

Ed

On Thu, Aug 8, 2019 at 8:11 PM Ni, Hongjun 
mailto:hongjun...@intel.com>> wrote:
Hello FD.io TSCs

Please accept this project proposal for uDPI for consideration.
https://wiki.fd.io/view/Project_Proposals/uDPI

So far, this project has 11 founders and 15 initial committers from
Intel, ZTE, China Telecom, HuachenTel, Inspur, Yxlink, Sunyainfo, Tencent, 
China Unicom, Huawei, QingCloud.

If possible, I would like to present this on TSC meeting.

Thanks,
Hongjun
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#1070): https://lists.fd.io/g/tsc/message/1070
Mute This Topic: https://lists.fd.io/mt/32805806/464962
Group Owner: tsc+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/tsc/unsub  
[hagb...@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#1077): https://lists.fd.io/g/tsc/message/1077
Mute This Topic: https://lists.fd.io/mt/32805806/464962
Group Owner: tsc+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/tsc/unsub  
[hagb...@gmail.com]
-=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13775): https://lists.fd.io/g/vpp-dev/message/13775
Mute This Topic: https://lists.fd.io/mt/32857358/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Problem in VPP Time To Live (TTL) checking system

[Ole Troan]

Brayan,

> I checked vpp behavior when it receives packets with Time To Live (TTL) value 
> of 1. I'm using  vpp version of v19.08-rc0 on master branch.  
> 
> Based on Cisco network devices, I expected that VPP drops packets with TTL 1 
> and it sends an ICMP reject message to client. Also, when client pings the 
> Cisco device's interfaces with packets having TTL 1, the packets are rejected 
> again and an icmp reject message is sent to the client.  
> 
> I see two types of different behavior between vpp and Cisco.
> 
> In normal configuration, the TTL checking is done after lookup ( based on 
> trace log) but I expected to see this checking before routing, nat or other 
> functionality nodes. It is not optimized to do a lot of process on packets 
> and then check their TTL value, Isn't it? Currently, the TTL value is checked 
> in ip4-rewrite node, which is too late. 
> Another difference is when a client pings vpp interfaces ip with TTL 1, VPP 
> sends echo reply packet to the client while in Cisco this packets are 
> rejected. 

The correct behaviour is RFC8200:

  Hop Limit   8-bit unsigned integer.  Decremented by 1 by
  each node that forwards the packet.  When
  forwarding, the packet is discarded if Hop
  Limit was zero when received or is decremented
  to zero.  A node that is the destination of a
  packet should not discard a packet with Hop
  Limit equal to zero; it should process the
  packet normally.

This also applies for IPv4.
A packet with TTL=1 that hits the host stack is valid (e.g. a ICMP echo 
request); a packet for forwarding should be dropped.
The TTL check cannot be done before determining if the packet is for us or to 
be forwarded.

Best regards,
Ole-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13774): https://lists.fd.io/g/vpp-dev/message/13774
Mute This Topic: https://lists.fd.io/mt/32921392/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Problem in VPP Time To Live (TTL) checking system

[brayan ortega]

Dear VPP Folks,

I checked vpp behavior when it receives packets with Time To Live (TTL)
value of 1. I'm using  vpp version of v19.08-rc0 on master branch.

Based on Cisco network devices, I expected that VPP drops packets with TTL
1 and it sends an ICMP reject message to client. Also, when client pings
the Cisco device's interfaces with packets having TTL 1, the packets are
rejected again and an icmp reject message is sent to the client.

I see two types of different behavior between vpp and Cisco.

In normal configuration, the TTL checking is done after lookup ( based on
trace log) but I expected to see this checking before routing, nat or other
functionality nodes. It is not optimized to do a lot of process on packets
and then check their TTL value, Isn't it? Currently, the TTL value is
checked in ip4-rewrite node, which is too late.
Another difference is when a client pings vpp interfaces ip with TTL 1, VPP
sends echo reply packet to the client while in Cisco this packets are
rejected.

Can we consider this behavior as a bug?


my topology:

|Client 20.20.20.20| <> | 20.20.20.1  VPP device  30.30.30.1|
<-> |30.30.30.30 Router 40.40.40.1| <> |40.40.40.40
Server|

attached, you will find my configuration file.

Best Regards,


Configuration1
Description: Binary data
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13773): https://lists.fd.io/g/vpp-dev/message/13773
Mute This Topic: https://lists.fd.io/mt/32921392/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] TTL and NAT

[brayan ortega]

Dear VPP Folks,

I checked vpp behavior when nat is enabled to face packets with Time To
Live (TTL) value of 1. I'm using vpp version of v19.08-rc0 on master branch.

I configured a simple nat scenario with static mapping, In normal Scenario,
when my client ping the vpp IP, nat function has good functionality and
convert destination address of packet to the desired address. But when
client send an icmp packet with TTL 1, vpp drops the packets without
generating any reject icmp message.

I saw different behavior in different nat Scenario but I am not familiar
with nat plugin , I think it is needed to check TTL test in another
Scenario in vpp. For example, I test a scenario in which a packet with TTL
2 is sent to the vpp. VPP changed its destination address and forwarded it
to the next hop, which was a router. In that hop, TTL was 1 and the packet
was rejected due to TTL issue. The router that rejected the packet, sent an
ICMP reject message to the client. Since a device having VPP was between
the client and the router, VPP nat plugin changed the source ( router ip )
of icmp reject packet. So client received a rejected message from source of
vpp while it was sent from the router. As a result, Client thinks that its
next hop has rejected the packet, while it was not true.

Can we consider this behavior as a bug?

my topology:

|Client 20.20.20.20| <> | 20.20.20.1  VPP device  30.30.30.1|
<-> |30.30.30.30 Router 40.40.40.1| <> |40.40.40.40
Server|

attached, you will find my configuration file.


Configuration
Description: Binary data
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13772): https://lists.fd.io/g/vpp-dev/message/13772
Mute This Topic: https://lists.fd.io/mt/32921308/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-