Hmm, thanks!
'show resource' at least gives us a counter of failed allocations. It
doesn't make a whole lot of sense to me, because we're seeing failed
allocations despite only being ~70% used:
[IP]1102400(size), 339702(free), 069.18%(used), 4198683(failed)
We're running with a system-max ip cache/route of 1000000 and ivp6
cache/route of 102400. 'sh default values' confirms those are actually
set, we ran into those limits ages ago (and have rebooted many times
since raising them)
On 9/6/2017 4:09 PM, i3D.net - Martijn Schmidt wrote:
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
