Re: [vpp-dev] #vpp #vpp-dev

2021-03-11 Thread liuyacan 






hI Nikhil,
I don't know why the VM did not receive icmp reply packet, But I am sure it is not caused by fib because icmp reply, because the packet will not go through the ip4-lookup again.The reason you see "fib 0" is because the value of sw_if_index[VLIB_RX] was set to vnet_main.local_interface_sw_if_index in ip4-icmp-echo-reply nodeBTW, This trace information once also confused me...Best regards,yacan   
 

On 3/12/2021 02:12，nikhil subhedar wrote： 


Hi All,Today i found a strange thing on my  POD on which VPP is running.  Can anyone please shed some light on this?Thanks.Config:1) I created a loopback interface on VPP using confd CLI. on fib-index 1loop2 (up):  L3 50.50.50.50/32 ip4 table-id 1 fib-idx 1Also , on the top of this i  am having physical/ connected interface.VirtualFuncEthernet0/6/0.900 (up):  L3 20.20.146.226/24 ip4 table-id 1 fib-idx 12) On ubuntu VM i have created a loopback,lo:mobile: flags=73  mtu 65536    inet 60.60.60.60  netmask 255.255.255.255    loop  txqueuelen 1000  (Local Loopback)And i have a connected interface ens5.900: flags=4163  mtu 1500    inet 20.20.146.216 route on VM.root@vmsrvrlnx-strongswan-216:~# route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref    Use Iface0.0.0.0 10.163.64.1 0.0.0.0 UG    0  0    0 ens32.1.75.0    0.0.0.0 255.255.255.252 U 0  0    0 gre110.163.64.0 0.0.0.0 255.255.224.0   U 0  0    0 ens320.20.146.0 0.0.0.0 255.255.255.0   U 0  0    0 ens5.90050.50.50.50 20.20.146.226   255.255.255.255 UGH   0  0    0 ens5.9003) I am  trying to ping from VM to vpp.using command ping 50.50.50.50 -I  ens5.900.4)  This icmp packet is reached to VPP on fib index 1, but when VPP is trying to send the echo-reply it is using fib index 0  and because of this icmp reply packetis not reaching to my VM.Below is o/p of show trace command.Packet 103:50:52:603829: dpdk-input  VirtualFuncEthernet0/6/0 rx queue 0  buffer 0x4c2f16: current data 0, length 102, buffer-pool 0, ref-count 1, totlen-nifb 0, trace handle 0x100   ext-hdr-valid   l4-cksum-computed l4-cksum-correct  PKT MBUF: port 0, nb_segs 1, pkt_len 102    buf_len 2176, data_len 102, ol_flags 0x180, data_off 128, phys_addr 0x7b0bc600    packet_type 0x591 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0    rss 0x0 fdir.hi 0x0 fdir.lo 0x0    Packet Offload Flags  PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid  PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid    Packet Types  RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet  RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or without extension headers  RTE_PTYPE_L4_ICMP (0x0500) ICMP packet  IP4: fa:16:3e:08:4c:1d -> fa:16:3e:78:ca:96 802.1q vlan 900  ICMP: 20.20.146.216 -> 50.50.50.50    tos 0x00, ttl 64, length 84, checksum 0x3d88 dscp CS0 ecn NON_ECN    fragment id 0xf1d0, flags DONT_FRAGMENT  ICMP echo_request checksum 0x430303:50:52:603840: ethernet-input  frame: flags 0x3, hw-if-index 3, sw-if-index 3  IP4: fa:16:3e:08:4c:1d -> fa:16:3e:78:ca:96 802.1q vlan 90003:50:52:603847: ip4-input  ICMP: 20.20.146.216 -> 50.50.50.50    tos 0x00, ttl 64, length 84, checksum 0x3d88 dscp CS0 ecn NON_ECN    fragment id 0xf1d0, flags DONT_FRAGMENT  ICMP echo_request checksum 0x430303:50:52:603853: ip4-lookup  fib 1 dpo-idx 22 flow hash: 0x  ICMP: 20.20.146.216 -> 50.50.50.50    tos 0x00, ttl 64, length 84, checksum 0x3d88 dscp CS0 ecn NON_ECN    fragment id 0xf1d0, flags DONT_FRAGMENT  ICMP echo_request checksum 0x430303:50:52:603857: ip4-local    ICMP: 20.20.146.216 -> 50.50.50.50  tos 0x00, ttl 64, length 84, checksum 0x3d88 dscp CS0 ecn NON_ECN ICMP echo_request checksum 0x430303:50:52:603859: ip4-icmp-input  ICMP: 20.20.146.216 -> 50.50.50.50    tos 0x00, ttl 64, length 84, checksum 0x3d88 dscp CS0 ecn NON_ECN    fragment id 0xf1d0, flags DONT_FRAGMENT  ICMP echo_request checksum 0x430303:50:52:603860: ip4-icmp-echo-request  ICMP: 20.20.146.216 -> 50.50.50.50    tos 0x00, ttl 64, length 84, checksum 0x3d88 dscp CS0 ecn NON_ECN    fragment id 0xf1d0, flags DONT_FRAGMENT  ICMP echo_request checksum 0x430303:50:52:603863: ip4-load-balance  fib 0 dpo-idx 9 flow hash: 0x  ICMP: 50.50.50.50 -> 20.20.146.216    tos 0x00, ttl 64, length 84, checksum 0x246c dscp CS0 ecn NON_ECN    fragment id 0x0aed, flags DONT_FRAGMENT  ICMP echo_reply checksum 0x4b0303:50:52:603865: ip4-rewrite  tx_sw_if_index 11 dpo-idx 9 : ipv4 via 20.20.146.216 VirtualFuncEthernet0/6/0.900: mtu:9000 next:9 fa163e084c1dfa163e78ca96810003840800 flow hash: 0x  : fa163e084c1dfa163e78ca9681000384080045540aed40004001246c3232  0020: 3232141492d84b03000a0001795c4a602a62080003:50:52:603867: VirtualFuncEthernet0/6/0-output  VirtualFuncEthernet0/6/0.900  IP4: fa:16:3e:78:ca:96 -> fa:16:3e:08:4c:1d

