0

I know that hubs send broadcast packets, so every packets is received by each node in the broadcast domain. I read that frames that are received but that aren't addressed to a NIC'S MAC address are dropped. But I mean if it is a broadcast packet, it shouldn't be accepted by each node?

8
  • Hubs are obsolete since way back. Do you perhaps mean switch?
    – schaiba
    Nov 11 '19 at 15:12
  • Nono, I mean hubs and I refer to this post
    – FbaStack
    Nov 11 '19 at 15:17
  • "I know that hubs send broadcast packets, so every packets is received by each node in the broadcast domain. I read that frames that are received but that aren't addressed to a NIC'S MAC address are dropped. " -- true for hubs. Broadcast packets don't really make sense with repeaters (hubs), only for switches.
    – schaiba
    Nov 11 '19 at 15:22
  • 2
    There is a difference between "mindless" repeating (what a hub does) and broadcasting (what a switch does) . To be precise, broadcasting is something that a switch "chooses" to do, while a hub will repeat what it "hears" "mindlessly".
    – schaiba
    Nov 11 '19 at 15:38
  • 1
    Hubs have no idea what they are sending. Hubs merely amplify and repeat the signals received to all other hub interfaces.
    – Ron Maupin
    Nov 11 '19 at 16:57
2

Hubs are layer 1 devices. As they receive electrical impulses constituting a frame, they forward them out all ports other than the receiving port.

This is regardless of whether the l2 destination is unicast, multicast, or broadcast (ff:ff:ff:ff:ff:ff).

This may result in an Ethernet collision if multiple hosts transmit traffic to the hub simultaneously.

A host’s Ethernet adapter will pass certain received frames up the protocol stack for further processing ( generating a cpu interrupt)

  1. Unicast frames which match its Ethernet unicast address
  2. Multicast frames destined to any l2 multicast address which the host is “listening” to
  3. All broadcast l2 frames

If the l2 frame includes a l3 packet, the host cpu will de-encapsulate and process it.

If the interface is placed in “promiscuous mode” ( by tcpdump for example) it is possible for all received Ethernet frames to be sent up the protocol stack and generate interrupts.

0
1

I know that hubs send broadcast packets

Hubs don't send anything (by themselves). They forward bits (or symbols) on the wire, regardless of framing and addressing.

so every packets is received by each node in the broadcast domain.

Every frame is forwarded to each hub port and ending up on each node in the broadcast domain, yes. With a repeater hub, the broadcast domain is identical to the collision domain.

I read that frames that are received but that aren't addressed to a NIC'S MAC address are dropped.

By the NIC, yes.

But I mean if it is a broadcast packet, it shouldn't be accepted by each node?

A NIC (not in promiscuous mode) processes frames addressed to its MAC or the broadcast address or a multicast address that it was configured for. All other frames are dropped/ignored.

Early Ethernet relied on the NICs sorting out unwanted frames as the shared wire transmitted each frame to all the nodes on the wire. A repeater hub replicates that behavior in that it copies each bit from the receiving port to all other ports. Only one port can be receiving at any time, anything else received causes a collision. It doesn't make any difference to where that bit's frame is addressed to as a repeater (hub) has no concept of frames and addressing.

Addressing does make a difference with switches that selectively forward unicasts by MAC address. They handle broadcasts similar to how a repeater handles everything: the broadcast is "flooded" out of all ports but the one it was received on.

8
  • Thanks, but for example in a network with 3 computer A,B,C (no-one in promiscuous mode). Supposing arp cache are empty, A pings B, why a sniffer in C can see arp request/reply and ICMP request/reply?
    – FbaStack
    Nov 11 '19 at 18:32
  • @Fab996 I assume you're referring to a repeated, single collision domain network? All traffic between A and B is also physically seen by C's NIC - but unless it's broadcast (ARP request) it's dropped there (unicast ARP reply). A sniffer usually activates promiscuous mode, so it's able to capture the unicast traffic as well.
    – Zac67
    Nov 11 '19 at 18:39
  • So a sniffer not in promiscuous mode shouldn't see ARP reply and ICMP request/reply because they are unicast? How can i check with tcpdump, I used this command tcpdump -p -enni <interface>, is it right?
    – FbaStack
    Nov 11 '19 at 19:10
  • A sniffer not using promiscuous mode won't see alien unicast, e.g. ARP replies from B sent as unicast to A. The -p should stop tcpdump from using promiscuous mode.
    – Zac67
    Nov 11 '19 at 20:10
  • Ah okay because in the comment above you said "is also physically seen by C's NIC", so I thought that the sniffer sees unicast packets but then they are dropped, but maybe I understood wrong. So unicast traffic is not seen by a sniffer working in a no promiscuous mode?
    – FbaStack
    Nov 11 '19 at 20:23

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.