Mailing List Archive: VRFs, VPDN and Virtual Access Interfaces

VRFs, VPDN and Virtual Access Interfaces

Aug 10, 2007, 4:48 AM

Post #1 of 7 (9188 views)

Hi,

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.

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. Obviously the answer is to pre-clone as many VAIs as
possible but again, I'm concerned about the overhead of doing this.

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?

The router is a 7301 with 1GB memory. My RADIUS attributes for the VRF
users are:

Cisco-AVPair := lcp:interface-config=ip vrf forwarding customer_alpha
Cisco-AVPair += lcp:interface-config=peer default ip address pool
ALPHA_POOL Cisco-AVPair += lcp:interface-config=ip unnumbered Loopback
100

My VPDN config looks like this:

vpdn-group TEST
! Default L2TP VPDN group
accept-dialin
protocol l2tp
virtual-template 1
source-ip a.b.c.d
lcp renegotiation always
no l2tp tunnel authentication
!
interface Loopback10
description "The Internet"
ip address 192.168.100.1 255.255.255.0
!
interface Loopback100
description "Customer Alpha"
ip vrf forwarding customer_alpha
ip address 192.168.110.1 255.255.255.0 secondary ip address 4.0.4.1
255.255.255.0 !
interface Virtual-Template1
ip unnumbered Loopback10
ip mtu 1492
peer default ip address pool ADDR
ppp authentication chap

I would appreciate any pointers or information that the list can give
me.

Regards,

Dermot Williams

Senior Network Engineer
Irish Broadband Internet Services

Mobile: +353 86 3887961
DDI: +353 1 4818481


Note: 
This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Irish Broadband and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity.


Irish Broadband Internet Services Ltd, Registered in Ireland, Number: 357181, Registered Office: Burton Court, Burton Hall Road, Sandyford Industrial Estate, Dublin 18.<o:p></o:p>
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

Re: VRFs, VPDN and Virtual Access Interfaces [ In reply to ]

oboehmer at cisco

Aug 11, 2007, 1:35 AM

Post #2 of 7 (8516 views)

Permalink

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
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

Re: VRFs, VPDN and Virtual Access Interfaces [ In reply to ]

dermot.williams at irishbroadband

Aug 13, 2007, 3:46 AM

Post #3 of 7 (8493 views)

Permalink

> -----Original Message-----
> From: Oliver Boehmer (oboehmer) [mailto:oboehmer@cisco.com]
> Sent: 11 August 2007 09:36
> To: Dermot Williams; cisco-bba@puck.nether.net
> Subject: RE: [cisco-bba] VRFs, VPDN and Virtual Access Interfaces
>
> 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?
>
[Dermot Williams]

I have this working in a lab environment at the moment so I have
complete control over both the LNS and the LAC. In this lab scenario I
am working with just one 'subscriber', an 800 series router. Obviously,
in this case, I don't really have to worry too much about resource
consumption by VRF forwarded subscribers.

However, in our production it won't be so clear-cut. We resell DSL
connections using the local incumbent's wholesale DSL product so we
don't have any control over the LAC. On the production 7301 we have
approximately one thousand subscribers currently - these subscribers are
all internet-bound so we aren't doing anything fancy. Our intention is
to start offering L3VPN services over DSL so eventually there will be a
mix of subscribers who are destined for the internet and subscribers who
are dumped into a VRF.

> > 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.
>
[Dermot Williams]

Unfortunately, as I say, we don't have control over the LAC.

> 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.
>
[Dermot Williams]

This is all benched in the lab at the moment so I can chop and change as
I want for the moment. We're actually running 12.4(11)T so I'll have to
download a 12.2SB image to test these AVPairs. Does it matter what order
I send the 'lcp:allow-subinterface=yes' VSa in? I.e., should it be sent
before the other VSAs? Incidentally, is there anywhere that I can find a
list of AVPairs for each IOS version?

Thanks for your help,

Dermot


Note: 
This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Irish Broadband and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity.


