[j-nsp] M160/JunOS 7.6R1.10: ae0 fails to install L2 descriptor

[peter brenner]

Hello Josef,

thank you very much for your detailed reply.

>pb>  I have a couple of questions:
>pb>  a) Is it normal to have 32k L2 Descriptors for 8.2k Next-Hop Entries?
>
>      yes..  since  this is ethernet and the layer2 header size is
>      big for ethernet and you most likely have all three links on
>      one FPC. i.e 3 times more resources.

I had one PIC on fpc0 and 1 PIC on fpc1 (both non-e fpc1). I then added a 
second
PIC to fpc1.
I'll insert a spare fpc1 and retry with all links spread out.

>pb>  b) Is there a way to increase the number of available L2 Descriptors? 
>(how
>pb>  many L2 Descriptors does a SFM-16 support?)
>
>      this has nothing to do with the SFM.. Enhanced FPC will have
>      about 160K space... its all about memory

Oh okay, thank you. Is there a linear correlation between L2 Descriptors and 
Next-Hop
Entries?
Given that I move the third (and maybe someday fourth) link to separate 
non-e fpcs, and the usage on other interfaces stays about the same, can I 
calculate that we'll be
able to support about 50k / (32k / 8.2k) = 12.8k Next-Hops over that ae 
interface before we have to move the individual ae-links over to fpc-es?

>pb>  c) Is there a way to make the router fail with less impact to the 
>network
>pb>  (for example simply shutting down the new interface automatically 
>instead of
>pb>  refusing to update the next-hop table until the interface is taken 
>down and
>pb>  all sfms are restarted manually)
>
>      there  would  have been never a need to restart any SFM. all
>      you  would  have  need  to do is to deactivate the aggregate
>      interface and enable it again without the third member link.

I tried removing the one new link but I still got
Dec 29 03:58:12  ham-cr2-re1 /kernel: ae_link_op: link ge-1/3/0.2 (lidx=2) 
detached from bundle ae0.2
Dec 29 03:59:36  ham-cr2-re1 /kernel: RT_PFE: NH IPC op 31 (CHANGE AGGREGATE 
NEXTHOP) failed, err 5 (Invalid)

in the logfiles. This is when I decided to restart the SFMs.
Taking the entire aggregate interface down amounts to more impact to the 
network
imho (at least in our setup). With SFMs restarting I've got a couple seconds 
of little
packetloss, while a deactivated ae0 would mean x bouncing BGP sessions and 
traffic
stopping completely for a short amount of time.

>      In  fact you know only that you run out of resource once you
>      try to program it in hardware and the only way is to refuse
>      it. There is no real good way to know upfront. I believe the
>      RSMON  feature  is  able  to monitor such resources and will
>      send  an  alarm  if  configured  once  you reached a certain
>      threshold so you know that you are moving to the limits.

That makes sense.
I had actually looked at the nhdb stats beforehand but didn't consider 20k 
free entries
to be of concern.

Best Regards, Peter

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/