Getting the MAC of device on other end of line.

USMCGrunt said:
If I had to guess, I'd say the switch is passing the traffic but it's the hosts that are dropping the traffic. The switch will have its table populated with all the MAC addresses its learned, so when a frame comes in, it just pushes it off to the host as it should. I'd guess that the destination host receives the frame but because the vlan tag on the packet doesn't match it's own vlan, the host drops the packet. Though this wouldn't explain why two hosts in the same vlan couldn't communicate....Wireshark could probably shed some light on what's going on if you were so inclined.

I've seen switches labeled as vlan capable, which I imagine means it's a managed switch that allows you to set vlan configurations per port, causing the switch to build separate mac tables for each vlan.
Click to expand...
Simple switches; no vlan tags.

If I had to guess, I'd say the programming on the switch cut corners for speed and firmware size, so learned only the characteristics of the first network it saw and built it's arp->port table relative to that.

So instead of aa:bb:cc:dd:ee:ff = 192.168.2.1, it might be aa:bb:cc:dd:ee:ff = 1, knowing that the network is 192.168.2.0/24.

Someday I may test that hypothesis out.
 
XOR != OR said:
Simple switches; no vlan tags.

If I had to guess, I'd say the programming on the switch cut corners for speed and firmware size, so learned only the characteristics of the first network it saw and built it's arp->port table relative to that.

So instead of aa:bb:cc:dd:ee:ff = 192.168.2.1, it might be aa:bb:cc:dd:ee:ff = 1, knowing that the network is 192.168.2.0/24.

Someday I may test that hypothesis out.
Click to expand...

We are talking L2 switches only though. I know Dell's PowerConnect series supports VLANs but are most definitely not L3 switches, so their MAC tables contain only mac addresses, interfaces, and vlans. Your example would require the switch to analyze L3, something an L2 switch can't do.

I guess until someone chimes in that knows or someone drops the scenario into real hardware and looks at the frames, its just gonna be guesswork.
 
USMCGrunt said:
We are talking L2 switches only though. I know Dell's PowerConnect series supports VLANs but are most definitely not L3 switches, so their MAC tables contain only mac addresses, interfaces, and vlans. Your example would require the switch to analyze L3, something an L2 switch can't do.

I guess until someone chimes in that knows or someone drops the scenario into real hardware and looks at the frames, its just gonna be guesswork.
Click to expand...
That's why I said my choice of wording was poor; I'm not talking about ROUTING traffic, but using a single simple switch ( no vlans ) to switch traffic among two separate networks.

No biggy; it was a side conversation anyway.
 
Maybe this is interesting for some people. I know most of you are past this.

Start with an empty MAC table in the switch and empty ARP tables in two hosts A and B. Let MAC addresses of hosts A and B be AA:AA:AA:AA:AA:AA and BB:BB:BB:BB:BB:BB just for example. I know these are not valid. Any other MAC address I mention is verbatim, e.g. FF:FF:FF:FF:FF:FF is literally the broadcast address. A and B have IP addresses x.y.z.a/24 and x.y.z.b/24.

A wants to send a single packet to B

1. A looks into its routing table to see if there's an entry for x.y.z.b. No.
2. A looks into its routing table to see if x.y.z.b is inside any networks it knows how to reach, starting with the smallest subnet. Yes, by configuring x.y.z.a/24 onto an interface on A, there's also an entry for x.y.z.0/24 in A's routing table that says x.y.z.0/24 is directly reachable via interface so-and-so.
3. Because it's directly reachable, A sends an ARP broadcast with src AA:AA:AA:AA:AA:AA and dst FF:FF:FF:FF:FF:FF asking for the MAC address of x.y.z.b.
4. The switch receives that broadcast on A's port and enters A's MAC address and port into its MAC table since it didn't know A's MAC address before.
5. Since the multicast bit in FF:FF:FF:FF:FF:FF is set, the switch broadcasts that frame on all ports unconditionally.
6. The frame eventually gets output on B's port and B receives the (unmodified) frame with src AA:AA:AA:AA:AA:AA and dst FF:FF:FF:FF:FF:FF. Since the multicast bit is set, B looks at the frame even if dst is not its own MAC address, to see if there's anything in the frame the kernel might care about.
7. B notices its an ARP request from AA:AA:AA:AA:AA:AA and notices its own IP address in it.
8. B sends an ARP reply with src BB:BB:BB:BB:BB:BB and dst AA:AA:AA:AA:AA:AA, saying that x.y.z.b belongs to BB:BB:BB:BB:BB:BB.
9. The switch receives that reply on B's port and enters B's MAC address and port into its MAC table since it didn't know B's MAC address before.
10. Since the multicast bit in the frame is not set, the switch must figure out where to send it. It looks in its MAC table to see if it knows AA:AA:AA:AA:AA:AA. Yes, AA:AA:AA:AA:AA:AA is on A's port. Frame goes to port A. If the switch didn't know AA:AA:AA:AA:AA:AA at this point - maybe the MAC table entry just timed out - it would output the frame on all ports again. It would then enter A's MAC address into its MAC table again as it receives the next frame from A.
11. A receives the ARP reply and enters x.y.z.b and BB:BB:BB:BB:BB:BB into its ARP table, which causes a routing table entry to appear for x.y.z.b. (not entirely sure about this part).

