What about trying to swap NIC and/or cable? > > On 18 Oct 2019, at 16:05, Chuan Han <chuan...@google.com> wrote: > > > Hi, Damjan, > > It seems the bug is in vpp. > > On R230, vpp shows eth0 is down. > > vpp# sh hardware-interfaces eth0 > Name Idx Link Hardware > eth0 2 down 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 0000: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 > 1 B4:96:91:23:1E:D6 0000:06:00.1 net_ixgbe up 10000Mbps > testpmd> > > Does this prove something wrong on vpp side? > > Thanks. > Chuan > > On Fri, Oct 18, 2019 at 3:06 PM Chuan Han <chuan...@google.com> 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 >> <chuanhan=google....@lists.fd.io> wrote: >>> So, it is a dpdk bug? >>> >>> I am new to dpdk/vpp. >>> >>> How do I run dpdk testpmd? Shall I install dpdk separately on the r230 >>> server? Are there any steps to follow? >>> >>> On Fri, Oct 18, 2019 at 10:30 AM Damjan Marion <dmar...@me.com> wrote: >>>> In this case we are purely relying on link state provided by DPDK. >>>> Have you tried to check if same problem exists with DPDK testpmd app? >>>> >>>> >>>>> On 18 Oct 2019, at 10:26, Chuan Han via Lists.Fd.Io >>>>> <chuanhan=google....@lists.fd.io> wrote: >>>>> >>>>> I cleaned up startup config a bit. I can still see eth0 down. >>>>> >>>>> See attachment for config file and log. There are some errors in log, but >>>>> I am not sure they are worrisome or not. >>>>> >>>>> On Thu, Oct 17, 2019 at 5:22 PM Florin Coras <fcoras.li...@gmail.com> >>>>> wrote: >>>>>> 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 >>>>>>> <chuanhan=google....@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 <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) >>>>>>>> <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 <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: 10000baseT/Full >>>>>>>>>> Supported pause frame use: Symmetric >>>>>>>>>> Supports auto-negotiation: No >>>>>>>>>> Supported FEC modes: Not reported >>>>>>>>>> Advertised link modes: 10000baseT/Full >>>>>>>>>> Advertised pause frame use: Symmetric >>>>>>>>>> Advertised auto-negotiation: No >>>>>>>>>> Advertised FEC modes: Not reported >>>>>>>>>> Speed: 10000Mb/s >>>>>>>>>> Duplex: Full >>>>>>>>>> Port: Direct Attach Copper >>>>>>>>>> PHYAD: 0 >>>>>>>>>> Transceiver: internal >>>>>>>>>> Auto-negotiation: off >>>>>>>>>> Supports Wake-on: d >>>>>>>>>> Wake-on: d >>>>>>>>>> Current message level: 0x00000007 (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 >>>>>>>>>> 10000baseT/Full >>>>>>>>>> Supported pause frame use: Symmetric >>>>>>>>>> Supports auto-negotiation: Yes >>>>>>>>>> Supported FEC modes: Not reported >>>>>>>>>> Advertised link modes: 100baseT/Full >>>>>>>>>> 1000baseT/Full >>>>>>>>>> 10000baseT/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: 0x00000007 (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 >>>>>>>>>> <chuanhan=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 <chuan...@google.com> >>>>>>>>>>>> Date: Thursday, October 17, 2019 at 11:09 AM >>>>>>>>>>>> To: "Balaji Venkatraman (balajiv)" <bala...@cisco.com> >>>>>>>>>>>> Cc: "vpp-dev@lists.fd.io" <vpp-dev@lists.fd.io>, Arivudainambi >>>>>>>>>>>> Appachi gounder <aappa...@google.com>, Jerry Cen >>>>>>>>>>>> <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 >>>>>>>>>>>> Name Idx Link Hardware >>>>>>>>>>>> eth0 2 down 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 >>>>>>>>>>>> 0000: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 packets 33278 >>>>>>>>>>>> rx multicast packets 33278 >>>>>>>>>>>> rx total packets 33278 >>>>>>>>>>>> rx total bytes 3960082 >>>>>>>>>>>> vpp# sh int >>>>>>>>>>>> Name Idx State 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 >>>>>>>>>>>> local0 0 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->3->4->ixia? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> vpp# sh int >>>>>>>>>>>> Name Idx State 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 >>>>>>>>>>>> local0 0 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 should be seen on its other port. Are the ixia >>>>>>>>>>>> ports up at both ends? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Balaji. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> From: <vpp-dev@lists.fd.io> on behalf of "Chuan Han via >>>>>>>>>>>> Lists.Fd.Io" <chuanhan=google....@lists.fd.io> >>>>>>>>>>>> Reply-To: "chuan...@google.com" <chuan...@google.com> >>>>>>>>>>>> Date: Thursday, October 17, 2019 at 9:59 AM >>>>>>>>>>>> To: "Balaji Venkatraman (balajiv)" <bala...@cisco.com> >>>>>>>>>>>> Cc: "vpp-dev@lists.fd.io" <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 Idx State 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 >>>>>>>>>>>> local0 0 down 0/0/0/0 >>>>>>>>>>>> >>>>>>>>>>>> vpp# sh int >>>>>>>>>>>> Name Idx State 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 >>>>>>>>>>>> local0 0 down 0/0/0/0 >>>>>>>>>>>> >>>>>>>>>>>> vpp# sh error >>>>>>>>>>>> Count Node Reason >>>>>>>>>>>> 30899 l2-output L2 output packets >>>>>>>>>>>> 30899 l2-learn L2 learn packets >>>>>>>>>>>> 1 l2-learn L2 learn misses >>>>>>>>>>>> 30899 l2-input L2 input packets >>>>>>>>>>>> 30899 l2-flood L2 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 Idx State 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 >>>>>>>>>>>> local0 0 down 0/0/0/0 >>>>>>>>>>>> >>>>>>>>>>>> vpp# sh error >>>>>>>>>>>> Count Node Reason >>>>>>>>>>>> 2 llc-input unknown llc >>>>>>>>>>>> ssap/dsap >>>>>>>>>>>> 61846 l2-output L2 output packets >>>>>>>>>>>> 61846 l2-learn L2 learn packets >>>>>>>>>>>> 2 l2-learn L2 learn misses >>>>>>>>>>>> 61846 l2-input L2 input packets >>>>>>>>>>>> 61846 l2-flood L2 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? Here >>>>>>>>>>>> is what I can see on R230 vpp. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> vpp# show bridge-domain 1 detail >>>>>>>>>>>> BD-ID Index BSN Age(min) Learning U-Forwrd UU-Flood >>>>>>>>>>>> Flooding ARP-Term arp-ufwd BVI-Intf >>>>>>>>>>>> 1 1 0 off on on flood >>>>>>>>>>>> on off off N/A >>>>>>>>>>>> >>>>>>>>>>>> Interface If-idx ISN SHG BVI TxFlood >>>>>>>>>>>> VLAN-Tag-Rewrite >>>>>>>>>>>> eth0 2 1 0 - * >>>>>>>>>>>> none >>>>>>>>>>>> eth1 1 1 0 - * >>>>>>>>>>>> none >>>>>>>>>>>> vpp# sh l2fib verbose >>>>>>>>>>>> Mac-Address BD-Idx If-Idx BSN-ISN Age(min) static filter >>>>>>>>>>>> bvi Interface-Name >>>>>>>>>>>> 28:99:3a:f4:3a:a6 1 2 0/1 - - - >>>>>>>>>>>> - eth0 >>>>>>>>>>>> 28:99:3a:f4:3a:9c 1 1 0/1 - - - >>>>>>>>>>>> - eth1 >>>>>>>>>>>> L2FIB total/learned entries: 2/2 Last scan time: 0.0000e0sec >>>>>>>>>>>> Learn limit: 4194304 >>>>>>>>>>>> vpp# >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Oct 16, 2019 at 6:01 PM Balaji Venkatraman (balajiv) >>>>>>>>>>>> <bala...@cisco.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> +-------------------------------------------------------------------------+ >>>>>>>>>>>> >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> >>>>>>>>>>>> | IXIA >>>>>>>>>>>> | >>>>>>>>>>>> >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> >>>>>>>>>>>> +-----------------------------------------------------------^-------------+ >>>>>>>>>>>> >>>>>>>>>>>> |172.16.1.1/24 >>>>>>>>>>>> |172.16.1.2/24 >>>>>>>>>>>> >>>>>>>>>>>> | | >>>>>>>>>>>> >>>>>>>>>>>> | | >>>>>>>>>>>> >>>>>>>>>>>> |eth0 | eth0 >>>>>>>>>>>> >>>>>>>>>>>> +-----------v-------------+ >>>>>>>>>>>> +------------+-----------+ >>>>>>>>>>>> >>>>>>>>>>>> | 1 | | 4 >>>>>>>>>>>> | >>>>>>>>>>>> >>>>>>>>>>>> | | | >>>>>>>>>>>> | >>>>>>>>>>>> >>>>>>>>>>>> | | | >>>>>>>>>>>> | >>>>>>>>>>>> >>>>>>>>>>>> | | | >>>>>>>>>>>> | >>>>>>>>>>>> >>>>>>>>>>>> | |eth1 eth1 | >>>>>>>>>>>> | >>>>>>>>>>>> >>>>>>>>>>>> | VPP1 2 +--------------------> 3 VPP 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: <vpp-dev@lists.fd.io> on behalf of "Damjan Marion via >>>>>>>>>>>> Lists.Fd.Io" <dmarion=me....@lists.fd.io> >>>>>>>>>>>> Reply-To: "dmar...@me.com" <dmar...@me.com> >>>>>>>>>>>> Date: Wednesday, October 16, 2019 at 5:12 PM >>>>>>>>>>>> To: "chuan...@google.com" <chuan...@google.com> >>>>>>>>>>>> Cc: "vpp-dev@lists.fd.io" <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 >>>>>>>>>>>> >>>>>>>>>>>> <r230 vpp.conf><r740 vpp.conf><r230 vpp startup.cfg><r740 vpp >>>>>>>>>>>> startup.cfg><r740.log><r230.log><vpp testbed - >>>>>>>>>>>> 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 (#14211): >>>>>>>>>>> https://lists.fd.io/g/vpp-dev/message/14211 >>>>>>>>>>> Mute This Topic: https://lists.fd.io/mt/34655826/1991531 >>>>>>>>>>> Group Owner: vpp-dev+ow...@lists.fd.io >>>>>>>>>>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub >>>>>>>>>>> [chuan...@google.com] >>>>>>>>>>> -=-=-=-=-=-=-=-=-=-=-=- >>>>>>> -=-=-=-=-=-=-=-=-=-=-=- >>>>>>> Links: You receive all messages sent to this group. >>>>>>> >>>>>>> View/Reply Online (#14219): https://lists.fd.io/g/vpp-dev/message/14219 >>>>>>> Mute This Topic: https://lists.fd.io/mt/34655826/675152 >>>>>>> Group Owner: vpp-dev+ow...@lists.fd.io >>>>>>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub >>>>>>> [fcoras.li...@gmail.com] >>>>>>> -=-=-=-=-=-=-=-=-=-=-=- >>>>>> >>>>> <log><vpp startup.conf>-=-=-=-=-=-=-=-=-=-=-=- >>>>> Links: You receive all messages sent to this group. >>>>> >>>>> View/Reply Online (#14240): https://lists.fd.io/g/vpp-dev/message/14240 >>>>> 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] >>>>> -=-=-=-=-=-=-=-=-=-=-=- >>>> >>>> -- >>>> Damjan >>>> >>> -=-=-=-=-=-=-=-=-=-=-=- >>> Links: You receive all messages sent to this group. >>> >>> View/Reply Online (#14243): https://lists.fd.io/g/vpp-dev/message/14243 >>> Mute This Topic: https://lists.fd.io/mt/34655826/1991531 >>> Group Owner: vpp-dev+ow...@lists.fd.io >>> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [chuan...@google.com] >>> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group.
View/Reply Online (#14246): https://lists.fd.io/g/vpp-dev/message/14246 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] -=-=-=-=-=-=-=-=-=-=-=-
