You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Weirdly, a physical Arista switch is happy with LLDP packets from a real sidecar:
eveningstar#show lldp neighbors ethernet 26/1
Last table change time : 8:34:13 ago
Number of table inserts : 9
Number of table deletes : 6
Number of table drops : 0
Number of table age-outs : 3
Port Neighbor Device ID Neighbor Port ID TTL
------------ ------------------------ ---------------------- ---
Et26/1 BRM44220001 qsfp0/0 120
eveningstar#show lldp neighbors ethernet 26/1 detail
Interface Ethernet26/1 detected 1 LLDP neighbors:
Neighbor "BRM44220001"/"qsfp0/0", age 7 seconds
Discovered 8:34:21 ago; Last changed 8:34:21 ago
- Chassis ID type: Chassis component (1)
Chassis ID : "BRM44220001"
- Port ID type: Interface name(5)
A simple Venn diagram approach would suggest a problem in sidecar-lite and/or softnpu, but the tcpdump log shows that the packets are making it out of our emulated switch, which makes that less likely.
The text was updated successfully, but these errors were encountered:
We are using Arista containerized EOS (cEOS). I suspect this is either not supported by cEOS or the linux plumbing into the cEOS container is not passing LLDP traffic. The arista interfaces are plumbed here so you could tcpdump those on cr1 or cr2 to see if you see the lldp packets. You could also instal lldpd on linux to see if that works.
In an
a4x2
environment, the emulated Arista router is ignoring our LLDP packets.LLDP is enabled on sidecar 0, which connects to Arista switch 1 on Ethernet port 2. We have LLDP-receive enabled:
With
tcpdump
, we can see them arriving at the switch:For some reason, these packets aren't being accepted/processed by Eos. They don't even appear to get far enough to register as errors:
Weirdly, a physical Arista switch is happy with LLDP packets from a real sidecar:
A simple Venn diagram approach would suggest a problem in
sidecar-lite
and/orsoftnpu
, but thetcpdump
log shows that the packets are making it out of our emulated switch, which makes that less likely.The text was updated successfully, but these errors were encountered: