2

I have a mixed environment using HP and Blade / IBM / Lenovo networking switches. We have VLANs for many subnets. We don't have any central management for switches, nor VLAN aware mapping. I'm having a problem where I think I need to figure out how a VLANs traffic is being sent.

I have a VLAN that is connected thusly: Router --- [bldmgtswitch] --- [bldG8000] ={=}= [bldG8264]

The --- is untagged 1Gbit, the ={=}= is a tag on a 10Gbit connection. Connecting to [bldmgtswitch] untagged I can ping router. Connecting to [bldG8000] untagged I cannot ping router...

I'm thinking this may be because there's something wrong with the configuration on [bldG8000], but the VLANs are all configured correctly. Spanning tree doesn't seem to be blocking... I'm wondering if the port cost is the issue. More so, I just am not sure how at Layer 2 to figure out where the frames are going when I plug into the untagged port on [bldG8000]...

Improve this question
8
  • Switches are transparent devices. Traceroute depends on the layer-3 TTL, but there is no such thing at layer-2, which is why broadcast storms can happen; the layer-2 frames will never time out, unlike layer-3 packets with a TTL.
    – Ron Maupin ♦
    Commented Feb 10, 2017 at 14:55
  • Surely there is some way to diagnose or find out what [bldG8000] is doing with frames on a particular VLAN?
    – jmp242
    Commented Feb 10, 2017 at 15:01
  • Are all the VLANs running through the untagged link?
    – Ron Maupin ♦
    Commented Feb 10, 2017 at 15:04
  • You can verify that all the ports are forwarding traffic for the particular VLAN.
    – Ron Trunk
    Commented Feb 10, 2017 at 15:43
  • Sometimes it can be incredibly handy to have a very low-rate broadcast going on to see where packets in a given VLAN are going. Deploy a sniffer at various points on the network to verify connectivity. That's about as close to a generalized L2 traceroute as you'll find.
    – rnxrx
    Commented Feb 11, 2017 at 4:08

2 Answers 2

Reset to default
1

There is no traceroute tool for layer 2. The main reasons are that there is no TTL mechanism and no feedback mechanism comparable to ICMP for IP.

In addition to the packet capturing suggested by ViperX and mxrx, you can look at the switches' MAC tables to see how far a specific MAC propagates and an actual connection reaches. Any layer 3 connection attempt will ARP and thus propagate the source's MAC address to all switches with a working connection in that segment/VLAN. For me, that's the fastest trouble-shooting method.

Improve this answer
1
  • Using what Zac67 says... At layer 2 you are using frames which use the Mac address. Between a show mac-address command and show arp (after a ping or other traffic comes from the device) you can figure out where it's going. If the address the traffic is going to isn't in those tables and it doesn't respond to your computers arp request the computer sends traffic to the gateway if your computer has a gateway assigned. At that point it leaves the layer 2 vlan.
    – Fixitrod
    Commented Aug 13, 2017 at 17:45
0

Try setup a switch port analyser(port mirror/SPAN, other commons terms) , that will mirror packets from your port of interest, out to a specified port. Then plug a laptop/pc into the port that is mirroring the data and use a packet sniffer like wire shark, you'll be able to see all the layer 2 frames with tagging etc.

Hope this helps!

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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