Difference between broadcast and unknow unicast flooding

[cosimodagostino]

Hi everyone I have read the differences between unknown unicast flooding and broadcast on this forum. Broadcast ok is clear but Unknown unicast flooding there's a bit of confusion. How does the host already know the destination mac address without making an arp request? At this point I think that the sending host had the destination mac address in its arp cache and that for example an attack on the mac address table, the destination host's mac is overwritten by fake mac addresses. The only ways the host has to know the destination mac address are: 1) Arp request 2) mac table of the switch 3) host arp cache At this point in case of Unknown unicast flooding I think that the sending host knows the mac address of the destination host via arp cache. What do you say?

[Karsten Iwen · Accepted solution]

Then ARP cache can be relevant here. Although Windows uses a quite short ARP-cache timeout, an IOS router has a quite long one, longer that the MAC-address-timeout on the switch. This can lead to unknown unicast packets on the switch.

[cosimodagostino]

Let's assume there are no routers and there is a mac address flooding attack. Switch receives a frame from a host with target mac. Due to the attack on the table, the switch does not have the destination mac address inserted in the host frame. What is not clear to me in this scenario described how does the host get the destination mac address if the switch table does not have an entry for this mac?

[Karsten Iwen]

In this type of attack, the destination MAC addresses are typically randomly generated. The sending host doesn't need to have them in advance.

[Giuseppe Larosa]

Hello @cosimodagostino ,

as correctly noted by @Karsten Iwen  the attacker PC does not want to talk to a real existing host(s) to perform the attack it sends out correct ethernet frames each of them with a different randomly generated destination address or source address.

By using different source MAC addresses the attacker will try to fill the CAM table of the switch so that legiitimate users MAC addresses are treated as unknown unicast MAC and flloded to all ports on the VLAN including the port connecting to the attacker.

This provides to the attacker the capability to see interesting traffic and even to perform some man in the middle MITM attacks.

Port security can easily stop this kind of attacks by putting a max number of MAC addresses that can be learned per single port and reacting to a violation using error disable of the affected port.

Hope to help

Giuseppe

[cosimodagostino]

Yes I know this; it was an example that is to understand the concept of unknown unicast flooding is based on forwarding frames with unknown destination macs in the table. What was not clear to me was: how does the host know the destination mac address? At this point it is logical to think that previously the host had already searched for the mac address associated with the destination ip and inserted in its arp cache table. In the meantime, for an X reason, the switch table has emptied itself, but the host still has the mac + ip association in its arp table. When this situation occurs the host uses its arp table before using the switch table, because otherwise it is not explained how the switch does not find the destination mac address in its table, while the host quietly creates the its frame knowing the target mac. The only way is that the host had it in its cache if the switch doesn't have an entry for the target mac. Why, let's make another hypothesis; host A does not have in its cache the ip - mac address association of host B, the same thing the switch does not have the association between the mac address and port to which host B is connected; in this situation, if host A wants to communicate with host B, it must send an arp request; if it makes this request, the switch table is automatically populated by mac of host A + host B

[Giuseppe Larosa]

Hello @cosimodagostino ,

if we speak of unknown unicast flooding in normal networks without an attack the root causes are the following:

a) ARP timeout in TCP/IP stack on PC end user devices is longer then CAM aging time on LAN switches ( 300 seconds on Cisco Catalyst)

b) the intended destination is silent ( not speaking at all) for a time greater then CAM aging time

if conditions a) and b) happen there is an uniknown unicast flooding, but as soon as the intended destination MAC address answers back the CAM entry is created again and unknown unicast flloding stops for that MAC address

ARP table is populated using ARP requests , ARP replies and received gratuitous ARP by each device indipendently.

Hope to help

Giuseppe

[cosimodagostino]

Good morning Giuseppe yes that was what I wanted to say that's why I put the example into play with the host. As you say the host arp has a longer time and in normal conditions the unknown unicast floading happens but it is normal; at that point the pc sends a broadcast later and solves the problem. I still study for the CCNA that's why maybe there was this misunderstanding. I gave a look at the ccnp program where we talk more about the unknown unicast flloding. I even read that if there are high and low bandwidths, unknown unicast flooding is continuously generated. As for my path at the moment it is okay so later I deepen hello and thanks

[Giuseppe Larosa]

Hello @cosimodagostino ,

>> t that point the pc sends a broadcast later and solves the problem

No, the PC sends to the intended unicast MAC address, but the first frame(s) is/are flooded by the switch as it does not remember where the destination is connected to. As soon as the destination host replies back the switch learns its MAC address location and unknown unicast flloding stops.

It is not the iniital sender that solves the problem but the intended destination host that starts to talk again.

Hope to help

Giuseppe

[cosimodagostino]

Yes ok I confused :); in unicast pc anwer it

[Joseph W. Doherty]

"As you say the host arp has a longer time and in normal conditions the unknown unicast floading happens but it is normal; . . ."

Actually, a) it's more abnormal than normal (as Giuseppe explains why in his latest post) and b) as far as I know (?) there are no standards for host or switch MAC table flush timers.

". . . at that point the pc sends a broadcast later and solves the problem."

I suspect by "broadcast", you mean a new ARP to refresh host's ARP cache.  If so, I believe Giuseppe misunderstood what you meant, because, yes, a new ARP would fix the unicast broadcast, but, again, only for a time.  In such a situation, unicast flooding would "cycle" on and off.