Since A now knows how to reach B, it can send frames with AA:AA:AA:AA:AA:AA and BB:BB:BB:BB:BB:BB as src and dst and the switch just looks into its MAC table to forward the frames to the right port.

I think that should roughly cover it. If there's some gross errors in there, correct me.

You can think of an Ethernet connection to a switch as a connection to a 1-port hub. The packets don't need to be addressed _to_ the switch. They just get put onto the wire and the switch "snatches" them off the wire. It's a direct electrical connection after all, so the switch of course gets all the packets that all connected stations emit.
 
TCM2 said:
...snip...
Click to expand...

This is a solid explanation.

To clarify on point 11. Host A doesn't update its routing table, it simply makes a note of the IP to MAC relationship in its local ARP table. The ARP table would be consulted between points 2. and 3. in your post (though initially being empty) before sending an ARP request. In later iterations, A would no longer need to send an ARP request since x.y.z.b would already be in its ARP table.
 
Code: 
192.168.0.211      00:0c:29:62:d1:6b  UHLc       1       38     -     4 vmx0

Actual routing table entry on OpenBSD box. .211 is not the box itself but a different one on the same segment.

Edit: But yeah, not all OSes seem to do that.
 
Last edited:
TCM2 said:
Code: 
192.168.0.211      00:0c:29:62:d1:6b  UHLc       1       38     -     4 vmx0

Actual routing table entry on OpenBSD box. .211 is not the box itself but a different one on the same segment.

Edit: But yeah, not all OSes seem to do that.
Click to expand...

The 'L' flag in that print out means that the entry is being managed by a link layer protocol, in this particular case the protocol is ARP. It shows up in netstat for informational purposes but isn't really part of the routing table (or this is a routing optimization OpenBSD does that I'm not familiar with).

You should be able to run 'arp -a' on OpenBSD and see the complete ARP table.
 
Last edited:
I would add onto that explanation something about checking to see if destination IP is in source subnet, then check arp table, arp if needed. Shouldn't that happen first?
 
The authoritative place that decides routing is the routing table. You could perfectly well override ARP with a host route, e.g. 192.168.0.0/24 is on one of your interfaces, but you route 192.168.0.10 via some VPN. Then there won't be any ARP traffic for it.
 
It seems that a lot of the stuff in this thread has been ironed out... but I just wanted to chime in at the end (I'm very sorry I missed this) and say that this was an entertaining read to see others be educated on how L2 switches work.
 
TCM2 said:
Maybe this is interesting for some people. I know most of you are past this.

Start with an empty MAC table in the switch and empty ARP tables in two hosts A and B. Let MAC addresses of hosts A and B be AA:AA:AA:AA:AA:AA and BB:BB:BB:BB:BB:BB just for example. I know these are not valid. Any other MAC address I mention is verbatim, e.g. FF:FF:FF:FF:FF:FF is literally the broadcast address. A and B have IP addresses x.y.z.a/24 and x.y.z.b/24.

A wants to send a single packet to B

1. A looks into its routing table to see if there's an entry for x.y.z.b. No.
2. A looks into its routing table to see if x.y.z.b is inside any networks it knows how to reach, starting with the smallest subnet. Yes, by configuring x.y.z.a/24 onto an interface on A, there's also an entry for x.y.z.0/24 in A's routing table that says x.y.z.0/24 is directly reachable via interface so-and-so.

/snip
Click to expand...

Perhaps I'm misunderstanding what you are trying to convey, but your points are spot on for the most part, however I'm confused on #1 and #2:

Host A doesn't look at it's routing table for Host B, as they are directly connected to the same subnet. If Host B was x.y.a.b/24 then it would look at its default gateway in the routing table and it would ARP broadcast for its default gateway MAC. If Host A and Host B are on the same subnet as in your example, it would ARP broadcast for Host B's MAC address and then proceed. The LAN switch that connects the segment would update its CAM table with Host A and Host B's MAC address.

EDIT: My mistake TCM2, you are correct that it would obviously need to use its routing table to determine what is directly connected.
 
You must log in or register to reply here.
Back
Top