[c-nsp] per-user MCQ on vaccess interfaces?

[Andre Beck]

Hi,

On Wed, Nov 16, 2005 at 07:20:09AM +0100, Gert Doering wrote:
> On Wed, Nov 16, 2005 at 12:21:20PM +1100, Nick Shah wrote:
> > Both MQC and CAR are supported. Using Radiator (other radiuses syntax
> > would differ) here's how we do it.
> [..]
> > MQC : 
> > 
> >     cisco-avpair = "lcp:interface-config#6=service-policy out
> > CE-Pol-16kI-240kBD",
> >     Framed-IP-Address = 10.255.64.238
> > 
> > Ps. The actual policy map (and subsequent class maps) should be
> > preconfigured on the router.
> 
> Well - that's actually more along the line of "per-user config not
> being supported" :-/

It's something in the middle. As long as "per-user" can be broken down
to a manageable number of predefined policy maps, it is actually more
elegant than doing everything detailed in RADIUS. The problem is to
design a decent set of building blocks that make up maps which fit 99%
of the cases needed.
 
> Pre-requisite in our case is that the service-policies can contain
> user-specific elements (for VPN services with QoS), and that we do 
> NOT want to configure the stuff on the NAS.

Not at all or just "not manually"? And on user specificness, is it really
necessary to build fully individual policies (like ones matching certain
individual IP addresses) or could the policies be expressed in more
generic ways (like matching on IKE/ESP, or on precedence/DSCP, with
the customer himself providing the correct TOS markings)?
 
> Well.  So either it's "do this with a unix box" (mpd on FreeBSD *can*
> do this), or "run scripts to nightly pre-configure all policy maps
> for non-standard users on the NAS".

The script could eventually use RADIUS data itself (or data from the
actual backend that just feeds RADIUS) to build these maps. One might
introduce private RADIUS AVPairs for this purpose or such.

But beware: In recent threads about MQC I've read on this very list
there was a repeated statement that MQC will *not* (yet) work in certain
vaccess environments, namely those used to concentrate DSL access in
Germany (L2TP VPDN termination). It was planned to be implemented, but
at that time was dysfunctional. You should make sure it is available
for your application at all before rolling out the management solution.
And when you find a working solution, I'd be interested in feedback ;)

HTH,
Andre.
-- 
                  The _S_anta _C_laus _O_peration
  or "how to turn a complete illusion into a neverending money source"

-> Andre Beck    +++ ABP-RIPE +++    IBH Prof. Dr. Horn GmbH, Dresden <-