1

We have a chain of switches configured for vlan 13, let's call them switch1, switch2 and switch3 No, somewhere on this chain the arp requests get lost. I can run tcpdump on these switches. Running just sudo tcpdump -n host 192.168.42.1 shows that switch1 and switch2 get the arp requests but switch3 doesn't.

I'd like to further isolate the problem to see if the problem is switch2 or switch3. Can I tell tcpdump to only listen for outgoing arp requests on one specific interface? I tried with sudo tcpdump -e -i et6 but I don't see the arp requests.

Update:

here's the port config of the three switches. The layout (syntax incoming_port#switch#outgoing_port):

fw1 - 6#switch1#45 - 45#switch2#51 - fiber - 41#switch3 - fw2

! switch 1: incoming

interface Ethernet6
   switchport access vlan 13
   spanning-tree portfast

! switch 1: outgoing

interface Ethernet45
   channel-group 60 mode active

interface Port-Channel60
   switchport trunk allowed vlan 1-3,5-4094
   switchport mode trunk
   mlag 16

! switch 2: incoming

interface Ethernet45
   switchport mode trunk
   channel-group 60 mode active
!

interface Port-Channel60
   switchport trunk allowed vlan 1-3,5-4094
   switchport mode trunk
!

! switch 2: outgoing

interface Ethernet51
   mtu 9000
   switchport access vlan 8
   switchport trunk allowed vlan 2-3,5-14,101-110,112-120
   switchport mode trunk
!

! switch 3: incoming

interface Ethernet51
   mtu 9000
   switchport access vlan 8
   switchport trunk allowed vlan 2-3,5-14,101-110,112-120
   switchport mode trunk
!
9
  • You are going to need to provide more information. What are the switch models and configurations? – Ron Maupin Nov 4 '16 at 16:42
  • By the way, switches are transparent devices, and they don't get involved in ARP. ARP is between hosts to resolve a layer-3 address to a layer-2 address, and switches don't know anything about layer-3. ARP requests are layer-2 broadcasts, and ARP replies are layer-2 unicasts. – Ron Maupin Nov 4 '16 at 16:53
  • I know that arp requests are any/multicast on layer 2 and that switches are also layer 2. Only tcpdump seems misplaced. If there are better tools for that, I'd interested to know – hansaplast Nov 4 '16 at 17:43
  • We need a diagram to see how these switches are connected to each other and the hosts. Where are you running tcpdump from? – Ron Trunk Nov 4 '16 at 17:46
  • What is the outgoing port of switch 3? The configuration of that port could be the problem. Otherwise, you should give the full switch configurations. – Ron Maupin Nov 4 '16 at 17:56
2

I was able to solve the problem. The issue was indeed on the outgoing port as suggested in the comments above. Whatever it's worth a few findings along the way of solving this problem:

  1. first understand the network topology. Nobody can help you before you did that exercise yourself. You cannot ask for punctual help if you don't understand the big picture first
  2. no, there doesn't seem a way to see if an arp packet is sent to a specific interface
  3. on some switches tcpdump didn't show the arp packages. This thread explains that only packets show up that go through the cpu of the switch. This is the case if the packets originate from the switch or are destined for the switch or the advanced tracking is turned on (which was probably my case as the switches where it did show up are running on version 4.15.x of Aristas EOS and the ones which didn't show the arp packages were running 4.12.x)
  4. for debugging vlans it's helpful to set up vlan interfaces along the way. In my case the Arista switch supports setting up an endpoint with an ip address like this:

    interface Vlan13
      ip address 192.168.42.17/24
    

doing this lets you do e.g. arping 192.168.42.2 -I vlan13 or simply ping 192.168.42.2 (the switch knows that this IP address is configured on vlan 13 and sends the pings over this vlan)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.