You can find tcam utilisation mix in GUI :
"Administration - Routing resources"
or in CLI
#System router resources ip xxx
In new firmware Default value is 128, so a maximum of 128 IPv4 routed. I dont remember to see this parameters in firmware 1.0.0, i belive that in prior firmware the switch use IPv4 TCAM until he had ressource left.
You have maximum 466 tcam ressources in SG300, you have to find right balance between max IPv4 routed hosts and route/interface/qos/ACL utilisation. My case i've chose to raise it to 384 (256 today because actualy I can't reboot switch in production environement) and let 82 TCAM ressource for non ip rules.
I hope it help.
Help me understand this a bit better...
I have about 60 hosts "behind" the switch (connected to switch ports). They sit in their own VLAN 125, then I "route" any traffic that doesn't belong to that VLAN out port 52 to my firewall on VLAN0.
I should be way under that default max, since only about 60 IPs are on the switch, everything else should go to the default gateway... right?
The routing table shares the same TCAM resource for the three following IP entries types:
--> Static IPv4 routes entries
--> IP Interfaces (Assign IP address on port, LAG or VLAN)
--> IP Hosts (Dynamically assigned IP address)
Maximum reserved TCAM memory for all IP type entries = Max number of static routes + Max number of IP Interfaces * 2 + max Number of IP hosts.
I hope this answer your concern.
So we bought a brand new SG300-10MPP and cannot reproduce the problem on the latest firmware :) This is one of the newest hardware revisions: SG300-10MPP-K9-NA
I think we're going to try to factory reset our hardware, then rather than load the settings from our config file, just use the web gui to change enable dhcp relay and leave all the other features at their factory default on one of the sg300-52 we have.
Wish us luck, trying this on sunday afternoon.
This is definitely a bug in the Cisco Firmware :) But the good news is I have finally confirmed exactly what the problem is.
The DHCP protocol is unique because it requires a specific source port 68, in addition to the destination port 67. Most DHCP servers seem to happily reply to whatever source port the is however, even if it's out of spec.
In this case, the DHCP Relay Agent on the Cisco firmware is out of compliance because it's change the source port to 67, not 68 as specified by the RFC.
It just so happens that an over-zealous IPS firewall on our network was [silently] dropping these packets because they were malformed. Due to a really lucky misconfiguration, we had disabled said IPS firewall when we added the new switch and everything started working.
So in the end, definitely a Cisco firmware bug because they're no longer fully compliant with the RFC, but not a major issue because most DHCP servers are smart enough to figure it out anyway. I would certainly appreciate if this was fixed in a future version of the firmware, but it's not a huge issue, just something everyone should be aware of.
Very good feedback. I have seen this before but being honest my DHCP server work like many others and would just simply process requests.
I am not sure if this is clearly written in RFC however neither way it is not the desired behavior of the switch.
-This switch is HW v01 (I will test if issue appear on HW v02 switch this week)
-I saw in wireshark that "DHCP ACK" comming from switch have TTL value at "1", is it normal ???
It is not normal but depends on what the DHCP server sends. I have done quick test in my lab with latest firmware 18.104.22.168 and boot code 1.3.5.06 and cannot see any difference comparing to old firmware. is your boot code the same as mine?