[vpp-dev] #vpp #vpp-dev

2021-03-11 Thread nikhil subhedar 
Hi All,

Today i found a strange thing on my  POD on which VPP is running.  Can anyone 
please shed some light on this?
Thanks.
*Config:*

1) I created a loopback interface on VPP using confd CLI. on fib-index 1
*loop2 (up):*
*L3 50.50.50.50/32 ip4 table-id 1 fib-idx 1
* Also , on the top of this i  am having physical/ connected interface. *
VirtualFuncEthernet0/6/0.900 (up):
L3 20.20.146.226/24 ip4 table-id 1 fib-idx 1

2)* On ubuntu VM i have created a loopback, *
lo:mobile: flags=73  mtu 65536
inet 60.60.60.60  netmask 255.255.255.255
loop  txqueuelen 1000  (Local Loopback)

And i have a connected interface
ens5.900: flags=4163  mtu 1500
inet 20.20.146.216

route on VM.
root@vmsrvrlnx-strongswan-216:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref    Use Iface
0.0.0.0 10.163.64.1 0.0.0.0 UG    0  0    0 ens3
2.1.75.0    0.0.0.0 255.255.255.252 U 0  0    0 gre1
10.163.64.0 0.0.0.0 255.255.224.0   U 0  0    0 ens3
20.20.146.0 0.0.0.0 255.255.255.0   U 0  0    0 ens5.900
50.50.50.50 20.20.146.226   255.255.255.255 UGH   0  0    0 ens5.900

* *
* 3) I am  trying to ping from VM to vpp.
using command *ping 50.50.50.50 -I  ens5.900.

* 4)  This icmp packet is reached to VPP on fib index 1, but when VPP is trying 
to send the echo-reply it is using fib index 0  and because of this icmp reply 
packet
is not reaching to my VM.
Below is o/p of show trace command.

Packet 1

