[cisco-bba] VRFs, VPDN and Virtual Access Interfaces

[Oliver Boehmer (oboehmer)]

Dermot Williams <> wrote on Friday, August 10, 2007 1:48 PM:

> I'm new to the list so I apologise in advance if any of the questions
> that I am asking have been asked and answered ad nausea. In my
> defence, I did search the archives first and have already found
answers to
> other questions that I had.
> 
> I'm doing some testing with L2TP-based VPDNs and VRFs for a future
> L3VPN product. My goal is to switch certain users into a VRF
configured on
> the LNS and to continue to allow other users access to the internet. I
> have this working but I do have some questions about my
implementation.
> 
> My main issue is that all of the VRF users are given a Virtual Access
> interface and not a Virtual Access sub-interface. I know why this is
> happening - I am using RADIUS to send "lcp:interface-config= ... "
> attributes back for the VRF users. However, I also know that Virtual
> Access interfaces have a larger memory/CPU overhead than VA
> sub-interfaces.

this is correct, the impact, however, depends on the number of sessions
and also the session setup rate. So full VAI are no "bad" per se, it
depends on the environment. Can you describe your environment a bit
more?

> To mitigate against this I can pre-clone the VAIs but my understanding
> is that if there are pre-cloned VAIs, none of my users will be
> allocated VA sub-interfaces and I would like to avoid this if
possible. I don't
> want to use VAIs unless absolutely necessary and my assumption is that
> if I were to pre-clone 50 VAIs, only 50 users would be allowed online
> at a given time. 

No, this is not correct, if the system needs more VAIs, it allocates
them as needed.

> Instead of using RADIUS attributes to create a user-specific VAI, is
> there anyway that I could use them to force the VPDN session to use a
> Virtual-Template interface that already has the correct config on it?

Yes, this is one of the two options. But you would need the LAC to
forward these sessions in a different tunnel (and you can then use
"terminate-from hostname <foo>" to map those to a vpdn-group  (i.e. one
vpdn-group per vrf). This could be a problem if the LAC is not owned by
you, or if the LAC doesn't know which vrf the user belongs to.

In latest 12.2SB, you have two additional options:

1) Use Cisco-avpair = "ip:vrf-id=<vrf-name>" and
"ip:ip-unnumbered=Loopback<n>", which are subinterface-capable

2) Use Cisco-avpair = "lcp:allow-subinterface=yes" and use the
"lcp:interface-config" commands you've mentioned. This is a workaround
for those lcp:interface-config config statements which are actually
subinterface-capable, which I think is the case for all the ones you
sent (vrf, unnumbered, pool). Other, non sub-VAI compatible config
commands will be ignored, as far as I know.

Please try this in the lab first, haven't really worked with this for a
while now.

	oli