On the CER, the equivalent of "show cam-partition usage" is "show resource". I believe the IP entries include both IPv4 & IPv6.
"show default values" is also useful because you can see if your "system-max ipv6-route" is high enough - the default is only 8192 and your IPv6 DFZ table obviously won't fit if your system-max is set to such a low value. We tend to run it at 262144 because system-max is a fairly pointless feature anyway, it doesn't carve up your CAM, just restricts certain features from over-consuming resources that are shared with different features. And, of course, after messing around with system-max you're going to have to reload the device to apply the new settings. Best regards, Martijn On 06-09-17 21:53, Brian Rak wrote: > > What sort of resource limits are you running into here? Did you find > any sort of workaround, or are you just reloading all the time? > > > On 9/6/2017 3:45 PM, Youssef Bengelloun-Zahr wrote: >> Been there, suffer from it everyday. >> >> They might not have CAM profiles ala MLXe, but they still have >> CAMs... so they have limited and counted ressources. >> >> Best regards. >> >> >> >> Le 6 sept. 2017 à 21:37, Brian Rak <[email protected] >> <mailto:[email protected]>> a écrit : >> >>> CER's don't have CAM profiles. From the information I can find, >>> they don't actually use TCAM anyway. >>> >>> >>> On 9/6/2017 3:32 PM, Derek wrote: >>>> Did you check the CAM utilization? It's probably full, perhaps you >>>> can partition it differently. >>>> >>>> On Wed, Sep 6, 2017 at 2:30 PM, Brian Rak <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> Has anyone else seem problems with the CER's being unable to >>>> add routes before? We have multiple devices (all 2024C-4X) >>>> reporting one or both of these messages: >>>> >>>> IPv6 Route ADD: CAM entry creation FAILED >>>> IPv4 Network Route ADD: CAM entry creation FAILED >>>> >>>> They're learning a full v4+v6 table, but we are well below the >>>> limits defined in `sh default values`. From past experience, a >>>> reload seems to be the only thing that will actually correct >>>> this, but that is a pretty annoying thing to have to do. >>>> >>>> Any ideas for what may be causing this? We're on 5.6.0m right now. >>>> >>>> _______________________________________________ >>>> foundry-nsp mailing list >>>> [email protected] <mailto:[email protected]> >>>> http://puck.nether.net/mailman/listinfo/foundry-nsp >>>> <http://puck.nether.net/mailman/listinfo/foundry-nsp> >>>> >>>> >>>> >>>> >>>> -- >>>> Be Well, >>>> >>>> Derek Labian >>> >>> _______________________________________________ >>> foundry-nsp mailing list >>> [email protected] <mailto:[email protected]> >>> http://puck.nether.net/mailman/listinfo/foundry-nsp > > > > _______________________________________________ > foundry-nsp mailing list > [email protected] > http://puck.nether.net/mailman/listinfo/foundry-nsp -- Met vriendelijke groet / Kindest regards, Martijn Schmidt i3D.net performance hosting *Martijn Schmidt | Network Architect* Email: [email protected] <mailto://[email protected]> | Tel: +31 10 8900070 *i3D.net B.V. | Global Backbone AS49544* Rivium 1e Straat 1, 2909 LE Capelle aan den IJssel, The Netherlands VAT: NL 8202.63.886.B01 Website <http://www.i3d.net/?utm_source=emailsignature&utm_medium=email&utm_campaign=home> | Case Studies <http://www.i3d.net/partners/?utm_source=emailsignature&utm_medium=email&utm_campaign=case-studies> | LinkedIn <https://www.linkedin.com/company/i3d-net>
_______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