Again, this is abnormal, i.e. something we want to avoid.

BTW, you, I believe, keep thinking about the source host, and its ARP time out timers, but this problem can arise in transit "hosts" like routers, especially the last one sending to the destination host on the same L2 domain.

"I even read that if there are high and low bandwidths, unknown unicast flooding is continuously generated."

Can you reference where you read that?  It has me wondering how high and low bandwidths would cause continuous unicast flooding.

[Joseph W. Doherty]

"Broadcast ok is clear . . ."

Are you sure it's clear?  Are you aware of the impact of a "broadcast storm", and/or why we limit number of hosts per network?  (NB: Even w/o consideration of any "network failure" or "network attacks" situation.)

"How does the host already know the destination mac address . . ."

Unicast flooding doesn't have anything to do with the host.

Unicast flooding is a term, generally, used when discussing a situation, on switches, where unknown unicast and broadcast frame are processed, by the switch, alike.

To switches, the answer to your thread's header "Difference between broadcast and unknow unicast flooding", is basically, none.

However, to hosts, connected to those switches, there's a huge difference.  (In case you're unaware, to hosts, broadcasts need to be accepted and processed by the host.  Undesired unicast is ignored, often at the NIC.  To the host, an undesired unicast only consumes bandwidth to the host.)

BTW, you can have unicast flooding even when hosts have ARPed, and do have destination MACs.  See https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/23563-143.html for additional information.

[cosimodagostino]

Hi I think I'm not so spoiled on the subject ..... Unknown unicast floding (you can also read a book if you don't believe me) It means that the switch when it receives a frame with an unknown destination mac forwards it as if it were a broadcast but only after making sure that the target mac is not present in its table. When I refer to the host it is normal excuse who creates the frames with the destination host? Host A encapsulates the ip packet in a frame and inserts the destination mac address. Let's assume that the switch receiving the frame doesn't have this destination mac address in its table what does it do? Unknown unicast floding right? My question was if we have a switch without the target device output mac - port association, how does the host create the frame by inserting the target mac into the frame; Because it is obvious that if host A sends (as per standard procedure if it does not have the destination mac in its internal table), an arp request in broadcast (whose address is 192.168.1.123?), If it exists , Host C responding with an arp reply to host A, the switch populates the association mac address port to which host C is connected. In the latter situation Unknown unicast flooding does not occur. Let's go back to the case in which the switch does not have the mac address of host C but, Host A by magic has the mac address of Host C and manages to create the frame forwards it on its port the switch receives it registers the mac address of Host A but it doesn't find host C's mac address in its table and does unknown unicast flooding. But my question was and I understood it (maybe you didn't understand my question) how does Host A create the frame with destination mac address? The only answer is he had it in his cache

[Joseph W. Doherty]

Hosts, can have "static" ARP, IP/MAC, tables.  If they do, a host could send a frame, with a MAC, that has not been seen by a switch.  This, though, would be uncommon, and perhaps even more uncommon, no reply from destination host.  In the former case, first frame would be unicast flooded.  In the latter case, ever frame would be unicast flooded.  All this happening because the usual ARP has been bypassed by the static ARP entry.

However, even with the usual ARP, what can happen, as described in the reference I provided, is where, for example, in a case of asymmetric routing, with timeout timers on switches, and hosts, for their ARP and MAC table caches, differ, so that a host continues to "know" a destination MAC but a switch forgets it.  I.e. every thing is working, as expected, but then follow-up frames are unicast flooded.

Similar can also happen, again with different timer times outs between switches and hosts, where all the traffic is being sent in just one direction.  (IP camera, using UDP, perhaps?)

You're correct that an ARP should load the switch's MAC table, and the host's ARP table, but again, their flush timers can differ and traffic flows can be such that a switch, again, "forgets" the destination MAC's egress port while a sending host continues to generate frames for that destination MAC.  This will then cause the switch to begin, and continue, to flood those unicast frames.

What I believe you've been "missing", and the answer to your question, is assuming switch MAC tables and host ARP tables are always in sync.  When they are, and usually are, all's good.  When they are not, you have unicast flooding.

In some ways, this is a bit like assuming all routers have the same "good" understanding of a topology, but when they (sometimes) do not, you may have things like routing loops and blackholes.

[cosimodagostino]

Ok I was doing a case of unicast flooding with two switches. You did the example with two switches each of which connected with routers on a stick are two different cases of unknown unicast. Returning to the two switches without routers. Usually the arp on PCs, except for special needs, I don't think they understand often. My example was with a dynamic arp table following the classic request process. Obviously if you set up a static table it happens that the switch is not aware of the mac. In general unknown unicast flooding is that frame (it depends on the cases) that has a destination mac address that is unknown to the switch and not finding it in its table it also floods it to other connected switches (without vlan, I looked at an example in the book by Wendell Odom ) In the book there is an example where two switches are connected (without vlan) where he hypothesizes this: Fredd Pc is connected to Switch A; Switch A is connected to switch B via g0 / 2; Wilma pc is connected on switch B. The book writes: if Fredd pc forwards the frame to Wilma pc (frame that as you say he may have statically set in his arp table or was left in cache) and switch A in his table does not find an entry for Wilma's mac towards g0 / 2 on which it is connected, switch A forwards a frame on all ports except the one from which it was received to try to receive a response