03:50:52:603829: dpdk-input
VirtualFuncEthernet0/6/0 rx queue 0
buffer 0x4c2f16: current data 0, length 102, buffer-pool 0, ref-count 1, 
totlen-nifb 0, trace handle 0x100
ext-hdr-valid
l4-cksum-computed l4-cksum-correct
PKT MBUF: port 0, nb_segs 1, pkt_len 102
buf_len 2176, data_len 102, ol_flags 0x180, data_off 128, phys_addr 0x7b0bc600
packet_type 0x591 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
rss 0x0 fdir.hi 0x0 fdir.lo 0x0
Packet Offload Flags
PKT_RX_IP_CKSUM_GOOD (0x0080) IP cksum of RX pkt. is valid
PKT_RX_L4_CKSUM_GOOD (0x0100) L4 cksum of RX pkt. is valid
Packet Types
RTE_PTYPE_L2_ETHER (0x0001) Ethernet packet
RTE_PTYPE_L3_IPV4_EXT_UNKNOWN (0x0090) IPv4 packet with or without extension 
headers
RTE_PTYPE_L4_ICMP (0x0500) ICMP packet
IP4: fa:16:3e:08:4c:1d -> fa:16:3e:78:ca:96 802.1q vlan 900
ICMP: 20.20.146.216 -> 50.50.50.50
tos 0x00, ttl 64, length 84, checksum 0x3d88 dscp CS0 ecn NON_ECN
fragment id 0xf1d0, flags DONT_FRAGMENT
ICMP echo_request checksum 0x4303
03:50:52:603840: ethernet-input
frame: flags 0x3, hw-if-index 3, sw-if-index 3
IP4: fa:16:3e:08:4c:1d -> fa:16:3e:78:ca:96 802.1q vlan 900
03:50:52:603847: ip4-input
ICMP: 20.20.146.216 -> 50.50.50.50
tos 0x00, ttl 64, length 84, checksum 0x3d88 dscp CS0 ecn NON_ECN
fragment id 0xf1d0, flags DONT_FRAGMENT
ICMP echo_request checksum 0x4303
03:50:52:603853: ip4-lookup
*fib* 1 dpo-idx 22 flow hash: 0x
ICMP: 20.20.146.216 -> 50.50.50.50
tos 0x00, ttl 64, length 84, checksum 0x3d88 dscp CS0 ecn NON_ECN
fragment id 0xf1d0, flags DONT_FRAGMENT
ICMP echo_request checksum 0x4303
03:50:52:603857: ip4-local
ICMP: 20.20.146.216 -> 50.50.50.50
tos 0x00, ttl 64, length 84, checksum 0x3d88 dscp CS0 ecn NON_ECN
*
*

ICMP echo_request checksum 0x4303
03:50:52:603859: ip4-icmp-input
ICMP: 20.20.146.216 -> 50.50.50.50
tos 0x00, ttl 64, length 84, checksum 0x3d88 dscp CS0 ecn NON_ECN
fragment id 0xf1d0, flags DONT_FRAGMENT
ICMP echo_request checksum 0x4303
03:50:52:603860: ip4-icmp-echo-request
ICMP: 20.20.146.216 -> 50.50.50.50
tos 0x00, ttl 64, length 84, checksum 0x3d88 dscp CS0 ecn NON_ECN
fragment id 0xf1d0, flags DONT_FRAGMENT
ICMP echo_request checksum 0x4303
03:50:52:603863: ip4-load-balance
*fib* 0 dpo-idx 9 flow hash: 0x
ICMP: 50.50.50.50 -> 20.20.146.216
tos 0x00, ttl 64, length 84, checksum 0x246c dscp CS0 ecn NON_ECN
fragment id 0x0aed, flags DONT_FRAGMENT
ICMP echo_reply checksum 0x4b03
03:50:52:603865: ip4-rewrite
tx_sw_if_index 11 dpo-idx 9 : ipv4 via 20.20.146.216 
VirtualFuncEthernet0/6/0.900: mtu:9000 next:9 
fa163e084c1dfa163e78ca96810003840800 flow hash: 0x00
00
: fa163e084c1dfa163e78ca9681000384080045540aed40004001246c3232
0020: 3232141492d84b03000a0001795c4a602a620800
03:50:52:603867: VirtualFuncEthernet0/6/0-output
VirtualFuncEthernet0/6/0.900
IP4: fa:16:3e:78:ca:96 -> fa:16:3e:08:4c:1d 802.1q vlan 900
ICMP: 50.50.50.50 -> 20.20.146.216
tos 0x00, ttl 64, length 84, checksum 0x246c dscp CS0 ecn NON_ECN
fragment id 0x0aed, flags DONT_FRAGMENT
ICMP echo_reply checksum 0x4b03

*Below is o/p of show ip fib index 1 command*

