<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7654.12">
<TITLE>RE: [rbak-nsp] SE800 QoS architecture</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>
<P><FONT SIZE=2>>I'll be gratefull for any feedback as to the best way of terminateing<BR>
>and routing L2TP subs on particular line cards, but having routing fall<BR>
>back to others in the event of failure.<BR>
<BR>
Well, as I'm sure you know, L2TP subs must be associated with a linecard, in order for the redback to tie them to a "circuit", this is done by default like this:<BR>
<BR>
redback(config-l2tp)#lns card select ?<BR>
priority Use card priority to select card for session<BR>
route Use route to peer to choose card for session (default)<BR>
<BR>
The circuit is managed by the card who has the best route to the l2tp peer at the time, this is the "owner" card,<BR>
for instance, the GE-3 cards can terminate 16K of these (it is possibly now 32K, not heard if this limit has been increased or not), due to RAM constraints.<BR>
<BR>
You can also select a specific card for users to use :<BR>
<BR>
redback(config-l2tp)#lns card ?<BR>
1..14 Card number to locate sessions on<BR>
selection Specify card selection algorithm for LNS session circuits<BR>
<BR>
It used to be the case (not sure about now) that you could create a "group" of cards to share the sub load,<BR>
as you know, in order to avoid the 16K limit, the problem with this was that, if your sub is "owned" by card 1 but the route to the peer (where the EPPA is sending L2TP to the peer) is on card 2, then QoS is not possible because a virtual circuit had to exist between the PPA on card 1 and EPPA on card 2 which could not have prioritisation or congestion management applied to it (again, somebody correct me if this is now possible, this information could be out of date), so you had to ensure that subs stayed glued to the card where the active L2TP peer route was present if you wanted any QoS (which is why I suppose now the card-groups are no longer the default and peer route is)<BR>
<BR>
For information, we use the default (route to peer) method, meaning that the card sub limits are important to us.<BR>
<BR>
We have multiple boxes, each with a seperate "termination" context for each provider / DSLAM network,<BR>
at least two boxes have copies of this termination context, each context having a /32 loopback announced via routing protocol with the choice of l2tp peer to tunnel to (context, chassis) made by the DSL network.<BR>
<BR>
We also use intercontext routing, but run an IGP (routing protocol) , such as OSPF or IS-IS to create a loop free topology. We do not exchange default routes across this.<BR>
<BR>
Should there be a network event which causes an uneven number of subscribers to end up on a single linecard, we have a system which "rebalances" the cards by moving the subscribers off (and admin shutting the l2tp peer to prevent new sessions joining), this is done automatically and usually outside of business hours.<BR>
<BR>
Hope you find this information useful, am happy to go into more detail offlist if you so wish.<BR>
<BR>
David.<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>