cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1675
Views
0
Helpful
10
Replies

On a switch after a broadcast why should a network computer accept

Cisco10956
Level 1
Level 1

On a Cisco switch, after a broadcast has taken place and a computer connected to the switch has accepted the frame even though it doesn't have a destination MAC for this computer that has accepted.

Question :
Why did this computer accept this frame and message.
Is it because of the ip address in the ip packet the frame is holding.

 

 

THanks and Have A great Day

1 Accepted Solution

Accepted Solutions

Jon Marshall
Hall of Fame
Hall of Fame

 

If the destination mac address is a broadcast then all PCs in the vlan see it but only the PC with the correct IP address will accept it as you put it. 

 

Jon

View solution in original post

10 Replies 10

Hi

 If the mac address it is not recognized by the destination PC, it will discary the fram and not accept it. 

Flavio, yes I understand that

Jon Marshall
Hall of Fame
Hall of Fame

 

If the destination mac address is a broadcast then all PCs in the vlan see it but only the PC with the correct IP address will accept it as you put it. 

 

Jon

Joseph W. Doherty
Hall of Fame
Hall of Fame

"On a Cisco switch, after a broadcast has taken place . . ."

Are you asking about about a broadcast frame, broadcast packet or unicast frame/packet that a switch replicates to all ports but the ingress port?

If you're asking a broadcast frame or packet, a host will physically accept such because frame or packet having a broadcast address is intended for all hosts to accept (i.e. a host should accept it).

However, depending on the contents of the broadcast frame or packet the host might quickly determine the content is of no interest to the host and quickly drop/dispose of the received broadcast frame or packet.

Again, as mentioned in my prior posting, to another of your questions, host accepting, or not, physically received frames/packets has nothing to do whether frame/packet was transmitted on a switch, Cisco's or other vendors.

 

PS:

Ethernet hosts will, at the Ethernet NIC, (generally) immediately ignore unicast frames/packets to an address not being used by the host, multicast frames/packets to an address of no interest to the host.  However, again, broadcast frames/packets are always accepted.  BTW, because of the latter, broadcast frames/packets, and their volume, is often why number of hosts are limited within the same broadcast domain.

Hello Joseph

 

Sorry your answer is not in contrast to what I am asking. 

 

After a switch has a flooding, then broadcast of the one frame, - Only one PC will accept the frame with-out the destination MAC address.

 

Why does this PC accept this Frame. ???

       - Is it because the frame has an IP packet - with the ip address of the destination computer.  

             If Not then why does it accept the frame. 

 

THanks 

 

 

"If Not then why does it accept the frame. "

Why? As noted in my prior post (by Ethernet design) every host NIC that receives a broadcast frame will accept it.  Often it doesn't want it but it must "examine" it to determine that.

Also as noted in prior post (by Ethernet design) every host NIC will only accept unicast frames, of a MAC being used by NIC and/or multicast frames, "of interest" to the NIC, and/or broadcast frames.  All other frames will be ignored (unless NIC is running in promiscuous mode, see promiscuous mode, which will also touch on acceptance or dropping other received frames, i.e. unicast, multicast and broadcast).

Also again, host NIC processing is independent of hub or switch.  You keep mentioning switch flooding.  Well, consider, original Ethernet on a shared media like 10Base2 or 10Base5 "flooded" all frames to all hosts (on the same "wire") all the time.

"Switch flooding" occurs for unicast, when destination port is unknown, multicast, when IGMP snooping isn't active, and/or broadcast (all the time).  On switches, by restricting unicast flooding and/or multicast flooding, it frees bandwidth to the host(s) and it may also reduce resource usage on the host.  I.e. it allows the network to operate more efficiently/"better", but, once again, hosts "don't care" in that they process received frames just like they would on shared media.

I suggest you look further into Ethernet operation on shared media, like 10Base2 or 10Base5, then L2 segmentation using bridges, then the impact of 10BaseT (hubs), then switches (multi-port bridges).  Doing so, you might start to see your "why" a host accepts some frames and not others, doesn't depends on hub or switches (or routers) being used, yet also, perhaps, better understand why Ethernet moved to hubs and then switches.

In this post, I haven't yet touched on L3 packet receiving considerations, as I think, at this point, they would confuse you further, yet, hosts don't care how the packet was sent to them, regarding how they will process it.  There's some further complexity, with how L3 can interact with L2, for example, L3 has a larger address block for multicast than L2 Ethernet supports.  So, a host might accept a multicast Ethernet frame that is not for an IP multicast address "of interest" to the host.  Like Ethernet frames, "why" host will accept an IP packet, or not, doesn't depends on hubs, switches or routers.

