Re: [vpp-dev] Basic l2 bridging does not work
Just for record purposes, we did not continue trying this R740-R230 setup. We moved to R740-R740 setup. We did not see this phy nic down issue. It seems some compatibility bug within R230 + some nic. On Sun, Oct 20, 2019 at 9:37 PM Balaji Venkatraman via Lists.Fd.Io wrote: > I see in the log of “ethtool enp6s0f1“ on R230: > > > > root@esdn-relay:~/gnxi/perf_testing/r230# ethtool enp6s0f1 > > > > Supported ports: [ *FIBRE* ] <<<<<<<<<<<<<<<< > > Supported link modes: 1baseT/Full > > Supports auto-negotiation: No > > Advertised link modes: 1baseT/Full <<<<< > > Speed: 1Mb/s > > Port: Direct Attach Copper > > *Auto-negotiation: off* > > > > > > While on R 230: > > root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ethtool eno3 > Settings for eno3: > Supported ports: [ *TP* ]. <<<<<<<<<<<<<<<<< > > > *Supported link modes: 100baseT/Full > 1000baseT/Full 1baseT/Full *<<<<< > Supported pause frame use: Symmetric > Supports auto-negotiation: Yes > Supported FEC modes: Not reported > Advertised link modes: 100baseT/Full > 1000baseT/Full > 1baseT/Full > Advertised pause frame use: Symmetric > Advertised auto-negotiation: Yes > Advertised FEC modes: Not reported > Speed: 1Mb/s > Duplex: Full > *Port: Twisted Pair* > PHYAD: 0 > Transceiver: internal > *Auto-negotiation: on* > MDI-X: Unknown > > > > > > The supported ports seem mismatched at either end with AutoNeg disabled at > one, I doubt the parameters are exchanged to get the transmissions going. > Some expert in the ethernet might want to comment if this could be an issue. > > Regards, > > Balaji. > > > > > > *From: * on behalf of "steven luong via Lists.Fd.Io" > > *Reply-To: *"Steven Luong (sluong)" > *Date: *Friday, October 18, 2019 at 10:06 PM > *To: *"vpp-dev@lists.fd.io" > *Cc: *"vpp-dev@lists.fd.io" > *Subject: *Re: [vpp-dev] Basic l2 bridging does not work > > > > Can you reduce your rx and tx queues to 1 and try again? > > > > rx: queues 2 (max 128), desc 512 (min 32 max 4096 align 8) > tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) > > > Steven > > > > *From: * on behalf of "Chuan Han via Lists.Fd.Io" > > *Reply-To: *"chuan...@google.com" > *Date: *Friday, October 18, 2019 at 4:05 PM > *To: *Chuan Han > *Cc: *"vpp-dev@lists.fd.io" > *Subject: *Re: [vpp-dev] Basic l2 bridging does not work > > > > Hi, Damjan, > > > > It seems the bug is in vpp. > > > > On R230, vpp shows eth0 is down. > > > > vpp# sh hardware-interfaces eth0 > NameIdx Link Hardware > eth0 2down eth0 > Link speed: unknown > > > * Ethernet address b4:96:91:23:1e:d6 Intel 82599 carrier down* > flags: admin-up promisc pmd rx-ip4-cksum > rx: queues 2 (max 128), desc 512 (min 32 max 4096 align 8) > tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) > pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 > max rx packet len: 15872 > promiscuous: unicast on all-multicast on > vlan offload: strip off filter off qinq off > rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro >macsec-strip vlan-filter vlan-extend jumbo-frame > scatter >security keep-crc > rx offload active: ipv4-cksum > tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum > sctp-cksum >tcp-tso macsec-insert multi-segs security > tx offload active: none > rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex > ipv6-tcp >ipv6-udp ipv6-ex ipv6 > rss active:none > tx burst function: (nil) > rx burst function: ixgbe_recv_pkts_vec > > extended stats: > mac local errors 318 > vpp# > > > > However, the testpmd tool shows it is up. > > > > testpmd> show port summary 1 > Number of available ports: 2 > Port MAC Address Name Driver Status Link > *1B4:96:91:23:1E:D6 :06:00.1 net_ixgbe up 1Mbps* > testpmd> > > > &g
Re: [vpp-dev] Basic l2 bridging does not work
The same problem still exists. vpp# sh hardware-interfaces eth0 NameIdx Link Hardware eth0 2down eth0 Link speed: unknown Ethernet address b4:96:91:23:1e:d6 Intel 82599 *carrier down * flags: admin-up promisc pmd rx-ip4-cksum *rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8)tx: queues 1 (max 64), desc 512 (min 32 max 4096 align 8)* pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 max rx packet len: 15872 promiscuous: unicast on all-multicast on vlan offload: strip off filter off qinq off rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro macsec-strip vlan-filter vlan-extend jumbo-frame scatter security keep-crc rx offload active: ipv4-cksum tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum tcp-tso macsec-insert multi-segs security tx offload active: none rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex ipv6-tcp ipv6-udp ipv6-ex ipv6 rss active:none tx burst function: (nil) rx burst function: ixgbe_recv_pkts_vec vpp# testpmd shows that interface is up. testpmd> show port summary 1 Number of available ports: 2 Port MAC Address Name Driver Status Link *1B4:96:91:23:1E:D6 :06:00.1 net_ixgbe up 1Mbps* testpmd> On Fri, Oct 18, 2019 at 8:16 PM Steven Luong (sluong) wrote: > Can you reduce your rx and tx queues to 1 and try again? > > > > rx: queues 2 (max 128), desc 512 (min 32 max 4096 align 8) > tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) > > Steven > > > > *From: * on behalf of "Chuan Han via Lists.Fd.Io" > > *Reply-To: *"chuan...@google.com" > *Date: *Friday, October 18, 2019 at 4:05 PM > *To: *Chuan Han > *Cc: *"vpp-dev@lists.fd.io" > *Subject: *Re: [vpp-dev] Basic l2 bridging does not work > > > > Hi, Damjan, > > > > It seems the bug is in vpp. > > > > On R230, vpp shows eth0 is down. > > > > vpp# sh hardware-interfaces eth0 > NameIdx Link Hardware > eth0 2down eth0 > Link speed: unknown > > > * Ethernet address b4:96:91:23:1e:d6 Intel 82599 carrier down* > flags: admin-up promisc pmd rx-ip4-cksum > rx: queues 2 (max 128), desc 512 (min 32 max 4096 align 8) > tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) > pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 > max rx packet len: 15872 > promiscuous: unicast on all-multicast on > vlan offload: strip off filter off qinq off > rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro >macsec-strip vlan-filter vlan-extend jumbo-frame > scatter >security keep-crc > rx offload active: ipv4-cksum > tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum > sctp-cksum >tcp-tso macsec-insert multi-segs security > tx offload active: none > rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex > ipv6-tcp >ipv6-udp ipv6-ex ipv6 > rss active:none > tx burst function: (nil) > rx burst function: ixgbe_recv_pkts_vec > > extended stats: > mac local errors 318 > vpp# > > > > However, the testpmd tool shows it is up. > > > > testpmd> show port summary 1 > Number of available ports: 2 > Port MAC Address Name Driver Status Link > *1B4:96:91:23:1E:D6 :06:00.1 net_ixgbe up 1Mbps* > testpmd> > > > > Does this prove something wrong on vpp side? > > > > Thanks. > > Chuan > > > > On Fri, Oct 18, 2019 at 3:06 PM Chuan Han wrote: > > I built testpmd binary on both r740 and r230, and ran the test. I did see > testpmd reports some link status change on r230 server. testpmd report on > r740 is stabler. no status change reported. > > > > r230 log > > > > Press enter to exit > > Port 0: link state change event > > Port 1: link state change event > > Port 1: link state change event > > r740 log > > > > Press enter to exitx0 - TX RS bit threshold=32 > > If it is a dpdk bug, what shall I do? Report to dpdk mailing list? > > > > On Fri, Oct 18, 2019 at 11:55 AM Chuan Han via Lists.Fd.Io google@lists.fd.io> wrote: > > So, it is
Re: [vpp-dev] Basic l2 bridging does not work
two nics to be successfully added to the same vpp >>>>>>> instance, it seems to be a bug. Is it something which can be easily >>>>>>> spotted in the code base? >>>>>>> >>>>>>> It is also not possible to enforce symmetricity on internet. The other >>>>>>> party can do anything as long as basic ping works. >>>>>>> >>>>>>> On Thu, Oct 17, 2019 at 3:55 PM Chuan Han wrote: >>>>>>>> If I only put one phy nic, i.e., eth0, to vpp, 'sh hardware' shows it >>>>>>>> is up. If I put both eth0 and eth1 in vpp, eth0 is always down. It >>>>>>>> seems something is wrong with the nic or vpp does not support this >>>>>>>> type of hardware? >>>>>>>> >>>>>>>> We tried enabling autoneg on R230. It is not allowed. To avoid >>>>>>>> asymmetric settings, disabling autoneg on R740 will help? >>>>>>>> >>>>>>>> On Thu, Oct 17, 2019 at 3:46 PM Balaji Venkatraman (balajiv) >>>>>>>> wrote: >>>>>>>>> It plays a role if it is asymmetric at both ends. You could enable it >>>>>>>>> at both ends and check. >>>>>>>>> >>>>>>>>>> On Oct 17, 2019, at 3:15 PM, Chuan Han wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I rebooted the r230 machine and found the phy nic corresponding to >>>>>>>>>> eth has autoneg off. >>>>>>>>>> >>>>>>>>>> root@esdn-relay:~/gnxi/perf_testing/r230# ethtool enp6s0f1 >>>>>>>>>> Settings for enp6s0f1: >>>>>>>>>> Supported ports: [ FIBRE ] >>>>>>>>>> Supported link modes: 1baseT/Full >>>>>>>>>> Supported pause frame use: Symmetric >>>>>>>>>> Supports auto-negotiation: No >>>>>>>>>> Supported FEC modes: Not reported >>>>>>>>>> Advertised link modes: 1baseT/Full >>>>>>>>>> Advertised pause frame use: Symmetric >>>>>>>>>> Advertised auto-negotiation: No >>>>>>>>>> Advertised FEC modes: Not reported >>>>>>>>>> Speed: 1Mb/s >>>>>>>>>> Duplex: Full >>>>>>>>>> Port: Direct Attach Copper >>>>>>>>>> PHYAD: 0 >>>>>>>>>> Transceiver: internal >>>>>>>>>> Auto-negotiation: off >>>>>>>>>> Supports Wake-on: d >>>>>>>>>> Wake-on: d >>>>>>>>>> Current message level: 0x0007 (7) >>>>>>>>>>drv probe link >>>>>>>>>> Link detected: yes >>>>>>>>>> root@esdn-relay:~/gnxi/perf_testing/r230# >>>>>>>>>> >>>>>>>>>> On r740, autoneg is on. It is copper. >>>>>>>>>> >>>>>>>>>> root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ethtool eno3 >>>>>>>>>> Settings for eno3: >>>>>>>>>> Supported ports: [ TP ] >>>>>>>>>> Supported link modes: 100baseT/Full >>>>>>>>>> 1000baseT/Full >>>>>>>>>> 1baseT/Full >>>>>>>>>> Supported pause frame use: Symmetric >>>>>>>>>> Supports auto-negotiation: Yes >>>>>>>>>> Supported FEC modes: Not reported >>>>>>>>>> Advertised link modes: 100baseT/Full >>>>>>>>>> 1000baseT/Full >>>>>>>>>> 1baseT/Full >>>>>>>>>> Advertised pause frame use: Symmetric >>>>>>>>>> Advertised auto-negotiation: Yes >>>
Re: [vpp-dev] Basic l2 bridging does not work
nic or vpp does not support this type of >>>>> hardware? >>>>> >>>>> We tried enabling autoneg on R230. It is not allowed. To avoid >>>>> asymmetric settings, disabling autoneg on R740 will help? >>>>> >>>>> On Thu, Oct 17, 2019 at 3:46 PM Balaji Venkatraman (balajiv) < >>>>> bala...@cisco.com> wrote: >>>>> >>>>>> It plays a role if it is asymmetric at both ends. You could enable it >>>>>> at both ends and check. >>>>>> >>>>>> On Oct 17, 2019, at 3:15 PM, Chuan Han wrote: >>>>>> >>>>>> >>>>>> I rebooted the r230 machine and found the phy nic corresponding to >>>>>> eth has autoneg off. >>>>>> >>>>>> root@esdn-relay:~/gnxi/perf_testing/r230# ethtool enp6s0f1 >>>>>> Settings for enp6s0f1: >>>>>> Supported ports: [ FIBRE ] >>>>>> Supported link modes: 1baseT/Full >>>>>> Supported pause frame use: Symmetric >>>>>> Supports auto-negotiation: No >>>>>> Supported FEC modes: Not reported >>>>>> Advertised link modes: 1baseT/Full >>>>>> Advertised pause frame use: Symmetric >>>>>> Advertised auto-negotiation: No >>>>>> Advertised FEC modes: Not reported >>>>>> Speed: 1Mb/s >>>>>> Duplex: Full >>>>>> *Port: Direct Attach Copper* >>>>>> PHYAD: 0 >>>>>> Transceiver: internal >>>>>> *Auto-negotiation: off* >>>>>> Supports Wake-on: d >>>>>> Wake-on: d >>>>>> Current message level: 0x0007 (7) >>>>>>drv probe link >>>>>> Link detected: yes >>>>>> root@esdn-relay:~/gnxi/perf_testing/r230# >>>>>> >>>>>> On r740, autoneg is on. It is copper. >>>>>> >>>>>> root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ethtool eno3 >>>>>> Settings for eno3: >>>>>> Supported ports: [ TP ] >>>>>> Supported link modes: 100baseT/Full >>>>>> 1000baseT/Full >>>>>> 1baseT/Full >>>>>> Supported pause frame use: Symmetric >>>>>> Supports auto-negotiation: Yes >>>>>> Supported FEC modes: Not reported >>>>>> Advertised link modes: 100baseT/Full >>>>>> 1000baseT/Full >>>>>> 1baseT/Full >>>>>> Advertised pause frame use: Symmetric >>>>>> Advertised auto-negotiation: Yes >>>>>> Advertised FEC modes: Not reported >>>>>> Speed: 10000Mb/s >>>>>> Duplex: Full >>>>>> *Port: Twisted Pair* >>>>>> PHYAD: 0 >>>>>> Transceiver: internal >>>>>> *Auto-negotiation: on* >>>>>> MDI-X: Unknown >>>>>> Supports Wake-on: umbg >>>>>> Wake-on: g >>>>>> Current message level: 0x0007 (7) >>>>>>drv probe link >>>>>> Link detected: yes >>>>>> root@esdn-lab:~/gnxi/perf_testing/r740/vpp# >>>>>> >>>>>> not clear if this plays a role or not. >>>>>> >>>>>> On Thu, Oct 17, 2019 at 2:41 PM Chuan Han via Lists.Fd.Io >>>>>> <http://lists.fd.io/> wrote: >>>>>> >>>>>>> Restarting ixia controller does not help. We ended up with both ixia >>>>>>> ports having '!'. >>>>>>> >>>>>>> We are not sure how ixia port plays a role here. eth0 interfaces are >>>>>>> the interfaces connecting two servers, not to ixia. >>>>>>> >>>>>>> On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) < >>>>>>> bala...@cisco.com> wrote: >>>>>>>
Re: [vpp-dev] Basic l2 bridging does not work
ected: yes >>>>> root@esdn-relay:~/gnxi/perf_testing/r230# >>>>> >>>>> On r740, autoneg is on. It is copper. >>>>> >>>>> root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ethtool eno3 >>>>> Settings for eno3: >>>>> Supported ports: [ TP ] >>>>> Supported link modes: 100baseT/Full >>>>> 1000baseT/Full >>>>> 1baseT/Full >>>>> Supported pause frame use: Symmetric >>>>> Supports auto-negotiation: Yes >>>>> Supported FEC modes: Not reported >>>>> Advertised link modes: 100baseT/Full >>>>> 1000baseT/Full >>>>> 1baseT/Full >>>>> Advertised pause frame use: Symmetric >>>>> Advertised auto-negotiation: Yes >>>>> Advertised FEC modes: Not reported >>>>> Speed: 1Mb/s >>>>> Duplex: Full >>>>> *Port: Twisted Pair* >>>>> PHYAD: 0 >>>>> Transceiver: internal >>>>> *Auto-negotiation: on* >>>>> MDI-X: Unknown >>>>> Supports Wake-on: umbg >>>>> Wake-on: g >>>>> Current message level: 0x0007 (7) >>>>>drv probe link >>>>> Link detected: yes >>>>> root@esdn-lab:~/gnxi/perf_testing/r740/vpp# >>>>> >>>>> not clear if this plays a role or not. >>>>> >>>>> On Thu, Oct 17, 2019 at 2:41 PM Chuan Han via Lists.Fd.Io >>>>> <http://lists.fd.io/> wrote: >>>>> >>>>>> Restarting ixia controller does not help. We ended up with both ixia >>>>>> ports having '!'. >>>>>> >>>>>> We are not sure how ixia port plays a role here. eth0 interfaces are >>>>>> the interfaces connecting two servers, not to ixia. >>>>>> >>>>>> On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) < >>>>>> bala...@cisco.com> wrote: >>>>>> >>>>>>> Hi Chuan, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Could you please try to reset the ixia controller connected to port >>>>>>> 4? >>>>>>> >>>>>>> I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is >>>>>>> down, I suspect the ixia port. >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Balaji. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From: *Chuan Han >>>>>>> *Date: *Thursday, October 17, 2019 at 11:09 AM >>>>>>> *To: *"Balaji Venkatraman (balajiv)" >>>>>>> *Cc: *"vpp-dev@lists.fd.io" , Arivudainambi >>>>>>> Appachi gounder , Jerry Cen >>>>>> > >>>>>>> *Subject: *Re: [vpp-dev] Basic l2 bridging does not work >>>>>>> >>>>>>> >>>>>>> >>>>>>> Yes. It is unidirectional stream from port 1 to port 4. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Another engineer, Nambi, configured ixia. What he showed me >>>>>>> yesterday is that xia port connected to port 1 is green and good. ixia >>>>>>> port >>>>>>> connected to port 4 is green but has a red exclamation mark, which means >>>>>>> ping does not work. >>>>>>> >>>>>>> >>>>>>> >>>>>>> We also found eth0 on R230 is down shown by "show hardware eth0" >>>>>>> command. However "show int" shows it is up. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> vpp# sh hardware-interfaces eth0 >>
Re: [vpp-dev] Basic l2 bridging does not work
d auto-negotiation: Yes >>>> Advertised FEC modes: Not reported >>>> Speed: 1Mb/s >>>> Duplex: Full >>>> *Port: Twisted Pair* >>>> PHYAD: 0 >>>> Transceiver: internal >>>> *Auto-negotiation: on* >>>> MDI-X: Unknown >>>> Supports Wake-on: umbg >>>> Wake-on: g >>>> Current message level: 0x0007 (7) >>>>drv probe link >>>> Link detected: yes >>>> root@esdn-lab:~/gnxi/perf_testing/r740/vpp# >>>> >>>> not clear if this plays a role or not. >>>> >>>> On Thu, Oct 17, 2019 at 2:41 PM Chuan Han via Lists.Fd.Io >>>> <http://lists.fd.io/> wrote: >>>> >>>>> Restarting ixia controller does not help. We ended up with both ixia >>>>> ports having '!'. >>>>> >>>>> We are not sure how ixia port plays a role here. eth0 interfaces are >>>>> the interfaces connecting two servers, not to ixia. >>>>> >>>>> On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) < >>>>> bala...@cisco.com> wrote: >>>>> >>>>>> Hi Chuan, >>>>>> >>>>>> >>>>>> >>>>>> Could you please try to reset the ixia controller connected to port 4? >>>>>> >>>>>> I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is >>>>>> down, I suspect the ixia port. >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Regards, >>>>>> >>>>>> Balaji. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From: *Chuan Han >>>>>> *Date: *Thursday, October 17, 2019 at 11:09 AM >>>>>> *To: *"Balaji Venkatraman (balajiv)" >>>>>> *Cc: *"vpp-dev@lists.fd.io" , Arivudainambi >>>>>> Appachi gounder , Jerry Cen >>>>>> *Subject: *Re: [vpp-dev] Basic l2 bridging does not work >>>>>> >>>>>> >>>>>> >>>>>> Yes. It is unidirectional stream from port 1 to port 4. >>>>>> >>>>>> >>>>>> >>>>>> Another engineer, Nambi, configured ixia. What he showed me yesterday >>>>>> is that xia port connected to port 1 is green and good. ixia port >>>>>> connected >>>>>> to port 4 is green but has a red exclamation mark, which means ping does >>>>>> not work. >>>>>> >>>>>> >>>>>> >>>>>> We also found eth0 on R230 is down shown by "show hardware eth0" >>>>>> command. However "show int" shows it is up. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> vpp# sh hardware-interfaces eth0 >>>>>> NameIdx Link Hardware >>>>>> eth0 2down eth0 >>>>>> Link speed: unknown >>>>>> Ethernet address b4:96:91:23:1e:d6 >>>>>> Intel 82599 >>>>>> carrier down >>>>>> flags: admin-up promisc pmd rx-ip4-cksum >>>>>> rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8) >>>>>> tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) >>>>>> pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 >>>>>> numa 0 >>>>>> max rx packet len: 15872 >>>>>> promiscuous: unicast on all-multicast on >>>>>> vlan offload: strip off filter off qinq off >>>>>> rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum >>>>>> tcp-lro >>>>>>macsec-strip vlan-filter vlan-extend >>>>>> jumbo-frame scatter >>>>>>security keep-crc >>>>>> rx offload active: ipv4-cksum >>>>>> tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum >>>>>> sctp-cksum >>
Re: [vpp-dev] Basic l2 bridging does not work
ke-on: umbg >>> Wake-on: g >>> Current message level: 0x0007 (7) >>>drv probe link >>> Link detected: yes >>> root@esdn-lab:~/gnxi/perf_testing/r740/vpp# >>> >>> not clear if this plays a role or not. >>> >>> On Thu, Oct 17, 2019 at 2:41 PM Chuan Han via Lists.Fd.Io >>> <http://lists.fd.io/> >> <mailto:google@lists.fd.io>> wrote: >>> Restarting ixia controller does not help. We ended up with both ixia ports >>> having '!'. >>> >>> We are not sure how ixia port plays a role here. eth0 interfaces are the >>> interfaces connecting two servers, not to ixia. >>> >>> On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) >>> mailto:bala...@cisco.com>> wrote: >>> Hi Chuan, >>> >>> >>> >>> Could you please try to reset the ixia controller connected to port 4? >>> >>> I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is down, I >>> suspect the ixia port. >>> >>> >>> >>> -- >>> >>> Regards, >>> >>> Balaji. >>> >>> >>> >>> >>> >>> From: Chuan Han mailto:chuan...@google.com>> >>> Date: Thursday, October 17, 2019 at 11:09 AM >>> To: "Balaji Venkatraman (balajiv)" >> <mailto:bala...@cisco.com>> >>> Cc: "vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>" >> <mailto:vpp-dev@lists.fd.io>>, Arivudainambi Appachi gounder >>> mailto:aappa...@google.com>>, Jerry Cen >>> mailto:zhiw...@google.com>> >>> Subject: Re: [vpp-dev] Basic l2 bridging does not work >>> >>> >>> >>> Yes. It is unidirectional stream from port 1 to port 4. >>> >>> >>> >>> Another engineer, Nambi, configured ixia. What he showed me yesterday is >>> that xia port connected to port 1 is green and good. ixia port connected to >>> port 4 is green but has a red exclamation mark, which means ping does not >>> work. >>> >>> >>> >>> We also found eth0 on R230 is down shown by "show hardware eth0" command. >>> However "show int" shows it is up. >>> >>> >>> >>> >>> >>> vpp# sh hardware-interfaces eth0 >>> NameIdx Link Hardware >>> eth0 2down eth0 >>> Link speed: unknown >>> Ethernet address b4:96:91:23:1e:d6 >>> Intel 82599 >>> carrier down >>> flags: admin-up promisc pmd rx-ip4-cksum >>> rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8) >>> tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) >>> pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 >>> max rx packet len: 15872 >>> promiscuous: unicast on all-multicast on >>> vlan offload: strip off filter off qinq off >>> rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro >>>macsec-strip vlan-filter vlan-extend jumbo-frame >>> scatter >>>security keep-crc >>> rx offload active: ipv4-cksum >>> tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum >>> sctp-cksum >>>tcp-tso macsec-insert multi-segs security >>> tx offload active: none >>> rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex >>> ipv6-tcp >>>ipv6-udp ipv6-ex ipv6 >>> rss active:none >>> tx burst function: (nil) >>> rx burst function: ixgbe_recv_pkts_vec >>> >>> rx frames ok 33278 >>> rx bytes ok 3960082 >>> extended stats: >>> rx good packets 33278 >>> rx good bytes 3960082 >>> rx q0packets 33278 >>> rx q0bytes 3960082 >>> rx size 65 to 127 packets33278 >>> rx multicast packets 33278 >>> rx total packets
Re: [vpp-dev] Basic l2 bridging does not work
t;>>> Restarting ixia controller does not help. We ended up with both ixia >>>> ports having '!'. >>>> >>>> We are not sure how ixia port plays a role here. eth0 interfaces are >>>> the interfaces connecting two servers, not to ixia. >>>> >>>> On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) < >>>> bala...@cisco.com> wrote: >>>> >>>>> Hi Chuan, >>>>> >>>>> >>>>> >>>>> Could you please try to reset the ixia controller connected to port 4? >>>>> >>>>> I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is >>>>> down, I suspect the ixia port. >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> Regards, >>>>> >>>>> Balaji. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From: *Chuan Han >>>>> *Date: *Thursday, October 17, 2019 at 11:09 AM >>>>> *To: *"Balaji Venkatraman (balajiv)" >>>>> *Cc: *"vpp-dev@lists.fd.io" , Arivudainambi >>>>> Appachi gounder , Jerry Cen >>>>> *Subject: *Re: [vpp-dev] Basic l2 bridging does not work >>>>> >>>>> >>>>> >>>>> Yes. It is unidirectional stream from port 1 to port 4. >>>>> >>>>> >>>>> >>>>> Another engineer, Nambi, configured ixia. What he showed me yesterday >>>>> is that xia port connected to port 1 is green and good. ixia port >>>>> connected >>>>> to port 4 is green but has a red exclamation mark, which means ping does >>>>> not work. >>>>> >>>>> >>>>> >>>>> We also found eth0 on R230 is down shown by "show hardware eth0" >>>>> command. However "show int" shows it is up. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> vpp# sh hardware-interfaces eth0 >>>>> NameIdx Link Hardware >>>>> eth0 2down eth0 >>>>> Link speed: unknown >>>>> Ethernet address b4:96:91:23:1e:d6 >>>>> Intel 82599 >>>>> carrier down >>>>> flags: admin-up promisc pmd rx-ip4-cksum >>>>> rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8) >>>>> tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) >>>>> pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 >>>>> numa 0 >>>>> max rx packet len: 15872 >>>>> promiscuous: unicast on all-multicast on >>>>> vlan offload: strip off filter off qinq off >>>>> rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum >>>>> tcp-lro >>>>>macsec-strip vlan-filter vlan-extend >>>>> jumbo-frame scatter >>>>>security keep-crc >>>>> rx offload active: ipv4-cksum >>>>> tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum >>>>> sctp-cksum >>>>>tcp-tso macsec-insert multi-segs security >>>>> tx offload active: none >>>>> rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex >>>>> ipv6-tcp >>>>>ipv6-udp ipv6-ex ipv6 >>>>> rss active:none >>>>> tx burst function: (nil) >>>>> rx burst function: ixgbe_recv_pkts_vec >>>>> >>>>> rx frames ok 33278 >>>>> rx bytes ok 3960082 >>>>> extended stats: >>>>> rx good packets 33278 >>>>> rx good bytes 3960082 >>>>> rx q0packets 33278 >>>>> rx q0bytes 3960082 >>>>> rx size 65 to 127 packets33278 >>>>> rx multicast packets 33278 >>>>>
Re: [vpp-dev] Basic l2 bridging does not work
This looks like a DPDK issue, but I’ll let Damjan be the judge of that. To see if this is a config issues, could you simplify your startup config by - removing “workers 0” from the two nics and adding “num-rx-queues 2” to the nics or to the default stanza, if you’re running with 2 workers - comment out the cryptodev config If the two nics don’t come up, check if there’s any obvious dpdk error in “show log”. Florin > On Oct 17, 2019, at 4:56 PM, Chuan Han via Lists.Fd.Io > wrote: > > I tried disabling autoneg on R740 side. It is not allowed too. If vpp cannot > allow two nics to be successfully added to the same vpp instance, it seems to > be a bug. Is it something which can be easily spotted in the code base? > > It is also not possible to enforce symmetricity on internet. The other party > can do anything as long as basic ping works. > > On Thu, Oct 17, 2019 at 3:55 PM Chuan Han <mailto:chuan...@google.com>> wrote: > If I only put one phy nic, i.e., eth0, to vpp, 'sh hardware' shows it is up. > If I put both eth0 and eth1 in vpp, eth0 is always down. It seems something > is wrong with the nic or vpp does not support this type of hardware? > > We tried enabling autoneg on R230. It is not allowed. To avoid asymmetric > settings, disabling autoneg on R740 will help? > > On Thu, Oct 17, 2019 at 3:46 PM Balaji Venkatraman (balajiv) > mailto:bala...@cisco.com>> wrote: > It plays a role if it is asymmetric at both ends. You could enable it at both > ends and check. > >> On Oct 17, 2019, at 3:15 PM, Chuan Han > <mailto:chuan...@google.com>> wrote: >> >> >> I rebooted the r230 machine and found the phy nic corresponding to eth has >> autoneg off. >> >> root@esdn-relay:~/gnxi/perf_testing/r230# ethtool enp6s0f1 >> Settings for enp6s0f1: >> Supported ports: [ FIBRE ] >> Supported link modes: 1baseT/Full >> Supported pause frame use: Symmetric >> Supports auto-negotiation: No >> Supported FEC modes: Not reported >> Advertised link modes: 1baseT/Full >> Advertised pause frame use: Symmetric >> Advertised auto-negotiation: No >> Advertised FEC modes: Not reported >> Speed: 1Mb/s >> Duplex: Full >> Port: Direct Attach Copper >> PHYAD: 0 >> Transceiver: internal >> Auto-negotiation: off >> Supports Wake-on: d >> Wake-on: d >> Current message level: 0x0007 (7) >>drv probe link >> Link detected: yes >> root@esdn-relay:~/gnxi/perf_testing/r230# >> >> On r740, autoneg is on. It is copper. >> >> root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ethtool eno3 >> Settings for eno3: >> Supported ports: [ TP ] >> Supported link modes: 100baseT/Full >> 1000baseT/Full >> 1baseT/Full >> Supported pause frame use: Symmetric >> Supports auto-negotiation: Yes >> Supported FEC modes: Not reported >> Advertised link modes: 100baseT/Full >> 1000baseT/Full >> 1baseT/Full >> Advertised pause frame use: Symmetric >> Advertised auto-negotiation: Yes >> Advertised FEC modes: Not reported >> Speed: 1Mb/s >> Duplex: Full >> Port: Twisted Pair >> PHYAD: 0 >> Transceiver: internal >> Auto-negotiation: on >> MDI-X: Unknown >> Supports Wake-on: umbg >> Wake-on: g >> Current message level: 0x0007 (7) >>drv probe link >> Link detected: yes >> root@esdn-lab:~/gnxi/perf_testing/r740/vpp# >> >> not clear if this plays a role or not. >> >> On Thu, Oct 17, 2019 at 2:41 PM Chuan Han via Lists.Fd.Io >> <http://lists.fd.io/> > <mailto:google@lists.fd.io>> wrote: >> Restarting ixia controller does not help. We ended up with both ixia ports >> having '!'. >> >> We are not sure how ixia port plays a role here. eth0 interfaces are the >> interfaces connecting two servers, not to ixia. >> >> On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) >> mailto:bala...@cisco.com>> wrote: >> Hi Chuan, >> >> >> >> Could you please try to reset the ixia controller connected to port 4? >> &
Re: [vpp-dev] Basic l2 bridging does not work
I tried disabling autoneg on R740 side. It is not allowed too. If vpp cannot allow two nics to be successfully added to the same vpp instance, it seems to be a bug. Is it something which can be easily spotted in the code base? It is also not possible to enforce symmetricity on internet. The other party can do anything as long as basic ping works. On Thu, Oct 17, 2019 at 3:55 PM Chuan Han wrote: > If I only put one phy nic, i.e., eth0, to vpp, 'sh hardware' shows it is > up. If I put both eth0 and eth1 in vpp, eth0 is always down. It seems > something is wrong with the nic or vpp does not support this type of > hardware? > > We tried enabling autoneg on R230. It is not allowed. To avoid asymmetric > settings, disabling autoneg on R740 will help? > > On Thu, Oct 17, 2019 at 3:46 PM Balaji Venkatraman (balajiv) < > bala...@cisco.com> wrote: > >> It plays a role if it is asymmetric at both ends. You could enable it at >> both ends and check. >> >> On Oct 17, 2019, at 3:15 PM, Chuan Han wrote: >> >> >> I rebooted the r230 machine and found the phy nic corresponding to eth >> has autoneg off. >> >> root@esdn-relay:~/gnxi/perf_testing/r230# ethtool enp6s0f1 >> Settings for enp6s0f1: >> Supported ports: [ FIBRE ] >> Supported link modes: 1baseT/Full >> Supported pause frame use: Symmetric >> Supports auto-negotiation: No >> Supported FEC modes: Not reported >> Advertised link modes: 1baseT/Full >> Advertised pause frame use: Symmetric >> Advertised auto-negotiation: No >> Advertised FEC modes: Not reported >> Speed: 1Mb/s >> Duplex: Full >> *Port: Direct Attach Copper* >> PHYAD: 0 >> Transceiver: internal >> *Auto-negotiation: off* >> Supports Wake-on: d >> Wake-on: d >> Current message level: 0x0007 (7) >>drv probe link >> Link detected: yes >> root@esdn-relay:~/gnxi/perf_testing/r230# >> >> On r740, autoneg is on. It is copper. >> >> root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ethtool eno3 >> Settings for eno3: >> Supported ports: [ TP ] >> Supported link modes: 100baseT/Full >> 1000baseT/Full >> 1baseT/Full >> Supported pause frame use: Symmetric >> Supports auto-negotiation: Yes >> Supported FEC modes: Not reported >> Advertised link modes: 100baseT/Full >> 1000baseT/Full >> 1baseT/Full >> Advertised pause frame use: Symmetric >> Advertised auto-negotiation: Yes >> Advertised FEC modes: Not reported >> Speed: 1Mb/s >> Duplex: Full >> *Port: Twisted Pair* >> PHYAD: 0 >> Transceiver: internal >> *Auto-negotiation: on* >> MDI-X: Unknown >> Supports Wake-on: umbg >> Wake-on: g >> Current message level: 0x0007 (7) >>drv probe link >> Link detected: yes >> root@esdn-lab:~/gnxi/perf_testing/r740/vpp# >> >> not clear if this plays a role or not. >> >> On Thu, Oct 17, 2019 at 2:41 PM Chuan Han via Lists.Fd.Io > google@lists.fd.io> wrote: >> >>> Restarting ixia controller does not help. We ended up with both ixia >>> ports having '!'. >>> >>> We are not sure how ixia port plays a role here. eth0 interfaces are the >>> interfaces connecting two servers, not to ixia. >>> >>> On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) < >>> bala...@cisco.com> wrote: >>> >>>> Hi Chuan, >>>> >>>> >>>> >>>> Could you please try to reset the ixia controller connected to port 4? >>>> >>>> I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is >>>> down, I suspect the ixia port. >>>> >>>> >>>> >>>> -- >>>> >>>> Regards, >>>> >>>> Balaji. >>>> >>>> >>>> >>>> >>>> >>>> *From: *Chuan Han >>>> *Date: *Thursday, October 17, 2019 at 11:09 AM >>>> *To: *"Balaji Venkatraman (balajiv)" >>>> *Cc: *"vpp-dev@lists.fd.io" , Arivudainamb
Re: [vpp-dev] Basic l2 bridging does not work
If I only put one phy nic, i.e., eth0, to vpp, 'sh hardware' shows it is up. If I put both eth0 and eth1 in vpp, eth0 is always down. It seems something is wrong with the nic or vpp does not support this type of hardware? We tried enabling autoneg on R230. It is not allowed. To avoid asymmetric settings, disabling autoneg on R740 will help? On Thu, Oct 17, 2019 at 3:46 PM Balaji Venkatraman (balajiv) < bala...@cisco.com> wrote: > It plays a role if it is asymmetric at both ends. You could enable it at > both ends and check. > > On Oct 17, 2019, at 3:15 PM, Chuan Han wrote: > > > I rebooted the r230 machine and found the phy nic corresponding to eth has > autoneg off. > > root@esdn-relay:~/gnxi/perf_testing/r230# ethtool enp6s0f1 > Settings for enp6s0f1: > Supported ports: [ FIBRE ] > Supported link modes: 1baseT/Full > Supported pause frame use: Symmetric > Supports auto-negotiation: No > Supported FEC modes: Not reported > Advertised link modes: 1baseT/Full > Advertised pause frame use: Symmetric > Advertised auto-negotiation: No > Advertised FEC modes: Not reported > Speed: 1Mb/s > Duplex: Full > *Port: Direct Attach Copper* > PHYAD: 0 > Transceiver: internal > *Auto-negotiation: off* > Supports Wake-on: d > Wake-on: d > Current message level: 0x0007 (7) >drv probe link > Link detected: yes > root@esdn-relay:~/gnxi/perf_testing/r230# > > On r740, autoneg is on. It is copper. > > root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ethtool eno3 > Settings for eno3: > Supported ports: [ TP ] > Supported link modes: 100baseT/Full > 1000baseT/Full > 1baseT/Full > Supported pause frame use: Symmetric > Supports auto-negotiation: Yes > Supported FEC modes: Not reported > Advertised link modes: 100baseT/Full > 1000baseT/Full > 1baseT/Full > Advertised pause frame use: Symmetric > Advertised auto-negotiation: Yes > Advertised FEC modes: Not reported > Speed: 1Mb/s > Duplex: Full > *Port: Twisted Pair* > PHYAD: 0 > Transceiver: internal > *Auto-negotiation: on* > MDI-X: Unknown > Supports Wake-on: umbg > Wake-on: g > Current message level: 0x0007 (7) >drv probe link > Link detected: yes > root@esdn-lab:~/gnxi/perf_testing/r740/vpp# > > not clear if this plays a role or not. > > On Thu, Oct 17, 2019 at 2:41 PM Chuan Han via Lists.Fd.Io google@lists.fd.io> wrote: > >> Restarting ixia controller does not help. We ended up with both ixia >> ports having '!'. >> >> We are not sure how ixia port plays a role here. eth0 interfaces are the >> interfaces connecting two servers, not to ixia. >> >> On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) < >> bala...@cisco.com> wrote: >> >>> Hi Chuan, >>> >>> >>> >>> Could you please try to reset the ixia controller connected to port 4? >>> >>> I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is down, >>> I suspect the ixia port. >>> >>> >>> >>> -- >>> >>> Regards, >>> >>> Balaji. >>> >>> >>> >>> >>> >>> *From: *Chuan Han >>> *Date: *Thursday, October 17, 2019 at 11:09 AM >>> *To: *"Balaji Venkatraman (balajiv)" >>> *Cc: *"vpp-dev@lists.fd.io" , Arivudainambi >>> Appachi gounder , Jerry Cen >>> *Subject: *Re: [vpp-dev] Basic l2 bridging does not work >>> >>> >>> >>> Yes. It is unidirectional stream from port 1 to port 4. >>> >>> >>> >>> Another engineer, Nambi, configured ixia. What he showed me yesterday is >>> that xia port connected to port 1 is green and good. ixia port connected to >>> port 4 is green but has a red exclamation mark, which means ping does not >>> work. >>> >>> >>> >>> We also found eth0 on R230 is down shown by "show hardware eth0" >>> command. However "show int" shows it is up. >>> >>> >>> >>> >>> >>> vpp# sh hardware-interfaces eth0 >>>
Re: [vpp-dev] Basic l2 bridging does not work
It plays a role if it is asymmetric at both ends. You could enable it at both ends and check. On Oct 17, 2019, at 3:15 PM, Chuan Han wrote: I rebooted the r230 machine and found the phy nic corresponding to eth has autoneg off. root@esdn-relay:~/gnxi/perf_testing/r230# ethtool enp6s0f1 Settings for enp6s0f1: Supported ports: [ FIBRE ] Supported link modes: 1baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: 1baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 1Mb/s Duplex: Full Port: Direct Attach Copper PHYAD: 0 Transceiver: internal Auto-negotiation: off Supports Wake-on: d Wake-on: d Current message level: 0x0007 (7) drv probe link Link detected: yes root@esdn-relay:~/gnxi/perf_testing/r230# On r740, autoneg is on. It is copper. root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ethtool eno3 Settings for eno3: Supported ports: [ TP ] Supported link modes: 100baseT/Full 1000baseT/Full 1baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 100baseT/Full 1000baseT/Full 1baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: 1Mb/s Duplex: Full Port: Twisted Pair PHYAD: 0 Transceiver: internal Auto-negotiation: on MDI-X: Unknown Supports Wake-on: umbg Wake-on: g Current message level: 0x0007 (7) drv probe link Link detected: yes root@esdn-lab:~/gnxi/perf_testing/r740/vpp# not clear if this plays a role or not. On Thu, Oct 17, 2019 at 2:41 PM Chuan Han via Lists.Fd.Io<http://Lists.Fd.Io> mailto:google@lists.fd.io>> wrote: Restarting ixia controller does not help. We ended up with both ixia ports having '!'. We are not sure how ixia port plays a role here. eth0 interfaces are the interfaces connecting two servers, not to ixia. On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) mailto:bala...@cisco.com>> wrote: Hi Chuan, Could you please try to reset the ixia controller connected to port 4? I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is down, I suspect the ixia port. -- Regards, Balaji. From: Chuan Han mailto:chuan...@google.com>> Date: Thursday, October 17, 2019 at 11:09 AM To: "Balaji Venkatraman (balajiv)" mailto:bala...@cisco.com>> Cc: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" mailto:vpp-dev@lists.fd.io>>, Arivudainambi Appachi gounder mailto:aappa...@google.com>>, Jerry Cen mailto:zhiw...@google.com>> Subject: Re: [vpp-dev] Basic l2 bridging does not work Yes. It is unidirectional stream from port 1 to port 4. Another engineer, Nambi, configured ixia. What he showed me yesterday is that xia port connected to port 1 is green and good. ixia port connected to port 4 is green but has a red exclamation mark, which means ping does not work. We also found eth0 on R230 is down shown by "show hardware eth0" command. However "show int" shows it is up. vpp# sh hardware-interfaces eth0 NameIdx Link Hardware eth0 2down eth0 Link speed: unknown Ethernet address b4:96:91:23:1e:d6 Intel 82599 carrier down flags: admin-up promisc pmd rx-ip4-cksum rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8) tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 max rx packet len: 15872 promiscuous: unicast on all-multicast on vlan offload: strip off filter off qinq off rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro macsec-strip vlan-filter vlan-extend jumbo-frame scatter security keep-crc rx offload active: ipv4-cksum tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum tcp-tso macsec-insert multi-segs security tx offload active: none rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex ipv6-tcp ipv6-udp ipv6-ex ipv6 rss active:none tx burst function: (nil) rx burst function: ixgbe_recv_pkts_vec rx frames ok 33278 rx b
Re: [vpp-dev] Basic l2 bridging does not work
When two interfaces are in the linux, ping works. On R740, we have root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ip a s eno3 4: eno3: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 24:6e:96:b4:b2:06 brd ff:ff:ff:ff:ff:ff inet 10.10.10.11/24 scope global eno3 valid_lft forever preferred_lft forever inet6 fe80::266e:96ff:feb4:b206/64 scope link valid_lft forever preferred_lft forever root@esdn-lab:~/gnxi/perf_testing/r740/vpp# On R230, we have root@esdn-relay:~/gnxi/perf_testing/r230# ip a s enp6s0f1 5: enp6s0f1: mtu 1500 qdisc mq state UP group default qlen 1000 link/ether b4:96:91:23:1e:d6 brd ff:ff:ff:ff:ff:ff inet 10.10.10.10/24 scope global enp6s0f1 valid_lft forever preferred_lft forever inet6 fe80::b696:91ff:fe23:1ed6/64 scope link valid_lft forever preferred_lft forever root@esdn-relay:~/gnxi/perf_testing/r230# ping -I enp6s0f1 10.10.10.11 PING 10.10.10.11 (10.10.10.11) from 10.10.10.10 enp6s0f1: 56(84) bytes of data. 64 bytes from 10.10.10.11: icmp_seq=1 ttl=64 time=0.101 ms 64 bytes from 10.10.10.11: icmp_seq=2 ttl=64 time=0.099 ms 64 bytes from 10.10.10.11: icmp_seq=3 ttl=64 time=0.099 ms ^C --- 10.10.10.11 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2028ms rtt min/avg/max/mdev = 0.099/0.099/0.101/0.011 ms root@esdn-relay:~/gnxi/perf_testing/r230# On Thu, Oct 17, 2019 at 3:17 PM Florin Coras wrote: > Hi Chuan, > > As Balaji said, probably it’s worth making sure the cable between the eth0 > nics is fine and that eth0 on R230 works as expected. For instance, you > could double check your setup by switching to linux drivers and trying a > ping between the two boxes. > > Regarding “sh int”, it only shows the admin status of the interface. To > see the link status, as Damjan explained, you have to use the “show > hardware” cli. > > Hope this helps, > Florin > > On Oct 17, 2019, at 3:08 PM, Balaji Venkatraman via Lists.Fd.Io < > balajiv=cisco@lists.fd.io> wrote: > > Hi Chuan, > I got the eth0 and eth1 mixed up. My bad. > Are these fiber or copper links? You may want to check if the cable is ok. > Also, please make sure you have crossover cable(if RJ) between the servers. > > Thanks! > -- > Regards, > Balaji. > > > *From: *Chuan Han > *Date: *Thursday, October 17, 2019 at 2:41 PM > *To: *"Balaji Venkatraman (balajiv)" > *Cc: *"vpp-dev@lists.fd.io" , Arivudainambi Appachi > gounder , Jerry Cen > *Subject: *Re: [vpp-dev] Basic l2 bridging does not work > > Restarting ixia controller does not help. We ended up with both ixia ports > having '!'. > > We are not sure how ixia port plays a role here. eth0 interfaces are the > interfaces connecting two servers, not to ixia. > > On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) < > bala...@cisco.com> wrote: > > Hi Chuan, > > Could you please try to reset the ixia controller connected to port 4? > I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is down, I > suspect the ixia port. > > -- > Regards, > Balaji. > > > *From: *Chuan Han > *Date: *Thursday, October 17, 2019 at 11:09 AM > *To: *"Balaji Venkatraman (balajiv)" > *Cc: *"vpp-dev@lists.fd.io" , Arivudainambi Appachi > gounder , Jerry Cen > *Subject: *Re: [vpp-dev] Basic l2 bridging does not work > > Yes. It is unidirectional stream from port 1 to port 4. > > Another engineer, Nambi, configured ixia. What he showed me yesterday is > that xia port connected to port 1 is green and good. ixia port connected to > port 4 is green but has a red exclamation mark, which means ping does not > work. > > We also found eth0 on R230 is down shown by "show hardware eth0" command. > However "show int" shows it is up. > > > vpp# sh hardware-interfaces eth0 > NameIdx Link Hardware > eth0 2down eth0 > Link speed: unknown > Ethernet address b4:96:91:23:1e:d6 > Intel 82599 > carrier down > flags: admin-up promisc pmd rx-ip4-cksum > rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8) > tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) > pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 > max rx packet len: 15872 > promiscuous: unicast on all-multicast on > vlan offload: strip off filter off qinq off > rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro >macsec-strip vlan-filter vlan-extend jumbo-frame > scatter >security keep-crc > rx offload active: ipv4-cksum > tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum >
Re: [vpp-dev] Basic l2 bridging does not work
Hi Chuan, As Balaji said, probably it’s worth making sure the cable between the eth0 nics is fine and that eth0 on R230 works as expected. For instance, you could double check your setup by switching to linux drivers and trying a ping between the two boxes. Regarding “sh int”, it only shows the admin status of the interface. To see the link status, as Damjan explained, you have to use the “show hardware” cli. Hope this helps, Florin > On Oct 17, 2019, at 3:08 PM, Balaji Venkatraman via Lists.Fd.Io > wrote: > > Hi Chuan, > I got the eth0 and eth1 mixed up. My bad. > Are these fiber or copper links? You may want to check if the cable is ok. > Also, please make sure you have crossover cable(if RJ) between the servers. > > Thanks! > -- > Regards, > Balaji. > > > From: Chuan Han mailto:chuan...@google.com>> > Date: Thursday, October 17, 2019 at 2:41 PM > To: "Balaji Venkatraman (balajiv)" <mailto:bala...@cisco.com>> > Cc: "vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>" <mailto:vpp-dev@lists.fd.io>>, Arivudainambi Appachi gounder > mailto:aappa...@google.com>>, Jerry Cen > mailto:zhiw...@google.com>> > Subject: Re: [vpp-dev] Basic l2 bridging does not work > > Restarting ixia controller does not help. We ended up with both ixia ports > having '!'. > > We are not sure how ixia port plays a role here. eth0 interfaces are the > interfaces connecting two servers, not to ixia. > > On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) > mailto:bala...@cisco.com>> wrote: > Hi Chuan, > > Could you please try to reset the ixia controller connected to port 4? > I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is down, I > suspect the ixia port. > > -- > Regards, > Balaji. > > > From: Chuan Han mailto:chuan...@google.com>> > Date: Thursday, October 17, 2019 at 11:09 AM > To: "Balaji Venkatraman (balajiv)" <mailto:bala...@cisco.com>> > Cc: "vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>" <mailto:vpp-dev@lists.fd.io>>, Arivudainambi Appachi gounder > mailto:aappa...@google.com>>, Jerry Cen > mailto:zhiw...@google.com>> > Subject: Re: [vpp-dev] Basic l2 bridging does not work > > Yes. It is unidirectional stream from port 1 to port 4. > > Another engineer, Nambi, configured ixia. What he showed me yesterday is that > xia port connected to port 1 is green and good. ixia port connected to port 4 > is green but has a red exclamation mark, which means ping does not work. > > We also found eth0 on R230 is down shown by "show hardware eth0" command. > However "show int" shows it is up. > > > vpp# sh hardware-interfaces eth0 > NameIdx Link Hardware > eth0 2down eth0 > Link speed: unknown > Ethernet address b4:96:91:23:1e:d6 > Intel 82599 > carrier down > flags: admin-up promisc pmd rx-ip4-cksum > rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8) > tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) > pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 > max rx packet len: 15872 > promiscuous: unicast on all-multicast on > vlan offload: strip off filter off qinq off > rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro >macsec-strip vlan-filter vlan-extend jumbo-frame > scatter >security keep-crc > rx offload active: ipv4-cksum > tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum >tcp-tso macsec-insert multi-segs security > tx offload active: none > rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex > ipv6-tcp >ipv6-udp ipv6-ex ipv6 > rss active:none > tx burst function: (nil) > rx burst function: ixgbe_recv_pkts_vec > > rx frames ok 33278 > rx bytes ok 3960082 > extended stats: > rx good packets 33278 > rx good bytes 3960082 > rx q0packets 33278 > rx q0bytes 3960082 > rx size 65 to 127 packets33278 > rx multicast packets 33278 > rx total packets 33278 > rx total bytes
Re: [vpp-dev] Basic l2 bridging does not work
Does vpp have some special requirements on nic types and cabling? On Thu, Oct 17, 2019 at 3:08 PM Balaji Venkatraman (balajiv) < bala...@cisco.com> wrote: > Hi Chuan, > > I got the eth0 and eth1 mixed up. My bad. > > Are these fiber or copper links? You may want to check if the cable is ok. > Also, please make sure you have crossover cable(if RJ) between the servers. > > > > Thanks! > > -- > > Regards, > > Balaji. > > > > > > *From: *Chuan Han > *Date: *Thursday, October 17, 2019 at 2:41 PM > *To: *"Balaji Venkatraman (balajiv)" > *Cc: *"vpp-dev@lists.fd.io" , Arivudainambi Appachi > gounder , Jerry Cen > *Subject: *Re: [vpp-dev] Basic l2 bridging does not work > > > > Restarting ixia controller does not help. We ended up with both ixia ports > having '!'. > > > > We are not sure how ixia port plays a role here. eth0 interfaces are the > interfaces connecting two servers, not to ixia. > > > > On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) < > bala...@cisco.com> wrote: > > Hi Chuan, > > > > Could you please try to reset the ixia controller connected to port 4? > > I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is down, I > suspect the ixia port. > > > > -- > > Regards, > > Balaji. > > > > > > *From: *Chuan Han > *Date: *Thursday, October 17, 2019 at 11:09 AM > *To: *"Balaji Venkatraman (balajiv)" > *Cc: *"vpp-dev@lists.fd.io" , Arivudainambi Appachi > gounder , Jerry Cen > *Subject: *Re: [vpp-dev] Basic l2 bridging does not work > > > > Yes. It is unidirectional stream from port 1 to port 4. > > > > Another engineer, Nambi, configured ixia. What he showed me yesterday is > that xia port connected to port 1 is green and good. ixia port connected to > port 4 is green but has a red exclamation mark, which means ping does not > work. > > > > We also found eth0 on R230 is down shown by "show hardware eth0" command. > However "show int" shows it is up. > > > > > > vpp# sh hardware-interfaces eth0 > NameIdx Link Hardware > eth0 2down eth0 > Link speed: unknown > Ethernet address b4:96:91:23:1e:d6 > Intel 82599 > carrier down > flags: admin-up promisc pmd rx-ip4-cksum > rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8) > tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) > pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 > max rx packet len: 15872 > promiscuous: unicast on all-multicast on > vlan offload: strip off filter off qinq off > rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro >macsec-strip vlan-filter vlan-extend jumbo-frame > scatter >security keep-crc > rx offload active: ipv4-cksum > tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum > sctp-cksum >tcp-tso macsec-insert multi-segs security > tx offload active: none > rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex > ipv6-tcp >ipv6-udp ipv6-ex ipv6 > rss active:none > tx burst function: (nil) > rx burst function: ixgbe_recv_pkts_vec > > rx frames ok 33278 > rx bytes ok 3960082 > extended stats: > rx good packets 33278 > rx good bytes 3960082 > rx q0packets 33278 > rx q0bytes 3960082 > rx size 65 to 127 packets33278 > rx multicast packets 33278 > rx total packets 33278 > rx total bytes 3960082 > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 rx > packets 33279 > rx > bytes 3960201 > drops > 5 > punt > 1 > > tx-error 33274 > eth1 1 up 9000/
Re: [vpp-dev] Basic l2 bridging does not work
I rebooted the r230 machine and found the phy nic corresponding to eth has autoneg off. root@esdn-relay:~/gnxi/perf_testing/r230# ethtool enp6s0f1 Settings for enp6s0f1: Supported ports: [ FIBRE ] Supported link modes: 1baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: No Supported FEC modes: Not reported Advertised link modes: 1baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: No Advertised FEC modes: Not reported Speed: 1Mb/s Duplex: Full *Port: Direct Attach Copper* PHYAD: 0 Transceiver: internal *Auto-negotiation: off* Supports Wake-on: d Wake-on: d Current message level: 0x0007 (7) drv probe link Link detected: yes root@esdn-relay:~/gnxi/perf_testing/r230# On r740, autoneg is on. It is copper. root@esdn-lab:~/gnxi/perf_testing/r740/vpp# ethtool eno3 Settings for eno3: Supported ports: [ TP ] Supported link modes: 100baseT/Full 1000baseT/Full 1baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 100baseT/Full 1000baseT/Full 1baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: 1Mb/s Duplex: Full *Port: Twisted Pair* PHYAD: 0 Transceiver: internal *Auto-negotiation: on* MDI-X: Unknown Supports Wake-on: umbg Wake-on: g Current message level: 0x0007 (7) drv probe link Link detected: yes root@esdn-lab:~/gnxi/perf_testing/r740/vpp# not clear if this plays a role or not. On Thu, Oct 17, 2019 at 2:41 PM Chuan Han via Lists.Fd.Io wrote: > Restarting ixia controller does not help. We ended up with both ixia ports > having '!'. > > We are not sure how ixia port plays a role here. eth0 interfaces are the > interfaces connecting two servers, not to ixia. > > On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) < > bala...@cisco.com> wrote: > >> Hi Chuan, >> >> >> >> Could you please try to reset the ixia controller connected to port 4? >> >> I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is down, >> I suspect the ixia port. >> >> >> >> -- >> >> Regards, >> >> Balaji. >> >> >> >> >> >> *From: *Chuan Han >> *Date: *Thursday, October 17, 2019 at 11:09 AM >> *To: *"Balaji Venkatraman (balajiv)" >> *Cc: *"vpp-dev@lists.fd.io" , Arivudainambi Appachi >> gounder , Jerry Cen >> *Subject: *Re: [vpp-dev] Basic l2 bridging does not work >> >> >> >> Yes. It is unidirectional stream from port 1 to port 4. >> >> >> >> Another engineer, Nambi, configured ixia. What he showed me yesterday is >> that xia port connected to port 1 is green and good. ixia port connected to >> port 4 is green but has a red exclamation mark, which means ping does not >> work. >> >> >> >> We also found eth0 on R230 is down shown by "show hardware eth0" command. >> However "show int" shows it is up. >> >> >> >> >> >> vpp# sh hardware-interfaces eth0 >> NameIdx Link Hardware >> eth0 2down eth0 >> Link speed: unknown >> Ethernet address b4:96:91:23:1e:d6 >> Intel 82599 >> carrier down >> flags: admin-up promisc pmd rx-ip4-cksum >> rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8) >> tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) >> pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 >> max rx packet len: 15872 >> promiscuous: unicast on all-multicast on >> vlan offload: strip off filter off qinq off >> rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro >>macsec-strip vlan-filter vlan-extend jumbo-frame >> scatter >>security keep-crc >> rx offload active: ipv4-cksum >> tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum >> sctp-cksum >>tcp-tso macsec-insert multi-segs security >> tx offload active: none >> rss avail: ipv4
Re: [vpp-dev] Basic l2 bridging does not work
Hi Chuan, I got the eth0 and eth1 mixed up. My bad. Are these fiber or copper links? You may want to check if the cable is ok. Also, please make sure you have crossover cable(if RJ) between the servers. Thanks! -- Regards, Balaji. From: Chuan Han Date: Thursday, October 17, 2019 at 2:41 PM To: "Balaji Venkatraman (balajiv)" Cc: "vpp-dev@lists.fd.io" , Arivudainambi Appachi gounder , Jerry Cen Subject: Re: [vpp-dev] Basic l2 bridging does not work Restarting ixia controller does not help. We ended up with both ixia ports having '!'. We are not sure how ixia port plays a role here. eth0 interfaces are the interfaces connecting two servers, not to ixia. On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) mailto:bala...@cisco.com>> wrote: Hi Chuan, Could you please try to reset the ixia controller connected to port 4? I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is down, I suspect the ixia port. -- Regards, Balaji. From: Chuan Han mailto:chuan...@google.com>> Date: Thursday, October 17, 2019 at 11:09 AM To: "Balaji Venkatraman (balajiv)" mailto:bala...@cisco.com>> Cc: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>" mailto:vpp-dev@lists.fd.io>>, Arivudainambi Appachi gounder mailto:aappa...@google.com>>, Jerry Cen mailto:zhiw...@google.com>> Subject: Re: [vpp-dev] Basic l2 bridging does not work Yes. It is unidirectional stream from port 1 to port 4. Another engineer, Nambi, configured ixia. What he showed me yesterday is that xia port connected to port 1 is green and good. ixia port connected to port 4 is green but has a red exclamation mark, which means ping does not work. We also found eth0 on R230 is down shown by "show hardware eth0" command. However "show int" shows it is up. vpp# sh hardware-interfaces eth0 NameIdx Link Hardware eth0 2down eth0 Link speed: unknown Ethernet address b4:96:91:23:1e:d6 Intel 82599 carrier down flags: admin-up promisc pmd rx-ip4-cksum rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8) tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 max rx packet len: 15872 promiscuous: unicast on all-multicast on vlan offload: strip off filter off qinq off rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro macsec-strip vlan-filter vlan-extend jumbo-frame scatter security keep-crc rx offload active: ipv4-cksum tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum tcp-tso macsec-insert multi-segs security tx offload active: none rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex ipv6-tcp ipv6-udp ipv6-ex ipv6 rss active:none tx burst function: (nil) rx burst function: ixgbe_recv_pkts_vec rx frames ok 33278 rx bytes ok 3960082 extended stats: rx good packets 33278 rx good bytes 3960082 rx q0packets 33278 rx q0bytes 3960082 rx size 65 to 127 packets33278 rx multicast packets 33278 rx total packets 33278 rx total bytes 3960082 vpp# sh int Name IdxState MTU (L3/IP4/IP6/MPLS) Counter Count eth0 2 up 9000/0/0/0 rx packets 33279 rx bytes 3960201 drops 5 punt 1 tx-error 33274 eth1 1 up 9000/0/0/0 rx packets 33274 rx bytes 3959606 tx packets 33273 tx bytes 3959487 drops 33274 tx-error 3 local00
Re: [vpp-dev] Basic l2 bridging does not work
Restarting ixia controller does not help. We ended up with both ixia ports having '!'. We are not sure how ixia port plays a role here. eth0 interfaces are the interfaces connecting two servers, not to ixia. On Thu, Oct 17, 2019 at 11:26 AM Balaji Venkatraman (balajiv) < bala...@cisco.com> wrote: > Hi Chuan, > > > > Could you please try to reset the ixia controller connected to port 4? > > I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is down, I > suspect the ixia port. > > > > -- > > Regards, > > Balaji. > > > > > > *From: *Chuan Han > *Date: *Thursday, October 17, 2019 at 11:09 AM > *To: *"Balaji Venkatraman (balajiv)" > *Cc: *"vpp-dev@lists.fd.io" , Arivudainambi Appachi > gounder , Jerry Cen > *Subject: *Re: [vpp-dev] Basic l2 bridging does not work > > > > Yes. It is unidirectional stream from port 1 to port 4. > > > > Another engineer, Nambi, configured ixia. What he showed me yesterday is > that xia port connected to port 1 is green and good. ixia port connected to > port 4 is green but has a red exclamation mark, which means ping does not > work. > > > > We also found eth0 on R230 is down shown by "show hardware eth0" command. > However "show int" shows it is up. > > > > > > vpp# sh hardware-interfaces eth0 > NameIdx Link Hardware > eth0 2down eth0 > Link speed: unknown > Ethernet address b4:96:91:23:1e:d6 > Intel 82599 > carrier down > flags: admin-up promisc pmd rx-ip4-cksum > rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8) > tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) > pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 > max rx packet len: 15872 > promiscuous: unicast on all-multicast on > vlan offload: strip off filter off qinq off > rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro >macsec-strip vlan-filter vlan-extend jumbo-frame > scatter >security keep-crc > rx offload active: ipv4-cksum > tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum > sctp-cksum >tcp-tso macsec-insert multi-segs security > tx offload active: none > rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex > ipv6-tcp >ipv6-udp ipv6-ex ipv6 > rss active:none > tx burst function: (nil) > rx burst function: ixgbe_recv_pkts_vec > > rx frames ok 33278 > rx bytes ok 3960082 > extended stats: > rx good packets 33278 > rx good bytes 3960082 > rx q0packets 33278 > rx q0bytes 3960082 > rx size 65 to 127 packets33278 > rx multicast packets 33278 > rx total packets 33278 > rx total bytes 3960082 > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 rx > packets 33279 > rx > bytes 3960201 > drops > 5 > punt > 1 > > tx-error 33274 > eth1 1 up 9000/0/0/0 rx > packets 33274 > rx > bytes 3959606 > tx > packets 33273 > tx > bytes 3959487 > drops > 33274 > > tx-error 3 > local00 down 0/0/0/0 > vpp# > > > > On Thu, Oct 17, 2019 at 10:54 AM Balaji Venkatraman (balajiv) < > bala...@cisco.com> wrote: > > Hi Chuan, > > > > I assume u have unidirectional stream ? ixia->1->2->
Re: [vpp-dev] Basic l2 bridging does not work
Hi Chuan, Could you please try to reset the ixia controller connected to port 4? I have seen issues with ‘!’ on ixia. Given the carrier on eth0 is down, I suspect the ixia port. -- Regards, Balaji. From: Chuan Han Date: Thursday, October 17, 2019 at 11:09 AM To: "Balaji Venkatraman (balajiv)" Cc: "vpp-dev@lists.fd.io" , Arivudainambi Appachi gounder , Jerry Cen Subject: Re: [vpp-dev] Basic l2 bridging does not work Yes. It is unidirectional stream from port 1 to port 4. Another engineer, Nambi, configured ixia. What he showed me yesterday is that xia port connected to port 1 is green and good. ixia port connected to port 4 is green but has a red exclamation mark, which means ping does not work. We also found eth0 on R230 is down shown by "show hardware eth0" command. However "show int" shows it is up. vpp# sh hardware-interfaces eth0 NameIdx Link Hardware eth0 2down eth0 Link speed: unknown Ethernet address b4:96:91:23:1e:d6 Intel 82599 carrier down flags: admin-up promisc pmd rx-ip4-cksum rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8) tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 max rx packet len: 15872 promiscuous: unicast on all-multicast on vlan offload: strip off filter off qinq off rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro macsec-strip vlan-filter vlan-extend jumbo-frame scatter security keep-crc rx offload active: ipv4-cksum tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum tcp-tso macsec-insert multi-segs security tx offload active: none rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex ipv6-tcp ipv6-udp ipv6-ex ipv6 rss active:none tx burst function: (nil) rx burst function: ixgbe_recv_pkts_vec rx frames ok 33278 rx bytes ok 3960082 extended stats: rx good packets 33278 rx good bytes 3960082 rx q0packets 33278 rx q0bytes 3960082 rx size 65 to 127 packets33278 rx multicast packets 33278 rx total packets 33278 rx total bytes 3960082 vpp# sh int Name IdxState MTU (L3/IP4/IP6/MPLS) Counter Count eth0 2 up 9000/0/0/0 rx packets 33279 rx bytes 3960201 drops 5 punt 1 tx-error 33274 eth1 1 up 9000/0/0/0 rx packets 33274 rx bytes 3959606 tx packets 33273 tx bytes 3959487 drops 33274 tx-error 3 local00 down 0/0/0/0 vpp# On Thu, Oct 17, 2019 at 10:54 AM Balaji Venkatraman (balajiv) mailto:bala...@cisco.com>> wrote: Hi Chuan, I assume u have unidirectional stream ? ixia->1->2->3->4->ixia? vpp# sh int Name IdxState MTU (L3/IP4/IP6/MPLS) Counter Count eth0 2 up 9000/0/0/0 rx packets 30925 rx bytes 3680075 drops 5 punt 1 tx-error 30920 eth1 1 up 9000/0/0/0 rx packets 30920 <<< packets are received on port 3
Re: [vpp-dev] Basic l2 bridging does not work
/0/0/0 > > > > On sh error logs on R 230 we see > > 1 ethernet-input l3 mac mismatch <<<< > 3 eth1-output interface is down > 30922 eth0-output interface is down > > > > > > Do u see the arp getting resolved on ixia? The mac on ixia at port with > 172.16.1.2/24 should be seen on its other port. Are the ixia ports up at > both ends? > > > > > > -- > > Regards, > > Balaji. > > > > > > *From: * on behalf of "Chuan Han via Lists.Fd.Io" > > *Reply-To: *"chuan...@google.com" > *Date: *Thursday, October 17, 2019 at 9:59 AM > *To: *"Balaji Venkatraman (balajiv)" > *Cc: *"vpp-dev@lists.fd.io" > *Subject: *Re: [vpp-dev] Basic l2 bridging does not work > > > > It seems R740 vpp works fine. All packets coming from port 1 go to port > 2. > > > > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 tx > packets 30895 > tx > bytes 3676505 > eth1 1 up 9000/0/0/0 rx > packets 30895 > rx > bytes 3676505 > local00 down 0/0/0/0 > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 tx > packets 30897 > tx > bytes 3676743 > eth1 1 up 9000/0/0/0 rx > packets 30897 > rx > bytes 3676743 > local00 down 0/0/0/0 > vpp# sh error >CountNode Reason > 30899l2-output L2 output packets > 30899l2-learnL2 learn packets > 1l2-learnL2 learn misses > 30899l2-inputL2 input packets > 30899l2-floodL2 flood packets > vpp# > > > > The drop happened on R230 vpp. Port 3 dropped all pkts complaining about > down interface. However, show command shows interfaces are up. > > > > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 rx > packets 30925 > rx > bytes 3680075 > drops > 5 > punt > 1 > > tx-error 30920 > eth1 1 up 9000/0/0/0 rx > packets 30920 > rx > bytes 3679480 > tx > packets 30919 > tx > bytes 3679361 > drops > 30920 > > tx-error 3 > local00 down 0/0/0/0 > vpp# sh error >CountNode Reason > 2llc-input unknown llc ssap/dsap > 61846l2-output L2 output packets > 61846l2-learnL2 learn packets > 2l2-learnL2 learn misses > 61846l2-inputL2 input packets > 61846l2-floodL2 flood packets > 1 ethernet-input l3 mac mismatch > 3 eth1-output interface is down > 30922 eth0-output interface is down > vpp# > > > > Not sure how to check mac issues. Can you explain a bit more? He
Re: [vpp-dev] Basic l2 bridging does not work
Hi Chuan, I assume u have unidirectional stream ? ixia->1->2->3->4->ixia? vpp# sh int Name IdxState MTU (L3/IP4/IP6/MPLS) Counter Count eth0 2 up 9000/0/0/0 rx packets 30925 rx bytes 3680075 drops 5 punt 1 tx-error 30920 eth1 1 up 9000/0/0/0 rx packets 30920 <<< packets are received on port 3 rx bytes 3679480 tx packets 30919 tx bytes 3679361 drops 30920 <<< all dropped at port 3 tx-error 3 local00 down 0/0/0/0 On sh error logs on R 230 we see 1 ethernet-input l3 mac mismatch <<<< 3 eth1-output interface is down 30922 eth0-output interface is down Do u see the arp getting resolved on ixia? The mac on ixia at port with 172.16.1.2/24<http://172.16.1.2/24> should be seen on its other port. Are the ixia ports up at both ends? -- Regards, Balaji. From: on behalf of "Chuan Han via Lists.Fd.Io" Reply-To: "chuan...@google.com" Date: Thursday, October 17, 2019 at 9:59 AM To: "Balaji Venkatraman (balajiv)" Cc: "vpp-dev@lists.fd.io" Subject: Re: [vpp-dev] Basic l2 bridging does not work It seems R740 vpp works fine. All packets coming from port 1 go to port 2. vpp# sh int Name IdxState MTU (L3/IP4/IP6/MPLS) Counter Count eth0 2 up 9000/0/0/0 tx packets 30895 tx bytes 3676505 eth1 1 up 9000/0/0/0 rx packets 30895 rx bytes 3676505 local00 down 0/0/0/0 vpp# sh int Name IdxState MTU (L3/IP4/IP6/MPLS) Counter Count eth0 2 up 9000/0/0/0 tx packets 30897 tx bytes 3676743 eth1 1 up 9000/0/0/0 rx packets 30897 rx bytes 3676743 local00 down 0/0/0/0 vpp# sh error CountNode Reason 30899l2-output L2 output packets 30899l2-learnL2 learn packets 1l2-learnL2 learn misses 30899l2-inputL2 input packets 30899l2-floodL2 flood packets vpp# The drop happened on R230 vpp. Port 3 dropped all pkts complaining about down interface. However, show command shows interfaces are up. vpp# sh int Name IdxState MTU (L3/IP4/IP6/MPLS) Counter Count eth0 2 up 9000/0/0/0 rx packets 30925 rx bytes 3680075 drops 5 punt 1 tx-error 30920 eth1 1 up 9000/0/0/0 rx packets 30920 rx bytes 3679480 tx packets 30919
Re: [vpp-dev] Basic l2 bridging does not work
On R230, we have the following. Not sure why eth0 is down. I used the same setup for L3 routing measurement. Everything worked fine. vpp# sh hardware-interfaces eth0 NameIdx Link Hardware eth0 2down eth0 Link speed: unknown Ethernet address b4:96:91:23:1e:d6 Intel 82599 *carrier down <= How can this be done? * flags: admin-up promisc pmd rx-ip4-cksum rx: queues 1 (max 128), desc 512 (min 32 max 4096 align 8) tx: queues 3 (max 64), desc 512 (min 32 max 4096 align 8) pci: device 8086:154d subsystem 8086:7b11 address :06:00.01 numa 0 max rx packet len: 15872 promiscuous: unicast on all-multicast on vlan offload: strip off filter off qinq off rx offload avail: vlan-strip ipv4-cksum udp-cksum tcp-cksum tcp-lro macsec-strip vlan-filter vlan-extend jumbo-frame scatter security keep-crc rx offload active: ipv4-cksum tx offload avail: vlan-insert ipv4-cksum udp-cksum tcp-cksum sctp-cksum tcp-tso macsec-insert multi-segs security tx offload active: none rss avail: ipv4-tcp ipv4-udp ipv4 ipv6-tcp-ex ipv6-udp-ex ipv6-tcp ipv6-udp ipv6-ex ipv6 rss active:none tx burst function: (nil) rx burst function: ixgbe_recv_pkts_vec rx frames ok 32770 rx bytes ok 3899630 extended stats: rx good packets 32770 rx good bytes 3899630 rx q0packets 32770 rx q0bytes 3899630 rx size 65 to 127 packets32770 rx multicast packets 32770 rx total packets 32770 rx total bytes 3899630 vpp# On Thu, Oct 17, 2019 at 10:47 AM Damjan Marion wrote: > > > On 17 Oct 2019, at 09:59, Chuan Han wrote: > > It seems R740 vpp works fine. All packets coming from port 1 go to port 2. > > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 tx > packets 30895 > tx > bytes 3676505 > eth1 1 up 9000/0/0/0 rx > packets 30895 > rx > bytes 3676505 > local00 down 0/0/0/0 > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 tx > packets 30897 > tx > bytes 3676743 > eth1 1 up 9000/0/0/0 rx > packets 30897 > rx > bytes 3676743 > local00 down 0/0/0/0 > vpp# sh error >CountNode Reason > 30899l2-output L2 output packets > 30899l2-learnL2 learn packets > 1l2-learnL2 learn misses > 30899l2-inputL2 input packets > 30899l2-floodL2 flood packets > vpp# > > The drop happened on R230 vpp. Port 3 dropped all pkts complaining about > down interface. However, show command shows interfaces are up. > > > Can you capture "show hardware eth0" ? > > -- > Damjan > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14205): https://lists.fd.io/g/vpp-dev/message/14205 Mute This Topic: https://lists.fd.io/mt/34655826/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] Basic l2 bridging does not work
> On 17 Oct 2019, at 09:59, Chuan Han wrote: > > It seems R740 vpp works fine. All packets coming from port 1 go to port 2. > > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 tx > packets 30895 > tx bytes >3676505 > eth1 1 up 9000/0/0/0 rx > packets 30895 > rx bytes >3676505 > local00 down 0/0/0/0 > vpp# sh int > Name IdxState MTU (L3/IP4/IP6/MPLS) > Counter Count > eth0 2 up 9000/0/0/0 tx > packets 30897 > tx bytes >3676743 > eth1 1 up 9000/0/0/0 rx > packets 30897 > rx bytes >3676743 > local00 down 0/0/0/0 > vpp# sh error >CountNode Reason > 30899l2-output L2 output packets > 30899l2-learnL2 learn packets > 1l2-learnL2 learn misses > 30899l2-inputL2 input packets > 30899l2-floodL2 flood packets > vpp# > > The drop happened on R230 vpp. Port 3 dropped all pkts complaining about down > interface. However, show command shows interfaces are up. > Can you capture "show hardware eth0" ? -- Damjan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14204): https://lists.fd.io/g/vpp-dev/message/14204 Mute This Topic: https://lists.fd.io/mt/34655826/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] Basic l2 bridging does not work
IXIA | > > | | > > | | > > +---^-+ > > |172.16.1.1/24 | > 172.16.1.2/24 > > | | > > | | > > |eth0 | eth0 > > +---v-+++---+ > > | 1 ||4 | > > | ||| > > | ||| > > | ||| > > | |eth1 eth1 || > > |VPP1 2 +> 3VPP 2 | > > | ||| > > | ||| > > | ||| > > | ||| > > +-+++ > > R 740 R 230 > > > > > > Might help if you could check if the packet counts at ingress (port 1) & > egress (port 2) match. Similarly 3 & 4. And the mac entries seen on both > vpp(s). ARP req/rep tracing might also help. > > > > > > /- > > Balaji > > > > > > > > > > *From: * on behalf of "Damjan Marion via Lists.Fd.Io" > > *Reply-To: *"dmar...@me.com" > *Date: *Wednesday, October 16, 2019 at 5:12 PM > *To: *"chuan...@google.com" > *Cc: *"vpp-dev@lists.fd.io" > *Subject: *Re: [vpp-dev] Basic l2 bridging does not work > > > > > > On 16 Oct 2019, at 16:14, Chuan Han via Lists.Fd.Io < > chuanhan=google@lists.fd.io> wrote: > > > > Hi, vpp experts, > > > > We are trying to make basic l2 bridge works within vpp. > > > > We have two servers: r230 and r740, each of which has two phy nics. Two > servers are connected via cable. On each server, we bring these two nics > into the same vpp instance and put them into the same l2 bridge. We tried > sending traffic using ixia. However, ixia shows ping does not work. > > > > I attached the topology, vpp conf files, startup conf file, and logs. > > > > Please advise where we could make it wrong. > > > > Thanks. > > Chuan > > startup.cfg> bridge.pdf>-=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#14189): https://lists.fd.io/g/vpp-dev/message/14189 > Mute This Topic: https://lists.fd.io/mt/34655826/675642 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [dmar...@me.com] > -=-=-=-=-=-=-=-=-=-=-=- > > > > On the 1st look everything look ok including the packet trace. > > Can you try to clear counters* and enable packet trace on both instances. > > Then send known number of packets and find put where drop happens by > looking into same outputs you already shared. > > > > * "clear int", "clear run", "clear trace" > > > > -- > Damjan > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14202): https://lists.fd.io/g/vpp-dev/message/14202 Mute This Topic: https://lists.fd.io/mt/34655826/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] Basic l2 bridging does not work
+-+ | | | | | IXIA | | | | | +---^-+ |172.16.1.1/24 | 172.16.1.2/24 | | | | |eth0 | eth0 +---v-+++---+ | 1 ||4 | | ||| | ||| | ||| | |eth1 eth1 || |VPP1 2 +> 3VPP 2 | | ||| | ||| | ||| | ||| +-+++ R 740 R 230 Might help if you could check if the packet counts at ingress (port 1) & egress (port 2) match. Similarly 3 & 4. And the mac entries seen on both vpp(s). ARP req/rep tracing might also help. /- Balaji From: on behalf of "Damjan Marion via Lists.Fd.Io" Reply-To: "dmar...@me.com" Date: Wednesday, October 16, 2019 at 5:12 PM To: "chuan...@google.com" Cc: "vpp-dev@lists.fd.io" Subject: Re: [vpp-dev] Basic l2 bridging does not work On 16 Oct 2019, at 16:14, Chuan Han via Lists.Fd.Io mailto:chuanhan=google@lists.fd.io>> wrote: Hi, vpp experts, We are trying to make basic l2 bridge works within vpp. We have two servers: r230 and r740, each of which has two phy nics. Two servers are connected via cable. On each server, we bring these two nics into the same vpp instance and put them into the same l2 bridge. We tried sending traffic using ixia. However, ixia shows ping does not work. I attached the topology, vpp conf files, startup conf file, and logs. Please advise where we could make it wrong. Thanks. Chuan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14189): https://lists.fd.io/g/vpp-dev/message/14189 Mute This Topic: https://lists.fd.io/mt/34655826/675642 Group Owner: vpp-dev+ow...@lists.fd.io<mailto:vpp-dev+ow...@lists.fd.io> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [dmar...@me.com<mailto:dmar...@me.com>] -=-=-=-=-=-=-=-=-=-=-=- On the 1st look everything look ok including the packet trace. Can you try to clear counters* and enable packet trace on both instances. Then send known number of packets and find put where drop happens by looking into same outputs you already shared. * "clear int", "clear run", "clear trace" -- Damjan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14191): https://lists.fd.io/g/vpp-dev/message/14191 Mute This Topic: https://lists.fd.io/mt/34655826/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] Basic l2 bridging does not work
> On 16 Oct 2019, at 16:14, Chuan Han via Lists.Fd.Io > wrote: > > Hi, vpp experts, > > We are trying to make basic l2 bridge works within vpp. > > We have two servers: r230 and r740, each of which has two phy nics. Two > servers are connected via cable. On each server, we bring these two nics into > the same vpp instance and put them into the same l2 bridge. We tried sending > traffic using ixia. However, ixia shows ping does not work. > > I attached the topology, vpp conf files, startup conf file, and logs. > > Please advise where we could make it wrong. > > Thanks. > Chuan > startup.cfg> bridge.pdf>-=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#14189): https://lists.fd.io/g/vpp-dev/message/14189 > Mute This Topic: https://lists.fd.io/mt/34655826/675642 > Group Owner: vpp-dev+ow...@lists.fd.io > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [dmar...@me.com] > -=-=-=-=-=-=-=-=-=-=-=- On the 1st look everything look ok including the packet trace. Can you try to clear counters* and enable packet trace on both instances. Then send known number of packets and find put where drop happens by looking into same outputs you already shared. * "clear int", "clear run", "clear trace" -- Damjan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14190): https://lists.fd.io/g/vpp-dev/message/14190 Mute This Topic: https://lists.fd.io/mt/34655826/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
