<div>David</div>
<div> </div>
<div>Thanks for the response, my environment is dual homed to lac network which is loadbalancing over the two links so the lac's can connect over either circuit. Basically its a BT 21cn host link which we are loadbalancing, would qos towards the lac still work with this setup.</div>
<div> </div>
<div>Thanks</div>
<div>Rick<br><br></div>
<div class="gmail_quote">On 8 January 2011 13:52, David Freedman <span dir="ltr"><<a href="mailto:david.freedman@uk.clara.net">david.freedman@uk.clara.net</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">The ³load sharing² of l2tp subscribers to multiple cards is when acting as<br>an LNS is the default configuration.<br>
<br>In order to force subscribers to terminate on a particular card, use the<br>³lns card selection² configuration directive under your l2tp-peer to the<br>LAC/LTS<br><br>³lns card selection route² will terminate the subscribers on the card to<br>
which the route to the LAC is present as the preferred option,<br><br>"lns card X preference Y" will set preference of Y for card X either in<br>addition to or instead of the route selection algorithm above.<br>
<br>The goal if you are doing any kind of QoS back to the LAC is to have the<br>subscriber terminating on the same card as the route back to the LAC exists,<br>since the box does not do any QoS across linecards internally (between the<br>
PPAs) , this means configuring the "lns card selection route" on all LAC<br>peers ideally , but this puts you in the unfortunate situation of having to<br>change cards automatically (and dump all subs on the card) should you be<br>
multihomed to the LAC and lose the link on this card (i.e the route<br>changes).<br><br>Dave.<br>
<div>
<div></div>
<div class="h5"><br><br>On 08/01/2011 13:13, "Richard Clayton" <<a href="mailto:sledge121@gmail.com">sledge121@gmail.com</a>> wrote:<br><br>> Looking at the output of the command 'show l2tp global ipc' we have 5<br>
> subscribers on card 1 and 17 on card 2, what part of the configuration steers<br>> subscribers to card 1 and 2 and what is best practice for subscriber/card<br>> termination.<br>> <br>> I have read that if subscriber shaping is configured the subscribers have to<br>
> terminate on the same card the L2TP tunnel terminates on, how do I ensure that<br>> L2TP and subs all connect to same card (or is this not best practice)<br>> <br>> Num Circuits (L2TP):<br>> 1: 5, 2: 17, 3: 0, 4: 0, 5: 0, <br>
> 6: 0, 7: 0, 8: 0, 9: 0, 10: 0, <br>> 11: 0, 12: 0, 13: 0, 14: 0, <br>> Thanks<br>> Rick<br>><br>><br></div></div>> _______________________________________________<br>
> redback-nsp mailing list<br>> <a href="mailto:redback-nsp@puck.nether.net">redback-nsp@puck.nether.net</a><br>> <a href="https://puck.nether.net/mailman/listinfo/redback-nsp" target="_blank">https://puck.nether.net/mailman/listinfo/redback-nsp</a><br>
<br>--<br><br>David Freedman<br>Group Network Engineering<br><br><a href="mailto:david.freedman@uk.clara.net">david.freedman@uk.clara.net</a><br>Tel +44 (0) 20 7685 8000<br><br>Claranet Group<br>21 Southampton Row<br>London - WC1B 5HA - UK<br>
<a href="http://www.claranet.com/" target="_blank">http://www.claranet.com</a><br><br>Company Registration: 3152737 - Place of registration: England<br><br>All the information contained within this electronic message from Claranet<br>
Ltd is covered by the disclaimer at <a href="http://www.claranet.co.uk/disclaimer" target="_blank">http://www.claranet.co.uk/disclaimer</a><br><br><br></blockquote></div><br>