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

I am also wondering if there is some local condition than can trigger 
this. Running into a IPv6 route condition: Ok - running also into a IPv4 
condition and also on all CER-devices: Well!

What about the mac-address size table? Is the rest of the network as 
stable as it should be like? Do you run 05.6.00m on all devices? Can you 
upgrade one CER e.g. to a newer 6.1? I have found DEFECT000549512 <= 
5.9, but this should be fixed in the m-version.

Can you post
show default values
show ip cache
show ipv6 cache

Jörg

On 6 Sep 2017, at 22:35, i3D.net - Martijn Schmidt wrote:

> 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 <[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]
http://puck.nether.net/mailman/listinfo/foundry-nsp