[f-nsp] CER: IPv6 Route ADD: CAM entry creation FAILED

Wed Sep 6 16:35:22 EDT 2017

Sounds like it's time to open a TAC case, then! :-)

Best regards,
Martijn

On 06-09-17 22:33, Brian Rak wrote:
>
> 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 <brak at gameservers.com
>>>> <mailto:brak at gameservers.com>> 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 <brak at gameservers.com
>>>>>> <mailto:brak at gameservers.com>> 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
>>>>>>     foundry-nsp at puck.nether.net <mailto:foundry-nsp at puck.nether.net>
>>>>>>     http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>>>>     <http://puck.nether.net/mailman/listinfo/foundry-nsp>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Be Well,
>>>>>>
>>>>>> Derek Labian
>>>>>
>>>>> _______________________________________________
>>>>> foundry-nsp mailing list
>>>>> foundry-nsp at puck.nether.net <mailto:foundry-nsp at puck.nether.net>
>>>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>>
>>>
>>>
>>> _______________________________________________
>>> foundry-nsp mailing list
>>> foundry-nsp at puck.nether.net
>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
>>
>> -- 
>> Met vriendelijke groet / Kindest regards,
>> Martijn Schmidt
>>
>>
>> i3D.net performance hosting 	
>> *Martijn Schmidt | Network Architect*
>> Email: martijnschmidt at i3d.net <mailto://martijnschmidt@i3d.net> |
>> 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>
>> 	
>>
>

-- 
Met vriendelijke groet / Kindest regards,
Martijn Schmidt

i3D.net performance hosting 	
*Martijn Schmidt | Network Architect*
Email: martijnschmidt at i3d.net <mailto://martijnschmidt@i3d.net> | 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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/foundry-nsp/attachments/20170906/5d13e529/attachment.html>