Irish Broadband Internet Services Ltd, Registered in Ireland, Number: 357181, Registered Office: Burton Court, Burton Hall Road, Sandyford Industrial Estate, Dublin 18.<o:p></o:p>
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

Re: VRFs, VPDN and Virtual Access Interfaces [ In reply to ]

oboehmer at cisco

Aug 13, 2007, 10:38 AM

Post #4 of 7 (8499 views)

Permalink

Dermot Williams <mailto:dermot.williams@irishbroadband.ie> wrote on
Monday, August 13, 2007 12:47 PM:

>>>
>>> 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?
>>
> [Dermot Williams]
>
> I have this working in a lab environment at the moment so I have
> complete control over both the LNS and the LAC. In this lab scenario I
> am working with just one 'subscriber', an 800 series router.
> Obviously, in this case, I don't really have to worry too much about
resource
> consumption by VRF forwarded subscribers.
>
> However, in our production it won't be so clear-cut. We resell DSL
> connections using the local incumbent's wholesale DSL product so we
> don't have any control over the LAC. On the production 7301 we have
> approximately one thousand subscribers currently - these subscribers
> are all internet-bound so we aren't doing anything fancy. Our
intention is
> to start offering L3VPN services over DSL so eventually there will be
> a mix of subscribers who are destined for the internet and subscribers
> who are dumped into a VRF.

I wouldn't be that concerned with a thousand subscribers using full
VAIs. Can you tell how much sessions/sec you get with your user base? I
guess the only time you would see a difference is when the connection to
the incumbent goes down and all the sessions will need to be
re-established more or less at the same time. This can take longer with
full VAI..

>> 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.
>>
> [Dermot Williams]
>
> This is all benched in the lab at the moment so I can chop and change
> as I want for the moment. We're actually running 12.4(11)T so I'll
have
> to download a 12.2SB image to test these AVPairs. Does it matter what
> order
> I send the 'lcp:allow-subinterface=yes' VSa in? I.e., should it be
> sent before the other VSAs? Incidentally, is there anywhere that I can
> find a list of AVPairs for each IOS version?

Not sure, I'd send it first before the other attributes. There is also a
CLI "aaa policy inteface-config allow-subinterface" which enables this
globally..

oli
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

Re: VRFs, VPDN and Virtual Access Interfaces [ In reply to ]

dermot.williams at irishbroadband

Aug 17, 2007, 1:33 AM

Post #5 of 7 (8397 views)

Permalink

Oliver,

Thanks for your help - I've installed c7301-a3jk91s-mz.122-28.SB8.bin on
the (lab) router and I now have sub-interfaces working. I suppose the
next question I have to answer is whether or not the resource savings
that I can make by running this version of the code rather than the
12.4T line that we're running on the production 7301 is worth the
maintenance outage required to swap it!

Regards,

Dermot

> -----Original Message-----
> From: Oliver Boehmer (oboehmer) [mailto:oboehmer@cisco.com]
> Sent: 13 August 2007 18:38
> To: Dermot Williams; cisco-bba@puck.nether.net
> Subject: RE: [cisco-bba] VRFs, VPDN and Virtual Access Interfaces
>
> Dermot Williams <mailto:dermot.williams@irishbroadband.ie> wrote on
> Monday, August 13, 2007 12:47 PM:
>
> >>>
> >>> 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?
> >>
> > [Dermot Williams]
> >
> > I have this working in a lab environment at the moment so I have
> > complete control over both the LNS and the LAC. In this lab scenario
> I
> > am working with just one 'subscriber', an 800 series router.
> > Obviously, in this case, I don't really have to worry too much about
> resource
> > consumption by VRF forwarded subscribers.
> >
> > However, in our production it won't be so clear-cut. We resell DSL
> > connections using the local incumbent's wholesale DSL product so we
> > don't have any control over the LAC. On the production 7301 we have
> > approximately one thousand subscribers currently - these subscribers
> > are all internet-bound so we aren't doing anything fancy. Our
> intention is
> > to start offering L3VPN services over DSL so eventually there will
be
> > a mix of subscribers who are destined for the internet and
> subscribers
> > who are dumped into a VRF.
>
> I wouldn't be that concerned with a thousand subscribers using full
> VAIs. Can you tell how much sessions/sec you get with your user base?
I
> guess the only time you would see a difference is when the connection
> to
> the incumbent goes down and all the sessions will need to be
> re-established more or less at the same time. This can take longer
with
> full VAI..
>
> >> 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.
> >>
> > [Dermot Williams]
> >
> > This is all benched in the lab at the moment so I can chop and
change
> > as I want for the moment. We're actually running 12.4(11)T so I'll
> have
> > to download a 12.2SB image to test these AVPairs. Does it matter
what
> > order
> > I send the 'lcp:allow-subinterface=yes' VSa in? I.e., should it be
> > sent before the other VSAs? Incidentally, is there anywhere that I
> can
> > find a list of AVPairs for each IOS version?
>
> Not sure, I'd send it first before the other attributes. There is also
> a
> CLI "aaa policy inteface-config allow-subinterface" which enables this
> globally..
>
> oli