20.20.146.216/32
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:55 buckets:1 uRPF:71 to:[0:0] 
via:[7953:668052]]
[0] [@5]: ipv4 via 20.20.146.216 VirtualFuncEthernet0/6/0.900: mtu:9000 next:9 
fa163e084c1dfa163e78ca96810003840800
20.20.146.0/24
unicast-ip4-chain
[@0]: dpo-load-balance: [proto:ip4 index:50 buckets:1

Re: [vpp-dev] RFC: vlib_global_main_t

2021-03-11 Thread Florin Coras 
+1

Florin

> On Mar 11, 2021, at 7:18 AM, Dave Barach  wrote:
> 
> Looks like a win to me...
> 
> -Original Message-
> From: vpp-dev@lists.fd.io   > On Behalf Of Damjan Marion via lists.fd.io 
> 
> Sent: Thursday, March 11, 2021 9:36 AM
> To: vpp-dev mailto:vpp-dev@lists.fd.io>>
> Subject: [vpp-dev] RFC: vlib_global_main_t
> 
> 
> 
> Guys,
> 
> I found that having both global and thread data in vlib_main_t  is confusing 
> to many people and also bug prone.
> 
> I wonder if there is sense in. moving global data to new vlib_global_main_t?
> 
> I submitted RFC patch and would like to hear what people think about that….
> 
> https://gerrit.fd.io/r/c/vpp/+/31623
> 
> Thanks,
> 
> Damjan
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18901): https://lists.fd.io/g/vpp-dev/message/18901
Mute This Topic: https://lists.fd.io/mt/81253828/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] Packet generator continuous stream

2021-03-11 Thread Ray Kinsella 
To answer my own question.

Limit is set by the length (in packets) of the pcap file.
You can make continuous with packet-generator configure  limit 0.

Ray K

On 11/03/2021 14:23, Kinsella, Ray wrote:
> Folks,
> 
> Is there anyway to tell the Packet Generator to generate a continuous stream?
> Configuration is below and is stopping at the end of the pcap files (1m 
> packets).
> 
> Ray K
> 
> create packet-generator interface pg1 
> create packet-generator interface pg2 
> packet-generator new pcap ../vpp_configs/pg/vxlan_traces/intfc1.pcap source 
> pg1 name s1 rate 1.00e6 maxframe 256
> packet-generator new pcap ../vpp_configs/pg/vxlan_traces/intfc2.pcap source 
> pg2 name s2 rate 1.00e6 maxframe 256
> packet-generator enable-stream
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18900): https://lists.fd.io/g/vpp-dev/message/18900
Mute This Topic: https://lists.fd.io/mt/81253570/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] RFC: vlib_global_main_t

2021-03-11 Thread Dave Barach 
Looks like a win to me...

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Damjan Marion via 
lists.fd.io
Sent: Thursday, March 11, 2021 9:36 AM
To: vpp-dev 
Subject: [vpp-dev] RFC: vlib_global_main_t



Guys,

I found that having both global and thread data in vlib_main_t  is confusing to 
many people and also bug prone.

I wonder if there is sense in. moving global data to new vlib_global_main_t?

I submitted RFC patch and would like to hear what people think about that….

https://gerrit.fd.io/r/c/vpp/+/31623

Thanks,

Damjan



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18899): https://lists.fd.io/g/vpp-dev/message/18899
Mute This Topic: https://lists.fd.io/mt/81253828/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] RFC: vlib_global_main_t

2021-03-11 Thread Damjan Marion via lists.fd.io 


Guys,

I found that having both global and thread data in vlib_main_t  is confusing to 
many people and also bug prone.

I wonder if there is sense in. moving global data to new vlib_global_main_t?

I submitted RFC patch and would like to hear what people think about that….

https://gerrit.fd.io/r/c/vpp/+/31623

Thanks,

Damjan


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18898): https://lists.fd.io/g/vpp-dev/message/18898
Mute This Topic: https://lists.fd.io/mt/81253828/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Packet generator continuous stream

2021-03-11 Thread Ray Kinsella 
Folks,

Is there anyway to tell the Packet Generator to generate a continuous stream?
Configuration is below and is stopping at the end of the pcap files (1m 
packets).

Ray K

create packet-generator interface pg1 
create packet-generator interface pg2 
packet-generator new pcap ../vpp_configs/pg/vxlan_traces/intfc1.pcap source pg1 
name s1 rate 1.00e6 maxframe 256
packet-generator new pcap ../vpp_configs/pg/vxlan_traces/intfc2.pcap source pg2 
name s2 rate 1.00e6 maxframe 256
packet-generator enable-stream


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#18897): https://lists.fd.io/g/vpp-dev/message/18897
Mute This Topic: https://lists.fd.io/mt/81253570/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-