08-08-2017 09:23 AM
Is there a best practice for MAG aging time in order to minimize the broadcast of unicast traffic on a VLAN? We've experienced pretty high values in our setup (Cisco routers, Ciena/Cyan transport, Calix access) due to a very low setting on Ciena (45s) compared to others (300s). We brought them to the same value on transport and access (300s) while Cisco being a bit lower (280s on both router side, 300s on switch side) and that cut that traffic down to 2-5 times. However, the amount of that traffic is still too high (up to 300mbps) given there are about 800 hosts on that domain that do not exceed 1.5gbps traffic at peak.
Or should I better ask: what is the best practice in attempting to lower the amount of broadcast unicast traffic on a VLAN having a large number of hosts?
08-08-2017 09:53 AM
First, I recommend that you research the MAC forced forwarding feature. You can find specifics about it in the Engineering and Planning Guide and it cuts down on a lot of broadcast traffic. The other thing I'll mention is that 800 hosts is pretty high for a single broadcast domain. I don't know that there's an official best practice on the subject, but I try to limit domains to 512 hosts.
08-08-2017 10:53 AM
I think what sorin might be reffering to is in a best practice training that calix had they had a specific slide that specifies "ensure upstream router ARP timer <= the MAC age timer in access network devices". Calix does a great job in bringing this issue to light but it be nice to know what people are setting there arp timers and mac age that gives the best performance.
08-08-2017 11:09 AM
MACFF is enabled on the vlans that are experiencing high broadcast unicast traffic. The traffic we see broadcasted is from gateway MAC to the various hosts on the VLAN. That traffic is not flowing under MACFF rules.
Now, 512 hosts is quite low compared to what Calix recommends, as you can see below:
08-08-2017 08:34 PM
Sorin: what is broadcast unicast traffic? Do you mean unicast traffic is being flooded?
We set our ARP aging time to 270 or 300 seconds and our MAC table to 300 seconds.
We did have issues with unicast traffic being flooded a few years ago, and we traced it down to a bug in our Brocade ICX6610 stack -- took many months to persuade Brocade that it was an issue and then a few more months for them to identify and code a fix, but that was a big help to our own network.
But biggest help was VLANs with lower number of hosts and MACFF.
08-08-2017 10:11 PM
@frnkblk yes, that is one of the ways our vendors calls the unicast traffic being flooded all over the place.
So far we came down to conclusion that the HSRP for redundant gateways might be also generating quite some unicast traffic that is flooded everywhere. We are going to investigate that soon and see if that is true.
08-08-2017 10:12 PM
we set it to arp timeout to 280s and changed the ciena (cyan) from 45s to 300s and that looked to have made a significant difference, and yes sorin is reffering to unicast traffic is being flooded. We currently do have MACFF on. Out of currisoity whats the max amount of hosts you guys have found does not degregate a vlan? We currently have an open ticket with ciena to understand why the cyan platform default out the box was set to 45s.
08-09-2017 07:21 AM
We also have a Cyan Z33/Z77 transport network -- just curious, where is that MAC address table aging set?
If your Cyan was set ot age its MAC table in 45 seconds I can see how flooding could be an issue for any host that didn't talk in 45 seconds. As mentioned elsewhere, by having an ARP table age <= MAC address table age, there will always be some traffic exchanged <= ARP table age timer that will keep the MAC address table populated.
Based on the information in Calix's best practices guide and our own negative experiences, we are trying limit the number of hosts in a VLAN to no more than 500 to 750.