Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 199
  • Last Modified:

How to gauge if broadcast traffic is a problem due to subnet size?

So I took over a network recently where they using a very large subnet (10.4.0.0/16).  Of course a subnet can never be that large, but I didn't change it as they had a lot of servers and other devices in production and didn't want to change subnets.  They are now using about 350 IP Addresses from this subnet.  Infrastructure is Completely Cisco.  All switches are Cisco 3560G's.  What is a safe number to grow this subnet before I should start another VLAN?
0
denver218
Asked:
denver218
  • 4
  • 3
1 Solution
 
PredragNetwork EngineerCommented:
Same subject here.
0
 
Don JohnstonCommented:
The general rule of thumb is 20%.  That is, when broadcast traffic exceeds 20% of the total traffic, that's when you want to start looking at breaking up the network.

The first step is making sure you check the traffic during normal traffic. If you look at it in the middle of the night, you'll probably be way over 20% since there's not as much unicast traffic.

Because it's based on total traffic, switches can make this a bit of a challenge.  So what I like to do is check the interface statistics on trunks that see the most traffic.  Clear the counters first and then wait an hour.  Do a "show interface" on the trunks, divide total traffic by broadcast and you've got your number.  I like to check this at various times during the day over multiple days.
0
 
denver218Author Commented:
So what number do I divide by the number of broadcasts:

GigabitEthernet1/0/4 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet, address is 001b.d511.8d04 (bia 001b.d511.8d04)
  Description: TOP_3560G-48
  MTU 1530 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 3/255, rxload 4/255
  Encapsulation ARPA, loopback not set
  Keepalive not set
  Full-duplex, 1000Mb/s, link type is auto, media type is 1000BaseSX SFP
  input flow-control is off, output flow-control is unsupported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output 00:00:19, output hang never
  Last clearing of "show interface" counters 00:15:56
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 15988000 bits/sec, 6113 packets/sec
  5 minute output rate 15661000 bits/sec, 5672 packets/sec
     6417526 packets input, 2451754699 bytes, 0 no buffer
     Received 427839 broadcasts (280131 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 280131 multicast, 0 pause input
     0 input packets with dribble condition detected
     5993425 packets output, 2412545171 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier, 0 PAUSE output
     0 output buffer failures, 0 output buffers swapped out
0
What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

 
Don JohnstonCommented:
6417526 packets input, 2451754699 bytes, 0 no buffer
     Received 427839 broadcasts (280131 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 watchdog, 280131 multicast, 0 pause input
     0 input packets with dribble condition detected

So in 15 minutes, you've received 6,417,526 packets of which 427,839 were broadcast. This puts the broadcast received on this port at 6%.
0
 
denver218Author Commented:
Thanks.  If I divide 6417526/427839 that equals 14.99.   How did you get 6%?  I must be missing something.
0
 
Don JohnstonCommented:
427839/6417526=.06
0
 
denver218Author Commented:
Ok, thanks.  So its broadcasts/packets input.  

So if I did another trunk port:

 1668527 packets input, 376258519 bytes, 0 no buffer
     Received 620 broadcasts (615 multicasts)

It would be 620/1668527 which would equal approximately 3.72% broadcast traffic right?
0
 
denver218Author Commented:
Thanks
0

Featured Post

Nothing ever in the clear!

This technical paper will help you implement VMware’s VM encryption as well as implement Veeam encryption which together will achieve the nothing ever in the clear goal. If a bad guy steals VMs, backups or traffic they get nothing.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now