Note: 
This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Irish Broadband and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity.


Irish Broadband Internet Services Ltd, Registered in Ireland, Number: 357181, Registered Office: Burton Court, Burton Hall Road, Sandyford Industrial Estate, Dublin 18.<o:p></o:p>
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

Re: VRFs, VPDN and Virtual Access Interfaces [ In reply to ]

oboehmer at cisco

Aug 17, 2007, 1:43 AM

Post #6 of 7 (8425 views)

Permalink

Dermot,

you didn't say how much calls/sec you get on this box? If this is low (a
few per second), the overhead will possibly so low that you won't even
notice it. You'll really benefit from VAI subinterfaces when you deal
with several thousands of sessions and or a very high call load (guess
more than 20 or so calls/sec).
Do you see significant load in vtemplate backgr mgr (or similar)
process? Any process using up a considerable amount of CPU?

oli

Dermot Williams <mailto:dermot.williams@irishbroadband.ie> wrote on
Friday, August 17, 2007 10:33 AM:

> Oliver,
>
> Thanks for your help - I've installed c7301-a3jk91s-mz.122-28.SB8.bin
> on
> the (lab) router and I now have sub-interfaces working. I suppose the
> next question I have to answer is whether or not the resource savings
> that I can make by running this version of the code rather than the
> 12.4T line that we're running on the production 7301 is worth the
> maintenance outage required to swap it!
>
> Regards,
>
> Dermot
>
>> -----Original Message-----
>> From: Oliver Boehmer (oboehmer) [mailto:oboehmer@cisco.com]
>> Sent: 13 August 2007 18:38
>> To: Dermot Williams; cisco-bba@puck.nether.net
>> Subject: RE: [cisco-bba] VRFs, VPDN and Virtual Access Interfaces
>>
>> Dermot Williams <mailto:dermot.williams@irishbroadband.ie> wrote on
>> Monday, August 13, 2007 12:47 PM:
>>
>>>>>
>>>>> 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?
>>>>
>>> [Dermot Williams]
>>>
>>> I have this working in a lab environment at the moment so I have
>>> complete control over both the LNS and the LAC. In this lab
>>> scenario I am working with just one 'subscriber', an 800 series
>>> router. Obviously, in this case, I don't really have to worry too
>>> much about resource consumption by VRF forwarded subscribers.
>>>
>>> However, in our production it won't be so clear-cut. We resell DSL
>>> connections using the local incumbent's wholesale DSL product so we
>>> don't have any control over the LAC. On the production 7301 we have
>>> approximately one thousand subscribers currently - these subscribers
>>> are all internet-bound so we aren't doing anything fancy. Our
>>> intention is to start offering L3VPN services over DSL so
>>> eventually there will be a mix of subscribers who are destined for
>>> the internet and subscribers who are dumped into a VRF.
>>
>> I wouldn't be that concerned with a thousand subscribers using full
>> VAIs. Can you tell how much sessions/sec you get with your user
>> base? I guess the only time you would see a difference is when the
>> connection to the incumbent goes down and all the sessions will need
>> to be re-established more or less at the same time. This can take
>> longer with full VAI..
>>
>>>> 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.
>>>>
>>> [Dermot Williams]
>>>
>>> This is all benched in the lab at the moment so I can chop and
>>> change as I want for the moment. We're actually running 12.4(11)T
>>> so I'll have to download a 12.2SB image to test these AVPairs. Does
>>> it matter what order I send the 'lcp:allow-subinterface=yes' VSa
>>> in? I.e., should it be sent before the other VSAs? Incidentally, is
>>> there anywhere that I can find a list of AVPairs for each IOS
>>> version?
>>
>> Not sure, I'd send it first before the other attributes. There is
>> also a CLI "aaa policy inteface-config allow-subinterface" which
>> enables this globally..
>>
>> oli
>
>
>
>
>
> style='font-size:10.0pt;font-family:"Arial","sans-serif";
> color:#808080'>
> Note: 
> This message is for the named person's use only. It may contain
> confidential, proprietary or legally privileged information. No
> confidentiality or privilege is waived or lost by any
> mistransmission. If you receive this message in error, please
> immediately delete it and all copies of it from your system, destroy
> any hard copies of it and notify the sender. You must not, directly
> or indirectly, use, disclose, distribute, print, or copy any part of
> this message if you are not the intended recipient. Irish Broadband
> and any of its subsidiaries each reserve the right to monitor all
> e-mail communications through its networks. Any views expressed in
> this message are those of the individual sender, except where the
> message states otherwise and the sender is authorized to state them
> to be the views of any such entity. style='font-size:7.5pt;font-family:"Arial","sans-serif";
> color:#808080'>
> Irish Broadband Internet Services Ltd, Registered in Ireland, Number:
> 357181, Registered Office: Burton Court, Burton Hall Road, Sandyford
> Industrial Estate, Dublin 18. lang=EN-GB><o:p></o:p>
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba

