<div class="gmail_quote">
<div>David</div>
<div> </div>
<div>A couple of my friends work at 2 large UK ISP's and they both load balance their host link resilient pairs without any problems (they don't shape towards the lac though) and the BT SIN pdf 472v1p9 details how to achieve load balancing over the pair. I think the main reason they load balance is less user disruption when one of the fibres fails. I do agree with you though as the same SIN doc does say that you should actually use them as active/standby.</div>
<div> </div>
<div>Am I correct in saying that your advise for shaping/queuing is as follows:</div>
<div> </div>
<div>1. Set the pair as active/standby</div>
<div>2. Configure subscribers to connect to the card that has the route back to the lac using the 'lns card selection route' command</div>
<div>3. Configure subscriber shaping as normal</div>
<div> </div>
<div>And in the event of the primary fibre failing</div>
<div> </div>
<div>1 Configure subscribers to connect to the card that now has the route back to the lac</div>
<div>2. Boot all users so they connect to the correct card</div>
<div> </div>
<div>Thanks</div>
<div>Rick</div>
<div>
<div></div>
<div class="h5">
<div> </div>
<div><br><br> </div>
<div class="gmail_quote">On 8 January 2011 15:09, David Freedman <span dir="ltr"><<a href="mailto:david.freedman@uk.clara.net" target="_blank">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 point of traffic egress toward the user is the ePPA (chip) on the<br>linecard facing the physical interface back towards the LAC IP that the user<br>
has been terminated from.<br>If you have two circuits on your hostlink and are using them in an<br>³active/active² scenario, I¹m assuming you receive the LAC /32 across both<br>linecards and can reach it through both with an equal metric (thus causing<br>
the load sharing to occur).<br><br>In this case, I don¹t believe ³lns card selection route² would work for you<br>if you wanted egress QoS back to the LAC as the card selected to own the<br>subscriber would only receive the traffic a certain percentage of the time.<br>
<br>From what I have seen, it is not common to have such "active/active" setups<br>across a single hostlink's constituent circuits as this was not their<br>original design (i.e they were orignally designed to be operated in an<br>
"active/passive" scenario) and you may find a number of other features (such<br>at BT aggregate policing) do not behave as expected.<br><br>Dave.<br>
<div>
<div></div>
<div><br><br>On 08/01/2011 14:48, "Richard Clayton" <<a href="mailto:sledge121@gmail.com" target="_blank">sledge121@gmail.com</a>> wrote:<br><br>> David<br>> <br>> Thanks for the response, my environment is dual homed to lac network which is<br>
> loadbalancing over the two links so the lac's can connect over either<br>> circuit. Basically its a BT 21cn host link which we are loadbalancing, would<br>> qos towards the lac still work with this setup.<br>
> <br>> Thanks<br>> Rick<br>><br>> On 8 January 2011 13:52, David Freedman <<a href="mailto:david.freedman@uk.clara.net" target="_blank">david.freedman@uk.clara.net</a>> wrote:<br>>> 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>>><br>
>><br>>> On 08/01/2011 13:13, "Richard Clayton" <<a href="mailto:sledge121@gmail.com" target="_blank">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<br>>>> 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<br>>>> 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>>>> _______________________________________________<br>>>> redback-nsp mailing list<br>>>> <a href="mailto:redback-nsp@puck.nether.net" target="_blank">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" target="_blank">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></div></div>>> <a href="http://www.claranet.com/" target="_blank">http://www.claranet.com</a> <<a href="http://www.claranet.com/" target="_blank">http://www.claranet.com/</a>><br>
<div>
<div></div>
<div>>><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>><br>><br><br>--<br><br>David Freedman<br>Group Network Engineering<br><br><a href="mailto:david.freedman@uk.clara.net" target="_blank">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></div></div></blockquote></div><br></div></div></div><br>