Re: [vpp-dev] VRRP issue
Hi Naveen, Could you try a shut/no shut on the vlan segment between the VRs? Sometimes unreliable communication between the switches can cause the hellos to not be seen at other end.. Interface counters on the interface in question should help Thanks! -- Regards, Balaji. From: on behalf of "Naveen Joy via lists.fd.io" Reply-To: "Naveen Joy (najoy)" Date: Thursday, August 13, 2020 at 3:34 PM To: "mgsm...@netgate.com" Cc: "vpp-dev@lists.fd.io" Subject: [vpp-dev] VRRP issue Hi Matthew/All, I am facing an issue with VRRP in VPP and would appreciate your help. (Attached - architecture diagram) 1. I have 2 nodes with VPP & in each node, VRRP is configured to back up a router BVI interface in a bridge domain. 2. The VRRP VRs are speaking VRRP (multicast) over an uplink VLAN interface connected to an external switch. 3. The active router has a VR priority of 110 and is set to preempt. The backup router has a VR priority of 100 and is not in preempt. 1. The issue is that VRRP in the backup router is unstable and keeps transitioning between the master and backup states every second. However, the VRRP in the master node is stable. I am running the latest VPP release installed from master this week. vpp# show version verbose Version: v20.09-rc0~283-g40c07ce7a~b1542 Compiled by: root Compile host: 1f7cd9b19229 Compile date: 2020-08-11T20:40:47 Compile location: /w/workspace/vpp-merge-master-ubuntu1804 Compiler: Clang/LLVM 9.0.0 (tags/RELEASE_900/final) Current PID: 5504 On the backup node – Aug 13 12:59:48 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238: Deleting VR addresses on sw_if_index 11 Aug 13 12:59:48 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123: Deleting virtual MAC address 00:00:5e:00:01:0a on hardware interface 10 Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_vr_transition:283: VR [0] sw_if_index 11 VR ID 10 IPv4 transitioning to Master Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238: Adding VR addresses on sw_if_index 11 Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123: Adding virtual MAC address 00:00:5e:00:01:0a on hardware interface 10 Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_input_process:223: Received advertisement for master VR [0] sw_if_index 11 VR ID 10 IPv4 Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_vr_transition:283: VR [0] sw_if_index 11 VR ID 10 IPv4 transitioning to Backup Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238: Deleting VR addresses on sw_if_index 11 Aug 13 12:59:50 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123: Deleting virtual MAC address 00:00:5e:00:01:0a on hardware interface 10 Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_vr_transition:283: VR [0] sw_if_index 11 VR ID 10 IPv4 transitioning to Master Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238: Adding VR addresses on sw_if_index 11 Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123: Adding virtual MAC address 00:00:5e:00:01:0a on hardware interface 10 Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_input_process:223: Received advertisement for master VR [0] sw_if_index 11 VR ID 10 IPv4 Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_vr_transition:283: VR [0] sw_if_index 11 VR ID 10 IPv4 transitioning to Backup Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238: Deleting VR addresses on sw_if_index 11 Aug 13 12:59:51 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123: Deleting virtual MAC address 00:00:5e:00:01:0a on hardware interface 10 Aug 13 12:59:52 ml-ucs-03 vnet[4023]: vrrp_vr_transition:283: VR [0] sw_if_index 11 VR ID 10 IPv4 transitioning to Master Aug 13 12:59:52 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238: Adding VR addresses on sw_if_index 11 Aug 13 12:59:52 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123: Adding virtual MAC address 00:00:5e:00:01:0a on hardware interface 10 Aug 13 12:59:52 ml-ucs-03 vnet[4023]: vrrp_input_process:223: Received advertisement for master VR [0] sw_if_index 11 VR ID 10 IPv4 Aug 13 12:59:52 ml-ucs-03 vnet[4023]: vrrp_vr_transition:283: VR [0] sw_if_index 11 VR ID 10 IPv4 transitioning to Backup Aug 13 12:59:52 ml-ucs-03 vnet[4023]: vrrp_vr_transition_addrs:238: Deleting VR addresses on sw_if_index 11 Aug 13 12:59:52 ml-ucs-03 vnet[4023]: vrrp_vr_transition_vmac:123: Deleting virtual MAC address 00:00:5e:00:01:0a on hardware interface 10 vpp# show vrrp vr [0] sw_if_index 11 VR ID 10 IPv4 state Backup flags: preempt no accept yes unicast no priority: configured 100 adjusted 100 timers: adv interval 30 master adv 30 skew 18 master down 108 virtual MAC 00:00:5e:00:01:0a addresses 10.4.4.5 peer addresses tracked interfaces vpp# show vrrp vr [0] sw_if_index 11 VR ID 10 IPv4 state Master flags: preempt no accept yes unicast no priority: configured 100 adjusted 100 timers: adv interval 30 master adv
Re: [vpp-dev] FD.io 20.09 and 21.01 Release Schedule
Well I am mean there is always a bit of back and forth on any feature you intend to upstream. And many of those discussions are active into the month prior to the release. I don't think it is a case of people postponing code, and being ill-prepared. People will always sprint the last 100 yards to the finish line in any long race. Ray K On 13/08/2020 11:46, Andrew 👽 Yourtchenko wrote: > What do you mean by “most reviews” ? > > The F0 for both is in the start of September and January - so for the release > work people should already be back... > > Or you mean that people postpone stuff they plan to code for the upcoming > release until the latest moment ? > > --a > >> On 13 Aug 2020, at 12:12, Ray Kinsella wrote: >> >> Folks, >> >> I just wanted to ask if the current release cadence is working for us? >> >> A September release (FD.io 20.09) means most reviews need to happen in >> August, not a month when many people are in the office. Similarly a January >> release (FD.io 21.01) means most reviews need to happen in December, again >> not a month when many people are in the office. >> >> What do folks think? >> >> Ray K >> -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17226): https://lists.fd.io/g/vpp-dev/message/17226 Mute This Topic: https://lists.fd.io/mt/76164625/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] FD.io 20.09 and 21.01 Release Schedule
What do you mean by “most reviews” ? The F0 for both is in the start of September and January - so for the release work people should already be back... Or you mean that people postpone stuff they plan to code for the upcoming release until the latest moment ? --a > On 13 Aug 2020, at 12:12, Ray Kinsella wrote: > > Folks, > > I just wanted to ask if the current release cadence is working for us? > > A September release (FD.io 20.09) means most reviews need to happen in > August, not a month when many people are in the office. Similarly a January > release (FD.io 21.01) means most reviews need to happen in December, again > not a month when many people are in the office. > > What do folks think? > > Ray K > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17225): https://lists.fd.io/g/vpp-dev/message/17225 Mute This Topic: https://lists.fd.io/mt/76164625/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[vpp-dev] FD.io 20.09 and 21.01 Release Schedule
Folks, I just wanted to ask if the current release cadence is working for us? A September release (FD.io 20.09) means most reviews need to happen in August, not a month when many people are in the office. Similarly a January release (FD.io 21.01) means most reviews need to happen in December, again not a month when many people are in the office. What do folks think? Ray K -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17224): https://lists.fd.io/g/vpp-dev/message/17224 Mute This Topic: https://lists.fd.io/mt/76164625/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] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
[Edited Message Follows] 172.16.16.18 and 172.16.82.247 are IP addresses assigned to vpp physical interfaces. 172.16.16.17 and 172.16.82.4 are hosts(different machines) attached to those interfaces. VPP is acting as router. That works perfectly. Now I just want to let some non-vpp application to read packets. Hence using memif. Below is total config. vppctl create interface memif id 0 master vppctl set int state memif0/0 up vppctl ip table add 1 vppctl set interface table memif0/0 1 vppctl set int ip address memif0/0 192.168.1.1/24 vppctl set interface state GigabitEthernet3/0/0 up vppctl set interface state GigabitEthernet4/0/0 up vppctl set interface ip address GigabitEthernet4/0/0 172.16.16.18/24 vppctl set interface ip address GigabitEthernet3/0/0 172.16.82.247/24 vppctl ip route add 172.16.82.4/32 via 192.168.1.1 next-hop-table 1 ---> removed memif0/0 as per suggestion, VPP itself starts answering to icmp, packet does not reach to memif or original destination vppctl ip route add 172.16.82.4/32 table 1 via GigabitEthernet3/0/0 next-hop-table 0 ---> results in error -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17223): https://lists.fd.io/g/vpp-dev/message/17223 Mute This Topic: https://lists.fd.io/mt/76099289/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] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
172.16.16.18 and 172.16.82.247 are IP addresses assigned to vpp physical interfaces. 172.16.16.17 and 172.16.82.4 are hosts(different machines) attached to those interfaces. VPP is acting as router. That works perfectly. Now I just want to let some non-vpp application to read packets. Hence using memif. Below is total config. vppctl create interface memif id 0 master vppctl set int state memif0/0 up vppctl ip table add 1 vppctl set interface table memif0/0 1 vppctl set int ip address memif0/0 192.168.1.1/24 vppctl set interface state GigabitEthernet3/0/0 up vppctl set interface state GigabitEthernet4/0/0 up vppctl set interface ip address GigabitEthernet4/0/0 172.16.16.18/24 vppctl set interface ip address GigabitEthernet3/0/0 172.16.82.247/24 vppctl ip route add 172.16.82.4/32 via 192.168.1.1 next-hop-table 1 ---> removed memif0/0 as per suggestion vppctl ip route add 172.16.82.4/32 table 1 via GigabitEthernet3/0/0 next-hop-table 0 ---> results in error -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17223): https://lists.fd.io/g/vpp-dev/message/17223 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
You can't use the same address as a nexthop in a route and as an address applied to one of your own interfaces: you can't route to yourself. You might also want to read: https://fd.io/docs/vpp/master/gettingstarted/developers/fib20/attachedexport.html /neale tpyed by my fat tumhbs From: vpp-dev@lists.fd.io on behalf of techi...@gmail.com Sent: Wednesday, August 12, 2020 8:05:56 PM To: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif Hello Ben, vppctl create interface memif id 0 master vppctl set int state memif0/0 up vppctl ip table add 1 vppctl set interface table memif0/0 1 vppctl set int ip address memif0/0 192.168.1.1/24 vppctl set interface state GigabitEthernet3/0/0 up vppctl set interface state GigabitEthernet4/0/0 up vppctl set interface ip address GigabitEthernet4/0/0 172.16.16.18/24 vppctl set interface ip address GigabitEthernet3/0/0 172.16.82.247/24 vppctl ip route add 172.16.82.4/32 via 192.168.1.1 memif0/0 vppctl ip route add 172.16.82.4/32 table 1 via GigabitEthernet3/0/0 I did above config. It shows blackholed packet error in trace. What am I doing wrong ? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17222): https://lists.fd.io/g/vpp-dev/message/17222 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
> vppctl ip route add 172.16.82.4/32 via 192.168.1.1 memif0/0 next- > hop-table 1 > It shows following error: > ip route: parse error `via 192.168.1.1 memif0/0 next-...' My bad, you should remove the interface: vppctl ip route add 172.16.82.4/32 via 192.168.1.1 next-hop-table 1 ben -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17221): https://lists.fd.io/g/vpp-dev/message/17221 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Unable to create fib table and add interfaces in vpp 20.09
[Edited Message Follows] Got it. Thanks.. in vpp v17 there was no ip table add/del in newer version it is introduced I guess... -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17201): https://lists.fd.io/g/vpp-dev/message/17201 Mute This Topic: https://lists.fd.io/mt/76146302/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] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
On Thu, Aug 13, 2020 at 01:38 AM, Benoit Ganne (bganne) wrote: > > vppctl ip route add 172.16.82.4/32 via 192.168.1.1 memif0/0 next-hop-table > 1 It shows following error: ip route: parse error `via 192.168.1.1 memif0/0 next-...' -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17220): https://lists.fd.io/g/vpp-dev/message/17220 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
Ok, from what I understand, what you see in the trace is when the packet is entering VPP through DPDK, it matches the route 'vppctl ip route add 172.16.82.4/32 via 192.168.1.1 memif0/0' you configured in table 0 (default VRF), so VPP tries to forward it through 192.168.1.1, but this address is programmed only in VRF 1, so VRF 0 does not know it and ARP. Then ARP reply comes back from memif0, but is is looked up in VRF 1 and is dropped (it is waited for in VRF 0). I think you should change your route like this: vppctl ip route add 172.16.82.4/32 via 192.168.1.1 memif0/0 next-hop-table 1 vppctl ip route add 172.16.82.4/32 table 1 via GigabitEthernet3/0/0 next-hop-table 0 Best ben > -Original Message- > From: vpp-dev@lists.fd.io On Behalf Of > techi...@gmail.com > Sent: jeudi 13 août 2020 10:09 > To: vpp-dev@lists.fd.io > Subject: Re: [vpp-dev] #vpp-memif Send packets out on physical interface > controlled by vpp(DPDK) once they are received through memif > > Hi ben, > > Please find below trace (dpdk-input and memif-input) in application I > am just writing back buffers I received on memif.. > > 00:02:56:971957: dpdk-input > GigabitEthernet4/0/0 rx queue 0 > buffer 0x98114: current data 0, length 74, buffer-pool 0, ref-count 1, > totlen-nifb 0, trace handle 0x0 > ext-hdr-valid > l4-cksum-computed l4-cksum-correct > PKT MBUF: port 1, nb_segs 1, pkt_len 74 > buf_len 2176, data_len 74, ol_flags 0x180, data_off 128, phys_addr > 0x56604580 > packet_type 0x11 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 (0x0010) IPv4 packet without extension headers > IP4: a4:bb:6d:0f:bf:56 -> 00:0d:48:49:12:a2 > ICMP: 172.16.16.17 -> 172.16.82.4 > tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN > fragment id 0x7c68 > ICMP echo_request checksum 0x4baf > 00:02:56:971980: ethernet-input > frame: flags 0x3, hw-if-index 2, sw-if-index 2 > IP4: a4:bb:6d:0f:bf:56 -> 00:0d:48:49:12:a2 > 00:02:56:971994: ip4-input-no-checksum > ICMP: 172.16.16.17 -> 172.16.82.4 > tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN > fragment id 0x7c68 > ICMP echo_request checksum 0x4baf > 00:02:56:972001: ip4-lookup > fib 0 dpo-idx 3 flow hash: 0x > ICMP: 172.16.16.17 -> 172.16.82.4 > tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN > fragment id 0x7c68 > ICMP echo_request checksum 0x4baf > 00:02:56:972007: ip4-arp > ICMP: 172.16.16.17 -> 172.16.82.4 > tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN > fragment id 0x7c68 > ICMP echo_request checksum 0x4baf > 00:02:56:972019: ip4-drop > ICMP: 172.16.16.17 -> 172.16.82.4 > tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN > fragment id 0x7c68 > ICMP echo_request checksum 0x4baf > 00:02:56:972083: error-drop > rx:GigabitEthernet4/0/0 > 00:02:56:972088: drop > ip4-arp: ARP requests sent > > Packet 2 > > 00:02:56:972299: memif-input > memif: hw_if_index 3 next-index 4 > slot: ring 0 > 00:02:56:972327: ethernet-input > frame: flags 0x1, hw-if-index 3, sw-if-index 3 > ARP: 02:fe:87:ff:c6:2a -> ff:ff:ff:ff:ff:ff > 00:02:56:972335: arp-input > request, type ethernet/IP4, address size 6/4 > 02:fe:87:ff:c6:2a/192.168.1.1 -> 00:00:00:00:00:00/192.168.1.1 > 00:02:56:972339: arp-reply > request, type ethernet/IP4, address size 6/4 > 02:fe:87:ff:c6:2a/192.168.1.1 -> 00:00:00:00:00:00/192.168.1.1 > 00:02:56:972350: error-drop > rx:memif0/0 > 00:02:56:972351: drop > null-node: blackholed packets -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17219): https://lists.fd.io/g/vpp-dev/message/17219 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] Issue in VRRP functionality when compiling with devtoolset-7 with single worker configuration
Hi Matthew, I am not observing the issue with the patch applied. Thanks for your support. Regards Amit On Tue, Aug 11, 2020 at 2:19 PM Amit Mehra via lists.fd.io wrote: > Hi Matthews, > > Thanks for the reply. I will try with this patch and will let you know my > observations. > > Regards > Amit > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17218): https://lists.fd.io/g/vpp-dev/message/17218 Mute This Topic: https://lists.fd.io/mt/76043759/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] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
Hi ben, Please find below trace (dpdk-input and memif-input) in application I am just writing back buffers I received on memif.. 00:02:56:971957: dpdk-input GigabitEthernet4/0/0 rx queue 0 buffer 0x98114: current data 0, length 74, buffer-pool 0, ref-count 1, totlen-nifb 0, trace handle 0x0 ext-hdr-valid l4-cksum-computed l4-cksum-correct PKT MBUF: port 1, nb_segs 1, pkt_len 74 buf_len 2176, data_len 74, ol_flags 0x180, data_off 128, phys_addr 0x56604580 packet_type 0x11 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 (0x0010) IPv4 packet without extension headers IP4: a4:bb:6d:0f:bf:56 -> 00:0d:48:49:12:a2 ICMP: 172.16.16.17 -> 172.16.82.4 tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN fragment id 0x7c68 ICMP echo_request checksum 0x4baf 00:02:56:971980: ethernet-input frame: flags 0x3, hw-if-index 2, sw-if-index 2 IP4: a4:bb:6d:0f:bf:56 -> 00:0d:48:49:12:a2 00:02:56:971994: ip4-input-no-checksum ICMP: 172.16.16.17 -> 172.16.82.4 tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN fragment id 0x7c68 ICMP echo_request checksum 0x4baf 00:02:56:972001: ip4-lookup fib 0 dpo-idx 3 flow hash: 0x ICMP: 172.16.16.17 -> 172.16.82.4 tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN fragment id 0x7c68 ICMP echo_request checksum 0x4baf 00:02:56:972007: ip4-arp ICMP: 172.16.16.17 -> 172.16.82.4 tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN fragment id 0x7c68 ICMP echo_request checksum 0x4baf 00:02:56:972019: ip4-drop ICMP: 172.16.16.17 -> 172.16.82.4 tos 0x00, ttl 128, length 60, checksum 0x0423 dscp CS0 ecn NON_ECN fragment id 0x7c68 ICMP echo_request checksum 0x4baf 00:02:56:972083: error-drop rx:GigabitEthernet4/0/0 00:02:56:972088: drop ip4-arp: ARP requests sent Packet 2 00:02:56:972299: memif-input memif: hw_if_index 3 next-index 4 slot: ring 0 00:02:56:972327: ethernet-input frame: flags 0x1, hw-if-index 3, sw-if-index 3 ARP: 02:fe:87:ff:c6:2a -> ff:ff:ff:ff:ff:ff 00:02:56:972335: arp-input request, type ethernet/IP4, address size 6/4 02:fe:87:ff:c6:2a/192.168.1.1 -> 00:00:00:00:00:00/192.168.1.1 00:02:56:972339: arp-reply request, type ethernet/IP4, address size 6/4 02:fe:87:ff:c6:2a/192.168.1.1 -> 00:00:00:00:00:00/192.168.1.1 00:02:56:972350: error-drop rx:memif0/0 00:02:56:972351: drop null-node: blackholed packets -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17217): https://lists.fd.io/g/vpp-dev/message/17217 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [vpp-dev] #vpp-memif Send packets out on physical interface controlled by vpp(DPDK) once they are received through memif
> I did above config. It shows blackholed packet error in trace. What am I > doing wrong ? Could you share the packet trace? Best ben -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#17216): https://lists.fd.io/g/vpp-dev/message/17216 Mute This Topic: https://lists.fd.io/mt/76099289/21656 Mute #vpp-memif: https://lists.fd.io/g/fdio+vpp-dev/mutehashtag/vpp-memif Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