Re: VRFs, VPDN and Virtual Access Interfaces [ In reply to ]

dermot.williams at irishbroadband

Aug 17, 2007, 1:49 AM

Post #7 of 7 (8408 views)

Permalink

> -----Original Message-----
> From: Oliver Boehmer (oboehmer) [mailto:oboehmer@cisco.com]
> Sent: 17 August 2007 09:43
> To: Dermot Williams; cisco-bba@puck.nether.net
> Subject: RE: [cisco-bba] VRFs, VPDN and Virtual Access Interfaces
>
> Dermot,
>
> you didn't say how much calls/sec you get on this box? If this is low
> (a
> few per second), the overhead will possibly so low that you won't even
> notice it. You'll really benefit from VAI subinterfaces when you deal
> with several thousands of sessions and or a very high call load (guess
> more than 20 or so calls/sec).
> Do you see significant load in vtemplate backgr mgr (or similar)
> process? Any process using up a considerable amount of CPU?
>
> oli
[Dermot Williams]

Oliver,

To be honest, I'm really worrying about nothing - our DSL service is
quite young and is peaking at about 700 concurrent users at the moment
so the call setup rate should probably be measured in minutes rather
than seconds! We obviously have huge scope for growth as it stands and
there's a pretty good chance that we will use a completely separate LNS
to deliver service to our L3VPN customers anyway.

With that in mind, I'll stop pestering you about this and worry about
something else instead!

Thanks again for your help though.

Regards,

Dermot

>
> Dermot Williams <mailto:dermot.williams@irishbroadband.ie> wrote on
> Friday, August 17, 2007 10:33 AM:
>
> > Oliver,
> >
> > Thanks for your help - I've installed
c7301-a3jk91s-mz.122-28.SB8.bin
> > on
> > the (lab) router and I now have sub-interfaces working. I suppose
the
> > next question I have to answer is whether or not the resource
savings
> > that I can make by running this version of the code rather than the
> > 12.4T line that we're running on the production 7301 is worth the
> > maintenance outage required to swap it!
> >
> > Regards,
> >
> > Dermot
> >
> >> -----Original Message-----
> >> From: Oliver Boehmer (oboehmer) [mailto:oboehmer@cisco.com]
> >> Sent: 13 August 2007 18:38
> >> To: Dermot Williams; cisco-bba@puck.nether.net
> >> Subject: RE: [cisco-bba] VRFs, VPDN and Virtual Access Interfaces
> >>
> >> Dermot Williams <mailto:dermot.williams@irishbroadband.ie> wrote on
> >> Monday, August 13, 2007 12:47 PM:
> >>
> >>>>>
> >>>>> 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?
> >>>>
> >>> [Dermot Williams]
> >>>
> >>> I have this working in a lab environment at the moment so I have
> >>> complete control over both the LNS and the LAC. In this lab
> >>> scenario I am working with just one 'subscriber', an 800 series
> >>> router. Obviously, in this case, I don't really have to worry too
> >>> much about resource consumption by VRF forwarded subscribers.
> >>>
> >>> However, in our production it won't be so clear-cut. We resell DSL
> >>> connections using the local incumbent's wholesale DSL product so
we
> >>> don't have any control over the LAC. On the production 7301 we
have
> >>> approximately one thousand subscribers currently - these
> subscribers
> >>> are all internet-bound so we aren't doing anything fancy. Our
> >>> intention is to start offering L3VPN services over DSL so
> >>> eventually there will be a mix of subscribers who are destined for
> >>> the internet and subscribers who are dumped into a VRF.
> >>
> >> I wouldn't be that concerned with a thousand subscribers using full
> >> VAIs. Can you tell how much sessions/sec you get with your user
> >> base? I guess the only time you would see a difference is when the
> >> connection to the incumbent goes down and all the sessions will
need
> >> to be re-established more or less at the same time. This can take
> >> longer with full VAI..
> >>
> >>>> 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.
> >>>>
> >>> [Dermot Williams]
> >>>
> >>> This is all benched in the lab at the moment so I can chop and
> >>> change as I want for the moment. We're actually running 12.4(11)T
> >>> so I'll have to download a 12.2SB image to test these AVPairs.
Does
> >>> it matter what order I send the 'lcp:allow-subinterface=yes' VSa
> >>> in? I.e., should it be sent before the other VSAs? Incidentally,
is
> >>> there anywhere that I can find a list of AVPairs for each IOS
> >>> version?
> >>
> >> Not sure, I'd send it first before the other attributes. There is
> >> also a CLI "aaa policy inteface-config allow-subinterface" which
> >> enables this globally..
> >>
> >> oli
> >
> >
> >
> >
> >
> > > style='font-size:10.0pt;font-family:"Arial","sans-serif";
> > color:#808080'>
> > Note: 
> > This message is for the named person's use only. It may contain
> > confidential, proprietary or legally privileged information. No
> > confidentiality or privilege is waived or lost by any
> > mistransmission. If you receive this message in error, please
> > immediately delete it and all copies of it from your system, destroy
> > any hard copies of it and notify the sender. You must not, directly
> > or indirectly, use, disclose, distribute, print, or copy any part of
> > this message if you are not the intended recipient. Irish Broadband
> > and any of its subsidiaries each reserve the right to monitor all
> > e-mail communications through its networks. Any views expressed in
> > this message are those of the individual sender, except where the
> > message states otherwise and the sender is authorized to state them
> > to be the views of any such entity. > style='font-size:7.5pt;font-family:"Arial","sans-serif";
> > color:#808080'>
> > Irish Broadband Internet Services Ltd, Registered in Ireland,
Number:
> > 357181, Registered Office: Burton Court, Burton Hall Road, Sandyford
> > Industrial Estate, Dublin 18. > lang=EN-GB><o:p></o:p>


Note: 
This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Irish Broadband and any of its subsidiaries each reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorized to state them to be the views of any such entity.


Irish Broadband Internet Services Ltd, Registered in Ireland, Number: 357181, Registered Office: Burton Court, Burton Hall Road, Sandyford Industrial Estate, Dublin 18.<o:p></o:p>
_______________________________________________
cisco-bba mailing list
cisco-bba@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-bba