Why should a destination pc accept an ethernet frame, even if there is no destination mac address in the Ethernet frame. ??

- The Ethernet frame has to be verified by destination computers to specific its network card.


Example : and answer.
This is broadcasted to all the computers on the switch: Ethernet frame = [ "192.168.50.10" : Src:D7895_A Dst:unknown ???_B ]
Only one destination computers network card having "192.168.50.10" will verify, then accept this same Ethernet Frame because it has the same ip packets ip address.

Then, the destination computers network card will answer back to the Ethernet Frame with it's MAC address and send it to the switches MAC address table to be writen into the table.
- Finished


IF you disagree please by all means tell me why. ??

"IF you disagree please by all means tell me why. ??"

There appear to be so many possible misunderstandings in your posting, it's difficult to know where to start.  Further, I don't mean to seem argumentative, but have you truly read and tried to understand my prior posts?  Reason I ask, not only are we not on the same page, unclear we're even in the same book.

For example: "Why should a destination pc accept an ethernet frame, even if there is no destination mac address in the Ethernet frame. ??"

Ethernet frames, to my knowledge, always have destination MAC, but it's not always a unicast MAC.  So, there are cases where a PC will "accept" an Ethernet frame with a MAC other than the NIC's unicast MAC.

See https://www.ccnahub.com/ip-fundamentals/understanding-ethernet-mac-addresses/ 

or see https://networkengineering.stackexchange.com/questions/69975/mac-address-and-unicast-multicast-and-broadcast

or see https://study-ccna.com/unicast-multicast-and-broadcast-addresses/

"The Ethernet frame has to be verified by destination computers to specific its network card."

Indeed, but again, don't presume the frame's destination MAC must be the PC's NIC MAC.  Also the NIC, itself, can do some "verifications", but not all of them.

There are Ethernet frames, that a PC NIC will accept, but with further PC examination, beyond the NIC filters, the PC may ignore the Ethernet frame the NIC accepted.

(Have you investigated how Ethernet works on shared media?  [As I earlier suggested.])

"This is broadcasted to all the computers on the switch: Ethernet frame = [ "192.168.50.10" : Src:D7895_A Dst:unknown ???_B ]
Only one destination computers network card having "192.168.50.10" will verify, then accept this same Ethernet Frame because it has the same ip packets ip address."

Ah, note the word "broadcasted"!  This appears to be an ARP example.  Destination addresses, both MAC and IP, will be broadcast addresses.  All PCs receiving the ARP will open the frame/packet to (then) determine what IP is being requested so host, with the requested IP, can reply.

Also a) "This is broadcasted to all the computers on the switch", may not be true if a VLAN switch and b) it's also all hosts on the same L2 broadcast domain that receive the broadcasted frame, i.e. possible other switches and/or hubs, etc.  (One reason, in my prior posts, I keep noting to avoid concerning yourself with hubs and/or switches - i.e. they don't matter, logically.)

"Then, the destination computers network card will answer back to the Ethernet Frame with it's MAC address and send it to the switches MAC address table to be writen into the table."

First, nothing is explicitly sent to switch.  Switches automatically note, in their MAC to port table, all frames source MACs, and what port the frame ingressed on.  In most cases, switch would already have the replying host's MAC before the ARP request.  However, with the ARP reply, for an existing MAC known to the switch, switch will update its timeout for that entry.

Second, don't recall if ARP reply has anything explicitly defined beyond it's an ARP reply, because the information sought by the ARP request is present in the reply's frame/packet.

In the process of my research, there have been examples where it was said that in the frame - the destination mac is not known.

- This of course can be a mistake on the person or person who posted this information. This is also very bad information on their part. 

 

I will take what you said about frames as having and always having a src and dst mac address. Which makes sense if the frame is going to get identified by the destination computer network card. 

 

I do appreciate you input and information, and want you to continue to get your answers. " They are valuable 

 

However, you have a habit of over explaining.  - Please work on getting right to the point.  

This explanation is way to long.  

 

Thanks 

 

 

"In the process of my research, there have been examples where it was said that in the frame - the destination mac is not known."

More likely, examples are where a unicast MAC is unknown.

"This of course can be a mistake on the person or person who posted this information. This is also very bad information on their part. "

Perhaps person posting did make an error, or perhaps you misunderstood what was posted.  Do you have a reference link to it?

"However, you have a habit of over explaining. - Please work on getting right to the point. "

Laugh, actually I do try to get to the point, but when someone keeps, basically, asking the same question, in different ways, at least to me, a more in depth answer appears needed.  Also, for to the point answers, ask to the point questions.

 

PS:

BTW, just wondering, is English your native language?

 

Review Cisco Networking for a $25 gift card