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 (#14213): https://lists.fd.io/g/vpp-dev/message/14213
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]
-=-=-=-=-=-=-=-=-=-=-=-
