[j-nsp] Virtual Chassis RPD/BGP Rsync high CPU

Scott Harvanek scott.harvanek at login.com
Wed Sep 24 17:35:21 EDT 2014


Disregard, 18 is correct, looks like IETF/RFC4893 has this as " 
AS4_AGGREGATOR" not AGGREGATOR4.

Scott H.
Login Inc.

On 9/24/14, 5:11 PM, Scott Harvanek wrote:
> Well shoot, that's a great idea, looks like this command is "hidden" 
> so I didn't even see it.  I assume AGGREGATOR4 is type code 18? I 
> can't find anything official confirming that though?
>
> Scott H.
>
> On 9/24/14, 3:39 PM, Alexander Arseniev wrote:
>> Have You tried "drop-path-attributes" 
>> http://kb.juniper.net/InfoCenter/index?page=content&id=JSA10491 ?
>> You can drop any attribute, not only 128 as in the KB.
>> Thanks
>> Alex
>>
>> On 24/09/2014 18:38, Scott Harvanek wrote:
>>> Okay so we traced this down to BGP Replication for NSR.  Looks like 
>>> a bad attribute kills the replication process.  Other than blocking 
>>> the received prefix is there a way to fix this:
>>>
>>> Sep 24 17:31:06  TUS-2-VC-1 rpd[48424]: Received malformed update 
>>> from xxxxxxxxx
>>> Sep 24 17:31:06  TUS-2-VC-1 rpd[48424]:   Family inet-unicast, 
>>> prefix 5.56.168.0/21
>>> Sep 24 17:31:06  TUS-2-VC-1 rpd[48424]:   Malformed Attribute 
>>> AGGREGATOR4(18) flag 0xc0 length 8.
>>> Sep 24 17:31:06  TUS-2-VC-1 rpd[48424]: Total incoming malformed 
>>> attributes from xxxxxxxxxx since last logging
>>> Sep 24 17:31:06  TUS-2-VC-1 rpd[48424]:   Received  1 malformed 
>>> attribute AGGREGATOR4(18)
>>>
>>> Mind you, the primary session with the peer stays up, this only 
>>> kills the replication process...
>>>
>>> Scott H.
>>>
>>> On 9/18/14, 11:38 AM, Scott Harvanek wrote:
>>>> Has anyone had a issue with MX units in a VC where BGP rsync was 
>>>> consuming a boatload of CPU?
>>>>
>>>> Master chassis shows:
>>>> Task                       Started    User Time  System Time 
>>>> Longest Run
>>>> BGP rsync                     9650          10. 0.8 0.0
>>>> ( BGP rsync is the only task with any user time during high user 
>>>> CPU for rpd )
>>>>
>>>> now, that's only like 20% CPU on the master but on the slave it's 
>>>> 90%....  This seems to have happened when our total paths exceeded 
>>>> 2MM but does not seem to be a memory issue:
>>>>
>>>>     Dynamically allocated memory:  411009024      Maximum: 808517632
>>>>          Program data+BSS memory:    5537792      Maximum: 5537792
>>>>               Page data overhead:    1196032      Maximum: 1196032
>>>>              Page directory size:     212992      Maximum: 212992
>>>>                   ----------
>>>>               Total bytes in use:  417955840 (12% of available memory)
>>>>
>>>
>>> _______________________________________________
>>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>>
>> _______________________________________________
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/juniper-nsp
>
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp



More information about the juniper-nsp mailing list