cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4393
Views
30
Helpful
9
Replies

Ideal Broadcast Domain Size & ARP Target Address & ARP Cache Overflow

Iluvnetwork
Level 1
Level 1

First, I would like to know what is the ideal broadcast domain size. I guess it is always to better to have more collision domains. But I have not been taught about the ideal broadcast domain size. So, I googled and figured out that the ideal braodcast domain size is usually is /22. In other words, 1024 - 2(Network ID + Broadcasting Address) hosts can be in one network. If /22 is the correct answer for my question, could you please explain to me why /22 is the ideal broadcast domain size?

For address resolution protocol, I see 0.0.0.0 or 255.255.255.255 as a target address in Wireshark. In packet tracer, the target address is always 0.0.0.0. Which one is right target address? I would appreciate if you can give me some explanations between 0.0.0.0 and 255.255.255.255 as the target address.  

What happens if ARP cashe overflows? I asked people around me, but sadly none of them knows what actually happens if ARP cashe overflows. I am curious about the ARP cache overflow because static routing by outgoing interface in point to multipoint case could be really dangerous and ARP cache overflows could happen.     

 

1 Accepted Solution

Accepted Solutions

Joseph W. Doherty
Hall of Fame
Hall of Fame
This is a "it depends" answer.

The common problem with large network segments is broadcast traffic. Broadcast traffic, even with switches, goes to every port, so every port loses bandwidth to them. Then, every host getting broadcasts needs to accept then, open them up, and see if they are anything the host must be concerned with. I.e., so broadcasts, besides burning port bandwidth, also burn host resources. (Broadcasts can be so detrimental, that's why some switches support broadcast storm policers.)

Traditionally, hosts usually don't have issues, on switched networks, if the network is limited to the number of hosts supported by a /24 or /23. /22 might be okay too. Much depends on the nature of your hosts and their needs. For example, early Microsoft NetBEUI were very "chatty" compared to IP networks, so you didn't want as many hosts on the same network segment.

Or, for example, one VoIP vendor recommends networks not larger than a /24 if PCs and VoIP phones share a port, but are on separate VLANs or a /23 if the VoIP phones have their own port. (Student exercise - why?)

Where I work, we're using /20s for wireless VLANs, but with those, the wireless controller doesn't replicate traffic to all hosts as happens on a wired network, so, host segment can be larger.

As to your question on ARP cache overflow, it would depend on how the host deals with it. Such an overflow might cause the oldest or some other "random" ARP entry to be pushed out of the cache, or the ARP entry might not be cached, or it might crash the host. (Another student exercise, of the foregoing, what's the best solution?)

View solution in original post

9 Replies 9

Philip D'Ath
VIP Alumni
VIP Alumni
There is no specific answer to this question. You basically want a size that does not cause an impact to your systems or applications.

Personally, I like to stick to using /24's.

~chris
Level 1
Level 1

There is no general answer to the size of BC domain... keep your BC as small as possible.

My personal recommendation is, to use not more than a /24 per BC domain.

 

I guess it is always better to have a small BC domain because of broadcasting traffics. If possible, could you please explain to me why your recommendation is to use not more than a /24 per BC domain?

Joseph W. Doherty
Hall of Fame
Hall of Fame
This is a "it depends" answer.

The common problem with large network segments is broadcast traffic. Broadcast traffic, even with switches, goes to every port, so every port loses bandwidth to them. Then, every host getting broadcasts needs to accept then, open them up, and see if they are anything the host must be concerned with. I.e., so broadcasts, besides burning port bandwidth, also burn host resources. (Broadcasts can be so detrimental, that's why some switches support broadcast storm policers.)

Traditionally, hosts usually don't have issues, on switched networks, if the network is limited to the number of hosts supported by a /24 or /23. /22 might be okay too. Much depends on the nature of your hosts and their needs. For example, early Microsoft NetBEUI were very "chatty" compared to IP networks, so you didn't want as many hosts on the same network segment.

Or, for example, one VoIP vendor recommends networks not larger than a /24 if PCs and VoIP phones share a port, but are on separate VLANs or a /23 if the VoIP phones have their own port. (Student exercise - why?)

Where I work, we're using /20s for wireless VLANs, but with those, the wireless controller doesn't replicate traffic to all hosts as happens on a wired network, so, host segment can be larger.

As to your question on ARP cache overflow, it would depend on how the host deals with it. Such an overflow might cause the oldest or some other "random" ARP entry to be pushed out of the cache, or the ARP entry might not be cached, or it might crash the host. (Another student exercise, of the foregoing, what's the best solution?)

I am literally new to the IT. I recently started to study network and programming(Python) from no computer or network background. So, probably my answers are not right, but I will give a shot.
I guess, if PCs and VoIP phones are sharing a same port(PCs or VoIP phones would get packets they don't want which leads to burning resources). In this case, I guess the best solution is to separate them using VLANs. If PCs and VoIP phones have their own port, I guess you don't need to separate them by VLANs, but you don't want the boradcast domain size too big because of broadcasting traffics.
For ARP one, I think ARP cache overflow could happen in router only if I configure my router by static routing + outgoing interface. So best solution I can think of at this point, using static routing + next hop address.
I am literally a newbie. Please let me know if my solutions are not correct.

You're warm.

Assume in the case of the VoIP phones, whether they share a port with a PC or not, in either case they are on their own VLAN, assume number of VoIP phones for either case also remains the same. So, again, why would the vendor recommend different max network sizes?

You're correct, ARP cache overflow can happen when you configure a router using just the interface and not the next hop. I.e. using next hop would keep the cache from filling. But, the question was, what's likely the best way for a device to deal with a ARP cache overflow if it does happen?

PS:
Take another stab try, and depending on your answers, I'll explain further the "right" answers.

I am a super newbie. But, I will take another shot. First, if they are not sharing the port, the vendor would definitely recommand bigger max network sizes. Because, if they are sharing the port, they are also sharing the bandwidth. Thus, if they are not sharing the port -> not sharing the port's bandwidth ->  PCs and Phones can be more chatty -> More Boradcast Traffics can be allowed -> Broadcast Domain Size can be increased -> the vendor would definitely recommand bigger max network sizes.
For second question, I honestly am not sure what to do since I have never seen a ARP cache overflow! If I can manually change the ARP cache size, I would definitely increase it. But since I have never heard about the increasing ARP cache size, I guess this solution probably won't work. The best solution I can think of at this point is to check which interface is point to multipoint. Then, I would check the routing table. If the point to multipoint interface is configured using the outgoing interface, I would fix it to the next hop. If that still doesn't fix the problem, I would call the CISCO :)

Correct. If you share a port (with a VoIP phone and PC) you're sharing physical bandwidth (although the two devices are on different VLANs).

For the second answer, I suspect Cisco devices just keep growing the ARP cache, dynamically, until they run out of free RAM. (This would explain why small routers configured with a default route to an interface [especially for Internet destinations] often hang after a few days of operation.)

The more classical solution when you fill a cache is to replace some "random" or the oldest entry. Cisco probably didn't use this "solution" because it's unlikely to happen for non-Internet destinations and/or if you use a next hop IP. Growing the cache dynamically avoids purging perhaps "needed" entries. Most of the time, this approach works just fine.

Thank you very much for your patience and kindness :) I really learned aaaaa lot!
Review Cisco Networking products for a $25 gift card