[rbak-nsp] First post - SEOS Features
David Freedman
david.freedman at uk.clara.net
Tue Sep 19 19:59:11 EDT 2006
Jim
>- - Gige3 (PPA2) cards should take >16K subs (or circuits)
>Yes please!! I think thats more of a commercial issue than a technical
>one though. They would much rather sell you another
>card at 30k than increase the sub limit.
According to what I was told, the limitation is down to the amount of RAM
the card can use to deal with circuits, allthough it has sufficient RAM to
deal with 32K (theoretically) its never been tested at over 16K, but
I think its safe to assume that the reason that its not on big on the agenda
is that, as you said, they would rather sell more of them :)
>- - LNS Shaping for virtual circuits should work (think what happens when
>you use LNS group with dual PPA2 cards to overcome the above and want to
>shape them)
>Not sure what this is. Is this basic rate limiting or proper QoS shaping?
By this I mean WFQ and proper shaping (i.e delaying traffic gracefully as
opposed to just policing it)
>I'd also like to be able to pull traffic & packet info for L2TP tunnels
>via SNMP. I believe this
>has been raised and theres plans for enhanced L2TP mibs 'in the future'.
I think for a cli command or snmpd to report on a counter, statd needs to
have collected it first, I do think that statd collects some basic
ingress/egress tunnel packet counters , but I dont think it makes them
available to snmpd, its probably only for a cli command or aaad (radius)
accounting response.
I think, for what you are asking, there is additional work to be done to
statd in order to make the data available to all the other processes that
could ask for it (including snmpd)
Saying this however, I've found the speed at which features get into SEOS ,
to be considerably faster than AOS....
Dave.
Jim.
More information about the redback-nsp
mailing list